Zoom Player Professional v3.00 is packed with UPX and scrambled. So I used jmp eip command in SI to froze the .EXE on the OEP, after which I dumped it and fixed the OEP. The dumped .EXE would however only run when I run SI in the background. Strange! No difference if I dump it with ProcDump v1.6.2 or LordPE Deluxe v1.41.

When I start Win98SE or WinXP without SI in the background, the unpacked EXE terminates after entering. In Win98SE I get this error message after termination:
Runtime error 216 at C01A2349.

So I tried to debug it with OllyDbg v1.09, but there I can't give in the jmp eip command. I tried it with the assemble command, but then it says something about an Unrecognized operand.

Someone has any idea to solve this?

TIA

Hi!

When you are at OEP in Olly the program IS paused. So you can just go ahead and dump it.
(No need to insert any code.)

/Manko

i had a look at the oep, right after them is call to an well known anti debugger api.. think

Forgot to tell I tried this already with Olly, but than ProcDump wasn't able to dump... I'll try it with LordPE now.

Yep, dumped .EXE by LordPE is is right!

Also tried again with ProcDump, but EXE still not good. No prob, I'll use the good dumped .EXE.

Thanks

After restarting my pc, again w/o SI, the unpacked .EXE still crashes when I start it...

Dunno which call you mean, but I'll try to find it.

Hi!

You said this was scrambled UPX. Dunno exactly, but does this mean it has destroied IAT? Maybe you have to rebuild IAT, ala ImpREC?

Though, I don't know that it would work even WITH sice, if that was the case...

Exactly what errormessage do you get when it crashes and have you disassembled and looked at the adress in which this occurs?
If you don't know the adress it can be found with for example faults off in sice if you haven't patched it, dr.watson or probably olly... Though, if you use olly, that antidebug api will kick in... I guess probably it is IsDebuggerPresent?

Let me know if this helps, or if you have aditional questions... ?

/Manko

What I mean with scramble is that UPX itself can't unpack the .EXE. But the .EXE runs if I start SI in background. So it seems clear that there must be SI check, but

And I found the IsDebuggerPresent call (0054CC43), but first error occurs at 0054CC30.
I can simply remove the crash by nopping the call to it, and jumping after the debugger check, but that's not enough. It seems I overlook something. Again any idea?

Btw here's the asembling list for the unpacked .EXE, where I noted the crashed and the debugger check.

---

//******************** Program Entry Point ********
:0054CC18 55 push ebp
:0054CC19 8BEC mov ebp, esp
:0054CC1B B909000000 mov ecx, 00000009

* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|:0054CC25(C)
|
:0054CC20 6A00 push 00000000
:0054CC22 6A00 push 00000000
:0054CC24 49 dec ecx
:0054CC25 75F9 jne 0054CC20
:0054CC27 51 push ecx
:0054CC28 53 push ebx
:0054CC29 56 push esi
:0054CC2A 57 push edi
:0054CC2B B828C75400 mov eax, 0054C728
:0054CC30 E843A6EBFF call 00407278 // <- crash
:0054CC35 33C0 xor eax, eax
:0054CC37 55 push ebp
:0054CC38 680CD35400 push 0054D30C
:0054CC3D 64FF30 push dword ptr fs:[eax]
:0054CC40 648920 mov dword ptr fs:[eax], esp
:0054CC43 E8B0FAFFFF call 0054C6F8 // <- IsDebuggerPresent?
:0054CC48 3C01 cmp al, 01
:0054CC4A 0F848C060000 je 0054D2DC
:0054CC50 B8C0015600 mov eax, 005601C0

* Possible StringData Ref from Code Obj ->"OUJdf/tzt"
|
:0054CC55 BA24D35400 mov edx, 0054D324
:0054CC5A E8C981EBFF call 00404E28
:0054CC5F A1C0015600 mov eax, dword ptr [005601C0]
:0054CC64 E85784EBFF call 004050C0
:0054CC69 8BF0 mov esi, eax
:0054CC6B 85F6 test esi, esi
:0054CC6D 7E23 jle 0054CC92
:0054CC6F BF01000000 mov edi, 00000001

---

