KeyboardKit - Windows Kernel-Mode Keylogger - Educational rootki

项目说明

UDP Keyboard Logger - Educational Kernel-Mode Project

Quick Start

This project demonstrates the use of a custom keyboard dri in kernel mode with a built-in UDP protocol under 30 kB. After successful installation, operation with:

Expected Output (Fully Operational):

Table of Contents

Project O

Architecture O

Component 1: kvckbd.sys - Kernel Driver

Component 2: ExplorerFrame.dll - Persistence Layer

Component 3: UdpLogger.exe - Management Hub

BCD Deep Dive

Dri Registration

Installation & Usage

Technical Details & Internals

Security Considerations

Build & De

Troubleshooting

Legal & Educational Notice

Project O

Introduction

This comprehensi project represents one of the few fully functional IRP-based keyboard filter drivers de in recent years, specifically compiled and tested for Windows 11 25H2 that successfully combines kernel-mode interception, network communication, sophisticated pri escalation, and persistent installation mechanisms. The project serves as a practical reference for understanding modern Windows protection mechanisms and kernel programming techniques.

Educational Purpose

This system is designed for:

Security researchers studying Windows defense mechanisms and attack

Kernel de learning IRP-based filter drivers and Windows Dri (WDM)

System programmers understanding Windows internals, BCD manipulation, and pri escalation

Red team operators researching persistence techniques in authorized penetration testing en

Critical Prerequisites

⚠️ MANDATORY REQUIREMENTS:

Disable Secure Boot in BIOS/UEFI settings

Administrator pri required

Windows 10/11 x64 systems only

Authorized, controlled testing en

Alternati: use the companion KVC tool – a separate project that can load an unsigned kernel dri reboot in any protection mode (including Secure Boot). Note: the user must update the K (including the offset map in OffsetFinder.cpp) before use.

Three-Component Ecosystem

| Component | Type | Pri Level | Primary Function |
|-----------|------|----------------|------------------|
| kvckbd.sys | Kernel Filter Driver | Ring 0 | IRP-le interception, scan code processing, WSK networking |
| ExplorerFrame.dll | COM In-Process Server | Ring 3 (User) | CLSID hijacking for persistence, API hooking for watermark removal |
| UdpLogger.exe | Service Manager | Ring 3 (TI/Admin) | Installation orchestration, UDP logging, system status monitoring |

Architecture O

Data Flow Pipeline

The system implements a multi-layer interception and processing pipeline:

Component Interaction Model

The three components operate independently yet cooperatively:

Kernel Space (Ring 0):

kvckbd.sys operates as a transparent filter between applications and the keyboard hardware

Intercepts IRP_MJ_READ requests destined for kbdclass.sys

Processes keyboard input asynchronously using system threads

Transmits processed keystrokes UDP (WSK)

User Space (Ring 3):

UdpLogger.exe runs as a Windows Service (UdpKeyboardLogger)

Listens on UDP port 31415 for incoming keystroke data

Implements daily log rotation with automatic header/footer generation

Provides comprehensive CLI for system management and status monitoring

Persistence Layer:

ExplorerFrame.dll (misspelled as ExpIorerFrame.dll) hijacks legitimate COM CLSID

Loads automatically when explorer.exe initializes shell components

Hooks API functions to remove "Test Mode" watermark

Ensures stealth operation by patching import tables

Installation State Flow

Secure Boot Detection & Blocking

Pre-Installation Check (SystemStatus.cpp:91-104)

Before any installation steps, the system checks if Secure Boot is enabled:

Installation Blocking (UdpLogger.cpp:216-234)

If Secure Boot is detected, installation terminates immediately with error message:

Why This Matters:

kvckbd.sys is test-signed, not WHQL/Microsoft-signed

Secure Boot enforces Microsoft's dri policy

Installation would complete but dri fail to load

Pre-check prevents wasted time and provides clear guidance

Component 1: kvckbd.sys - Kernel Driver

O

The kernel driver is the cornerstone of this system, operating at Ring 0 with full kernel pri. It implements a sophisticated IRP filter mechanism that intercepts keyboard input at the Windows Dri (WDM) level, specifically targeting the kbdclass.sys class driver.

Architectural Design

Filter Dri:
Rather than implementing a complete keyboard dri, kvckbd.sys adopts the filter dri. It positions itself between user-mode applications and the legitimate Windows keyboard driver, allowing it to observe and process all keyboard input without replacing core system functionality.

Key Inno - Modern IRP-Based Implementation – Tested on Windows 11 25H2:
This dri a rare working implementation of IRP-based keyboard filtering. Most modern attempts fail due to:

Incorrect offset calculations for De structures

Improper synchronization leading to race conditions and BSODs

Failure to handle IRP cancellation correctly

Inadequate resource cleanup during dri

This project solves all these challenges through careful architecture-specific offset management, proper IRQL-aware synchronization, and comprehensi handling.

IRP Interception Mechanism

De Offset Technique:
The dri accesses internal structures of kbdclass.sys by using architecture-specific offsets into the De. This technique is necessary because Microsoft doesn't expose these structures publicly:

| Structure | x86 Offset | x64 Offset | Purpose |
|-----------|------------|------------|---------|
| IO_REMO | 0x10 | 0x20 | Prevents device remo operations |
| KSPIN_LOCK | 0x6C | 0xA0 | Synchronizes access to IRP queue |
| LIST_ENTRY | 0x70 | 0xA8 | Head of pending read IRP queue |

IRP Queue Manipulation:
The dri pending IRPs directly from kbdclass.sys's internal queue, processes them, then forwards them to the original handler. This requires:

