هذا هدف محلي بسيط يمكن لـ AFL++ التعامل معه بشكل مثالي، وهو معطى فقط كمثال سريع. تم تصميم Litefuzz للقيام بالمزيد في مجال اختبار الشبكات وواجهات المستخدم الرسومية، وهو ما ستراه بمجرد التعمق.

## لماذا

نعم، أداة اختبار أخرى لا تتبع الاتجاهات والأعراف الحالية بشكل جيد. تم إجراء بعض المقايضات لمعالجة متطلبات معينة. هذه المتطلبات هي أداة اختبار تعمل افتراضيًا على منصات متعددة، وتختبر الأهداف المحلية والشبكية، وسهلة الاستخدام للغاية. لا أحاول إقناع أي شخص بأي شيء، لكن دعنا نقدم بعض السياق. تتطلب بعض الأهداف جهدًا كبيرًا لدمج أدوات الاختبار مثل AFL في سلسلة البناء. هذه ليست مشكلة لأن هذه الأداة لا تتطلب إضافة تعليمات، مما يضحي بالتغطية الدقيقة المكتسبة من الإضافة مقابل السهولة وقابلية النقل. كما أن AFL لا يدعم اختبار الشبكات مباشرة، وعلى الرغم من وجود مشاريع مبنية عليه تفعل ذلك، إلا أنها بعيدة كل البعد عن سهولة الاستخدام وتتطلب عادةً المزيد من تعديلات الكود وأدوات التهيئة لتعمل (قصة مماثلة مع [Libfuzzer](https://llvm.org/docs/LibFuzzer.html)).

لا تقوم الأداة بالاختبار المتوازي، ولا تدعم أي شيء مثل تحسينات السرعة الهائلة التي يوفرها [الوضع المستمر](https://lcamtuf.blogspot.com/2015/06/new-in-afl-persistent-mode.html)، لذا لا يمكنها التوسع بالقرب من أدوات الاختبار التي تمتلك مثل هذه الإمكانيات. مرة أخرى، هذه ليست أداة اختبار من أحدث التقنيات. لكنها لا تتطلب كود مصدري، أو إعداد بناء بشكل صحيح، أو ميزات معينة لنظام التشغيل. يمكنها حتى اختبار بعض واجهات المستخدم الرسومية للعملاء الشبكيين والتطبيقات التفاعلية. تعتمد على ما هو متاح في البيئة بطرق عديدة، والعديد من الميزات مثل المحولات والتصغير تمت كتابتها من الصفر.

صُممت الأداة "لتنجح فورًا"، وبُذل جهد في أتمتة الإعداد والتركيب للتبعيات القليلة التي تحتاجها. كُتبت هذه الأداة لخدمة غرض، لتوفير قيمة في العديد من سيناريوهات وبيئات الهدف المختلفة، والأهم من ذلك، ما يجب أن تُحكم به جميع أدوات الاختبار في النهاية: القدرة على العثور على الأخطاء. وهي **تجد بالفعل** [أخطاء](https://github.com/sec-tools/beta/blob/main/README.md#trophies). لا تفترض وجود كود مصدري للهدف، لذا يمكنها تغطية البرامج مغلقة المصدر بشكل جيد إلى حد ما. يمكن تشغيلها كجزء من الأتمتة مع تعديلات طفيفة، لكنها موجهة نحو كونها ممتعة الاستخدام لباحثي الثغرات. ومع ذلك، من الأفضل التفكير فيها كمشروع بحث وتطوير وليس كمنتج متكامل. أيضًا، لا يوجد إعداد معقد يكون معطلًا قليلاً خارج الصندوق أو يحتاج إلى مزيد من العمل لتشغيله على أنظمة التشغيل الحديثة.

تم اختبارها وتعمل على Ubuntu Linux وMac وWindows، وتأتي مع نصوص برمجية وظيفية بالكامل تفعل كل شيء تقريبًا من أجلك لإعداد بيئة جاهزة للاختبار.

**بمجرد اكتمال برنامج الإعداد، يستغرق الأمر بضع دقائق فقط لبدء اختبار العديد من الأهداف المختلفة.**

## كيف يعمل

**يدعم Litefuzz ثلاثة أوضاع مختلفة: محلي، عميل، وخادم.**

المحلي يعني استهداف البرامج الثنائية المحلية، والتي يتم تشغيلها على Linux/Mac عبر عملية فرعية مع دعم تلقائي لـ GDB و LLDB للفرز عند الأعطال على التوالي، وعبر [WinAppDbg](https://github.com/MarioVilas/winappdbg) على Windows. تُكتب الأعطال إلى دليل أعطال محلي وتُصنف حسب نوع الخطأ، مثل أخطاء القراءة/الكتابة AV أو SIGABRT/SIGSEGV مع تجزئات الملفات. يتم فرز جميع الأعطال الفريدة أثناء الاختبار، ويتم أيضًا التقاط هذه البيانات مع مخرجات الهدف (حسب التوفر) ووضعها كقطع أثرية في نفس الدليل. من الممكن أيضًا إعادة تشغيل الأعطال باستخدام `--replay` مع توفير الملف المتسبب في العطل. في وضع العميل `المحلي`، يجب أن يحتوي دليل الإدخال على تحية خادم، أو رد، أو أي بيانات يتوقعها العميل عند الاتصال بالخادم.

حتى الآن، تم تنفيذ "طلقة" واحدة فقط لاختبار الشبكات دون دعم جلسات معقدة. يتم تشغيل العميل عبر سطر الأوامر وتصحيحه بنفس الطريقة المتبعة عند اختبار الملفات. يتم إعداد مستمع لدعم هذا السيناريو، نعم إنها بطيئة وعمل يدوي على حافة القبول لكنها تعمل. إذا تم اكتشاف عطل، يتم إعادة تشغيله في gdb للحصول على تفاصيل الفرز. في وضع العميل `عن بُعد`، يعمل هذا بنفس الطريقة باستثناء عدم وجود تصحيح/فرز محلي للعطل. في وضع الخادم *المحلي*، يشبه وضع العميل المحلي، وبالنسبة لوضع الخادم `عن بُعد`، يتصل فقط بهدف محدد ويرسل بيانات عميل متحولة يحددها المستخدم كمدخلات، ولكن يتم توفير فرز بسيط فقط مثل "هل يمكننا الاتصال مرة أخرى، إذا لم يكن الأمر كذلك فمن المحتمل أنه تعطل على الأخير".

هناك عدة وظائف تحوير مكتوبة من الصفر تقوم في الغالب بتحويرات عشوائية مع اختيار عشوائي للمدخلات المحددة بواسطة العلم `-i`. لاختبار الملفات، ما عليك سوى تحديد الوضع المحلي وتمرير سطر الأوامر الهدف مع FUZZ للإشارة إلى مكان توقع التطبيق لاسم الملف لتحليله، على سبيل المثال: `tcpdump -r FUZZ` مع دليل إدخال من "الملفات الجيدة" لتحويرها. لاختبار عميل الشبكة، يشبه الاختبار المحلي، ولكن أيضًا قم بتوفير تفاصيل الاتصال عبر `-a`. وإذا كنت ترغب في اختبار الخوادم، فاستخدم وضع الخادم وقدم `protocol://address:port` تمامًا كما هو الحال مع العملاء.

تختبر الأداة بنفس سرعة قدرة الهدف على استهلاك البيانات والخروج، كما هو الحال في معظم تطبيقات CLI أو للمدة التي تحددها قبل انتهاء مهلة التنفيذ المحلي أو اتصال الشبكة، والتي يمكن أن تكون أبطأ بكثير. لا توجد حيل تنفيذية متقدمة أو حيل نواة هنا. ولكن بالطبع إذا كتبت أداة تهيئة تحلل الإدخال وتخرج بسرعة، وتغطي جزءًا محددًا من الهدف، فهذا يساعد أيضًا. لكن في هذه المرحلة، إذا تمكنت من الاقتراب من الهدف بهذا القدر، فمن المحتمل أنك أفضل حالًا باستخدام [الوضع المستمر](https://lcamtuf.blogspot.com/2015/06/new-in-afl-persistent-mode.html) أو ميزات مماثلة تقدمها أدوات الاختبار الأخرى.

باختصار...

### ما تفعله
- تعمل على لينكس، ويندوز وماك وتدعم py2/py3
- تختبر برامج CLI/GUI التي تقرأ من الملفات/المدخل القياسي
- تختبر العملاء والخوادم الشبكيين، مفتوحة المصدر أو مغلقة، متاحة للتصحيح محليًا أو عن بُعد
- الاختلافات، التصغير، إعادة التشغيل، الفرز، الفرز التلقائي للأعطال
- أشياء متنوعة مثل دعم TLS، اختبار برامج Golang الثنائية وبعض الإضافات لماك
- تحوير المدخلات باستخدام محولات مدمجة متنوعة + pyradamsa (لينكس)

### ما لا تفعله
- الإضافة الأصلية
- التوسع مع الوظائف المتزامنة
- اختبار الجلسات المعقدة
- مراقبة العميل والخادم عن بُعد (فحوصات أساسية فقط مثل الاتصال)

## الدعم

تم اختباره بشكل أساسي على **Ubuntu Linux 20.04** (تم اختبار 22.04 و 21.04 بشكل خفيف)، **Windows 10** و **Mac OS 11** (تم اختبار 12 بشكل خفيف). قد تعمل الأداة ونصوص الإعداد على إصدارات أحدث أو أقدم قليلاً من أنظمة التشغيل هذه أيضًا، لكن غالبية البحث والاختبار والتطوير تمت في هذه البيئات. يتم دعم Python3 وبُذل جهد لجعل الكود متوافقًا مع Python2 أيضًا لأنه ضروري للاختبار على Windows عبر [WinAppDbg](https://github.com/MarioVilas/winappdbg).

تم إجراء اختبار النظام الأساسي بشكل أساسي على أجهزة Intel، لكن الأمور تبدو أنها تعمل بشكل جيد أيضًا على منصة Apple M1 (الاستثناءات الملحوظة هي أن البرنامج الإضافي exploitable لـ GDB على Linux ربما غير مدعوم، وكذلك Pyradamsa). توجد أيضًا نصوص إعداد في setup/ لأتمتة معظم أو كل المهام وتركيب التبعيات. يمكنها بشكل عام اختبار البرامج الثنائية الأصلية على كل نظام أساسي، والتي غالبًا ما تُكتب بلغة C/C++، ولكنها أيضًا تلتقط الأعطال لبرامج Golang الثنائية (تجريبي).

### إصدارات بايثون

Python3 مدعومة على لينكس وماك بينما Python2 مطلوبة على ويندوز.

لماذا Py3 على لينكس وماك؟ Pyautogui، Pyradamsa (لينكس فقط)، دعم أفضل للمقابس على ماك.

لماذا Py2 على ويندوز؟ Winappdbg يتطلب Py2.

### لينكس

GDB للتصحيح و [exploitable](https://github.com/jfoote/exploitable) لفرز الأعطال. إذا كان مفتوح المصدر، يمكنك بناء الهدف وإضافته باستخدام [sanitizers](https://fuzzing-project.org/tutorial2.html) وما شابه، وإلا يوجد بعض [مصححات الذاكرة](https://en.wikibooks.org/wiki/Linux_Applications_Debugging_Techniques/Heap_corruption) التي يمكننا تحميلها في وقت التشغيل.

تمت أتمتة هذا التثبيت مع تبعيات بايثون وأشياء مفيدة أخرى باستخدام [setup/linux.sh](https://github.com/sec-tools/litefuzz/blob/HEAD/setup/linux.sh). نظام التشغيل الموصى به هو Ubuntu 20.04 حيث تمت غالبية الاختبارات.

### ماك

بدلاً من gdb، نستخدم lldb للتصحيح على OS X لأنه مضمن مع أدوات سطر الأوامر XCode. كونك مسؤولًا أو في مجموعة المطورين يجب أن يسمح لك باستخدام lldb، لكن هذا السلوك قد يختلف عبر البيئات والإصدارات وقد تحتاج إلى تشغيله بصلاحيات sudo إذا فشلت كل المحاولات الأخرى.

الشيء الوحيد الذي ستحتاج إلى القيام به يدويًا هو إيقاف تشغيل SIP (في وضع الاسترداد، عبر cmd+R أو استخدم اختراقات vmware fusion). وإلا، سيفشل الفرز التلقائي عند الاختبار على نظام Tim Apple.

تمت أتمتة معظم الإعداد باستخدام البرنامج النصي [setup/mac.sh](https://github.com/sec-tools/litefuzz/blob/HEAD/setup/mac.sh)، لذا يمكنك تشغيله للحصول على بداية سريعة.

### ويندوز

يستخدم [WinAppDbg](https://github.com/MarioVilas/winappdbg) للتصحيح على ويندوز مع تحذير صغير بأن اختبار المدخل القياسي غير مدعوم.

مثل الإعدادات الآلية لأنظمة التشغيل الأخرى، يساعد chocolatey في أتمتة تثبيت الحزم على ويندوز. قم بتشغيل [setup/windows.bat](https://github.com/sec-tools/litefuzz/blob/HEAD/setup/windows.bat) في الدليل الجذر لـ litefuzz كمسؤول لأتمتة التثبيتات. سيقوم بتثبيت أدوات التصحيح والتبعيات الأخرى لجعل الأمور تعمل بسلاسة.

### الأهداف

هذه قائمة بأنواع الأهداف التي تم اختبارها ومدعومة بشكل عام.

* تطبيقات CLI/GUI محلية تحلل تنسيقات الملفات أو المدخل القياسي
  - دعم التصحيح

* عميل شبكة CLI/GUI محلي يحلل ردود الخادم
  - دعم التصحيح لـ CLI
  - دعم محدود للتصحيح لـ GUI

* خادم شبكة CLI محلي يحلل طلبات العميل
  - دعم التصحيح (تحذير: يجب أن يكون قادرًا على العمل كبرنامج مستقل، وإلا يمكن معاملته كـ *عن بُعد*)

* خادم شبكة GUI محلي يحلل طلبات العميل
  - مدعوم نظريًا، غير مختبر

* عميل شبكة CLI/GUI عن بُعد يحلل ردود الخادم
  - لا يوجد دعم تصحيح

* خادم شبكة CLI/GUI عن بُعد يحلل طلبات العميل
  - لا يوجد دعم تصحيح
  - استثناء على ماك باستخدام ميزات `attach` أو `reportcrash`

مرة أخرى، يمكن للأداة العمل على ودعم التطبيقات المحلية، والعملاء، والخوادم على لينكس، ماك، وويندوز، وبالطبع يمكنها اختبار الأشياء عن بُعد بغض النظر عن نظام الهدف الأساسي.

### الفرز

* تطبيقات CLI/GUI محلية تحلل تنسيقات الملفات أو المدخل القياسي
  - تشغيل التطبيق، التقاط الإشارات، إعادة الإنتاج بتشغيله مرة أخرى داخل مصحح مع المسبب لعطل

* عميل شبكة CLI/GUI محلي يحلل ردود الخادم
  - تشغيل التطبيق، التقاط الإشارات، إعادة الإنتاج بتشغيله مرة أخرى داخل مصحح مع المسبب لعطل

* خادم شبكة CLI/GUI محلي يحلل طلبات العميل
  - تشغيل التطبيق في المصحح، التقاط الإشارات، إعادة الإنتاج بتشغيله مرة أخرى داخل مصحح مع المسبب لعطل

* عميل شبكة CLI/GUI عن بُعد يحلل ردود الخادم
  - لا رؤية، جمع الأعطال من الجهة البعيدة
  - يمكن كتابة نصوص داعمة يدويًا للمساعدة في الفرز

* خادم شبكة CLI/GUI عن بُعد يحلل طلبات العميل
  - لا رؤية، جمع الأعطال من الجهة البعيدة
  - يمكن كتابة نصوص داعمة يدويًا للمساعدة في الفرز
  - استثناء على ماك هما خيارا `attach` و `reportcrash`، والتي يمكن استخدامها لتمكين بعض إمكانيات الفرز

## البدء

تمت أتمتة معظم الإعداد عبر المنصات باستخدام البرامج النصية في دليل [setup](https://github.com/sec-tools/litefuzz/blob/main/README.md#setup).

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

انظر [INSTALL.md](https://github.com/sec-tools/litefuzz/blob/main/INSTALL.md) للتفاصيل.

**بعد التثبيت، ارجع إلى مثال اختبار latex2rtf في القسم الأولي للتشغيل السريع أو تعمق في جميع خيارات سطر الأوامر والأمثلة الإضافية المفصلة في هذا README.**

### دوكر

يمكنك تشغيل litefuzz باستخدام Docker مع `Dockerfile` دون تثبيت التبعيات محليًا. هذا مفيد بشكل خاص للاختبار السريع أو إذا كنت ترغب في تجنب تثبيت التبعيات على نظامك.

يعمل ملف Dockerfile على كلا النحوين:
- **من داخل المستودع** - يستخدم الملفات المحلية (أسرع، يشمل التغييرات المحلية)
- **مستقل** - يمكن بناؤه من أي دليل (يستنسخ من GitHub)```bash
# Build the Docker image (from any directory with Dockerfile)
docker build -t litefuzz:latest .

# Run litefuzz
docker run --rm litefuzz:latest python3 litefuzz.py --help

سوف يقوم هذا بما يلي:
- فحص latex2rtf باستخدام 1000 تكرار
- استخدام تصحيح أخطاء الكومة (علامة `-z`)
- حفظ حالات التعطل إلى مجلد `./crashes` على جهازك المضيف
- استخدام ملفات الإدخال المضمنة من المستودع في `/litefuzz/input/tex`

إذا كنت ترغب في استخدام ملفات الإدخال الخاصة بك من الجهاز المضيف:```bash
# Create input directory with your test files
mkdir -p input/tex crashes
# Add your test files to input/tex/
cp your-test.tex input/tex/

# Run fuzzing with your input files
docker run --rm \
  -v $(pwd)/input:/litefuzz/input \
  -v $(pwd)/crashes:/tmp/crashes \
  litefuzz:latest \
  python3 litefuzz.py -l -c "latex2rtf FUZZ" -i /litefuzz/input/tex -o /tmp/crashes -n 1000 -z

سيقوم هذا بتشغيل pytest لـ `test_litefuzz.py` في الدليل الرئيسي وسيعرض نتائج PASS/FAIL بمجرد انتهاء تشغيل الاختبار.

#### اختبارات تعطل التطبيقات
بعض الأمثلة على التطبيقات المعطلة لاختبار قدرات التعطل والتصنيف على المنصات المختلفة موجودة في مجلد `test`.

- (أ) إلغاء مرجع مؤشر فارغ
- (ب) القسمة على صفر
- (ج) تجاوز سعة الكومة
- (د-واجهة رسومية) خلل في سلسلة التنسيق في تطبيق واجهة رسومية
- (هـ) تجاوز سعة المخزن المؤقت في العميل
- (و) تجاوز سعة المخزن المؤقت في الخادم

يتم بناؤها تلقائيًا أثناء الإعداد ويمكنك تشغيلها من سطر الأوامر، أو في مصحح الأخطاء، أو استخدامها لاختبار الاستهداف بالتعمية.

**إذا كنت تعمل على سطر أوامر Windows، تحقق من `عارض الأحداث -> سجلات Windows -> التطبيق` لرؤية الأعطال.**

## الخيارات
هناك الكثير من الخيارات والميزات المختلفة للاستفادة من سيناريوهات الهدف المختلفة. فيما يلي شرح موجز وبعض الأمثلة للمساعدة في فهم كيفية استخدامها.

### دليل الأعطال
`-o` يتيح لك تحديد دليل للأعطال غير الافتراضي، وهو مجلد crashes/ في المسار المحلي. يمكن استخدام هذا لإدارة مجلدات الأعطال لعدة عمليات تعمية متزامنة لتطبيقات مختلفة في نفس الوقت.

### وضع العزل
`-u` يعزل التطبيق الهدف عن عملية التعمية العادية، مثل تنفيذ الأوامر أو إرسال الحزم مرارًا وتكرارًا والتحقق من الأعطال. بدلاً من ذلك، تم تصميم هذا الوضع لتطبيقات العميل التفاعلية، مثل Postman حيث يمكنك كتابة نصوص برمجية داخل التطبيق لتكرار الاتصالات لتعمية العميل. يتم تشغيل الهدف داخل مصحح الأخطاء، ويتم إيقاف المُعمّي مؤقتًا لإعطاء المستخدم وقتًا للنقر على بعض الأزرار أو ضبط إعدادات الهدف لجعله يعمل تلقائيًا، ثم يستأنف المستخدم وتبدأ تعمية عملاء الشبكة التفاعلية.

`litefuzz -lk -c "/snap/postman/140/usr/share/Postman/_Postman" -i input/http_responses -a tcp://localhost:8080 -u -n 100000 -z`

يمكن استخدام وضع العزل مع التحديث للعملاء التفاعليين، على سبيل المثال تشغيل FileZilla في مصحح أخطاء، مع الضغط المستمر على F5 لإعادة الاتصال بالخادم لكل تكرار جديد. أيضًا، يتم تشغيل خوادم CLI/GUI المحلية مرة واحدة فقط داخل مصحح أخطاء لجعل العملية أكثر كفاءة.

يسمح لك `--key` أيضًا بإرسال مفاتيح أثناء تعمية الأهداف التفاعلية، مثل تعمية تحليل FileZilla لاستجابات خادم FTP عن طريق إرسال "تحديث الاتصال" باستخدام F5.

`litefuzz -lk -c "filezilla" -a tcp://localhost:2121 -i input/ftp/filezilla -u -pp --key "F5" -n 100 -z glibc`

ملاحظة: تم اختبار وضع العزل على Linux فقط وغير مدعوم على Windows.

### المهلة
`-x secs` يتيح لك تحديد مهلة. عمليًا، هذا أقرب إلى "مدة تقريبية بين التكرارات" لأهداف CLI ومهلة فعلية لواجهات المستخدم الرسومية.

### المُغيرات
`--mutator N` يحدد أي مُغير (mutator) يجب استخدامه للتعمية. إذا لم يتم تقديم الخيار، يتم اختيار عشوائي من قائمة المُغيرات المتاحة لكل تكرار تعمية.

تمت كتابة هذه المُغيرات من الصفر (باستثناء Radamsa بالطبع). وعلى الرغم من اختبارها على نطاق واسع وأدائها الجيد خلال ملايين التكرارات، فقد تحتوي على أخطاء دقيقة من وقت لآخر، لكن هذا لا يؤثر عمومًا على الوظيفة.```
FLIP_MUTATOR = 1
HIGHLOW_MUTATOR = 2
INSERT_MUTATOR = 3
REMOVE_MUTATOR = 4
CARVE_MUTATOR = 5
OVERWRITE_MUTATOR = 6
RADAMSA_MUTATOR = 7

### pause
اضغط على ctrl+c لإيقاف عملية الفازينغ مؤقتاً. إذا أردت الاستئناف، اختر `y` أو `n` للإيقاف. تعمل هذه الميزة بشكل جيد عبر المنصات، لكنها قد تكون أقل موثوقية عند فازينغ تطبيقات الواجهة الرسومية.

### إعادة استخدام الأعطال للبحث عن متغيرات

`-e` تفعّل وضع إعادة الاستخدام. يعني ذلك أنه إذا تم العثور على أي أعطال أثناء عملية الفازينغ، فسيتم استخدامها كمدخلات لجولة ثانية من الفازينغ يمكن أن تساعد في استخراج المزيد من الأخطاء. ادمج مع `-z` للحصول على أخطاء `-ez`! دا-دوف.

المثال التالي يقوم بفازينغ antiword مع 100000 تكرار ثم يبدأ تشغيلاً آخر بنفس عدد التكرارات والخيارات لإعادة استخدام الأعطال كمدخلات لمحاولة استخراج المزيد من الأخطاء.

`litefuzz -l -c "antiword FUZZ" -i docs -n 100000 -ez`

(أو يمكن نسخ الأعطال يدوياً إلى دليل إدخال للتحكم المباشر في التكرارات لتشغيل إعادة الاستخدام)

`litefuzz -l -c "antiword FUZZ" -i docs-crashes -n 500000 -z`

ملاحظة: هذا الوضع مدعوم للتطبيقات المحلية فقط.

### مساعدات تصحيح أخطاء الذاكرة
`-z` تفعّل Electric Fence (أو glib malloc debugging كبديل) على لينكس، وGuard Malloc على ماك، وPageHeap على ويندوز. أيضاً، يمكن استخدام `-zz` لتعطيل PageHeap بعد تفعيله لتطبيق ما. إذا أردت فقط تشغيله/إيقافه دون بدء الفازر، فقط اترك علامة `-i`. أثناء إعداد ويندوز، يتم تثبيت [gsudo](https://github.com/gerardog/gsudo) ويمكن استخدامه لتشغيل أوامر مرتفعة في سطر الأوامر، مثل تشغيل PageHeap للأهداف.

`sudo litefuzz -l -c "notepad FUZZ" -i texts/files -z`

`sudo litefuzz -l -c "notepad FUZZ" -zz`

على لينكس، يمكن اختيار مساعدات محددة. على سبيل المثال، بدلاً من استخدام glib malloc كبديل فقط، يمكن اختياره.

`litefuzz -l -c "geany FUZZ" -i texts/codes -z glibc`

مصحح أخطاء الذاكرة الافتراضي Electric Fence رائع، لكنه لا يعمل مع جميع الأهداف. يمكنك اختبار الهدف باستخدام EF وإذا تعطل، فاختر المساعد glibc بدلاً من ذلك.

### التحقق من مخرجات الهدف المباشرة
إذا كنت تقوم بفازينغ تطبيقات محلية على لينكس أو ماك، يمكنك استخدام `cat /tmp/litefuzz/RUN_ID/fuzz.out` للتحقق من آخر stdout من الهدف. يظهر `RUN_ID` في منطقة معلومات STATS عند بدء الفازينغ. في حالة حدوث عطل، يتم أيضاً التقاط stdout في دليل الأعطال كملف `.out`. كما يتم توجيه stdout/stderr العام إلى `/tmp/litefuzz/out` لأغراض التصحيح لجميع أهداف الفازينغ باستثناء وضعي insulated أو local server حيث يذهب مخرجات المصحح إلى `/tmp/litefuzz/RUN_ID/out`.

Winappdbg لا يدعم بشكل أصلي التقاط stdout للأهداف (على حد علمي)، لذا فإن هذا الأثر غير متوفر على ويندوز.

### أوضاع العميل والخادم
إذا كان يمكن تشغيل الخادم محلياً ببساطة عن طريق تنفيذ الملف الثنائي (مع أو بدون بعض العلامات والإعدادات)، فيمكن تمرير سطر الأوامر الخاص به مع `-c` وسيتم بدؤه وفازنغه وإنهاؤه مع تنفيذ جديد لكل تكرار. الفكرة هنا هي مقايضة السرعة بالقدرة على تجنب تلك الأخطاء المزعجة التي تظهر فقط بعد أن تكون ذاكرة الهدف في "حالة معينة"، مما قد يؤدي إلى نتائج إيجابية خاطئة. نفس الأمر ينطبق على فازينغ عملاء الشبكة محلياً. حتى أنه يدعم اتصالات TLS، ويولد الشهادات لك أثناء التنقل (السماح للمستخدم بتوفير شهادة عميل عند فازينغ خادم يتطلبها، وفازينغ الشهادة بحد ذاته فكرة أخرى هنا).

لا يوفر Litefuzz دعم التصحيح عند فازينغ العملاء والخوادم البعيدة، لذا فإن الإعداد على الطرف البعيد متروك للمستخدم. بالنسبة للخوادم، نتحقق ببساطة مما إذا توقف الخادم عن الاستجابة ونسجل الحمولة السابقة كمسببة للعطل. هذا يعمل بشكل جيد مع اتصالات TCP، لكننا لا نملك هذه الرفاهية لخدمات UDP، لذا فإن مراقبة الخادم البعيد متروكة إما لميزة ReportCrash (المتاحة على ماك)، أو تشغيل الهدف في مصحح (عبر وضع local server أو يدوياً)، أو كتابة نصوص داعمة مخصصة. أيضاً، قد تعيد بعض الخوادم تشغيل نفسها تلقائياً أو تتعافى بعد التعطل، لكن قد تكون هناك علامات على ذلك في السجلات أو أثر آخر على نظام الملفات يمكن تحليله بواسطة نصوص داعمة مكتوبة لهدف معين.

### أمثلة الشبكة المحلية

`litefuzz -lk -c "wget http://localhost:8080" -a tcp://localhost:8080 -i input/http -z`

`litefuzz -lk -c "curl -k https://localhost:8080" -a tcp://localhost:8080 -i input/http -z`

`litefuzz -lk -c "curl -k https://localhost:8080" -a tcp://localhost:8080 -i input/http -o crashes/curl --tls -n 100000 -z`

(افتح Wireshark والتقط الرد من 
d، انقر بزر الماوس الأيمن على Simple Network Management Protocol -> Export Packet Bytes -> resp.bin)

`litefuzz -lk -c "snmpwalk -v 2c -c public localhost:1616 1.3.6.1.2.1.1.1" -a udp://localhost:1616 -i input/snmp/resp.bin -n 1 -d -x 3`

`litefuzz -ls -c "./sc_serv shoutcast.conf" -a localhost:8000 -i input/shouts -z`

`litefuzz -ls -c "snmpd" -i input/snmp -a udp://localhost:161 -z`

**ملاحظات سريعة**
- قد تتصرف مقابس UDP بشكل غريب على Mac + Py2، لذلك تم اختبار ودعم Mac + Py3 فقط
- فازينغ عملاء الشبكة المحلية على ويندوز قد يكون متعثراً ويجب اعتباره تجريبياً في هذا الوقت

### أمثلة الشبكة البعيدة

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

UDP يزيد الأمر تعقيداً. حتى إرسال حزمة اختبار لمعرفة ما إذا كانت هناك خدمة استماع على منفذ UDP لا يضمن رداً. لذا من الممكن فازنة عملاء وخوادم الشبكة عن بعد، لكن هناك مقايضة على مستوى الرؤية.

#### عميل

`while :; do echo "user test\rpass test\rls\rbye\r" | ftp localhost 2121; sleep 1; done`

`litefuzz -k -i input/ftp/test -a tcp://localhost:2121 -pp -n 100`

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

#### خادم

يمكن أن تساعدك إيجابيات وسلبيات فازنة خادم محلياً أو عن بعد في اتخاذ قرار حول كيفية التعامل مع الهدف عندما يكون كلا الخيارين متاحاً.

بشكل أساسي، فازنة الخادم في مصحح ستكون أبطأ لكنك ستتمكن من الحصول على سجلات الأعطال مع الفرز التلقائي، بينما فازنة الخادم في الوضع البعيد (حتى توجيهه إلى localhost) ستكون أسرع بكثير في المتوسط، لكنك تفقد الرؤية العالية وقدرات الفرز القائمة على المصحح، لكنها ستمنحك وقتاً لإعادة تشغيل الخادم يدوياً بعد كل عطل لمواصلة التشغيل قبل أن يخرج (خوادم TCP فقط، الميزة لا تدعم الخوادم القائمة على UDP).

**Shoutcast**

`./sc_serv ...`

`litefuzz -s -a localhost:8000 -i input/shouts -n 10000`

**SSHesame**

`sshesame`

`litefuzz -s -a tcp://target:2022 -i input/ssh-server -p -n 1000000 -x 0.05`

**FTP**

`litefuzz -s -a tcp://target:21 -i input/ftp/req.txt -pp -n 1000`

**DNS**

`coredns -dns.port 10000`

`litefuzz -ls -c "coredns -dns.port 10000" -a udp://localhost:10000 -i dns-req/1.bin -o crashes/coredns -n 10000`

أو

`litefuzz -s -a udp://localhost:10000 -i dns-req/1.bin -o crashes/coredns -n 10000`

##### TLS

`litefuzz -s -a tcp://hostname:8080 -i input/http --tls -n 10000````
...
@ 48/10000 (1 crashes, 0 duplicates, ~7:13:18 remaining)

[!] check target, sleeping for 60 seconds before attempting to continue fuzzing...

يتم استهلاك كل حزمة في مصفوفة، ويتم تحوير فهرس عشوائي وإعادة إرساله لاختبار الهدف بالتشويش.

`litefuzz -lk -c "ssh -T test@localhost -p 2222" -a tcp://localhost:2222 -i input/ssh -o crashes/ssh -p -n 250000 -z glibc`

ويمكنك التحقق من مخرجات الهدف لآخر تكرار.```
cat /tmp/litefuzz/out
kex_input_kexinit: discard proposal: string is too large
ssh_dispatch_run_fatal: Connection to 127.0.0.1 port 2222: string is too large

... and others like

ssh_dispatch_run_fatal: Connection to 127.0.0.1 port 2222: unknown or unsupported key type

ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory
Host key verification failed.

Bad packet length 1869636974.
ssh_dispatch_run_fatal: Connection to 127.0.0.1 port 2222: message authentication code incorrect

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

`litefuzz -lk -c "ftp localhost 2121" -a tcp://localhost:2121 -i input/ftp -o crashes/ftp -n 100000 -pp -z`

يمكن أيضًا دمج هذا مع *-u* لعزل أهداف الشبكة الرسومية مثل FileZilla.

`litefuzz -lk -c "filezilla" -a tcp://localhost:2121 -i input/ftp.resp -n 100000 -u -pp -z glibc`

### الارتباط بعملية
إذا أنشأ الهدف عملية جديدة عند الاتصال، يمكن للمرء تحديد اسم عملية (أو معرف عملية) للارتباط بها بعد إنشاء الاتصال بالخادم. هذا مفيد في الحالات التي يستمع فيها، على سبيل المثال، launchd على منفذ ويطلق فقط عملية المعالجة بمجرد اتصال العميل. هذه ميزة تطمس الخط الفاصل بين الاختبار المحلي والبعيد، حيث أن المختبر من الناحية الفنية في الوضع البعيد، ومع ذلك نحدد عنوان الهدف كـ localhost ونطلب منه الارتباط بعملية.

`./litefuzz.py -s -a tcp://localhost:8080 -i input/shareserv -p --attach ShareServ -x 1 -n 100000`

ملاحظة: هذه الميزة مدعومة حاليًا فقط على Mac (LLDB) وللاختبار الشبكي، على الرغم من أنه إذا تم تنفيذها، يجب أن تعمل بشكل جيد على Linux (GDB) أيضًا.

### آثار الأعطال
عند مواجهة عطل أثناء الاختبار، يتم إعادة تشغيله في مصحح الأخطاء لإنتاج آثار تصحيح ومعلومات تصنيف. تختلف المعلومات من منصة إلى أخرى، ولكن عمومًا يتم إنتاج ملف نصي يحتوي على تتبع الاستدعاءات، معلومات السجلات، أشياء من نوع `!exploitable` (حيثما توفرت) وغيرها من المعلومات الأساسية.

**تفريغات الذاكرة** يمكن تمكينها على Windows عن طريق تمرير `--memdump` أو تعطيلها باستخدام `--nomemdump` على غرار كيفية التحكم في مصححات malloc عبر `-z` و `-zz` على التوالي. إذا تم التمكين، سيتم أيضًا تحميل التفريغ في مصحح الأخطاء الطرفي (cdbg) وسيتم التقاط إخراج تحليل الأعطال `!analyze -v` داخل سجل تحليل أعطال تفريغ الذاكرة الإضافي. يحتوي Winappdbg بالفعل على تحليل من نوع !exploitable الذي نحصل عليه في تحليل العطل الأولي، لذا نقوم فقط بـ !analyze هنا.

`litefuzz -l -c "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" --memdump`

أو لتعطيل تفريغات الذاكرة لتطبيق

`litefuzz -l -c "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" --nomemdump`

بالإضافة إلى الفحص التلقائي للأعطال، يتم أيضًا إنتاج الفروقات الثنائية/النصية (حسب الاقتضاء) ومخرجات stdout للهدف (حسب المنصة/الهدف) وبالطبع ملفات إعادة الإنتاج.

بالنسبة للاختبار المحلي، تتضمن الآثار عمومًا الفروقات، stdout (Linux/Mac فقط)، ملف إعادة الإنتاج، وسجل العطل وملف المعلومات.```
$ ls crashes/latex
PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.diff
PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.diffs
PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.out
PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.tex
PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.txt

بالنسبة للاختبار العشوائي عن بُعد، قد تختلف القطع الأثرية (artifacts) وفقًا للخيارات المختارة، ولكنها غالبًا ما تتضمن الفروقات (diffs)، وملف إعادة الإنتاج (repro file) و/أو دليل ملف إعادة الإنتاج (إذا كان الإدخال جلسة تحتوي على عدة حزم)، وإعادة إنتاج تكرار الاختبار العشوائي السابق (لمنع فقدان خطأ في حال كان هو السبب الفعلي للتعطل، حيث أن للاختبار العشوائي عن بُعد تحدياته)، وسجل التعطل أو ملف معلومات موجز.```
ls crashes/serverd
REMOTE_SERVER_testbox.1_NNNN_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY
REMOTE_SERVER_testbox.1_NNNN_PREV_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY
UNKNOWN_XXXX2040YYYY_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY.diff
UNKNOWN_XXXX2040YYYY_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY.diffs
UNKNOWN_XXXX2040YYYY_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY.txt
UNKNOWN_XXXX2040YYYY_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY.zz

ls crashes/serverd/REMOTE_SERVER_localhost_NNNN_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY
REMOTE_SERVER_testbox.1_NNNN_1.zz	REMOTE_SERVER_localhost_NNNN_2.zz
REMOTE_SERVER_testbox.1_NNNN_3.zz	REMOTE_SERVER_localhost_NNNN_4.zz

ألق نظرة على نسخته المصغرة.```
GET /admin.cgi?mode=debug&option=a
Authorization:s YWRtaW46Y2hhbmdlbWU
Referer:admin.cgi

**أمثلة التصغير**

`litefuzz -l -c "latex2rtf FUZZ" -m test.tex -z`

`litefuzz -ls -c "./sc_serv shoutcast.conf" -a "tcp://localhost:8000" -m repro.http`

**مثال supermin**```
litefuzz -l -c "latex2rtf FUZZ" -mm crashes/latex2rtf/test.tex -z
...
[+] starting minimization

@ 582/582 (1 new crashes, 1145 -> 582 bytes, ~0:00:00 remaining)  

[+] reduced crash @ pc=55555556c141 -> pc=55555557c57d to 582 bytes

[+] supermin activated, continuing...

@ 299/299 (1 new crashes, 582 -> 300 bytes, ~0:00:00 remaining)

[+] reduced crash @ pc=55555557c57d to 300 bytes
...
[+] reduced crash @ pc=555555562170 to 17 bytes

@ 17/17 (2 new crashes, 17 -> 17 bytes, ~0:00:00 remaining)

[+] achieved maximum minimization @ 17 bytes (test.min.tex)

[RESULTS]
completed (17) iterations with 2 new crashes found

#### تعداد معالجات الملفات على Ubuntu```
$ cat /usr/share/applications/defaults.list
[Default Applications]
application/csv=libreoffice-calc.desktop
application/excel=libreoffice-calc.desktop
application/msexcel=libreoffice-calc.desktop
application/msword=libreoffice-writer.desktop
application/ogg=rhythmbox.desktop
application/oxps=org.gnome.Evince.desktop
application/postscript=org.gnome.Evince.desktop
....

**اختبار تشويش على فك تشفير gpg عبر stdin مع فحص أخطاء الكومة** (Mac)

`litefuzz -l -c "gpg --decrypt" -i test-gpg -o crashes-gpg -z`

**تشويش تطبيق Books** (Mac GUI)

`litefuzz -l -c "/System/Applications/Books.app/Contents/MacOS/Books FUZZ" -i test-epub -t "/Users/test/Library/Containers/com.apple.iBooksX/Data" -x 8 -n 100000 -z`

ملاحظة: `-z` هنا يُفعّل [Guard Malloc](https://www.manpagez.com/man/3/libgmalloc/) فحص أخطاء الكومة بهدف اكتشاف أخطاء تلف الكومة الدقيقة

**ملاحظة لماك**

قد تفشل بعض أهداف GUI في الإنهاء بعد انتهاء مهلة كل تكرار وتصبح غير مستجيبة. للتخفيف من ذلك، يمكنك تشغيل سكريبت مشابه لهذا في طرفية أخرى لقتلها بشكل دوري في دفعة واحدة لتقليل الجهد اليدوي والمراقبة، وإلا فقد تتأثر عملية التشويش.```
#!/bin/bash
ps -Af | grep -ie "$1" | awk '{print $2}' | xargs kill -9

*/Users/test* (مثال للجزء الأول من المسار حيث يتم تمرير الملفات المؤقتة إلى تطبيق واجهة المستخدم الرسومية المحلي، يصبح FUZZ مسارًا أثناء التنفيذ) تم اختياره لأنك تحتاج إلى سلسلة نصية فريدة لإنهاء العمليات، وإذا استخدمت فقط اسم العملية (Process Name)، فسيؤدي ذلك إلى إنهاء عملية التفحيم (fuzzing) لأنها تحتوي على اسم العملية أيضًا.

**تعداد معالجات الملفات على Windows**

باستخدام سكريبت [AssocQueryString](https://github.com/sec-tools/WindowsFileHandlerEnumeration/) مع الأمر *assoc* يمكن تعيين امتدادات الملفات إلى التطبيقات الافتراضية.```
C:\> .\AssocQueryString.ps1
...
.hlp :: C:\Windows\winhlp32.exe
.hta :: C:\Windows\SysWOW64\mshta.exe
.htm :: C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
.html :: C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
.icc :: C:\Windows\system32\colorcpl.exe
.icm :: C:\Windows\system32\colorcpl.exe
.imesx :: C:\Windows\system32\IME\SHARED\imesearch.exe
.img :: C:\Windows\Explorer.exe
.inf :: C:\Windows\system32\NOTEPAD.EXE
.ini :: C:\Windows\system32\NOTEPAD.EXE
.iso :: C:\Windows\Explorer.exe

#### عميل محلي

**اختبار عميل SNMP على المضيف المحلي (Linux)**

`litefuzz -lk -c "snmpwalk -v 2c -c public localhost:1616 1.3.6.1.2.1.1.1" -a udp://localhost:1616 -i input/snmp/resp.bin -n 1 -d -x 3`

#### عميل بعيد

**اختبار عميل FTP بعيد (Linux)**

`while :; do echo "user test\rpass test\rls\rbye\r" | ftp localhost 2121; sleep 1; done`

`litefuzz -k -i input/ftp/test -a tcp://localhost:2121 -n 100`

ملاحظة: اعتمادًا على الهدف، قد يتطلب اختبار العميل الاستماع على منفذ مميز (1-1024). في هذه الحالة، على Linux يمكنك إما استخدام `setcap cap_net_bind_service=+ep` على مترجم بايثون أو استخدام sudo عند تشغيل المُختبر، على Mac استخدم sudo فقط، وعلى Windows يمكنك تشغيل المُختبر كمسؤول لتجنب أي أخطاء في رفض الإذن.

### الخادم

#### نظرة سريعة```
litefuzz -ls -c "./sc_serv shoutcast.conf" -a tcp://localhost:8000 -i input/shoutcast -o crashes/shoutcast -n 1000 -z
--========================--
--======| litefuzz |======--
--========================--

[STATS]
run id:     4001
cmdline:    ./sc_serv shoutcast.conf
address:    tcp://localhost:8000
crash dir:  crashes/shoutcast
input dir:  input/shoutcast
inputs:     3
iterations: 1000
mutator:    random(mutators)

@ 1000/1000 (1 crashes, 7 duplicates, ~0:00:00 remaining)

[RESULTS]
> completed (1000) iterations with (1) unique crashes and 7 dups
>> check crashes/shoutcast for more details

# الجوائز

قامت Litefuzz بعمل fuzzing لاستخراج الأعطال من حزم برمجية مختلفة مثل...

* antiword
* AppleScript (OS X)
* ArangoDB VelocyPack
* Avast authenticode-parser
* Avast RetDec
* BBC Audio Waveform
* ColorSync (OS X)
* Dynamsoft BarcodeReader
* eot2ttf
* evernote2md
* faad2
* Facebook's Origami Studio
* FontForge
* ForestDB
* Gifsicle
* GPUJPEG
* GPAC Multimedia Framework
* Google Draco
* Google Quipper
* GoPro GPR
* GtkRadiant
* IIPImage Server
* John The Ripper
* Kyoto Cabinet
* latex2rtf
* libMeshb
* libembroidery
* libsndfile
* Lion Vector Graphics (lvg)
* L-SMASH
* mp3-decoder
* MindNode
* minimp4
* MiniWeb Server
* MLpack
* Nvidia Data Center GPU Manager
* Numbers (OS X)
* OpenJPEG
* OpenOrienteering Mapper
* OSM Express
* Pages (OS X)
* PBRT-Parser
* Pixar USD
* Remote Apple Events (OS X)
* Samsung rlottie
* Samsung ThorVG
* Shoutcast Server
* Silo
* syslog (OS X)
* Tencent NCNN
* TinyXML2
* UEFITool
* Ulfius Web Framework
* zlib

# الأسئلة الشائعة

## كيف نشأ هذا المشروع؟
الـ Fuzzing ممتع! ومن الجيد القيام بمشاريع تأخذ وجهة نظر معارضة مفادها أن أدوات الـ fuzzing لا يجب أن تتبع دائمًا الأساليب الحديثة أو الشائعة للوصول إلى الهدف النهائي المتمثل في إيجاد الأخطاء. سواء كنت قريبًا من العتاد المباشر، أو تحصل على تغطية الكود عبر جميع المسارات، أو ببساطة تحسين السرعة والمرونة، أو الطريقة الأساسية "لتفنيد الافتراضيات" وغيرها. مهما كان شكله، استمتع به.

## هل هذا المشروع يُصان بنشاط؟
يرجى عدم توقع دعم نشط أو صيانة للمشروع. لا تتردد في عمل fork لإضافة ميزات جديدة أو إصلاح الأخطاء، إلخ. ربما حتى تقديم PR للأشياء الصغيرة، على الرغم من عدم وجود توقعات للردود أو استكشاف الأخطاء وإصلاحها. ليس المقصود أن يكون التطوير على هذا المستودع نشطًا.

## كيف تعرف أن أداة الـ fuzzer تعمل بشكل جيد وهل قستها مقابل أدوات أخرى؟
الغرض من Litefuzz هو إيجاد الأخطاء عبر المنصات. وهي تفعل ذلك. لذا، بصراحة، القدرة على مقارنتها مع fuzzerX أو fuzzerY لم تكن أولوية. تم اتخاذ بعض المفاضلات والإقرار بها عند البداية، راجع [#intro](https://github.com/sec-tools/litefuzz/blob/HEAD/README.md#intro) لمزيد من التفاصيل.

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

## ما مدى استقرار litefuzz؟
تم اختبار سطر الأوامر، واجهة المستخدم الرسومية، fuzzing الشبكة (معظمه على لينكس وماك)، التصغير، إلخ بشكل شامل ويجب أن تكون صلبة بشكل عام. بعض الميزات الأكثر غرابة مثل fuzzing الشبكة المعزول مع واجهة المستخدم الرسومية، ودعم ReportCrash لماك وبعض الميزات المتخصصة الأخرى يجب اعتبارها تجريبية.

## هل هناك سيناريوهات غير مدعومة لـ litefuzz؟
نعم، القليل منها. لكن معظمها إما سيناريوهات غير شائعة ومعيبة، أو تتطلب وقتًا وبحثًا أكثر "للوصول إلى الصواب"، أو لا تعمل بشكل جيد لأسباب تتعلق بالمنصة. العديد منها يخرج بشكل صريح برسالة "غير مدعوم" عند محاولة تشغيلها مع تلك الخيارات، وقد تم ذكر بعض التحذيرات في الأقسام أعلاه عند وصف الميزات المختلفة. بعض الأكثر دقة تشمل وضع إعادة الإنتاج على التطبيقات *المعزولة* غير مدعوم، وأيضًا كان هناك اختبار محدود لتطبيقات Mac باستخدام ميزة العزل، ويبدو أن Pyautogui يعمل بشكل جيد على لينكس وويندوز ولكن على Mac لم يكن موثوقًا به، لذا اعتبره غير مدعوم وظيفيًا، ويمكن أن يكون fuzzing العميل على ويندوز أقل موثوقية من الأوضاع الأخرى على المنصات الأخرى.

قد يكون هناك بعض الحالات الحدودية هنا وهناك، ولكن تم اختبار سيناريوهات fuzzing المحلية والشبكية الأكثر شيوعًا وهي تعمل. آه، هذه هي أفراح كتابة أدوات عبر المنصات: مجزية، ولكن من الصعب جعل كل شيء يعمل بشكل رائع طوال الوقت. بشكل عام، يبدو أن fuzzing على لينكس/ماك أكثر استقرارًا ويدعم ميزات أكثر بشكل عام، خاصةً أنه خضع لاختبارات أكثر بكثير لـ fuzzing الشبكة مقارنة بمنصة ويندوز، ولكن تم بذل جهد لجعل الأساسيات على الأقل متاحة على Win32 مع بعض الإضافات.

لا تتردد في عمل fork لهذه الأداة وإجراء مثل هذه التحسينات، ودعم ما هو غير مدعوم حاليًا، إلخ، أو PRs لأشياء أصغر ولكن مفيدة.

## ما هي الضمانات المقدمة لهذا المشروع أو كوده؟
لا شيء على الإطلاق. لكن من الممتع جدًا عمل fuzzing ومشاهدته وهو يقدم لك الأخطاء.

## المؤلف / المراجع
- [Jeremy Brown](https://github.com/sec-tools/litefuzz/blob/HEAD/jbrown3264%5BNOSPAM%5Dgmail)
- [شريحة عرض لـ macOS Fuzzing](https://www.slideshare.net/JeremyBrown37/summer-of-fuzz-macos)