AFL
Version 2.57b (2020-06-30)
تم تطويره في الأصل بواسطة Michal Zalewski [email protected].
راجع QuickStartGuide.txt إذا لم يكن لديك الوقت لقراءة هذا الملف.
تعد Fuzzing واحدة من أقوى الاستراتيجيات التي أثبتت جدواها لتحديد المشكلات الأمنية في برامج العالم الحقيقي؛ وهو مسؤول عن الغالبية العظمى من عمليات تنفيذ التعليمات البرمجية عن بعد وأخطاء تصعيد الامتيازات التي تم اكتشافها حتى الآن في البرامج الأمنية الهامة.
ولسوء الحظ، فإن التشويش هو أيضًا سطحي نسبيًا؛ تجعل الطفرات العشوائية العمياء من غير المرجح جدًا الوصول إلى مسارات تعليمات برمجية معينة في التعليمات البرمجية التي تم اختبارها، مما يترك بعض الثغرات الأمنية خارج نطاق هذه التقنية.
وكانت هناك محاولات عديدة لحل هذه المشكلة. أحد الأساليب المبكرة - التي ابتكرها تافيس أورماندي - هو تقطير الجسم. وتعتمد هذه الطريقة على إشارات التغطية لاختيار مجموعة فرعية من البذور المثيرة للاهتمام من مجموعة ضخمة وعالية الجودة من الملفات المرشحة، ثم تشويشها بالوسائل التقليدية. ويعمل هذا النهج بشكل جيد للغاية، ولكنه يتطلب أن تكون مثل هذه المجموعة متاحة بسهولة. وبالإضافة إلى ذلك، فإن قياسات تغطية الكتلة لا توفر سوى فهم مبسط للغاية لحالة البرنامج، وتكون أقل فائدة في توجيه جهود التشويش على المدى الطويل.
وقد ركزت أبحاث أخرى أكثر تطورًا على تقنيات مثل تحليل تدفق البرنامج ("التنفيذ القولوني")، أو التنفيذ الرمزي، أو التحليل الثابت. جميع هذه الأساليب واعدة للغاية في الإعدادات التجريبية، ولكنها تميل إلى المعاناة من مشاكل الموثوقية والأداء في الاستخدامات العملية - ولا تقدم حاليًا بديلاً قابلاً للتطبيق لتقنيات التشويش "الغبية".
American Fuzzy Lop عبارة عن قوة غامضة مقترنة بخوارزمية جينية بسيطة للغاية ولكنها قوية وموجهة بالأجهزة. ويستخدم شكلاً معدلاً من تغطية الحافة لالتقاط التغييرات الدقيقة على المستوى المحلي بسهولة لتدفق التحكم في البرنامج.
بتبسيط الأمر قليلاً، يمكن تلخيص الخوارزمية الشاملة على النحو التالي:
تحميل حالات الاختبار الأولية المقدمة من قبل المستخدم في قائمة الانتظار،
خذ ملف الإدخال التالي من قائمة الانتظار،
محاولة تقليص حالة الاختبار إلى أصغر حجم لا يغير السلوك المُقاس للبرنامج،
قم بتغيير الملف بشكل متكرر باستخدام مجموعة متنوعة متوازنة ومدروسة جيدًا من استراتيجيات التشويش التقليدية،
إذا أدى أي من الطفرات التي تم إنشاؤها إلى انتقال حالة جديدة مسجلة بواسطة الأجهزة، قم بإضافة الإخراج المتحور كإدخال جديد في قائمة الانتظار.
اذهب إلى 2.
يتم أيضًا التخلص من حالات الاختبار المكتشفة بشكل دوري للتخلص من الحالات التي عفا عليها الزمن من خلال الاكتشافات الأحدث ذات التغطية الأعلى؛ والخضوع للعديد من خطوات تقليل الجهد الأخرى المعتمدة على الأجهزة.
وكنتيجة جانبية لعملية التشويش، تقوم الأداة بإنشاء مجموعة صغيرة مستقلة من حالات الاختبار المثيرة للاهتمام. وهي مفيدة للغاية في زرع أنظمة اختبار أخرى كثيفة العمالة أو الموارد - على سبيل المثال، لمتصفحات اختبار التحمل، أو التطبيقات المكتبية، أو مجموعات الرسومات، أو الأدوات مغلقة المصدر.
تم اختبار التشويش بدقة لتقديم أداء خارج الصندوق يتفوق بكثير على أدوات التشويش الأعمى أو أدوات التغطية فقط.
عندما يكون كود المصدر متاحًا، يمكن إدخال الأجهزة بواسطة أداة مصاحبة تعمل كبديل مباشر لـ gcc أو clang في أي عملية إنشاء قياسية لتعليمات برمجية خارجية.
الأجهزة لها تأثير أداء متواضع إلى حد ما. بالاشتراك مع التحسينات الأخرى التي تنفذها afl-fuzz، يمكن تحسين معظم البرامج بسرعة أو حتى أسرع من الأدوات التقليدية.
قد تختلف الطريقة الصحيحة لإعادة ترجمة البرنامج المستهدف اعتمادًا على تفاصيل عملية الإنشاء، ولكن النهج الشامل تقريبًا سيكون كما يلي:
$ CC=/path/to/afl/afl-gcc ./configure
$ make clean all بالنسبة لبرامج C++، قد ترغب أيضًا في تعيين CXX=/path/to/afl/afl-g++ .
يمكن استخدام أغلفة clang (afl-clang وafl-clang++) بنفس الطريقة؛ قد يختار مستخدمو clang أيضًا الاستفادة من وضع الأجهزة عالي الأداء، كما هو موضح في llvm_mode/README.llvm.
عند اختبار المكتبات، تحتاج إلى العثور على أو كتابة برنامج بسيط يقرأ البيانات من stdin أو من ملف ويمررها إلى المكتبة التي تم اختبارها. في مثل هذه الحالة، من الضروري ربط هذا الملف القابل للتنفيذ بإصدار ثابت من المكتبة المُجهزة، أو التأكد من تحميل ملف .so الصحيح في وقت التشغيل (عادةً عن طريق تعيين LD_LIBRARY_PATH ). الخيار الأبسط هو البناء الثابت، والذي يكون ممكنًا عادةً عبر:
$ CC=/path/to/afl/afl-gcc ./configure --disable-shared سيؤدي تعيين AFL_HARDEN=1 عند استدعاء "make" إلى تمكين برنامج CC المجمّع تلقائيًا لخيارات تقوية التعليمات البرمجية التي تسهل اكتشاف أخطاء الذاكرة البسيطة. Libdislocator، وهي مكتبة مساعدة متضمنة مع AFL (انظر libdislocator/README.dislocator) يمكن أن تساعد في الكشف عن مشكلات تلف الكومة أيضًا.
ملاحظة: يُنصح مستخدمو ASAN بمراجعة ملف Notes_for_asan.txt للتعرف على التحذيرات المهمة.
عندما لا يكون كود المصدر متاحًا، يقدم Fuzzer دعمًا تجريبيًا للأدوات السريعة والسريعة لثنائيات الصندوق الأسود. يتم تحقيق ذلك من خلال إصدار QEMU الذي يعمل في وضع "محاكاة مساحة المستخدم" الأقل شهرة.
يعد QEMU مشروعًا منفصلاً عن AFL، ولكن يمكنك إنشاء الميزة بسهولة عن طريق القيام بما يلي:
$ cd qemu_mode
$ ./build_qemu_support.shللحصول على تعليمات وتحذيرات إضافية، راجع qemu_mode/README.qemu.
يكون الوضع أبطأ بمقدار 2-5 مرات تقريبًا من أدوات وقت الترجمة، وهو أقل ملاءمة للموازاة، وقد يحتوي على بعض المراوغات الأخرى.
لكي يعمل بشكل صحيح، يتطلب Fuzzer ملف بداية واحدًا أو أكثر يحتوي على مثال جيد لبيانات الإدخال التي يتوقعها عادةً التطبيق المستهدف. هناك قاعدتان أساسيتان:
احتفظ بالملفات صغيرة الحجم. أقل من 1 كيلو بايت يعتبر مثاليًا، على الرغم من أنه ليس ضروريًا تمامًا. لمناقشة سبب أهمية الحجم، راجع perf_tips.txt.
استخدم حالات اختبار متعددة فقط إذا كانت مختلفة وظيفيًا عن بعضها البعض. ليس هناك أي فائدة من استخدام خمسين صورة مختلفة للإجازة لإضفاء التشويش على مكتبة الصور.
يمكنك العثور على العديد من الأمثلة الجيدة لبدء الملفات في حالات الاختبار/الدليل الفرعي الذي يأتي مع هذه الأداة.
ملاحظة: إذا كانت هناك مجموعة كبيرة من البيانات متاحة للفحص، فقد ترغب في استخدام الأداة المساعدة afl-cmin لتحديد مجموعة فرعية من الملفات المتميزة وظيفيًا والتي تمارس مسارات تعليمات برمجية مختلفة في الملف الثنائي المستهدف.
يتم تنفيذ عملية التشويش نفسها بواسطة الأداة المساعدة afl-fuzz. يتطلب هذا البرنامج دليلًا للقراءة فقط يحتوي على حالات الاختبار الأولية، ومكانًا منفصلاً لتخزين نتائجه، بالإضافة إلى مسار إلى الملف الثنائي للاختبار.
بالنسبة للثنائيات المستهدفة التي تقبل الإدخال مباشرة من stdin، فإن بناء الجملة المعتاد هو:
$ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program [...params...]بالنسبة للبرامج التي تتلقى إدخالاً من ملف، استخدم "@@" لتحديد الموقع في سطر أوامر الهدف حيث يجب وضع اسم ملف الإدخال. سوف يقوم Fuzzer باستبدال هذا لك:
$ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program @@يمكنك أيضًا استخدام الخيار -f لكتابة البيانات المتحولة إلى ملف معين. يعد هذا مفيدًا إذا كان البرنامج يتوقع امتداد ملف معين أو نحو ذلك.
يمكن تشويش الثنائيات غير المُجهزة في وضع QEMU (أضف -Q في سطر الأوامر) أو في وضع التشويش الأعمى التقليدي (حدد -n).
يمكنك استخدام -t و -m لتجاوز المهلة الافتراضية وحد الذاكرة للعملية المنفذة؛ تشمل الأمثلة النادرة للأهداف التي قد تحتاج إلى لمس هذه الإعدادات المترجمين وأجهزة فك تشفير الفيديو.
تمت مناقشة نصائح تحسين أداء التشويش في الملف perf_tips.txt.
لاحظ أن afl-fuzz يبدأ بتنفيذ مجموعة من خطوات التشويش الحتمية، والتي يمكن أن تستغرق عدة أيام، ولكنها تميل إلى إنتاج حالات اختبار أنيقة. إذا كنت تريد الحصول على نتائج سريعة وقذرة على الفور - على غرار zzuf وغيره من أدوات التشويش التقليدية - أضف الخيار -d إلى سطر الأوامر.
راجع ملف Status_screen.txt للحصول على معلومات حول كيفية تفسير الإحصائيات المعروضة ومراقبة صحة العملية. تأكد من الرجوع إلى هذا الملف خاصةً إذا تم تمييز أي عناصر لواجهة المستخدم باللون الأحمر.
ستستمر عملية التشويش حتى تضغط على Ctrl-C. على الأقل، تريد السماح للـ Fuzzer بإكمال دورة قائمة انتظار واحدة، والتي قد تستغرق من بضع ساعات إلى أسبوع أو نحو ذلك.
هناك ثلاثة أدلة فرعية تم إنشاؤها داخل دليل الإخراج ويتم تحديثها في الوقت الفعلي:
queue/ - حالات اختبار لكل مسار تنفيذ مميز بالإضافة إلى كافة ملفات البداية التي قدمها المستخدم. هذه هي المجموعة المركبة المذكورة في القسم 2. قبل استخدام هذه المجموعة لأي أغراض أخرى، يمكنك تقليصها إلى حجم أصغر باستخدام أداة afl-cmin. ستجد الأداة مجموعة فرعية أصغر من الملفات التي تقدم تغطية حافة مكافئة.
الأعطال/ - حالات اختبار فريدة تتسبب في تلقي البرنامج الذي تم اختباره إشارة قاتلة (على سبيل المثال، SIGSEGV، SIGILL، SIGABRT). يتم تجميع الإدخالات حسب الإشارة المستلمة.
Hangs/ - حالات اختبار فريدة تؤدي إلى انتهاء مهلة البرنامج الذي تم اختباره. الحد الزمني الافتراضي قبل تصنيف شيء ما على أنه تعليق هو ثانية واحدة أكبر وقيمة المعلمة -t. يمكن ضبط القيمة بدقة عن طريق تعيين AFL_HANG_TMOUT، ولكن نادرًا ما يكون هذا ضروريًا.
تعتبر الأعطال والتعليقات "فريدة" إذا كانت مسارات التنفيذ المرتبطة تتضمن أي انتقالات حالة لم يتم مشاهدتها في الأخطاء المسجلة مسبقًا. إذا كان من الممكن الوصول إلى خطأ واحد بطرق متعددة، فسيكون هناك بعض التضخم في العدد في وقت مبكر من العملية، ولكن هذا يجب أن يتضاءل بسرعة.
ترتبط أسماء الملفات الخاصة بالأعطال والتعليقات بإدخالات قائمة الانتظار الأصلية وغير المسببة للخطأ. وهذا من شأنه أن يساعد في تصحيح الأخطاء.
عندما لا تتمكن من إعادة إنتاج العطل الذي عثرت عليه afl-fuzz، فإن السبب الأكثر احتمالاً هو أنك لا تقوم بتعيين نفس حد الذاكرة الذي تستخدمه الأداة. يحاول:
$ LIMIT_MB=50
$ ( ulimit -Sv $[LIMIT_MB << 10] ; /path/to/tested_binary ... )قم بتغيير LIMIT_MB لمطابقة المعلمة -m التي تم تمريرها إلى afl-fuzz. في OpenBSD، قم أيضًا بتغيير -Sv إلى -Sd.
يمكن أيضًا استخدام أي دليل إخراج موجود لاستئناف المهام المجهضة؛ يحاول:
$ ./afl-fuzz -i- -o existing_output_dir [...etc...]إذا قمت بتثبيت gnuplot، فيمكنك أيضًا إنشاء بعض الرسوم البيانية الجميلة لأي مهمة غامضة نشطة باستخدام afl-plot. للحصول على مثال لكيفية ظهور ذلك، راجع http://lcamtuf.coredump.cx/afl/plot/.
كل مثيل لـ afl-fuzz يستهلك نواة واحدة تقريبًا. وهذا يعني أنه في الأنظمة متعددة النواة، يعد التوازي ضروريًا للاستفادة الكاملة من الأجهزة. للحصول على نصائح حول كيفية التشويش على هدف مشترك على مراكز متعددة أو أجهزة متعددة متصلة بالشبكة، يرجى الرجوع إلى Parallel_fuzzing.txt.
يوفر وضع التشويش المتوازي أيضًا طريقة بسيطة لربط AFL مع أجهزة التشويش الأخرى، ومحركات التنفيذ الرمزية أو المتزامنة، وما إلى ذلك؛ مرة أخرى، راجع القسم الأخير من Parallel_fuzzing.txt للحصول على النصائح.
افتراضيًا، يتم تحسين محرك طفرة afl-fuzz لتنسيقات البيانات المضغوطة - على سبيل المثال، الصور أو الوسائط المتعددة أو البيانات المضغوطة أو بناء جملة التعبير العادي أو نصوص shell النصية. إنها أقل ملاءمة إلى حد ما للغات ذات الإسهاب المطول والمتكرر بشكل خاص - لا سيما بما في ذلك HTML أو SQL أو JavaScript.
لتجنب متاعب بناء أدوات بناء الجملة، يوفر afl-fuzz طريقة لبذر عملية التشويش باستخدام قاموس اختياري للكلمات الأساسية للغة، أو الرؤوس السحرية، أو الرموز المميزة الأخرى المرتبطة بنوع البيانات المستهدف - واستخدام ذلك لإعادة البناء القواعد الأساسية أثناء التنقل:
http://lcamtuf.blogspot.com/2015/01/afl-fuzz-making-up-grammar-with.html
لاستخدام هذه الميزة، تحتاج أولاً إلى إنشاء قاموس بأحد التنسيقين اللذين تمت مناقشتهما في القواميس/README.dictionaries؛ ثم قم بتوجيه الـ Fuzzer إليه عبر الخيار -x في سطر الأوامر.
(يتم توفير العديد من القواميس الشائعة بالفعل في هذا الدليل الفرعي أيضًا.)
لا توجد طريقة لتقديم أوصاف أكثر تنظيمًا للصيغة الأساسية، ولكن من المرجح أن يكتشف الغامض بعضًا من هذا بناءً على ردود فعل الأجهزة وحدها. هذا يعمل في الواقع العملي، قل:
http://lcamtuf.blogspot.com/2015/04/finding-bugs-in-sqlite-easy-way.html
ملاحظة: حتى في حالة عدم وجود قاموس واضح، سيحاول afl-fuzz استخراج الرموز النحوية الموجودة في مجموعة الإدخال من خلال مراقبة الأجهزة عن كثب أثناء تقلبات البايت الحتمية. يعمل هذا مع بعض أنواع المحللين والقواعد النحوية، ولكنه ليس بنفس جودة الوضع -x.
إذا كان من الصعب حقًا الحصول على قاموس، فهناك خيار آخر وهو السماح بتشغيل AFL لفترة من الوقت، ثم استخدام مكتبة التقاط الرمز المميز التي تأتي كأداة مساعدة مصاحبة مع AFL. لذلك، راجع libtokencap/README.tokencap.
عادةً ما ينتج عن تجميع الأعطال على أساس التغطية مجموعة بيانات صغيرة يمكن فرزها يدويًا بسرعة أو باستخدام برنامج نصي بسيط جدًا GDB أو Valgrind. يمكن أيضًا تتبع كل تعطل إلى حالة اختبار عدم التعطل الأصلية الموجودة في قائمة الانتظار، مما يسهل تشخيص الأخطاء.
بعد قولي هذا، من المهم الاعتراف بأن بعض الأعطال المبهمة قد يكون من الصعب تقييمها سريعًا من حيث قابلية الاستغلال دون الكثير من أعمال تصحيح الأخطاء وتحليل التعليمات البرمجية. للمساعدة في هذه المهمة، يدعم afl-fuzz وضع "استكشاف الأعطال" الفريد جدًا والذي يتم تمكينه باستخدام علامة -C.
في هذا الوضع، يأخذ التشويش حالة اختبار تعطل واحدة أو أكثر كمدخلات، ويستخدم إستراتيجيات التشويش المبنية على ردود الفعل لتعداد جميع مسارات التعليمات البرمجية التي يمكن الوصول إليها في البرنامج بسرعة كبيرة مع إبقائه في حالة التعطل.
يتم رفض الطفرات التي لا تؤدي إلى تحطم الطائرة؛ وكذلك أي تغييرات لا تؤثر على مسار التنفيذ.
الناتج عبارة عن مجموعة صغيرة من الملفات التي يمكن فحصها بسرعة كبيرة لمعرفة درجة سيطرة المهاجم على العنوان المخطئ، أو ما إذا كان من الممكن تجاوز القراءة الأولية خارج الحدود - ومعرفة ما يكمن تحتها .
أوه، شيء آخر: لتقليل حالة الاختبار، جرب afl-tmin. يمكن تشغيل الأداة بطريقة بسيطة جدًا:
$ ./afl-tmin -i test_case -o minimized_result -- /path/to/program [...]تعمل الأداة مع حالات الاختبار المتعطلة وغير المتعطلة على حدٍ سواء. في وضع التعطل، سيقبل بسعادة الثنائيات المجهزة وغير المجهزة. في وضع عدم التعطل، يعتمد المصغر على أدوات AFL القياسية لجعل الملف أكثر بساطة دون تغيير مسار التنفيذ.
يقبل المصغر بناء الجملة -m و -t و -f و@@ بطريقة متوافقة مع afl-fuzz.
إضافة حديثة أخرى إلى AFL هي أداة تحليل AFL. فهو يأخذ ملف إدخال، ويحاول قلب البايتات بشكل تسلسلي، ويلاحظ سلوك البرنامج الذي تم اختباره. ثم يقوم بعد ذلك بترميز الإدخال بالألوان بناءً على الأقسام التي تبدو حرجة وأيها ليست كذلك؛ على الرغم من أنه ليس مضادًا للرصاص، إلا أنه غالبًا ما يقدم رؤى سريعة حول تنسيقات الملفات المعقدة. يمكن العثور على مزيد من المعلومات حول تشغيله بالقرب من نهاية ملف tech_details.txt.
يعد Fuzzing تقنية رائعة وغير مستغلة لاكتشاف أخطاء التصميم والتنفيذ غير المتعطلة أيضًا. تم العثور على عدد لا بأس به من الأخطاء المثيرة للاهتمام عن طريق تعديل البرامج المستهدفة لاستدعاء abort() عندما، على سبيل المثال:
تنتج مكتبتان كبيرتان مخرجات مختلفة عند إعطائهما نفس المدخلات التي تم إنشاؤها بواسطة Fuzzer،
تنتج مكتبة الصور مخرجات مختلفة عندما يُطلب منها فك تشفير نفس الصورة المدخلة عدة مرات على التوالي.
تفشل مكتبة التسلسل/إلغاء التسلسل في إنتاج مخرجات مستقرة عند إجراء تسلسل وإلغاء تسلسل للبيانات المقدمة من قبل Fuzzer بشكل متكرر،
تنتج مكتبة الضغط مخرجات غير متوافقة مع ملف الإدخال عندما يُطلب منك ضغط كائن ثنائي كبير الحجم ثم فك ضغطه.
عادةً ما يستغرق تنفيذ هذه الضوابط أو ما شابهها من فحوصات السلامة وقتًا قصيرًا جدًا؛ إذا كنت مشرفًا على حزمة معينة، فيمكنك جعل هذا الكود مشروطًا باستخدام #ifdef FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION (علامة مشتركة أيضًا مع libfuzzer) أو #ifdef __AFL_COMPILER (هذا مخصص لـ AFL فقط).
يرجى الأخذ في الاعتبار أنه، كما هو الحال مع العديد من المهام الحسابية المكثفة، قد يؤدي التشويش إلى الضغط على أجهزتك ونظام التشغيل. بخاصة:
سوف تعمل وحدة المعالجة المركزية الخاصة بك بشكل ساخن وستحتاج إلى تبريد مناسب. في معظم الحالات، إذا كان التبريد غير كافٍ أو توقف عن العمل بشكل صحيح، فسيتم تقليل سرعات وحدة المعالجة المركزية تلقائيًا. ومع ذلك، خاصة عند استخدام أجهزة أقل ملاءمة (أجهزة الكمبيوتر المحمولة والهواتف الذكية وما إلى ذلك)، فليس من المستحيل تمامًا أن ينفجر شيء ما.
قد ينتهي الأمر بالبرامج المستهدفة إلى الاستيلاء بشكل غير منتظم على غيغابايت من الذاكرة أو ملء مساحة القرص بالملفات غير المرغوب فيها. يحاول AFL فرض حدود الذاكرة الأساسية، لكنه لا يستطيع منع كل حادث مؤسف محتمل. خلاصة القول هي أنه لا ينبغي عليك التشويش على الأنظمة التي لا يشكل فيها احتمال فقدان البيانات خطراً مقبولاً.
يتضمن Fuzzing مليارات عمليات القراءة والكتابة في نظام الملفات. في الأنظمة الحديثة، عادةً ما يتم تخزين هذا بشكل كبير في ذاكرة التخزين المؤقت، مما يؤدي إلى عمليات إدخال/إخراج "فعلية" متواضعة إلى حد ما - ولكن هناك العديد من العوامل التي قد تغير هذه المعادلة. تقع على عاتقك مسؤولية مراقبة المشاكل المحتملة؛ مع عمليات الإدخال/الإخراج الثقيلة جدًا، قد ينخفض العمر الافتراضي للعديد من محركات الأقراص الثابتة ومحركات أقراص الحالة الصلبة.
هناك طريقة جيدة لمراقبة الإدخال/الإخراج للقرص على نظام التشغيل Linux وهي الأمر "iostat":
$ iostat -d 3 -x -k [...optional disk ID...]فيما يلي بعض أهم التحذيرات الخاصة بـ AFL:
يكتشف AFL الأخطاء عن طريق التحقق من موت العملية الناتجة الأولى بسبب الإشارة (SIGSEGV، SIGABRT، إلخ). قد تحتاج البرامج التي تثبت معالجات مخصصة لهذه الإشارات إلى التعليق على التعليمات البرمجية ذات الصلة. وعلى نفس المنوال، قد تتجنب الأخطاء في العمليات الفرعية الناتجة عن الهدف المبهم اكتشافها ما لم تقم بإضافة بعض التعليمات البرمجية يدويًا لاكتشاف ذلك.
كما هو الحال مع أي أداة أخرى من أدوات القوة الغاشمة، يوفر جهاز Fuzzer تغطية محدودة في حالة استخدام التشفير أو المجموع الاختباري أو توقيعات التشفير أو الضغط لتغليف تنسيق البيانات الفعلي المراد اختباره بالكامل.
للتغلب على هذه المشكلة، يمكنك التعليق على عمليات التحقق ذات الصلة (راجع التجريبية/libpng_no_checksum/ للحصول على الإلهام)؛ إذا لم يكن ذلك ممكنًا، فيمكنك أيضًا كتابة معالج لاحق، كما هو موضح في تجريبي/post_library/.
هناك بعض المقايضات المؤسفة مع ASAN والثنائيات 64 بت. هذا لا يرجع إلى أي خطأ محدد في afl-fuzz؛ راجع Notes_for_asan.txt للحصول على النصائح.
لا يوجد دعم مباشر لخدمات الشبكة المبهمة أو برامج الخلفية أو التطبيقات التفاعلية التي تتطلب تفاعل واجهة المستخدم حتى تعمل. قد تحتاج إلى إجراء تغييرات بسيطة على التعليمات البرمجية لجعلها تتصرف بطريقة أكثر تقليدية. قد تقدم Preeny خيارًا بسيطًا نسبيًا أيضًا - راجع: https://github.com/zardus/preeny
يمكن أيضًا العثور على بعض النصائح المفيدة لتعديل الخدمات المستندة إلى الشبكة على: https://www.fastly.com/blog/how-to-fuzz-server-american-fuzzy-lop
لا يقوم AFL بإخراج بيانات تغطية يمكن قراءتها بواسطة الإنسان. إذا كنت تريد مراقبة التغطية، استخدم afl-cov من مايكل راش: https://github.com/mrash/afl-cov
في بعض الأحيان، تثور الآلات الواعية ضد صانعيها. إذا حدث هذا لك، فيرجى الرجوع إلى http://lcamtuf.coredump.cx/prep/.
أبعد من ذلك، راجع التثبيت للحصول على نصائح خاصة بالنظام الأساسي.
العديد من التحسينات على afl-fuzz لن تكون ممكنة بدون تعليقات أو تقارير أخطاء أو تصحيحات من:
Jann Horn Hanno Boeck
Felix Groebert Jakub Wilk
Richard W. M. Jones Alexander Cherepanov
Tom Ritter Hovik Manucharyan
Sebastian Roschke Eberhard Mattes
Padraig Brady Ben Laurie
@dronesec Luca Barbato
Tobias Ospelt Thomas Jarosch
Martin Carpenter Mudge Zatko
Joe Zbiciak Ryan Govostes
Michael Rash William Robinet
Jonathan Gray Filipe Cabecinhas
Nico Weber Jodie Cunningham
Andrew Griffiths Parker Thompson
Jonathan Neuschfer Tyler Nighswander
Ben Nagy Samir Aguiar
Aidan Thornton Aleksandar Nikolich
Sam Hakim Laszlo Szekeres
David A. Wheeler Turo Lamminen
Andreas Stieger Richard Godbee
Louis Dassy teor2345
Alex Moneger Dmitry Vyukov
Keegan McAllister Kostya Serebryany
Richo Healey Martijn Bogaard
rc0r Jonathan Foote
Christian Holler Dominique Pelle
Jacek Wielemborek Leo Barnes
Jeremy Barnes Jeff Trull
Guillaume Endignoux ilovezfs
Daniel Godas-Lopez Franjo Ivancic
Austin Seipp Daniel Komaromy
Daniel Binderman Jonathan Metzman
Vegard Nossum Jan Kneschke
Kurt Roeckx Marcel Bohme
Van-Thuan Pham Abhik Roychoudhury
Joshua J. Drake Toby Hutton
Rene Freingruber Sergey Davidoff
Sami Liedes Craig Young
Andrzej Jackowski Daniel Hodson
شكرًا لك!
أسئلة؟ مخاوف؟ تقارير الأخطاء؟ الرجاء استخدام جيثب.
كما توجد قائمة بريدية للمشروع؛ للانضمام، أرسل بريدًا إلكترونيًا إلى [email protected]. أو، إذا كنت تفضل تصفح الأرشيفات أولاً، فجرّب: https://groups.google.com/group/afl-users.
