How to unpack a file using Process Explorer and WinDbg
One of the big issues when analyzing malicious files is that DLL’s and EXE’s are often packed using executable ‘packing’ software. Sometimes this software is well known, other times it is could be a custom compression software which makes it even more difficult to unpack.
While it can be very tedious and difficult to statically analyze a binary that has been packed, by its very nature, when executed the file must decrypt itself in order to execute on the system.
Using the latest version of Process Explorer (v12.04) and WinDbg, I have figured out at least 1 way to dump a DLL or EXE from the system’s loaded memory to a file. This version of the DLL or EXE written back to disk is not the same as the packed original, but is in fact the unpacked version that has been loaded into the system’s memory.
This technique is useful because it allows an analyst to review an unpacked version of the malicious file. Enough background, let’s begin.
In this example, we will be attempting to unpack a potentially malicious DLL. Virus Total currently shows that 6/41 AV Vendors detect this as a Trojan known as Win32.Hiloti.
I copied the file, “ezoyenaxixib.dll” to my c:\temp folder on my sandboxed system. The first step is to launch Process Explorer.
The next step is to actually load this DLL on my sandbox system. Because I was able to capture the registry entry for this file, I know the command it intended to use in order to have the system launch it at logon:
You may receive an error message that rundll32 could not find the entry point named “startup”. This is alright, but do NOT click OK. Doing so will cause rundll32.exe to close and to unload our malicious DLL. If you do mistakenly click OK, then just re-run the previous command.
Notice in the screenshot above that Process Explorer shows “rundll32.exe” as a child of cmd.exe, which we would expect since we launched it from a cmd prompt. Also notice that the command line shows rundll32.exe and our DLL.
Right-click on “rundll32.exe” in Process Explorer and select the Create Dump menu and select Create Full Dump …
For this example, we will save this file to c:\temp\rundll32_hiloti.dmp
Next, click again on “rundll32.exe” in order to highlight it. Now click on the View menu at the top of the Process Explorer Window and select the Lower Pane View menu and select DLLs:
(You also need to ensure that Show Lower Pane is checked). Notice that we now see our malicious DLL in the lower pane view. Go to the lower pane and right click on the malicious DLL and select Properties.
Once the properties dialog opens up, take note of 2 important pieces of information, the Load Address and the Mapped Size. Write these 2 values down if you need to.
NOTE that if you click on the Strings tab and select the Memory radio button, you will see the strings embedded in the unpacked version of this DLL that is loaded into memory. Sometimes this is all you may be looking for, and can quit here.
But, if you’d like to write this unpacked version of the DLL loaded in memory to a file on disk, continue on!
At this point, we can close Process Explorer and click OK on the Rundll32 error dialog box. Next you will need to launch WinDbg, which is part of the freely downloadable Windows Debugging Tools.
Once WinDbg is open, click the File menu and select Open Crash Dump. In this case, I am going to load the crash dump that I created with Process Explorer earlier, and saved to c:\temp\rundll32_hiloti.dmp.
Now, with our crash dump loaded by WinDbg, we can start entering commands (where the red arrow is pointing above). We are going to execute the .writemem command which allows us to write a section of memory to a file. Enter the following:
.writemem c:\temp\unpacked_hiloti.dll 0x10000000 L47000
So what does this all mean?
- Well, c:\temp\unpacked_hiloti.dll is the name of the file we are creating and where this memory is written.
- 0x10000000 is the Load Address of this DLL that Process Explorer gave us.
- And finally, L47000 is the number of bytes to write from memory, which was given to us by Process Explorer. Note that WinDbg requires the prefix “L” when referring to an object value, such as the number of bytes
That’s it! At this point, you can now load the unpacked DLL into your favorite disassembler for further analysis.