Salamander .NET Linker - How does it work?

I'd like a step through of how the Salamander does what it does? I will include a few points im particularly interested in

-

Link On Demand

The lin开发者_运维百科ker starts with the entry methods (which you can configure), and recursively walks the call graph to link only the required bits of MSIL code. Unused code will not be linked into the final assembly. Therefore, your code becomes more efficient and file size becomes smaller.

-

Link into Framework APIs

The linker is so powerful that even the Microsoft .NET Framework assemblies, such as System.Windows.Forms.dll, can be linked into your own .NET assemblies. Since it links on demand, only the required portion will be linked. This is very useful for protecting your code, simple application deployment, and trouble shooting by debugging into the framework code itself.

-

Native Compliation

The native compiler converts all managed assemblies, including system assemblies, into x86 native code. No MSIL instruction will be shipped, no JIT compilation at run time. This provides the best ever protection against disassembling and decompilation, and it also improves performance and startup time.

-

Simple and Fast Deployment without full Microsoft .NET Framework Installation

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?

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.