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!