BYOVD - BYOVD research use cases featuring vulnerable driv

项目说明

<img width="956" height="538" alt="cropped-Aug 28, 2025, 03_39_19 PM" src=" />

BYOVD is a collection of PoCs demonstrating how drivers can be exploited to disable AV/EDR solutions.

The collection includes both undocumented drivers and those with existing co in LOLDDrivers or Microsoft's recommended dri rules.

---
> Since its initial discovery, the TfSysMon driver has been added to LOLDrivers and abused by ransomware groups using the EDRKillShifter tool, as reported by Sophos & ESET
---

📚 Table of Contents

🔍 O

🏗️ Project Structure

🔧 Building

📦 byo

💡 POCs

🔬 Complete Dri Engineering Process (x64)

🔗 References

⚠️ Disclaimer

🔍 O

The BYO has recently gained popularity in offensi, particularly with the release of tools such as SpyBoy's *Terminator* (sold for $3,000) and the *ZeroMemoryEx Blackout* project. These tools capitalize on drivers to disable AV/EDR agents, facilitating further attacks by reducing detection.

This repository contains several PoCs de for educational purposes, helping researchers understand how these drivers can be abused to terminate processes.

🏗️ Project Structure

The project is organized as a Rust Cargo workspace. Most PoCs share a common library (byo) that handles the boilerplate: dri lifecycle, IOCTL dispatch, process monitoring, pri adjustment, and cleanup. Each killer is a thin binary (~50-100 lines) that only defines its dri configuration. K7Terminator, Astra64-Killer, Ktapi-Killer, and Xhunter1-Killer are standalone — they ha own [workspace] declarations and are built directly from their own directories, not via the root workspace.

Each *-Killer/ directory contains its own Cargo.toml, src/main.rs (the Dri impl + CLI), README.md (dri + usage), and the matching .sys file the binary loads at runtime.

🔧 Building

Prerequisites: Rust toolchain and Studio Build Tools with the Windows SDK.

Binaries are output to target/release/. Copy the corresponding .sys driver file into the same directory as the executable before running.

📦 byo

byo is the shared library that all PoCs (except K7Terminator) are built on. It exposes two complementary APIs -- a high-le one for the standard "install driver, kill on sight, clean up" flow, and a low-le one for killers that need a custom flow (attach to an already-loaded driver, fan out to multiple PIDs, structured IOCTL buffers, custom retry logic, etc.). Both can be mixed in the same binary.

Module layout

High-level API: Dri trait + run()

This is what the bundled killers use. Implement the trait, call byo::run(), done.

run() does: preflight_check → install service (SER) → StartService → kill-on-sight monitor (Ctrl+C to exit) → stop + delete service.

Optional trait o with their defaults:

| Method | Default | Purpose |
|---|---|---|
| de() | SER | CreateFileW access flags |
| skip_unload() | false | Skip dri (e.g. drivers that BSOD on unload) |
| ignore_ioctl_error() | false | Treat IOCTL failure as success (e.g. NSecKrnl reports error on success) |
| ioctl_output_size() | 0 | Expected output buffer size in bytes |
| preflight_check() | Ok(()) | Pre-launch (e.g. LocalSystem check) |

Low-level API: imperati

When the trait flow doesn't fit -- e.g. the driver is already loaded and you only want to fire one IOCTL, you need a custom retry policy, the IOCTL takes a structured input rather than just a PID, or you want to fan out across all matching PIDs -- compose the lower-le directly.

Dri -- Byo:

IOCTL dispatch -- De exposes fi shapes:

| Method | Use when |
|---|---|
| ioctl<I, O>(code, &input, &mut output) | Both input and output buffers, separate types |
| ioctl_inout<T>(code, &mut data) | Same buffer for input + output |
| ioctl_in<I>(code, &input) | Input only, no output buffer |
| ioctl_in_unchecked<I>(code, &input) | Input only, ignore failure (per-call alternative to ignore_ioctl_error) |
| ioctl_raw(code, in_ptr, in_size, out_ptr, out_size) | Raw pointer escape hatch |

The typed forms remove the manual to_ne_bytes() / extend_from_slice() boilerplate when the IOCTL takes a struct (e.g. { pid: u32, padding: [u8; 20] }).

