I see there is quite some interest around Sodin on OSINT pages, some have problems with unpacking the sample, others reverse and create complex IDAPython scripts to recreate the IAT.
In this post, I’ll demonstrate a quick and easy way to unpack this malware without losing time with scripting. IDAPython has it’s benefits, but sometimes its important to get toe job done quick!
The sample I’ll be working with can be downloaded from here.
- quick analysis in IDA of the packed sample
- identify the unpacking subroutine
- debug in x32dbg
- execute through the unpacking subroutine
- find the jump to the unpacked code
- dump the process with the new OEP
- load the unpacked sample in IDA
- identify any calls to undefined pointers
- identify the subroutine that rebuilds the IAT
- run the IAT rebuilding subroutine
- locate the new IAT
- patch the process dump with the correct IAT
After the sample is loaded into IDA, you’ll immediately observe some odd things.
- the first call is pointing to a subroutine composed only of mathematical operations and some loops. looks like a deobfuscation routine to me…
- several instructions down, another call, but this time to a pointer that will hold the value from another pointer that is set inside the previous subroutine. (check references of the pointer)
Load the sample into x32dbg and add a breakpoint at 0x00404E18, run and step into the call. You are now in a memory section that was created and written by the first subroutine of the malware. Stepping through the code you’ll see another unpacking routine that will allocate memory for the PE sections and will copy data./ode in them.
Every time I unpack samples, I look for CALLs or JUMPs to undefined memory sections (like calls to undefined pointers, calls to CPU registers). In this case, after the unpacking has finished the instruction that will jump to the OEP (original entry-point) is “JMP EAX”.
Breakpoint, run and step into the “JMP EAX” instruction. Now you have an unpacked sample, but Sodin hasn’t yet rebuilt the entire IAT.
Now, the first thing comes to mind is to dump the process from memory using Scylla. Navigating through the binary in IDA, you’ll see calls to undefined pointers all over the PE.
These pointers are parts of a table that is populated by one of the first subroutines to be called (addr: 0x004052B0).
Lets rebuilt the IAT
- locate one of those calls to an undefined pointer and keep the address of the pointer (eg. 0x0041B80C)
- execute the “sub_4060EF” subroutine to resolve and populate those pointers with the appropriate values
- go to 0x0041B80C inside the dump windows of x32dbg, right click and select the “Address” view mode
- scroll up and find the header of the table. (the red address indicate data has been written and can be used to find the header of the table)
- open Scylla and write the address of the header (0x0041B630) in the “VA” field
- the size of the table can retrieved by double clicking on the address column from x32dbg and scrolling to the bottom of the table. this will show the relative offsets of each entry of the table and can be used as a size
- Press “Get Imports” from Scylla and delete any invalid entries (if any)
- Fix the previous memory
Voilà! You now have an unpacked Sodin sample. This unpacking technique can be used to save critical time when working with malware, shouldn’t take more than a few minutes to do after properly understood.