Status report: the API monitor project
API Vision (avdemo15.exe) promises
by Mammon_

+cracker
21 January 1998


reverser 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(&quot;\\\\.\\name.vxd&quot;,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, <esi> clc ret EndProc ControlProc VxD_LOCKED_CODE_ENDS ;vxd.c DWORD _OnDeviceIoCtrl(PDIOCPARAMETERS param){ switch (param-&gt;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?
OURTOOLS
Back to our own tools

redhomepage red links red anonymity +ORC redstudents' essays redacademy database
redantismut redtools redcocktails redsearch_forms redmail_reverser
redIs reverse engineering illegal?