Acquiring the keyboard device's spinlock (at DISPATCH_LEVEL)

Removing IRP from linked list

Clearing cancel routines safely

Handling race conditions with IRP cancellation

Thread-Based Processing:
Each intercepted IRP spawns a dedicated system thread. This design:

Prevents blocking at high IRQL

Allows synchronous waiting for lower dri

Enables proper context for WSK network operations

Simplifies error handling and resource cleanup

Scan Code Processing Engine

Multi-Table Translation System:
The dri an efficient scan code translation engine using multiple lookup tables:

Base Table (84 entries): Maps scan codes 0x00-0x53 to lowercase characters

Shift Modifiers (10 entries): Translates digits under Shift (1→!, 2→@, etc.)

Special Characters: Handles punctuation marks with Shift

Extended Codes (18 entries): E0-prefixed scan codes (arrows, Right Ctrl/Alt, etc.)

International Support: Polish diacritics combinations (ą, ć, ę, ł, ń, ó, ś, ú, ż)

State Machine Implementation:
The dri keyboard state flags (Shift, CapsLock, NumLock) and implements XOR logic for proper character output. For letters:

Shift + CapsLock OFF = Uppercase

Shift OFF + CapsLock = Uppercase

Shift + CapsLock = Lowercase (XOR behavior)

Performance Optimization:
Instead of storing all combinations (84 × 4 = 336 entries), the dri at runtime, reducing memory footprint to ~1KB for all translation tables while maintaining O(1) lookup complexity.

Line Buffering Inno

Design Rationale:
Traditional keystroke loggers send one network packet per key press, generating excessi. This dri line-based buffering:

Accumulates keystrokes in a 512-byte buffer

Filters out modifier keys ([Shift], [Ctrl], [Alt])

Filters out function keys (F1-F12)

Transmits complete lines only when Enter is pressed

Performance Impact:

Before: 1000 keystrokes/minute = 1000 UDP packets

After: 1000 keystrokes/minute ≈ 10-20 UDP packets (typical typing patterns)

Network o reduction: 95-98%

Synchronization:
The buffer uses KSPIN_LOCK for protection since it's accessed at DISPATCH_LEVEL. Spinlocks are mandatory here (mutexes would cause BSOD at DISPATCH_LEVEL).

WSK Network Stack

Kernel-Mode Networking:
The driver uses Winsock Kernel (WSK) for UDP communication. WSK ad:

No context switching to user mode

Direct access to network stack

Operation at IRQL ≤ DISPATCH_LEVEL

Suitable for dri or dri communication

Initialization Process:

1. Start WSK subsystem (WSKStartup)
2. Resol address (supports both IPv4/IPv6)
3. Create datagram socket (WSKSocket with SOCK_DGRAM)
4. Configure default destination DDRESS ioctl

UDP Transmission:
Calls WSKSendTo with pre-configured socket. No need to specify destination address on each call since SIO_WSK_SET_SENDTO_ADDRESS sets a default target.

Dri Management

Initialization Thread:
A persistent system thread (KbdThread_IrpHookInit) runs continuously:

Enumerates keyboard device objects every 100ms

Detects newly plugged keyboards (hot-plug support)

Hooks device objects by modifying FileObject->De pointers

Maintains list of hooked keyboard objects

Clean Unload Process:
Unloading a filter driver is notoriously difficult. This dri:

1. Signal shutdown: Set IsUnloading flag
2. Unhook devices: Restore original De pointers
3. Wait for safety: Poll SafeUnload flag on each keyboard object
4. Flush buffers: Send any remaining buffered keystrokes
5. Release resources: Close sockets, delete resources, free pool memory
6. Delete device: Remo device object

Critical Safety Mechanism:
The SafeUnload flag prevents premature unload while IRPs are still processing. Each keyboard object tracks whether it's safe to cleanup, pre BSOD during unload.

Component 2: ExplorerFrame.dll - Persistence Layer

O

This COM in-process ser two objectives: persistence through CLSID hijacking and stealth through API hooking to remove test mode watermarks. It demonstrates ad techniques for DLL injection and import table manipulation.

CLSID Hijacking for Persistence

Target CLSID:

Mechanism:
When Windows Explorer (explorer.exe) starts, it loads numerous COM components. By hijacking the InProcServer32 registry value for a specific CLSID, we can inject our DLL into Explorer's address space automatically at every system boot.

Registry Manipulation:

Original: HKCR\CLSID\{...}\InProcServer32 = %SystemRoot%\system32\ExplorerFrame.dll

Hijacked: HKCR\CLSID\{...}\InProcServer32 = %SystemRoot%\system32\ExpIorerFrame.dll

Stealth Through Typosquatting:
The filename uses similarity:

ExplorerFrame.dll (legitimate, uses lowercase 'l')

ExpIorerFrame.dll (malicious, uses uppercase 'I')

In many fonts, 'l' and 'I' are nearly indistinguishable, making casual file listing appear normal.

Persistence Characteristics:

Survi reboots

Loads automatically with Explorer

No additional scheduled tasks or startup entries

Difficult to detect without registry inspection

Survives user logout/login

API Hooking - Import Address Table (IAT) Patching

Objective:
Remove "Test Mode" watermark displayed by Windows when test signing is enabled. The watermark is rendered by shell32.dll using LoadStringW and ExtTextOutW API calls.

Hooking Technique:
The DLL implements IAT patching to redirect API calls:

