KPC: Ultimate Windows Privilege Escalation & Memory Forensics Tool

I switched to the smart, quiet version, where disabling memory integrity during early boot works. The link is the same. Default entry: Verbose=NO in drivers.ini
P.S - I'll upload it to GitHub in a few hours with an updated detailed description

 

Before anything: back up your current kvc.exe

Copy the existing binary somewhere safe just in case, though you should be fine. I've tested this build on both Windows 10 and Windows 11.

The correct update procedure

This is the part that matters most. Do NOT simply drop the new kvc.exe into System32 and leave it at that. The reason is that kvc_smss.exe — the native boot-phase component that does the actual early-load work — is embedded inside kvc.exe as a resource. The copy currently sitting in your System32 is from your previous install and does not match the new build.

The correct sequence is:

Code:

kvc uninstall smss

This removes the BootExecute registry entry, deletes C:\Windows\drivers.ini, and removes the old kvc_smss.exe from System32. Then replace kvc.exe in System32 with the new build from the GitHub link, and run:

Code:

kvc install YOUR_DRIVER

This single command does three things automatically:

1. Extracts the new kvc_smss.exe from the embedded resource and writes it to C:\Windows\System32\
2. Downloads the ntoskrnl.exe PDB from the Microsoft Symbol Server (cached in C:\ProgramData\dbg\sym\ for subsequent runs) and resolves the two required kernel offsets — SeCiCallbacks and ZwFlushInstructionCache
3. Writes a fresh C:\Windows\drivers.ini with the correct Offset_SeCiCallbacks and Offset_SafeFunction values for your exact running kernel, then re-registers kvc_smss in BootExecute

On the offsets — this is why you run kvc install after every Windows update

Microsoft changes these kernel offsets with cumulative updates. The offsets in your current drivers.ini are valid for whichever ntoskrnl.exe build was running when you originally installed. After a Windows update — or after swapping to a new kvc.exe build — kvc install YOUR_DRIVER re-resolves them from the live PDB for your current kernel. The PDB is the authoritative offset map. No manual editing of drivers.ini required.

Your Verbose=NO is correct

kvc_smss.exe runs silently during the boot phase. No screen output is expected with Verbose=NO.

Regarding Memory Integrity / HVCI

You don't have it enabled, so it's a non-issue. The HVCI handling path in the new build exists for systems that do have it enabled — it patches the SYSTEM hive offline and schedules an extra reboot cycle. Since your system doesn't have HVCI, execution goes straight through the standard DSE bypass cycle and loads your driver exactly as before. Nothing changes for you there.

tl;dr

Code:

kvc uninstall smss
; replace kvc.exe in System32 with the new build
kvc install YOUR_DRIVER

Your driver will be back on the BootExecute list with a fresh ini and correctly resolved offsets for your current kernel build. Should work exactly as it did before.

 

With the new build, a few things directly relevant to your setup:

Verbose=NO — total silence during deployment

With Verbose=NO in drivers.ini, kvc_smss.exe produces zero screen output during the boot phase — which is the correct setting for a production deployment. If you ever need to debug a boot sequence, flip it to Verbose=YES temporarily and you'll see the full operation log on screen during POST. Set it back to NO afterwards.

drivers.ini now ships with additional commented-out sections

The generated drivers.ini now includes two pre-scaffolded but commented-out sections:

Code:

[RenameX]
; Action=RENAME
; SourcePath=
; TargetPath=
; ReplaceIfExists=NO

[DeleteX]
; Action=DELETE
; DeletePath=
; RecursiveDelete=NO

These are inert by default — the parser ignores commented lines. They're there as a reference if you ever need to schedule a file rename or deletion at the native NT layer during boot, before any filesystem filter drivers are active. For your current use case, just leave them as-is.

Regarding Secure Boot / Memory Integrity — not relevant for you right now, but good to know

Since you confirmed you don't have Memory Integrity (HVCI) enabled, RestoreHVCI=NO is the correct setting and nothing changes for you. For reference: if you ever end up on a system with HVCI active, setting RestoreHVCI=YES instructs kvc_smss to patch the offline SYSTEM hive directly — disabling Memory Integrity at the raw binary level before the driver load, then scheduling a restore on the next cycle so the system comes back up clean. The hive parser handling that is now significantly more robust than the previous implementation, so that path is safe to use when needed.

For your system — everything works exactly as before, just quieter.

 

You need to login to view this posts content.

 

Correct — and that's exactly why the silent boot path matters here.

To give you some context on what's packed in that binary: the icon resource in kvc.exe is ~34 KB — the raw icon itself is ~4 KB, the remaining ~30 KB is a steganographic container carrying four embedded components compiled from ASM/C/C++:

• kvc.sys — the signed BYOVD primitive
• kvcstrm.sys — the purpose-built kernel primitive driver; IOCTL surface covers cross-process memory R/W, PP/PPL stripping, physical memory access, token elevation and more — currently only a fraction of that is wired into the command surface
• kvc_smss.exe — the NATIVE subsystem boot-phase loader, pure C, no CRT, runs under SMSS before any usermode security stack is online
• ExplorerFrame.dll — the watermark removal library

