通过替换为 NOP 来修补 CALLL 在用户空间中有效，但在内核空间中无效
我有一个想要修补的设备驱动程序。 该设备驱动程序调用 IOLog，我想摆脱日志记录。
如果我用设备驱动程序 (kext) 内的（相应数量的）NOP 替换对 IOLog 的 CALLL，则内核会崩溃，堆栈看起来像是破碎的（“Backtrace 终止 - 无效帧指针 0”）。
然而，同样的技术在用户空间中工作得很好（例如，在 OS X 二进制文件中 NOPping NSLogs）。
我在这里缺少什么？
I have a device driver I want to patch.
This device driver calls IOLog and I want to get rid of the logging.
If I replace the CALLL to IOLog with (the corresponding number of) NOPs inside the device driver (kext), the kernel crashes with what looks like a smashed stack ("Backtrace terminated-invalid frame pointer 0").
The same technique however, works fine in user-space (e.g. NOPping NSLogs inside an OS X binary).
What am I missing here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您没有解释是否进行冷补丁（磁盘上的驱动程序）或热补丁（内存中的驱动程序）。 对于内存中修补，可能存在各种问题，例如修补驱动程序时执行的驱动程序、缓存部分代码的 CPU 等。请参阅 Intel 手册中有关自修改代码的部分。
对于磁盘上修补，您可能有目标地址的重定位记录。 因此，当驱动程序加载时，动态模块加载器将修复代码中IOLog的地址，将其替换为真实地址。 这将覆盖您的 nop 指令。
You didn't explain whether you do cold patching (driver on disk) or hot patching (driver in memory). For in-memory patching, all kinds of issues might exist, such as the driver being executed when you patch it, the CPU(s) having cached portions of the code, etc. See the Intel manual section on self-modifying code.
For on-disk patching, it might be that you have a relocation record for the target address. So when the driver is loaded, the dynamic module loader will fixup the address of IOLog in the code, replacing it with the real address. This will overwrite your nop instructions.