يؤدي هذا إلى وضع الإضافة في مجلد فرعي من مجلد الإضافات الخاص بالمستخدم (مثل
`%APPDATA%\Hex-Rays\IDA Pro\plugins\DriverBuddyReloaded\` أو `~/.idapro/plugins/DriverBuddyReloaded/`)، مع الاحتفاظ بنقطة الدخول
`DriverBuddyReloaded.py` *داخل* ذلك المجلد الفرعي. هذا هو التخطيط المقصود: يقرأ IDA البيان التصريحي،
ويحمل نقطة الدخول المعلنة من المجلد الفرعي، ويضع المجلد الفرعي في `sys.path` حتى تتمكن نقطة الدخول من
استيراد حزمة `DriverBuddyReloaded` المجاورة. لا **تحتاج** إلى نقل `DriverBuddyReloaded.py` إلى المستوى الأعلى.

تحقق من التثبيت باستخدام `hcli plugin status`، ثم شغّل IDA وتأكد من ظهور الإضافة ضمن
`Edit -> Plugins` (تحقق من نافذة الإخراج (Output window) من وجود أي أخطاء Python عند بدء التشغيل).

للتثبيت من نسخة محلية للاختبار (مثلًا بعد التعديلات الخاصة بك)، قم بتشغيل `hcli plugin install .` من
جذر المستودع؛ يقوم `hcli plugin lint .` بالتحقق من صحة البيان/التخطيط أولاً.

### IDA 7.6 / 8.x (نسخ يدوي)

لا تحتوي هذه الإصدارات على مدير إضافات، لذا فإن الإضافة المثبتة عبر `hcli` في مجلد فرعي **لن** يتم اكتشافها. انسخ
مجلد `DriverBuddyReloaded` وملف البرنامج النصي `DriverBuddyReloaded.py` مباشرة إلى **المستوى الأعلى** من
مجلد إضافات IDA، على سبيل المثال:
- `%APPDATA%\Hex-Rays\IDA Pro\plugins\`
- `C:\Program Files\IDA Pro 8.4\plugins\`
- `~/.idapro/plugins/`

سيكون التخطيط الناتج هو `plugins\DriverBuddyReloaded.py` بجانب `plugins\DriverBuddyReloaded\` (مجلد الحزمة).

### ملاحظات

إذا كان IDA الخاص بك مهيأ لـ Python 2، فشغّل الملف الثنائي `idapyswitch` (الموجود في مجلد IDA) لتبديله إلى Python 3.

**ملاحظة:** يعمل Driver Buddy Reloaded على IDA 7.6+، 8.x (بما في ذلك 8.4) و 9.0+ مع Python 3. يتم التعامل مع جميع الاختلافات الخاصة بإصدارات IDA في واجهة برمجة التطبيقات (إزالة `get_inf_structure`، ووحدة `ida_struct` ووظائف المساعدة `idc.*struc*` في IDA 9.0، وما إلى ذلك) داخليًا من خلال طبقة التوافق `DriverBuddyReloaded/ida_compat.py`.

## الاستخدام السريع

لاستخدام ميزة التحليل التلقائي:

1. شغّل IDA وحمّل برنامج تشغيل Windows kernel driver.
2. انتقل إلى `Edit -> Plugins -> Driver Buddy Reloaded` أو اضغط `CTRL+ALT+A` لبدء التحليل التلقائي.
3. تحقق من نافذة "Output" للحصول على نتائج التحليل، ونافذة **Driver Buddy Reloaded - Findings** التي تفتح
   عند انتهاء التشغيل (انقر نقرًا مزدوجًا على صف للانتقال إلى عنوانه).
4. تتم كتابة الملفات التالية في دليل قاعدة بيانات IDA (جميعها مسبوقة بـ `<DRIVER_NAME>-YYYY-MM-DD-TIMESTAMP-`):
   - `findings.json` - نتائج قابلة للقراءة آليًا (IOCTLs، وظائف مُعلّمة، أسماء الأجهزة، pooltags، سلاسل استدعاء، استكشاف استدلالي، مراجعة ACL للجهاز، روابط رمزية، مراجعة الصادرات، التعليمات البرمجية المميزة)
   - `report.html` - تقرير HTML مستقل، مجمّع حسب الخطورة
   - `pooltags.txt` - تفريغ pooltags بتنسيق `pooltags.txt` لـ WinDbg
   - `autoanalysis.txt` - سجل التحليل النصي الكامل (يعكس نافذة Output)

لفك تشفير IOCTL:

1. ضع مؤشر الماوس على السطر الذي يحتوي على رمز IOCTL مشتبه به.
2. انقر بزر الماوس الأيمن واختر `Driver Buddy Reloaded -> Decode IOCTL`؛ بدلاً من ذلك، اضغط على الاختصار `CTRL+ALT+D`.

لإعادة فتح نافذة IOCTLs أو نافذة findings في أي وقت (دون إعادة تشغيل التحليل):

- اضغط `CTRL+ALT+I` لفتح نافذة IOCTLs.
- اضغط `CTRL+ALT+F` لفتح نافذة findings.

### الاستخدام المتقدم

- يحتوي دليل [vulnerable_function_lists](https://github.com/voidsec/driverbuddyreloaded/blob/HEAD/DriverBuddyReloaded/vulnerable_functions_lists) على قوائم بالوظائف/واجهات برمجة التطبيقات/التعليمات البرمجية التي قد تشكل خطورة؛ يتم تقديم وصف موجز لسبب إدراج وظيفة/API معينة. يمكنك تحرير القائمة `custom` لتضمين وظائف محددة للسائق.
  
  **ملاحظة**: `winapi_function_prefixes` ستطابق جزئيًا بداية اسم الوظيفة (مثلًا `Zw` ستطابق `ZwClose`، `ZwCommitComplete` وهكذا) بينما `winapi_functions` ستقوم بمطابقة تامة فقط.
- في [find_opcodes.py](https://github.com/voidsec/driverbuddyreloaded/blob/HEAD/DriverBuddyReloaded/find_opcodes.py)، يعمل خيار `find_opcode_data` (القيمة الافتراضية `False`)
  على قمع مطابقات التعليمات البرمجية التي تقع في أقسام البيانات
  ([issue #11](https://github.com/VoidSec/DriverBuddyReloaded/issues/11)). يؤدي تغييره إلى `True` إلى إظهار
  مطابقات البايت الخام في البيانات أيضًا؛ إذا تم تفويت تعليمة برمجية حقيقية بهذه الطريقة، فإن الذهاب إلى العنوان المُبلغ عنه وإعادة تعريف
  البايتات كرمز عادة ما يستعيدها. يتم الإبلاغ عن المطابقات مثل أي مرحلة أخرى (نافذة النتائج،
  `findings.json`، `report.html`).
  
  **انتبه**: يؤدي تغييره إلى `True` إلى توليد مزيد من النتائج الإيجابية الخاطئة!

## حول Driver Buddy Reloaded

**Driver Buddy Reloaded** هي إضافة IDA Pro بلغة Python تساعد في أتمتة بعض المهام المملة في هندسة عكسية لـ Windows Kernel Drivers. تحتوي على عدد من الميزات المفيدة، مثل:

* تحديد نوع السائق (WDM، KMDF، UMDF، WDF، Mini-Filter، Stream Minidriver، AVStream، PortCls)
* تحديد موقع وظائف `DispatchDeviceControl` / `DispatchInternalDeviceControl` لكل **نوع** من السائقين
  (يقوم فحص تخزين `MajorFunction[IRP_MJ_DEVICE_CONTROL]` بالعثور على المعالج حتى في سائق minifilter/WDF الذي يعرض أيضًا
  جهاز تحكم قديم، وحتى عندما يكون التعيين في دالة مساعدة بدلاً من `DriverEntry`)
* تعبئة الهياكل الشائعة لسائقين `WDF` و `WDM`
    * محاولات التعرف على هياكل مثل `IRP` و `IO_STACK_LOCATION` ووضع تسميات عليها
    * وضع تسميات على استدعاءات وظائف `WDF` التي عادةً ما تكون غير موسومة
    * إنشاء تعداد IDA لـ `IRP_MJ_FUNCTION` وتطبيقه على عناصر مصفوفة `MajorFunction` في `DriverEntry` (WDM)
* العثور على رموز IOCTL وفك تشفيرها
    * مسح متعدد الاستراتيجيات تلقائي لوظائف المعالج المحددة (لا حاجة لوضع المؤشر):
      شجرة ctree الخاصة بـ decompiler (تستعيد الرموز المخفية بواسطة jump-table أو binary-search dispatch التي لا تظهر أبدًا كقيم فورية)، واسترداد جدول switch الخاص بـ IDA، وبديل raw immediate-operand (يعمل البديل فقط على
      دالة تقوم فعليًا بقراءة IoControlCode الخاص بـ IRP، لذا لا يمكن لوظيفة مكتبة مساعدة تم التعرف عليها خطأً أن تسرب
      ثوابتها الداخلية كـ IOCTLs خاطئة)
    * يتم حل قيم NTSTATUS ديناميكيًا من قاعدة بيانات أنواع IDA (مع بديل واسع النطاق مشفر)، ويتم استبعاد
      IOCTLs **الصادرة** التي يرسلها السائق فقط إلى الأسفل (`IoBuildDeviceIoControlRequest` / `ZwDeviceIoControlFile`
      / ...) حتى لا يتم الخلط بينها وبين سطح الهجوم الخاص بالسائق
* وضع علامات على الوظائف المعرضة لسوء الاستخدام
* العثور على `DeviceName` المحتمل (مسح mmap + بديل قاعدة بيانات سلاسل IDA، مع عنوان المصدر)
* تفريغ `Pooltags` (أساسي قائم على الاستيراد + بديل انتشار السجل للعلامات المخزنة في سجل)
* **فحوصات استدلالية للثغرات الأمنية** لكل معالج والوظائف التي يستدعيها بشكل متعدٍ: نسخة مستخدم غير موثقة،
  TOCTOU/double-fetch، use-after-free (داخل الوظيفة وعبر الوظائف عبر متغير عام تم تحريره)،
  عدم وجود بوابة امتياز، عدم تطابق IRQL، تعيين MDL غير آمن، مخازن مخصصة على الرصة (`_alloca`)، تخصيص مجموعة دون التحقق من الحجم، تعليمات معالج مميزة (إدخال/إخراج المنفذ `in`/`out`، `mov cr*`)، كتابة عشوائية
  (write-what-where)، ومراجع `\Device\PhysicalMemory` (نمط BYOVD) - انظر
  [فحوصات الثغرات الاستدلالية](#heuristic-vulnerability-checks)
* **تدقيق ACL للجهاز وتتبع الروابط الرمزية**: وضع علامات على أجهزة `IoCreateDevice` التي تم إنشاؤها بدون واصف أمان
  (يمكن الوصول إليها عالميًا) / SDDL ضعيفة `IoCreateDeviceSecure`، وفك تشفير مسارات الهدف لـ `IoCreateSymbolicLink`
* **تدقيق الصادرات**: وضع علامات على صادرات السائق التي لا تحتوي على مراجع متقاطعة داخلية (سطح هجوم محتمل)
* **تسجيل المخاطر** لرموز IOCTL التي تم فك تشفيرها لكل IOCTL (إعطاء أولوية لـ `METHOD_NEITHER` / `FILE_ANY_ACCESS`، ورفع خطورة IOCTL
  فقط للمصارف/التعليمات البرمجية الخطرة التي يمكن الوصول إليها من **معالج الحالة الخاص بها** - `MmMapIoSpace`، `memcpy`،
  `__writemsr`، إدخال/إخراج المنفذ، الوصول إلى PCI-config - بحيث لا يتم تلويث رمز غير ضار في معالج متجانس بمصارف
  شقيق خطير؛ عندما يكون الإسناد غير دقيق، يتم رفع الحد الأقصى بدلاً من فرضه على CRITICAL) وعرض جميع النتائج، حسب الخطورة، في نافذة نتائج قابلة للنقر (انقر نقرًا مزدوجًا للانتقال إلى العنوان)
* **تتبع سلاسل الاستدعاءات** من معالجات التوزيع / IOCTL إلى المصارف الخطيرة (استكشاف استدلالي، قائم على الاسم)
* تصدير النتائج كملف **JSON** قابل للقراءة آليًا وتقرير **HTML** مستقل

![](https://assets.kitploit.com/production/public/readmes/5861/811a51641acd398e4a1ac0df3ea86575be806cdbd8e85397d07c07ef3b18974c.png)

### العثور على DispatchDeviceControl

يمكن للأداة تحديد موقع وتحديد روتين `DispatchDeviceControl` تلقائيًا. تُستخدم هذه الوظيفة لتوجيه جميع
رموز `DeviceIoControl` الواردة إلى وظيفة السائق المحددة المرتبطة بهذا الرمز. تحديد هذه الوظيفة تلقائيًا
يجعل العثور على رموز `DeviceIoControl` الصالحة لكل سائق أسرع بكثير. بالإضافة إلى ذلك، عند
التحقيق في الثغرات الأمنية المحتملة في سائق بسبب تعطل، فإن معرفة موقع هذه الوظيفة يساعد في تركيز
الاهتمام على استدعاء الوظيفة المحدد المرتبط برمز `DeviceIoControl` المتسبب في التعطل.

عند نجاح التحليل، سيتم إعادة تسمية بعض الدوال الفرعية كما يلي:

- `DriverEntry`: الروتين الأول الذي يوفره السائق والذي يتم استدعاؤه بعد تحميل السائق. وهو مسؤول
  عن تهيئة السائق.
- `Real_Driver_Entry`: عادةً الوظيفة التي تم نقل التنفيذ إليها من `DriverEntry`. وهي عادةً
  حيث يتم تهيئة `DeviceName`.
- `DispatchDeviceControl`/`DispatchInternalDeviceControl`: إذا تمكنت الأداة من استعادة الوظائف في بعض
  الإزاحات المحددة، فسيتم إعادة تسمية الوظائف بالاسم المناسب.
- `Possible_DispatchDeviceControl_#`: إذا لم تتمكن الأداة من استعادة `DispatchDeviceControl`
  أو `DispatchInternalDeviceControl`، فإنها تستخدم بحثًا تجريبيًا، يتبع تدفق التنفيذ، ويتحقق
  من الحالات التي تقوم فيها الوظيفة بتحميل عناوين `IO_STACK_LOCATION` و `IRP` المعروفة؛ مما يشير
  إلى أن الوظيفة قد تكون هي DispatchDeviceControl. نظرًا لأنه يعتمد على الاستكشاف الاستدلالي، فقد يُرجع أكثر من نتيجة واحدة، وهو عرضة
  للنتائج الإيجابية الخاطئة.

![](https://assets.kitploit.com/production/public/readmes/5861/6a79ef45d8df6c23fd5b67d0584787760336450a6e4d2f1f8a930cc953f0cff0.png)

### تسمية هياكل WDM و WDF

هياكل السائق المشتركة متشابهة بين جميع سائقين `WDM`/`WDF`. الأداة قادرة على تحديد هذه الهياكل تلقائيًا،
مثل هياكل `IO_STACK_LOCATION`، `IRP`، و `DeviceObject` ويمكن أن تساعد في توفير الوقت أثناء عملية
الهندسة العكسية وتوفير سياق لمناطق السائق حيث يتم استخدام هذه الوظائف.

![](https://assets.kitploit.com/production/public/readmes/5861/58daa36949a8ecfcbb6f0237cfd524c00d2dc65ed4c107eb3e0e381abbbb532b.png)

### العثور على رموز IOCTL وفك تشفيرها

أثناء عكس هندسة السائقين، من الشائع مواجهة رموز IOCTL كجزء من التحليل. تكشف هذه الرموز، عند فك تشفيرها،
عن معلومات مفيدة وقد تركز الاهتمام على أجزاء معينة من السائق حيث تكون الثغرات الأمنية أكثر احتمالية للوجود.

بالنقر بزر الماوس الأيمن على رمز IOCTL محتمل، يظهر خيار قائمة سياق (بدلاً من ذلك باستخدام
الاختصار `Ctrl+Alt+D` عندما يكون المؤشر على السطر الذي يحتوي على رمز IOCTL مشتبه به) ويمكن استخدامه لفك
تشفير القيمة. سيؤدي ذلك إلى طباعة جدول يحتوي على جميع رموز IOCTL التي تم فك تشفيرها. من خلال النقر بزر الماوس الأيمن على رمز IOCTL مفكك التشفير، في
طريقة عرض التفكيك، من الممكن وضع علامة عليه كغير صالح؛ سيؤدي ذلك إلى ترك أي تعليق غير IOCTL سليمًا.

- تتم طباعة رموز IOCTL التي تم فك تشفيرها إلى نافذة Output وإدراجها في نافذة IOCTLs الملونة حسب الخطورة؛ بعد
  التحليل التلقائي يتم تسجيلها أيضًا في `findings.json` / `report.html`.

يقوم التحليل التلقائي أيضًا بتشغيل مسح متعدد الاستراتيجيات على وظائف المعالج المحددة لاكتشاف IOCTLs
تلقائيًا، دون الحاجة إلى وضع المؤشر يدويًا. لكل معالج، يستخدم أداة فك الترجمة Hex-Rays
(عند توفرها) لقراءة تسميات switch-case وثوابت المقارنة `==`/`!=` مباشرة من التدفق
التحكم المعاد بناؤه، مع الرجوع إلى بيانات جدول switch الخاصة بـ IDA ثم إلى مسح raw immediate-operand. مسار
أداة فك الترجمة يستعيد الرموز التي لا تظهر حرفيًا في التفكيك - على سبيل المثال، السائقون الذين قام المترجم
بإصدار معالجهم كجدول قفز (فقط قاعدة/حد الجدول يبقى كقيم فورية) أو كشجرة مقارنة بحث ثنائي
(الرموز الوسيطة تبقى فقط كفروق). على مجموعة تمثيلية، رفع هذا معدل الاسترداد
من 7/28 إلى 28/28 (HEVD) و 4/17 إلى 17/17 (ALSysIO64) بدون نتائج إيجابية خاطئة.

![](https://assets.kitploit.com/production/public/readmes/5861/2b0e646ecef812022e0bf79bd327aaa3fc63c93223620209a7ca63e247fa53b4.png)
![](https://assets.kitploit.com/production/public/readmes/5861/cc36d0572feb45c7e104f6f4f1ab1190d347b3956b0c00c509cde9562f850ef5.png)

### وضع علامات على الوظائف

يحتوي Driver Buddy Reloaded على قوائم بوظائف C/C++، وتعليمات برمجية، وواجهات برمجة تطبيقات Windows (محددة في
دليل [vulnerable_function_lists](https://github.com/voidsec/driverbuddyreloaded/blob/HEAD/DriverBuddyReloaded/vulnerable_functions_lists)) التي تكون شائعة في الثغرات الأمنية
أو يمكن أن تسهل ظروف تجاوز سعة المخزن المؤقت. يتم الإبلاغ عن جميع الحالات التي تم العثور عليها أثناء التحليل التلقائي ويمكن
المساعدة في البحث عن مسارات رمز يمكن التحكم فيها من قبل المستخدم تصل إلى وظائف حساسة.

![](https://assets.kitploit.com/production/public/readmes/5861/4bf753eb0e33c5e3260f2da9710d4d33948ebaf55eb7cf2dcb795758fcd4f527.png)

### العثور على DeviceName

تحاول الأداة تلقائيًا العثور على مسارات الجهاز المسجلة (`DeviceName`) للسائق، إذا لم يتم العثور على أي مسارات من خلال
النظر في سلاسل Unicode داخل الملف الثنائي، فيمكن للمحلل محاولة استخدام
[Madiant's FLOSS](https://github.com/mandiant/flare-floss/) يدويًا لمحاولة العثور على مسارات مخفية.

![](https://assets.kitploit.com/production/public/readmes/5861/0023b8dc5328ce292a3b35d276e48c96607dfb3fbbb852aac406382e25eeeef3.png)

### تفريغ Pooltags

أثناء التحليل التلقائي، تقوم الأداة أيضًا بتفريغ `Pooltags` المستخدمة من قبل الملف الثنائي بتنسيق يعمل
مع `pooltags.txt`. يمكن بعد ذلك نسخ ولصق المخرجات في نهاية الملف والتقاطها لاحقًا بواسطة WinDbg.

- سيتم كتابة ملف `DriverName.sys-DATE-TIME_STAMP-pooltags.txt`، الذي يحتوي على جميع Pooltags التي تم تفريغها، ضمن
  دليل قاعدة بيانات IDA.

![](https://assets.kitploit.com/production/public/readmes/5861/f4de5449cc1ddb5f762bfe28d06c05aae42a9c01220033fbcf906de0ad039132.png)

### فحوصات الثغرات الاستدلالية

تعمل وحدة `heuristics.py` بعد تتبع سلسلة الاستدعاءات وتفحص كل معالج **والوظائف التي يستدعيها بشكل متعدٍ** - لذلك يتم تحليل معالجات كل IOCTL، وليس فقط مقدم المعالج. مطابقة المُستدعَى تراعي الاستيراد (استدعاء تم استيراده `call cs:__imp_<Name>` يطابق نفس الاسم كاستدعاء محلي). تُصدر النتائج في
فئة **heuristic** (نتائج التعليمات البرمجية المميزة تستخدم فئة **opcode**):

| الاختبار | ما يتم وضع علامة عليه | درجة الخطورة |
|---|---|---|
| نسخة غير موثقة من المستخدم | `memcpy`/`RtlCopyMemory`/إلخ بدون وجود `ProbeForRead`/`ProbeForWrite`/حارس سلسلة آمنة قريب | HIGH (معالج)، MEDIUM (أخرى) |
| TOCTOU / double fetch | إعادة قراءة حقل مؤشر لوضع المستخدم في مسار تدفق تحكم واحد دون وجود `ProbeForRead` وسيط (فقط في معالجات METHOD_NEITHER، لذلك لا يتم وضع علامة على إعادة قراءة المخزن المؤقت للنواة) | MEDIUM |
| Use-after-free | إعادة استخدام مؤشر تم تحريره داخل الوظيفة (اجتياز CFG للتسجيل)، أو متغير عام تم تحريره دون تعيينه إلى null ثم إلغاء الإشارة إليه من وظيفة أخرى | HIGH |
| عدم وجود بوابة امتياز | عملية حساسة (`ZwOpenProcess`/`MmMapIoSpace`/PCI-config/إلخ) يمكن الوصول إليها من معالج بدون `SeAccessCheck`/`SeSinglePrivilegeCheck`/فحص رمز مميز في أي مكان على المسار | HIGH |
| عدم تطابق IRQL | استدعاء قابل للصفحة / `Zw*` / `MmMap*` عندما تكون دالة رفع IRQL موجودة أيضًا | MEDIUM |
| تعيين MDL غير آمن | استدعاء `MmMapLockedPages`/`MmProbeAndLockPages`/إلخ مع `UserMode` في التفكيك | HIGH، وإلا MEDIUM |
| تخصيص رصة | استدعاء `_alloca`/`_malloca`/`_chkstk` (تخصيص رصة كبير أو ديناميكي) | LOW |
| تخصيص مجموعة دون التحقق من الحجم | استدعاء `ExAllocatePool*` بدون وجود حارس عملية حسابية آمنة قريب (نمط تجاوز عدد صحيح قبل التخصيص) | HIGH |
| تعليمة مميزة | إدخال/إخراج المنفذ (`in`/`out`)، نقل سجل التحكم/التصحيح (`mov cr*`/`mov dr*`)، تحميل جدول واصف، `cli`/`sti`/`hlt` يمكن الوصول إليها من معالج (أولية BYOVD للوصول إلى الأجهزة) | CRITICAL (`out`) / HIGH (`in`) / MEDIUM |
| كتابة عشوائية (write-what-where) | تخزين عبر مؤشر مستخدم تم إلغاء الإشارة إليه مرتين `*(*p) = c`؛ يتم الإبلاغ عن نسخة محكومة `*p = *q` كدليل أضعف | HIGH / MEDIUM |
| مرجع `\Device\PhysicalMemory` | مرجع متقاطع إلى سلسلة كائن جهاز الذاكرة الفعلية (نمط BYOVD عبر `ZwOpenSection`/`ZwMapViewOfSection`) | HIGH (معالج)، MEDIUM (أخرى) |

هذه **مولدات أدلة**، وليست ثغرات أمنية مؤكدة. تعامل مع نتائج HIGH/CRITICAL كنقاط بداية للمراجعة اليدوية.

## أعلام الميزات

يتم التحكم في جميع مراحل التحليل الاختيارية بواسطة `DriverBuddyReloaded/config.py`. قم بتحرير فئة `Feature` لتمكينها أو تعطيلها:

| العلم | الافتراضي | الوصف |
|---|---|---|
| `IOCTL_SCAN` | `True` | اكتشاف وفك تشفير IOCTLs (مسح المعالج + بديل `IoControlCode`) |
| `IOCTL_DECOMPILER` | `True` | استخدام شجرة ctree الخاصة بـ Hex-Rays في مسح المعالج (يستعيد رموز jump-table / binary-search) |
| `HEURISTICS` | `True` | فحوصات الثغرات الاستدلالية (انظر الجدول أعلاه) |
| `TOCTOU_CHECK` | `True` | استكشاف استدلالي لـ double-fetch / TOCTOU |
| `UAF_DETECT` | `True` | استكشاف استدلالي لـ use-after-free (اجتياز سجل داخل الوظيفة + متغير عام عبر الوظائف) |
| `ACL_AUDIT` | `True` | وضع علامات على `IoCreateDevice` القابل للوصول عالميًا / SDDL ضعيفة `IoCreateDeviceSecure` |
| `SYMLINK_TRACK` | `True` | فك تشفير مسارات الهدف لـ `IoCreateSymbolicLink` |
| `CALLCHAIN` | `True` | تتبع سلسلة استدعاءات BFS من المعالجات إلى المصارف الخطيرة |
| `EXPORTS_AUDIT` | `True` | وضع علامات على صادرات السائق التي لا تحتوي على مراجع متقاطعة داخلية |
| `POOLTAG_FALLBACK` | `True` | ماسح pooltag منتشر بالتسجيل (يُستخدم عندما لا يجد المسح القائم على الاستيراد شيئًا) |
| `IRP_MJ_ENUM` | `True` | إنشاء تعداد IDA لـ `IRP_MJ_FUNCTION` وتطبيقه على فتحات `MajorFunction` (WDM فقط) |
| `RISK_SCORING` | `True` | تسجيل مخاطر IOCTL (أوزان METHOD/ACCESS + رفع المصارف لكل معالج) |
| `RESULTS_WINDOW` | `True` | إظهار نافذة نتائج Driver Buddy Reloaded بعد التحليل |
| `JSON_EXPORT` | `True` | كتابة `findings.json` |
| `HTML_REPORT` | `True` | كتابة `report.html` |
| `SEGMENT_OPCODE_SCAN` | `False` | مسح تعليمات برمجية خطي على مستوى القطعة (مزعج، معطل افتراضيًا) |

## الاختبار

ثلاث طبقات، من السريع إلى الشامل:

- **اختبار انحدار Python خالص** (لا يتطلب IDA) - يغطي جميع المنطق الذي لا يلمس قاعدة البيانات الحية:  ```
  python tests/test_dbr.py
  DBR_SDK=900 python tests/test_dbr.py   # simulate the IDA 9.0 import paths