Log in

View Full Version : A simple question concerning an iat rebuilder


tsehp
November 5th, 2000, 18:18
hi,
I'm actually writing a (lame) iat rebuilder in c++. The purpose is to use the IT addresse's put them in a table, take all the modules in mem that target uses , extract their import names, and then compare
by a getprocaddress the result with the entries inside the IT. If the
adresses are equal, write the module and procaddress inside a table, when finished, finally used to generate IAT, IAD and IT.
My question is : is there a more direct way, when you have the import's mem adress to know it's name and module ?
regards.

G-RoM
November 5th, 2000, 18:37
Answer is easy :

There is no other way... BTW ur method has some flaws from the beginning : Some API have no name

Cheers,
G-RoM

notme
November 5th, 2000, 20:28
also, some asciiz's share the same address as others .. like, 2-3 asciiz's in kernel32.dll will return the same api address.. dupes.. which cause the program to have a 99% rebuilded IAT im some cases

dont know any off the top of my head, but they do exist..

kill3xx
November 5th, 2000, 21:05
mem that target uses , extract their import names, and then compare by a getprocaddress the result with the entries inside the IT. If the adresses are equal, write the module and procaddress inside a table, when finished, finally used to generate IAT, IAD and IT.
My question is : is there a more direct way, when you have the import's mem adress to know it's name and module ?
regards.[/QUOTE]

G-Rom has already answered to ur question..

so the following is just to satisfy my own ego

umm AFAIK the only shortcut in (UM) is to let windows find the module name (and imagebase) usign VirtualQuery .. this method is well documented in Ritcher "Advanced Window Programming" if i racall correctly [ eheh it's a long time that i'm out of business ]

best regards,

kill3xx

tsehp
November 6th, 2000, 02:23
First I thank you all for your answers.
g-rom : it's an honor to see you here If I double check with the ordinals, am I sure to have an unique entry ? I would love to see the
source of your *fantastic* phoenix plug-in, but you maybe want to
keep it private and I'll understand why.

notme : So those dupes are some kind of overloaded member functions ? Do you remember if they only differ by the parameters ?

kill3x : very interesting function, I'll just check for that and publish what I found about this virtualquery.

best regards,

tsehp

tsehp
November 6th, 2000, 12:22
Sorry killer3x but I don't get it.
Virtualquery and virtualqueryex just gives into a structure some general infos about the mem protection state (commited/decommited,
protected or not) it gives also the base mem address, pages etc...
But nothing in direct relation with dll's exports names/ordinals.
Maybe I've missed something, but I'm actually taking the option I spoke before :'(
regards,

tsehp

kill3xx
November 6th, 2000, 20:02
Quote:
+Tsehp (11-06-2000 01:22):
Sorry killer3x but I don't get it.
Virtualquery and virtualqueryex just gives into a structure some general infos about the mem protection state (commited/decommited,
protected or not) it gives also the base mem address, pages etc...
But nothing in direct relation with dll's exports names/ordinals.
tsehp


yup.. not directly related with exports.. it's just a shortcut to find the baseaddress and module name given a valid address in the process address space.. let me explain better (umm.. with my crappy english it's hard

when u pass to virtualquery an address that is within a module image.. virtualquery return as mbi.baseaddress = allocationBase the module base addr...

so if u've some this condition:
1) mbi.state != mem_free
2) mbi.state != mem_reserve
3) mbi.baseaddress = mbi.allocationBase

u can assume it's a module image and try GetModuleFileName to find the module name and then use the address to lookup ET.. at this point u've both the ordinal or the asciiz api name...

umm.. i know it sounds crappy.. but it works .. at least it has worked for me sometime ago when i've coded a lame iat dumper..

But again.. this solution is not the bulletproof or the best one.. so simply forget it..
as i've said in my previus post it was only for my own ego

best regards,

kill3xx

p.s. sorry again for my english

G-RoM
November 6th, 2000, 20:33
Seeing source code of Phoenix : Dream about it.

As point out Kill33r, it is true that under 9x, some API point to same address, IE Kernel32.Ord1-Ord9. There is no easy way to get back REAL one. I think I know a method but it involves special code and specific to 9x.

Now let's Speak of NT : u will have to deal with forwarded API... These are nice stuff as well .

What Kill33r gives u with virtualquery is to get ride of ToolHelp32/PSAPI system to list attached DLLs... Advantage is it works uniformally under nt and 9x. Pb is when deal with wrapped API even if u can probably find a workaround.

Btw: this board got a little lack of feature... can't see posts of which I am replying, this is a bit annoying... IE here I have pb to remember exact nickname of Kill33r (sorry buddy if i am wrong).

Regards,
G-RoM

