question about security (decompiling msil, native code)

  • Thread starter Thread starter Richard Gjerde
  • Start date Start date
R

Richard Gjerde

We have a component in .net which contains encryption and decryption
algorithms. (We cannot use standard ones because these are going to be the
same as already existing algorithms in another application.) Of course,
these algorithms are pretty worthless if it is possible to simply decompile
the msil-code and see them directly. Therefore, we are thinking about using
some tool (ngen?) to generate native code from this component. In that
connection I have a couple of questions which I hope are not too ignorant (I
am not an expert on the framework!):

1. I guess one still needs the msil-code when deploying to generate native
code. Is it possible to just remove this after native compilation?
2. Must native compilation be done for a whole assembly, or is it possible
to make native code from just certain modules or even methods? (Maybe this
can specified by attributes?)
3. Does native compilation present any specific problems when deploying?
 
Richard Gjerde said:
We have a component in .net which contains encryption and decryption
algorithms. (We cannot use standard ones because these are going to be the
same as already existing algorithms in another application.) Of course,
these algorithms are pretty worthless if it is possible to simply decompile
the msil-code and see them directly.
Click to expand...

Ín that case they're worthless.

Any encryption algorithm which requires the algorithm itself (rather
than a key) to be secret is worthless, because anything which the
computer runs can be run by hand as well. It's slightly harder to
decompile native code, but it's still doable.
 
Thanks, Jon.
What you say makes sense. But I am a bit confused when it comes to the
key. Because where do you get the key from? I guess it can't be in the code
since then you could get it from decompilation. But if not it has to be
passed
to the code in some way (this is a webservice) and then we need to encrypt
the key... Seems like going in circles, but I have probably missed
something?

Richard Gjerde said:
We have a component in .net which contains encryption and decryption
algorithms. (We cannot use standard ones because these are going to be the
same as already existing algorithms in another application.) Of course,
these algorithms are pretty worthless if it is possible to simply decompile
the msil-code and see them directly.
Click to expand...

Ín that case they're worthless.

Any encryption algorithm which requires the algorithm itself (rather
than a key) to be secret is worthless, because anything which the
computer runs can be run by hand as well. It's slightly harder to
decompile native code, but it's still doable.
 
Richard Gjerde said:
What you say makes sense. But I am a bit confused when it comes to
the key. Because where do you get the key from? I guess it can't be
in the code since then you could get it from decompilation. But if
not it has to be passed to the code in some way (this is a
webservice) and then we need to encrypt the key... Seems like going
in circles, but I have probably missed something?
Click to expand...

Nope. You can't have secrets buried in code, basically. Where you get
the key from depends on the application - but sooner or later, if
you've got as much information as the computer has at runtime when it
decrypts the data, you've got enough information to decrypt the data
yourself.
 
one potent solution is to use the registry. protect the registry keys by
restriction thru the windows ACL. the idea is that even if the malfeasant
could gain access to the computer, the ACL would restrict the access. if
that person has access to the registry, all bets are off - kinda like
storing money in a vault and giving the key to slim shadey
 
Back
Top