Reverse engineering obfuscated assembly .NET

Introduction

In this article, I want to share with the respected community my experience of analyzing and modifying the obfuscated .NET assembly using the example of the PokeIn COMET library.



A few days ago I became interested in COMET solutions for ASP.NET and found some interesting libraries, among which there was a formerly free PokeIn. Obviously she enjoyed some popularity, as the authors transferred it from the category of open source to paid. The library website has the opportunity to download a free version with some limitations, among which, perhaps the most important is the limitation of 10 simultaneous connections. With him we will fight.

')

Decompilation

The first tool for reverse engineering and analyzing .NET assemblies is the well-known Reflector. We download the free version of the library from the PokeIn website, look for the assembly for the .NET Framework in the archive and run Reflector. Here we are waiting for the first disappointment: Reflector refuses to open the assembly at all.



Okay, close Reflector and recall ildasm.exe, a utility from the Windows SDK for decompiling .NET assemblies into MSIL code (Microsoft Intermediate Language). This will certainly give us a lower-level code and it will not be so convenient to work with it, but, in fact, it is not much more complicated.
So, launch ildasm, open our build ... and again the file: “Protected module - can not disassemble”.



This means that the assembly is compiled with the SupressIldasmAttribute attribute. To decompile this assembly, we need to get rid of this attribute. For this I used a free utility for editing PE files CFF Explorer . It has full support for .NET metadata assemblies. Open our file and look for metadata: '.NET Directory' / 'MetaData Streams' / '# ~' / 'Tables'. In the table of type references metadata (TypeRef) we find a reference to the SupressIldasmAttribute type and delete it by setting the Name and Namespace fields to 0.



Now we can open the build in ildasm and view the MSIL code, this is not bad. But in Reflector, our file still does not open. To do this, save the MSIL to a file with the command " ildasm.exe pokein.dll / source / out : pokein.il " and reassemble the assembly using the ilasm utility, which is included in the .NET Framework distribution : " ilasm.exe pokein.il / dll /out:pokein.dll ". Unfortunately, the benefits of this are few, since most obfuscated methods will still be unavailable, and the list of classes / fields / methods can be viewed in the Object Browser.

Code analysis

Let's start analyzing the code. The meager documentation and example from the archive make it possible to understand that the main work takes place in the static class PokeIn.Comet.CometWorker. In a more detailed study of it, we find the static property ActiveClientCount, the name of which hints that it can be used when checking the limit on the number of clients, as well as several overloaded Bind methods that are obviously caused when a new client is connected.
We continue to work with the il-file. When searching by the ActiveClientCount string, we find several invocations of the following property:

IL_0007: call int32 PokeIn.Comet.CometWorker::get_ActiveClientCount()
IL_000c: ldc.i4.s 10
IL_000e: ble IL_0027

Let us analyze this code line by line:
IL_0007: calls the getter of the ActiveClientCount property and pushes the result onto the stack.
IL_000c: pushes 10 onto the stack.
IL_000e: if the first operand from the stack is less than or equal to the second, go to IL_0027

Tellingly, these calls are in the Bind and DynamicBind methods, which indicates that we are on the right track.

MSIL Debugging

The next step is optional, but I’m always interested to see how it works live, so we’ll try to run the build in debug mode.
Stop, we don’t have any source code, since Reflector didn’t cope with decompilation, or debug information?
That's right, but there are several ways to debug MSIL code directly. I’m used to debugging Visual Studio, so I’ll tell you about this method.
To generate debug information, we rebuild the library with the / debug key: " ilasm.exe pokein.il / dll / debug /out:pokein.dll ". A debugging pdb will also appear in the folder with the dll file. In the test project, we replace the link from the original pokein.dll with a new one, and set the breakpoints directly in the il file on get_ActiveClientCount () calls. To emulate several clients, simply open the test page in several tabs in the browser. When opening each new tab, we will have a breakpoint in one of the Bind () methods. When the tab becomes over 10, we will get on the javascript alert page with the information that we have exceeded the maximum number of simultaneous connections.

MSIL Modification

Now we need to remove the limit on 10 simultaneous connections. Open the il file and go to the verification code. The first line (in the example - IL_0007) is left unchanged. As we remember, calling the property will put the result on the stack, so we need to pick it up from there - replace
IL_000c: ldc.i4.s 10
on
IL_000c: pop
Now replace the conditional transition
IL_000e: ble IL_0027
on unconditional
IL_000d: br IL_0027

In fact, the call to ActiveClientCount can also be removed. I leave it to you as a homework.
We repeat this operation in all the places where connections are checked, we assemble the il file back with the ilasm utility, update the link in the test project, check that there are no more restrictions, no alerts appear, the task is completed.

In the free version of this library there are some other limitations that can be eliminated in the same way.

This article is written for educational purposes, and is not a call or instructions for hacking paid programs.
I hope you liked it, and you learned something new for yourself.