为什么原生Win32难拆，.NET应用易拆？

Question

Why is the process of disassembling a native Win32 image (built in C/C++ for eg) miles more difficult than disassembling a .NET app?

What is the main reason? Because of what?

Answer 1

A .net assembly is built into Common Intermediate Language . It is not compiled until it is about to be executed, when the CLR compiles it to run on the appropriate system. The CIL has a lot of metadata so that it can be compiled onto different processor architectures and different operating systems (on Linux, using Mono). The classes and methods remain largely intact.

.net also allows for reflection, which requires metadata to be stored in the binaries.

C and C++ code is compiled to the selected processor architecture and system when it is compiled. An executable compiled for Windows will not work on Linux and vice versa. The output of the C or C++ compiler is assembly instructions. The functions in the source code might not exist as functions in the binary, but be optimized in some way. Compilers can also have quite agressive optimizers that will take logically structured code and make it look very different. The code will be more efficient (in time or space), but can make it more difficult to reverse.

Answer 2

Due to the implementation of .NET allowing for interoperability between languages such as C#,VB, and even C/C++ through the CLI and CLR this means extra metadata has to be put into the object files to correctly transmit Class and object properties. This makes it easier to disassemble since the binary objects still contain that information whereas C/C++ can throw that information away since it is not necessary (at least for the execution of the code, the information is still required at compile time of course).

This information is typically limited to class related fields and objects. Variables allocated on the stack will probably not have annotations in a release build since their information is not needed for interoperability.

Answer 3

One more reason - optimizations that most C++ compilers perform when producing final binaries are not performed on IL level for managed code.

As result something like iteration over container would look like couple inc / jnc assembly instructions for native code compared with function calls with meaningful names in IL. Resulting executed code may be the same (or at least close) as JIT compiler will inline some calls similar to native compiler, but the code one can look at is much more readable in CLR land.

Answer 4

People have mentioned some of the reasons; I'll mention another one, assuming we're talking about disassembling rather than decompiling .

The trouble with x86 code is that distinguishing between code and data is very difficult and error-prone. Disassemblers have to rely on guessing in order to get it right, and they almost always miss something; by contrast, intermediate languages are designed to be "disassembled" (so that the JIT compiler can turn the "disassembly" into machine code), so they don't contain ambiguities like you would find in machine code. The end result is that disassembly of IL code is quite trivial.

If you're talking about decompiling , that's a different matter; it has to do with the (mostly) lack of optimizations for .NET applications. Most optimizations are done by the JIT compiler rather than the C#/VB.NET/etc. compiler, so the assembly code is almost a 1:1 match of the source code, so figuring out the original is quite possible. But for native code, there's a million different ways to translate a handful of source lines (heck, even no-ops have a gazillion different ways of being written, with different performance characteristics!) so it's quite difficult to figure out what the original was.

Answer 5

In general case there is no much difference between disassembling C++ and .NET code. Of cause C++ is harder to disassemble because it does more optimizations and stuff like that, but that's not the main issue.

The main issue is with names. A disassembled C++ code will have everything named as A,B,C,D,...A1, and etc. Unless you could recognize an algorithm in such format, there is not much information you could extract from the disassembled C++ binary.

The .NET library on the other side contains in it names of methods, method parameters, class names, and class field names. It makes understanding of the disassembled code much easier. All other stuff is secondary.

Answer 6

Besides something about metadata, debugging informations and all the technical reasons have pointed out by the other answers; what I thought about is:

The main reason you would think to disassembling win32 image is more difficult than .Net programs, is because of human perspective .

From the perspective of machine, native code is much more transparent, even of the processing of reverse engineering.

Oppositely, I'd like to say that to disassemble .Net applications/libraries CAN be more difficult, if the code has been obfuscated .

You might think it's difficult to disassemble native win32 programs, is because of its nature is consisting of machine code. But in fact, by a analogy of physical world and psychic, I think machine code is more like the physical one - it acts on what it actually does. Although reverse engineering of win32 programs could be very complex, the code is in the scope of instruction set of CPUs. The most complicated thing might be:

• addressing
• memory/register accessing
• hardware communications
• OS level technology (processing, swapping, paging, etc.)

There are a count of obfuscators and de-obfuscators for .Net , implemented in different technics. It is totally possible to make .Net applications much more difficult to be disassembled than win32 programs . For the reason most of virtual machine based programs are easier to be disassembled I think there are following considerations of them not to be too obfuscated :

• execution performance
• code optimizability
• maintainability
• cost considerations

If you've read the code of OpCodes of .Net framework, and you realize that there are more complicating concepts of language level and about OOP. For example, with Reflection.Emit , you can emit the opcode of calling a constructor, method or virtual method. Yes, it's based on MSIL(CIL) and runs by the CLR ; but that does not mean it is easier to be disassembled; it can be made in a obfuscated manner, and becomes much more difficult to be reversed to the source code; like the psychical world is always more impalpable than the physical world.