Analysis of JIT layer shelling

Prepared by: chenxiaolu

Now. the Net shell is getting stronger and stronger, and the current mainstream protection ideas are all based on the "method" layer. In the memory, we can no longer obtain the complete Assembly, even if the Dump is down, the IL code is also incomplete. The Representative shells are Reactor, MaxToCode, DNGuard HVM, and so on.
However, I don't know why, the scalpers are always hiding their technology, which makes it impossible for us to crack these dishes. After carefully reading rick's articles and following someone's careful guidance, I have a little bit of experience, let's share it with you.
As the saying goes: "The persimmon is looking for a soft pinch." Among the three strong shells mentioned above, the weakest thing is to calculate the Reactor. Although it is the weakest, I believe it can hardly beat 90% of DOTNET beginners. Although the scalpers are dismissive or even seckilling, we still need to study it for a long time.
To facilitate research, we should first create a small CrackMe. The code is very simple as follows:
Code:
If (textBox1.Text = "123456 ")
{
MessageBox. Show ("code is OK ");
}
Else
{
MessageBox. Show ("ERROR ");
}
As long as the registration code is 123456, the registration can be successful. Based on the RVA address, we can find its binary code as follows:


 
 
We will use Reactor4.4 to encrypt this CrackMe. For the same purpose, we only select the NecroBit option.
 
 
After encryption, we can no longer see the IL code.
 

This is the exclusive secret of the Reactor, which is encrypted based on the method body.
 
So there is really no way for us? Of course there are some methods. One of them is to study the Reactor's self-decryption function, so we can even perform static shelling, But this is part of the research scope of Niu Ren. We will not study it for the moment. The second is to use Hook JIT to intercept IL code. I have already explained in detail how to compile a hook jit code on the snow forum, so I will not discuss it. We can even directly use the ILLY plug-in of OllyDBG to directly obtain the IL code.
Http://bbs.pediy.com/showthread.php? T = 116218
Http://bbs.pediy.com/showthread.php? T = 63940
Before using this plug-in, you must first build a Pure DOTNET environment. The so-called Pure DOTNET environment means that only the original Windows XP operating system is installed on a bare metal. NET Framework v2.0.50727 Framework.
Http://www.microsoft.com/downloads/z...d-aab15c5e04f5
No other software is installed. This environment is very helpful for hook jit, so that we can use the ILLY plug-in today to stably intercept the IL code. We recommend that you create such an environment in a virtual machine.
 
Copy the ILLY plug-in to the plug-in directory of OllyDBG. Then, drag the encrypted CrackMe into the OllyDBG,
OllyDBG will soon be interrupted to the compileMethod method, and the IL Code dialog box will pop up. Of course, only the CrackMe entry point is displayed here. To test, we will suspend the monitoring of ILLY first, let the program run.
 
 
You can use the preceding menu to pause or execute ILLY monitoring. When the program runs, we enable ILLY again. After clicking the button, the ILLY plug-in truly intercepts the IL code we need.
 
 
It is the core IL code we get. We don't have to worry about it first, so we can see a small unexpected result. Please refer to the disassembly code of OllyDBG:
 
 
Isn't that the Native code after the IL code is compiled ?? The red part is the key hop to judge whether the registration is successful. After 74 is changed to 75, the registration is successful! It seems that we can only make one memory patch, but it is not the topic of today's research. We will not discuss it for the moment.
In the pop-up ILLY dialog box, we can click Save *. BIN to the file, so that we can actually get the Reactor encrypted data through the hook jit. We only need to restore the binary code to the original program, but the new problem arises: the encrypted program stores too few bytes of the IL code, we get too many IL bytes, so we can't put them down .....
 
I had to ask someone for help for a long time. Someone did this: he first used CFF to create a Section in the encrypted program to add the binfile to which the Dump is saved. As shown in
 
 
After the Section is added, the new Section is named. text2.
 
 
We only need to re-point the rav of the button_click1 Method to the new decrypted method (the RAV of. text2 is 14000 ). But here we must pay attention to a big problem: Tiny Method and Fat Method. Because there is a lot of data for calculating the Fat Method, we still process it as Tiny Method, the Tiny Method header calculated based on the size of the IL code should be CA, so we will change RAV 14006 to CA (limited by space, the specific calculation Method can be Google) then we can change the RVA of Button_click1 to 14006.
 
Modify the red box to 14006


 
After saving the disk, we can use ILSPY to open it and see the magic scene:
 
 







We have successfully restored the source code after Reactor4.4 encryption !!! Excited ~~~~ How many cainiao were once hard to find ~~~
The program tried to run. No error was reported !!! The rest of the cracking work is too simple to avoid.
 
Today, we have completed simple cracking of the Reactor4.4 encrypted program by hand. Are you satisfied? If you write a tool to complete the entire manual operation process, the entire Reactor shell can be easily removed !! This article only plays a role in attracting others. Although someone has already written an automatic shell removal machine, it is a pity that he didn't give it to me ....... I can't share it with you. Sorry .......
Finally, I hope you can write it out and share it.
The appendix provides the CrackMe mentioned in the article. Please try it out. Please leave a post or send an email to me to discuss the chenxiaolu2012@gmail.com together.

Http://www.bkjia.com/uploadfile/2012/0215/20120215102518946.rar