Password Hiding

Hi,

I have created batch file for DB deployment scripts.
So i have given the Username and passwords for Schema connection purpose (Oracle database).
Is there any way by which i can hide the Password from the deployer in batch file..

Regards

No, Batch Files have no security what so ever.

No, Batch Files have no security what so ever.

But is you convert a BAT into a EXE, does that not help a little?

[Moderator]

Nope.
Well yes...
Maybe.

I gave you a Thank you.
For your concise, comprehensive answer.   

Best way to hide it is to have the script execute from a server side with admin permissions over all lower level workstations where users could never get their hands on the script to decompile the exe etc.

Is there a way to deploy the changes down to the systems server side down or does it have to be workstation side authenticating for passthrough to server side or to run runas admin in user environment for a mapping etc?

Other than Bat2EXE, I have also hid authentication scripts inside other programs before such as writing C++ to run system(); commands and use tricks in C++ to hide the window, but I will not divulge further as to how to do this as for it could be used for the worng purpose and its against CH Policy to describe such a device in detail to share how to go about making one that could be used as a virus etc.

When the system was first set up, the Administrator, or System Designer, had the option of letting an Administrator execute programs on a client so that the program run in the client environment. The administrator would pass command line parameters to the executable and it would modify the client system. Sorry, I don't know more. I read that somewhere.

@bholeuday
you can use choice instead of "hard typing" password, but i dont know if you can use it.

I'm wondering if he means Hide the password in a Batch file so that the batch file uses that password to log into the DB.

If he means that then, BAT2EXE is possible.

But if he means Hide the password in a batch file just for safe keeping(which i doubt) then its pretty much pointless.

Best way to hide it is to have the script execute from a server side with admin permissions over all lower level workstations where users could never get their hands on the script to decompile the exe etc.

Is there a way to deploy the changes down to the systems server side down or does it have to be workstation side authenticating for passthrough to server side or to run runas admin in user environment for a mapping etc?

Other than Bat2EXE, I have also hid authentication scripts inside other programs before such as writing C++ to run system(); commands and use tricks in C++ to hide the window, but I will not divulge further as to how to do this as for it could be used for the worng purpose and its against CH Policy to describe such a device in detail to share how to go about making one that could be used as a virus etc.

How would someone get around to "Decompiling" a .exe that was previously a .bat to its original state? You guys are always talking about it, but I can't find one...

How would someone get around to "Decompiling" a .exe that was previously a .bat to its original state? You guys are always talking about it, but I can't find one...

Why should we tell you? Or publish it on the web for all to see? Better if only a few know.

it's not decompiling at all. NOTHING GET'S COMPILED.


it's just a stub EXE with a bat file tacked onto the end. nothing sophisticated at all about that.

the supposedly "better" ones encrypt the batch file before attaching it. This doesn't help at all because Process Explorer can view the Strings in memory after being decrypted. In fact, the "compiler" is often so weak it doesn't even bother to run through the batch and remove comments, which really serve no purpose in a "compiled" batch file.

Really it's a poor solution to pretty much anything. In fact I'm hard pressed to even think of a hypothetical situation where a "compiled" batch file is more useful then just a batch file. The most common usage is for "hiding" the batch code by compiling it. As I explained however this is a terrible reason to do so. I mean- let's be frank here- they're batch files. they aren't going to contain any patentable algorithms- they are usually just a group- a batch, of DOS commands strung together. I doubt you can apply for a patent, "redirecting output from the SORT command to a text file later processed with a FIND /I".

Basically there is nothing to know. It takes logic.

The executables are ALWAYS a set size larger then the size of the batch file. this says that it adds the SAME code on top of the batch file. if the program was literally compiling the batch into assembly, then various constructs such as for loops and so forth will be far larger in assembly. Also, the resulting program will need to duplicate all the functionality of cmd, including of course for loops, string parsing, evaluation, how parameters are passed, etc.


basically, it's impossible to package a batch as a Pure EXE- and if somebody "needs" too, then there is something amiss.


basically what Dave is describing is a "functional" equivalent, whereby a C++ program is constructed using a series of "SYSTEM" calls.

The one drawback nowadays is that that blasted cmd interpreter is now a state machine while parsing and running the batch file- whereas before each line was a single atomic operation, now there are multi-line loops and control structures. Basically the only "feasible" solution would be to rewrite the entire program in C/C++(or other language) for compilation, using the equivalent control structures in C. Of course, it would be faster to have started off with C/C++.

Wait abit here. I just tried the BAT2EXE from this site. I could not easily read the contents of the EXE file. Am I missing something?

if I'm not wrong, that exe just have your file packed then extract it to TMP folder and run, so run your exe and check TMP folder

and...

it's not decompiling at all. NOTHING GET'S COMPILED.


it's just a stub EXE with a bat file tacked onto the end. nothing sophisticated at all about that.

the supposedly "better" ones encrypt the batch file before attaching it. This doesn't help at all because Process Explorer can view the Strings in memory after being decrypted. In fact, the "compiler" is often so weak it doesn't even bother to run through the batch and remove comments, which really serve no purpose in a "compiled" batch file.

Really it's a poor solution to pretty much anything. In fact I'm hard pressed to even think of a hypothetical situation where a "compiled" batch file is more useful then just a batch file. The most common usage is for "hiding" the batch code by compiling it. As I explained however this is a terrible reason to do so. I mean- let's be frank here- they're batch files. they aren't going to contain any patentable algorithms- they are usually just a group- a batch, of DOS commands strung together. I doubt you can apply for a patent, "redirecting output from the SORT command to a text file later processed with a FIND /I".

Basically there is nothing to know. It takes logic.

The executables are ALWAYS a set size larger then the size of the batch file. this says that it adds the SAME code on top of the batch file. if the program was literally compiling the batch into assembly, then various constructs such as for loops and so forth will be far larger in assembly. Also, the resulting program will need to duplicate all the functionality of cmd, including of course for loops, string parsing, evaluation, how parameters are passed, etc.


basically, it's impossible to package a batch as a Pure EXE- and if somebody "needs" too, then there is something amiss.


basically what Dave is describing is a "functional" equivalent, whereby a C++ program is constructed using a series of "SYSTEM" calls.

The one drawback nowadays is that that blasted cmd interpreter is now a state machine while parsing and running the batch file- whereas before each line was a single atomic operation, now there are multi-line loops and control structures. Basically the only "feasible" solution would be to rewrite the entire program in C/C++(or other language) for compilation, using the equivalent control structures in C. Of course, it would be faster to have started off with C/C++.

it's not decompiling at all. NOTHING GET'S COMPILED.

How would someone get around to "Decompiling" a .exe that was previously a .bat to its original state? You guys are always talking about it, but I can't find one...

Note the quotes around Decompiling...