Why it is impossible to transplant or patch the Windows kernel

windows-kernel-patching.md

Why it is impossible to transplant or patch the Windows kernel

I wanted to write this because I was unable to find anything online about what I was trying to accomplish.

Background

A while back I came up with the idea of potentially backporting Windows 11's improved thread scheduling features for newer CPUs (Multi-CCD and hybrid designs with E-cores etc.) to Windows 10, because frankly I really dislike Windows 11. This however, proved to be impossible through kernel modification.
The thread scheduling is (likely) handled by the functions KiSwapThread, KiSelectCandidateProcessor, KiSearchForNewThread and other undocumented functions. These can be found in the kernel image ntoskrnl.exe.
Could we just implement it ourselves? Well you would need to reverse engineer it, but even if we did have the code, we would still not be able to "just patch it in"... because of a security feature: cryptographic integrity checks.

Side note: The Windows NT kernel does actually get updated with Windows updates. I was initially skeptical and thought Windows updates were merely just features and extra bloat that don't touch the underlying kernel itself, like how updates are done on Linux. But if you put the kernel image before and after a Cumulative Update through a disassembler, you can see that they are indeed different, and have slightly varying code with each release.

Important Components

The Windows kernel isn't just stored in the kernel image C:\Windows\System32\ntoskrnl.exe, there are other crucial components that the kernel needs to load. This includes but is not limited to:

• hal.dll - Hardware Abstraction Layer
• ci.dll - Code Integrity Engine
• kdcom.dll - Kernel Debugger Stub
• mcupdate_GenuineIntel.dll / mcupdate_AuthenticAMD.dll - Early micro-code update
• pshed.dll - Platform Specific Hardware Error Driver
• bootvid.dll + bootres.dll - Text & graphics routines used in the pre-boot environment
• clfs.sys - Common Log File System
• ALL boot-start drivers (*.sys) in System32\drivers
• Corresponding catalog (*.cat) files in CatRoot

All of these need to be cryptographically validated and have version numbers that match with each other in order for Windows to accept them.

Windows Boot Process

1. Firmware → EFI\Microsoft\Boot\bootmgfw.efi
   ↓ (check)
2. \Windows\System32\winload.efi + winload.efi.mui (checksum pair)
   ↓ (check)
3. \Windows\System32\boot\ci.dll → \System32\boot\ci.dll.mui → bootcat.cache
   ↓ (check)
4. \Windows\System32\boot\ksecdd.sys → \System32\boot\cng.sys
   ↓ (check & load boot drivers)
5. \Windows\System32\boot\hal.dll, ntoskrnl.exe, kdcom.dll, pshed.dll, etc.
   ↓ (kernel handoff)
6. ntoskrnl.exe: nt!KiSystemStartup

Code Integrity

Modern Windows NT isn't just a loose collection of binaries and files that you can patch and modify however you want; it's a carefully cryptographically validated environment. The kernel (ntoskrnl.exe) is deeply integrated with a code-integrity policy (ci.dll, catalogs), a HAL (hal.dll), drivers, and a bootloader (winload.efi) that all have precise version hashes baked into the Code Integrity policy system, making mixing versions impossible.

Therefore, without an exploit for ci.dll that is injected at pre-boot time, you can NOT have differing version numbers without updating Windows through the Deployment Image Servicing and Management (DISM) tool, effectively just upgrading your Windows 10 PC to Windows 11. *gasps*

Conclusion

My experiment proved to be very anti-climactic, as Windows NT is robustly engineered precisely to stop kernel modification that could potentially compromise system security and stability.

What Next?

Options for improving CPU scheduling behavior on Windows 10 for hybrid CPUs would have to be done as a user mode utility that can talk to the kernel and tell it to utilize certain threads over others, depending on the situation. Such tools already exist in some form, such as Process Lasso. Automating this would be our next step.