protecting .NET assemblies against hackers
From: Nate A (NateA_at_discussions.microsoft.com)
Date: Tue, 26 Oct 2004 10:47:03 -0700
I am at the beginning stages of writing a massive database-connected business
management application using the .NET framework and am becoming worried about
the security of the application upon completion.
I have recently become aware of the ease at which a .NET assembly can be
disassembled into its easily readable, underlying CLI code. I can see that it
would not be difficult for a malicious user to disassemble, modify, and then
recompile in CLI byte code (using the included VS.NET tools). This concerns
me deeply since I can see how easy it would be to obtain critical information
within the code.
I looked into code obfuscation tools such as DotFuscator. As far as I can
tell, these tools can only make your code harder to understand by renaming
CLI metadata to more or less random names, and optionally encrypting internal
strings (such as "salts" to use in encryption/decryption algorithms or
passwords used to access remote data, like a database server). Apparently
they can also slightly modify the way an algorithm operates to hide the
details of the algorithm while maintaining the true functionality of the
algorithm. However, algorithm hiding is not my big concern so that is
This, however, fails to put my mind at ease since much can be understood
about the code after disassembling an obfuscated assembly.
For example, if one's application has a class containing methods for
encryption and decryption of data using the .NET Framework's "Cryptography"
namespace, a hacker needs only to look for classes that "Imports" the
Cryptography namespace, or that make calls to members of that namespace in
order to realize "hey, I bet this class contains the functions used for this
applications encryption." The class may be named "a", with public members
"a", "b" and "c" by the obfuscator, but the hacker still knows that members
"a", "b" and "c" probably do encryption and decryption.
So now let me get to a particular concern of mine dealing with my
application and see if anyone has any suggestions.
My application connects to a remote database, so let’s say a hacker wants to
cop the database password from my app. He knows there must be a database
password stored somewhere in the application code, registry, or an external
settings file. WHERE it is stored is more or less irrelevant since it won’t
be hard to find it either way. I happen to store it in a XML settings file.
Of course the password is encrypted in the file, but once the hacker finds
the encrypted password string, he knows that at some point in the
application, the string will be decrypted when it needs to be sent to the
database server to log onto the database.
So once he finds the CLI code in the assembly where the encrypted password
is fetched from the settings file, pushed onto the stack, and then a call is
made to a method in the suspected encryption/decryption class, he has now
figured out the method that decrypts the password and can use this to wreak
havoc on my app.
It seems to me that all the programmer has to do at this point to get the
decrypted password is add a little CLI code after the point where the
password is decrypted. I don't know much of the specifics of the CLI
language, but after inspection of my disassembled code, the hacker could add
//push the decrypted string onto the stack
ldstr "the decrypted password string returned by the 'secret' decryption
//call the visual basic "messagebox" method to show him the decrypted string
Boom, there it is, the database password shown to the hacker in a MsgBox! He
now has free reign to log into my database and delete records or replace all
credit card numbers with "suck it!" if he wants (or whatever it is these guys
like to do BESIDES getting laid!)
So the only thing I can see that would almost guarantee that a hacker could
not do this would be by not allowing him to modify the code, like having the
program detect if it was modified before it was run. I'm not aware of any way
to do this that is built into the .NET Framework, but if this exists, maybe
someone can let me know.
I also considered the possibility of calculating the .exe file's checksum,
sending it along with the application in some form or another, and then
having the application calculate it's own checksum each time it's run, and
check it against the stored value and throw an error if they do not match. (I
was hoping that the .NET framework had this kind of security built in, but I
haven't come across it yet.) Has anyone ever tried this? Or can anyone think
of some pitfalls of this method?
So anyway, I hope this post will catch the eye of someone who knows more
about these kinds of things than me and maybe they can point me in the right
direction on how to secure my code considering these issues mentioned above.
Thanks for taking the time to read this.