Obfuscation – and pesky strings

A friend of a friend asked

"When .NET code is compiled a program called Reflector can be used to decompile the binary file in to its original code. I understand there are tools called Obfuscators that will make the code harder to read, but it can still be decompiled and read in plain text. The problem with obfuscation is that any database username and passwords in the code are still readable as plain text. Is there anyway to stop this problem?"

This is a big old topic (the "do you really need to store the username and password in the code" is a good place to start) - but it also points out a common misconception about .NET code and obfuscation. Many folks assume that the free obfuscator we ship in the box 

  1. Represents all that obfuscators are able to do and
  2. There is no other approach than obfuscating

In reality

  1. Many companies create more powerful obfuscators than the one we ship in the box - which include features such as string encryption (all string or selected strings)
  2. Obfuscation is just one approach - you can also use techniques such as encrypting launchers and native code compilers.

A good place to start is the howtoguide from August 2005 which includes a great comparison table (As this is a few years old, do check the specifics of each tool at their site as things will have changed).

If anyone has a more recent comparison, please do share. Thanks.

Comments (1)

  1. Alastair says:

    I’ve used two other products your own (Microsoft’s) SLPS (http://www.microsoft.com/slps/ and Xheo’s) CodeVeil (http://www.xheo.com/products/codeveil/default.aspx). Xheo’s approach is much simpler in that it encrypts the entire assembly. One downside is that you have to run the assemblies under full trust as the stub used to decrypt is native code. There are also ways for a determined hacker to get around this type of protection. However, in most instances you are trying to foil the casual reflector user.

    SLPS’ approach is to identify what portions of the code you want to protect your IPR in. There is more of a performance vs. protection balance to be considered with this approach and personally, I believe that IPR is not just about protecting a few ‘clever’ routines, it can be about the entire approach to combining components together.

Skip to main content