473,322 Members | 1,614 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

protecting .NET assemblies from hackers

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
irrelevant.

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
something like:

//push the decrypted string onto the stack
ldstr "the decrypted password string returned by the 'secret' decryption
function"

//call the visual basic "messagebox" method to show him the decrypted string
call [Microsoft.VisualBasic]Microsoft.VisualBasic.Interaction::MsgBox(object)

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.
-Nate A
Jul 21 '05 #1
6 1729
interesting.. but why would you store an administrator password again in your
config file? maybe you can create a new database user and give that user only
the access necessary. permissions on stored procedures most probably.. then
do not allow that user to do anything else..

there are other levels of security you can implement. do not put all the
burden in your application. if it is a web application, maybe you can use
other methods of security like domain authentication or using ssl. or
limiting access to certain ip addresses.
"Nate A" wrote:
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
irrelevant.

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
something like:

//push the decrypted string onto the stack
ldstr "the decrypted password string returned by the 'secret' decryption
function"

//call the visual basic "messagebox" method to show him the decrypted string
call [Microsoft.VisualBasic]Microsoft.VisualBasic.Interaction::MsgBox(object)

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.
-Nate A

Jul 21 '05 #2
I actually have to store the database password somewhere outside the assembly
because it can be changed by the user. It is encrypted where it is stored
however. But even if I were to not allow the user to change the password and
just have the pasword somewhere in code like

Dim pass as string = "mypass"

This could be easily read by opening the .exe in a hex editor or
dissasembling it. So one thing to do here is use a code obfuscator to encrypt
this string in code. But obfuscator encryption is easily breakable since the
decryption method is included in the code by definition. That's why I need
some kind of protection that can actually detect if the .exe file has been
modified, e.g. by computing it's checksum and comparing it to what it's
supposed to be.

The problem with having different database accounts that restrict access to
operations on certain tables is that my application is to be used by people
who have varying degrees of access (managed by the application). This access
will range from very limited--users who only have access to a few forms that,
in turn, modify data on the database--to full acess--access to forms that can
edit data on basically every table in the database. So with this in mind, the
"master" db password would still have to be stored somewhere on the
application, which doesn't improve the situation.

"Allan" wrote:
interesting.. but why would you store an administrator password again in your
config file? maybe you can create a new database user and give that user only
the access necessary. permissions on stored procedures most probably.. then
do not allow that user to do anything else..

there are other levels of security you can implement. do not put all the
burden in your application. if it is a web application, maybe you can use
other methods of security like domain authentication or using ssl. or
limiting access to certain ip addresses.
"Nate A" wrote:
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
irrelevant.

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
something like:

//push the decrypted string onto the stack
ldstr "the decrypted password string returned by the 'secret' decryption
function"

//call the visual basic "messagebox" method to show him the decrypted string
call [Microsoft.VisualBasic]Microsoft.VisualBasic.Interaction::MsgBox(object)

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.
-Nate A

Jul 21 '05 #3
I guess I pretty much figured out the solution to my own problem with some
sifting though the .NET framework help regarding assembly signing. It turns
out, luckily, that signing an assembly with a key pair generated by sn.exe
will ensure that if a hacker modifies your .exe assembly, it will not load
becuase the cryptographic hash will not be correct. I'm sure most of you were
already aware of that so I apologize for the post ; )

"Nate A" wrote:
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
irrelevant.

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
something like:

//push the decrypted string onto the stack
ldstr "the decrypted password string returned by the 'secret' decryption
function"

//call the visual basic "messagebox" method to show him the decrypted string
call [Microsoft.VisualBasic]Microsoft.VisualBasic.Interaction::MsgBox(object)

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.
-Nate A

Jul 21 '05 #4
if you do not want to store any significant info on your application, you can
try exposing a web service or a remote class..

"Nate A" wrote:
I actually have to store the database password somewhere outside the assembly
because it can be changed by the user. It is encrypted where it is stored
however. But even if I were to not allow the user to change the password and
just have the pasword somewhere in code like

Dim pass as string = "mypass"

This could be easily read by opening the .exe in a hex editor or
dissasembling it. So one thing to do here is use a code obfuscator to encrypt
this string in code. But obfuscator encryption is easily breakable since the
decryption method is included in the code by definition. That's why I need
some kind of protection that can actually detect if the .exe file has been
modified, e.g. by computing it's checksum and comparing it to what it's
supposed to be.

