TheCruZ/kdmapper

KDMapper is a simple tool that exploits iqvw64e.sys Intel driver to manually map non-signed drivers in memory

View on GitHub ↗Jump to charts ↓Open shareable report →

TheCruZ/kdmapper has 3k+ stars and 650+ forks on GitHub, is written in C++, and was last pushed on Aug 23, 2026. Data as of . Signed-in members get hourly updates — create a free account.

Summary Information

Updated 56 minutes ago
Added to GitGenius on September 22nd, 2026
Created on May 30th, 2020
Open Issues & Pull Requests: 3 (+0)
GitHub issues: Enabled
Number of forks: 662
Total Stargazers: 3,160 (+0)
Total Subscribers: 45 (+0)

Repository Insights (GitGenius)

Median issue/PR response: 4.8 hours
Mean response time: 2.5 days
90th percentile: 3.5 days
Tracked items: 73

Charts & Analytics

Fetching additional details & charts...

Issue Activity (beta)

Open issues: 1
New in 7 days: 0
Closed in 7 days: 0
Avg open age: 3 days
Stale 30+ days: 0
Stale 90+ days: 0

Recent activity

Opened in 7 days: 0
Closed in 7 days: 0
Comments in 7 days: 0
Events in 7 days: 0

Top labels

No label distribution available yet.

Most active issues this week

Sign in to see which issues are moving.
Sign in

Detailed Description

KDMapper is a kernel driver injection tool that exploits the iqvw64e.sys Intel driver to manually map unsigned drivers into kernel memory on Windows systems.

The tool solves the problem of loading unsigned kernel drivers by leveraging a vulnerability in the Intel driver to bypass signature verification. It works by hooking NtAddAtom, clearing kernel data structures that track loaded drivers (MmUnloadedDrivers, PiDDBCacheTable, g_KernelHashBucketList), and using NtLoadDriver and NtUnloadDriver to minimize forensic traces. The approach includes features like header section skipping during driver copying, support for drivers compiled with /GS-, and the ability to modify driver parameters before execution. An optional PDB-based offset system allows the tool to adapt to Windows updates by parsing symbol files rather than relying on hardcoded offsets.

This tool is intended for security researchers and developers working on low-level Windows internals who need to load custom unsigned drivers. It suits scenarios where standard driver loading mechanisms are unavailable or undesirable. The project requires careful driver development practices: entry points must return quickly to avoid triggering Patch Guard, and infinite loops in DriverEntry will cause crashes. Users must be aware that DriverObject and RegistryPath parameters are NULL in manually mapped drivers, differing from normal driver loading procedures. The vulnerable driver blocklist should be disabled if enabled on the target system.

Development activity shows consistent maintenance across a wide range of Windows versions from Windows 10 through Windows 11. The project includes tooling for symbol parsing through the SymbolsFromPDB utility, indicating an effort to maintain compatibility as Windows evolves. Documentation covers common failure modes and troubleshooting steps, suggesting active engagement with user issues.