* Referenced by a CALL at Address:
|:0054CC30
|
:00407278 53 push ebx
:00407279 8BD8 mov ebx, eax
:0040727B 33C0 xor eax, eax
:0040727D A3C4E05400 mov dword ptr [0054E0C4], eax
:00407282 6A00 push 00000000
:00407284 E82BFFFFFF call 004071B4
:00407289 A368965500 mov dword ptr [00559668], eax
:0040728E A168965500 mov eax, dword ptr [00559668]
:00407293 A3D0E05400 mov dword ptr [0054E0D0], eax
:00407298 33C0 xor eax, eax
:0040729A A3D4E05400 mov dword ptr [0054E0D4], eax
:0040729F 33C0 xor eax, eax
:004072A1 A3D8E05400 mov dword ptr [0054E0D8], eax
:004072A6 E8C1FFFFFF call 0040726C
:004072AB BACCE05400 mov edx, 0054E0CC
:004072B0 8BC3 mov eax, ebx
:004072B2 E8A5D7FFFF call 00404A5C // <- crash
:004072B7 5B pop ebx
:004072B8 C3 ret

--

* Referenced by a CALL at Address:
|:004072B2
|
:00404A5C C70514905500CC124000 mov dword ptr [00559014], 004012CC
:00404A66 C70518905500DC124000 mov dword ptr [00559018], 004012DC
:00404A70 A340965500 mov dword ptr [00559640], eax
:00404A75 33C0 xor eax, eax
:00404A77 A344965500 mov dword ptr [00559644], eax
:00404A7C 891548965500 mov dword ptr [00559648], edx
:00404A82 8B4204 mov eax, dword ptr [edx+04]
:00404A85 A330905500 mov dword ptr [00559030], eax
:00404A8A E8C5FEFFFF call 00404954
:00404A8F C6053890550000 mov byte ptr [00559038], 00
:00404A96 E861FFFFFF call 004049FC // <- crash
:00404A9B C3 ret

---

* Referenced by a CALL at Address:
|:00404A96
|
:004049FC 55 push ebp
:004049FD 8BEC mov ebp, esp
:004049FF 53 push ebx
:00404A00 56 push esi
:00404A01 57 push edi
:00404A02 A140965500 mov eax, dword ptr [00559640]
:00404A07 85C0 test eax, eax
:00404A09 744B je 00404A56
:00404A0B 8B30 mov esi, dword ptr [eax]
:00404A0D 33DB xor ebx, ebx
:00404A0F 8B7804 mov edi, dword ptr [eax+04]
:00404A12 33D2 xor edx, edx
:00404A14 55 push ebp
:00404A15 68424A4000 push 00404A42
:00404A1A 64FF32 push dword ptr fs:[edx]
:00404A1D 648922 mov dword ptr fs:[edx], esp
:00404A20 3BF3 cmp esi, ebx
:00404A22 7E14 jle 00404A38

* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|:00404A36(C)
|
:00404A24 8B04DF mov eax, dword ptr [edi+8*ebx]
:00404A27 43 inc ebx
:00404A28 891D44965500 mov dword ptr [00559644], ebx
:00404A2E 85C0 test eax, eax
:00404A30 7402 je 00404A34
:00404A32 FFD0 call eax <- crash the eightest time when EAX=40FFEC

* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|:00404A30(C)
|
:00404A34 3BF3 cmp esi, ebx
:00404A36 7FEC jg 00404A24

* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|:00404A22(C)
|
:00404A38 33C0 xor eax, eax
:00404A3A 5A pop edx
:00404A3B 59 pop ecx
:00404A3C 59 pop ecx
:00404A3D 648910 mov dword ptr fs:[eax], edx
:00404A40 EB14 jmp 00404A56
:00404A42 E91DFAFFFF jmp 00404464
:00404A47 E850FFFFFF call 0040499C
:00404A4C E827FDFFFF call 00404778
:00404A51 E876FDFFFF call 004047CC

* Referenced by a (U)nconditional or (C)onditional Jump at Addresses:
|:00404A09(C), :00404A40(U)
|
:00404A56 5F pop edi
:00404A57 5E pop esi
:00404A58 5B pop ebx
:00404A59 5D pop ebp
:00404A5A C3 ret

---

and so on...

Ok go in you call eax, look around you will see some jumps to apis

I bet one APi is wrong or maybe not imported in the IAT. Trace your code with F7 in sice or other debuggers. Step IN the calls and not over and mark where exactly your app crashes.

/away to look some ManchesterUnited game

I just paused with ollydbg on oep and dumped it with lordpe. After that I fixed the IAT with imprec and everything ran fine. Offcourse the isdebuggerpresent test must be patched but then it's a piece of cake...

Off topic:

