Insert password code into an .Exe file

Status
This thread has been Locked and is not open to further replies. Please start a New Thread if you're having a similar issue. View our Welcome Guide to learn how to use this site.

-Fabez-

Thread Starter
Joined
Jul 28, 2008
Messages
1,899
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 :D
 

DoubleHelix

Banned
Joined
Dec 9, 2004
Messages
24,388
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.
 
Joined
Oct 25, 2007
Messages
551
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).
 
Joined
Jul 29, 2004
Messages
6,650
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).
 
Joined
Jan 20, 2002
Messages
433
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-

Thread Starter
Joined
Jul 28, 2008
Messages
1,899
Thanks for all of the responces :D 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 ?
 
Joined
Sep 27, 2008
Messages
116
:confused: 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..
 
Joined
Sep 27, 2008
Messages
116
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...
 
Joined
Jan 20, 2002
Messages
433
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.
 
Joined
Oct 25, 2007
Messages
551
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.
 
Joined
Jan 20, 2002
Messages
433
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.
 
Joined
Sep 27, 2008
Messages
116
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..
 
Joined
Jan 20, 2002
Messages
433
@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.
 
Joined
Sep 27, 2008
Messages
116
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
 
Joined
Sep 27, 2008
Messages
116
@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..
 
Status
This thread has been Locked and is not open to further replies. Please start a New Thread if you're having a similar issue. View our Welcome Guide to learn how to use this site.

Users Who Are Viewing This Thread (Users: 0, Guests: 1)

As Seen On
As Seen On...

Welcome to Tech Support Guy!

Are you looking for the solution to your computer problem? Join our site today to ask your question. This site is completely free -- paid for by advertisers and donations.

If you're not already familiar with forums, watch our Welcome Guide to get started.

Join over 807,865 other people just like you!

Top