Hard code passwords compiled into program

1

I have several hardcoded passwords and other “secret” information that I need to be kept as hard coded into the program. How are others compiling this into their program to reduce just hex editing the EXE and figuring out some passwords?

1 Like
2

Can’t prove this is necessarily any better (your potential attacker always has the option of disassembling the binary), but to stop the most obvious method of looking in the binary file for obvious strings the way I’ve seen it done before is to build the password at runtime.

So instead of
password = ‘12345’
you do
password = ‘1’ & ‘2’ & ‘3’ …
or
password = chr(49) & chr(50) …

1 Like
3

Realizing that someone who’s determined enough to attach a debugger can find things…

I’ve taken a couple of approaches.

  1. Having a routine that XORs two hard-coded strings together and uses the result as a password.
  2. Combining pieces on the fly, such as:
LOC:Password  string(30)
LOC:STRING1 string ('<120,125>GPFat%s1.}}Other error'
code
LOC:Password = '9' & sub(LOC:string1,7,len(LOC:String1)-6) & '  ' & (4*13)
2 Likes
4

Simple ways:

  • use a very long string containing parts of real passwords
  • use unusual passwords consisting of non-printable characters like ‘<01,0AFh>3<1Dh>{99}’
  • encrypt actual passwords with a key string building at run time, for example, as bytes from the PE header or located at entry of some procedure.
3 Likes
5

I store “secret” information … encoded with a simple encoder.

I use password generating procedure(s) using the date as part of the algorithm (hence it changes daily), this has turned out to be better than I originally thought because I can give the customer temporary access when he forgets his own password (very convenient).

1 Like
6

As noted put it in a longer string of random characters like a strong password generator: G7gFEzLyTXUSyuFr3pC9Rf3CJnMYBuFLnsJq2uTbCbVtfumD

Then you could use something like Jeff’s Amble Scray

And / or use this to compress and create a hex string that would not be obvious.

2 Likes
7

We must still be cognizant of the fact that if you are decoding something into memory, all of the clever little dances that we do are just clever little dances that we do while cleverer people read our stuff

3 Likes
8

Place a breakpoint in the debugger on Cla$FILE_OPEN and all files’ passwords are yours…

4 Likes
9

cleverer people read our stuff

Armadillo debugger-detector/blocker for the win!

10

She said, confidently :slight_smile:

1 Like
11

GitHub can search Repositories for specific kinds of secrets

Edit: Fixed link, thanks

12

@CarlBarnes your link is broken.

13
1 Like
14

If net access is an option, short term certs like a 1 day cert can help expire things.

MS SBS and other software would fail during installation if the system date time was too far in the future due to the certs.

Making an app download pertinent dlls to run in memory at runtime can also help.

But nothing is perfect, time, knowledge and resources are the enemy which probably explains why windows is so bloated!

1 Like
15

Saw the below link and thought of this post. Haven’t tried it myself but the link is here if someone fancies trying it out.

Change a message into a password!

1 Like
16

Both are very similiar. To hide the fixed password in the code I used different lines like this;

.
password[4]=‘4’
.
(some other codes)
.
password[2]=‘2’
.
(some other codes)
.
password[1]=‘1’
.
(some other codes)
.
password[5]=‘5’
.
(some other codes)
.
password[4]=‘4’

1 Like
17

I have moved away from hard coded passwords within the exe.

I am using two components, one stored in the user’s profile, the other stored within the user’s registry settings. The two components combined form the password.

I am using industry standard cryptography algorithms to combine the two components.

18

yeah, i used to do that in days gone by.

I have dozens of pass codes, api keys, secrets etc…

I may just create an encrypted TPS file to old everything as 1 large encrypted JSON string that is loaded at run time.

I wish there was compiler directive to encrypt/encode as it is being compiled to hide sensitive information in the EXE/DDL/LIB

MyEquatePassword EQUATE(‘somesecretpassword’),ENCRYPT

That would encrypt as compile time and unencrypt at run time.

We are not too concerned about the actual app running being hacked, just the image on disk.

19

You could encode Base 64 or encode Base 85 so its not plain text.

Original: Secr3t Pa$w0rd
Base 64:  U2VjcjN0IFBhJHcwcmQ=
Base 85:  ;e9HZ1NXa9@3g%NEb#

Then take some steps so that it is not obvious Base 64 with just your password than can easily be decoded. Note that Base 64 takes 3 Bytes and encodes as 4 characters [A-Za-z0-9+\] with “=” for padding. A few thoughts…

  1. Make the Length a multiple of 3 so no obvious trailing “=” padding in Base 64.
  2. Mix the secret in a longer junk string you know to ignore
  3. Mix in parts in a longer junk string so all the bytes are not together, or reverse, etc
  4. Make the leading junk length Not a multiple of 4 so it will not decode right

E.g. the below the Password is mixed in with other Base 64. It starts with Junk that is 9 bytes that will cause it not to decode. The 14 byte password padded with ‘X’ so no ‘=’ on end

MySecrets GROUP,PRE(Secret)
Junk_9   STRING('N2dGRXpMe')  !9 bytes incomplete encode of '7gFEzLyTXUSyu'
Password STRING('U2VjcjN0IFBhJHcwcmRY')   !Base 64: `Secr3t Pa$w0rd' & 'X'
Junk_12  STRING('Rkxuc0pxMnVUYkNiVnRmdW1E')   !Encode Junk: FLnsJq2uTbCbVtfumD
                 END

Only you know to Decode MySecrets.Password and Cutoff the ending ‘X’.

Trying to decode the entire MySecrets N2dGRXpMeU2VjcjN0IFBhJHcwcmRYRkxuc0pxMnVUYkNiVnRmdW1E
will return 7gFEzLy … then high/low ASCII that not your secret.

It would be simple to code your own Base 64 function that changes the translation map [A-Za-z0-9+\] which would make it harder to crack. But then you cannot use an online Encoder / Decoder. I might pass in a Number that is used to rotate the Map e.g. (1) moves the ‘A’ in [1] to [64].

1 Like