This issue mainly discuss some popular protection means under Microsoft .Net framework, including strongname, name obfuscation, flow obfuscation, metadata encryption, packing and some anti analysis tricks. With each protection, I will also provide some advice on how to reverse them. This issue is not a newbie tutorial, it targets on those guys who already get some experience in .Net programming and reversing.

Introduction

Believe it or not, Microsoft .Net framework is becoming more and more popular nowadays. Since the first version released at 2002, now we get four major versions of .net running on windows, that is v1.0, v1.1, v2.0 and v3.0. With the improvement of .net framework itself, protection technology also make great progress.

Later, we will discuss some protection means for .net applications, but before we dig into the main part, make sure you understand those basic conceptions, such as Assembly, Module, Type, Member, CLR(common language runtime), CTS(common type system), JIT(just in-time compile) etc. For those guys who don't know how easy a .net app can be reversed without protection, check .net reverse tutorial on http://www.accessroot.com.

Now, let's begin.

Introduction

Believe it or not, Microsoft .Net framework is becoming more and more popular nowadays. Since the first version released at 2002, now we get four major versions of .net running on windows, that is v1.0, v1.1, v2.0 and v3.0. With the improvement of .net framework itself, protection technology also make great progress.

Later, we will discuss some protection means for .net applications, but before we dig into the main part, make sure you understand those basic conceptions, such as Assembly, Module, Type, Member, CLR(common language runtime), CTS(common type system), JIT(just in-time compile) etc. For those guys who don't know how easy a .net app can be reversed without protection, check .net reverse tutorial on http://www.accessroot.com.

Now, let's begin.

StrongName

What's strongname? You can find lots of great papers in MSDN. In fact, strongname is not a protection means, but a verification. It make a hash calculation of your PE file, so system and app can check for that hash to see if the file is the original one. If the file is modified, the verification fail, and system refuse to run it.

When .net first come into birth, strongname is widely used as a measure to protect file be patched. But strongname is easily been removed, replaced, or even bypassed. The classic method is ildasm the PE file into il source code, then remove .publickey section in .assembly scope, then recompile it into PE file using ilasm. Search google you will understand why I say this ways is classic. Now, we get more convenient way, using tools directly. Check http://www.andreabertolotto.net/ you will find Strong Name Remove. Or, the most brute force one, patch system dll file to make strongname check always succeed. Sometimes the verification is made by application itself rather than system. Then you need a little more work to do, patch the app.

I'll not talk more about strongname, just stop here. More funny stuff is waiting for us. But for new birds, it's helpful to dig into strongname a little deeper. Just search in the internet library.

Name Obfuscation

Obfuscation may be the first formal protection means coming with .net, because Visual Studio is released with free edition of DotFuscator. How does name obfuscation protect our applications? As we all know, .net save all names(including names of assembly, module, method, field, OK, almost everything) into metadata, these metadata are all saved in the PE file. Using a decompiler (I prefer to using the word decompile, not disassemble, because msil itself is a high level language in contrast to asm), you will get more information than traditional win32 exe/dll. The result is, it's SO readable, just like reading original source code.

Name obfuscator obfuscate the names into unreadable (or unprintable) characters. There are several directions in how to obfuscate names: to meaningless string, to unprintable string, to “same” string, to very long string, or just delete the strings. Figure 1 illustrate using Reflector (the most popular decompiler under .net) to decompile an application which has been protected by a commercial obfuscator, how you feel when reading this code? (fig1 also shows flow obfuscation, which is the topic of next section.)

fig 1 using reflector to decompiler application protected by a commercial obfuscator

How to deal with name obfuscation? You can deobfuscate names into meaningful strings, such as Class1, Method1, TextBox1. Here meaningful means more readable, because name obfuscation is single-path transformation, we can't change them back to original names. Dis# has deobfuscate function, which can make this job easier. But at most time, it's not necessary to do that. The code is there, only a little hard to read, all we need is patience, time, and some skills (using analyze function of reflector, etc).

FLOW Obfuscation

Obviously, name obfuscation is not enough. To make the msil reading even harder, people invent flow obfuscation. Flow obfuscation means change code flow, but not change the code result. Flow obfuscation have at least two functions: make msil reading harder, make decompiling to high level language fail. Function one is clear, at least reversers have to spend more time on reading garbage codes. The second function bases on the fact that most decompilers can transform msil into HLL such as C#, C++/CLI. Reversers find that HLL is more readable than low level msil.