tsehp
November 7th, 2000, 03:04
Thanks again kill3x and g-rom.
To see the post wich you are replying, simply click on reply w/quote.,
this will get back the msg on your reply.
I've read the "under the hood" contributions about another use of virtualquery and imagehelp.dll, using a map file it gets directly the function name, but it's useless in our case, we dont have debug info.
So I'll do it the hard way, I've already created the process and module
browser, I'll do a getprocaddress on all the exports present in the modules related to the process :'(
Just to ease my work, do you know about the existence of pre-defined
c++ classes concerning the pe-format ? Not the ones inside windows.h
off course, but more newbie-oriented ones ?
TIA,

tsehp

el.caracol
November 8th, 2000, 18:04
Hi +Tsehp,

first of all: excuse-me for my very bad english !
(I'm French and I have used an electronic translator to write this message..)

Well, I also worked on Asprotect and I followed with much interest your essays on the call fixer and import table rebuilder.

For my part I had already put in practice the idea consisting in finding the function name and the DLL name starting from its address mem. It is a very simple idea, which has certainly weaknesses, but I can ensure you that it goes! (works fine).
Two months ago, I developed a (lame) tool prototype (with Delphi 5) based on the (nearly) same idea, which makes it possible to examine the IAT of a dumped prog, to visually detect "abnormal" IAT, to facilitate the validity of an IAT call fixer, and especially to rebuild a new import table.

(I recently worked on a program Asprotected v1.1: "AZPR351" (elcomsoft), and I dumped it, call-fixed and rebuilded Import Table without any problem :-)

Well, i will not explain in detail how works the prototype, but here is the essential points :
- from files containing the names of the export functions for each DLL (ie: 'kernel32.txt'), it builds a directory of these functions with the addresses corresponding to your system (with getprocaddress).
- It use these directories to solve the IAT adresses contained in the executable target and create a file called 'addr-FunctResolved.TXT'
- finally it use this text file to rebuild an Import Table (of Borland type) directly in the executable dumped, according to the parameters specified by the user.

some details :
It is preferable to work on programs dumped with Raw Offset and Virtual Offset aligned.

The design of the prototype enables you to solve the IAT on a dumped program (even incomplete) and rebuild an import table on another dump of this same program (dump complete).
(look at the example on Notepad Asprotected on "Caracol-Readme.doc".

The rebuilding of the IAT only starting from the txt file 'addr-FunctResolved.txt', it is possible for you to make corrections directly on the txt file.
That can be useful in the case of a " call fixer " doesn't fix all the IAT addresses on once and once only .
It is possible to back up the partially solved file, then modify the call fixer to correct only the bad addresses, then paste the corrected addresses.

(Voluntarily) the prototype does not write the offset values of the Import Table and size in the PE Header of the target file. But if you miss that, you can to add this on the source code.

In short, to treat a program asprotected here is the stages which I used with the prototype:
1- launching prog, then dump full
2- examination of the IAT with the prototype to determine the limits of the iAT and to see which are the "abnormal" addresses
3- writing a simply call fixer after the launching of the contamined program, then dump it
4- examination of the result and solve the IAT addresses with the prototype
5- rebuild an import table in the prog dumped on the entry point with the prototype.

If you give me an available e-mail address, y will send to you "caracol.zip" wich contains the following files :
(sorry but the majority of the documents are in French and I'm too lazy and too weak to try to translate them. But I am sure that you will understand the main point by reading only the listings and the logs..)

- Caracol-Readme.doc (well.. a readme on how works the prototype + some tuts on how to use it)
- AZPR321-Asprotected.doc ((asprotected 1.05) a tut on how to make a simply call fixer and use the prototype)
- Caracol-eng.exe (the prototype)
- Delphi-Caracol-Project-Eng (the code source with a little translation.. the first release..there was no modification since.)
- Address-DLL-TXT (contains some txt files with functions names)
- Work (a directory with some little examples (Win 98))

Well, that's all..

best regards,

el.caracol@caramail.com

tsehp
November 9th, 2000, 14:04
hi caracol,
I have to thank you very much for your complete reply.
Just one thing : I'm French too, so you don't have to translate the docs
What you already did is exactly what I'm currently working on, so the
more people working on this actual problem will surely give some reliable solutions.
Several programs like those are emerging, icedump 6 with hydra plugin
from g-rom, it_build by boris, the dedicated apps written by lutin noir.
Sure it would be better if a general, updated app could solve the most
different cases, I decided to code my own, so their most recent tricks
can be updated in no time, but I'm very far from this point.
Your sources will save me a lot of time, I'm actually thinking far beyond and finish this app with a tracer to fix their later encrypting
progresses.
I sent you a copy on your mail box, thanks again.
regards,

tsehp