Reverse Engineering of an Obfuscated .NET Assembly

Introduction

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



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

Decompilation

The first tool for reverse engineering and analysis of .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 completely refuses to open the assembly.



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 give us of course 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, we start ildasm, open our assembly ... and again the file: “Protected module - cannot disassemble”.



This means that the assembly is compiled with the SupressIldasmAttribute attribute. To decompile this assembly, we need to get rid of this attribute. I used the free utility for editing PE CFF Explorer files for this . It has full .NET metadata support for assemblies. Open our file and look for metadata: '.NET Directory' / 'MetaData Streams' / '# ~' / 'Tables'. In the typereference metadata table (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 assembly in ildasm and view the MSIL code, which is already good. But in Reflector our file still does not open. In order to do this, save the MSIL to a file with the command " ildasm.exe pokein.dll / source /out:pokein.il"and rebuild the assembly using the ilasm utility that is included with the .NET Framework:" ilasm.exe pokein.il / dll /out:pokein.dll . "Unfortunately, there is little benefit from this, since most obfuscated methods will still be are not available, and the list of classes / fields / methods can be viewed in the Object Browser.

Code analysis

Let's start the code analysis. Scanty documentation and an example from the archive make it possible to understand that the main work takes place in the static class PokeIn.Comet.CometWorker. Upon a more detailed study of it, we find the static ActiveClientCount property, the name of which hints that it can be used to check the limit on the number of clients, as well as several overloaded Bind methods that are obviously called when a new client is connected.
We continue to work with the il-file. When searching the ActiveClientCount string, we find several property calls of the following type: Let's parse this code into the lines: IL_0007: calls the getter of the ActiveClientCount property and pushes the result onto the stack IL_000c: pushes the number 10 on the stack

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




IL_000e: if the first operand from the stack is less than or equal to the second, the jump to the address IL_0027 Typically

, 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 let's try to run the assembly in debug mode.
Stop, we don’t have any source code, since Reflector could not cope with decompilation, nor debugging information?
That's right, but there are several ways to debug MSIL code directly. I’m most used to using Visual Studio for debugging, so I’ll tell you about this particular method.
To generate debugging information, we rebuild the library with the / debug switch: " ilasm.exe pokein.il / dll / debug /out:pokein.dll". A debug 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 put breakpoints directly in the il file on calls to get_ActiveClientCount (). To emulate several clients, simply open the test page in several tabs in the browser.When each new tab is opened, we will have a breakpoint in one of the Bind () methods work. When the tabs become over 10, we will receive an alert on the javascript page with information that we have exceeded the maximum number of simultaneous connections.

MSIL Modification

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

In fact, the ActiveClientCount call can also be removed. I leave this as your homework.
We repeat this operation in all places for checking the connections, collect the il file back with the ilasm utility, update the link in the test project, check that there are no more restrictions, alerts do not appear, the task is completed.

The free version of this library has some more restrictions that can be eliminated in the same way.

This article is written for educational purposes, and is not an appeal or instruction for hacking paid programs.
I hope you enjoyed it, and you learned something new for yourself.