Unprotecting crypter

[Usr6]

Tools Used

1)OllyDbg

2)Process Explorer

3)PUPE

4)PE Tools

5)Hex WorkShop

Crypter

So what is a Crypter.If have some experience in malware Field then You must have Heard about tool called “Crypter”or may be used it.The Aim of Crypter to Protect the executables ,making difficult to analyze it or reverse engineer it .But Mostly in Malware Scene the crypters are mainly used to make malwares FUD .Here FUD stands for Fully Undetectable.

Actually the malware are basically distributed as executables ,I mean sources are gernally not available. Public malwares are gernally detected by antivurses ,that’s why crypters are used to make them FUD .

How Crypters Work

Principle for making a crypter is very simple . Crypter Consist of Two parts

1)Builder

2)Stub

How they both parts work

1)You give your file as input to crypter,it encrypts it with any encryption algorithm (most likely RC4,AES)

By encrypting the file it defeat the static analysis done by antivirus.During static analysis the antivirises try to find the the patterns in executable and match with with signatures.Because the file is encrypted

So the antivirus can’t find patterns here.

2)Add the stub before the executable code.

When you run executable then the stub runs and decrypt the encrypted file .

Note :The decrypted file remains in memory .

3)Execute the Decrypted from Memory .

This is actually the heart of crypter.This is also called “Run PE “.There are different methods for Run PE .But Mostly the Crypter used a public method to exectute the File from Memory ,that’s what we are going to target.

Let me Explain the the method .The orginal link of this method is

SIG^2 G-TEC - Dynamic Forking of Win32 EXE

I just copying the steps .i realy suggest you to once read the whole article to understand in more depth.

The steps listed in article are :

1) Use the CreateProcess API with the CREATE_SUSPENDED parameter to create a suspended process from any EXE file. (Call this the first EXE).

2) Call GetThreadContext API to obtain the register values (thread context) of the suspended process. The EBX register of the suspended process points to the process’s PEB. The EAX register contains the entry point of the process (first EXE)

3) Obtain the base-address of the suspended process from its PEB, i.e. at [EBX+8]

4) Load the second EXE into memory (using ReadFile) and perform the neccessary alignment manually. This is required if the file alignment is different from the memory alignment

5) If the second EXE has the same base-address as the suspended process and its image-size is <= to the image-size of the suspended process, simply use the WriteProcessMemory function to write the image of the second EXE into the memory space of the suspended process, starting at the base-address

6) Otherwise, unmap the image of the first EXE using ZwUnmapViewOfSection (exported by ntdll.dll) and use VirtualAllocEx to allocate enough memory for the second EXE within the memory space of the suspended process. The VirtualAllocEx API must be supplied with the base-address of the second EXE to ensure that Windows will give us memory in the required region. Next, copy the image of the second EXE into the memory space of the suspended process starting at the allocated address (using WriteProcessMemory)

7) Patch the base-address of the second EXE into the suspended process’s PEB at [EBX+8]

8) Set EAX of the thread context to the entry point of the second EXE

9) Use the SetThreadContext API to modify the thread context of the suspended process

10) Use the ResumeThread API to resume execute of the suspended process.

When you normally load a packed executable in ollydbg then it shows warning like “the code section is compressed” or “the entrypoint is outside the code section “ whatever means olly give you hint that the executable is packed.But the executable crypted by crypter (which is using above method) never shows any warning when it is loaded into olly it does not show any warning .

Analysis

Lets start from very basic stuff ,Scan it with PEID

Looks Inocent ,is it ?

Lets Load it in Olly ..see it shows any warning or not

Everthing Looking normal,Looks Like a normal VB excutable no warning shown by olly

First Verify If our target is realy innocent or malicious.Acc. to method described above it must call Create a new process.So Put a BP on CreateProcessA and CreateProcessW (for both ascii and unicode versions).If it Breaks then see the arguments passed check if it is in SUSPENDED MODE (Also You can Put Breakpoint on ReadProcessMemory and WriteProcessMemory APIs to check it more accurately )

I Put BP on CreateProcessW and CreateProcessA and run it in olly.As you can see this it is Breaked at CreateProcessA..Also You can see it parameters in stack ,also you can see that it is in SUSPENDED_MODE .

It calles the CreateProcess In suspended mode(suspend its main thread) then decrypt the encrypted malware in newly created process address space when everything is on its place then it calls the ResumeThread API and it start running

We are going to attack at the point when It calles the ResumeThread API,because ResumeThread API is last step in executaion and before this everthing will be on its place .

So I Put BP on ResumeThread,Lets See what Happens

Wow Its Breaked on ResumeThread..

Now Step Into ResumeThread by Pressing F7.

As You can see that ResumeThread internally calls window native api NtResumeThread

NOTE: NtResumeThread is Undocumneted native API . Most of windows API works this way .They provide a documented interface for main function then internally called the undocumented native APIs.This Concept is very Important Because Sometime the Crypter authors uses undocumented native APIs instead of Documented APIs.

