UPX Unpacking Issues

I'm trying to unpack two different versions of an application to find out how it generates checksums for the packets it sends.

The packing is identified as UPX by PEID.
The unpacking proccess only runs properly when the isDebuggerPresent flag is modified/hidden, so it may not actually be UPX.

Anyway. I set memory access break point at the "code" section and the first line of code it breaks on is a call to LoadLibraryA, so I continue past a few security checks and it jumps into the OEP.

At this point, I dumped it using Ollydump and Imprec can be used to fix the tables.

It worked fine on the first version, but it *didn't* work properly on the second. So I'm not sure what I'm doing wrong.

In the latter version's dump, most of the imports show as YES (Valid) in Imprec, but there are three imports that show NO (Invalid).

If I try trace level 1, they point to some Kernel import, but the resulting fixed dump does not run.

The first version's dump on the other hand has all Valid (YES) imports and it runs/executes perfectly after being unpacked. The three "invalid" imports are there but they are marked as Valid.

How can I resolve the three invalid pointers in the later version? Any help would be appreciated.

Did you try using the import table from the first version in the second one? Usually minor version updates don't involve changes in import table.

Furthermore, try to debug the second dump, finding the point that make it crash.. or mabe there's a crc check.

it cant be upx due he doesnt have any antidebug, also doesnt destroy iat, exe is perfectly 100% same as unpacked only unneded things are striped, so rdata where iat is, is same as in not packed version. so check better. maybe its some upx scrambler etc. you can recognize upx by section names and UPX! and ver 2.01 or other, some people remove names and ver to fool you. like curerom
but use cfe to change section name to UPX0 UPX1 and add in winhex 2.00 UPX! and upx -d unpacks perfectly.
you can also recognize upx by his EP code like this

00982950 > 60 PUSHAD
00982951 BE 00407B00 MOV ESI,MPC.007B4000
00982956 8DBE 00D0C4FF LEA EDI,DWORD PTR DS:[ESI+FFC4D000]
0098295C 57 PUSH EDI ; ntdll.7C910738
0098295D 83CD FF OR EBP,FFFFFFFF
00982960 EB 10 JMP SHORT MPC.00982972

Thanks for both of your comments, the import address table was invalid because the process makes certain API calls only after modifying the kernel with a driver.

Imprec's level 1 trace worked, but it didn't seem like it was executing because "ExitProcess" gets called after it checks for a device/driver it unpacks and loads into the kernel on runtime.

It is an evil, piece of software.