STKMapper - Stealth Kernel Driver Manual Mapper

A custom CLI tool for manually mapping Windows kernel-mode drivers into physical memory by exploiting the iqvw64e.sys Intel driver vulnerability (CVE-2015-2291). Designed for stealth operations with comprehensive anti-forensic countermeasures.

⚠️ WARNING: This project is for educational purposes only. I am not responsible for any misuse of this software.

---

Table of Contents

• How It Works
• System Requirements
• Build Instructions
• Usage
• Technical Details
• Anti-Forensic Features
• Driver Requirements
• Limitations
• License

---

How It Works

STKMapper loads a driver into kernel memory without using standard Windows driver loading APIs (like ZwLoadDriver or the Service Control Manager). Instead, it performs manual mapping — a technique that bypasses Windows driver signature enforcement (DSE).

High-Level Flow

┌─────────────────────────────────────────────────────────────┐
│  1. Open iqvw64e.sys (vulnerable Intel driver)              │
│     └─ Uses IOCTL 0x8086200B to map physical memory         │
├─────────────────────────────────────────────────────────────┤
│  2. Parse the target .sys driver PE image                   │
│     └─ Validate DOS/NT headers, enumerate sections          │
├─────────────────────────────────────────────────────────────┤
│  3. Allocate contiguous physical memory                     │
│     └─ Scan 1MB–256MB range for free pages (0xFF probe)     │
│     └─ Map physical pages to user-space via IOCTL           │
├─────────────────────────────────────────────────────────────┤
│  4. Copy PE sections to allocated kernel memory             │
│     └─ Headers → kernel base                                │
│     └─ Each section → kernel base + section.VirtualAddress  │
├─────────────────────────────────────────────────────────────┤
│  5. Fix relocations (base address delta patching)           │
│     └─ Process IMAGE_DIRECTORY_ENTRY_BASERELOC blocks       │
│     └─ Apply delta = actualBase - preferredBase             │
├─────────────────────────────────────────────────────────────┤
│  6. Resolve imports (kernel API functions)                  │
│     └─ Use NtQuerySystemInformation to find ntoskrnl.exe    │
│     └─ Parse ntoskrnl.exe exports to resolve function addrs │
├─────────────────────────────────────────────────────────────┤
│  7. Erase PE headers from kernel memory (stealth)           │
│     └─ Zero out SizeOfHeaders bytes at kernel base          │
├─────────────────────────────────────────────────────────────┤
│  8. Call ManualMapEntry(BaseAddress)                        │
│     └─ Find entry point via exports or AddressOfEntryPoint  │
│     └─ Execute the driver's initialization routine          │
├─────────────────────────────────────────────────────────────┤
│  9. Self-destruct (anti-forensic cleanup)                   │
│     └─ Scramble PEB, delete prefetch, timestomp, etc.       │
└─────────────────────────────────────────────────────────────┘

Key Technique: Physical Memory Allocation

Instead of using VirtualAlloc/MmAllocateContiguousMemory, STKMapper:

1. Scans physical memory from 0x100000 (1MB) to 0x10000000 (256MB) looking for pages filled with 0xFF (indicating unmapped/free memory).
2. Maps each candidate page into user space via the vulnerable driver's IOCTL_IQVW64E_MAP_IO_SPACE (0x8086200B).
3. Probes the first byte — if it's 0xFF, the page is likely free.
4. Verifies contiguity by checking all pages in the required range.
5. Maps the full region and zeroes it out for use as the driver's execution space.

Key Technique: Import Resolution

Since the driver runs in kernel memory but is loaded from user space, it needs kernel function addresses. STKMapper:

1. Calls NtQuerySystemInformation(SystemModuleInformation, ...) to enumerate loaded kernel modules.
2. Finds ntoskrnl.exe in the module list and gets its kernel base address.
3. Loads ntoskrnl.exe as a data file (without resolving imports) using LoadLibraryExA(..., DONT_RESOLVE_DLL_REFERENCES).
4. Uses GetProcAddress on the local copy to find function RVAs.
5. Calculates the actual kernel address: kernelBase + functionRVA.

---

System Requirements

Supported Operating Systems