This baby uses the DCPcrypt(free with Delphi source code, hyyp://www.cityinthesky.co.uk/cryptography.html) to do the keyfile check. The algorithm includes RC4, blowfish, twofish etc. according to TMG's nfo. Actually, we can search for "TDCP_" in its exe to locate the algorithm name or use IDA sig to identify it.

Hi,

like Shoob and Iwarez told you, the only anti-debugger is the one you mentioned (IsDebuggerPresent). I think (correct me if I am wrong) your problem is related with the IAT. You can follow the method used by Iwarez or you can simply copy the original IAT above the IAT of the dumped file. If you want you can only copy all the thunkRVAs...

ZaiRoN

After I did this, it works in WinXP, but not in Win98SE. In Win98SE I get a error message that the unpacked .EXE file is linked to missing export KERNEL32.DLL:RestoreLastError.

If I try same procedure in Win98SE (Olly - ProcDump or LordPE - ImpREC) IAT is not completely restored (3 "invalid" addresses). I tried Tracer Level 1 on the first invalid adress, and now there are no invalid addresses anymore and I could fix the dumped .EXE.

However, after restarting my pc, the unpacked .EXE crashed again. Does this mean that it's not possible to make a good unpacked .EXE which can run in Win98SE?

Hi!

Have you checked what the author says about compatibility, or maybe you even downloaded a w2k/xp version?

/Manko

I did, but nothing about that. Also the uncracked worked in Win98SE even as the cracked one EAT and with the right keyfile made by TMG keygen. So I think it's only the dump/IAT process that causes the prob.

Did you by any chance LOOK at the unresolved IAT addresses with a debugger? +Spl/\j has written several small threads about how to follow the address back to the "true" API or eliminate it altogether. I also remember some threads where it was reported that after a rebuilding, the "repaired" exe would not work on other OSs.

If it works without your fixes, it should work AFTER your work, IF you fix it correctly. I don't have time this morning to find those threads for you, but if you can't find them yourself or someone else doesn't post the method for you, I'll find them and post again after I get some real world work done.

Regards.

No, I didn't look at the unresolved IAT addresses with a debugger. And also I can't find +Spl/\j threads. Would be great if someone can help to work this out. Very interesting...

Why do I have to do all the work? I know we are having some problems with the search function, but if you put "+Splaj" in the right hand button you will get all the threads in which he posted. I just took a quick look as some and found this comment:
*****
The public release of ASPR1.2x plugin that fits Imprec/RV worked for a long time.

This is a delphi 'bloatware' dll , but a packed version. Currently it does NOT resolve the latest Alexey trick to shake off API tracers :-

001F3500 kernel32.dll 01DC GetVersion <-WRONG should be GetCommandLineA

If you un-assemble that redirector call in SI you'll see wtf gives
*****

What he is suggesting is that you LOOK at the address given in the IAT and use the "U" command to see what the address is pointing to and go there and examing the code there and maybe "U" a new address shown there. These "re-directions" are usually together in a section of code and you need to study it. Eventually it will "re-direct" back to the proper API.

This is all I have time to do for you at the moment, but again if you "follow" the code, by which I mean go to the address, at the IAT, it has to eventually lead to the correct API, even if the ready made "tools" don't find it for you on autopilot. This is what your brain and a debugger are intended for.

[Edit: Here's one of the thread I had in mind which explains how you go from the address in the IAT to the re-directed API:
http://www.woodmann.net/forum/showthread.php?threadid=2603]

Regards.

Hi

This looked very interesting so I had a go at it.

Found the same OEP and then run our old friend TRW, broke and suspended the program, dumped with LordPE and changed the EP.

Ran it again with no debugger present and found all the API's with revirgin, generated the BIN and all worked fine. Then ran the "dumped" program and did the same with Imprec and it runs on ME 98[2] & 2000!

If you change section flags look at it with WDASM and you will soon find the rest!

/hobferret

Ajo,

Normally i didn't encounter problems with upx-ed files till i tried
to unpack on w XP.
On w 98 i unpacked it the prob without any difficulties but on XP my dumped.exe simply refused to load in si.(safety of XP??)
I rebuilded the import table pasted and quess,,,it runs smooth.... .
Strange i thought upx didn't scramble the imports...




SpeKK.

No, but I think it does affect the IMAGE_IMPORT_DESCRIPTOR structure in some way, if you look at a dumped upx file in a PE editor the imports don't usually show up correctly. The file runs fine, presumably because the import addresses are now hardcoded in since the PE loader has already done the job of that before dumping, but their identification is still wrong. It's a matter of aesthetics if you want to fix it. Maybe on XP this is a factor, or the upx version is modified.

Kayaker

The NT/2000/XP loader is much more picky with having correct PE-structure in the exe files it approves of loading, so this is probably it, yes. But you probably still don't want to have a file with hard-coded API addresses. As soon as you change computer, or even just apply a service pack or update some components in your current computer, it might stop working anyway.


dELTA