如何防止 DLL 注入
所以有一天，我看到了这个：
http://www.edgeofnowhere.cc/viewtopic.php?p=2483118
它介绍了 DLL 注入的三种不同方法。 我将如何防止这些过程发生？ 或者至少，我如何防止第一个？
我在想，也许 Ring 0 驱动程序可能是阻止这三个驱动程序的唯一方法，但我想看看社区的想法。
So the other day, I saw this:
http://www.edgeofnowhere.cc/viewtopic.php?p=2483118
and it goes over three different methods of DLL injection. How would I prevent these from the process? Or at a bare minimum, how do I prevent the first one?
I was thinking maybe a Ring 0 driver might be the only way to stop all three, but I'd like to see what the community thinks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
最好的技术解决方案是采取一些措施，导致加载程序代码在进程初始化后无法正常运行。 实现此目的的一种方法是获取 NT 加载程序锁，这将有效防止发生任何加载程序操作。 其他选项包括直接在内存中修补加载程序代码，以使攻击者对 LoadLibrary 的调用失败（例如插入 int3 断点和自调试以处理预期情况）。
但是以黑客的身份（管理您链接到的站点的人）来说，事实上），你永远不会阻止人们以某种方式将代码添加到你的流程中。 LoadLibrary 恰好是一个方便的快捷方式，但是有大量不同的手动加载代码的方法，您永远无法希望完全停止，除非有一些极其复杂的ring0代码。 即使您确实进入了ring0，黑客也会就在您身边。
此外，DLL 注入还有很多合法用途。 主题程序、辅助工具以及扩展操作系统功能的各种程序都可以使用 DLL 注入来为任何程序提供附加功能。
The best technical solution would be to do something that causes the loader code to not be able to run properly after your process initializes. One way of doing this is by taking the NT loader lock, which will effectively prevent any loader action from taking place. Other options include patching the loader code directly in memory to make calls to LoadLibrary fail for the attacker (e.g. insert an int3 breakpoint and self-debug to handle expected cases)..
But speaking as a hacker (one who admins the site you linked to, in fact), you're not going to ever stop people from getting code into your process, one way or another. LoadLibrary just happens to be a handy shortcut, but there are tons of different ways to load code manually that you could never hope to stop entirely, short of some extremely involved ring0 code. And even if you do go to ring0, the hackers will be right there beside you.
Also, there are plenty of legitimate uses for DLL injection. Theme programs, accessibility tools, and various programs that extend OS functionality can all potentially use DLL injection to give added functionality to any program.
如何防御这 3 种技术：
CreateRemoteThread
您可以通过挂接 LoadLibrary 来阻止第一种技术（调用 LoadLibrary 的 CreateRemoteThread）。 在您的钩子中，您可以检查您知道是进程一部分并且可能会加载的 DLL 名称列表，也可以检查您不想加载的已知 DLL 列表。
当您找到不想加载的 DLL 时，SetLastError(ERROR_ACCESS_DENIED) 然后返回 NULL。 我设置了最后一个错误，以便编写寻找错误代码的代码的人得到一个。 这似乎可行，也许不同的代码可能更合适。
这将阻止 DLL 加载。
SetWindowsHookEx
我认为用于 CreateRemoteThread 阻塞的相同技术也适用于 SetWindowsHookEx，但前提是您可以在 SetWindowsHookEx 技术开始加载其代码之前安装挂钩（通常是在应用程序中创建第一个窗口时 - 如此早期）寿命）。
Code Cave
技术不错。 以前没见过。 您可以防御这种情况，但您必须挂钩 LoadLibrary 入口点（而不是 IAT 表），因为 Code Cave 直接调用 LoadLibrary。
正如该文章的作者所评论的那样 - 您可能会受到多种攻击，并且您可能很难击败所有这些。 但通常您只想防御某些 DLL 加载（例如与您的软件不兼容的特定第 3 方 DLL，因为第 3 方 DLL 未正确编写以适应另一个钩子也可能存在的事实，因此您阻止它从加载）。
How to defend against those 3 techniques:
CreateRemoteThread
You can prevent the first technique (CreateRemoteThread which calls LoadLibrary) by hooking LoadLibrary. In your hook you check against a list of DLL names that you know are part of the process and that may be loaded, or you can check against a list of known DLLs you don't want to load.
When you find a DLL you don't want to load SetLastError(ERROR_ACCESS_DENIED) then return NULL. I set the last error so that people that write code looking for an error code get one. This appears to work, perhaps a different code may be more appropriate.
That will stop the DLL from loading.
SetWindowsHookEx
I think the same technique for CreateRemoteThread blocking will work for SetWindowsHookEx, but only if you can get your hook installed before the SetWindowsHookEx technique has started loading its code (which is typically when the first Window is created in an app - so early in its lifetime).
Code Cave
Nice technique. Not seen that before. You can defend against this, but you'll have to hook the LoadLibrary entry point (not the IAT table) as the Code Cave calls LoadLibrary directly.
As the author of the article commented - there are many ways you can be attacked and you probably will have a hard time defeating them all. But often you only want to defend against certain DLL loads (such as a particular 3rd party DLL that is incompatible with your software because the 3rd party DLL wasn't written properly to accomodate the fact that another hook may also be present, so you block it from loading).
最好的方法是确保没有不受信任的进程获得管理员访问权限，或者以与应用程序相同的用户帐户运行。 如果没有此访问权限，则无法将代码注入到您的应用程序中； 一旦这样的进程获得了该访问权限，它就可能会导致各种恶作剧，而无需将自身注入到另一个进程中 - 注入只会使其更容易隐藏。
The best way would be to ensure no untrusted process gets Administrator access, or runs as the same user account as your application. Without this access, code injection into your application is not possible; and once such a process gets that access, it can cause all kinds of mischief without needing to inject itself into another process - the injection just makes it easier to hide.
由于这张海报暗示他正在投资游戏反黑客，让我阐明一下我的想法。 作为一个前骗子。
只是关于游戏反黑客的提示。
最好的方法是让服务器运行核心游戏逻辑。 例如，在第一人称射击游戏中，监视客户端发送到服务器的动作。 不要让他们随意走动。 让服务器根据自己的逻辑告诉客户端每个玩家的位置。 永远不要只是转发命令。 它们可能是假的。
谁在乎黑客是否入侵了自己的客户？ 只要拒绝其他的，一切都很好。 对于星际争霸maphacks，解决方案很简单。 不要为应该未知的区域提供游戏状态。 它还可以节省带宽。
我在《三角洲特种部队》（这是一款老游戏）中是个大骗子。 我使用的主要技巧是通过直接修改进程内存来扭曲游戏中的任何位置。 无需 DLL！
Since this poster alludes that he is investing game anti-hacking, let me shed some light on what I think. As a ex cheater.
Just a pointer about game anti-hacking.
The best way is to let the server run the core game logic. e.g. In a first person shooter, monitor movements the clients send to the server. Don't allow them to move around at random. Let the server tell the clients where each player is based on its own logic. Don't ever just forward commands. They could be bogus.
Who cares if the hacker hacks his own client? just refuse it on the other ones and all is good. For starcraft maphacks, solution is simple. Don't give out gamestate for areas that should be unknown. It saves bandwidth too.
I was a big cheater in Delta Force (its an old game). The main trick I used was to warp anywhere in the game by modifying the process memory directly. No DLL required!
那么您是否正在寻找 Ring3 解决方案？ 如果是这样，您希望在系统中构建当前（至少据我所知）未提供的额外功能，因此需要做一些工作。 此外，这可以通过驱动程序实现，事实上，大多数 AV 软件都会定期执行此类活动。
至于从用户模式停止上述方法，它会变得有点棘手，因为你不能只是将自己注册为进程创建或 DLL 加载的回调。 但是，如果您假设您的进程先于他们的进程启动，则可以全局挂接 CreateRemoteThread 和类似函数并自行执行此类检查。
因此，实际上您需要检查 CreateRemoteThread 想要在哪里创建线程，如果您对此不满意，则返回错误。
这将否定前两种方法。 对于第三种方法，如果磁盘上有原始程序的有效哈希值，那么您始终可以在加载之前检查哈希值。 如果您没有哈希值，您至少可以检查一些有人会添加该类型代码的简单位置，并查找您不希望出现的 DLL（例如 IAT 或运行字符串）。
它并不是万无一失的，但它似乎提供了您所要求的功能。
Are you looking for a Ring3 solution then? If so, you're wanting to build additional functionality into the system that is not currently ( at least to my knowledge ) provided out-of-the-box, so it will require some bit of work. Also, this is possible from a driver, in fact most of your AV software performs this type of activity regularly.
As for stopping the above methods from user-mode, it gets a bit trickier since you can't just register yourself as a call back to process creation or DLL loading. You can, however, if you assume your process has started before theirs, hook CreateRemoteThread and similar functions globally and perform this type of checking yourself.
So in effect you'd want to check where CreateRemoteThread wants to create a thread and return an error if you're not happy with it.
This would negate the first two methods. For the third method, if you have valid hashes of the original program on disk, then you could always check the hash before loading it. If you're without hashes, you could at least just check some of the simple places someone would add that type of code and look for DLLs you don't expect to be there (e.g. the IAT, or run strings).
It's not fool-proof, but it appears to give the functionality you requested.
只是供讨论的简要想法:)
使用 Code Cave 将 CRC 检查注入您自己的代码中可能会减慢其他人使用其他 Code Cave 的速度。
轮询进程模块列表以查找正在加载的未知 dll 可能有助于减慢人们通过附加线程和消息挂钩注入任何旧东西的速度。
Just brief thoughts for discussion :)
Using a code cave to inject a CRC check into your own code will perhaps slow down others from using other code caves.
Polling the process module list for unknown dll's being loaded might help with slowing down people just injecting any old thing with attach thread and message hooks.
为什么要阻止这种情况发生？ 这是实际的“业务”需求，还是您只是对“黑客”感兴趣以反对“黑客”
如果用户权限允许这样做，这是设计使然 - 操作系统向您<的所有用户提供设施/em>，系统管理员已分配给他们运行的帐户。
Raymond Chen 很快就会链接到这里......
Why do you want to prevent this? Is it an actual 'business' need, or are you just interested in a 'hack' to oppose the 'hack'
If the user rights permit this, it's by design - the OS provides the facility to all users that you, the administrator of the system have assigned to the accounts under which they run.
Raymond Chen's going to be linking here soon...
我对 Windows API 不太熟悉，但我可以为您提供一些更通用的指导：
看看您是否可以使用 Windows 数据执行保护 (DEP)。 它可能不适用于所有（阅读：大多数）情况，因为从操作系统的角度来看，链接中概述的过程是有效的过程。 纵深防御
确保您的进程方法在整个应用程序中声明安全权限
静态分配内存空间，以便在其中生成的任何新线程都将失败或覆盖现有内存空间； 你可能需要一大块
静态地分配内存空间，
将您的代码分解到设备驱动程序或其他一些低级类型进程中，您可以将其纳入 Windows 文件保护保护范围内。
刚刚看到 Cthulon 的答案，我担心他可能是正确的：任何想要在您的应用程序上执行代码注入的人都会找到一种方法来做到这一点。 上述步骤可能只会让事情变得更加困难。
希望这可以帮助
I'm not intimately familiar with the Windows API, but I can give you some more generalized pointers:
See if you can use Windows Data Execution Prevention (DEP). It will probably not work for all (read: most) situations, because the process outlined in your link is a valid process from the OS's standpoint. Defense in depth though
Ensure that your process methods assert security permissions throughout the application
Statically allocate your memory space so that any new threads spawned into it will either fail or overwrite existing memory space; you'll need probably a hefty chunk
of logic to detect and correct for this though.
Factor your code into a device driver or some other low-level type process that you can get covered under the Windows File Protection umbrella.
Just saw Cthulon's answer and I'm afraid he's probably correct: anyone who wants to perform code injection on your application will find a way to do so. The steps above might merely make it a bit more difficult.
Hope this helps