I recently used a crypkey protected application that seems different than normal. It can be registered the normal way (using SKW/CKI), but unpacking the program was a bit more of a challenge than normal.

Crypkey programs are, normally, incredibly easy to unpack. However, I could not dump this target using ProcDump or most other dumpers. Further inspection revealed that even before the target reached OEM, there was several memory areas around the process code with state of "Reserved" rather than "Committed". Ended up writing my own process dumper which managed to dump it successfully.

Correcting the section headers went fine, but the import table had been nuked - not something that I remember Crypkey protected apps doing - I even tried running the latest Crypkey Stealth over one of my own programs, but the import table was intact and the process was easily dumpable.

Even stranger, Revirgin couldn't find anything usable most of the time, and dumped out what could only be described as garbage when it did. Imprec found a working table however, but screwed up the section headers of the target when applied to the target. In the end I gave in, and did it manually.

I've managed to successfully get the program working in the unpacked state, but I'm wondering if any else has noticed this with any Crypkey protected apps ? Looking through the original (packed) code it just seemed like standard Crypkey Stealth protection, which you can spot a mile away.

What target are you looking at? Could be interesting to look at it...

hobgoblin

Spectra Audio Analyse RTA 132 v13

See PM.

Not really interested in the target by any means, but it's protection interested me and that's what made me unpack it. Now it's unpacked and working, it'll most likely be deleted

Well, I haven't seen something like this before. The import table can easily be dumped, as far as I can see (using Softice), but I haven't been able to solve the dumping of the file. I have only tried to dump it at different locations. I also tried to partially dump the sections, but couldn't dump all of them.
How did you do that?

hobgoblin

Dump the sections of the program's process space seperately, but miss out the ones with a status of Reserved. Once these sections are concatenated together and a proper section header built for the resulting file, you only need an import table for it to work properly. There's a import table to dump within the process, but only the locations are there - no the function names, so the file will not execute until this is fixed. (Well, not strictly true - the names are there, but the pointers to them have been nuked)

With the strange section alignment used, both LordPE and Imprec both screwed up the PE file every time they were used as they assumed a section alignment of 1000.

I don't think I could have chosen a better program to test my new dumping engine on

Hajo,

You should try lordpe's active dump engine>intellidump>select!

(verry intelli..)

Dumping without a prob.(yep some zero padded locations.
Your oep will be a few instructions before
the jmp....(make shure the right value is pushed(4b002c !)

No need to rebuild the imports, thay are all there
Do not forget to rename your dumped.exe.


Ciao,

SpeKK.

So you got a working dump just be using LordPE's intellidump and fixing OEP ?

uhhhh...i think so ....??

SpeKK.

damn !

Ah well, at least I learned a lot about the PE file structure

Glad i could help


SpeKK.

Aha! LordPE has built in Import-builder for dumped progs, maybe that's why it worked. My own app will dump these and fix the imports too now anyway, so I is happy

Just implemented a nice new feature to it also, it can dump Crypkey "stealth" target, find OEP, rebuild the header so it runs without the encryption wrapper, and then tell you vendor ID, app ID, password etc used so you can enter them in SKW. No more needing to look through dumped file for the hex strings and using ckinfo

This is not working for me. I use the intellidump, and the dumping goes okey. But I think I have a problem finding the right place for the OEP. I have tried to dump from the address 410056 (after the instruction push 4c002c is executed, I have tried to dump it from the jmp instruction just below, but nothing works. I also tried to dump it form the location 4B2230 (which I first thought to be the correct OEP). When I tried all this, the program doesn't even load properly in the Softice loader. Where am I going wrong here.?
A hint would be helpful..

hobgoblin

PS. I did rename the dumped file.

OEP is stored at <have> section, pos 14 in the code. Eg. If section says 5B0000, then OEP will be stored @ 5B0014. A longword upwards (behind the area storing OEP) also stores the section the unpacked program lives in, but we know this is normally the first section anyway.

As for dumping, dump from start of section of first section named "code" with code attribs, this was RVA 10000 on my system, and should be pretty much the same on yours.

Eg. on this particular app, HAVE section is at RVA 1B0000, so OEP is stored at 1B0014, which would be file offset 169014 (hex). VMA is at 1B0010. Don't forget these are stored as intel longwords.

Okey,
I did dump it from the address 5B06F9, but after changing the OEP to what I found (0041000), it still doesn't run. I get the message "This is not a valid ....... program", so I guess I somehow managed to screw up the import table (or header). I used LordPE's intellidumper. I guess I have to look more into the import table.

Thanks anyway,

hobgoblin

Quick way to check the import table: Load resulting dump into LordPE, Click "directories" and then "import table". If clicking Kernel32 shows you function names, then import table is ok. If it only shows addresses, then it needs repairing. Also, don't confuse the import tables! There are two in the resulting dump - one used by the decryption routine (contains very few calls) and one for the actual app (much more calls).

You should be dumping from RVA 10000 upto RVA 1D1000 to get all of the process.

41000 is the correct OEP, but don't forget the section alignment ! If any of your sections violate the alignment, the program will not run, showing the error you describe.

Also, if you are using XP, ensure SizeOfImage is also aligned, or XP will not load it, and will just show the "blah not a valid Win32 blah blah". LordPE seems to corrupt this by using the wrong alignment.