make sure that code is properly obfuscated. Otherwise, it will be exceedingly
easy to recover an accurate approximation of your program’s source code sim-
ply by decrypting the assembly.
Conclusion
.NET code is vulnerable to reverse engineering, certainly more so than native
IA-32 code or native code for most other processor architectures. The combi-
nation of metadata and highly detailed IL code makes it possible to decompile
IL methods into remarkably readable high-level language code. Obfuscators
aim at reducing this vulnerability by a number of techniques, but they have a
limited effect that will only slow down determined reversers.
There are two potential strategies for creating more powerful obfuscators
that will have a serious impact on the vulnerability of .NET executables. One
is to enhance the encryption concept used by Remotesoft Protector and actu-
ally use separate keys for different areas in the program. The decryption
should be done by programmatically generated IL code that is never the same
in two obfuscated programs (to prevent automated unpacking), and should
use keys that come from a variety of places (regions of metadata, constants
within the code, parameters passed to methods, and so on).
Another approach is to invest in more advanced obfuscating transforma-
tions such as the ones discussed in Chapter 10. These are transformations that
significantly alter the structure of the code so as to make comprehension con-
siderably more difficult. Such transformations might not be enough to prevent
decompilation, but the objective is to dramatically reduce the readability of the
decompiled output, to the point where the decompiled output is no longer
useful to reversers. Version 3.0 of PreEmptive Solution’s DotFuscator product
(not yet released at the time of writing) appears to take this approach, and I
would expect other developers of obfuscation tools to follow suit.
Reversing .NET 455