Click to See Complete Forum and Search --> : exe file security
ultim8
November 22nd, 2002, 10:31 AM
One of my users has just come to me with the sqlserver name, username and password, along with the network paths that one of my apps uses.
He opened the exe file in Notepad, and EVERY SINGLE STRING from my app is there for all to see.
I can find no official documentation about this.
I have had to withdraw the application while I rewrite it - but as I do not know the details about this security issue, I do not know what is safe.
Is this a known issue?
If so, what is/is not safe?
Are there any compile solutions?
Quick replies on this one would be appreciated!!
Steve.
RobAnd
November 22nd, 2002, 06:30 PM
Of course this is the case. You most likely hard coded the strings into your application. The compiler will obviously store them with the code for all to see.
If it is an absolute requirement that the values be hardcoded into the application, I suggest encrypting them then decrypting them during run-time.
- Robert
DOSida
November 23rd, 2002, 03:49 PM
There is a chance my suggestion might not work in the VB.NET
but give it a spin...
if you want to hardcode a string... that you wont see if you
open the exe with wordpad or notepad...
try converting the string as chr statements...
for example...
you have "www.yahoo.com" that you want to hardcode right? :)
Now this will become
d=chr$(119)+chr$(119)+chr$(119)+chr$(46)+chr$(121)+chr$(97)+chr$(104)+chr$(111)+chr$(111)+chr$(46)+chr$(99)+chr$(111)+chr$(109)
d will now contain "www.yahoo.com" but the string will not
show up in the compiled exe program.
What CHR$ does is create an ASCII Character out of its
respective number (0 - 255, 256 characters in total)
That will in NO WAY BEAT reverse-engineering or cracking methods
for binary files... but it will certainly make it a bit more difficult
for crackers to understand how your program works...
Hope I helped...
Give it a spin with this test string and tell me if it works for you.
Regards
DOSida
PS: ASCII Codes can be found at
http://www.asciitable.com/
ultim8
November 25th, 2002, 06:26 AM
Thanks DOSida,
its a bit of a pain, but that is the best quick solution that anyone has come up with so far!!
RobAnd,
hard-coding an encrypted string to be decrypted at runtime would work, to make it simple to maintain would have to build a little prgram first to generate the encrypted/decryted strings.
I think I go down this route for future apps.
Thanks both of you!
More help and more sense than other forums!!
Steve.
ultim8
November 25th, 2002, 06:58 AM
DOSida,
just tested this.
Unfortunately, when dotnet compiles, it interprets the ascii values and generates the string (rather that doing so at runtime) - so we have the same problem: The exe contains the strings.
Thinking about it, obvious really - functions are interpreted at compilation, not at runtime.
So, coding a function that decrypts a string would suffer the same problem
Anybody think of a way round this??
Cheers.
Steve.
DOSida
November 25th, 2002, 06:44 PM
Well the only other thing that comes to mind is to create a
block of characters in a file...
read them in memory and then just go and read a specific
character from a specific line...
For example lets say you have:
as92q387as01dfo
d-dps-0flsd9ow23
.a98q1ckkioq912
as9yho12020sdd9
and you want to read www.yahoo.com from it, right?
now you store this in a file and you go and check
a character at each time thus creating the string
that you want at runtime.
what my only concern is that I dont really know if
dotnet actually stores the expected contects of a
variable in the actual compiled program...
meaning if you chose different characters from the
block in our example... would dotnet store it in the
exe anyway?
Give it a spin and let me know what you come up with
Hope I helped
All the luck to you my friend
Regards
DOSida
ultim8
November 26th, 2002, 11:10 AM
DOSida,
I have been unable to compile an exe in such a way that functions are evaluated at runtime, rather than during compilation - so I don't think this method would work.
What I have done instead is to create an install program which populates a registry key (which could be encrypted).
My applications now read the application-specific server/username/password from the registry.
Couple of lines of code:
(install program)
'creates/writes uid, pwd, server to 'Appname' Registry Key
SaveSetting("AppName", "KeyHeader", "Keyid1", "uid")
SaveSetting("AppName", "KeyHeader", "Keyid2", "pwd")
SaveSetting("AppName", "KeyHeader", "Keyid3", "server")
SaveSetting("AppName", "KeyHeader", "Keyid4", "DB")
(Main App)
'retrieves registry keys at runtime
strcon = "driver={SQL Server};server=" & GetSetting("AppName", "KeyHeader", "Keyid3") & ";"
strcon = strcon & "uid=" & GetSetting("AppName", "KeyHeader", "Keyid1") & ";"
strcon = strcon & "pwd=" & GetSetting("AppName", "KeyHeader", "Keyid2") & ";"
strcon = strcon & "database=" & GetSetting("AppName", "KeyHeader", "Keyid4")
con.ConnectionString = strcon
(delete key and contents)
DeleteSetting("AppName")
Thanks for all your help and suggestions.
Steve.
Innocent
November 26th, 2002, 08:17 PM
You could push letters in a function and pass the number of letters to push (i.e. if push = 3 then A = D, B = E) and so on. That way with push = 3 "test" would be "whvw" in application.
It's still a very simple code to crack - even if you use different push number for each text - or word, but in an application on a few hundred kb's, it's easy to miss - even for the best hackers...
NB! A function like this would be inefficient compared to other methods to save texts - and it's very difficult to internationalize texts.
ultim8
November 28th, 2002, 04:58 AM
I think that this would have the same result as functions that I have tried - in that when you compile the exe, the functions are evaluated, rather than at runtime.
eg: if in your code you have 'str$ = chr(65)',
your compiled exe would contain 'str$ = A'
same with any function :(
If anyone can come up with a way of changing the settings so that the compiled exe evaluates functions at runtime, I would appreciate it!
Cheers again
Steve.
Percent
December 2nd, 2002, 09:02 PM
Like UPX the source code is free so you can modify its encryption and compression key - When a exe is compressed most of the strings are no longer visible - and also any resource files other than your first icon and version information are not visible
neo_42748
December 12th, 2002, 10:39 AM
I have run into the same problem that you have. Here is what I did.
I actually changed my program to open a file from a network path. For example \\servername\filename.ini. Within that file I had all the information I needed for my program encrypted. So if they saw that path within my program and went to the path and opened the file all they saw was encrypted information.
All you have to do is when the program loads have if open the file and decrypt it and then use the information that way. If you need some encryption code just email at wwise@larue.k12.ky and I will be happy to send you some encryption code.
Matt
ibeevbee
January 6th, 2003, 12:04 PM
Just stumbled on this while looking for something else... I came across this problem sometime ago, simple solution...
Just use a function to XOR the string you want to protect, then hardcode in the XOR'ed version and XOR it back when needed (at runtime), something like this...
For i = 0 To EncryptThis.Length - 1
Encrypted = Encrypted & Chr(Asc(EncryptThis.Substring(i)) Xor i)
Next i
No readable text will be stored in the .exe file.
Prevents all casual snoopers from finding your passwords, you could even XOR plus the char position to increase the security a bit more if you want (will then prevent someone from XORing the whole file to discover the password).
Hope this helps anyone else who stumbles here!
codeguru.com
Copyright Internet.com Inc., All Rights Reserved.