1

我想了解一下蝾螈是如何做到的？我将包括我特别感兴趣的几点

-

按需链接

链接器从入口方法（您可以配置）开始，并递归地遍历调用图以仅链接所需的 MSIL 代码位。未使用的代码不会链接到最终程序集中。因此，您的代码变得更高效，文件大小变得更小。

-

链接到框架 API

链接器非常强大，甚至可以将 Microsoft .NET Framework 程序集（例如 System.Windows.Forms.dll）链接到您自己的 .NET 程序集中。由于它是按需链接，因此只会链接所需的部分。这对于保护您的代码、简单的应用程序部署以及通过调试框架代码本身来排除故障非常有用。

-

本机编译

本机编译器将所有托管程序集（包括系统程序集）转换为 x86 本机代码。不会发布 MSIL 指令，不会在运行时进行 JIT 编译。这提供了有史以来最好的反汇编和反编译保护，并且还提高了性能和启动时间。

-

无需完整的 Microsoft .NET Framework 安装即可进行简单快速的部署

The mini-deployment tool puts together the minimum set of CLR runtime files and dependent assemblies that can be simply copied to a single folder on a target machine, and your application runs as if the whole framework is installed. Since the installation is isolated into a single folder, there will be no conflicts with future .NET installation. When linking is used for the dependent assemblies, it will further reduce the file size.

-

Code Protection There is one problem none of the current obfuscators address, that is, no matter how good the obfuscation is, there are system library calls and other external references scattered over in your code (see red in below). Since these calls are external references, obfuscators will have to leave them unchanged. However, these references help a lot to understand the decompiled code, because they are well documented and public APIs. The linker removes or reduces such public APIs by linking the framework APIs into your own code, and thus makes your code much more difficult to decompile after obfuscation. Below shows sample MSIL code before and after the linker is used.

before: (no obfuscators are able to rename the following code, since they are external public APIs)

IL_0000:  ldarg.0
IL_0001:  call       instance void [System.Windows.Forms]System.Windows.Forms.Form::.ctor()
IL_0006:  ldarg.0
IL_0007:  newobj     instance void  [System.Windows.Forms]System.Windows.Forms.TextBox::.ctor()
IL_000c:  stfld      class [System.Windows.Forms]System.Windows.Forms.TextBox A.A::A
IL_0011:  ldarg.0
IL_0012:  ldfld      class [System.Windows.Forms]System.Windows.Forms.TextBox A.A::A
IL_0017:  call       valuetype  [System.Drawing]System.Drawing.Color [System.Drawing]System.Drawing.Color::get_Cyan()
IL_001c:  callvirt   instance void  [System.Windows.Forms]System.Windows.Forms.TextBoxBase::set_BackColor(valuetype [System.Drawing]System.Drawing.Color)
IL_0021:  ldarg.0

after: (absolutely no clue Windows.Forms APIs are used, a high obstacle for a hacker to understand this junk)

IL_0000:  ldarg.0
IL_0001:  call       instance void a.A::.ctor()
IL_0006:  ldarg.0
IL_0007:  newobj     instance void  D.c::.ctor()
IL_000c:  stfld      class D.c A.A::A
IL_0011:  ldarg.0
IL_0012:  ldfld      class f.aA.A::A 
IL_0017:  call  valuetype        a.B()
IL_001c:  callvirt  instance   void  D.c(valuetype g.e)
IL_0021:  ldarg.0

Some of these things baffle me, and i was wondering if anyone else knew how it all worked?

4

1 回答 1

1

Native Compliation, Simple and Fast Deployment without full Microsoft .NET Framework Installation, Code Protection:

They are compiling "YourApp" + ".NetFramework' into a native dll. This has no IL and no symbols so it is much harder to reverse engineer.

Link On Demand, Link into Framework APIs:

To keep the .dll a resonable size, they have to leave out the dead code (the code that will never be called) from the dll. To do this they walk the call tree from the root, usually Main(), and just include these methods. There may be issues with code being called via reflection, so I guess they allow more than 1 root.

于 2010-07-25T23:02:09.943 回答