Why Does Not Eazfuscator.NET Provide MSIL Encryption?

Article ID: KB100028

Eazfuscator.NET has a carefully crafted set of features. One feature it does not provide is MSIL encryption. This was a thought-out decision and it was made for a good reason. Let's see why.

What MSIL encryption basically does during obfuscation is this:

  1. It takes the original instructions of a method
  2. Encrypts them
  3. Then stores the resulting encrypted instructions at embedded resource of an obfuscated assembly
  4. The original method body gets swapped with a call to decryptor code which does the reverse job during runtime

When obfuscated assembly is run, the encrypted instuctions are decyphered into memory and the method runs in a very same way as the original one.

But what's wrong with MSIL encryption?

First of all, it is a piece-of-cake target for an attacker:
  • Decyphered method bodies are prone to memory dumping
  • The key for decyphering is stored at the same assembly, giving attacker a perfect hint on how to decrypt the bodies without running the assembly at all

The second, and more important implication of MSIL encryption is that it kills the performance.

MSIL encrypted methods can not be compiled ahead of time, this means that NGEN is useless on such methods. Other performance technologies such as Windows Prefetch become helpless too when MSIL encryption takes place.

The outcome of MSIL encryption is a not-so-good protection in expense of the precious speed.

If we draw an imaginary surface with four quadrants then we see that bad protection and bad speed are the worst possible combination. Clearly not that feature that should be implemented in a good obfuscator.

Decision surface for MSIL encryption