Flow obfuscator are implemented through several ways. First, insert junk code, such as figure one shows, adding Boolean judgement that always be true or false. Second, split source code into lots of segments, using branch or Boolean branch to connect them. Third, wrapper system calls into a new class, change all reference to these system methods to the new class's methods. Fourth, using decompiler's bug.

A simple example will illustrate how weak decompilers are when they try to transform msil to HLL. Input following code and assemble it using ilasm. Open it separately with four decompilers: Reflector, Dis#, Decompiler .Net 2005, and Xenocode Fox 2007.

.assembly extern mscorlib { }

.assembly extern System{}

.assembly sample {}

.method public hidebysig void Main()

{

.entrypoint

br.s start_here

pop

start_here:

ldstr "hello!"

call void [mscorlib]System.Console::WriteLine(string)

ret

}

Reflector report an exception when decompiling method Main() into HLL, the other three even don't decompile. The reason is simple, msil is a stack based language, which means it does not allow stack imbalance. These compilers using stack variable as the measure to decompile, but they all failed to recognise the junk code “pop” will never run. Of course, this little trick has no effect on msil decomiling. But that's what the flow obufscator want, to make code reading harder: now reverses have to say goodbye to HLL, and deal with boring il instructions.

How to deal with flow obfuscate? An answer come into everyone's mind immediately: flow deobfuscate. For simple flow obfuscate and for small applications with very little code, you can deobfuscate code by hand, remove junk code, connect code segments. But for larger ones, it's impossible. Then, good programmers may code a deobfuscator to make job automatically. Yes, it's a way, but I don't know if there are already some practical deobfuscators now. (I once coded a toy deobfuscator, which is useful for some obfuscated code, but need lots of work to do to be practical.) Some compiler tools/frameworks have optimization function, which can remove some of the junk code, such as MONO.CECIL, Microsoft phoenix RDK.

Metadata Encryption

Sometimes string reference is the key for reverse engineering. It's a basic rule that application should hide clue strings. String reference (called user string in .net) are saved as metadata in managed PE file. This section we will only talk about string encryption, more metadata encryption technology are combined into encryption/packing, which will be discussed in later sections.

In essence, there is only one way to hide user strings: encrypt them, then decrypt them when needed. But different protectors implement this hiding in different ways. Some encrypt each string with a unique key, then decrypt it with that key when running. Following is code sample.

IL_666e: ldstr "moacpphccapcmpfdhkmdepdedpkenobfpnifnopfingggongpi"

+ "ehbnlhpncihmjipmajfnhjolojomfkammkdmdlplklogbmllimnkpmhlgnlknnokeoakloj"

+ "fcpojjpejaadkhaneoapifbpjmbejdckikcajbdaiidmhpdgdge"

IL_6673: ldc.i4 0x7a122093

IL_6678: call string xb9d8bb5e6df032aa.x7840e3d83ad1c299::_bc24e513a5229081(string,int32)

The result string of this call is “Your product evaluation period has expired!”. Others may combine all user string into one encrypted byte array, assign each string an offset in the array. When the string is needed, using the offset and length to locate original string.

String encryption is easy to handle, why? Because the encryption is bidirectional. But, every programmer should use string encryption on their products, it's a basic rule.

OK, let's have a break here. Maybe some of you already become weary: protections under .net are not too hard, easy for me to deal with. Patient please, real challenge comes.

Packing / Encryption

Packing is so popular when facing traditional win32 applications. Now in .net era, it's also a powerful protection means. It's hard to make clear dividing line between packing and encryption, I prefer to discuss them together in one section. Let's start with the most simple packing: compression.

Compression

Compression means using compression algorithm to compress the PE file. When running, decompress the whole file in memory then invoke the entry method of the assembly. It is a kind of whole assembly protection, because the whole original file appear in memory at running time. It's easy to dump the assembly, by hand or by tools, such as .Net Generic Unpacker made by http://www.ntcore.com.

The typical code for whole assembly protection is call System.Reflection.Assembly::Load(), this instruction tell us at this time, the whole assembly is decrypted and ready to run. The following code always be locating the entry method or a special method, then invoke it.

Where the encrypted assembly be saved may be a little tricky. It can be saved as byte array in program code, or as a resource in .rsrc section. Once you locate the position and size, then get clear about the decryption algorithm, you can directly get original assembly without running the application. Static decryption or dynamic dump, you choose how.

