Why Does Not Eazfuscator.NET Provide IL Encryption?
Article ID: KB100028Published: September 19, 2013
Synopsis​
Eazfuscator.NET has a carefully crafted set of features. One feature it does not provide is IL encryption. This was a thought-out decision and it was made for a good reason.
What IL encryption basically does during obfuscation is this:
- It takes the original instructions of a method
- Encrypts them
- Then stores the resulting encrypted instructions at embedded resource of an obfuscated assembly
- The original method body gets swapped with a call to decryption code which does the reverse job during run time
When obfuscated assembly is run, the encrypted instructions are deciphered into memory and the method runs in a very same way as the original one.
Analysis​
Let's analyze pros and cons of IL encryption.
Pros​
The positive aspects of IL encryption are:
- IL encryption provides a code protection barrier
Cons​
Now to the negatives. First of all, IL encryption is an easy target for an attacker:
- Deciphered methods are prone to memory dumping
- The key for deciphering is stored at the same assembly, giving the attacker a perfect hint on how to decrypt the methods without running the assembly at all
The second, and more important implication of IL encryption is that it negatively impacts the code performance:
- IL encrypted methods cannot be compiled ahead of time, meaning that techniques like native image generation and ready-to-run compilation do not work on such methods
- IL encryption negatively impacts other performance technologies such as Windows Prefetch
Conclusion​
Considering observations above, we can conclude that IL encryption provides a not-so-good protection at the expense of precious speed.
If we draw an imaginary surface with four quadrants, we can see that a weak protection and a bad performance is the worst possible combination:
According to the chart, IL encryption is clearly not that feature that should be implemented in a good obfuscator.