1. Locate IAT: Parse PE headers of shell32.dll in memory
2. Find import entries: Scan import directory for LoadStringW and ExtTextOutW
3. Modify function pointers: Replace original addresses with proxy functions
4. : Temporarily disable page protection to write

Proxy Functions:

Proxy_LoadString: Returns 0 (empty string) for string IDs 62000/62001 (test mode strings)

Proxy_ExtTextOut: Filters out watermark text before calling original ExtTextOutW

String Detection:
The DLL maintains a list of watermark strings:

"Windows [Edition]"

"Build [Number]"

Test Mode indicators

If detected in text output calls, the function returns success without actually drawing.

Initialization Timing:
Hooking occurs in DllMain during DLL_PROCESS_ATTACH, ensuring it activates before Explorer renders any UI elements.

Minimalist Implementation

Design Philosophy:
The DLL is built with aggressive size optimization:

No C Runtime Library (CRT)

Custom memory allocation using HeapAlloc

Custom string functions (min_memcpy, min_memset, min_memcmp)

Direct Windows API calls only

Custom new/delete operators

Binary Size:
Through these optimizations, the compiled DLL is extremely small (~7 KB), making it less suspicious and easier to hide.

Function Forwarding:
The DLL exports two functions that forward to the legitimate explorerframe.dll:

This ensures COM functionality remains intact while injection occurs transparently.

Component 3: UdpLogger.exe - Management Hub

O

UdpLogger.exe is the orchestration center of the entire system. It serves four critical roles:

1. Installer - Deploys and configures all components with TrustedInstaller pri
2. Service - Runs as Windows Service to receive and log UDP keystroke data
3. Manager - Provides CLI for controlling driver and service states
4. Monitor - Comprehensi status checking and diagnostics

This component demonstrates ad Windows service programming, pri escalation techniques, and secure resource embedding.

Command-Line Interface

The tool provides a comprehensive CLI for all management operations:

TrustedInstaller Pri Escalation

Why TrustedInstaller?
Windows protects critical system files and registry keys using TrustedInstaller ownership. Standard Administrator pri cannot:

Write to %SystemRoot%\System32 ()

Modify HKLM\BCD00000000 registry hive

Write to Dri directories

Modify certain CLSIDs in HKCR

Escalation Chain:

Key Techniques:

1. SYSTEM Acquisition:
- Locates winlogon.exe process (always runs as SYSTEM)
- Opens process with PROCESS_QUERY_INFORMATION
- Duplicates token with SecurityImpersonation level

2. TrustedInstaller Service:
- Service name: "TrustedInstaller"
- Start type: Manual (must be started explicitly)
- Monitors service state until SER
- Acquires process token once running

3. Pri Enablement:
- Enables all 8 critical pri on token:
- SeDebugPri - Debug any process
- SeImpersonatePri - Impersonate tokens
- SeAssignPrimaryTokenPri - Assign tokens to processes
- SeTcbPri - Trusted Computer Base
- SeBackupPri - Backup files
- SeRestorePri - Restore files
- SeTakeOwnershipPri - Take ownership of objects
- SeSecurityPri - Manage audit/security logs

4. Impersonation Context:
- All file/registry operations occur within ImpersonateLoggedOnUser context
- Operations use impersonated credentials automatically
- Re() called after each operation batch

Resource Extraction - Steganography Technique

Embedding Method:

The final UdpLogger.exe embeds both kvckbd.sys and ExpIorerFrame.dll using steganography with CAB compression, achieving exceptional size efficiency (~18 KB total).

Structure:

Encryption:

Files are XOR-encrypted with a 7-byte key before CAB compression:

Extraction Process (ResourceExtractor.cpp):

Stage 1: Resource Loading (Lines 269-283)

Stage 2: Icon Skipping (Lines 285-292)

Stage 3: XOR Decryption (Lines 294-295)

Stage 4: In-Memory CAB Decompression (Lines 123-183)

Uses Windows FDI (File Decompression Interface) API with custom callbacks:

Key implementation details:

fdi_open: Returns pointer to memory context (not file handle)

fdi_read: Reads from memory buffer instead of disk

fdi_write: Writes to in-memory (no filesystem I/O)

fdi_seek: Adjusts memory offset pointer

No temporary files created - entire operation in RAM

Stage 5: PE Binary Separation (Lines 188-242)

The extracted kvc.bin contains two concatenated PE files. Parser identifies them by:

Ad:

Size Efficiency: ~18 KB total resource (icon + compressed binaries)

Stealth: Hidden in legitimate icon resource (RT_RCDATA type)

Memory-only: No temporary files during extraction process

Obfuscation: XOR encryption + CAB compression prevents static analysis

Single Executable: All components embedded in installer

A: Scanners often skip icon resources or struggle with multi-layer encoding

Detection Resistance:

1. First 1662 bytes are valid ICO data - appears as normal icon
2. Remaining data looks like random noise until XOR-decrypted
3. CAB signature only after decryption
4. PE files only accessible after CAB extraction
5. No external dependencies or suspicious file downloads

TrustedInstaller Token Impersonation

The installation process requires TrustedInstaller pri to deploy files to protected system locations. The system uses sophisticated token impersonation instead of traditional pri escalation methods (takeown/icacls), achieving direct API-le without spawning external processes.

Token Escalation Chain:

Implementation Details (TrustedInstallerExecutor.cpp):

Phase 1: SYSTEM Token Acquisition (Lines 258-275)

Phase 2: TrustedInstaller Service Acti (Lines 277-321)

Phase 3: Token Extraction & Duplication (Lines 323-337)

