Caveats
What could justify writing code that makes use of undocumented offsets and identifiers that might change between versions of NT? The answer is that system-call hooking opens the door to a level of system monitoring and control that far exceeds what is possible without it. NTOSKRNL contains services used to access the file systems, registry, processes and threads, memory, disk cache, and dozens of other facilities. NT's built-in support for monitoring these facilities is basically restricted to a few query services and the performance counters that are exported to the registry. By contrast, system-call hooking can be used to watch every request made to a service and even see the parameters being passed. System-call hooking can also be used to augment service functionality and change the behavior of services.
Even so, hooking system calls in this fashion is not for everyone. If your code must be forward compatible with future releases of NT, don't use it! On the other hand, if you require access to system information available no other way, and if it is acceptable to have version-specific releases (as with system-diagnostic applications, for example), this may be the way to go.
NTRegmon: System-Call Hooking at Work
NTRegmon graphically demonstrates the kinds of interesting information attainable only with hooking (see Figure 3). It displays complete information about every registry-related call that takes place as it is running. While Win32 provides a registry-change notification function with RegNotifyChangeKeyValue, applications have no control over the changes they are notified of. And without examining the registry after each notification, they have no way of knowing exactly what has changed. The framework built by NTRegmon allows a device driver to see not only changes, but any registry access as it occurs. If desired, a device driver could fail or alter certain registry accesses.
Figure 3: NTRegmon.
Due to its dependence on x86 TEB offsets, NTRegmon will only run on x86 systems. It is made up of a Win32 GUI, REGMON.EXE, and a device driver, REGSYS.SYS. When the GUI is started, it dynamically loads the device driver, which is immediately directed by the GUI, via DeviceIoControl, to hook all registry calls. The hooking procedure shown in Listing One hides NT version-dependent code in the SYSCALL macro The macro is used to index into one of two tables of registry system-call numbers that are specific to either NT 3.51 or NT 4.0. Version information is obtained by referencing the undocumented kernel variable, NtBuildNumber.
Listing One
VOID HookRegistry( void ){
// hook everything
RealRegOpenKey = SYSCALL( REGOPENKEY );
SYSCALL( REGOPENKEY ) = (PVOID) HookRegOpenKey;
RealRegQueryKey = SYSCALL( REGQUERYKEY );
SYSCALL( REGQUERYKEY ) = (PVOID) HookRegQueryKey;
RealRegQueryValueKey = SYSCALL( REGQUERYVALUEKEY );
SYSCALL( REGQUERYVALUEKEY ) = (PVOID) HookRegQueryValueKey;
RealRegEnumerateValueKey = SYSCALL( REGENUMERATEVALUEKEY );
SYSCALL( REGENUMERATEVALUEKEY ) = (PVOID) HookRegEnumerateValueKey;
RealRegEnumerateKey = SYSCALL( REGENUMERATEKEY );
SYSCALL( REGENUMERATEKEY ) = (PVOID) HookRegEnumerateKey;
RealRegDeleteKey = SYSCALL( REGDELETEKEY );
SYSCALL( REGDELETEKEY ) = (PVOID) HookRegDeleteKey;
RealRegFlushKey = SYSCALL( REGFLUSHKEY );
SYSCALL( REGFLUSHKEY ) = (PVOID) HookRegFlushKey;
RealRegSetValueKey = SYSCALL( REGSETVALUEKEY );
SYSCALL( REGSETVALUEKEY ) = (PVOID) HookRegSetValueKey;
RealRegCreateKey = SYSCALL( REGCREATEKEY );
SYSCALL( REGCREATEKEY ) = (PVOID) HookRegCreateKey;
RealRegDeleteValueKey = SYSCALL( REGDELETEVALUEKEY );
SYSCALL( REGDELETEVALUEKEY ) = (PVOID) HookRegDeleteValueKey;
RealRegCloseKey = SYSCALL( REGCLOSEKEY );
SYSCALL( REGCLOSEKEY ) = (PVOID) HookRegCloseKey;
RegHooked = TRUE;
}
Hook routines in the device driver must have prototypes that are identical to the services they hook so that parameters are passed correctly to the original service. All the hook routines in NTREGMON perform the same steps: obtaining data on the passed parameters, invoking the original service, and storing the return parameter and status information in a buffer periodically copied to the GUI for display. Listing Two presents HookRegDeleteValueKey, an example hook routine.
Listing Two
NTSTATUS HookRegDeleteValueKey( IN HANDLE Handle, PUNICODE_STRING Name ){
NTSTATUS ntstatus;
CHAR fullname[1024], name[20];
GetFullName( Handle, Name, fullname );
MUTEX_P( RegMutex );
ntstatus = RealRegDeleteValueKey( Handle, Name );
MUTEX_V( RegMutex );
UpdateStore( Sequence++, "%s\tDeleteValueKey\t%s\t\t%s",
GetProcess( name ), fullname,
ErrorString( ntstatus ));
return ntstatus;
}
Besides relying on the undocumented TEB definition and system-call numbers, NTRegmon makes use of another undocumented, version-specific data structure so that it can display the name of the process that is executing at the time of each registry access. In each hook routine, NTRegmon looks into the Process Environment Block (PEB) to copy out the process's name. It is unfortunate that the only function provided by NT to obtain process names, NtQuerySystemInformation call, returns information about all processes and threads that are running, instead of a specific one.
Although many registry calls perform accesses by handle rather than by a key's path name, NTRegmon is able to display the full path name of virtually every registry request by storing the path names associated with handles in a hash table. When a handle is referenced by a call, NTRegmon looks up the handle in the hash table to see if its name has been stored, and if so, translates the handle back to its path name. In cases where NTRegmon did not see the open or create call corresponding to a handle, the raw hex value of the key's handle is displayed. In order to save screen real estate, NTRegmon uses some abbreviations listed in Table 1 for root keys.
Table 1: Root-key abbreviations.
Although we've only implemented an x86 version of NTRegmon, a little poking around with WINDBG is all it should take to discover the platform-dependent changes that must be made to port it to the Alpha, MIPS, or PowerPC platforms.
Implementing Your Own Hooks
The simplicity of NTRegmon's hook routines shows how straightforward system-call hooking actually is. The essential information for performing system-call hooking includes the system-call number associated with a service, and the prototype definition of the service. A kernel debugger such as NuMega's NT/ICE or the Microsoft DDK's WINDBG can be used to obtain system-call numbers (use the ntcall command in NT/ICE), and some NTOSKRNL calls are either documented in the DDK or are very similar to related Win32 versions. In cases where a call is truly undocumented, there is no recourse other than to disassemble and study it under a debugger. In any case, the technique presented here should enable you to complete your own hooking routines to both gain insight into how NT works and to control and monitor it for real applications.
Mark can be contacted at [email protected] and Bryce at [email protected].
