Windows NT System-Call Hookingnew

1、Mark and Bryce present the design and implementation of NTRegmon, a tool that uses hooking to show detailed information about each and every registry access that occurs on a Windows NT system. Windows NT System-Call HookingMark can be contacted at mark and Bryce at . In our art

2、icle, Examining VxD Service Hooking (Dr. Dobbs Journal, May 1996), we focused on how Windows 95 device drivers can take advantage of built-in support for monitoring or altering system calls inside the Windows 95 kernel (Virtual Memory Manager). This ability is extremely powerful because it enables t

3、he development of applications that can see events and actions occurring inside a system at a level of detail not otherwise possible. Windows NT, besides having a less documented internal architecture, does not provide any support for hooking system calls. In this article, we describe the architectu

4、re of NT so as to clearly define what is meant by the term system call when it is used in the context of Windows NT. We also go inside the Windows NT kernelv (NTOSKRNL.EXE) to expose the mechanism by which a system-call request gets routed to the kernel routine that services it. We then show how dev

5、ice drivers can hook system calls, allowing them to see system requests both before and after theyve been serviced.To demonstrate the types of monitoring that can be achieved with system-call hooking, we present the design and implementation of an application, NTRegmon. NTRegmon uses hooking to show

6、 detailed information about every registry access that occurs on an NT system. It also is useful for studying NT registry usage, finding undocumented application-registry settings, and debugging your own registry-enabled programs.The Windows NT System-Call ArchitectureMost Windows NT developers thin

7、k of the Win32 interface when they hear the term system call. Calls like CreateFile, ShowWindow, PeekMessage and others are what make up the operating system that is exported to programmers by the NT architecture. However, beneath this layer, which shares most of its definition with the Windows 95 i

8、mplementation of Win32, is the real Windows NT operating system. The core components of NT are NTOSKRNL and WIN32K, named after the files they are loaded from, NTOSKRNL.EXE and WIN32K.SYS (in the system32 directory under the system root directory). When an NT system is diagrammed from the point of v

9、iew of request paths, Win32 is actually a layer that runs on top of the kernel; see Figure 1. If you are familiar with NTs architecture from Helen Custers Inside Windows NT (Microsoft Press, 1993), the sight of the WIN32K kernel-mode component may be surprising. In fact, WIN32K made its debut with N

10、T 4.0 when much of Win32s graphics engine, previously implemented in user mode by GDI32.DLL and USER32.DLL, was moved into kernel mode to boost performance. When an application makes a call to a Win32 function, the call is handled by a routine in one of the Win32 DLLs that make up the Win32 subsyste

11、m. In most cases, the routine performs operations that are specific to Win32, such as validating parameters, updating internal Win32 data structures, and breaking the request up into subrequests. But in the end, the DLL will usually end up calling upon native NT services provided by NTOSKRNL or WIN3

12、2K to actually carry out the system-related parts of the request. NTOSKRNL is invoked by a call to another DLL, NTDLL.DLL, which exports NTOSKRNL services to user-level subsystems like Win32, POSIX, and OS/2.For example, a call to the Win32 function CreateFile is serviced by KERNEL32.DLL, which vali

13、dates parameters and then, depending on the flags that were passed, makes one or more calls to NTOSKRNL via NTDLL wrappers. For instance, if the flags indicate that the CreateFile call should fail if a file of the same name already exists, a call is made to the kernel to see if that condition is tru

14、e. Then the kernel is called to actually create or open the specified file, and finally, a third call to the kernel might be made to set some of the files attributes.One of NTDLLs primary jobs is to initialize a register with a system-call number that identifies the service in the kernel being calle

15、d, and to execute a system-call trap. For the CreateFile example, the NTDLL function ZwCreateFile is one of the routines invoked. Example 1, ZwCreateFiles disassembly for x86 processors, demonstrates how thin a wrapper NTDLL provides for kernel services. NTDLL contains many snippets of code that loo

16、k almost exactly like the example. What makes each routine unique is its system-call number and the number of parameters that are popped off the stack when the routine is finished. Calls to WIN32K also look like the ZwCreateFile example, but instead of being placed in a separate DLL, they are locate

17、d within USER32 and GDI32.Zw-prefixed calls, like ZwCreateFile, have alias names that are identical except that Zw is replaced with Nt (NtCreateFile); kernel services corresponding to Zw calls use the Nt prefix. Thus, an application linking with NTDLL can use ZwCreateFile or NtCreateFile to access t

18、he kernel service NtCreateFile.Nothing prevents applications from accessing NTDLL functions without going through Win32, but Win32 generally provides a more friendly interface than the native NT interface. In addition, since NTDLLs interface is undocumented, applications that access it directly run

