I have a problem with a project im currently working on
I need to scan a exe and find RVA's of each call to a Certain function in the import table
Call GetVersionExA
i need to find every rva that has a call to that API however this seems impossible but cannot be because tools such as IDA do this? A friend suggested to me heuristic scanning which im not sure about?
I did think of one such idea that involves running the exe suspended and using getprocaddress and searching the exe in memory for the rva to the function (that windows prepares at runtime in memory) but such a idea could also be fooled by crazy opcode and i prefor not to have to load the exe....
Thanks in advanced
Posted on 2003-08-21 07:26:29 by Uradox
There are always flaws when scanning code. If you try to debug it, to trace each command executed, you might find trouble with strange opcodes, and not all code in a file will get executed every time. And there are those anti debug tricks, they are not such a big deal to a human, but for a program it can be catastrophic.
If you choose to scan the file and dissasemble, you also have anti dissasembly tricks :grin: so... Think of it this way: all heuristic scanning programs have false alarms, always, even antiviruses.
Anyway, do you really need to do this? Just curious. If you're going to implement some kind of API hook, there are probably better ways...
Posted on 2003-08-21 18:56:09 by QvasiModo

i prefor not to have to load the exe....

Then you should miss some easy ways:
I.E. Just path some bytes where "Call GetVersionExA" jumps ;)
Posted on 2003-08-21 19:38:37 by S.T.A.S.
If the program has a relocation table then this is a very easy to do. IDA parses the load addresses from the DLLs in the system folder and the names from the import section. Basically, you need the functionality of a PE loader and there is much you would miss - especially if buliaNaza was coding the PE. :)
Posted on 2003-08-21 21:22:43 by bitRAKE

- especially if buliaNaza was coding the PE. :)

I certainly do agree with you. But then again Lingo's code gives me some inspiration. :grin:
Posted on 2003-08-22 01:17:24 by roticv
Oh well let me clarify on what im exactly doing. Cant use relocation as every exe does not have this and it must be as generic as possible tho i dont give a crap if it doesnt work on VB.
Basicly i have a dll thats almost no code in it. The author uses the dll to call apon *certain* functions inside my protection system (wraped around the exe encrypted etc..)
So in one such case they have:
Push ...
Call User32EMU

i check to see if function is in import table and if so then i proceed to finding all calls to this and altering them to the REAL function RVA thats in the wrapper
Posted on 2003-08-22 02:11:25 by Uradox
Easier than that, you can patch the import table itself. But if the EXE makes calls to those functions by any other means, you'll loose them.
Posted on 2003-08-22 09:55:08 by QvasiModo
I'm currently coding a debugger with some of the features you guys have been discussing - it's trained to recognize a range of antidebug tricks, it heuristically analyses program execution (flow analyser/iteration counter), it marks uncalled execution paths, it grabs the target file import and exports and tabulates their string names (or ordinals) and addresses, it monitors stack usage, and looks ahead to the next opcode and disassembles it before it is executed - thus it can tell you for example whether a conditional jump will be followed or not before actually following it. It's a cross between a flow analyser and a stepping debugger (it uses Trap flag), which is geared toward mapping the runtime use of memory and registers with a view to distinguishing critical and uncalled code and identifying its function....
Posted on 2003-08-23 20:14:45 by Homer
I did find my solution thanks to someone on efnet and it was scanning and of course not 100% but accurate enough for my needs. Was using FirstThunk and check all FF 15/25 calls with lots of SEH cause of the fuckup chances are pretty high. And wont work on bound import tables either sadly
But im not really caring about VB support and the like
Posted on 2003-08-24 05:51:08 by Uradox