the microsoft windows nt ® operating system includes a hidden api that the operating system uses internally . this api , which is called the native api , is almost entirely hidden from view , with only a handful of its function documented in generally accessible publications . the windows nt native api serves one purpose : as a means for calling operating system services located in kernel mode in a controlled manner . kernel mode is where the core of nt executes , and it is in kernel mode that components have direct access to hardware and services that perform management of the computer &# 39 ; s resources including memory , devices and processes . thus , whenever a program executing in user mode wants to perform i / o , allocate or deallocate virtual memory , start a thread or process , or interact with global resources , it must call upon one or more services that live in kernel mode . an example of the architecture of the microsoft windows nt ® operating system is shown in fig1 . the microsoft windows nt ® operating system kernel provides two different sets of kernel services : both of them are exported from the kernel executable file ( ntoskrnl . exe ). nt functions are functions that start with “ nt ” and the zw functions are the functions that start with “ zw ”. windows kernel mode device drivers normally call into the nt os kernel using exported zw functions to execute kernel services . 1 . set the previous mode to be a kernel mode 2 . move the requested function index to the eax register 3 . load a pointer to the function parameters to the edx register 4 . call the kisystemservice function to handle the call to the appropriate nt function . an example of assembly language code that implements the zwcreatefile function is as follows : in the user mode space , the operating system kernel exports both the zw and the nt functions . the native api is accessible through an alternate naming convention , one where command names begin with “ zw ” instead of “ nt ”. thus , zwcreatefile ( ) is an alias for ntcreatefile ( ). the zw and nt functions are really identical functions and have the same function address . when called by a user mode application , the zw and nt functions execute a processor special instruction that transfers the execution control from user mode to the kernel mode , the kisystemservice function , which is inside the operating system kernel . as described above , the user - mode nt / zw functions and the kernel mode zw functions call into the kisystemservice function . as shown in fig2 , calls to system services are handled by the system service dispatcher 202 , which in microsoft windows nt ® is the kisystemservice function . kisystemservice maintains a table of the actual nt functions pointers . this table is called the kernel mode system service dispatch table ( ssdt ) 204 . the system service dispatcher 202 takes the requested function index from the eax and the parameters pointer from the edx register and uses them to index 206 into the ssdt 204 to get the actual function pointer 208 . the function pointer 208 is then used to call the system service function 210 . rootkits needs to hide something , whether it is a process , a thread , a file or a registry entry , etc . from user mode applications and from kernel mode device drivers . to achieve that , rootkits have to alter the execution path of the file system , the processes , the threads and the registry functions . in the example shown in fig3 , one technique used by rootkits device drivers is to hook the file system , the process , and the registry query functions inside the ssdt by replacing the functions pointers inside the ssdt table with new pointers , such as rootkit pointer 302 , which points to the rootkit functions 304 . this change of the execution path would affect all nt / zw functions calls made by user mode applications and all zw functions calls made by kernel mode device drivers . however , the change of execution path made by the rootkit does not affect the nt function calls made in kernel mode . some of the typical functions pointers replaced by rootkits device drivers are the following : a process 400 for detecting a rootkit is shown in fig4 . it is best viewed in conjunction with fig5 , which is a data flow diagram of the process shown in fig4 . the process begins with step 402 , in which the real addresses of the nt functions inside the nt os kernel are determined . for example , the nt os kernel export tables can be accessed to provide these addresses , since the nt functions are exported from the binary . in step 404 , the ssdt 204 is scanned to find modifications that have been made to the ssdt 204 . this is done by comparing each real address obtained in step 402 with the addresses found in the table . if any of the addresses in the ssdt 204 are different than the real address of the nt function , this means that the ssdt has been modified . the process will then continue with step 406 , in which a rootkit detector 502 software , which includes a kernel mode device driver , calls into the nt functions inside the nt os kernel . for example , rootkit detector 502 issues calls 504 to nt functions , which directly access system services 210 . the results 506 of the calls are returned to rootkit detector 502 . in step 404 , rootkit detector 502 issues calls to the zw functions that correspond to the nt functions that were called in step 402 . for example , rootkit detector 502 issues calls zw functions , which call the system service dispatcher 202 , which uses ssdt 204 to access system services 210 . these zw calls cause the rootkit functions 304 to be called , which modifies the function and / or results of the call . the results 510 of the zw calls are returned to the rootkit detector . in step 406 , the results 506 of the calls to the nt functions and the results 506 of the calls to the zw functions are compared . in step 408 , the difference between the results obtained from nt and zw calls are used to identify hidden processes , registry entries , threads , files , etc . a block diagram of an exemplary computer system 600 , in which the present invention may be implemented , is shown in fig6 . computer system 600 is typically a programmed general - purpose computer system , such as a personal computer , workstation , server system , and minicomputer or mainframe computer . computer system 600 includes processor ( cpu ) 602 , input / output circuitry 604 , network adapter 606 , and memory 608 . cpu 602 executes program instructions in order to carry out the functions of the present invention . typically , cpu 602 is a microprocessor , such as an intel pentium ® processor , but may also be a minicomputer or mainframe computer processor . although in the example shown in fig6 , computer system 600 is a single processor computer system , the present invention contemplates implementation on a system or systems that provide multi - processor , multi - tasking , multi - process , multi - thread computing , distributed computing , and / or networked computing , as well as implementation on systems that provide only single processor , single thread computing . likewise , the present invention also contemplates embodiments that utilize a distributed implementation , in which computer system 600 is implemented on a plurality of networked computer systems , which may be single - processor computer systems , multi - processor computer systems , or a mix thereof . input / output circuitry 604 provides the capability to input data to , or output data from , computer system 600 . for example , input / output circuitry may include input devices , such as keyboards , mice , touchpads , trackballs , scanners , etc ., output devices , such as video adapters , monitors , printers , etc ., and input / output devices , such as , modems , etc . network adapter 606 interfaces computer system 600 with network 610 . network 610 may be any standard local area network ( lan ) or wide area network ( wan ), such as ethernet , token ring , the internet , or a private or proprietary lan / wan . memory 608 stores program instructions that are executed by , and data that are used and processed by , cpu 602 to perform the functions of the present invention . memory 608 may include electronic memory devices , such as random - access memory ( ram ), read - only memory ( rom ), programmable read - only memory ( prom ), electrically erasable programmable read - only memory ( eeprom ), flash memory , etc ., and electro - mechanical memory , such as magnetic disk drives , tape drives , optical disk drives , etc ., which may use an integrated drive electronics ( ide ) interface , or a variation or enhancement thereof , such as enhanced ide ( eide ) or ultra direct memory access ( udma ), or a small computer system interface ( scsi ) based interface , or a variation or enhancement thereof , such as fast - scsi , wide - scsi , fast and wide - scsi , etc , or a fiber channel - arbitrated loop ( fc - al ) interface . memory 608 includes rootkit detector 502 , rootkit 612 , and operating system kernel 612 . rootkit detector 502 includes a kernel mode device driver and issues calls to nt functions , which directly access system services 210 , and issues calls to the zw functions , which correspond to the nt functions , which call the system service dispatcher 202 , which uses ssdt 204 to access system services 210 . rootkit 612 is a set of software tools intended to conceal running processes , files or system data , thereby helping an intruder to maintain access to a system whilst avoiding detection . rootkit 612 includes rootkit functions 304 , which are used by rootkit 612 to examine or modify calls to the kernel mode zw functions and / or the user mode nt and zw functions . operating system 614 includes system service dispatcher 202 , which handles calls to system services , ssdt 204 , which is a table of pointers to the actual nt functions , system services 210 , which are software routines and processes that perform system functions , and operating system ( os ) kernel 616 , which provides overall system functionality . it is important to note that while the present invention has been described in the context of a fully functioning data processing system , those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in the form of a computer readable medium of instructions and a variety of forms and that the present invention applies equally regardless of the particular type of signal bearing media actually used to carry out the distribution . examples of computer readable media include recordable - type media such as floppy disc , a hard disk drive , ram , and cd - rom &# 39 ; s , as well as transmission - type media , such as digital and analog communications links . although specific embodiments of the present invention have been described , it will be understood by those of skill in the art that there are other embodiments that are equivalent to the described embodiments . accordingly , it is to be understood that the invention is not to be limited by the specific illustrated embodiments , but only by the scope of the appended claims .