如何保护我的 .NET 应用程序免受 DLL 劫持？
我们有一个带有注册扩展的 .NET 3.5 应用程序。我们如何保护它免受 DLL 劫持攻击？
因为遗留问题和设计问题强命名/签名现在不是一个选项
如果您不知道什么是 DLL 劫持，请提供额外信息：
We have a .NET 3.5 application with registered extensions. How can we protect it against DLL Hijacking attacks?
Because of legacy & design problems strong naming/signing is not an option right now
Extra Information if you don't know what DLL Hijacking is:
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我遇到过类似的问题，我最终编写了自己的逻辑来验证 dll。对我来说，我只是以 LGPL 方式使用该 dll（我无法修改该 dll），但想确保我的应用程序使用正版 dll（而不是被劫持的 dll）。
简单的解决方案：
更好的解决方案：
如果您有任何证书来自威瑞信等受信任 CA 的证书，您可以使用该证书而不是使用 RSA 密钥值对。
这样，即使有人用破解的 dll 替换了您的 dll，哈希值也不会匹配，您的应用程序也会知道劫持尝试。
这种方法可能比只给 dll 一个强名称更好，因为可以通过运行来禁用强名称验证
希望这对您或想要了解数字签名内部工作原理的人有帮助。
I had came across similar issue, I had ended up writing my own logic for verifying the dll. For me I was just using that dll in LGPL fashion (I can't modify the dll), but wanted to make sure that my application uses the genuine dll (not the hi-jacked one).
Simple solution:
Better solution:
If you have any certificate from trusted CA like verisign, you can use that certificate instead of using RSA key value pair.
This way even if someone replaces your dll with cracked dll, the hash will not match and your application will know the Hijacking attempt.
This approach could is better than only giving dll a strong name because, may be strong name verification can be disabled by running
Hope this helps you, or someone who wants to understand how digital signature things work internally.
看看这个线程....它可能帮助你并给你洞察力......另一件事，你当然可以查看EasyHook，并拦截API createRemoteThread 并查明 DLL 是否是未经授权的DLL之一....看看这个 线程 解释如何阻止 dll 注入
Have a look at this thread....it might help you and give you insight....another thing, you can certainly check out EasyHook, and intercept the API createRemoteThread and find out if the DLL is one of the unauthorized ones.... have a look at this thread that explains how to block against dll injection
难道您不能将 dll 作为资源包含并在运行时将其写出到您想要的位置，然后将 dll 加载到程序集中吗？我这样做了一次，因为我们想作为一个 .exe 分发，但我认为它也可以解决这个问题，不是吗？
Couldn't you include the dll as a resource and write it out to where you want at run time then load the dll into the assembly? I did this once because we wanted to distribute as one .exe but I think it would also solve this problem, wouldn't it?
罗伯特，
公平地回答吉姆关于“那会是什么样的设计”的问题。通过回答，而不是仅仅说“事情就是这样”，您可以让我们深入了解我们的建议/解决方案必须受到的限制。
换句话说，如果不知道为什么遗留代码会阻止您以“正确的方式”进行操作，就很难为您的问题提供理想的解决方法。
除非您的架构阻止 Vishalgiri 建议的 MD5 校验和想法，否则我建议您采纳他的建议。不过，如果不知道什么应用程序调用这些 DLL 以及为什么它们无法签名，就很难知道这是否适合您。
我的想法可能更简单，但是您不能调整您的应用程序以从预定义位置预加载 DLL 吗？例如，只允许它从主应用程序的 BIN 文件夹加载，如果失败 - 不再尝试？
有关如何从不同路径加载的信息，请参阅此链接：http://www.chilkatsoft.com/p /p_502.asp
这可能比编写所有 MD5 校验和代码更快。尽管我也喜欢这个想法。
Robert,
In fairness to Jim's question about "what kind of design would that be". By answering, instead of just saying "it is what it is" you could give us insight into the constraints our suggestions/solutions must fall within.
Put another way, without knowing why the legacy code prevents you from doing it the "right way" it's hard to provide ideal workarounds to your problem.
Unless your architecture prevents the MD5 checksum idea suggested by Vishalgiri, I'd suggest taking his advice. Again though, without knowing what application(s) call these DLLs and why they can't be signed, it's hard to know if this will work for you.
My idea might be a lot simpler, but can you not adjust your application to preload the DLL from a predefined location? For example, only allow it to load from the BIN folder of your main applicaton, and failing that - never try again?
See this link on how to load from a distinct path: http://www.chilkatsoft.com/p/p_502.asp
This may be faster than writing all the MD5 checksum code. Even though I like that idea as well.
如果您的应用程序要进行混淆，那么在混淆之前首先使用 ILMerge 将 DLL 与 EXE 合并，将提供针对 DLL 劫持的绝对保护，并且还会消除未使用的代码并为您提供独立的 EXE。
If your application is meant to be obfuscated, merging the DLL with the EXE first using ILMerge before obfuscation would provide absolute protection against DLL hijacking and also eliminates unused code and gives you a standalone EXE.
如果您有文件夹/数据访问权限，您可以编写代码，在调用您自己的 .DLL（或搜索整个驱动器）之前，主动去 Windows 查找您的 .DLL 的相同位置进行查找，并且您可以计算 CRC 检查为您的合法 DLL 或其他模式匹配来比较您的合法 DLL 与已定位的匹配 DLL 文件，从而确保没有其他人劫持您（将文件放置在将在您自己的位置之前搜索的位置 - 或甚至任何位置）。这可能需要对不同版本的 Windows 下不同搜索顺序的方法进行一些研究。然后，如果您发现劫持企图，您可以采取一些行动，具体取决于您对有人试图劫持您的 DLL 的确定程度...重命名 faker.DLL，删除它，通知用户，通知管理员，不要这样做不调用你的DLL等。
If you have folder/data access priveledges, you could write code to proactively go and look in the same places Windows looks for your .DLL prior to calling your own .DLL (or search the whole drive), and you could compute a CRC check for your legit DLL, or other pattern match to compare your legit.DLL on located, matching DLL files, and thus make sure no one else has hijacked you (placed a file in a location that would be searched prior to your own location - or even any location). This could take some research into the methodology under different versions of Windows for the various orders of searches. Then, if you find a hijacking attempt, you could take some action, depending on how sure you are that someone is trying to hijack your DLL... Rename the faker.DLL, delete it, notify the user, notify admin, don't call your DLL, etc.