Phase 4: Pri Enablement (Lines 155-177)

Direct Operations (No External Processes):

File Operations (Lines 443-497)

Registry Operations (Lines 570-618)

Key Operations Performed:

| Operation Type | Target Location | Purpose |
|---------------|-----------------|---------|
| File Write | %SystemRoot%\System32\ExpIorerFrame.dll | CLSID hijack DLL deployment |
| File Write | %SystemRoot%\System32\Dri\FileRepository\keyboard.inf_amd64_*\kvckbd.sys | Kernel dri |
| Registry Write | HKCR\CLSID\{ab0b37ec-56f6-4a0e-a8fd-7a8bf7c2da96}\InProcServer32 | COM hijack registration |
| Registry Write | HKLM\SYSTEM\CurrentControlSet\Services\kvckbd | Dri creation |
| Registry Write | HKLM\BCD00000000\Objects\{GUID}\Elements\16000049 | BCD test signing enable |
| File Delete | Protected system files | Uninstall cleanup |

Ad O Methods:

| Traditional (takeown/icacls) | TrustedInstaller Token Impersonation |
|------------------------------|-------------------------------------|
| takeown.exe /F file | Direct Win32 API call |
| icacls.exe file /grant | Single token impersonation |
| 3-5 cmd.exe processes per file | No child processes spawned |
| 5-10 seconds per operation | Milliseconds per operation |
| in Process Explorer | Appears as normal system activity |
| EDR process chain detection | Single-thread operation |
| Console window flashing | Silent API-le |

Security Context:

Not a UAC bypass: Requires administrator pri to start

Legitimate mechanism: Uses built-in Windows TrustedInstaller service

Token borrowing: Not pri escalation, but pri impersonation

Audit trail: Operations logged in Windows Security Event Log (Event IDs: 4688, 4656, 4663)

Re: All operations can be undone process

Windows Service Implementation

Service Architecture:
The program implements a dual-mode design:

CLI Mode: Direct command execution when run from terminal

Service Mode: Activated via UdpLogger --service (called by SCM)

Service Lifecycle:

Worker Thread:
Runs continuously while service is active:

Monitors inactivity (logs warning after 15 minutes idle)

Periodic file flush (every 15 minutes)

Responds to stop events

No polling o (uses e signaling)

UDP Listener:

Non-blocking socket operations

select() with 1-second timeout for responsi

Handles multiple clients (though only localhost expected)

Strips carriage returns and newlines

Filters empty messages

File Logging with Daily Rotation

Log File Naming:

Rotation Logic:
At midnight, the logger:

1. Writes footer to current file (session duration summary)
2. Closes file handle
3. Opens new file with today's date
4. Writes header to new file

Header Format:

Entry Format:

Footer Format:

!Keyboard Log Example

Log Rotation:
New file created automatically at midnight...

System Status Monitoring

Component :
The UdpLogger status command performs comprehensi:

1. Windows Service Status:
- Opens SCM (Service Control Manager)
- Queries service state
- Checks if running

2. Kernel Dri:
- Queries kvckbd service
- SER state
- Indicates if driver is loaded in kernel

3. CLSID Hijack :
- Reads registry value with TI pri
- Checks if ExpIorerFrame.dll is registered
- against expected value

4. Test Signing Status:
- Reads BCD element 23000003 for current boot GUID
- Reads element 16000049 under boot GUID
- Checks if binary value = 0x01 (enabled)

5. File Presence Check:
- System32\ExpIorerFrame.dll exists
- Dri\...\kvckbd.sys exists
- Uses GetFileAttributes API

Output Interpretation:
Each component displays:

[+] checkmark (passing)

[-] checkmark (failing)

Details about current state

Fix hints for failures

Dri Management

kvckbd Service Control:
The tool can start/stop/restart the kernel driver:

Restart Strategy:

1. Stop service (if running)
2. Wait 2 seconds (allows cleanup)
3. Start service

Status Query:
Reads service state and displays:

RUNNING - Dri in kernel

STOPPED - Driver not active

BCD Deep Dive

Boot Configuration Data O

What is BCD?
Boot Configuration Data (BCD) is a firmware-independent database introduced in Windows Vista to replace boot.ini. It stores boot configuration parameters including:

Boot manager settings

Boot loader options

Operating system entries

Debug settings

Test signing configuration

Storage Location:
!BCD Registry Structure
The BCD is stored as a registry hive at:

When mounted, it appears in the registry at:

BCD Structure and Well-Known GUIDs

Hierarchy:

Well-Known GUID:

This is the Boot Manager GUID. It's a constant identifier for the Windows Boot Manager object.

Element Types Explained

BCD elements are identified by 8-digit hexadecimal codes:

| Element | Name | Type | Purpose |
|---------|------|------|---------|
| 23000003 | CurrentBootEntry | Pointer | GUID - Points to active boot entry |
| 16000049 | TestSigningEnabled | BINARY | Enables test-signed drivers |
| 12000004 | Description | STRING | OS description text |
| 11000001 | Device | BINARY | Boot device information |
| 26000010 | BootDebuggerEnabled | BOOLEAN | Kernel debugger status |

Element 23000003 - Current Boot Entry Pointer

Purpose:
This element contains the GUID of the currently active boot configuration. When Windows boots, the boot manager uses this to determine which OS entry to load.

Data Format:

Type: REG_BINARY

Length: (typically contains GUID)

Value: {GUID of current boot entry}

Usage in This Project:
The installer must dynamically determine which boot entry is current because:

Multiple OS installations may exist

Boot GUIDs are unique per installation

