Hi,

Followed the advice in the other thread, now I'm playing with aspack. I've aspacked Notepad and sucessfully found the OEP and dumped it. It of course doesn't run yet, but I've run araxis (compare tool) over it to double check I've got the right OEP. However now I have some questions:

1. It doesn't run because of a broken IAT. To fix this, I believe I have to run the packed notepad, dump the IAT from it, then add it into the one I dumped. I'm unsure how to find the IAT, and how to add it into the dumped notepad.

1b. Is the right way to do this, add a new section to the dumped exe, insert the dumped IAT at the raw offset, then edit the PE to point the IAT to the RVA?

2. The size of my dumped notepad is significantly larger that the original (not the packed one) notepad. Ie roughly: Win2k notepad.exe = 60k, aspacked version = 30k, dumped version = 90k. Why is this?

All replies appreciated. I've searched for some IAT rebuilding help, but most of the tutorials use tools (revirgin etc). I want to do this absolutely manually.

Silver

Have you tried searching for R@dier's tuts, if I remember correctly he did one on Aspack a while back

/hobferret

hobferret, thanks for the reply. I can't find R@dier's aspack tutorial (although I find a few other things by him).

Actually, I don't really need a "How to crack Aspack". I need a generic "Ideas on how to find the IAT after the app has been unpacked, and how to import the good/fixed IAT into the dumped app". When I know the outline, I can work the rest out myself...

It's very frustrating, everything I find just says "use revirgin/imprec"...

**edit. Hold on, am I being incredibly stupid? If I use sice's map32 on it when I've got to the OEP, that will show me the sections. One of those will be the import table, so I can just dump it with /pedump. Is that correct? Still leaves the question of how I add it to the dumped exe though...

There's nothing wrong with using ImpREC to do the hard work for you, letting it construct the IAT and adding a new section.

Yes, looking at the sections is usually a good start, you can usually tell on a lot of targets where the IAT used to be this way. Some protections, however, strip the section names out to screw you.

In that case, what I usually do, is put a BPX on some other API that i know is to be called. Then, just do a RET from that call back into the user code, and you will see where the API was called from. NOw, look at the call [xxxxxxxx] instruction that was in the code. Most API calls are like so:

in the code that calls the actual api:
CALL DWORD PTR[xxxxxxxx]

if you look at the xxxxxxxx in the CALL , it will point to the location of the original IAT. There is no overwriting that, cause it's in the code section. Only very few programs actually try to overwrite the CALL's into the IAT. Only SafeDisc is one that I know of that does.

Also, some programs use a "jump table" - instead of a CALL DWORD PTR they just do a CALL xxxxxxxx, and then at xxxxxxxx, there's a JMP DWORD PTR [xxxxxxxx]. It's the same principle, the JUMP goes into the table instead of the call. In either case, you can find the address xxxxxxxx by stepping thru the API that got called, because it must always return to the original code sooner or later, and then that xxxxxxxx value will point straight to the IAT.

-nt20

nikolatesla20, thanks for the reply, that's helped a lot. I know there's nothing wrong with using imprec/revirgin for this, but I want to do it myself manually a few times just to be sure I understand the process.

From your reply, I see I'm doing the right thing by creating a new section and importing the dumped IAT into it, then modifying the pe to point to it. I have some further questions though.

I know I can identify the end of the IAT by 5 dwords (0x00000000), but how do I identify the start? I understand that those 5 dwords are part of the descriptor struct, and that they appear at both the start and the end of the IAT. The ones at the end will be all 0's, but the ones at the start will not be 0x00000000 by definition, as they contain data for the first chunk.

I can follow the jmp in sice and scroll up from where it lands, but I'm not sure how to make sure I've got the start of the IAT.

Also, maybe I'm missing the point here, but when the exe is unpacked in mem shouldn't there be something that points to the RVA of the good, unpacked IAT? Why can't we locate & use that instead of manually looking for it?

Thanks for putting up with the questions

*bump* anyone able to offer some advice on my msg above (how to find the start of the IAT)?

Silver, I believe the easiest way of finding the IAT is to do the following:

1) At offset 0x3C you find the (DWORD) RVA to the PE header.
2) Now go 0x80 bytes into the PE header and you should see the (DWORD) RVA to the first IMAGE_IMPORT_DESCRIPTOR in the IAT. But remember that this is a virtual adress so you will have to convert it to an offset in the disk-based file. This can be done by opening the file in your favorite PE editor and seeing which section of the file would fall inside of. Then find the raw offset that corresponds to the virtual offset and you're good to go.

You may also want to check out the following tutorial by Yates he explains it in much greater detail and far more eloquently... well I found it quite useful at any rate....

http://its.mine.nu/html/re/essays/Import_Tables.html

Good luck

Why not read the version of the Yates article on the import table which is already located here and found in the link at the bottom of the Forums?

It's at:

http://www.woodmann.com/yates/Import_tables.txt

Regards,

Yes, yes... what JMI said

Thanks guys, that is precisely what I was looking for. Not sure how I missed the Yates one, I think my brain went to sleep after looking through hundreds of tutorials that just said "use revirgin".

Thanks!

You might want to also try something really off the wall and go to your favorite search engine and enter something really daring, such as "import table rebuilding." Just a thought.

Regards,

JMI, try that on Google. The first hit is some tutorial code to do it, the next few pages are junk. Hence my post

Off on holiday for a bit now, back in a few weeks!

Oh, while I think of it, can anyone offer an explanation as to the size difference (my original post question). More accurately:
Original notepad: 49.7 KB (50,960 bytes)
Aspacked notepad: 36.5 KB (37,376 bytes)
Unpacked/dumped notepad: 66.0 KB (67,584 bytes)

About the size issue, my guess would be that the PE section(s) added by Aspack is still left in the file after it's dumped, you must remove them manually. Looking at the PE sections (in the PE header of the file) and their sizes should be able to give you some good clues anyway.