Sirmabus
February 8th, 2008, 23:28
Thanks for importing my tool (http://www.woodmann.com/forum/showthread.php?t=10889), but I'll make a more formal introduction, and update here.
Ver 2.2: Got rid of the useless index numbers so now you can WinDiff dumps better.
============================================================
Intro
------
APIScan is a simple tool to gather a list of APIs that a target process uses.
You can use this list in an initial analysis to help determine a target's
general operating nature. Also can be used to help determine patch/update changes by doing a WinDiff on a "before" and "after" dump.
There are similar tools, often more robust (like "Dependency Walker"
, but
most of these just parse the target IAT ("Import Address Table" alone.
APIScan catches dynamically/delayed loaded modules too; and dumps them as a simple list.
============================================================
Example dump for a module:
Explanation:
APIScan saw that "COMCTL32.DLL" is loaded both as an import via the IAT, plus it caught it being loaded dynamically for "InitCommonControlsEx".
That's the 'D' flag in "[.D.F] InitCommonControlsEx". The 'F' in "[.D.F] ImNotHere" means that that the application failed in one or more attempt to dynamically load (from the 'D') "ImNotHere", since this export doesn't exist in "COMCTL32.DLL". In "[I.O.] InitCommonControls", the 'I' tells us this API is in the IAT, and the 'O' tells us it was by "ordinal".
Note, you can have both 'I' and 'D' flags since an application (as well as 'O', and 'F', if there is a 'D') can have it both in it's IAT and loaded it dynamicly (with "GetProcAddress()".
TODO:
1. Add intra-module support.
API scan could parse the IATs of modules/DLLs and optionally filter out GetProcAddress() calls made within modules for better focus.
2. Optional real time output to DBGVIEW.
Ver 2.2: Got rid of the useless index numbers so now you can WinDiff dumps better.
============================================================
Intro
------
APIScan is a simple tool to gather a list of APIs that a target process uses.
You can use this list in an initial analysis to help determine a target's
general operating nature. Also can be used to help determine patch/update changes by doing a WinDiff on a "before" and "after" dump.
There are similar tools, often more robust (like "Dependency Walker"
, butmost of these just parse the target IAT ("Import Address Table"
alone.APIScan catches dynamically/delayed loaded modules too; and dumps them as a simple list.
============================================================
Example dump for a module:
Code:
Library Flags Function
====================================
-- COMCTL32.DLL
[I...] ImageList_Add
[I...] ImageList_Create
[I...] ImageList_Destroy
[I.O.] InitCommonControls
[.D..] InitCommonControlsEx
[.D.F] ImNotHere
...
...
Explanation:
APIScan saw that "COMCTL32.DLL" is loaded both as an import via the IAT, plus it caught it being loaded dynamically for "InitCommonControlsEx".
That's the 'D' flag in "[.D.F] InitCommonControlsEx". The 'F' in "[.D.F] ImNotHere" means that that the application failed in one or more attempt to dynamically load (from the 'D') "ImNotHere", since this export doesn't exist in "COMCTL32.DLL". In "[I.O.] InitCommonControls", the 'I' tells us this API is in the IAT, and the 'O' tells us it was by "ordinal".
Note, you can have both 'I' and 'D' flags since an application (as well as 'O', and 'F', if there is a 'D') can have it both in it's IAT and loaded it dynamicly (with "GetProcAddress()"
.TODO:
1. Add intra-module support.
API scan could parse the IATs of modules/DLLs and optionally filter out GetProcAddress() calls made within modules for better focus.
2. Optional real time output to DBGVIEW.