We cannot hardcode a GUID (it per system)

Reading Process:

Element 16000049 - Test Signing Enable

Purpose:
Controls whether Windows will load drivers signed with test certificates. When enabled, the OS displays a watermark: "Test Mode - Windows [Edition] - Build [Number]"

Data Format:

Type: REG_BINARY

Length: 1 byte

Value:

- 0x01 = Enabled
- 0x00 = Disabled
- (missing) = Disabled

Location:

Why Test Signing is Needed:
Windows enforces Dri Enforcement (DSE) on x64 systems:

All kernel drivers must be signed by Microsoft or a trusted CA

Self-signed or test-signed drivers are rejected by default

Test signing mode allows test certificates (for de)

Our Driver's Signature:
kvckbd.sys is signed with a test certificate (WDKTestCert Administrator, thumbprint: 7870176), requiring test mode enabled.

Registry Manipulation Technique

Step-by-Step Process:

1. Read Current Boot GUID:
- Path: HKLM\BCD00000000\Objects\{9dea862c-5cdd-4e70-acc1-f32b344d4795}\Elements\23000003
- Value Name: Element
- Result: Binary data containing GUID

2. Parse GUID:
- Convert binary to string format: {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}

3. Construct Testsigning Path:

4. Create Key (if missing):
- Use RegCreateKeyExW with TrustedInstaller pri

5. Write Binary Value:
- Value Name: Element
- Type: REG_BINARY
- Data: 0x01 (single byte)

6. Reboot Required:
- Changes take effect only after system restart

Alternati Command

The standard way to enable test signing:

However, this project uses direct registry manipulation because:

Demonstrates ad Windows internals knowledge

Bypasses command-line detection

More stealthy (no process execution)

Educational value in understanding BCD structure

BCD Forensics - Detection

In can detect test signing via:

Output will show:

Or inspection at:

Dri Registration

Windows Dri Mechanism

Service Control Manager (SCM) Role:
Windows doesn't load drivers directly from files. Instead:

1. Dri is registered in the registry
2. SCM reads registry at boot
3. SCM loads drivers based on Start type
4. Drivers execute from their registered ImagePath

Why Registry-Based?

Centralized configuration

Boot-time loading (before file system fully initialized)

Dependency management

Security (controlled by system permissions)

Service Registry Structure

Primary Key:

Required :

| Value Name | Type | Data | Purpose |
|------------|------|------|---------|
| Type | REG_DWORD | 0x00000001 | SER |
| Start | REG_DWORD | 0x00000002 | SER (loads at boot) |
| ErrorControl | REG_DWORD | 0x00000001 | SER (log error, continue boot) |
| ImagePath | REG_EXPAND_SZ | \System32\...\kvckbd.sys | Relative path to driver |
| DisplayName | REG_SZ | "kvckbd" | Human-readable name |

Value Explanations:

Type :

0x00000001 = Kernel-mode driver

0x00000002 = File system driver

0x00000010 = Win32 service

Start :

0x00000000 = Boot (loads by boot loader)

0x00000001 = System (loads during kernel initialization)

0x00000002 = Automatic (loads at boot)

0x00000003 = Manual (must be started explicitly)

0x00000004 = Disabled

ErrorControl :

0x00000000 = Ignore (log error, continue silently)

0x00000001 = Normal (log error, display message, continue)

0x00000002 = Severe (try last known good, fail boot if una)

0x00000003 = Critical (must succeed or boot fails)

Dri Integration

What is Dri?
Windows maintains a protected repository of installed drivers at:

Directory Structure:

Why Dri?

Trusted location (TrustedInstaller ownership)

management (multiple dri coexist)

System protection (Windows File Protection monitors)

Dri

Path Resolution Algorithm

Challenge:
The Dri subdirectory has a random hash suffix:

This hash per system, so we cannot hardcode the path.

Solution - Dynamic Discovery:

Installation Process:

1. Locate Dri keyboard directory
2. Copy kvckbd.sys to this directory (requires TI pri)
3. Construct relati for registry

ImagePath Format

Relative Path:

Why Relative?

System-independent (works on any Windows installation)

Handles different dri (C:, D:, etc.)

Boot-time resolution (before dri assigned)

Boot-Time Resolution:
At boot, Windows resol paths:

Service Creation with TrustedInstaller

Standard API (Insufficient):

This fails because:

CreateServiceW writes to protected registry keys

Administrator pri cannot modify protected registry keys like CLSID entries in HKCR, which require TrustedInstaller-le, (maybe write to SYSTEM\CurrentControlSet\Services, but I find it more con to use TrustedInstaller e)

TrustedInstaller ownership required

Our Approach - Direct Registry:

Dri at Boot

Boot Sequence:

First Boot After Installation:

1. Dri registered in registry
2. System reboots
3. Test signing enabled (BCD modified)
4. SCM loads kvckbd.sys automatically
5. Dri intercepting keyboard

Commands

Check Service Registration:

Check Registry:

Check Driver in Memory:

Or using Dri tools:

Installation & Usage

Prerequisites

System Requirements:

Windows 10 or Windows 11 (x64 only)

Administrator pri

Secure Boot disabled in BIOS/UEFI

Minimum 50 MB free disk space

Pre-Installation Checklist:

✓ BIOS/UEFI Secure Boot disabled

✓ Administrator account (not standard user)

✓ Antivirus/EDR temporarily disabled (educational testing)

✓ System restore point created (recommended)

Security Boot Disable:

