Assembly security

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

IS the DLL's or assemblies written in c# or vb.net are secure ?
There are tools in the market which show the source codes of DLL
using the disassemblers,

any workaround or solutions to protect the .net assemblies ?
 
Jaisabari said:
IS the DLL's or assemblies written in c# or vb.net are secure ?
There are tools in the market which show the source codes of DLL
using the disassemblers,

Yup.

IL is quite easy to understand, and it's easy to convert it to high
level languages like C# and VB.NET. There are obfuscators available, but
they just make the process a little harder, anyone who is determined to
extract your secret algorithm will be able to do it. (And it is the
*determined* crackers you should be worried about, not the casual
snooper who are targeted by the obsfuscation vendors.)

This might be seen as a weakness of IL, but in fact it is a secure
feature of IL. The fact that it is possible for a machine to analyse the
IL and determine what it will do means that the JIT compiler can verify
that the IL will not do something nasty. This protects you from
executing .NET malware downloaded from the internet. The only downside,
as you note, is that you cannot make your algorithms secret.
any workaround or solutions to protect the .net assemblies ?

The only way to prevent someone from getting access to the IL in your
assembly (and using something like Reflector to get the C# or VB.NET
source) is to host your code on your own machine as a web service or
through .NET remoting.

Richard
 
Thanks Richard,for the detailed and clear information.

But in our case, our dll will be shipped along with the CD and will get
installed in the client system.

any way we will re-work on the architecture part again, to give a best to
our company.
 
Prakash said:

Hmmm, there was an article on the desaware site years ago about
obfuscation (available for free), and it gave C++ code to 'obfuscate'
code. All it did was changed the names of private members stored in the
metadata string table. This was a very simple technique and next to
useless in preventing a cracker. More concerning was that the C++
'coder' used the COM metadata interfaces but clearly did not understand
COM because the 'coder' did not release a single interface reference
count. Sloppy code like that never inspires confidence.

Richard
 
Back
Top