OS	Support	Notes
Windows 10 x64	✅ Supported	All versions (1507–22H2)
Windows 11 x64	✅ Supported	All versions
Windows Server 2016 x64	✅ Supported
Windows Server 2019 x64	✅ Supported
Windows Server 2022 x64	✅ Supported
Windows 7 x64	⚠️ Partial	Requires iqvw64e.sys availability
Windows 8/8.1 x64	⚠️ Partial	Requires iqvw64e.sys availability
x86 (32-bit)	❌ Not supported	64-bit only (AMD64)

Prerequisites

• Architecture: x64 (AMD64) only
• Privileges: Administrator rights (required for SCM access and IOCTL calls)
• Vulnerable Driver: iqvw64e.sys must be present at C:\Windows\System32\drivers\iqvw64e.sys
  • This is the Intel QuickPath Interconnect driver with a known physical memory mapping vulnerability
• Target Driver: A 64-bit kernel-mode driver (.sys) with a ManualMapEntry export

Build Requirements

• Compiler: MSVC (Visual Studio 2022 or later) with C++17 support
• SDK: Windows 10 SDK (10.0.19041.0 or later)
• Build command:

  cl /EHsc /std:c++17 stkmapper\mapper.cpp /Fe:stkmapper.exe
  

  Or open stkmapper.slnx in Visual Studio and build the solution.

---

Usage

Basic Usage

stkmapper.exe <driver.sys>

Example

stkmapper.exe C:\Users\admin\Desktop\mydriver.sys

Expected Output

========================================
[*] Initializing vulnerable driver interface...
========================================
[+] Vulnerable driver interface opened
========================================
[*] Loading driver image...
[+] Image base: 0x00007FF700000000, size: 0x5000
[+] Sections: 3
========================================
[*] Allocating kernel memory...
[*] Searching for free physical memory region...
[+] Kernel memory at 0x1a00000 (virtual: 0x7ffe0000)
========================================
[*] Fixing relocations...
[+] Fixed 42 relocations
========================================
[*] Resolving imports...
[+] Resolved 15 imports
========================================
[*] Erasing PE headers...
[+] PE headers erased from kernel memory
========================================
[*] Calling ManualMapEntry...
[+] Entry point at 0x7ffe0000
[+] Calling with BaseAddress = 0x7ffe0000
[+] ManualMapEntry returned: 0x00000000
========================================
[*] Cleaning up traces...
[*] Unloading vulnerable driver...
[*] Vulnerable driver stopped
[*] Vulnerable driver service deleted
========================================
[+] Driver loaded successfully!
[+] Driver base (kernel VA): 0x7ffe0000
========================================

Exit Codes

Code	Meaning
0	Success — driver loaded and self-deletion initiated
1	Failure — see error message for details

---

Technical Details

Vulnerable Driver: iqvw64e.sys

The Intel iqvw64e.sys driver exposes two critical IOCTLs:

IOCTL	Code	Function
IOCTL_IQVW64E_MAP_IO_SPACE	0x8086200B	Maps physical memory to user-space virtual address
IOCTL_IQVW64E_UNMAP_IO_SPACE	0x8086200F	Unmaps previously mapped physical memory

These IOCTLs allow any user-mode process (with a handle to the driver) to read/write arbitrary physical memory, effectively providing ring-0 access from user mode.

PE Structure Definitions

The project includes a standalone pe_structures.h header that defines all necessary PE structures (IMAGE_DOS_HEADER, IMAGE_NT_HEADERS64, IMAGE_SECTION_HEADER, etc.) without requiring the Windows Driver Kit (WDK). The header is designed to:

