Chapter 5 Monitoring Native API Call
Translation: kendiv (fcczj@263.net)
Update:
Thursday, February 24, 2005
Disclaimer: Please indicate the source and guarantee the integrity of the article, and all rights to the translation.
Intercepting system calls at all times are the favorite of programmers. The motivation of this popularity is also a variety of varieties: code profile and optimization, reverse engineering, user activity records, etc. All of this has a common purpose: pass control to a special code, so regardless of when an application calls the system service, it can be found in which service is called, what parameters have received, what is the result of the return? How much time it cost it. Based on the techniques initially made by Mark Russinovich and Bryce Cogswell, this chapter will introduce a general framework that can hook any Native API function. The method used here is Data-Driven, so it can be easily expanded and can adapt to other Windows NT / 2000 versions. The data generated by the API call generated by all processes is written in an annular buffer, and the client program can read the buffer by device I / O control. The format of the data protocol (Protocol Data) is based on behavioral-oriented ANSI text streams, which meets strict formatting rules, which can be easily processed again (PostProcessing). In order to demonstrate the basic framework of such a client program, this chapter also provides an exemplary data protocol viewer that is running in the console window.
Translation:
Profiling generally refers to testing of program performance, primarily on speed. In translation, it can be translated as: profiling, preferably based on the above environment.
Modify service descriptor table
Compare the "original" operating system, such as DOS or Windows 3.x, which adds small restrictions on programmers to the API, while Win32 systems, such as Windows 2000 / NT and Windows 9.x are difficult to control, because They use a clever protection mechanism to separate the unrelated code. Setting up a system-wide hook on Win32 API is never a small task. Fortunately, we have a Win32 wizard like Matt Pietrek and Jeffery Richter, who made a lot of work to show us how to complete this task, although in fact, there is no simple and elegant solution. In 1997, Russinovich and Cogswell introduced a completely different way to implement system-wide hook on Windows NT, which intercept system calls at a lower layer (Russinovich and Cogswell 1997). They proposed to inject log mechanisms to Native API Dispatcher, which is only lower than the boundaries between user mode and core mode, and the Windows NT is exposed to the "bottleneck" in this position: All user mode threads must pass here. Use the service provided by the operating system kernel.
Service and parameter table
Just as discussed in Chapter 2, the Native API call in user mode must pass through the Int 2EH interface, which provides an I386 interrupt door to change the privilege level. You may still remember that all int 2Eh calls are processed by internal functions KisystemService () in kernel mode, which uses the System Services Descriptor Table (SDT) to find the entry address of the Native API processing routine. Figure 5-1 shows the relationship between the basic components of this distribution mechanism. Listing 5-1 gives a formal definition of the service_descriptor_table structure and its sub-structure again, in the second chapter, has given the definitions (List 2-1). When you call KisystemService (), you need to provide two parameters, which are incorporated by EAX and EDX registers by the caller of Int 2EH. Eax contains an index starting from 0, which can be used for an array of API function pointers, and EDX points to the argument stack of the caller. KiSystemService () The base address of the function array is obtained by reading the value of a member of the serviceetable (one public data structure of Ntoskrnl.exe). In fact, KeserVicedScriptable points to a structure containing four service tables, but by default, only the first service table is valid. KisystemService () enters the internal structure Kiserventable through the index value in EAX to find the entry address of the function that can handle this API call. Before calling the target function, Query the KiargumentTable structure in the same way to find out how many bytes in the argument stack, and then use this value to copy the parameters to the current kernel stack. Thereafter, only a simple assembly instruction is required: Call is required to execute the API processing routine. All functions involved here are in line with the __stdcall standard.
Figure 5-1. Structure of KServicedescriptable
Typedef NTSTATUS (NTAPI * NTPROC) ();
Typedef ntproc * pntproc;
#define ntproc_ sizeof (ntproc)
Typedef struct _system_service_table
{
PNTProc ServiceTable; // Array Of Entry Points
PDOWRD CounterTable; // Array of Usage Counters
DWORD serviceLIMIT; // Number of Table Entries
PBYTE argumenttable; // array of byte counters
}
System_Service_Table,
* Psystem_service_table,
** ppsystem_service_table;
/ / -------------------------------------------------------------------------------------------- -------------------------------------------------- ---------
Typedef struct _service_descriptor_table
{
System_service_table ntoskrnl; // ntoskrnl.exe (Native API)
System_service_table win32k; // Win32k.sys (GDI / User Support)
SYSTEM_SERVICE_TABLE TABLE3; / / NOT USED
System_Service_Table Table4; // NOT USED}
System_descriptor_table,
* Psystem_descriptor_table,
** ppsystem_descriptor_table;
Listing 5-1. Service_descriptor_table definition
Windows 2000 also offers another service descriptor table parameter block ---- KeserviceDescriptAbleshadow. However, KeserviceDescriptable has been exported by Ntoskrnl.exe, so the kernel mode driver can be easily access it, and KeserviceDescriptAbleshadow can't. Under Windows 2000, KeserviceDescriptAbleshadow is followed by KeserviceDescriptable, but you can't find it in this way in Windows NT, because this rule is not used in Windows NT. This method may not work in subsequent versions of Windows 2000. The difference between these two parameter blocks is that the system uses the second service table in KeserviceDescriptAbleshadow to reference two internal structures: W32PServentable and W32PARGUMENTTABLE, WIN32 kernel mode components Win32k.sys use these two structures to assign their own API Call, as shown in Figure 5-2. KiSystemService () is confirmed by checking EAX's index values to handle the API calls by Win32k.sys. If these two bits are 0, the NTIVE API calls processed by Ntoskrnl.exe, so KisystemService () uses the first service table of the SDT. If the 12th bit is 1 and the 13th bit is 0, KisysTemService () uses the second service table of the SDT, and the other combinations of these two bits are used for the remaining two service tables, but the system is currently not used by these two. Service table. This means that the potential range of the index value called by the Native API is: 0x0000 --- 0x0fff, the index range used by Win32k.sys call is: 0x1000 --- 0x1FFF. Therefore, 0x2000 --- 0x2FFF and 0X3000 --- 0x3FFF reserves the remaining two service tables. In Windows 2000, the Native API service table contains 248 items, and the Win32k.sys table contains 639 items.
Figure 5-2. Structured diagram of KeserviceDescriptAbleshadow
Russinovich and Cogswell's unique ways are: Put all API calls to the Kiserventetable array to Hook all APIs. This processing routine finally calls the original handling routine located in Ntoskrnl.exe, but it has the opportunity to view the input / output parameters of the called function. This method is very powerful but so simple. Because all user mode threads must pass this "needle eye" to get the Native API service, install a global hook to simply replace a function pointer, which can be stable in the case of starting a new process and threads jobs. This does not require a communication mechanism to notify the newly joined or will be removed.
Unfortunately, the system service table is different on different WINDOWS NT versions. Table 5-1 compares the KiserventAble of Windows NT / 2000. Obviously, not only the number of the processing routine is added from 211 to 248, but also the new process routine is not directly added to the end of the list, but is inserted into all places! Therefore, a service function index, such as 0x20 pointing ntcreatefile () in Windows 2000, but pointing ntcreateprofile () in Windows NT. So, by operating the service function table, Hook's API call monitor must be careful to check the version of the Windows NT it. This can be accomplished in the following ways: L a possibility that the public variables exported by ntoskrnl.exe: NTBuildNumber, just like Russinovich and Cogswell in their original text. Windows NT 4.0 is the build number provided for all service packs: 1381. The current Number of Windows 2000 is: 2195. It seems that this version is very stable in the early versions of Windows NT.
L Another possibility is to check the NTmajorVersion and NTMinorVersion members in the SharedUserData structure, which defines the NTDDK.H with the Windows 2000 header file. All service packs of Windows NT 4.0 will set SharedUserData-> NtmajorVersion to 4, set SharedUserData-> NtminorVersion to 0. The current version of Windows 2000 is Windows NT Version 5.0.
l The code given in this chapter uses another alternative method: it tests if the SDT's serviceLimit member matches its expected value, which is 211 (0xD3) for Windows NT 4.0 and 248 (0xF8) for Windows 2000.
Table 5-1. Windows 2000 / NT Service Table Comparison
Windows 2000
index
Windows NT 4.0
NTACCEPTCONNECTPORT
0x00
NTACCEPTCONNECTPORT
NTACCESSCHECK
0x01
NTACCESSCHECK
NTACCESSCHECKANDITAlarm
0x02
NTACCESSCHECKANDITAlarm
NTACCESSCHECKBYTYPE
0x03
NTADDAM
NTACcessCheckbytypeAndauditararm
0x04
NTADJUSTGROUPSTOKEN
NtaccessCheckbyTypeResultlist
0x05
NTADJUSTPRIVILEGESTOKEN
NTACcessCheckbyTypeResultListandauditaRMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
0x06
NtalertResuMethread
NTACcessCheckbyTypeResultListandauditaRmbyhandle
0x07
Ntalertthread
NTADDAM
0x08
NTallocatelocallyLoNiqueld
NTADJUSTGROUPSTOKEN
0x09
NtallocateUuIDS
NTADJUSTPRIVILEGESTOKEN
0x0a
NtallocatevirtualMemory
NtalertResuMethread
0x0b
NTCallbackreturn
Ntalertthread
0x0c
Ntcancellofile
NTallocatelocallyLoNiqueld
0x0d
NTCANCELTIMER
NtallocateUserphysicalPages
0x0e
NTCLEAREVENT
NtallocateUuIDS
0x0f
Ntclose
NtallocatevirtualMemory
0x10
NTCloseObjectauditararm
Ntaremappedfilesthesame
0x11
NTcompleteConnectport
NTASSIGNPROCESSTOJOBOBOBIBIECT
0x12
NTCONNECTPORT
NTCallbackreturn
0x13
NtContinue
Ntcancellofile
0x14
NTCreatedIRectoryObject
NTCANCELTI MER
0x15
NtcreateEvent
NTCanceLDeviceWakeupRequest
0x16
NtcreateEventpair
NTCLEAREVENT
0x17
Ntcreatefile
Ntclose
0x18
Ntcreatelocompletion
NTCloseObjectauditararm
0x19
NTCREATEKEY
NTcompleteConnectport
0x1a
NtcreateMailslotfile
NTCONNECTPORT
0x1b
Ntcreatemutant
NtContinue
0x1c
NtcreateNamedPipefile
NTCreatedIRectoryObject
0x1D
NTCreatePagingFile
NtcreateEvent
0x1e
Ntcreateport
NtcreateEventpair
0x1f
NTCREATEPROCESS
Ntcreatefile
0x20
Ntcreateprofile
Ntcreatelocompletion
0x21
NtcreateSecion
NTCReateJobObject
0x22
NtcreateSemaphore
NTCREATEKEY
0x23
NtcreateSymbolicLinkObject
NtcreateMailslotfile
0x24
NTCReatethread
Ntcreatemutant
0x25
NtcreateTimer
NtcreateNamedPipefile
0x26
NTCReateToken
NTCreatePagingFile
0x27
NTDELAYEXECUTION
Ntcreateport
0x28
NTDeleTeatom
NTCREATEPROCESS
0x29
NTDELETEFILE
Ntcreateprofile
0x2a
NTDeleteKey
NtcreateSecion
0x2b
NTDeleteObjectAuditararm
NtcreateSemaphore
0x2c
NTDeleteValueKey
NtcreateSymbolicLinkObject
0x2d
NTDeviceLocontrolfile
NTCReatethread
0x2e
NTDISPLAYSTRING
NtcreateTimer
0x2f
NTDUPLICATEOBJECT
NTCReateToken
0x30
NTDUPlicateToken
NtcreateWaitableport
0x31
NTenumerateKey
NTDELAYEXECUTION
0x32
NTenumerateValueKey
NTDeleTeatom
0x33
NTEXTendSection
NTDELETEFILE
0x34
Ntfindatom
NTDeleteKey
0x35
NTFlushBuffersFilentdeEleteobj Ectauditararm
0x36
NTFLUSHLNSTRUCACACHE
NTDeleteValueKey
0x37
NTFLUSHKEY
NTDeviceLocontrolfile
0x38
NTFLUSHVIRTUALMEMORY
NTDISPLAYSTRING
0x39
NTFLUSHWRITEBUFFER
NTDUPLICATEOBJECT
0x3a
NTFreeVirtualMemory
NTDUPlicateToken
0x3b
NTFSControlFile
NTenumerateKey
0x3c
NtgetContextThread
NTenumerateValueKey
0x3d
NtgetPlugPlayEvent
NTEXTendSection
0x3e
NTGETTICKCOUNT
NtfilTerToken
0x3f
NtlmPersonateClientOfport
Ntfindatom
0x40
NTLMPERSONATTHREAD
NTFLUSHBUFFERSFILE
0x41
NtlnitializeREGISTRY
NTFLUSHLNSTRUCACACHE
0x42
Ntlistenport
NTFLUSHKEY
0x43
NTLOADDRIVER
NTFLUSHVIRTUALMEMORY
0x44
NTLOADKEY
NTFLUSHWRITEBUFFER
0x45
NTLOADKEY2
NTFreeUserphysicalPages
0x46
NtlockFile
NTFreeVirtualMemory
0x47
NTLOCKVIRTUALMEMORY
NTFSControlFile
0x48
NTMAKETEMPORARYOBJECT
NtgetContextThread
0x49
NTMapViewOfSection
NtgetDevicePowerstate
0x4a
NTNotifyChangeDirectoryFile
NtgetPlugPlayEvent
0x4b
NTNotifyChangeKey
NTGETTICKCOUNT
0x4c
NTOPENDIRECTORYOBJECT
NtgetWritewatch
0x4D
Ntopenevent
NtlmPersonateAnonymoustokeToken
0x4e
NtopeneventPair
NtlmPersonateClientOfport
0x4f
NTOPENFILE
NTLMPERSONATTHREAD
0x50
NTOPENLOCOMPLETION
NtlnitializeREGISTRY
0x51
NTOPENKEY
NTLNITIATEPOWERACTION
0x52
NTOPENMUTANT
NtlssystemResumeAutomatic
0x53
NtopenObjectauditararm
Ntlistenport
0x54
NTOpenProcess
NTLOADDRIVER
0x55
NtopenProcessToken
NTLOADKEY
0x56
NTOPENSECTION
NTLOADKEY2
0x57
NTOPENSEMAPHORE
NtlockFile
0x58
NTOPENSYMBOLICLINKOBJECT
NTLOCKVIRTUALMEMORY
0x59
NTOPENTHREAD
NTMAKETEMPORARYOBJECT
0x5a
NTopenThreadToken
NTMapUserphysicalPages
0x5b
NTOPENTIMER
NTMapUserphysicalPagessCatter
0x5c
NTPLUGPLAYCONTROL
NTMapViewofSECTION0X5D
NTPrivilegecheck
NTNotifyChangeDirectoryFile
0x5e
NtprivilegedServiceAuditararm
NTNotifyChangeKey
0x5f
NtprivileGeObjectAuditararm
NTNotifyChangeMultiPleKeys
0x60
NTProtectVirtualMemory
NTOPENDIRECTORYOBJECT
0x61
NTPulseEvent
Ntopenevent
0x62
NTQuerylnFormationAtom
NtopeneventPair
0x63
NTQueryattributesfile
NTOPENFILE
0x64
NTQueryDefaultlocale
NTOPENLOCOMPLETION
0x65
NTQueryDirectoryFile
NTOpenJobObject
0x66
NTQueryDirectoryObject
NTOPENKEY
0x67
NTQueryeafile
NTOPENMUTANT
0x68
NTQueryEvent
NtopenObjectauditararm
0x69
NTQueryfullattributesfile
NTOpenProcess
0x6a
NTQuerylnformationFile
NtopenProcessToken
0x6b
NTQueryLocompletion
NTOPENSECTION
0x6c
NTQueryLnformationPortport
NTOPENSEMAPHORE
0x6D
NTQuerylnformationProcess
NTOPENSYMBOLICLINKOBJECT
0x6e
NTQuerylnFormationthreadthread
NTOPENTHREAD
0x6f
NTQuerylnformationToken
NTopenThreadToken
0x70
NTQueryLntervalprofile
NTOPENTIMER
0x71
NTQueryKey
NTPLUGPLAYCONTROL
0x72
NTQueryMultiPLEKEYKey
Ntpowerlnformation
0x73
NTQuerymutant
NTPrivilegecheck
0x74
NTQueryObject
NtprivilegedServiceAuditararm
0x75
NTQueryoledirectoryFile
NtprivileGeObjectAuditararm
0x76
NTQueryperFormanceCounter
NTProtectVirtualMemory
0x77
NTQuerysection
NTPulseEvent
0x78
NTQuerySecurityObject
NTQuerylnFormationAtom
0x79
NTQuerysemaphore
NTQueryattributesfile
0x7a
NTQuerySymbolicLinkObject
NTQueryDefaultlocale
0x7b
NTQuerySystemEmenvironmentValue
NTQueryDefaultuilanguage
0x7c
NTQuerySystemLnformation
NTQueryDirectoryFile
0x7D
NTQuerySystemTime
NTQueryDirectoryObject
0x7e
NTQueryTimer
NTQueryeafile
0x7f
NTQueryTimerResolution
NTQueryEvent
0x80
NTQueryValueKey
NTQueryfullattributesfile
0x81
NTQueryVirtualMemory
NTQuerylnformationFile
0x82
NTQueryvoluMelnformationFile
NtquerylnformationJobiBObject
0x83
NTQueueapcthread
NTQueryLocompletion
0x84
NTRAISEEXCEPTION
NTQueryLnformationPortport
0x85
NTRAISEHARDERROR
NTQuerylnformationProcess
0x86
NTREADFILE
NTQuerylnFormationthreadthread
0x87
NTREADFILESCATTER
NTQuerylnformationToken
0x88
NTReadRequestData
NTQuerylnstalluilanguage
0x89
NTReadvirtualMemory
NTQueryLntervalprofile
0x8a
NtregisterThreadterminateport
NTQueryKey
0x8b
NTRELESEMUTANT
NTQueryMultiPle ValueKey
0x8c
NTRELEASEMAPHORE
NTQuerymutant
0x8D
NTREMOVELOCOMPLETION
NTQueryObject
0x8e
NtreplaceKey
NTQueryOpenSubkeys
0x8f
Ntreplyport
NTQueryperFormanceCounter
0x90
NtrePlyWaitreceport
NTQueryquotalnformationFile
0x91
NtrePlyWaitreplyport
NTQuerysection
0x92
NtRequestport
NTQuerySecurityObject
0x93
NTREQUESTWAITREPLYPORT
NTQuerysemaphore
0x94
NtRetevent
NTQuerySymbolicLinkObject
0x95
NTRESTOREKEY
NTQuerySystemEmenvironmentValue
0x96
NTRESUMETHREAD
NTQuerySystemLnformation
0x97
NtsaveKey
NTQuerySystemTime
0x98
NtsetLocompletion
NTQueryTimer
0x99
NtsetContextThread
NTQueryTimerResolution
0x9a
NtsetDefaultharderrport
NTQueryValueKey
0x9b
NtsetDefaultlocale
NTQueryVirtualMemory
0x9c
NTSETEAFILE
NTQueryvoluMelnformationFile
0x9D
Ntsevent
NTQueueapcthread
0x9e
NTSETHIGHEVENTPAIR
NTRAISEEXCEPTION
0x9f
NTSETHIGHWAITLOWEVENTPAIR
NTRAISEHARDERROR
0xA0
NtSethighWaitLowThread
NTREADFILE
0xa1
NtsetlnformationFile
NTREADFILESCATTER
0xA2
NtsetlnformationKey
NTReadRequestData
0xA3
NtsetlnformationObject
NTReadvirtualMemory
0xA4
NtsetlnformationProcess
NtregisterThreadterminateport
0xa5
NtsetlnFormationthreadthread
NTRELESEMUTANT0XA6
NtsetlnFormationToken
NTRELEASEMAPHORE
0xA7
Ntsetlntervalprofile
NTREMOVELOCOMPLETION
0xA8
Ntsetldtentries
NtreplaceKey
0xA9
NtsetlowEventPair
Ntreplyport
0xAA
NtsetlowWaithigheventpair
NtrePlyWaitreceport
0xAb
NtsetlowWaithighthread
NtrePlyWaitreceivePortex
0xac
NtsetSecurityObject
NtrePlyWaitrepiyport
0xAD
NtsetystemenvironmentValue
NTREQUESTDEVICEWAKEUP
0xae
Ntsetsystemlnformation
NtRequestport
0xAF
NtsetysystemPowerstate
NTREQUESTWAITREPLYPORT
0xB0
NtsetsystemTime
NTREQUESTWAKEUPLATENCY
0xb1
NTSETTIMER
NtRetevent
0xB2
NTSETTIMERRESOLUTION
NTRESETWRITEWATCH
0xB3
NtSetValueKey
NTRESTOREKEY
0xB4
NtsetVoluMelnformationFile
NTRESUMETHREAD
0xB5
NTSHUTDOWNSYSTEM
NtsaveKey
0xB6
NtsignalandWaitForsingleObject
NTSAVEMERGEDKEYS
0xB7
NTStartprofile
NTSecureConnectport
0xB8
NTSTOPPROFILE
NtsetLocompletion
0xB9
NTSUSPENDTHREAD
NtsetContextThread
0xba
NTSystemdebugControl
NtsetDefaultharderrport
0xbb
NTTERMINATEPROCESS
NtsetDefaultlocale
0xBC
NTTERMINATTHREAD
NtsetDefaultuilanguage
0xbd
NTTestalert
NTSETEAFILE
0xbe
NTUNLOADDRIVER
Ntsevent
0xBF
NtunloadKey
NTSETHIGHEVENTPAIR
0xc0
NTUNLOCKFILE
NTSETHIGHWAITLOWEVENTPAIR
0xc1
NTUNLOCKVIRTUALMORY
NtsetlnformationFile
0xc2
NTUNMAPVIEWOFSECTION
NtsetlnformationJobiBObject
0xc3
NTVDMControl
NtsetlnformationKey
0xc4
NTWAITFORMULTIPLEOBJECTS
NtsetlnformationObject
0xc5
NTWAITFORSINGLEOBJECT
NtsetlnformationProcess
0xc6
Ntwaithigheventpair
NtsetlnFormationthreadthread
0xc7
NtwaitLowEventPair
NtsetlnFormationToken
0xc8
Ntwritefile
Ntsetlntervalprofile
0xc9
Ntwritefilegather
Ntsetldtentries
0xca
NtwriteRequestData
NtsetlowEventPair
0xcb
NtwritevirtualMemory
NtsetlowWaithigheventpair
0xcc
NTCReateChannel
NtsetquotalnformationFile
0xcd
Ntlistenchannel
NtsetSecurity O B J ECT
0xce
NTOpenChannel
Ntsetysystemenvironment Value
0xcf
NtrePlyWaitsendchannel
Ntsetsystemlnformation
0xD0
NtsendwaitreplyChannel
Ntsetysystempowersrate
0xD1
NtsetContextChannel
NtsetsystemTime
0xD2
NtyieldExecution
NtSetthReadexecutionState
0xD3
N / a
NTSETTIMER
0xD4
N / a
NTSETTIMERRESOLUTION
0xD5
N / a
NtsetuIDSeed
0xD6
N / a
NtSetValueKey
0xD7
N / a
NtsetVoluMelnformationFile
0xD8
N / a
NTSHUTDOWNSYSTEM
0xD9
N / a
NtsignalandWaitForsingleObject
0xDA
N / a
NTStartprofile
0xDB
N / a
NTSTOPPROFILE
0xDC
N / a
NTSUSPENDTHREAD
0xDD
N / a
NTSystemdebugControl
0xDE
N / a
NTTERMINATEJOBOBJECT
0xDF
N / a
NTTERMINATEPROCESS
0xe0
N / a
NTTERMINATTHREAD
0xe1
N / a
NTTestalert
0xe2
N / a
NTUNLOADDRIVER
0xe3
N / a
NtunloadKey
0xe4
N / a
NTUNLOCKFILE
0xe5
N / a
NTUNLOCKVIRTUALMORY
0xe6
N / a
NTUNMAPVIEWOFSECTION
0xe7
N / a
NTVDMControl
0xe8
N / a
NTWAITFORMULTIPLEOBJECTS
0xe9
N / a
NTWAITFORSINGLEOBJECT
0xea
N / a
Ntwaithigheventpair
0xeb
N / a
NtwaitLowEventPair
0xec
N / a
Ntwritefile
0xed
N / a
Ntwritefilegather
0xee
N / a
NtwriteRequestData
0xef
N / a
NtwritevirtualMemory
0xF0
N / a
NTCReateChannel
0xf1
N / a
Ntlistenchannel
0xf2
N / a
NTOpenChannel
0xF3
N / a
NtrePlyWaitsendchannel
0xF4
N / a
NtsendwaitreplyChannel
0xf5
N / a
NtsetContextChannel
0xf6
N / a
NtyieldExecution 0xF7 N / A
The most important step in Russinoich and Cogewell is to write a built-in device driver to install and maintain Native API Hook. Because modules in user mode do not modify the permissions of the system service descriptor table. Just like the Spy driver in Chapter 4, this is a few special drivers because it does not deal with the usual I / O request. It just exports a simple device I / O control (IOCTL) interface to allow code in user mode to access the data it collected. The main task of the driver is to modify kiserventable, intercept and record the selected Windows 2000 Native API call. Although this method is simple and elegant, it is still worried. It briefly reminds me of the DOS era, Hook a system service only needs to simply modify the processor's interrupt vector table. Anyone who knows how to write basic Windows 2000 kernel drivers can work with any NT system service without the need. Russinovich and Cogswell have developed a very useful Windows NT registry monitor using their technology. When using their technology to complete other "spy" tasks, I will soon become irritated because I need to write a separate Hook API function for each API function I want to monitor. In order to avoid writing a lot of code, I intend to find a way to force all the API functions I am interested in entering the same HOOK function. This task spent a lot of time and showing me a variety of blue screens. However, the final result is that I got a general solution, just cost small efforts, I can hook different API functions collection.
……………..to be continued……………