Wrapper

Sometimes when you load a .net PE with reflector, you get a warn saying no CLI head. That means it's a native exe/dll file. But reading system requirements, it still needs .net framework installed. Why? Because the PE file has been packed (usually encrypted at the same time) by a native wrapper.

There are several kinds of wrapper. One is just a compression/encryption wrapper, after double click, it just release the whole assembly in memory. Others are more advanced, they take over .net system dll calls. If you inspect a .net PE with traditional tools, you will find there is only one instruction at the entry point: jump to CorExeMain or CorDllMain. Packer can take over this jump, only jump when it is ready(assembly has been decrypted).

Now we introduce a more advance wrapper in a new paragraph. Their wrapping target is JIT. We know that to make a .net program runs normally, all we need to do is give JIT the correct msil code and metadata. JIT don't care what you do before and after the just in-time compiling. The key code for JIT under .net framework 2.0 lies in mscorjit.dll, on my machine it's the following code.

.text:7906E7F4 private: virtual enum CorJitResult __stdcall

CILJit::compileMethod(class ICorJitInfo *,

struct CORINFO_METHOD_INFO *,

unsigned int,

unsigned char * *,

unsigned long *) proc near

The second parameter, a pointer to CORINFO_METHOD_INFO, is a structure as follows.

struct CORINFO_METHOD_INFO

{

CORINFO_METHOD_HANDLE ftn;

CORINFO_MODULE_HANDLE scope;

BYTE * ILCode;

unsigned ILCodeSize;

unsigned short maxStack;

unsigned short EHcount;

CorInfoOptions options;

CORINFO_SIG_INFO args;

CORINFO_SIG_INFO locals;

};

The third and fourth field of the struct is the key information JIT wants. All that packers need to do is decrypt msil and change the parameter to correct ones, then call compileMethod(), make JIT happy.

A trick here, how the packer knows when the CLR is going to call JIT? If we check the export table of mscorjit.dll, we will get a function: getJit(). What we get when call this? Check the code.

.text:7907EA7A __stdcall getJit() proc near

.text:7907EA7A mov eax, dword_790AF168

.text:7907EA7F test eax, eax

.text:7907EA81 jnz short locret_7907EA97

.text:7907EA83 mov eax, offset dword_790AF170

.text:7907EA88 mov dword_790AF170, offset const CILJit::`vftable'

.text:7907EA92 mov dword_790AF168, eax

.text:7907EA97

.text:7907EA97 locret_7907EA97: ; CODE XREF: getJit()+7j

.text:7907EA97 retn

.text:7907EA97 __stdcall getJit() endp

Obviously, it returns 0x790AF170, address of CILJit::'vftable'. What's the table about?

.text:7907EA98 const CILJit::`vftable' dd offset CILJit::compileMethod(ICorJitInfo *,CORINFO_METHOD_INFO *,uint,uchar * *,ulong *)

.text:7907EA98 ; DATA XREF: getJit()+Eo

.text:7907EA9C dd offset CILJit::clearCache(void)

.text:7907EAA0 dd offset CILJit::isCacheCleanupRequired(void)

The first member of CILJit::'vftable' just points to compileMethod, what we have discussed. This vtable never change on a fixed .net framework and machine. Packer can either using getJit() or directly patch the dword in memory.

Hook JIT

We have checked how packers warp JIT and dynamically decrypt msil. But some packers don't wrap, they hook special methods of JIT and EE(Execution Engine). A popular hooking lies in RuntimeMethodHandle::GetMethodBody.

.text:7A120C88 public: static class MethodBody * __fastcall RuntimeMethodHandle::GetMethodBody(class MethodDesc * *, void *) proc near

.text:7A120C88 ; DATA XREF: RuntimeMethodHandle::GetMethodBody(MethodDesc * *,void *)+29o

.text:7A120C88 ; .data:7A384EE4o

.text:7A120C88

.text:7A120C88 var_B0 = dword ptr -0B0h

…

…

.text:7A120DDF mov ecx, [ebp-34h]

.text:7A120DE2 call MethodDesc::GetILHeader(void)

.text:7A120DE7 mov [ebp-7Ch], eax

…

…

Take care of the bolded instruction call GetILHeader, packers can do their job here. Jump to their own code, decrypt the msil code and metadata, then go on with GetMethodBody.

