2
votes

I've succeeded in unpacking a file using OllyDbg and fixed the dump with ImportRec, but I still cannot find the OEP.

When I load the file with OllyDbg, I first see these instructions (see screenshot "EP" enter image description here):

CALL unpackme.00401931
MOV EAX,8C603
POP EBX
ADD EAX,EBX
JMP EAX
DB CA
DB 96 

These are the algorithms, that I have already tried: 1. Plugins -> OllyDump -> Find OEP by Section Hop (both Trace into and over). I end up at the following code (see screenshot "OllyDump" enter image description here):

0048DF34 CALL unpackme.0048DF39
0048DF39 POP EAX
0048DF3A PUSH EBP
0048DF3B MOV EDI, EAX...
0048DF47 ...JMP SHORT unpackme.0048DF4E

Dumping here doesn't create an unpacked file. 2. Placing "hr esp-4". I end up with the following code (running several times by pressing F9, see screenshot "HR1" enter image description here and "HR2" enter image description here- after EAX follow dump):

00490B50 POP ESI 
00490B51 POP EBP
00490B52 JMP EDI (here the program was paused)

Following Dump at EAX (which at this point stores value 00400000) I see an MZ header. But when I open the file in ImportRec and define the OEP as 90B52, it says that it could not find anything at this OEP. However, it lists all imports (advapi, comctl, gdi, kernel, oleaut, rpcrt, shell32, shlwapi, user32, wininet, ws2_32, ole32). When I load this unpacked file with OllyDBg, it says "Module 'unpacked' has entry point outside the code (as specified in the PE header). Maybe this file is self-extracting...", and when I press "OK", I stop at

00490B50 POP ESI 
00490B51 POP EBP
00490B52 JMP EDI (here the program was paused)

EDIT: I changed OEP in the OEP field in ImportRec to 0003A586 (absolute - 0043A586, address to where the JMP instruction jumps) and then open the unpacked file with Olly and see this: screenshot HR3enter image description here. Does it mean, 0003A586 is the OEP? 3. Setting breakpoint at "VirtualAlloc" just didn't work, it was never hit. 4. Setting breakpoint at "ZwAllocateVirtualMemory" would work partly, the bp was hit several times (when different dlls were loaded). I stopped at different places, but OEP was never good (however the file was unpacked). For example, when I've dumped the process from EAX at comctl_1 (address 7CA27320), the file was unpacked, in ImportRec I saw 4 dlls, but OEP is still not right. It's obviously not a user-code, but some (may be malicious) library. See screenshot "AllocVirtMem" enter image description here 5. Searching for POPAD, soon followed by unconditional JMP didn't work. (see screenshot "POPAD1enter image description here"). First of all, there is no JMP soon after, second, when bp's set here, code stops with a message at the bottom "Access violation when reading" (see screenshot POPAD2 enter image description here). 6. GetProcAddress bp didn't work either.

My question is: what are other techniques with this file that I can apply? What haven't I already tried? I've searched all through the internet, and couldn't find anything. You help would be very much appreciated!

1
Actually, the second way appeared to be correct.ShHolmes
I'm voting to close this question as off-topic because it belongs on the reverse engineering stack.David Hoelzer
I'm voting to close this question as off-topic because its about reverse engineering and Stack Exchange has a forum for that.karlphillip

1 Answers

0
votes

From your screenshots, the correct OEP is at the address 0043A586 (from this address, look around you see the API call GetVersionExA), you could set a hardware breakpoint there, F9/Shift+F9 till this breakpoint is hit, then you're at the OEP of the unpackme.