Process lookup -- find_pid_by_name(name) (first match) and find_all_pids_by_name(name) (all matches, excludes system PIDs ≤ 4).

Custom monitor loop -- run_monitor_loop(name, interval, |pid| ...) takes a closure so you can do whatever you want per match (multiple IOCTLs, structured logging, fan-out across PIDs, retry on error).

Pri -- enable_pri("SeDebugPri") / enable_pri("SeLoadDri") for drivers that require explicit token pri. ensure_running_as_local_system() returns an error if the process is not running as S-1-5-18.

Handle wrappers -- WinHandle (auto-CloseHandle) and ScHandle (auto-CloseSer) are Send + Sync and can be mo threads.

Example: attach to an already-loaded driver, no service lifecycle

This is what UnknownKiller --attach does -- skip SCM entirely, just open the device and fire the IOCTL once:

Back-compat aliases

FileHandle / Ser still resolve to WinHandle / ScHandle, and get_pid_by_name is kept as an alias for find_pid_by_name, so older code referencing those names keeps compiling.

💡 POCs

Below are the drivers and their respective PoCs a in this repository:

AppRemo: Targets ardrv.sys from OPSWAT AppRemover.

Astra64-Killer: Targets astra64.sys from EnTech Taiwan (Astra32 / TVicHW) -- standalone data-only Shadow SSDT hijack EDR killer.

BdApiUtil-Killer: Targets BdApiUtil64.sys from Baidu AntiVirus (C).

CcProtect-Killer: Targets CcProtect.sys from CnCrypt.

EnPort: Targets EnPortv.sys from Guidance EnCase.

GameDri: Targets GameDri.sys from Fedeen Games (C).

GoFlyDr: Targets GoFlyDrv.sys from Golink.

HNOs2Ec-Killer: Targets HNOs2Ec.sys from HONOR (PCManager).

HWAudioOs2Ec-Killer: Targets HWAudioOs2Ec.sys from Huawei.

K7Terminator: Targets K7RKScan.sys from K7 Computing (C, C) -- Full write-up.

Ksapi64-Killer: Targets ksapi64.sys / ksapi64_del.sys from Kingsoft Corporation.

Ktapi-Killer: Targets ktapi.sys from Kontron -- standalone two-stage shellcode EDR killer.

MonProcess-Killer: Targets MonProcess.sys from HONOR (HnRSMService).

MonProcessEX-Killer: Targets MonProcessEX.sys from HONOR.

NSec-Killer: Targets NSecKrnl.sys from NSEC ( BYO).

PCTcore64-Killer: Targets PCTcore64.sys from PC Tools (C).

PoisonX-Killer: Target PoisonX.sys from Microsoft ( reproduction)

STProcessMonitor-Killer: Targets STProcessMonitor.sys from Safetica (C, supports v11.11.4 and v11.26.18).

TfSysMon-Killer: Targets sysmon.sys from ThreatFire System Monitor.

UnknownKiller: Targets unknown.sys from an unattributed (dri TBD).

: Targets .sys from Tg Soft.

Wsftprm-Killer: Targets wsftprm.sys from Topaz Antifraud (C).

Xhunter1-Killer: Targets legacy xhunter1.sys from Wellbia (XIGNCODE3, C).

Xkpsm-Killer: Targets xkpsm.sys from JiranJikyosoft X-Keeper.

🔬 Complete Dri Engineering Process (x64)

This section demonstrates the complete A-Z reverse engineering methodology using the TfSysMon driver as a practical example. This process applies to any x64 Windows kernel dri.

🎯 Step 0: Pre-Analysis - Function Import Screening

Check dri before starting reverse engineering.

A basic process killer dri 2 things:

a way to get a handle on a process (for instance ZwOpenProcess or NtOpenProcess)

a way to terminate the process (for instance ZwTerminateProcess or NtTerminateProcess)

Check if a dri both function types. If a driver has in its imported functions Nt/ZwOpenProcess AND Nt/ZwTerminateProcess then it's a potential process killer dri.

Only after confirming these imports should you proceed to detailed reverse engineering in IDA Pro.

🛠️ Prerequisites for x64 Dri

Required Tools:

IDA Pro - for disassembling the driver for static analysis

OSRLoader - for loading/running the driver (alternative to sc.exe command)

