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

[JMI]

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

[nikola]

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):

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:

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:

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.

[britedream]

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

[nikola]

@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?

[britedream]

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.