19、the risk, albeit small, that Microsoft may change it without notice.The system-call trap is how NT changes gears from user-mode to kernel-mode execution to enter the privileged world of the operating-system kernel. When a trap occurs, the processors execution mode changes and it begins executing on

20、a kernel-mode stack. The kernel finds the address of the service that will handle the request by looking up a data structure referenced by a field in the executing threads Thread Environment Block (TEB). The TEB contains all the information necessary for operation of a thread, such as its registers,

21、 its priority level, a pointer to its process, and so on. The data structure in question, which well call the Service Table List, is shown in Figure 2. In the current implementation of NT 4.0, the list contains two entries that define system-call tables for NTOSKRNL and WIN32K calls. NT 3.51 and its

22、 predecessors have only one entry in the list: that for NTOSKRNL calls. Each entry is made up of four fields: The first is a pointer to an array of function addresses called a service table; the second field is 0 and is never referenced; the third field contains the number of system calls in the ser

23、vice table referenced by the first field; and the fourth field points to an argument table.First, the kernels system-call trap handler uses the system-call number passed to it via a register (EAX in Example 1) to determine which entry in the Service Table List it should access. Win32 system calls ha

24、ve system-call numbers that start at 0x1000, whereas kernel system calls begin at 0. Next, the handler ensures that it is dealing with a valid system-call number. It compares the number to the third field of the appropriate entry in the Service Table List, which contains the highest valid system-cal

25、l number for the table. (The handler subtracts 0x1000 from Win32K call numbers before the comparison.) If the call number is less than or equal to the highest acceptable number, the handler obtains a pointer to the service table and indexes into it with the system-call number to obtain the address o

26、f the service it must call. It then indexes into the argument table and reads the number of bytes it must get from the callers stack to push onto its own stack as it calls the service. After the service returns, the handler performs some cleanup and returns from the trap into (usually) NTDLL.Each th

27、read contains a pointer to a potentially unique copy of a Service Table List. However, all the Service Table Lists point to shared service and argument tables with the exception of some system threads that have NULL fields for the Win32K entry in their lists. The reason for having multiple identical

28、 Service Table Lists is unclear, but it seems to be the result of forward-thinking design. In the future, different threads may be presented for different versions of the NT kernel. Perhaps just as NT supports different user-mode personalities (POSIX, Win32, OS/2), it will also support different ker

29、nel personalities.Hooking System CallsSince each threads TEB has its own Service Table List pointer, it is possible that every thread could also have its own unique table of OS services. However, in practice, the list and tables are globally shared. Simply changing an entry in either the NTOSKRNL or

30、 WIN32K service tables to point to a new hook routine in a device driver is all that is needed. Changing an entry hooks the call across all threads in the system, including any new threads that are created. Unfortunately, as NT does not provide a service-hooking function, NT version-dependent code m

31、ust be written to hook specific services. Two variables tie system-call hooking to an implementation of NT. The first is the offset in the TEB where the Service Table List pointer is stored, and the second is the system-call numbers that identify services. Since there is no published definition for

32、the TEB, locating the Service Table List requires manually indexing into it by a fixed number of bytes and extracting the pointer. While the offset has not changed from NT 3.51 to NT 4.0, surprisingly, it is different across hardware platforms. System-call numbers, on the other hand, while constant

33、across hardware platforms, changed between NT 3.51 and NT 4.0. For example, under NT 3.51, the system-call number for RegOpenKey is 0x4D, but under NT 4.0, it is 0x51. CaveatsWhat could justify writing code that makes use of undocumented offsets and identifiers that might change between versions of

34、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. NTs bui

35、lt-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 ho

36、oking 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, dont use it! On the other hand, if you require access to system informati

37、on 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 WorkNTRegmon graphically demonstrates the kinds of interesting information attainable only with hooki

38、ng (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 examinin

39、g 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. (The complete

40、 source code and related files for NTRegmon is available electronically; see Availability, page 3.)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

41、 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 sp

42、ecific to either NT 3.51 or NT 4.0. Version information is obtained by referencing the undocumented kernel variable, NtBuildNumber.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

43、 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 r

44、outine.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 in

45、to the Process Environment Block (PEB) to copy out the processs 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

46、 calls perform accesses by handle rather than by a keys 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 tab

47、le 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 keys handle is displayed. In order to save screen real estate, NTRegmon uses some abbreviatio

48、ns listed in Table 1 for root keys.Although weve 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 HooksThe simpl

49、icity of NTRegmons 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 NuMegas NT/ICE or

50、 the Microsoft DDKs 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 contr