📍 Step 1: Locate and Analyze Dri

Every Windows dri with Dri - find this function first:

In TfSysMon, the Dri looks like this:

Analysis Notes:

The code performs some initialization with BugCheckParameter2 and BugCheckParameter3

The real dri happens in sub_17484

Follow the call to sub_17484(Dri) - this is where actual dri occurs

📍 Step 2: Follow Dri Chain

Na to the initialization function (sub_17484):

Key Reverse Engineering Findings:

Device Name: \\Device\\TfSysMon (kernel space)

Symbolic Link: \\DosDevices\\TfSysMon (user-mode accessible as \\.\\TfSysMon)

Device Type: 0x22 = FILE_DE

IRP Handler: All major functions point to sub_17694

Target Function: MajorFunction[14] = IRP_MJ_DE handler

📍 Step 3: Analyze the IRP Dispatch Function

Na to the dispatch function (sub_17694):

Reverse Engineering Analysis:

Device occurs first (if ( a1 != De ))

CurrentStackLocation->MajorFunction determines the operation type

CRITICAL: MajorFunction 14 (0xE) and 15 (0xF) call sub_177D8

MajorFunction 14 = IRP_MJ_DE = IOCTL processing

The code path is: IOCTL request → sub_177D8

📍 Step 4: Reverse Engineer the IOCTL Handler

Na to the IOCTL processing function (sub_177D8):

Critical Reverse Engineering Disco:

IOCTL Extraction: v7 = *(_DWORD *)(a2 + 24) gets the IOCTL code from IO_STACK_LOCATION

Input Buffer: Irp->AssociatedIrp.MasterIrp contains user data

Buffer Length: v9 = *(unsigned int *)(a2 + 16) gets input buffer size

IOCTL: 0xB4A00404 leads to sub_1837C

Size Check: Only buffer ≥ 0x18 (24 bytes) - minimal !

📍 Step 5: Analyze the Function

Na to the process termination function (sub_1837C):

Function Analysis:

Input Structure: From the driver code analysis, we determined the buffer layout where PID is at offset +4

Input Parsing: v3 = *(void **)(a1 + 4) extracts PID from input buffer at offset +4

Process Opening: ZwOpenProcess with minimal access rights (1u = PROCESS_TERMINATE)

No Security Checks: No of caller pri or target process protection

Process Termination: Direct call to ZwTerminateProcess

Retry Logic: Multiple attempts for both opening and termination

Any Process: Can terminate any process accessible to SYSTEM account

📍 Step 6: Map the Complete Attack Chain

Complete Reverse Engineering Flow:
1. Entry Point: User calls De on \\.\\TfSysMon
2. IRP Creation: I/O Manager creates IRP with MajorFunction = 14
3. Dispatch: sub_17694 routes to sub_177D8 for IOCTL processing
4. IOCTL Check: sub_177D8 IOCTL code 0xB4A00404 and buffer size ≥ 24 bytes
5. Execution: Calls sub_1837C with user input buffer
6. Termination: sub_1837C extracts PID from offset +4 and terminates process via ZwTerminateProcess

Input Buffer Structure (from dri engineering):

> This methodology demonstrates how to systematically reverse engineer any Windows x64 kernel driver to identify similar by following the execution path from user-mode communication through to dangerous kernel operations.

Support 🍺

If BYO your red team operations, consider buying me a beer:

<a href=" src=" width="200" height="60"></a>

🔗 References

Alice Climent-Pommeret's Blog: Finding and Exploiting Process Killer Drivers with LOL for $3000

LOLDrivers: A Central Repository of Known Drivers

Microsoft Dri Rules: Microsoft's Recommended Dri Rules

Windows Kernel Programming by Pa

Windows Internals, Part 1 & 2 by Mark E. Russinovich, Alex Ionescu, Da

⚠️ Disclaimer

The BYO is for educational and research purposes only. The author is not responsible for any misuse or damage caused by these programs. Always seek explicit permission before using these tools on any system.

项目信息

开发语言：Rust

Star 数：963

技术要点

该项目属于漏洞知识库方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕BYOVD research use cases featuring vulnerable driver discovery and reverse engineering methodology. (CVE-2025-52915, CVE-2025-1055, CVE-2026-3609, CVE-2026-8501).展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。