# Insert password code into an .Exe file



## -Fabez- (Jul 28, 2008)

I am trying to create a utility that will allow me to add some code to any .Exe file on my computer. The code I would like to add is small and will be used to prompt the user for a password, without which the user cannot gain access to the program. Does anyone have idea's on where to place the code or which language to use ? Any help or input will be greatly valued


----------



## DoubleHelix (Dec 10, 2004)

An EXE is a compiled program. You can't "insert" anything into one. You'd have to modify the source code or files and re-compile it.


----------



## TheRobatron (Oct 25, 2007)

Alternatively, you could write another EXE that validates the password and then calls the program if it's correct. This would however be very easy to bypass. I'm not quite sure how (and it'll probably be complicated) but I think you may be able to place the contents of the existing exe file into another exe with the password code in (so they would in effect be separate executables, but unseparable to users).


----------



## Chicon (Jul 29, 2004)

TheRobatron said:


> Alternatively, you could write another EXE that validates the password and then calls the program if it's correct. ...


I'm thinking about a kind of _wrapper_ program that encloses the .exe as data and that validates a password. When the password is correct, the _wrapper_ executes the enclosed .exe. The password part of the coding should be piece of cake but the way to launch the .exe from inside may be a bit tricky (needs certainly assembly coding).


----------



## jdean (Jan 20, 2002)

Simpler than a wrapper is to change the extension of the original file from .exe to something else (preferably something unique). I believe the invoking  program should be able to successfully execute the original program despite the non-standard extension. However, double-clicking the file with the nonstandard extension will fail.

Programs like Armadillo (used to be affordable but no longer) did what Chicon suggests; perhaps there are others out there that would work for you. Similarly, unzip programs (there are open source versions) allow you to double click and run an executable; in fact, if the file is encrypted, these programs will prompt for a password.


----------



## -Fabez- (Jul 28, 2008)

Thanks for all of the responces  Jdean you have a good idea, but couldnt they just change the extension back and run the program ? Chicons idea is really good and I would like to try to make a wrapper, but have no idea where to start, does anyone have any idea's ?


----------



## Codiah (Sep 27, 2008)

The best i can think is an included file, but anyone with even a lick of programming knowledge would be able to get around that one.. hmm.. if i think of anything i'll drop back by... as for an actual wrap, i'm lost there, looks like i have some research to do..


----------



## Codiah (Sep 27, 2008)

Sorry, just had a thought, i'm clueless when it comes to a wrapper rogram, but have you maybe thought of encryption, set up a program that compiles with whatever you want protected as the included file, but encrypt it.. then it would be as easy as running the program letting the file unpack and be automatically decrypted by your password program once the password is input... if that didn't make any sense let me know, i'm a little restless at the moment...


----------



## jdean (Jan 20, 2002)

Fabez, If you're not worried about hackers, then changing the file extension should be adequate. How would the average user know to change the extension?

If you want a real protection scheme, check out Armadillo and similar packages. Hackers will be able to crack most roll-your-own solutions; you would have to spend a lot of time to create something that is reasonably secure.


----------



## TheRobatron (Oct 25, 2007)

jdean said:


> Fabez, If you're not worried about hackers, then changing the file extension should be adequate. How would the average user know to change the extension?


Most average users I know are able to change the file extension and those who don't I'm sure will have people who will know how. It really depends on how secure you want it to be, but you don't have to be a hacker to bypass it.

It was a wrapper I was trying to explain in a roundabout sort of way  I think encryption is a good idea as it would be hard to reverse engineer the program to find the method of encryption to crack it (or even harder to brute-force the encyption) though it still won't be totally secure.


----------



## jdean (Jan 20, 2002)

Of course changing an extension is easy (although the Windows default hides extensions). That wasn't the question I meant to ask.

The question was: how would they know that they could work around the scheme by changing the extension? And how would they know which file to change?

If you use a single password for all users, then you've got little protection. If you create a separate password for each user and you use that to decrypt the file, then you've got better protection. However, there are very good password cracking programs out there and if you choose strong passwords, your users are never going to remember them.


----------



## Codiah (Sep 27, 2008)

well how about, script a small EXE that will allow you to input a password as an option, but will then execute the decryption program with a much longer password string, at least 15 characters, most cracking programs can't crack passwords that long, and if they can no hacker is going to want to wait a week for it to be brute-forced, and if you set it to a three try limit on the EXE, a brute force program wont work on it as it will shut down and make them restart.. that would be a work around so you wouldn't have to change the file extension, it would just use an SDA file through your EXE file..


----------



## jdean (Jan 20, 2002)

@Codiah: I could point out a number of issues with the approach you suggested but I'd rather look at this more generally. In the cryptography community, there is general agreement that creating your own algorithms and security schemes is a guarantee of failure. Successful schemes only become so after review by a larger community.

Please note that I'm drawing a parallel here. I'm not saying that we need to ask Rivest, Shamir, and Adelman (RSA) for help. What I'm saying is that anything you or I come up with will have loopholes.

My recommendation is to use a package/library that has already had some testing in the real world. However, if the need for security is basic (and we're still waiting for the original poster to weigh in on this) then perhaps a homebrewed scheme would be sufficient. As a software developer, I have deployed both homebrew and world-class cryptographic solutions. It all depends on the product requirements.


----------



## Codiah (Sep 27, 2008)

This is my idea... if you compile this into an .EXE with your original file included as an SDA File (easily made with winrar) it would work rather nicely.. if needed you could even add a small script to the end that would delete the SDA file and origonal exe so they wouldnt remain on the computer..

@ECHO off
color 7
ECHO.
ECHO Unpacking file...
ping localhost -n 4 >nul * /// gives time for included file to drop...*
REM start
:start
color 7
ECHO.
ECHO.
ECHO Please input password..
ECHO or type "Q" to exit program..
ECHO.
ECHO.
SET /p option=
IF '%option%'== 'q' GOTO EXIT
IF '%option%'== 'Q' GOTO EXIT
IF '%option%'== 'quit' GOTO EXIT
IF '%option%'== 'Quit' GOTO EXIT
IF '%option%'== '*YourShortPWHere*' GOTO decrypt
GOTO error
REM Error message if input is invalid..
:error
cls
color c
ECHO.
ECHO.
ECHO Invalid Input...
ping localhost -n 3 >nul
GOTO start
REM Exit section..
:EXIT
CLS
EXIT
REM decrypt
:decrypt
CLS
*MySDAfile.exe* -P*<InsertLongPWhere>*
ping localhost -n 4 >nul */// Gives time for file to decrypt properly..*
START *OrigionalFileName.exe*
ping localhost -n 2 >nul
GOTO EXIT


----------



## Codiah (Sep 27, 2008)

jdean said:


> @Codiah: I could point out a number of issues with the approach you suggested but I'd rather look at this more generally. In the cryptography community, there is general agreement that creating your own algorithms and security schemes is a guarantee of failure. Successful schemes only become so after review by a larger community.
> 
> Please note that I'm drawing a parallel here. I'm not saying that we need to ask Rivest, Shamir, and Adelman (RSA) for help. What I'm saying is that anything you or I come up with will have loopholes.
> 
> My recommendation is to use a package/library that has already had some testing in the real world. However, if the need for security is basic (and we're still waiting for the original poster to weigh in on this) then perhaps a homebrewed scheme would be sufficient. As a software developer, I have deployed both homebrew and world-class cryptographic solutions. It all depends on the product requirements.


I was writing that last thing up when you replied jdean, and i understand exactly where your comming from, but in that example i'm using a codded archive made by winrar, this could also be done with an SDA archive from PGP, so those are already in use and tested, so would that be satisfactory? like i said i understand what your saying, but perhaps thats a comfortable medium... you just have to work the script to run the already made SDA and then launch the program it extracts..


----------



## jdean (Jan 20, 2002)

@Codiah: Password-based encrypted files, such as SDAs, can be cracked with widely available tools. So it would be easy to crack the SDA, read the line in the batch file, and then run it yourself.

If you think about it for a minute, using a short password to protect a long password gives you the security of the short password.

Nothing personal but I really don't want to continue any further on the subject of creating secure protection schemes, so I'm going to drop out of this discussion unless something different turns up. The rest of you are of course most certainly welcome to continue without me


----------



## Codiah (Sep 27, 2008)

jdean... 
well it wouldn't be a batch file, i'd presume anyone would convert it to an exe before actually using it.. but yea, understandable.. well then i'm stumped from here, to be honest, i'm with you on this one, there's really not much we can do that doesn't produce some loophole in some way... nothing that a simple reverse engineering tool wouldnt negate.. 

well thanks for the input anyway, jdean.. it was nice that you at least looked at the idea..


----------