1. Enter BIOS/UEFI setup (usually F2, Del, F10 during boot)
2. Na to Security or Boot settings
3. Find "Secure Boot" option
4. Change to Disabled
5. Save and exit

Installation Process

Simple Installation:

This performs:

Resource extraction

Pri escalation

File deployment

Registry configuration

Service creation

Prompts for reboot

Automatic Reboot:

Skips reboot prompt

Initiates immediate system restart (10-second countdown)

Useful for scripted deployments

Installation Stages:

Post-Installation:
After reboot:

Dri automatically (Start=2)

Service starts automatically

CLSID hijack acti with Explorer)

Test mode watermark appears (can be suppressed by ExpIorerFrame.dll)

Comprehensi Check:

Example Output:

!UdpLogger Status Command

Indi Component Checks:

Service Status:

Dri:

Service Management

Start Service:

Stop Service:

Restart Service:

Stops service

Waits 1 second

Starts service

Dri

Start Driver:

Loads driver into kernel memory

Executes Dri()

Begins keyboard interception

Stop Driver:

Calls dri routine

Unhooks all keyboards

Releases resources

Removes from kernel memory

Restart Driver:

Stops driver

Waits 2 seconds (cleanup)

Starts driver

Note: Dri may be necessary after:

Plugging new USB keyboards

Resume from sleep/hibernation

Software conflicts

Log File Access

Log Location:
The service writes logs to the first writable location among:

1. %TEMP%\keyboard_log_YYYY-MM-DD.txt
2. %TMP%\keyboard_log_YYYY-MM-DD.txt
3. %USERPROFILE%\Documents\keyboard_log_YYYY-MM-DD.txt
4. Current directory

Logs:

Or open with any text editor.

Log Rotation:
New file created automatically at midnight. Old files preser (manual cleanup required).

Uninstallation

Complete Removal:

This performs:

Stops Windows service

Uninstalls service

Restores CLSID registry (points to legitimate ExplorerFrame.dll)

Disables test signing (BCD)

Unregisters dri

Deletes files (System32\ExpIorerFrame.dll, Dri\kvckbd.sys)

Post-Uninstall:
Reboot recommended (but not required). Driver and DLL will be removed at next boot if locked.

Note: Test signing remains in BCD but is disabled. To completely remove:

Technical Details & Internals

Synchronization Mechanisms

IRQL-Aware Design:
The dri at multiple IRQL (Interrupt Request Level) contexts:

| Context | IRQL | Allowed Operations |
|---------|------|-------------------|
| System thread | PASSI | All operations, can wait |
| IRP dispatch | ≤ DISPATCH_LEVEL | No paged memory, no blocking |
| Spinlock held | DISPATCH_LEVEL | Minimal operations only |

Synchronization Primitives Used:

1. KSPIN_LOCK (Line Buffer):
- Used at DISPATCH_LEVEL
- Fast, non-blocking
- Protects line buffer during keystroke accumulation
- Acquired/released in microseconds

2. ERESOURCE (Keyboard Objects):
- Used at PASSI
- Allows shared/exclusi
- Protects keyboard object state during IRP processing
- Can be held across function calls

3. LIST_ENTRY (Keyboard Object List):
- Interlocked operations
- Protected by spinlock
- Thread-safe insertion/removal

Memory Management Strategy

Pool Tags:
All allocations use KBDDRI ('KdbK'):

Benefits:

Leak detection via pool tag tracking

Dri integration

Debugging with !poolfind command

Allocation Strategy:

Non-paged pool only (accessible at DISPATCH_LEVEL)

Zero-initialize all allocations

RAII-style cleanup (resources tied to object lifecycle)

Example:

Architecture Differences (x86 vs x64)

Offset Handling:

Why Different?

Pointer sizes: 4 bytes (x86) vs 8 bytes (x64)

Structure padding/alignment requirements

Internal Microsoft structure layout changes

Implication:
Code compiled for x64 will not work on x86 and vice versa. Requires separate compilation for each architecture.

IRP Cancellation Handling

Challenge:
IRPs can be cancelled at any time (application closes, timeout expires). The driver must handle cancellation gracefully without causing BSOD.

Cancellation Routine:

Race Condition Pre:
When dequeuing IRPs, check if cancel routine was cleared:

Network Error Handling

WSK Operation Failures:

Address resolution failure → Log error, continue

Socket creation failure → Fatal, abort initialization

Send failure → Log error, discard data (no retry)

Design Decision:
Network failures are non-fatal. The dri to intercept keystrokes but silently drops data if network is una.

Rationale:

Prevents blocking keyboard input

Avoids BSOD from network errors

Graceful degradation

Build Optimizations

Compiler Flags (Release):

Linker Flags:

Result:

UdpLogger.exe: ~190 KB (highly optimized)

ExpIorerFrame.dll: ~7 KB (minimal CRT)

kvckbd.sys: ~30 KB (kernel driver)

Security Considerations

Protection Mechanisms Bypassed

1. Dri Enforcement (DSE):

Bypass: Enable test signing via BCD modification

Impact: Allows unsigned/test-signed drivers

Detection: watermark (unless suppressed), bcdedit /enum shows testsigning

2. File System :

Bypass: TrustedInstaller token impersonation

Impact: Direct write to protected directories

Detection: File system audit logs, TI process activity

3. Registry Protection:

Bypass: TrustedInstaller token

Impact: Modify CLSID entries, BCD, service keys

Detection: Registry auditing, RegMon tools

4. CLSID Integrity:

Bypass: Replace legitimate COM DLL path

Impact: Persistent code execution in Explorer