Such packers who using hook method are almost per-method decryption. That means it never decrypt the whole assembly at one time, but only decrypt the method which is needed. This make it impossible to directly dump the whole assembly in memory, because there is no whole assembly in memory.

To reverse applications protected by these packers (more precisely, to dump the whole assembly), you need some skill to deceive the packer, make it believe the JIT wants the code, then give us the decrypted code. Why not statically decrypt? Because most packers use more than one encryption algorithm, and randomly select among these algorithms to encrypt different methods. I prefer to deceive .

How? OK, I'll tell you one of the methods I deceive those packers. Using reflection mechanism of .net framework, enumerate all Classes, Methods, Fields and so on, scan decrypted metadata in memory, then rebuild the assembly. Sometimes we don't need the assembly be same with the original one, or even don't need it can run, we just need it can be decompiled. But, as I know, there is no generic unpacker useful for every type of protections under .net.

Some Anti Tricks

This section will be simple, just introduce some little tricks making analysis of your program a little harder. Most of them are borrowed from win32 anti reversing. I'll only mention their names, because no explanation is needed.

How to anti profiler? You can set the environment variable COR_ENABLE_PROFILING to make profiler disabled every time your application runs. Or, patch the sign directly in memory. Following code will give you some clue on how .net transform information to profiler.

.text:79E972AD ; MethodDesc::MakeJitWorker(COR_ILMETHOD_DECODER *,ulong)+267972j ...

.text:79E972AD test byte ptr ProfilerStatus g_profStatus, 6

.text:79E972B4 jnz loc_7A0FEB52

.text:79E972BA

.text:79E972BA loc_79E972BA:

If profiler is disabled, then managed debugging is disabled. But reversers can still using OllyDBG to perform native debug. Just use System.Diagnostics.Debugger::get_IsAttached supplied by .net or use IsDebuggerPresent from kenel32.dll to detect that. System.Diagnostics.DebuggerHiddenAttribute also may be used to prevent new birds step through key method freely (in managed debugging).

Enumerate all windows names and check if there is some should-not-be-there application is running. Process32First and Process32Next is also a good way.

Using time span checking in key method to deceive reversers. Don't just exit if time span is too large, just give them the wrong register code.

Using internet verification. But I don't like using software need forced internet verification, because most time I have no access to internet.

Don't offer trial versions on your site.

Summarize

We've discussed some (maybe not all) popular protection means under .net, introduce their implementation and how to reverse them. You can choose the most suitable one or ones for your application. The wars of reverse engineering and protection under .net is just begin, with the Vista comes. Which side will win? Just like the history, one may win a battle, but no one can win the war.

StrongName

What's strongname? You can find lots of great papers in MSDN. In fact, strongname is not a protection means, but a verification. It make a hash calculation of your PE file, so system and app can check for that hash to see if the file is the original one. If the file is modified, the verification fail, and system refuse to run it.

When .net first come into birth, strongname is widely used as a measure to protect file be patched. But strongname is easily been removed, replaced, or even bypassed. The classic method is ildasm the PE file into il source code, then remove .publickey section in .assembly scope, then recompile it into PE file using ilasm. Search google you will understand why I say this ways is classic. Now, we get more convenient way, using tools directly. Check http://www.andreabertolotto.net/ you will find Strong Name Remove. Or, the most brute force one, patch system dll file to make strongname check always succeed. Sometimes the verification is made by application itself rather than system. Then you need a little more work to do, patch the app.

I'll not talk more about strongname, just stop here. More funny stuff is waiting for us. But for new birds, it's helpful to dig into strongname a little deeper. Just search in the internet library.

Name Obfuscation

Obfuscation may be the first formal protection means coming with .net, because Visual Studio is released with free edition of DotFuscator. How does name obfuscation protect our applications? As we all know, .net save all names(including names of assembly, module, method, field, OK, almost everything) into metadata, these metadata are all saved in the PE file. Using a decompiler (I prefer to using the word decompile, not disassemble, because msil itself is a high level language in contrast to asm), you will get more information than traditional win32 exe/dll. The result is, it's SO readable, just like reading original source code.

Name obfuscator obfuscate the names into unreadable (or unprintable) characters. There are several directions in how to obfuscate names: to meaningless string, to unprintable string, to “same” string, to very long string, or just delete the strings. Figure 1 illustrate using Reflector (the most popular decompiler under .net) to decompile an application which has been protected by a commercial obfuscator, how you feel when reading this code? (fig1 also shows flow obfuscation, which is the topic of next section.)