Log in

View Full Version : Automated Imports Reconstruction


Admiral
January 3rd, 2005, 15:14
I was reading into IAT reconstruction of Armadilloed binaries recently when I came up with an idea I haven't been able to shake since. I'm fairly sure that I am misunderstanding something or other and so I don't want to go to the effort of coding the following dumper/fixer without being at least nearly sure that it won't be a total waste of time.

As I understand it, the IDATA section is a part of the (disk) executable header that tells the operating system which DLL imports to load, and the IAT is the part of the (memory image) header into which the OS loads all of the addresses. Many modern packers will pack the whole subject file including the header, and when executed, will unpack the whole file, step through its IDATA section filling in the IAT manually before/while destroying all the evidence in the IDATA area.
If this isn't right so far, then perhaps I have the wrong end of the stick entirely.

My problem is the apparent simplicity with which this IDATA section could be reconstructed. My conceptual panacaea program would attach itself to the target app once it has been unpacked; dump the relevant sections, then scan the code area for CALL commands that point to memory locations known to be imports. It will keep a record of all such CALLs, noting all relevant details before going on to redirect them in the dump as necessary and manually adding the entries into the IDATA section of the dumped PE header. Failing that, more elegant examples exist in which the app is loaded as a debugged process and all calls to LoadLibrary are logged etc etc.

If this was possible then surely somebody would already have implemented it, so what am I missing?

evlncrn8
January 3rd, 2005, 15:30
a lot.. you're missing how you'll handle dll forwarding, exports with diff names but at the same addresses etc etc.. it is possible to make an automated iat/it rebuilder, some including myself have done it, but it aint quite that simple

JMI
January 3rd, 2005, 16:07
Nothing in life is "quite that simple."

Regards,

Admiral
January 3rd, 2005, 16:09
Guess I'd better get reading then

CrackZ
January 3rd, 2005, 16:30
Hiya Admiral,

Your idea is one of those that sounds great in concept but doesn't work exactly in practice, and I'll tell you what, I recommend you actually code it ;-), (as I myself did a long time back), it'll teach you more about import rebuilding than any tutorial ever can.

The problem is the forever ending game of cat and mouse that you play with protectors, the Armadillos of this world I'm thinking (although there are a few others), you'll probably find your panacea app is actually able to defeat many of the easier packers out there.

As an example, I once thought that hooking GetProcAddress() at system level would be a really good idea, then along came the protector who now looks up his import addresses directly.....You find ways, they find counter measures, the only way you stay ahead it seems is not to share information or your tools.

Now I'm going another way, an instruction decoder/tracer with *tricks and hacks* (probably a lot of people have done similar).....Nothings ever perfect, I wanted a tool for me that did the majority of the boring stuff for me, not everything for anyone, thats where most of the existing tools fell down, they tried to do 'everything' and attracted users who didn't care for the details.

Regards

CrackZ.

cRk
January 6th, 2005, 11:29
Nice truly Comment CrackZ

Regards

Admiral
January 11th, 2005, 09:15
Cheers for the wise words, all.

I think I will try to write an auto-unpacker for something simple first, UPX perhaps. If I have any success I'll move on to bigger and better things, one step at a time.

Take it easy
Admiral