As there are little data about the unpack flow, here is the general approach you should follow in most packed malwares. This will probably be more complicated if we are talking about some custom and sophisticated packers.
I also strongly suggest to avoid various automatic unpacking plugins as they leaving you without the understanding of the process.
So in most cases unpackers (in terms of unpack process) will try to:
- validate their payload
- allocate new memory to store the unpacked code (data). This will (in most cases) be done with the help of
- unpack routing will take the obfuscated code and write the clean one to the allocated space
- at the end of the process transfer control to the payload
What you should try to do:
- place the HW breakpoint on the
VirtualAlloc(Ex) as there are packers which will check the preamble for the BP placements. Press
execute till ret and at the
EAX you will get the allocated memory area address
- right click on the
EAX to follow the address in
- place the
Memory On Write breakpoint or
HW on write breakpoint which should get you to the actual unpack routine
- analyze the flow of the unpack routing to place another breakpoint at the end of the unpack process
- once the unpacking is done, right click on the
Dump windows to save the unpacked payload to the file.
In your case, the payload will probably will not be the clean
MZ file or in contrary, the unpack routing intentionally had crippled the payload.
Probably this will be an iterative process as you also need to validate that the unpacked payload is actually the code. Try to use
- in addition place
HW on Execute at the beginning of the unpacked payload
- dump unpacking routine / area and open it in IDA to understand (find) if there are any control transferring process near by.