Exetools - SVKP 1.32 import problems

Exetools (https://forum.exetools.com/index.php)

- General Discussion (https://forum.exetools.com/forumdisplay.php?f=2)

- - SVKP 1.32 import problems (https://forum.exetools.com/showthread.php?t=3877)

SVKP 1.32 import problems

I'm having some problem resolving all the imports in this new version.
It seems the ImpRec svkp plugin just doesn't work anymore and I'm not to good at understanding the disassembled functions.

After Trace Level 1 I have 17 unresolved pointers.

I have protected one of my own apps, but if you wanna check it out I have found that DAP 7.1 has the same protection.

Regards
SvensK

Has it occurred to you to try to determine just what the heck these "17 pointers" are pointing to? They point to something, don't they?? Why not check them out.

If you ever want to learn manual unpacking, you eventually need to stop depending on ready made tools and actually learn how to trace an import table jump and learn what it is supposed to do and what the ones in your target are actually doing.

You said you have protected "one of your own apps" with the protector. Has it occurred to you to "compare" the import table of the app "without" the protector to what it looks like "with" the protector????? Doesn't that seem like a good place to start???? Afterall, they have to have the "same" calls to the API's as the original and, if there are some extra, you would even know where they came from.

Regards,

Nice, not a half-bad idea. Too early to consider the basics.

Edit: Well, well, well... that did the trick :)

Hi,
I'm having trouble with imports too :/
I've been trying to unpack certain app for whole day now. I got dump, eop, i think stolen bytes are good but program crashes. Tracing through exe that crashes i noticed that i didnt resolve one (for now) import correctly. Now i attempt to resolve it correctly by debugging packed app. I run packed app, break on place where this function is called and trace into it. It was very weird. Seems that whole function is in packer code. It never jumps/calls real dll. Btw this is kernel32 function. When function is executed only eax changes and before function executes eax is address inside code section (something like 4xxxxx). BUT result doesnt seem to be parameter dependent. Here is some code (this is some really obfuscated shit):

Code:

00C69B75   9C               PUSHFD

00C69B76   55               PUSH EBP

00C69B77   E8 00000000      CALL 00C69B7C

00C69B7C   5D               POP EBP

00C69B7D   81ED 7C9B0100    SUB EBP,19B7C

00C69B83   50               PUSH EAX

00C69B84   60               PUSHAD

00C69B85   8BEC             MOV EBP,ESP

00C69B87   55               PUSH EBP

00C69B88   29F6             SUB ESI,ESI

00C69B8A   0FBDF6           BSR ESI,ESI

00C69B8D   B9 6E990020      MOV ECX,2000996E

00C69B92   31D2             XOR EDX,EDX

00C69B94   D1C1             ROL ECX,1

00C69B96   29DB             SUB EBX,EBX

00C69B98   D1CE             ROR ESI,1

00C69B9A   29C0             SUB EAX,EAX

00C69B9C   29C3             SUB EBX,EAX

00C69B9E   81EB 9942F43E    SUB EBX,3EF44299

00C69BA4   C1C3 03          ROL EBX,3

.

.

.

and goes on like that.... and then:

Code:

00C69BF3   89E1             MOV ECX,ESP

00C69BF5   81F0 FFFFA262    XOR EAX,62A2FFFF

00C69BFB   01C8             ADD EAX,ECX

00C69BFD   39F3             CMP EBX,ESI

00C69BFF   7E 01            JLE SHORT 00C69C02

00C69C01   F7DB             NEG EBX

00C69C03   FFD0             CALL EAX

where EAX is address in other part of packer code :/ This is all that happens there:

Code:

0012FEC4   8BE5             MOV ESP,EBP

0012FEC6   61               POPAD

0012FEC7   58               POP EAX

0012FEC8   8B85 87AB0100    MOV EAX,DWORD PTR SS:[EBP+1AB87]

0012FECE   5D               POP EBP

0012FECF   9D               POPFD

0012FED0   C3               RETN

So eax gets value of [EBP+1AB87]. What API could this be? It's really annoying :/

what you just described there sounds like your standard (and old trick i might add) way of handling some apis that always return a specific value into eax. such as GetCommandLineA, GetVersion, GetVersionExA, GetModuleHandleA, and others. why not do a reference lookup to something that writes to [EBP+1AB87] and you should find your answer.

I had discussion about unpacking svkp dap 7.1 on _http://forum.accessroot.com/, some time ago.

@bollygud: I figured that out myself but thought that someone knows if SVKP has this wrapping for a one same api always.
From britedreams link i figured out that this api is MessageBoxA (and still it is very strange to me) but that i "inline patch to read the region c50000"
If i got this correct i need to add this code to unpacked exe. Well, i did. I made new section and put that SVKP code there but exe crashes again :/
So, correct oep, correct api, correct bytes, good dump, packer code... what i need to do more? This cant be this hard....

btw messageboxa api passes when i add c50000 section but it crashes elsewhere. Anyone want to look at my exe?

don't make new section , just use virtualAlloc to allocate the space needed then read the saved region back.

if you have changed the jmp I had referred to in the link above , please don't cut the invalid apies in importrec , fix the iat ignoring the msg.,if you are adding the region as I indicated.

Regards.