Detection: CLSID registry monitoring, file hash

Detection Indicators

File Artifacts:

Registry Artifacts:

Network Artifacts:

UDP traffic on port 31415

Localhost connections (127.0.0.1:31415)

Regular traffic patterns (typing sessions)

Process Artifacts:

Services.exe → UdpLogger.exe (Windows Service)

Explorer.exe → ExpIorerFrame.dll loaded

System → kvckbd.sys dri

Beha Indicators:

"Test Mode" watermark disappears

New service: UdpKeyboardLogger

Dri: kvckbd

Periodic UDP traffic to localhost

MITRE ATT&CK Mapping

| Technique ID | Description |
|--------------|-------------|
| T1547.001 | Boot or Logon Autostart – Dri with AUTO_START |
| T1546.015 | CLSID Hijacking – COM object persistence |
| T1547.006 | Kernel Modules and Extensions – Kernel dri |
| T1056.001 | Input Capture – Keyboard interception |
| T1134.001 | Impersonation – TrustedInstaller token theft |
| T1046 | Network Service Discovery – UDP listener on localhost |

Defensi

Pre:

Enable Secure Boot (blocks unsigned drivers)

Enforce Dri Enforcement

Monitor BCD modifications

Restrict TrustedInstaller token access

Monitor CLSID registry keys

File integrity monitoring for System32

Detection:

Audit registry: HKLM\BCD00000000 changes

Monitor service creation: HKLM\SYSTEM\CurrentControlSet\Services

Network monitoring: Unexpected localhost UDP traffic

EDR: Driver load events

SIEM: TrustedInstaller impersonation events

Response:

Disable test signing: bcdedit /set testsigning off

Unregister service: sc delete kvckbd

Delete files: Remo.dll, kvckbd.sys

Restore CLSID registry value

Reboot system

Build & De

De En

Required Tools:

Studio 2019 or 2022

Windows Driver Kit (WDK) 10

Windows SDK 10.0.19041.0 or later

Platform Toolset: v143

Project Structure:

Building Components

Build Order:

1. ExplorerFrame.dll (Release | x64)
2. kvckbd.sys (Release | x64)
3. Resource packaging script (embed DLL and SYS in ICO)
4. UdpLogger.exe (Release | x64)

Configuration:
All projects use Release configuration with aggressi.

Dri

Test Signing (De):

Production Signing:
Requires EV Code Signing Certificate from Microsoft-trusted CA.

Post-Build Steps

Timestamp Modification:
Both UdpLogger.exe and ExplorerFrame.dll ha events that modify timestamps:

Purpose:

Disguise recent compilation

Match legitimate Windows files

Avoid detection by creation/modification time

Troubleshooting

Common Issues

#### 1. Dri to Load

Symptoms:

Causes:

Test signing not enabled

Secure Boot enabled

Driver not signed

BCD not modified correctly

Solutions:

#### 2. Service Won't Start

Symptoms:

Causes:

Files missing

Permissions incorrect

Port 31415 already in use

Solutions:

#### 3. No Keystroke Logging

Symptoms:

Service running

Dri

No log file generated or empty file

Causes:

Driver not hooking keyboards

Network communication failing

Log file permissions

Solutions:

#### 4. CLSID Hijack Not Active

Symptoms:

Causes:

Registry not modified correctly

TrustedInstaller pri not acquired

File deleted/quarantined by AV

Solutions:

Debug Techniques

Dri Output:
Use DebugView (Sysinternals) to capture kernel debug messages:

Network Capture:

Registry Monitoring:

Recovery from Failures

System Won't Boot (Test Signing Issue):

1. Boot into Safe Mode (F8 during boot)
2. Disable test signing:

3. Reboot normally

Dri BSOD:

1. Boot into Safe Mode
2. Disable driver:

3. Delete dri:

4. Reboot

Service Locks Files:

📊 Technical Implementation Summary

Component Statistics

| Component | Size (Compressed) | Size (Deployed) | Location | Protection Level |
|-----------|-------------------|-----------------|----------|------------------|
| UdpLogger.exe | ~160 KB | ~160 KB | User-controlled | None (public executable) |
| Embedded Resource | ~18 KB | N/A | Inside UdpLogger.exe | XOR + CAB compressed |
| kvckbd.sys | ~6 KB (in CAB) | ~15 KB | Dri FileRepository | TrustedInstaller ACL |
| ExpIorerFrame.dll | ~4 KB (in CAB) | ~8 KB | System32 | TrustedInstaller ACL |
| keyboard_log_*.txt | N/A | | %TEMP% or Documents | LocalSystem ACL (ser) |

Installation Execution Flow

Total Installation Time: ~0,2-1 second (excluding reboot)

Runtime Data Flow

Total Keystroke Latency: ~1.5ms (key press → disk write)

Performance Metrics

| Metric | Value | Notes |
|--------|-------|-------|
| Installation Time | 0,5-1 seconds | Excluding reboot prompt |
| Resource Extraction | <50ms | Entirely in-memory operations |
| Token Impersonation | ~200ms | TrustedInstaller service startup time |
| File Write (TI) | ~50ms/file | Direct API, no cmd.exe o |
| Registry Write (TI) | ~10ms/key | Single API call per operation |
| Keystroke Latency | <2ms | Kernel → Service → Disk |
| Service Memory | ~2 MB | Resident set size (RSS) |
| Dri | ~32 KB | Non-paged pool allocation |
| Log Growth Rate | ~1 KB/hour | A typing (60 WPM) |
| CPU Usage (Idle) | <0.04% | Service + dri |
| CPU Usage (Active) | ~0.1% | During continuous typing |