For example they can directly use NtResumeThread instead of calling ResumeThread.In this way if you put BP on ResumeThread then it will not break .So I strongly suggest you to put breakpoint on native undocumented APIs instead of Documented APIs.

For example always put BP on NtResumeThread instead of ResumeThread ,then you will directly break at 75A0C3D5 instead of 75A0C3C9

Lets Step inside NtResumeThread. By pressing F7.Contnue pressing F7 until you reach it 778764F2

This is point where the ResumeThread actually get executed and our suspended Process will start executing ,but we do not want to execute it to not get infected .So stop Here

Now open the Process Explorer and dump the this process (the child process),select child process ,select full dump

It will be saved as filename .dmp format ,I rename it to dump.exe

I named file as dump.exe ,and I scan it with PEID

Ah, not a Valid PE file..seems scary ..lets Fix this..The PE File start With Letter “MZ “.The File Analyzer like PEID gernally first check if the file contain MZ in starting or not ..if not that mean not a valid PE file(Also they do some extra tests ..but check for ”MZ” is first one.)

Open Up it dump.exe in Hex Workshop,search for “MZ”.Delte Everything above “MZ”. Save It ,Then our file become valid executable .

Now You can scan your modified File with PEID .Just see the results i got

Now Look Like Valid PE

But this is Not runing and giving the C++ Run time Error

If this file is not going to run then why we waste so much time on it ?

The Purpose of making this valid PE is to Find Its OEP by Loading it into Olly or by using other PE utlity tools

Note : You can find directly Calculate OEP from Hex Workshop without Deleting the Bytes If You know PE Header, I want to make it simple so I do it by this simple ad long way.

OEP :Orginal Entry Point .It is the address from which the program start execution.

Why we need OEP ?

WE Dump the program before the ResumeThread execute but it is not working.I am supposing the the crypted program is malware so I do not want to run it,then how I am going to to get it working .The idea is

Change the First Two Bytes at Program Entry point so that it trapped in infinite LOOP ,this way it will not able to get executed and everthing will be placed correctly and we will have a gud chance to dump it .

Lets Find the OEP by of our dumped file by opening it in olly.Also Note Down the starting bytes at entry point

0048847F <ModuleEntryPoint> 6A 60 PUSH 60

EntryPoint 0048847F

The First Two Bytes are 6A 60

Show Time

Lets Finally Fix this:

Run the Crypted.exe in olly ,Continue Untill the last instruction inside ResumeThread Executes Like we did before.That is countinue Stepping into ResumeThread API until this instruction

7C90EB8D 0F34 SYSENTER

That’s point where the actually execuation takes place

Now We Have to change first two bytes at EntryPoint to trap the program in infinite Loop,we olly use the little program PUPE for this

We can see our child process Crypted.exe in process Explorer. Its process id is 544 in decimal

Process id in Hex =220

Select the Target Process and click Patch . Then You will see the patch window Like this

Change the Number of bytes to 2

Put the OEP in the Direction option and click search we get 6A 60 as bytes (these are ogrinal bytes .note it )

Put EB FE in change by .

EB FE will instruction will make the jump to to same instruction again and again and hence trap it in infinite loop

Now click on patching

After that the orginal bytes are replaced by EB FE .

Now Go to our ollly again and click and Run the Program

After Clicking on Run button you will see that that your process is terminated in olly .

Don’t Worry it does not matter to us .Only child process matter to us that is still running (trapped in infinite loop) . Now you just have to Dump it with Your Favourate Dumping tool. I Will dump it with my favourate that is PE tools

Click on Dump Full and save it with any name you want .i saved it with final_dump.exe

After Dumping Also Kill the process.

Now open the final_dump.exe in olly

As You can see the first two bytes are EB FE ,they will always trp the program in infinite loop to fix it replace these two bytes with orginal two bytes that are 6A 60

Right click on instruction then go to binary -> edit options and replace it with orginal bytes as shown in pic

Now click on the copy to executable option and save this file .Now You have Your orginal file back .

Congrats You just Unpck the crypted file successfully.

You can verify it by running .

Important :

As I already mention the crypter coders now days use the windows undcoumneted native APIs instead of documented API

FOR example Use of NtResumeThread instead of ResumeThread.

So I suggest to Put BP on NtResmeThread instead of Resume Thread.

Apply same to all other API that you want to break on .

These crypters gernally add junk code to make them undtectbale but don’t worry if they are using the same RUN PE method they will get unpacked by using this method because adding junk code did not matter at the end they have to to call ResumeThread

NOTE :This Method works on the crypter who are using the above method written .I found that more than 60 % crypters use the method.

Sursa

[giv]

Foarte bun articolul.

Insa cei care doresc sa faca acest lucru ar trebui sa aiba cunostinte tehnice de baza ca as poata intelege ce se intampla in aceste imagini.