I wanted to learn something about unpacking malware manuelly and found the following link:


As you can see, the malware in that example begins with the PUSHAD instruction. (I thought it would be a good link because 2 days ago I started to analyze a malware which begins with the same PUSHAD instruction. It was also packed with UPX like the malware in that example of the given link)

So, I downloaded the malware of the example for testing purpose.

What I did:

When I step into PUSHAD instruction(pressing F7), double-clicking ESP in combination with "Following in Dump", then I choose the first 4 bytes of the first row (ESP address) in the hex window. Then I go to Breakpoint -> Hardware, on access -> Dword. Then F9. (I hope I could explain it right but you can be sure that I did exactly the same things as in the example of the link)

My problem:

The first thing:

After I click ESP -> "Follow in Dump" , the 4 bytes of the first row looks like this: 00 00 00 00. (So, only zeros. Not the same like in the example which was 08 02 91 7c as you can see)

The second thing:

When I choose the 00 00 00 00 -> Breakpoint -> Hardware, on access -> Dword, then I let it run (F9) but the malware does not run to a location where I can find POPAD or JMP .... as in the example. In my case, after all that it runs to a location (especially, running ends in a LEAVE instruction) with the following:

   CALL DWORD PTR DS: [<&ntdll.RtlRaiseException>]
   LEAVE                                             <----- here, it ends
   RETN 10

So, even if I scroll hundreds of lines upwards or downwards, I could not find a POPAD instruction.

My question:

Why it is so? Do I need to configure something in the ollydbg settings ?

I hope someone can help me in that case, because although I do the same steps as in the example, I have different results.

best regards,

  • 0. What OS do you have on research machine? 1. Restart the Olly session and you should break on 0x424231. 2. Note the EDI register, before execution pushed. 3. Do you see, that EDI has 7c910208? 4. In addition, scroll down from 0x424231 and you should find popad at 0x424386. – PhoeniX Jan 12 '15 at 8:49

Your mistake is that you put the breakpoint while being on the PUSHAD instruction (meaning it wasn't executed yet).

I just unpacked the file, and this is how you do it:

1. Drop the file in Olly and find the PUSHAD instruction

Simply do what you did before, and end up here:

Step 1

2. Step once to skip the PUSHAD

Now, you got everything pushed, and the decompression can start.

Step 2

3. Put a breapoint on the stack

Now, you've arrived to the point where the stack looks like:

## original ESP
## some register's value
## some register's value
## some register's value
## ...
## you are here

Now, on the you are here point, the decompressor uses the stack, and it grows downwards (to lower addresses). When it is done using it, it clears the stack, and reaches again your original ESP point, where the popad instruction writes, and which is what causes the breakpoint to hit.

4. Run

Pretty much self-explanatory. You'll end up here after running:

Step 3

5. Step again

Done, you found the OEP!


Now you can dump. I used OllyDumpEx: OllyDumpEx

Simply click Get EIP as OEP while being on the PUSH EBP instruction, and then dump: (also write down the EIP1) dump fix OEP

6. Fix IAT

Now, you want to fix the IAT to properly see the used APIs! Do not close Olly and don't step, just dump and leave it as is.

Open ImportREC, pick the process, and press IAT AutoSearch, then Get Imports.

IAT fixing

Sometimes it may not find the OEP automatically, so just take the OEP you found before1, put it there, and click IAT AutoSearch and then Get Imports again, and then dump.

7. Taking a look at the file in IDA

Now you can analyze the file.

This is how it looks like when manually unpacked:


And this is how the UPX unpacked (upx -d) version looks like:

upx unpacked


As you mentioned, UPX was used and it can be unpacked by UPX itself see this example. To address scrolling to find the entry point, its because you are in a different module loaded by the binary. You're probably getting into ntdll.dll module disassembly.

  • the question clearly stated that the user wanted to unpack manually so the tool for unpacking is not really relevant. – PhoeniX Jan 12 '15 at 8:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.