




版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领
文档简介
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
温馨提示
- 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
- 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
- 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
- 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
- 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
- 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
- 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
最新文档
- 资料除夕夜日记
- 讲文明懂礼貌演讲稿范文500字(7篇)
- 五千以内加减混合两步运算水平检测口算题
- 高二下学期期末学生个人总结600字(9篇)
- 连锁餐饮年终总结
- 中华民族风情巡礼知到课后答案智慧树章节测试答案2025年春青海民族大学
- 人教辽宁 九年级 下册 语文 第六单元《 文言文主题阅读》习题课 课件
- 酒店业可行性报告
- 造价专业剖析
- 沪教版高中语文第三册师说 同步练习 完成文后各题
- 2025年湖南环境生物职业技术学院单招职业倾向性测试题库完整版
- 2025年河南应用技术职业学院单招职业倾向性测试题库含答案
- 煤矿常用机电设备的日常管理-培训课件
- 2025年新执业医师定期考核真题库附参考答案
- 第三单元第1课《广而告之》课件-七年级美术下册(人教版2024)
- 天津2025年天津市天宾服务中心招聘13人笔试历年参考题库附带答案详解
- 煤矿安全生产标准化管理体系-第3部分重大灾害防治
- 2025年全国普通话水平测试50套复习题库及答案
- 《科技园招商方案》课件
- 院感知识培训课件
- 集装箱知识培训课件
评论
0/150
提交评论