当前位置：文江博客话题详情

SysInternal 的 ProcessMonitor 如何工作？

发布于 2024-10-15 00:03:15 字数 276 浏览 1 评论 0原文

有人可以给我一个高级解释他们如何能够监控每个注册表访问吗？

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

足够的细节，以便我可以谷歌搜索各个子主题并尝试编写自己的子主题？我知道他们使用了某种 dll 注入/API 挂钩，但我不确定他们如何实现所有内核模式活动。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

极致的悲 2024-10-22 00:03:15

它在启动时加载一个虚拟驱动程序，该驱动程序在低级别上进行监视。所以它不必在其他进程中注入任何东西。

在 http://www.decuslib.com/decus/vmslt00a/nt/filemon。 htm 有一个关于 FileMon（ProcMon 的前身之一）如何工作的简短说明。

Filemon 的工作原理
对于 Windows 9x 驱动程序，Filemon 的核心在于虚拟
设备驱动程序，Filevxd.vxd。它是动态加载的，并且在其
初始化它通过VxD服务安装文件系统过滤器，
IFSMGR_InstallFileSystemApiHook，将自身插入到调用链中
所有文件系统请求。在 Windows NT 上，Filemon 的核心是
文件系统驱动程序创建和附加过滤设备的驱动程序
对象到目标文件系统设备对象，以便 Filemon 能够看到
所有针对驱动器的 IRP 和 FastIO 请求。
当 Filemon 看到
open、create 或 close 调用，它更新一个内部哈希表
用作内部文件句柄和文件路径之间的映射
名称。每当它看到基于句柄的调用时，它都会查找
哈希表中的句柄以获取显示的全名。如果一个
基于句柄的访问引用 Filemon 启动之前打开的文件，
Filemon 将无法在其哈希表中找到映射，并且只会
相反，显示句柄的值。
有关访问的信息被转储到 ASCII 缓冲区中
定期复制到 GUI 以便在其列表框中打印。

同样，Regmon 另一个前身也类似：

Regmon 的工作原理
Windows 9x 上 Regmon 的核心在于虚拟设备驱动程序，
Regvxd.vxd。它是动态加载的，并且在初始化时它
使用 VxD 服务挂钩（请参阅我们 1996 年 5 月的 Dr. Dobb's Journal 文章
有关 VxD 服务挂钩的更多信息）将其自身插入到
Windows 95内核中16个注册表访问函数的调用链
（虚拟机管理器）。所有注册表活动，无论是 16 位的
程序、Win32 应用程序或设备驱动程序都针对这些
例程，因此 Regmon 捕获发生在某个计算机上的所有注册表活动
机器。
在 Windows NT 上，Regmon 加载使用某种技术的设备驱动程序
我们为 NT 开发了称为系统调用挂钩的功能。当用户模式
组件进行特权系统调用，控制权转移到
NTOSKRNL.EXE（Windows NT 的核心）中的软件中断处理程序
操作系统）。该处理程序采用系统调用号，即
传入机器寄存器，并索引到系统服务表中
查找将处理请求的 NT 函数的地址。
通过用指向挂钩函数的指针替换该表中的条目，
可以拦截、替换、增强或监视 NT 系统
服务。 Regmon，显然只挂钩与注册表相关的
服务只是此功能实际应用的一个示例。
当 Regmon 看到 open、create 或 close 调用时，它会更新内部
哈希表用作键句柄和注册表之间的映射
路径名称。每当它看到基于句柄的调用时，它就会查找
哈希表中的句柄来获取显示的全名。如果一个
基于句柄的访问引用 Regmon 启动之前打开的密钥，
Regmon 将无法在其哈希表中找到映射，并且只会
相反，显示键的值。
有关访问的信息被转储到 ASCII 缓冲区中
定期复制到 GUI 以便在其列表框中打印。

如果您喜欢阅读代码，这里是 FileMon 和 RegMon 的源代码： http: //www.wasm.ru/baixado.php?mode=tool&id=283（来自 http://forum.sysinternals.com/topic8038_page1.html）

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.