imports are easy to fix

Well I read post at openrce posted by blabberer in X-Code thread here at woodmann (http://www.woodmann.com/forum/showthread.php?t=10635) and saw interesting discussion between Rolf Rolles (waz up man ) and Kris Kaspersky debating which way of generic fixing is better. Kris votes for adding loader, but Rolf likes clean import to have good disasm in IDA. Infact I had this same problem a few months ago, it was easy to locate all APIs and add loader, who cares, app works, well it works and you don't have to analyse it as long as registration scheme is located in the wraper, but what if registration is located in program itself and you have to analyse it? It would be mess and boring task in IDA not seeing real APIs Basically that small discussion was inspiration to write this blog post

Look at this messy fixed import. It looks like, for example, armadillo shuffled IAT or maybe ActiveMARK v6.xx fixed IAT. But take a closer
look where are APIs located:

According to PE specification OriginalFirstThunk points to API names, but if it is 0 then FirstThunk is pointing to API names, also FirstThunk is used to know where to store API addresses.

So what we shall do to make this concept work?

1. Build OriginalFirstThunk such that it only points to one API name
2. place RVA in FirstThunk where we want API loaded
3. When import table is built simply walk firstthunk and set it to
specific value != 0 as windows loader will deny loading image if
address to which FirstThunk is pointing is 0. Weird?! I didn't find
anything in PE specification about this behaviour

Lets see some code snipets from this library which you may find in src of my GenericUnpacker and import engine at http://deroko.phearless.org

When this small loop is done, all we have to do is to walk all first_thunks and set them
to != 0 so win loader can actually load this import table.

With this concept you don't have to write sorting algos to get nice and clean IAT, who
cares where are APIs located. In my, aspr2.3 dumper for example, I scan original code
for APIs that are not stolen, then I go for stolen APIs and write them into array
and I don't care if I have something like this:

MessageBoxA
GetModuleHandleA
RegOpenKeyExA

etc...

After this is done, then I go for APIs located in poly oep, or other stolen procedures
which are located in markers. At this point IAT looks like nightmare and importrec nor
any other public known engine can fix this IAT... But 1API = 1IDD concept fixes this
without a problem!!!

Think about it when writing unpacker and protection developers think too when
you try to make "hard" IAT to stop importrec, you will lose one way or another
Remember that not many people are using it lately

Last edited by deroko; October 23rd, 2007 at 11:55.
Reason: keep it upto date with edited blog post :p