The DLL is the one component I still want to revisit — it'll need an update to stay aligned with upcoming developer builds. The rest is stable.

All of that fits in what looks like a standard application icon. No external dependencies, no dropped files until you explicitly run an install command.

 

To answer the question regarding updates: If you decide to keep your current Windows version exactly as it is and completely block all updates, you do not need to download updated versions of the tool. The memory offsets we use to bypass security are directly tied to your specific kernel binary, ntoskrnl.exe. As long as that file remains unchanged by Windows Updates, the structure addresses remain constant and the tool will function indefinitely.

"Upcoming developer builds" refers to preview versions like those from the Windows Insider channels. These builds almost always shift the kernel layout, which forces us to hunt for new offsets. If you stay on your current build, the work is done once and for all.

---

Shaking off the PDB Dependency

For those following the technical side of this project, I have some interesting news. I managed to develop an algorithm that locates key Windows kernel offsets completely offline, without relying on Microsoft’s symbol servers. This is quite rare in public Proof-of-Concepts. Many reverse engineering colleagues eventually gave up, discouraged by the "bastion" of hidden private symbols and the strict separation between the Secure Kernel Code Integrity (SKCI) and standard CI responsibilities.

Our primary targets are Offset_SeCiCallbacks (the RVA of the global Code Integrity callback structure) and Offset_SafeFunction (the RVA of the ZwFlushInstructionCache export).

Instead of relying on fragile hardcoded byte patterns, the algorithm performs a semantic analysis of the SeCiCallbacks initialization within the SepInitializeCodeIntegrity function.

The Logic: LEA + memset + MOV
The core of the discovery is a specific initialization pattern. First, a

Code:

LEA rcx, [RIP + rel32]

instruction loads the address of SeCiCallbacks + 4. This +4 offset exists because the initialization process usually skips the first field, such as flags or versioning, which is handled separately. This is followed by a zero-init sequence, typically involving

Code:

xor edx, edx

and

Code:

mov r8d, [size]

, before calling memset. Immediately after, the code executes

Code:

mov [RIP + rel32], imm32

(opcode C7 05) to commit the specific flags.

The "Fast Path" Engine
To keep the tool lightning-fast, I avoided heavy disassembler libraries like Zydisk. Instead, I implemented a manual decoder for specific x64 instructions:

• Kernel Section Scanning: We scan for the C7 05 opcode (MOV with a 32-bit immediate).
• RIP-Relative Verification: We calculate the target RVA. If it points to a writable, non-executable section like .data, we analyze the surrounding 32-byte window.
• LEA Validation: We look for an 8D 05 (LEA) instruction pointing exactly 4 bytes below our target. If we find the memset register setup (EDX=0 and R8D within a reasonable range of 0x40 to 0x400) in the vicinity, we have a high-confidence match.

I first prototyped this in Python and then moved to a native C implementation (VS 2026) to test against various Windows 10 and 11 builds. The result? It hits the mark every time without a single PDB hit. I am currently integrating this directly into native modules like kvc_smss. This code will eventually be part of the KernelResearchKit.

Fallback and Resilience
In the event that the "Fast Path" fails on a radical new build, the engine switches to a Structural Scan. This mode analyzes the RUNTIME_FUNCTION table in the .pdata section to identify function boundaries and searches for legacy anchors. While I prefer the mathematical elegance of the Fast Path, this "dirty" method serves as a reliable backup. It takes roughly 3.2 seconds to complete, but it ensures the bypass remains autonomous even if Microsoft tweaks the compiler logic.

This approach makes the tool exceptionally resilient to updates as long as the underlying semantics of kernel initialization remain the same. We are moving toward fully autonomous bypass tools where the code is simply the execution of a well-understood logic.

Current Module Status:

• Target: ntoskrnl.exe
• Method: Semantic Heuristics
• PDB Dependency: None (100% Offline)
• Integration: kvc_smss / Native Runtime
• Scheduled for this week

 

If you only need to load drivers on Windows 10/11, you don’t need to use the entire kvc. Just unzip the DriverLoader.zip archive, adjust the driver name, service, and startup settings, then run the deploy.ps1 script.. and that’s it; it will work after every reboot. To keep things quiet, you should also change:
Verbose=YES to NO
P.S - This is a version of the system:native program, which is essentially a kernel disassembler and hits the mark without needing symbol files—it handles those darn hard-to-find SeCiCallbacks offsets. It works on Windows 10 and 11, and you probably won’t need to reload those symbols via “kvc install your_driver”.

 

You need to login to view this posts content.

 

I would remove it for this purpose and use bb.exe instead, which works offline without needing to handle changing offsets. It works as intended, and there’s nothing else you need to do. If the API ever undergoes a major overhaul or new security libraries are added, I’ll just figure it out.

 

Just run “kvc uninstall smss” and install BB

Yes, I expected it to be flagged because it’s not a tool that Microsoft tolerates, let alone others. You can exclude it from Defender, and the commands “kvc setup” or “kvc exclusion” do just that. In other cases, due to possible permissions, this can also be done, but the code will grow significantly, and besides, you need to have them (AV software)