injdrv Documentation

The project implements three distinct methods for DLL injection depending on the target architecture and requirements:

1. "Thunk" method

• Target: All architectures.
• Mechanism: Injects a DLL of the same architecture as the process. It allocates memory in the user-mode address space containing the DLL path and a small shellcode (thunk) that calls LdrLoadDll.
• Implementation Detail: To avoid security concerns with PAGE_EXECUTE_READWRITE and bypass ZwProtectVirtualMemory limitations on older Windows versions, it uses a section (ZwCreateSection) to map memory with PAGE_READWRITE, writes the data, unmaps it, and re-maps it with PAGE_EXECUTE_READ. To avoid deadlocks with AddressCreationLock, it uses a kernel-mode APC to perform the mapping.

2. "Thunkless" method

• Target: Windows x64 only.
• Mechanism: Injects an x64 DLL into both x64 (native) and x86 (Wow64) processes.
• Implementation Detail: This method bypasses Control Flow Guard (CFG) issues on Windows 10 by pointing the APC's NormalRoutine directly to the address of LdrLoadDll in the 64-bit ntdll.dll. It leverages the way KiUserApcDispatcher passes parameters to effectively call LdrLoadDll(NULL, 0, &DllName, &ContinueContext).

The driver uses Asynchronous Procedure Calls (APCs) to inject DLLs into user-mode processes. It achieves this by registering two callbacks:

• PsSetCreateProcessNotifyRoutineEx: For process create/exit notification.
• PsSetLoadImageNotifyRoutine: For image load notification.

Injection Lifecycle:

1. When a process is created, the driver allocates a structure to track loaded DLLs and function addresses (like LdrLoadDll).
2. The driver waits for specific system DLLs to load (e.g., ntdll.dll for native processes, or the Wow64-specific DLLs for Wow64 processes).
3. Once the target DLLs are loaded, the driver queues a user-mode APC to the process. This APC triggers the loading of the target DLL.
4. The injected DLL is forced to execute by calling KeTestAlertThread(UserMode), which sets Thread->ApcState.UserApcPending to TRUE, causing immediate delivery on the next kernel-to-user transition.

Constraints:

• Injected DLLs must depend only on ntdll.dll because they are injected during very early process initialization.
• Native processes (e.g., csrss.exe) and Pico processes (e.g., WSL applications) are not injected.

To use injdrv for DLL injection, you must first enable Test-Signing on Windows and reboot.

Setup:

1. Enable Test-Signing (requires Administrator privileges):

   bcdedit /set testsigning on
   shutdown /r /t 0

2. Reboot the machine.

**Running the tool:**
- **Install the driver:** Run `injldr -i`. The driver will stay active and wait for new processes to be created. Once a process is created, it will be hooked.
- **Start tracing only:** Run `injldr` without parameters to start an ETW tracing session that prints information about called hooked functions.
- **Uninstall the driver:** Run `injldr -u`.

**Note:** The tool defaults to specific injection methods based on architecture: `InjMethodThunk` on Windows x86, `InjMethodThunkless` on Windows x64, and `InjMethodWow64LogReparse` on Windows ARM64. To change this (e.g., to inject an x86 DLL into an x86 Wow64 process), you must set the injection method to `InjMethodThunk` in the source and ensure the corresponding `injdll` architectures are compiled and placed in the same directory as `injldr.exe`.

Because injected DLLs must only depend on ntdll.dll, they cannot directly use ETW functions from advapi32.dll (like EventWrite). However, since advapi32.dll functions are often just wrappers that redirect to ntdll.dll functions, you can mock them in your DLL by defining them to point to the EtwEvent* equivalents in ntdll.dll.

//
// Include support for ETW logging. 
// Note that following functions are mocked, because they're
// located in advapi32.dll.  Fortunately, advapi32.dll simply
// redirects calls to these functions to the ntdll.dll.
//

#define EventActivityIdControl  EtwEventActivityIdControl
#define EventEnabled            EtwEventEnabled
#define EventProviderEnabled    EtwEventProviderEnabled
#define EventRegister           EtwEventRegister
#define EventSetInformation     EtwEventSetInformation
#define EventUnregister         EtwEventUnregister
#define EventWrite              EtwEventWrite
#define EventWriteEndScenario   EtwEventWriteEndScenario
#define EventWriteEx            EtwEventWriteEx
#define EventWriteStartScenario EtwEventWriteStartScenario
#define EventWriteString        EtwEventWriteString
#define EventWriteTransfer      EtwEventWriteTransfer

#include <evntprov.h>

The following NTDLL functions are intercepted by the injected DLL to log their activity via ETW:

• NtQuerySystemInformation: Logs the SystemInformationClass, the SystemInformation pointer, and the SystemInformationLength.
• NtCreateThreadEx: Logs the ProcessHandle and the StartRoutine pointer.

// Hooked NtQuerySystemInformation
NTSTATUS NTAPI HookNtQuerySystemInformation(
  _In_ SYSTEM_INFORMATION_CLASS SystemInformationClass,
  _Out_writes_bytes_opt_(SystemInformationLength) PVOID SystemInformation,
  _In_ ULONG SystemInformationLength,
  _Out_opt_ PULONG ReturnLength
);

// Hooked NtCreateThreadEx
NTSTATUS NTAPI HookNtCreateThreadEx(
  _Out_ PHANDLE ThreadHandle,
  _In_ ACCESS_MASK DesiredAccess,
  _In_opt_ POBJECT_ATTRIBUTES ObjectAttributes,
  _In_ HANDLE ProcessHandle,
  _In_ PVOID StartRoutine,
  _In_opt_ PVOID Argument,
  _In_ ULONG CreateFlags,
  _In_ SIZE_T ZeroBits,
  _In_ SIZE_T StackSize,
  _In_ SIZE_T MaximumStackSize,
  _In_opt_ PPS_ATTRIBUTE_LIST AttributeList
);