- Status
- Offline
- Joined
- Mar 3, 2026
- Messages
- 421
- Reaction score
- 7
Anyone currently digging into UEFI-level persistence has probably hit this wall.
Trying to get a stable hook on ntoskrnl functions during the boot sequence is a classic headache. The logic here follows the standard path: hooking ExitBootServices, grabbing the winload.efi base, and then intercepting OslArchTransferToKernel to perform the final patch on the kernel before it takes over the machine.
The Technical Setup
The goal is to patch MmCopyMemory inside the kernel's memory space using a standard 12-byte shellcode jump. The execution flow looks solid on paper:
The Implementation
The Failure Point
While Windows boots normally, any call to the hooked MmCopyMemory results in a SYSTEM_SERVICE_EXCEPTION bugcheck. The core issue is almost certainly virtual memory mapping. When OslArchTransferToKernel is executing, you are in a transitional state. The hook address (mm_copy_memory_hook) resides in memory allocated by the EFI boot services.
Once the kernel fully initializes and shifts to its own page tables, that EFI-allocated memory is either unmapped, marked as non-executable, or simply inaccessible at the virtual address your shellcode is trying to jump to. Using ConvertPointer returning 0x0 confirms that the UEFI runtime doesn't have a valid mapping for that address in the new context.
To fix this, the hook handler needs to be placed in a region that the kernel will actually map, such as a code cave within ntoskrnl itself or by manually mapping the handler into a kernel-safe memory region using the LOADER_PARAMETER_BLOCK.
Who here has successfully mapped a persistent handler across the winload transition without catching a bugcheck?
Trying to get a stable hook on ntoskrnl functions during the boot sequence is a classic headache. The logic here follows the standard path: hooking ExitBootServices, grabbing the winload.efi base, and then intercepting OslArchTransferToKernel to perform the final patch on the kernel before it takes over the machine.
The Technical Setup
The goal is to patch MmCopyMemory inside the kernel's memory space using a standard 12-byte shellcode jump. The execution flow looks solid on paper:
- Locate winload.efi via the return address of EBS.
- Find OslExecuteTransition and BlpArchSwitchContext patterns.
- Hook OslArchTransferToKernel to get a clean window right before the kernel init.
- Patch the target ntoskrnl export.
The Implementation
Code:
EFI_STATUS osl_arch_transfer_to_kernel_hook(uint64_t loader_block, uint64_t entry)
{
// ... disable WP ...
switch_ctx(0);
KLDR_DATA_TABLE_ENTRY ntoskrnl = get_module_base(&lpb->LoadOrderListHead, L"ntoskrnl.exe");
g_mm_copy_memory = (uint64_t)ntoskrnl.DllBase + 0x030C030;
uint64_t hook_address = (uint64_t)mm_copy_memory_hook;
uint8_t shellcode[12] = {0x48, 0xB8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xE0};
copy_memory(shellcode + 2, (uint8_t*)&hook_address, 8);
// Apply the patch
copy_memory((uint8_t*)g_mm_copy_memory, shellcode, 12);
// ... restore WP ...
return ((osl_arch_transfer_to_kernel_t)g_osl_arch_transfer_to_kernel)(loader_block, entry);
}The Failure Point
While Windows boots normally, any call to the hooked MmCopyMemory results in a SYSTEM_SERVICE_EXCEPTION bugcheck. The core issue is almost certainly virtual memory mapping. When OslArchTransferToKernel is executing, you are in a transitional state. The hook address (mm_copy_memory_hook) resides in memory allocated by the EFI boot services.
Once the kernel fully initializes and shifts to its own page tables, that EFI-allocated memory is either unmapped, marked as non-executable, or simply inaccessible at the virtual address your shellcode is trying to jump to. Using ConvertPointer returning 0x0 confirms that the UEFI runtime doesn't have a valid mapping for that address in the new context.
- The shellcode 48 B8 ... FF E0 is correct for an absolute jump.
- switch_ctx(0) is necessary but doesn't solve the long-term mapping of the hook handler.
- Standard xor rax, rax; ret patches work because they don't rely on external addresses, but they don't allow for sophisticated trampoline logic.
- switch_ctx(0) is necessary but doesn't solve the long-term mapping of the hook handler.
- Standard xor rax, rax; ret patches work because they don't rely on external addresses, but they don't allow for sophisticated trampoline logic.
To fix this, the hook handler needs to be placed in a region that the kernel will actually map, such as a code cave within ntoskrnl itself or by manually mapping the handler into a kernel-safe memory region using the LOADER_PARAMETER_BLOCK.
Who here has successfully mapped a persistent handler across the winload transition without catching a bugcheck?
