because these make it much easier to reverse programs. The same problem
holds true for .NET executables as well: no matter how well an assembly
might be obfuscated, it is still going to have highly informative calls to the
Systemnamespace that can reveal a lot about the code being examined.
The solution is to obfuscate the .NET class library and distribute the obfus-
cated version along with the obfuscated program. This way, when a System
object is referenced, the names are all mangled, and it becomes quite difficult
to determine the actual name of the system call.
One approach that can sometimes reveal such system classes even after they
are renamed uses a hierarchical call graph view that shows how the various
methods interact. Because the Systemclass contains a large amount of code
that is essentially isolated from the main program (it never makes calls into the
main program, for instance), it becomes fairly easy to identify system branches
and at least know that a certain class is part of the Systemnamespace. There
are several tools that can produce call graphs for .NET assemblies, including
IDA Pro (which includes full IL disassembly support, by the way).Remotesoft Protector
The Remotesoft Protector product is another obfuscation product that takes a
somewhat different approach to prevent reverse engineering of .NET assem-
blies. Protector has two modes of operation. There is a platform-dependent
mode where the IL code is actually precompiled into native IA-32 code, which
completely eliminates the IL code from the distributable assembly. This offers
a significant security advantage because as we know, reversing native IA-32
code is far more difficult than reversing IL code. The downside of this
approach is that the assembly becomes platform-dependent and can only run
on IA-32 systems.
Protector also supports a platform-independent mode that encrypts the IL
code inside the executable instead of entirely eliminating it. In this mode the
Protector encrypts IL instructions and hides them inside the executable. This is
very similar to several packers and DRM products available for native pro-
grams (see Part III). The end result of this transformation is that it is not possi-
ble to directly load assemblies protected with this product into any .NET
disassembler or decompiler. That’s because the assembly’s IL code is not read-
ily available and is encrypted inside the assembly.
In the following two sections, I will discuss these two different protection
techniques employed by Protector and try and evaluate the level of security
they provide.452 Chapter 12