muskad202
asked on
vc++ - storing strings securely in exe files
hi !!
in my prog, i have to perform encryption, for which i use a key. this key is stored in a const char variable. my app depends on this key being kept private. however, if i open the exe in a hex editor, and look around, the key is displayed in plain sight ...anyway to hide it ??
more general case - anyway to hide const char* in an exe, so that they don't appear in hex editors ?? one way i was thinking would be to assign char by char to the string.. don't know whether this would work though .. and besides, its too tedious to do for all the strings in a prog..
muskad202
in my prog, i have to perform encryption, for which i use a key. this key is stored in a const char variable. my app depends on this key being kept private. however, if i open the exe in a hex editor, and look around, the key is displayed in plain sight ...anyway to hide it ??
more general case - anyway to hide const char* in an exe, so that they don't appear in hex editors ?? one way i was thinking would be to assign char by char to the string.. don't know whether this would work though .. and besides, its too tedious to do for all the strings in a prog..
muskad202
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
And, what's the difference (except of storing the string in a resource)?
ASKER
jaime_olivares: one thing .. the ciphering process would require a key ... which would need to be stored in the exe itself for deciphering .. any way to hide tht too ??
muskad202
muskad202
That's why I suggested a 'simple' method. BTW, you have to be clear about one thing: When debugging your application, there will be the time when your key will reside in memory in a unencrypted, clear way. And right *then* it can be grabbed anyway...
>And, what's the difference (except of storing the string in a resource)?
The different is that you can reach the string easily with simple WinApi functions, don't have to search in the middle of an exe's executable portion. The cipher algorithm is not inside, just the decipher.
>the ciphering process would require a key ... which would need to be stored in the exe itself for deciphering .. any way to hide tht too ??
Yes, you can hide it in many ways, but at least all your strings will be totally unlegible. Even you can use a strong alg. like 3DES, IDEA or many others.
>That's why I suggested a 'simple' method. BTW, you have to be clear about one
> thing: When debugging your application, there will be the time when your key will
>reside in memory in a unencrypted, clear way. And right *then* it can be grabbed >anyway...
My method is more secure than this:
>As a simple protection measure, you could just byte-reverse the key and/or
> add/subtract a certain value from each byte.
There are very well-know algorithms that detect byte-reverse and xor'ed strings easily. It will be harder to find a key in memory, but remember that there is not perfect algorithm, just some better than others.
You have to consider also who is interested in crack your software, a hobbist cracker, a mid-ranged cryptoanalyst or a goverment heavy weight guru.
The different is that you can reach the string easily with simple WinApi functions, don't have to search in the middle of an exe's executable portion. The cipher algorithm is not inside, just the decipher.
>the ciphering process would require a key ... which would need to be stored in the exe itself for deciphering .. any way to hide tht too ??
Yes, you can hide it in many ways, but at least all your strings will be totally unlegible. Even you can use a strong alg. like 3DES, IDEA or many others.
>That's why I suggested a 'simple' method. BTW, you have to be clear about one
> thing: When debugging your application, there will be the time when your key will
>reside in memory in a unencrypted, clear way. And right *then* it can be grabbed >anyway...
My method is more secure than this:
>As a simple protection measure, you could just byte-reverse the key and/or
> add/subtract a certain value from each byte.
There are very well-know algorithms that detect byte-reverse and xor'ed strings easily. It will be harder to find a key in memory, but remember that there is not perfect algorithm, just some better than others.
You have to consider also who is interested in crack your software, a hobbist cracker, a mid-ranged cryptoanalyst or a goverment heavy weight guru.
ASKER
"jaime_olivares" : can u tell me any way to hide the key ??
thanks :)
muskad202
thanks :)
muskad202
You can store it at different variables declared at different times.
You can store in the resouce ciphered with another key.
You can make some math with key components
Any combinations of the above.
It is true that you will have the key in the memoty at some moment, every cipher software does, but you can store it in an unordered fashion to difficult cracking.
You can store in the resouce ciphered with another key.
You can make some math with key components
Any combinations of the above.
It is true that you will have the key in the memoty at some moment, every cipher software does, but you can store it in an unordered fashion to difficult cracking.
>>The different is that you can reach the string easily with simple WinApi functions, don't have to search in the middle
>>of an exe's executable portion
Um, what's so bad about
char* pszEncryptedKey = "...";
?
muskad202,
thanks for blissfully ignoring my statements and giving no response at all, maybe I can do that with your Qs in the future also.
>>of an exe's executable portion
Um, what's so bad about
char* pszEncryptedKey = "...";
?
muskad202,
thanks for blissfully ignoring my statements and giving no response at all, maybe I can do that with your Qs in the future also.
>Um, what's so bad about
>char* pszEncryptedKey = "...";
I will tell you the advantages. Assumming that you will store the string cyphered let's say:
char* pszEncryptedKey = "KFHOR5UGD8NVJHLEOFJGF0H4E
You have to cypher manually each sensitive string of your application. With my method you don't have to do that, just store the unciphered string in a resource and use the utility program I suggested to cypher every resource string, automatically, in batch.
Your internal decyphering string could detect if string is cyphered or not, and decipher as needed, so you can have a protected and an unprotected version of your exe.
If you decide to change a string (or many strings), it is simple just do it, and run the cyphering tool again. No pain.
>char* pszEncryptedKey = "...";
I will tell you the advantages. Assumming that you will store the string cyphered let's say:
char* pszEncryptedKey = "KFHOR5UGD8NVJHLEOFJGF0H4E
You have to cypher manually each sensitive string of your application. With my method you don't have to do that, just store the unciphered string in a resource and use the utility program I suggested to cypher every resource string, automatically, in batch.
Your internal decyphering string could detect if string is cyphered or not, and decipher as needed, so you can have a protected and an unprotected version of your exe.
If you decide to change a string (or many strings), it is simple just do it, and run the cyphering tool again. No pain.
Yup, you indeed have a point about the "manually" thing. But, generating a .rc file instead of a .c file does not make a big difference :o)
I think you have not understood me clear. I suggest to design a little utility to modify an .exe resource strings **after** compiling. It is a big differente if you try to search those strings inside the .exe's code.
Even you can translate strings and recipher to create international versions.
There are lots of advantages, exposing only a few.
Even you can translate strings and recipher to create international versions.
There are lots of advantages, exposing only a few.
Yes, if you change them after compiling this is *indeed* an advantage on Win32 systems.
No, there is no way. As a simple protection measure, you could just byte-reverse the key and/or add/subtract a certain value from each byte.