“安全” DLL注入
抱歉，这不是一个很好的问题。
我有一个程序，当从资源管理器打开文件时需要发出警报（即调用 ShellExecute(A/W)）。
不幸的是，微软删除了允许您在 Vista 及更高版本中挂钩这些事件的 COM 接口 (IShellExecuteHook)，据说是因为旧代码可能会因更改而导致崩溃。有一个解决方法可以重新启用此功能，但它不再起作用。
我做了一些研究，看起来捕获对 ShellExecute 调用的唯一方法是将调用重新路由到 shell32.dll。目前，我正在考虑将我自己的 DLL 注入到资源管理器进程中，然后将 ShellExecute 的 IAT 条目复制到我的 DLL 中的某个地址分配，最后修改 ShellExecute 的 IAT 条目以指向我的函数，这将通知程序打开一个文件并跳转到我们之前存储的原始 ShellExecute 函数的地址。
我最关心的是防病毒软件。他们会关心我注入资源管理器吗？他们会关心我修改 IAT 吗？
另一个问题是这是否安全；浏览器的安全权限是否有可能（或者更可能）不允许通过 CreateRemoteThread 进行注入？如果是的话，有没有更好的方法来进行这种注射？
一般来说有更好的方法吗？
编辑：对于将来遇到此问题的任何人，explorer.exe 没有 shell32.dll 的 IAT；它有一个标头，但 thunk 充满了垃圾值，因此（据我所知）无法检索任何导入函数的条目。
看起来代码隧道是挂钩这个的唯一方法。
Not a terribly good question, sorry.
I have a program that needs to be alerted when a file is opened from explorer (i.e. ShellExecute(A/W) is called).
Unfortunately, Microsoft removed the COM interface (IShellExecuteHook) that allows you to hook these events in Vista and up, supposedly because older code could cause a crash due to changes. There was a work-around to re-enable this feature, but it no longer works.
I've done some research and it looks like the only way to catch calls to ShellExecute is to re-route the call to shell32.dll. At the moment, I'm looking at injecting my own DLL into the explorer process, then copying the IAT entry for ShellExecute to some address allocation in my DLL, and finally modifying the IAT entry for ShellExecute to point to my function, which will notify the program that a file was opened and jump to the original ShellExecute function, whose address we stored earlier.
My biggest concern here is antiviruses. Will they care that I'm injecting into explorer? Will they care that I'm modifying the IAT?
Another concern is whether this is safe; is it possible (or rather likely) for explorer's security priveleges to not allow injection via CreateRemoteThread? If so, is there a better way to do this injection?
Is there a better way to do this in general?
EDIT: For anyone who comes across this in the future, explorer.exe has no IAT for shell32.dll; it has a header, but the thunk is full of junk values, so there's no way (as far as I can tell) to retrieve the entry for any imported functions.
Looks like code tunneling is the only way to hook this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
大多数优秀的防病毒启发式方法都应该将导入表修补视为特洛伊木马的危险信号。
madcodehook 的在线文档有一些关于各种代码注入技术及其优点/缺点的扩展文章，并且 API 提供了一些用于指定“安全”挂钩的选项：
http://www.madshi.net/madCodeHookDescription.htm
Most good antivirus heuristics should pick up on import table patching as being a red flag for a trojan.
The online documentation for madcodehook has some extended articles on various code injection techniques, their benefits/drawbacks, and the API provides some options for specifying "safe" hooking:
http://www.madshi.net/madCodeHookDescription.htm
Detours 库：
http://research.microsoft.com/en-us/projects /detours/
来自微软研究院，允许任意挂钩函数。你可以尝试一下。
The Detours library:
http://research.microsoft.com/en-us/projects/detours/
From Microsoft Research allows arbitrary hooking of functions. You might give that a shot.
有关 API 挂钩的更多资源：
Easy hook：http://www.codeplex.com/easyhook
Deviare ：http://www.nektra.com/products/deviare-api- hook-windows/
一篇有趣的文章：http://www.codeproject。 com/KB/system/hooksys.aspx
在进行 API 挂钩时，评估需要在哪些环境中运行非常重要。
例如，并非所有库都支持 x86/x64。
Detours 仅在许可（付费）版本中支持 x64。
Easy hook 支持 x86 和 x64。
Some more resources on API hooking:
Easy hook: http://www.codeplex.com/easyhook
Deviare: http://www.nektra.com/products/deviare-api-hook-windows/
An interesting post: http://www.codeproject.com/KB/system/hooksys.aspx
When doing API hooking it is very important to asses in which environments you need to run.
Not all libraries support x86/x64 for example.
Detours only supports x64 in the licensed (payed) version.
Easy hook supports x86 and x64.
Windows Vista 和 Windows 7 中的 Windows 资源管理器甚至不调用 ShellExecuteA 或 ShellExecuteW。
没有必要打扰。哈哈 :-)
并且，如果我可以补充的话，我已经通过使用 32 位和 64 位内联挂钩来挂钩这两个函数进行了测试。
对不起。哈哈 ：-）
Windows Explorer in Windows Vista and Windows 7 doesn't even call ShellExecuteA or ShellExecuteW.
No point bother. Lol :-)
AND, if i may add, i have tested by hooking both functions with both 32 bit and 64 bit inline hooks.
Sorry. Lol :-)