Detection Surface Analysis

Static Analysis Challenges:

✓ XOR encryption of embedded CAB archive

✓ Typosquatting DLL name (ExpIorerFrame vs ExplorerFrame)

✓ No hardcoded file paths (dynamic Dri path resolution)

✓ In-memory CAB extraction (no temporary files on disk)

✓ PE files hidden inside compressed archive

✓ Icon resource appears legitimate to automated scanners

Runtime Beha Indicators:

| Indicator | | Forensic E |
|-----------|-----------|-------------------|
| Service "UdpKeyboardLogger" | High | sc query UdpKeyboardLogger |
| Driver "kvckbd" loaded | Medium | fltmc instances / dri |
| CLSID registry modification | Low | Requires TI pri to read |
| BCD test signing enabled | High | bcdedit /enum {current} shows testsigning=Yes |
| UDP port 31415 listening | Medium | netstat -ano | findstr 31415 |
| Log files in %TEMP% | High | to user account |
| "Test Mode" watermark absent | Medium | ExpIorerFrame.dll hooks API |
| TrustedInstaller usage | Low | Event log 4688 (process creation) |

EDR/A Techniques:

1. No Process Injection: Driver + service run as legitimate system components
2. No Code Caves: Direct file writes, not memory patching
3. Localhost-only Traffic: UDP to 127.0.0.1 (no external network activity)
4. Legitimate COM Mechanism: CLSID hijacking uses standard Windows feature
5. Test Signing Certificate: Dri (not unsigned/malformed)
6. TrustedInstaller Context: Operations appear as system maintenance
7. No Suspicious API Chains: Direct Win32 calls, minimal hooking

Forensic Artifacts:

Registry: HKLM\SYSTEM\CurrentControlSet\Services\kvckbd

Registry: HKLM\SYSTEM\CurrentControlSet\Services\UdpKeyboardLogger

Registry: HKCR\CLSID\{ab0b37ec-56f6-4a0e-a8fd-7a8bf7c2da96}\InProcServer32

Registry: HKLM\BCD00000000\Objects\{GUID}\Elements\16000049

File: %SystemRoot%\System32\ExpIorerFrame.dll

File: %SystemRoot%\System32\Dri\FileRepository\keyboard.inf_amd64_*\kvckbd.sys

Logs: %TEMP%\keyboard_log_*.txt or %USERPROFILE%\Documents\keyboard_log_*.txt

Event Log: Security events 4688, 4656, 4663 (TrustedInstaller operations)

## ⚖️ Legal Notice

### Educational Purpose Statement

This project is provided strictly for educational and research purposes. It demonstrates:

Ad Windows kernel programming techniques

Dri and IRP handling

Windows internals and security mechanisms

Pri escalation methods

Persistence techniques for defensi

Authorized Use Only

Legal Requirements:

Use only in controlled laboratory en

Obtain explicit written authorization before deployment

Never use on systems you do not own or ha to test

Comply with all applicable local, state, national, and international laws

Prohibited Uses:

Unauthorized access to computer systems

Monitoring without consent

Corporate espionage

Identity theft or fraud

Any illegal activity

Ethical Considerations

Red Team / Penetration Testing:
If used in authorized penetration testing:

Maintain signed contracts and scope documents

Follow rules of engagement

Report findings responsibly

Provide remediation guidance

Blue Team / Defense:
Understand these techniques to:

Impro capabilities

Develop countermeasures

Enhance incident response

Train security teams

Liability Disclaimer

The authors and contributors:

Provide this software "AS IS" without warranty

Accept no responsibility for misuse

Are not liable for any damages resulting from use

Do not endorse illegal acti

By using this software, you agree:

To comply with all applicable laws

To use only in authorized contexts

To accept full responsibility for your actions

To not hold authors liable for any consequences

Responsible Disclosure

If you disco or impro:

Report Issues (public)

Or email: (private)

Follow coordinated disclosure principles

Allow reasonable time for response

Conclusion

This project represents a comprehensi of Windows kernel programming, pri escalation, persistence mechanisms, and system internals. Through the three-component architecture (kernel driver, COM DLL, and management service), it demonstrates techniques rarely seen in modern dri.

Key Achie

First working IRP-based keyboard filter in over a decade

Sophisticated TrustedInstaller pri escalation

Inno line-buffering for reduced network o

Complete installation/uninstallation automation

Comprehensi status monitoring

Educational Value

Students and researchers can learn:

Windows Dri (WDM) internals

Kernel synchronization primitives

IRP handling and cancellation

Winsock Kernel (WSK) networking

BCD structure and manipulation

COM hijacking techniques

Windows Service de

Future Enhancements

KMDF dri (modern framework)

Configurable network destination (beyond localhost)

Encrypted keystroke transmission

Enhanced stealth (remove test mode requirement)

Multi-keyboard simultaneous support

Impro reliability

---

Repository Information

Project URL:

Author: Marek Wesolowski

Contact: | +48 607 440 283

License: Educational Use Only (See LICENSE file)

: 1.0.0

Last Updated: October 2025

Star this repository if you found it educational!

⚠️ Remember: Knowledge is power. Use it responsibly. ⚠️

项目信息

开发语言：C++

Star 数：15

技术要点

该项目属于防护思路方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕Windows Kernel-Mode Keylogger - Educational rootkit driver intercepting keyboard IRPs for UDP logging. Demonstrates stealth persistence, privilege escalation & IRP hooking for offensive security research and defensive analysis.展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。