Storing password info inside the exe

Editing the EXE Sounds tricky, but this is how I would do it.

1. Put an invisible text box on your form somewhere, and assign it's design time Text property to something specific, such as "ABCDEFGHIJ"  making sure it's as long as the password size limit.

In your password validation code, use this textbox.text as the string to compare with.

2. Compile the program

3. search the exe file, byte by byte, for the string "ABCDEFGHIJ" and note the starting and ending bytes.  You can use wordpad for this, I think.

4.  In your save password routine, write the new password to the exe file, replacing the old characters with the new ones, in the exact location they were found.  Pad with spaces if the new password is shorter.

5.  Repeat steps 2 - 4 until it's stable.  Every time you change your code and recompile, the bytes can end up in a different place.  


Potential Hurdles:  
1. Writing an EXE file while it's running might not be possible.
2. Hackers could easily extract the password, unless it's encrypted somehow.

A Better Way:

Hide your password in the registry.  Registry Keys don't have to say what they are.  No-one would know which key to investigate, and even if they did, you would encrypt the password anyway, so it would be useless to anyone trying to gain unauthorized access.  It's easy and fun to write an encryption/decryption function.  

I like to shift the ASCII values of the characters using a changing seed value.  The seed array is known only to you.  The CIA could bust it, but really, how secret is your app, really?

I'm sure there'd be dozens of other suggestions if you asked about encrypting a string.

Good Luck
-Lunch

Writing an EXE while it is running is *NOT* possible. So this approach flat will *NOT* work.

A mildly encrypted registry entry should be secure enough. Do something like reversing the bits MS/LS and no-one will stumble across it.

M

you could also add the same password to two diferent locations in the regestrey and check both agenist each other and with the user entered password.  this will allow you to detect if someone is trying to change and information.  On detection you could make the program display a message to that effect and lock it out.

You should reject my answer to unlock this question.  That way, you'll get more response

I have seen programs that do what I want to learn how to do.  The password would be encrypted inside the exe.  If editing the exe while running is impossible, how about terminating the exe just after shelling a second program (with the encrypted password as its command parameter) that will edit the main exe with the new password, shell the main exe, and then terminate itself.  I am rejecting lunchrevisited's proposed answer to unlock this question.  I would like to get more responses to my question.  Thank you!

There are lots of ways to make your software password protected. None of them are really tight. With the proliferation of virus scan software, attempting to modify a .EXE footprint might trigger the anti-virus program. Additionally what are you going to do, not allow running from CD, secured LAN's, write protected floppy's? There are a lot of ways to ensure a certain level of security but the *best* way is to simply practice good physical security instead of going nutz trying to double encrypt your files, etc.

Most times if I find a program that is getting snotty about things I'll either bypass it and edit the data direct or drill out the locks. Placing the password in an .EXE file is NOT very secure. Since it's so difficult to update the .EXE you're generally not going to change many bytes in the file. Since that is the case a quick comparision of the .EXE before and after the password change with FC.EXE will flag *EVERY BYTE* you changed. Yeah, *THAT'LL* take me all of ... ten seconds to crack! A couple minutes with a hex editor and I'll set the password to whatever you want. Knowing where the password is located and changing to some specific, known passwords will quickly reveal any "substitution cipher" you use to "hide" the password.

M

PS  Same comment applies to "hiding" the password in a .DLL/.OCX or some other component. Better to hide the password in a *BIG* transactional database where 17MB of it is changed daily. That way the password change won't stand out like a sore thumb!

M

the only idea that come to my mind is hide your exe in a self extracting exe and
password protecting the zipped file. theres a lot of compression controls available in shareware right now

Oke, first of all it is possible to write in the exe while loaded but only under NT and only in the resources.
And the resources is exactly the place where you don't want to store it. Way to easy to crack.
If look at professional tools like c-dille, you will see that they encrypt the code with the password from within the code. Very complicated but very good. The trick how to do that is using CreateProcess and WriteProcess. Forgot that in VB, impossible.
Just storing. Well possible, mark2150 described a rather good technique. One tip to enhance it. Encode necessary information in there. Some constants that you need to run your application well. This way they can remove the password but then your code won't run anymore. In C++ I always used jump tables. This cannot be done in VB.
BTW: These kinds of protection seldom pays off. A real hacker will conquer all and your paying users have the problems.
Don't overestimate the need for your program. Somebody must really need it to hack it.
We have multiple over 100.000 copies sold business applications, all rather expensive. As far as I know, there is no hack for our applications and I know one registration number on the internet.
Just change your registration codes every version. That makes distributing them must harder.

I guess I can use this.  I could use the password to encrypt a key hidden in the program code.  Then store that encrypted key into the registry in a couple of different places.  Then when the user logs into the program it will read in both values from the registry.  If one is missing, they do not match, or the password being used does not decrypt it to the original key; then access would be denied.  I would have to determine what to do if both are missing?

That's a good idea.

My idea was to make sure the user would have to call you everytime he/she wanted to run a new copy of that software.

If both are missing, just format it's hard drive!... just kiddin'!

>>My idea was to make sure the user would have to call you
>>everytime he/she wanted to run a new copy of that software.

An old question, but it's always useful.

That's what I've got after working several months to get a "machine's fingerprint" which uniquely identifies every machine (unfortunately, I have to read certain system resources under DOS mode to obtain non-protected access).

For reinstallation, when users changes some portion of hardware, user must call me to do that. Without my intervention, he can not make the program to run on that "unknown" machine.

That's the problem using some hardware based information.
Also, if the user re-installs windows... bye-bye registry!
but that's his(her) problem.

The programmer can also sell another license :-)