The problem with having different database accounts that restrict access to
operations on certain tables is that my application is to be used by people
who have varying degrees of access (managed by the application). This access
will range from very limited--users who only have access to a few forms that,
in turn, modify data on the database--to full acess--access to forms that can
edit data on basically every table in the database. So with this in mind, the
"master" db password would still have to be stored somewhere on the
application, which doesn't improve the situation.

"Allan" wrote:
interesting.. but why would you store an administrator password again in your
config file? maybe you can create a new database user and give that user only
the access necessary. permissions on stored procedures most probably.. then
do not allow that user to do anything else..

there are other levels of security you can implement. do not put all the
burden in your application. if it is a web application, maybe you can use
other methods of security like domain authentication or using ssl. or
limiting access to certain ip addresses.
"Nate A" wrote:
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
irrelevant.

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
something like:

//push the decrypted string onto the stack
ldstr "the decrypted password string returned by the 'secret' decryption
function"

//call the visual basic "messagebox" method to show him the decrypted string
call [Microsoft.VisualBasic]Microsoft.VisualBasic.Interaction::MsgBox(object)

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.
-Nate A

Jul 21 '05 #5
of course, but that only exposes problems with .net updater. unless you are
not using that..

"Nate A" wrote:
I guess I pretty much figured out the solution to my own problem with some
sifting though the .NET framework help regarding assembly signing. It turns
out, luckily, that signing an assembly with a key pair generated by sn.exe
will ensure that if a hacker modifies your .exe assembly, it will not load
becuase the cryptographic hash will not be correct. I'm sure most of you were
already aware of that so I apologize for the post ; )

"Nate A" wrote:
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
irrelevant.

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
something like:

//push the decrypted string onto the stack
ldstr "the decrypted password string returned by the 'secret' decryption
function"

//call the visual basic "messagebox" method to show him the decrypted string
call [Microsoft.VisualBasic]Microsoft.VisualBasic.Interaction::MsgBox(object)

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.
-Nate A

Jul 21 '05 #6
Yeah, as far as I can see in the future, updates of the program could just be
done by completely overwriting the application, since distribution size is
not really an issue becuase it will be distributed over a local network and
not over the internet.

Thanks for your suggestions.

"Allan" wrote:
of course, but that only exposes problems with .net updater. unless you are
not using that..

"Nate A" wrote:
I guess I pretty much figured out the solution to my own problem with some
sifting though the .NET framework help regarding assembly signing. It turns
out, luckily, that signing an assembly with a key pair generated by sn.exe
will ensure that if a hacker modifies your .exe assembly, it will not load
becuase the cryptographic hash will not be correct. I'm sure most of you were
already aware of that so I apologize for the post ; )

"Nate A" wrote:
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
irrelevant.

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
something like:

//push the decrypted string onto the stack
ldstr "the decrypted password string returned by the 'secret' decryption
function"

//call the visual basic "messagebox" method to show him the decrypted string
call [Microsoft.VisualBasic]Microsoft.VisualBasic.Interaction::MsgBox(object)

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.
-Nate A

Jul 21 '05 #7

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

5
by: Sky Fly | last post by:
Hi, I know that when an .NET exe is run, the CLR loads the exe (along with dependent assemblies), compiles them to native code then runs the code. Assuming the assemblies are loaded from a...
4
by: Michael | last post by:
Hi, When an application is shipped is there a way of un-authroized people from using the assemblies in their own applications? Regards, Michael
4
by: Michael | last post by:
Hi, I have written an application in C# and when I distribute it I would like to prevent un-authorised people from using these assemblies in their own applications. Is it possible to do this?...
10
by: Edlueze | last post by:
I am developing some Data Access Pages (DAP) using Microsoft Access 2003 on Microsoft Windows XP. When I try to open these pages (located on my C: drive), the display of the data access page is...
5
by: Chua Wen Ching | last post by:
Hi all, Basically right now, i am interested to learn how to break strong names in ..net assemblies. I had researched a lot and found a blog that mention how to hack strong name assemblies....
7
by: Bobby C. | last post by:
My company is in the process of getting ready (well actually QTR 2 2004) to roll out a rewritten version of a vertical market application for the municipal market (small and medium sized cities). ...
21
by: solomon_13000 | last post by:
I am using ms access database and asp 3.0 as my front end. In my database there is a table called account and a field called password. How do I protect the password stored in the database.
22
by: flit | last post by:
Hello All, I have a hard question, every time I look for this answer its get out from the technical domain and goes on in the moral/social domain. First, I live in third world with bad gov., bad...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.