Status report: the API monitor project
API Vision (avdemo15.exe) promises
by Mammon_
21 January 1998
Fravia
So far I have been working on two aspects of this project:
existing API monitors, and VXD writing.
Existing API Monitors
---------------------
In addition to APIMON.EXE. which is more of a debugger and is only
reliable (if even) in NT, I have found the following three API monitor
apps:
*API Vision
ftp://ftp.rahul.net/pub/apivis/avdemo15.exe
This is the best, and the one I highly recommend. The above url links to
a 15-day demo that I have not taken the time to crack, but will
definitely do now that I have evaulated the program (it should be a
standard time check, no need for an essay). The program is excellent,
although the available api calls are of course limited. The UI is
fantastic, and even has a "hook next task" feature. Output shows API
function name, parameters, and returns.
The monitor is implemented with a static-load VXD that is initialized in
system.ini--vxd name is vicept.386. There are also numerous "grabber"
DLLs that handle the function parameters calls for each API module.
Note that the use of a VXD is not required for this type of utility; the
next two apps use dlls for their monitoring. However, if we are to
intercept API calls and change their parameters, I think a VXD would be
recommended.
*EXESpy
http://www.spywindows.com/ZIPS/EXESPY98.ZIP
This is the worst of the lot, an ugly VB-style UI. Uses funhk.dll to
capture API calls and prints them to a window and log file. By the guys
who did ComSpy.
*Trace Plus Win32
ftp://ftp.sstinc.com/pub/tplus32.zip
Not a bad program, but I like API Vision better. This one relies on DLLs
as well and is quite well done, but has useless windows like a "system
log" and seems to slow the process down. Regarding the monitoring
technology, the following is from the readme:
"32 bit versions of TracePlus use the standard Microsoft
defined debugging interface for Win32 applications. The
Microsoft interface does not permit detaching from a process
after debugging has started. Therefore, if TracePlus is
terminated, it will also terminate all processes being traced."
In addition, I have found a copy of API Spy for Win16 (does not run in
95) and have come across references to a Win32 version...written in VB,
so once again VXD programming is not a must. There is also a program in
development--I think at spywindows--called API Insight.
Writing a VxD
-------------
After a bit of study and comparing DDK examples against the literature,
it appears that writing a VxD really is not that difficult
(comparatively speaking, of course). Basically you create an ASM program
to handle the Virtual Device Declaration and the VXD Locked Code/Data
segments (which contain the control procedure, a message handler for
VxDs)--you can code the rest in C quite easily (it's all structures and
macros). If you add a pseudo-api by using DeviceIoControl calls--which
contain as a parameter the name of the vxd function to be called--in the
application that communicates with the VxD, you will have a Ring-3
application that calls functions in the Ring-0 VxD; the whole
implementation is basically a combination of CreateFile (to open the
VxD) and DeviceIoControl calls. (The VxD contains a function named
OnDeviceIoControl or somesuch which is called by the control process [in
the .asm file, remember] in response the DeviceIoControl messages...the
OnDeviceIoControl function is a second message handler--a switch
statement in C--that then calls the internal vxd functions, like so:
;application.c
hVXD = CreateFile("\\\\.\\name.vxd",0,0,0,CREATE_NEW,
FILE_FLAG_DELETE_ON_CLOSE, 0);
DeviceIoControl(hVXD, FUNCTION_NAME, descriptor, sizeof(descriptor));
;vxd.asm
VxD_LOCKED_CODE_SEG
BeginProc ControlProc
Control_Dispatch W32DEVICEIOCONTROL, _OnDeviceIoCtrl, cCall,
clc
ret
EndProc ControlProc
VxD_LOCKED_CODE_ENDS
;vxd.c
DWORD _OnDeviceIoCtrl(PDIOCPARAMETERS param){
switch (param->dwIoControlCode) ;this struc member is the function
name
{
case API_Hook_Task:
_APIHookTask(....);
return 0;
case API_Patch_Call:
_APIPatch();
return 0;
default:
return 1;
}
}
The hard part, then, is not creating a VxD with an API--and using this
method you do not have to register with M$oft for a VxD API ID# ;) The
hard part will be intercepting these damn API calls instead of just
watching them.
Oh yeah, notice that this is a dynamically-loaded VxD (the CreateFile()
call)...I'm sure none of us want extra junk floating around in memory.
BTW, there is a registry key at
\HKLM\System\CurrentControlSet\Services\VxD
that contains VxDs to be loaded at startup _in_addition_to system.ini
and the RunServices key.
That's all for now, I'll update you later in the week when I start
taking apart Api Vision. What my "specifications" are for this prog is
to intercept calls made to any exported function in a Dll (even non-API
ones), which will require a different approach than these monitors have
been using...they seem to be using static DBases of API functions.
later,
_m
To be continued, of course... anybody else springs on?
Back to our own tools
homepage
links
anonymity
+ORC
students' essays
academy database
antismut
tools
cocktails
search_forms
mail_Fravia
Is reverse engineering illegal?