How does SysInternal's ProcessMonitor work?

Could someone please give me a high level explanation how they are able to monitor every single registry access?

http://technet.microsoft.com/en-us/sysinternals/bb896645

Enough detail so that i could google around the various sub-topics a开发者_高级运维nd try to write my own one? I know they've used some sort of dll injection/API hooking, but i'm unsure how they reached all the kernel mode activity.

It loads a virtual driver on startup which does the monitoring on a low-level. So it doesn't have to inject anything in other processes.

On http://www.decuslib.com/decus/vmslt00a/nt/filemon.htm there's a short explanation about how FileMon, one of ProcMon's predecessors, works.

How Filemon Works

For the Windows 9x driver, the heart of Filemon is in the virtual device driver, Filevxd.vxd. It is dynamically loaded, and in its initialization it installs a file system filter via the VxD service, IFSMGR_InstallFileSystemApiHook, to insert itself onto the call chain of all file system requests. On Windows NT the heart of Filemon is a file system driver driver that creates and attaches filter device objects to target file system device objects so that Filemon will see all IRPs and FastIO requests directed at drives.

When Filemon sees an open, create or close call, it updates an internal hash table that serves as the mapping between internal file handles and file path names. Whenever it sees calls that are handle based, it looks up the handle in the hash table to obtain the full name for display. If a handle-based access references a file opened before Filemon started, Filemon will fail to find the mapping in it hash table and will simply present the handle's value instead.

Information on accesses is dumped into an ASCII buffer that is periodically copied up to the GUI for it to print in its listbox.

Likewise, Regmon another predecessor is similar:

How Regmon Works

The heart of Regmon on Windows 9x is in the virtual device driver, Regvxd.vxd. It is dynamically loaded, and in its initialization it uses VxD service hooking (see our May 1996 Dr. Dobb's Journal article on VxD service hooking for more information) to insert itself onto the call chain of 16 registry access functions in the Windows 95 kernel (Virtual Machine Manager). All registry activity, be it from 16-bit programs, Win32 applications, or device drivers, are directed at these routines, so Regmon catches all registry activity taking place on a machine.

On Windows NT the Regmon loads a device driver that uses a technique we developed for NT called system-call hooking. When a user-mode component makes a privileged system call, control is transfered to a software interrupt handler in NTOSKRNL.EXE (the core of the Windows NT operating system). This handler takes a system call number, which is passed in a machine register, and indexes into a system service table to find the address of the NT function that will handle the request. By replacing entries in this table with pointers to hooking functions, it is possible to intercept and replace, augment, or monitor NT system services. Regmon, which obviously hooks just the Registry-related services, is merely one example of this capability in action.

When Regmon sees an open, create or close call, it updates an internal hash table that serves as the mapping between key handles and registry path names. Whenever it sees calls that are handle based, it looks up the handle in the hash table to obtain the full name for display. If a handle-based access references a key opened before Regmon started, Regmon will fail to find the mapping in it hash table and will simply present the key's value instead.

Information on accesses is dumped into an ASCII buffer that is periodically copied up to the GUI for it to print in its listbox.

If you like reading code, here's the source code of FileMon and RegMon: http://www.wasm.ru/baixado.php?mode=tool&id=283 (from http://forum.sysinternals.com/topic8038_page1.html)