在启动之前将dll注入进程的一种优雅方法

本文介绍了在启动之前将dll注入进程的一种优雅方法的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我正在制作一个"mod" dll，用于修改目标进程的行为.我成功注入了dll并挂接了target的某些功能.

但是当我需要在主模块启动之前(更清楚地，在入口点之前)挂接一些API时，需要做更多的工作.我需要使用CREATE_SUSPENDED属性手动启动目标程序，然后注入并恢复.但是，有些应用程序以其自己的启动器程序启动，而某些应用程序通常是从x64进程开始的.

似乎是最好的方法，将DLL注入所有进程并处理CreateProcess.但有时需要UAC，x64开发.

任何建议将不胜感激.

解决方案

您可能会滥用图像文件执行选项，然后将修改DLL注册为调试器"(请参见如何:自动启动调试器以获取详细信息).

过程很简单:

在 HKEY_LOCAL_MACHINE \ Software \ Microsoft \ Windows NT \ CurrentVersion \ Image File Execution Options 键下添加带有目标进程名称的键(例如受害者.exe).

在此键下，添加一个名为 debugger 的新 String值.

将值设置为修改二进制文件的路径名.该名称必须是标准路径名，或者图像位置必须在PATH环境变量中.

无论何时启动受害者.exe，在加载受害者.exe(及其依赖项)之后，但在执行开始之前，都会启动您的修改二进制文件.无论启动受害者.exe的方式如何，都会发生这种情况.

还请注意，在64位操作系统上，密钥也反映在 Wow6432Node 中，因此您的修改二进制文件将同时针对32位和64位版本的受害者启动.exe.

将DLL加载到每个可执行文件(至少与user32.dll链接的那些可执行文件)中的另一种方法是滥用 AppInit_DLLs注册表项(其名称也称为 Deadlock_Or_Crash_Randomly_DLLs >).这甚至比将随机可执行文件注册为调试器还要麻烦，但是仍然是任何自重的恶意软件作者都必须熟悉的一种黑客.另请注意，此功能-uhm-在将来的Windows版本中可能不可用. Windows Vista ，必须准备Windows 7和Windows Server 2008 R2 才能使AppInit_DLLs正常工作.

I am making a 'mod' dll that modifies behaviour of the target process. I succeeded to inject my dll and hook some functions of target.

But it requires more work to do when I need to hook some APIs BEFORE main module starts(more clearly, before the entry-point). I need to start the target program manually with CREATE_SUSPENDED attribute, inject, then resume. But some applications start with its own launcher program, some often start from x64 processes... such various environment make it hard to automate it.

Seems like the best way's inject hooking dll to all process and handle CreateProcess. But sometimes it requires UAC, x64 developement.

Any advice would be appreciated.

解决方案

You could abuse the Image File Execution Options and register your modification DLL as the 'debugger' (see How to: Launch the Debugger Automatically for details).

The procedure is simple:

Add a key with the name of your target process (e.g. victim.exe) under the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options key.

Under this key, add a new String Value with name debugger.

Set the value to the path name of your modification binary. This must be either the fully qualified path name, or the image location must be in your PATH environment variable.

Whenever victim.exe is launched your modification binary is launched after victim.exe (and its dependencies) have been loaded, but before execution begins. This will happen regardless of how victim.exe is launched.

Note also that on a 64-bit OS the key is reflected in the Wow6432Node as well, so your modification binary will be launched for both 32-bit as well as 64-bit versions of victim.exe.

Another way to have your DLL loaded into each and every executable (at least those that link against user32.dll) is to abuse the AppInit_DLLs registry key (which also goes by the name Deadlock_Or_Crash_Randomly_DLLs). This is even messier than registering a random executable as a debugger, but still one hack that any self-respecting malware author absolutely needs to be familiar with. Note also, that this - uhm - feature may become unavailable in future versions of Windows. Windows Vista, Windows 7 and Windows Server 2008 R2 must be prepared for AppInit_DLLs to work.