SysInternal 的 ProcessMonitor 是如何工作的? [英] 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
足够详细，以便我可以搜索各种子主题并尝试编写自己的子主题?我知道他们使用了某种 dll 注入/API 挂钩，但我不确定他们是如何达到所有内核模式活动的.
Enough detail so that i could google around the various sub-topics and 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.
在 http://www.decuslib.com/decus/vmslt00a/nt/filemon.htm 有一个关于 ProcMon 的前身之一 FileMon 如何工作的简短说明.
On http://www.decuslib.com/decus/vmslt00a/nt/filemon.htm there's a short explanation about how FileMon, one of ProcMon's predecessors, works.
Filemon 的工作原理
对于 Windows 9x 驱动程序，Filemon 的核心在于虚拟设备驱动程序，Filevxd.vxd.它是动态加载的，并且在其初始化它通过 VxD 服务安装文件系统过滤器，IFSMGR_InstallFileSystemApiHook，将自身插入调用链所有文件系统请求.在 Windows NT 上，Filemon 的核心是文件系统驱动程序创建和附加过滤器设备的驱动程序目标文件系统设备对象，以便 Filemon 将看到指向驱动器的所有 IRP 和 FastIO 请求.
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.
当 Filemon 看到一个打开、创建或关闭调用，它会更新一个内部哈希表用作内部文件句柄和文件路径之间的映射名字.每当它看到基于句柄的调用时，它就会查找哈希表中的句柄以获取显示的全名.如果一个基于句柄的访问引用在 Filemon 启动之前打开的文件，Filemon 将无法在它的哈希表中找到映射，并且只会简单地而是显示句柄的值.
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.
有关访问的信息被转储到一个 ASCII 缓冲区中，该缓冲区是定期复制到 GUI 以在其列表框中打印.
Information on accesses is dumped into an ASCII buffer that is periodically copied up to the GUI for it to print in its listbox.
同样，Regmon 另一个前身也类似:
Likewise, Regmon another predecessor is similar:
Regmon 的工作原理
Windows 9x 上 Regmon 的核心在于虚拟设备驱动程序，Regvxd.vxd.它是动态加载的，并在初始化时使用 VxD 服务挂钩(请参阅我们 1996 年 5 月的 Dobb 博士的期刊文章有关 VxD 服务挂钩的更多信息)将自身插入到Windows 95内核中16个注册表访问函数的调用链(虚拟机管理器).所有注册表活动，无论是 16 位程序、Win32 应用程序或设备驱动程序是针对这些例程，因此 Regmon 捕获发生在机器.
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.
在 Windows NT 上，Regmon 加载一个设备驱动程序，该驱动程序使用一种技术我们为 NT 开发的称为系统调用挂钩.当用户模式组件进行特权系统调用，控制权转移到NTOSKRNL.EXE 中的软件中断处理程序(Windows NT 的核心操作系统).这个处理程序接受一个系统调用号，即传入机器寄存器，并索引到系统服务表中找到将处理请求的 NT 函数的地址.通过用指向挂钩函数的指针替换此表中的条目，可以拦截和替换、增强或监视 NT 系统服务.Regmon，它显然只挂钩与注册表相关的服务，只是这种能力的一个例子.
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.
当 Regmon 看到一个 open、create 或 close 调用时，它会更新一个内部用作键句柄和注册表之间的映射的哈希表路径名称.每当它看到基于句柄的调用时，它就会查找哈希表中的句柄以获取显示的全名.如果一个基于句柄的访问引用在 Regmon 启动之前打开的密钥，Regmon 将无法在它的哈希表中找到映射，并且只会简单地而是显示键的值.
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.
有关访问的信息被转储到一个 ASCII 缓冲区中，该缓冲区是定期复制到 GUI 以在其列表框中打印.
Information on accesses is dumped into an ASCII buffer that is periodically copied up to the GUI for it to print in its listbox.
如果你喜欢阅读代码，这里是 FileMon 和 RegMon 的源代码:http://www.wasm.ru/baixado.php?mode=tool&id=283(来自 http://forum.sysinternals.com/topic8038_page1.html)
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)
这篇关于SysInternal 的 ProcessMonitor 是如何工作的?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