• Work standalone when compiled without Windows SDK headers
• Gracefully coexist with Windows SDK headers (via #ifndef _WINNT_ guard)
• Always define custom helper macros (IMAGE_FIRST_SECTION, IMAGE_RELOCATION_COUNT, etc.)

Memory Layout in Kernel

┌──────────────────────────────┐
│  DOS Header (64 bytes)       │  ← kernelBase
├──────────────────────────────┤
│  NT Headers                  │
│  ├─ Signature (PE\0\0)       │
│  ├─ File Header              │
│  └─ Optional Header64        │
├──────────────────────────────┤
│  Section Headers             │
│  └─ .text, .data, .rdata    │
├──────────────────────────────┤
│  Section Data                │
│  ├─ .text  (code)            │  ← kernelBase + section[0].VirtualAddress
│  ├─ .data  (data)            │
│  └─ .rdata (read-only data)  │
├──────────────────────────────┤
│  Import Address Table (IAT)  │
│  └─ Resolved function addrs  │
├──────────────────────────────┤
│  Base Relocation Table       │
│  └─ Already applied          │
└──────────────────────────────┘

After EraseHeaders(), the DOS and NT headers at the base are zeroed out, making forensic analysis of the memory dump more difficult.

---

Anti-Forensic Features

STKMapper includes comprehensive anti-forensic countermeasures that activate after successful driver loading:

1. PEB Scrambling

• XOR-scrambles the Process Environment Block's CommandLine and ImagePathName buffers
• Prevents tools like Process Explorer from showing the correct executable path
• Uses incrementing XOR keys (0xAA + i, 0xBB + i)

2. Prefetch File Deletion

• Deletes C:\Windows\Prefetch\mapper-*.pf files
• Prevents Windows from recording execution history
• Uses wildcard matching since the prefetch hash is unpredictable

3. File Timestamp Spoofing (Timestomping)

• Reads timestamps from notepad.exe (or calc.exe as fallback)
• Applies the same creation/modification/access timestamps to the mapper executable
• Makes it appear as if the file was never modified

4. Registry MRU Cleanup

• Cleans ComDlg32\OpenSavePidlMRU entries
• Cleans ComDlg32\LastVisitedPidlMRU entries
• Scans both binary (REG_BINARY) and string (REG_SZ) data for executable name/directory matches

5. Console Clearing

• Calls system("cls") to clear all console output

6. Self-Deletion

• Launches a hidden cmd.exe child process with a 3-second delay
• The child process deletes the .exe file after the main process exits
• Uses choice /C Y /N /D Y /T 3 for the delay, then Del to remove the file
• The main process calls ExitProcess(0) immediately

---

Driver Requirements

The target driver (.sys file) must meet these requirements:

1. 64-bit (AMD64) — x86 drivers are not supported
2. PE32+ format — Must use the PE32+ optional header (Magic = 0x020B)
3. Export ManualMapEntry — The driver should export a function named ManualMapEntry with the signature:

   NTSTATUS ManualMapEntry(PVOID BaseAddress);

   If ManualMapEntry is not found in exports, the tool falls back to AddressOfEntryPoint.

Creating a Compatible Driver

Your driver should include something like:

#pragma section("MANUALMAP", read, execute)
__declspec(allocate("MANUALMAP")) 
NTSTATUS ManualMapEntry(PVOID BaseAddress) {
    // Your initialization code here
    // BaseAddress points to the driver's base in kernel memory
    
    // Example: call DriverEntry
    typedef NTSTATUS (*DriverEntry_t)(PVOID, PVOID);
    DriverEntry_t DriverEntry = (DriverEntry_t)((ULONG_PTR)BaseAddress + 0x1000);
    return DriverEntry(BaseAddress, NULL);
}

And export it in the .def file or via #pragma comment(linker, "/export:ManualMapEntry=ManualMapEntry").

---

Limitations

• x64 only — Does not support 32-bit x86 systems
• Requires iqvw64e.sys — The vulnerable driver must be present on the target system
• Physical memory scanning — The allocation method (scanning for 0xFF pages) is heuristic and may fail on systems with unusual memory layouts
• No import forwarding — Ordinal imports are logged but not resolved
• Single-threaded — Does not handle multi-processor synchronization
• No exception handling — If the driver crashes, the system may bugcheck
• Antivirus detection — The IOCTL patterns and memory mapping behavior may be flagged by security software

---

License

This project is provided for educational and authorized security research purposes only. The authors are not responsible for any misuse or damage caused by this software.

---

References

• CVE-2015-2291: Intel iqvw64e.sys arbitrary physical memory mapping
• Windows PE Format specification (Microsoft)
• Windows kernel module loading internals