Packing and Unpacking:

Malware is often obfuscated and or “packed” to make it harder to reverse and examine. Packing can modify various data sections. When dealing with packed malware you will often need to reconstruct the import section.

In genreal we will want to find the “unpacking stub” which will lead to the OEP Original Entry Point of the executable. From there we can reconstruct the program. The unpacked program will not be identical to the original as the PE header is reconstructed.

For more info on packing see this eariler post: https://saadams.github.io/posts/mal-antirev/

Steps for Unpacking:

Automatic:

1
Use a tool like PE explorer, PEID

Manual:

• Use a debugger to find the OEP then dump the program.
  • OllyDbg has a built in OEP finder in OllyDump
  • Otherwise step through the program to find OEP.
  • Search for the tail jump which is a jump that typically goes far away.

Repairing Imports Manually:

• the imports table is 2 tables in memory:

  • list of names or ordinals used by the loader or unpacking stub to determine which functions are needed.
  • list of addresses of all functions imported.

• Repair each import function as encountered…

  • find unknown import func in IDA look it up in the debugger and then label it accordingly in IDA.

Sample 1

DIE (UPX detected)

Here we can see that the file is detected to have used UPX to be packed.

We can also observe that the entropy is very high which is a good indicator that it is packed.

Due to the fact that this file is using a modified version of UPX we will not be able to simply unpack it with UPX.

Manual Unpacking:

• When the file is opened in IDA it only contains 1 function start and a very small import table.

• Many unpackers use jmp as a means to transfer control to the unpacked code. A search for jmp instructions leaves a few results.

• The one that stood out was a jump at the address 0x409F43 as it jumps far away and to invalid instructions.

• Setting a breakpoint on the address in x32 debugger

• When the program is run again eip is stopped at the breakpoint.

• Single step/step into and the eip moves to the unpacked code. From here the process memory can be dumped with scylla.

• Open scylla and auto search.

• Get imports and then dump

• After the program is dumpped, fix the dump which will make the program analyzable in IDA.

• Re-opening the sample in IDA all the imports and functions now appear and the sample is ready for analysis.

Sample 2

DIE results:

Here we can see that DIE believes the file is packed due to repeating section names.

Lets check out the binary sections to see what is going on.

We can also observe that the entropy is very high which is a good indicator that it is packed.

We can also see that the DOS stub has been modifyed.

This differs from what would we expect to see “This program cannot be run in DOS mode.”

Within PEStudio we can see that the packer used is FSG 1.0.

Unpacking:

• When the file is opened in IDA it only contains very few functions and a very small import table.

• Combing through the binary in IDA a specfic jmp stood out.

This jump while at first it stands out it ends up just being part of a looping call for the function.

However if we follow this call we can see that there is another jump instruction

This jump appears to go to the end of a code section with invalid instructions and it jumps far away from the current addresses of the code being executed. This could likely be a tail jump.

Below we can observe the section the code jumps to.

Lets pick this apart in a debugger and see what is going on. I am going to set a breakpoint on the first address we found as well as the second.

As the program runs you can watch the addresses increase in esi and edi this is likely used with the packing algorithim.

Now im going to jump to the next breakpoint that we marked.

This time the jump is not taken so lets run the program until we see the jump is taken.

Each time we run it we can see a new string stored in edi

Here we can see the jump will be taken.

Lets take it…

Now lets run an analysis in x32dbg using anlaysis > "analyze module"

Then we can pick apart the disasembly and make sure it looks like unpacked code…

Here we can see the functions:

Clicking into sub_401090 which is where our jump took us we can open up a disassembly page and see what it is doing.

After picking around a little bit I found the following:

That looks pretty unpacked to me. Lets dump it and open it up with IDA.

I will be dumping with scylla

Remmeber to use the IAT autosearch first.

You can additionally use fix dump on the dumped file if something doesnt look right.

Now we can work in IDA

Sample 3

DIE results:

Here we can see that DIE believes the file is packed using PE Compact.

pestuido:

We get the same conclusion in pestudio.

Looking in IDA we can see a small ammount of imports, functions and no readable strings.

Auto Unpacking:

Do to this sample using PE Compact we can attempt to unpack it with peid and the generic unpacker plugin.

After clicking the arrow we can see it found a OEP

After unpacking with peid we can open the unpacked binary with IDA and see all sorts of unpacked strings.

We could now continue analysis in IDA or another dissasembler with the unpacked binary.

Manual Unpacking:

Sample 5 (Lab18_05.exe):

LoadLibraryA often used with packed malware.

DIE (Upack like)

High entropy

References/Resources:

• Mastering Malware Analysis by Alexey Kleymenov and Amr Thabet
  • https://www.packtpub.com/en-us/product/mastering-malware-analysis-9781803240244
• Practical Malware Analysis by Michael Sikorski and Andrew Honig
  • https://nostarch.com/malware

• https://learn.microsoft.com/en-us/windows/win32/seccng/cng-portal

• https://learn.microsoft.com/en-us/windows/win32/seccrypto/cryptography-portal

• https://www.aldeid.com/wiki/PEB-Process-Environment-Block/NtGlobalFlag

• https://www.aldeid.com/wiki/PEB-Process-Environment-Block/ProcessHeap

• https://anti-debug.checkpoint.com/

• https://www.jaiminton.com/Tutorials/PracticalMalwareAnalysis/Chapter18/#

• https://www.infosecinstitute.com/resources/malware-analysis/analyzing-packed-malware/