
منضدة عمل مكتبية لاختبار التشويش (Fuzzing) بإطار AFL++، ومحاكاة QEMU عبر البنى المختلفة، وتطوير أدوات الربط (harnesses)، وتحليل Ghidra بدون واجهة رسومية، ومولّدات التحوير المخصصة، ومقارنة التصحيحات لتطوير الاستغلالات.
إطار روج هو منصة عمل مكتبية لـ AFL++، والفحص عبر البنى باستخدام محاكي QEMU، وتطوير قوالب الاختبار (harnesses)، وتحليل Ghidra الرأسي الخفيف بدون واجهة رسومية، ومحوّرات مخصصة، ومقارنة التصحيحات. صُمم عمدًا ليكون منصة عمل قابلة للتدقيق وليس غلافًا يعتمد على الأزرار فقط: كل أمر AFL++ يُولَّد يكون مرئيًا قبل تنفيذه، وقوالب الاختبار المولَّدة هي ملفات مصدرية عادية يمكن للباحث تعديلها. من المفترض أن يكون "BurpSuite لمطوري استغلال الثغرات".
يستهدف إطار روج حاليًا لينكس وPython 3.11+ مع PyQt6.
على نظام Kali Linux، يُعدّ المثبّت بيئة Python، ويستنسخ فرع AFL++ الرسمي stable ويبني توزيعه الكامل مع خلفية QEMU المفعلة بالأدوات، ثم يثبّت Ghidra الرأسي، وGDB الأصلي/متعدد البنى، وخادم GDB، ومحاكاة QEMU للمستخدم/النظام، وأدوات المترجم وتبعيات البناء، ومشغّل المستخدم، وإضافات دائمة إلى PATH في الصدفة. يتم تنزيل AFL++ إلى الدليل المحلي المتجاهَل AFLplusplus/ ولا يتم توزيعه كجزء من إطار روج:
chmod +x install.sh
./install.sh
rogue-framework
قم أيضًا بتثبيت المترجمات المتقاطعة الشائعة وبيئاتها الجذرية للأنظمة الضيفة (هذا تنزيل أكبر بكثير) باستخدام:
./install.sh --with-cross-toolchains
المثبّت ذو خاصية عدم التكرار (idempotent). استخدم ./install.sh --check لفحص تثبيت موجود أو ./install.sh --rebuild-afl لفرض إعادة بناء AFL++/QEMU.
استخدم ./install.sh --update-afl للتقديم السريع الصريح للنسخة المستنسخة إلى أحدث مراجعة مستقرة رسمية.
شغّله كمستخدم سطح المكتب؛ فهو يطلب sudo فقط لحزم apt. لا يمكن لـ PATH المكتوب حديثًا تغيير الصدفة الأم التي تعمل بالفعل، لذا إما افتح طرفية جديدة، أو حمّل ~/.zshrc/~/.bashrc، أو شغّل Rogue عبر المسار المطلق ~/.local/bin/rogue-framework الذي يطبعه المثبّت.
يظل التشغيل اليدوي من مجلد الاستنساخ متاحًا:
python3 run.py
لبيئة قابلة للتحرير:
python3 -m pip install -e .
rogue-framework
الملفات الثنائية الديناميكية عبر البنى تحتاج إلى بيئة جذرية ضيفة مطابقة يتم تحديدها عبر QEMU_LD_PREFIX؛ وهذا بطبيعته خاص بالهدف/التوزيعة. يمكن تجاوز مسار analyzeHeadless الخاص بـ Ghidra من خلال Tools ← External tools.
مشروع .rgp هو JSON قابل للقراءة ومُدار بالإصدارات يحتوي على تعريف المشروع المحمول. أما الأصول الكبيرة والقابلة للتغيير فتُخزَّن في مساحة العمل المصاحبة المُدارة:
example.rgp
example.rgp-work/
workspace.json
project.sqlite3
corpus/
output/
harnesses/
mutators/
analysis/
logs/
runs/
staging/
recovery/
backups/
objects/sha256/
هذا التقسيم يُبقي ملفات المشروع قابلة للمراجعة ويتجنب تضمين مجموعات الأعطال (crash corpora) أو النتائج أو فهارس التحليل أو حالة Ghidra داخل JSON. يرتبط workspace.json بالبيان (manifest) مع هوية مساحة العمل الصحيحة، بينما يخزن project.sqlite3 الحالة التشغيلية/المفهرسة. تستخدم المراجع المُدارة workspace://؛ بينما تستخدم الموارد الخارجية صراحةً external://. يتم تخزين مسارات الأدوات المحلية للجهاز وحالة الواجهة خارج المشروع المحمول.
ينشئ "حفظ باسم" (Save As) نسخة مستقلة بهويات مشروع ومساحة عمل جديدة. يقوم Rogue بتهيئة الوجهة والتحقق منها قبل التبديل إلى المستند المفتوح، لذا فإن فشل الاستنساخ يُبقي المشروع المصدر دون تغيير. تستخدم عمليات الحفظ الأساسية ترخيص كاتب استشاري (advisory writer lease) بالإضافة إلى فحوصات تعارض المراجعة/SHA-256، وتحتفظ بالبيانات السابقة السليمة، وتنشر الملفات ذريًا مع fsync، وتحافظ على لقطات استرداد من الأعطال تتضمن مسودات المحرر النشطة. كما تُنشر قوالب الاختبار المولَّدة والمحوّرات وGhidra JSON ونتائج مقارنة التصحيحات والنتائج المصغَّرة بشكل تعاملي بحيث لا يحذف الاستبدال الفاشل الأصول الصالحة السابقة.
.fuzz القديمةيمكن لـ Rogue استيراد بيانات .fuzz القديمة من المخططات 0-2 مع مرافقاتها .fuzz-work. المصدر القديم ليس أبدًا الوجهة الأساسية: أول حفظ يرقّيه إلى مشروع .rgp مجاور ومساحة عمل .rgp-work مع الإبقاء على الملفات القديمة الأصلية. تستخدم المشاريع الجديدة ووجهات "حفظ باسم" دائمًا .rgp.