خانه » مروری بر فازینگ پروتکل

مروری بر فازینگ پروتکل

A Survey of Protocol Fuzzing

توسط Vulnerlab
101 بازدید
Protocol Fuzzing - فازینگ پروتکل

پروتکل‌های ارتباطی زیربنای جهانِ به‌هم‌پیوستهٔ امروز را تشکیل می‌دهند، اما وجود آسیب‌پذیری در پیاده‌سازی آن‌ها تهدیدات امنیتی مهمی را به همراه دارد. تحولات اخیر نشان‌ دهندهٔ رشد چشمگیر پژوهش‌های مبتنی بر فازینگ برای کشف این آسیب‌پذیری‌ها در پیاده‌سازی پروتکل‌ها است. بااین‌حال، هنوز مرور نظام‌مندی از فازینگ پروتکل (Protocol Fuzzing) ارائه نشده است که بتواند به پرسش‌های اساسی، مانند چالش‌های منحصربه‌فرد این حوزه و شیوهٔ مواجههٔ پژوهش‌های موجود با این چالش‌ها، پاسخ دهد. در راستای پر کردن این خلأ، ما بررسی جامعی از آثار مرتبط در دو حوزهٔ دانشگاه و صنعت انجام داده‌ایم. این مطالعه، ضمن ارائهٔ جمع‌بندی دقیقی از چالش‌های ویژهٔ فازینگ پروتکل، دسته‌بندی و نمایی نظام‌مند از تلاش‌های پژوهشی موجود را نیز فراهم می‌آورد. افزون بر این، مسیرهای بالقوهٔ پژوهش‌های آینده در حوزهٔ فازینگ پروتکل بررسی و بحث شده‌اند. این مقالهٔ مروری می‌تواند به‌ عنوان راهنمایی پایه برای پژوهشگران و دست‌اندرکاران این حوزه عمل کند.

1. مقدمه (INTRODUCTION)

پروتکل‌های ارتباطی، مانند TCP ‏(Transmission Control Protocol) [16]، ‏TLS ‏(Transport Layer Security) [40]، بلوتوث (Bluetooth) [139] و نظایر آن‌ها، با تعریف قواعد تبادل پیام میان طرفین، سنگ‌بنای ارتباطات را تشکیل می‌دهند. ازآنجاکه این پروتکل‌ها زیربنای خدماتی هستند که به‌صورت عمومی در دسترس قرار دارند، امنیت آن‌ها از اهمیتی اساسی برخوردار است و آسیب‌پذیری‌های موجود در آن‌ها می‌تواند پیامدهای بسیار شدیدی به همراه داشته باشد.

نمونه‌ای روشن از این مسئله، آسیب‌پذیری Heartbleed در OpenSSL، به‌ عنوان یکی از پیاده‌سازی‌های پروتکل TLS است. پس از افشای این آسیب‌پذیری، مشخص شد که Heartbleed بیش از ۱۷٪ از سرورهای سراسر جهان را تحت تأثیر قرار داده است [105, 119, 155]؛ موضوعی که نشان می‌دهد یک آسیب‌پذیری واحد تا چه اندازه می‌تواند اثرگذاری گسترده‌ای داشته باشد. افزون بر این، تحلیل‌های آماری اخیر از روندی صعودی در آسیب‌پذیری‌های نرم‌افزاری پرخطر در خدمات شبکه حکایت دارند [62] که این امر بر افزایش مخاطرات امنیت شبکه تأکید می‌کند. با توجه به این شرایط، توسعهٔ روش‌های خودکار برای کشف آسیب‌پذیری‌ها در پیاده‌سازی پروتکل‌های شبکه نه‌ تنها سودمند، بلکه برای حفاظت از خدمات نوین شبکه کاملاً ضروری است.

فازینگ، به‌ عنوان یکی از روش‌های آزمون نرم‌افزار، نخستین‌بار با مطالعهٔ تجربی Miller و همکاران در سال ۱۹۹۰ [103] به‌طور جدی مطرح شد. این روش مبتنی بر تولید شمار زیادی از موارد آزمون تصادفی یا جهش‌یافته است که با هدف برانگیختن رفتارهای اجرایی غیرعادی در یک برنامهٔ نرم‌افزاری ایجاد می‌شوند. فازینگ به‌ سبب سادگی و مقیاس‌پذیری خود، در کشف طیف گسترده‌ای از باگ‌ها بسیار مؤثر بوده و در نتیجه، به‌طور گسترده مورد پذیرش قرار گرفته است [41, 82–85, 94, 176–179, 182, 184].

با این‌حال، فازینگِ پیاده‌سازی‌های پروتکلی، در مقایسه با نرم‌افزارهای عمومی مانند ابزارهای خط فرمان [97, 117, 161]، چالش‌های مضاعفی را به همراه دارد. این پیچیدگی‌ها عمدتاً ناشی از ویژگی‌های خاص آزمون مؤثر منطق ارتباطیِ پیچیده‌ای است که پروتکل‌ها دربر دارند؛ منطق‌هایی که از ملاحظات روش‌شناختی گرفته تا نیازمندی‌های خاص ابزارها را شامل می‌شوند. در پاسخ به این چالش‌ها، گرایشی قابل‌توجه به‌سوی طراحی روش‌های پیشرفتهٔ فازینگ که به‌طور مشخص برای آزمون پروتکل‌ها توسعه یافته‌اند، شکل گرفته است [15, 18, 39, 53, 55, 89, 100, 116, 142]. با وجود این پیشرفت‌ها، هنوز خلأیی جدی در پژوهش‌هایی وجود دارد که به‌صورت نظام‌مند چالش‌های متمایز این حوزه را بررسی کنند، راه‌حل‌های موجود را به‌طور جامع جمع‌بندی نمایند و جهت‌گیری‌های آینده را مورد بحث قرار دهند. برای پر کردن این خلأ، ما در ادامهٔ این مقاله، به‌ تفصیل ویژگی‌ها و ملاحظات خاص فازینگ پروتکل را بررسی و تحلیل کرده‌ایم.

   ۱.۱ انگیزه (Motivation)

انگیزه‌های اصلی این مقالهٔ مروری به شرح زیر است:

  • پروتکل‌ها مجموعه قواعد بنیادینی هستند که چگونگی برقراری ارتباط میان دستگاه‌ها و کاربردهای ما را تعیین می‌کنند؛ ازاین‌رو، هم حضوری فراگیر دارند و هم از اهمیتی حیاتی برخوردارند. از آنجا که این پروتکل‌ها در همه‌جا حضور دارند، اطمینان از امنیت آن‌ها در برابر تهدیدات بالقوه، امری بسیار مهم است. فازینگ نقشی کلیدی در شناسایی و رفع مسائل امنیتی در این سامانه‌ها ایفا می‌کند. با توجه به این موضوع، تدوین نخستین راهنمای سرتاسری که هم نمای کلی و هم جزئیات اختصاصی فازینگ پروتکل را پوشش دهد، برای پژوهشگران و نیز فعالان صنعت فناوری ارزش فراوانی دارد.
  • فازینگ پروتکل با چالش‌های منحصربه‌فردی همراه است که آن را از فازینگ کاربردهای عمومی متمایز می‌سازد؛ چالش‌هایی که ریشه در پیچیدگی‌های خودِ پروتکل‌های ارتباطی دارند. نخست، لازم است قواعد سخت‌گیرانه‌ای رعایت شوند که نه‌تنها ساختار پیام‌ها، بلکه ترتیب دقیق و زمینه‌ای را که این پیام‌ها در آن ارسال و دریافت می‌شوند نیز تعیین می‌کنند [1, 2, 40, 126]. این امر فرایند آزمون را پیچیده می‌کند، زیرا مستلزم درکی عمیق از نحوهٔ کارکرد این پروتکل‌های ارتباطی و تغییرات آن‌ها در گذر زمان است. دوم، پروتکل‌ها صرفاً برای تبادل سادهٔ پیام طراحی نشده‌اند، بلکه باید ویژگی‌های گوناگونی را نیز پوشش دهند. برای مثال، آن‌ها باید عواملی مانند زمان‌بندی و نحوهٔ وقوع هم‌زمان چندین پیام یا کنش را نیز در نظر بگیرند؛ موضوعی که هنگام آزمون مسائل امنیتی، متغیرهای بیشتری را وارد فرایند می‌کند [68, 73, 75]. سوم، کاربرد گستردهٔ پروتکل‌ها در سطوح مختلف فناوری و سامانه‌های گوناگون، لایهٔ دیگری از پیچیدگی را ایجاد می‌کند. این پروتکل‌ها در همه‌جا، از سخت‌افزار تا نرم‌افزارهای کاربردی‌ای که روزانه با آن‌ها سروکار داریم، به‌کار گرفته شده‌اند و همین امر به سناریوهای آزمون متنوع و امکان کشف آسیب‌پذیری‌های بالقوه در هر لایه می‌انجامد [46, 53, 55, 56, 91, 130, 165]. با توجه به این واقعیت‌ها، دستیابی به درکی جامع از چالش‌های اختصاصی فازینگ پروتکل ضرورتی انکارناپذیر است.
  • با وجود آن‌که آثار متعددی در زمینهٔ فازینگ پروتکل منتشر شده‌اند، تاکنون هیچ مرور نظام‌مندی دربارهٔ فازینگ پروتکل انجام نشده است. هرچند برخی مقالات مروری [85, 94, 185] دربارهٔ فازینگ سنتی نرم‌افزار در دسترس‌اند، این آثار نمی‌توانند بر پایهٔ پژوهش‌های موجودی که به حل چالش‌های اختصاصی پروتکل پرداخته‌اند، تصویری نظام‌مند از وضعیت کنونی و جهت‌گیری‌های آیندهٔ این حوزه ارائه دهند.

جدول ۱. کنفرانس‌ها و مجلات تأثیرگذار منتخب

حوزه تحقیقاتی

نوع

نام

امنیت سایبری

کنفرانس‌ها

ACSAC, CCS, CODASPY, DSN, ICDCS, ICICS, NDSS, SP, USENIX, WiSec, Black Hat, DEFCON, RSA

مجلات

TDSC, TIFS

معماری سیستم

کنفرانس‌ها

ASPLOS, ATC, DAC, Eurosys, Mobisys, OSDI

مجلات

TC

ارتباطات

کنفرانس‌ها

INFOCOM, MobiCOM, NSDI, SIGCOMM

مجلات

TMC, TNSM, TON

مهندسی نرم‌افزار

کنفرانس‌ها

ASE, FSE, ICSE, ICST, ISSTA

مجلات

TOSEM, TSE

Protocol Fuzzing - فازینگ پروتکل
شکل ۱. معیارهای جستجو
شکل ۲. توزیع مقالات بر اساس سال‌های انتشار

   ۱.۲ پرسش‌های پژوهشی (Research Questions)

این مرور با هدف ارائهٔ تصویری کلی از چالش‌های اختصاصی فازینگ پروتکل، راهکارهای موجود برای مواجهه با آن‌ها و نیز مسیرهای آیندهٔ این حوزه انجام شده است. به‌طور مشخص، این مقاله به پرسش‌های زیر پاسخ می‌دهد:

RQ1: فازینگ سنتی و فازینگ پروتکل چه تفاوت‌هایی با یکدیگر دارند؟
RQ2: پژوهش‌های موجود چگونه چالش‌های فازینگ پروتکل را برطرف کرده‌اند؟
RQ3: مسیرهای بالقوهٔ آینده در این حوزه چه هستند؟

در بخش ۳، برای پاسخ به پرسش نخست، تفاوت‌های اساسی میان پروتکل‌ها و اهداف متداول فازینگ را به‌طور عمیق بررسی می‌کنیم. سپس در بخش‌های ۴ تا ۶، برای پاسخ به پرسش دوم، تکنیک‌ها و روش‌های مورد استفاده در فازرهای پروتکلی موجود را با جزئیات شرح می‌دهیم. در نهایت، پرسش سوم در بخش ۷ مورد بحث قرار می‌گیرد.   

   ۱.۳ استراتژی گردآوری منابع (Collection Strategy)

در این مرور، تمرکز ما بر پروتکل‌های شبکه حالت‌دار و تکنیک‌های مختلف مرتبط با فازینگ پیاده‌سازی‌های آن‌ها است. برای جمع‌آوری آثار مرتبط، مراحل زیر را که در شکل ۱ نمایش داده شده است، دنبال کردیم:

ابتدا یک مطالعهٔ مقدماتی انجام دادیم و ۱۲ ترکیب کلیدی واژه را برای جستجوی آثار مرتبط خلاصه کردیم. سپس با جستجوی این ترکیب‌های کلیدی در Google Scholar، ۵۳۵ مقاله منتشرشده بین سال‌های ۲۰۱۳ تا ۲۰۲۳ جمع‌آوری شد. پس از آن، به‌صورت دستی، مقالات غیرمرتبط با فازینگ پروتکل یا منتشرنشده در منابع مؤثر جدول ۱ را حذف کردیم. در این مرحله، تعداد مقالات به ۷۸ مقاله کاهش یافت. لازم به ذکر است که تمامی مقالات پیش‌چاپ حفظ شدند تا سوگیری ناشی از انتشار حذف شود [169].

یک مقاله زمانی مرتبط محسوب می‌شود که مشارکت کلیدی آن در حوزهٔ فازینگ پروتکل باشد یا این‌که ابزاری برای شناسایی باگ باشد و حداقل یک پیاده‌سازی پروتکل را به‌عنوان هدف ارزیابی خود انتخاب کرده باشد. معیار دوم مبتنی بر این فرض است که اگر یک ابزار شناسایی باگ از پیاده‌سازی‌های پروتکل برای ارزیابی استفاده کند، احتمالاً تکنیک‌های اختصاصی پروتکل نیز پیشنهاد داده است.

سپس، برای دستیابی به نمایی جامع‌تر، روش‌های Snowballing و Inverse Snowballing به‌کار گرفته شد و شش مقالهٔ جدید در این مرحله افزوده شدند. در نهایت، همین فرآیند گردآوری بر سخنرانی‌های منتشرشده در چندین کنفرانس امنیت صنعتی مطرح مانند BlackHat اعمال شد. ۲۱ اثر صنعتی اضافه شدند، شامل ۱۸ سخنرانی مرتبط و سه فازر پروتکل متن‌باز با بیش از ۵۰ ستاره در GitHub. روند صعودی انتشار مقالات، همان‌طور که در شکل ۲ نمایش داده شده، نشان‌دهندهٔ افزایش علاقهٔ پژوهشی به فازینگ پروتکل است و جایگاه آن را به‌عنوان یک محور مهم در این حوزه تأیید می‌کند.

سازماندهی ادامهٔ مقاله به شرح زیر است:

  • بخش ۲: معرفی دانش پس‌زمینهٔ فازینگ پروتکل.
  • بخش ۳: بررسی تفاوت‌های اصلی میان اهداف عمومی فازینگ و پروتکل‌ها و جمع‌بندی بهبودهای عمده فازرهای پروتکل موجود.
  • بخش‌های ۴ تا ۶: شرح تکنیک‌های موجود برای هر مؤلفهٔ کلیدی فازینگ پروتکل:
    • بخش ۴: پیشرفت‌ها در مؤلفهٔ تولیدکنندهٔ ورودی (Input Generator).
    • بخش ۵: تکنیک‌های بهبود مؤلفهٔ اجراکننده (Executor).
    • بخش ۶: دسته‌بندی اوراکل‌های به‌کاررفته در مؤلفهٔ شناسایی باگ (Bug Detector).
  • بخش ۷: ارائهٔ مسیرهای پژوهشی آینده.

۲. پیش زمینه (BACKGROUND)

   ۲.۱ پروتکل‌های ارتباطی (Communication Protocols)

یک پروتکل ارتباطی مجموعه‌ای از قواعد است که امکان تبادل اطلاعات بین دو یا چند موجودیت در یک سیستم ارتباطی را فراهم می‌کند و می‌تواند از هر نوع تغییر کمیت فیزیکی برای انتقال داده استفاده کند. پیاده‌سازی یک پروتکل ارتباطی معمولاً شامل چندین مرحله است [35]:

  1. مرحلهٔ طراحی مفهومی: در این مرحله، پروتکل به‌صورت نظری طراحی می‌شود و شامل تعریف قواعد، رفتارها و عملکردهایی است که بر اساس نیازهای پروتکل انجام خواهد شد. عواملی مانند کارایی، قابلیت اعتماد، مقیاس‌پذیری و امنیت نیز در این مرحله در نظر گرفته می‌شوند. نتیجهٔ این مرحله، یک مشخصات (Specification) است.
  2. مرحلهٔ توسعه: در این مرحله، طراحی پروتکل به پیاده‌سازی‌های واقعی تبدیل می‌شود که می‌تواند نرم‌افزاری، سخت‌افزاری یا ترکیبی از هر دو باشد.
  3. مرحلهٔ آزمون: پس از توسعه، پروتکل تحت آزمون‌های دقیق قرار می‌گیرد تا اطمینان حاصل شود که با مشخصات تعریف‌شده مطابقت دارد و نیازمندی‌های عملکرد و قابلیت اعتماد را برآورده می‌کند. در این میان، فازینگ که موضوع اصلی این مقاله است، یکی از تکنیک‌های رایج برای آزمون پیاده‌سازی‌های پروتکل محسوب می‌شود.
  4. مرحلهٔ استقرار: در نهایت، پیاده‌سازی پروتکل در یک محیط واقعی به‌کار گرفته می‌شود.

علاوه بر وظیفهٔ اصلی تبادل داده، پروتکل‌ها شامل کارکردهای متنوع دیگری نیز هستند که برای برقراری ارتباط حیاتی‌اند و لایه‌های جدیدی از پیچیدگی را ایجاد می‌کنند [96]. این کارکردها شامل مسائلی مانند مسیر‌یابی، شناسایی خطاهای انتقال، مدیریت تایم‌اوت و تکرار پیام‌ها، تأیید دریافت، کنترل جریان و کنترل ترتیب پیام‌ها می‌شوند. به‌عنوان مثال، TCP (Transmission Control Protocol) [16] شامل عملکردهایی است که به تضمین ارتباط بهینه کمک می‌کنند:

  • تأیید دریافت (Acknowledgment): تأیید، مکانیزمی برای اطمینان از دریافت بسته‌های داده است. این فرایند برای تضمین قابلیت اعتماد انتقال داده حیاتی است، زیرا به فرستنده امکان می‌دهد بداند داده‌ها به مقصد موردنظر رسیده‌اند یا خیر. در TCP، وقتی یک بستهٔ داده دریافت می‌شود، گیرنده یک پیام تأیید دریافت به فرستنده ارسال می‌کند تا دریافت بسته را تأیید کند.
Protocol Fuzzing - فازینگ پروتکل
شکل ۳. انواع پروتکل‌ها
  • کنترل قطعه (Sequence Control):کنترل ترتیب تضمین می‌کند که بسته‌های داده به همان ترتیبی که ارسال شده‌اند دریافت و پردازش شوند. در TCP، هر قطعه (segment) با یک شمارهٔ توالی (Sequence Number) برچسب‌گذاری می‌شود.
  • مدیریت خطا (Error Handling): مدیریت خطا شامل شناسایی و اصلاح خطاهایی است که در طول انتقال داده رخ می‌دهند. TCP دارای قابلیت‌های بررسی خطا است. هر بخش (segment) در TCP یک فیلد جمع‌آزما (Checksum) دارد که برای بررسی یکپارچگی داده استفاده می‌شود. اگر مشخص شود که یک بخش خراب شده است (یعنی داده‌ها با جمع‌آزما مطابقت ندارند)، آن بخش دور انداخته می‌شود و TCP فرایند ارسال مجدد را انجام می‌دهد.

هر یک از این کارکردها مجموعه‌ای از استراتژی‌ها و پیاده‌سازی‌ها را در خود جای داده‌اند که به‌صورت جمعی اثربخشی و قابلیت اعتماد پروتکل‌های ارتباطی را تضمین می‌کنند. یکپارچگی پیچیدهٔ این عملکردها نشان‌دهندهٔ ماهیت پیشرفتهٔ طراحی پروتکل‌ها و نقش محوری آن‌ها در سیستم‌های ارتباطی مدرن است.

   ۲.۲ انواع پروتکل‌ها (Types of Protocols)

پروتکل‌ها می‌توانند از جنبه‌های مختلفی دسته‌بندی شوند، مانند کارکرد، دسترس‌پذیری مشخصات آن‌ها و تطابق آن‌ها با لایه‌های مدل مرجع شبکه OSI. از دیدگاه کارکردی، پروتکل‌ها طیف گسترده‌ای از انواع را شامل می‌شوند که هر کدام برای تحقق اهداف عملیاتی خاص طراحی شده‌اند. برای مثال:

  • پروتکل‌های امنیتی عمدتاً برای تضمین یکپارچگی و محرمانگی داده‌ها طراحی شده‌اند، مانند TLS [40] و DTLS (Datagram Transport Layer Security) [126].
  • پروتکل‌های مسیریابی، مانند BGP (Border Gateway Protocol)، برای مدیریت کارآمد مسیرهایی که بسته‌های داده در شبکه طی می‌کنند اختصاص یافته‌اند.
  • پروتکل‌های کاربردی، مانند HTTP (Hypertext Transfer Protocol) برای خدمات وب و SMTP (Simple Mail Transfer Protocol) برای ایمیل، به منظور فعالیت‌های خاص در لایهٔ کاربرد طراحی شده‌اند.

با توجه به دسترس‌پذیری مشخصات پروتکل‌ها، تفاوتی میان پروتکل‌های باز (Open Protocols) و پروتکل‌های اختصاصی (Proprietary Protocols) وجود دارد. پروتکل‌های باز، مانند TCP، دارای مشخصات عمومی و قابل دسترسی هستند که امکان بررسی و پیاده‌سازی گسترده را فراهم می‌آورد. در مقابل، پروتکل‌های اختصاصی، مانند RDP (Remote Desktop Protocol) [102] مایکروسافت، تحت کنترل یک نهاد خاص هستند و مشخصات آن‌ها به‌طور کامل عمومی نیست.

دسترس‌پذیری مشخصات پروتکل، برای مراحل مختلف فازینگ اهمیت دارد؛ از جمله ساخت ورودی‌ها، طراحی ماشین‌های حالت، و شناسایی باگ‌ها. نکته مهم آن است که دسته‌بندی پروتکل‌ها به باز یا اختصاصی صرفاً مربوط به دسترس‌پذیری مشخصات است و مستقل از دسترسی به کد منبع پیاده‌سازی پروتکل‌ها می‌باشد.

جدول ۲- مقایسه بین هدف فازینگ سنتی و پروتکل

 

پیاده‌سازی پروتکل

اهداف فازینگ عمومی

پیچیدگی ارتباطات

بالا

پایین

محیط آزمایش

محدود

نامحدود

با توجه به وضعیت پذیری (Statefulness)، پروتکل‌ها به دو دستهٔ وضعیت‌مند (Stateful) و بدون وضعیت (Stateless) تقسیم می‌شوند. پروتکل‌های وضعیت‌مند، مانند TLS [39, 142] و TCP [69]، نیازمند چندین دور تعامل هستند تا ارتباط برقرار شود اما پروتکل‌های بدون وضعیت، مانند UDP و HTTP، اطلاعات وضعیت را بین درخواست‌ها حفظ نمی‌کنند.

بر اساس مدل مرجع شبکه OSI، پروتکل‌ها می‌توانند در هفت لایهٔ متمایز دسته‌بندی شوند: لایه فیزیکی (physical)، پیوند داده (data link)، شبکه (network)، انتقال (transport)، نشست (session)، ارائه (presentation) و کاربرد (application). هر لایه از پروتکل‌ها مسئلهٔ خاصی از ارتباطات را حل (solve) می‌کند و پروتکل‌های سطوح پایین‌تر با سخت‌افزار فیزیکی ارتباط بیشتری دارند.

شایان ذکر است که همهٔ پروتکل‌ها دقیقاً با یک لایهٔ واحد OSI هم‌تراز نیستند. به‌عنوان مثال TLS/DTLS شامل عملکردهای لایهٔ نشست و ارائه است و پروتکل Wi-Fi شامل عملکرد اصلی لایه‌های فیزیکی و پیوند داده است [2, 28]. با توجه به تفسیرهای متفاوت از لایه‌بندی پروتکل‌ها در منابع متعدد، ما این پروتکل‌ها را بر اساس عملکرد اصلی آن‌ها دسته‌بندی می‌کنیم.

۳. مروری بر فازینگ پروتکل‌ها (PROTOCOL FUZZING OVERVIEW)

   ۳.۱ تفاوت‌های فازینگ پروتکل و فازینگ سنتی (Differences between protocol fuzzing and traditional fuzzing)

در این زیر بخش، به چالش‌های منحصربه‌فرد فازینگ پروتکل که در متون علمی شناسایی شده‌اند می‌پردازیم و به پرسش پژوهشی RQ1 پاسخ می‌دهیم. جدول ۲ دو تفاوت اصلی میان پیاده‌سازی‌های پروتکل و اهداف عمومی فازینگ را خلاصه کرده است. این تفاوت‌ها نه تنها ویژگی‌های خاص فازینگ پروتکل را برجسته می‌کنند، بلکه مجموعه‌ای از چالش‌های ذاتی را نیز نشان می‌دهند.

      ۳.۱.۱ پیچیدگی بالای ارتباطات (High communication complexity)

پیچیدگی بالای ارتباطات را می‌توان از دو جنبه بررسی کرد:

رعایت محدودیت‌های معنایی در ارتباطات (Semantic Constraints). پروتکل‌ها به‌عنوان ستون فقرات ارتباط میان سیستم‌های مختلف عمل می‌کنند و مجموعه‌ای استاندارد از قواعد برای تبادل پیام ارائه می‌دهند. این ارتباط ذاتاً پیچیده است و اغلب شامل فرایند چند دوری می‌شود که در آن چندین مرحله باید به ترتیب اجرا شوند تا تبادل موفقیت‌آمیز باشد. چنین پروتکل‌هایی مستلزم پیاده‌سازی‌های وضعیت‌مند (Stateful)  هستند، به‌ گونه‌ای که هر مرحلهٔ ارتباط بر مرحلهٔ قبلی بنا می‌شود [1, 2, 40, 126].

در سناریوهای آزمون، این بدان معناست که لایه‌های عمیق‌تر پیاده‌سازی پروتکل تا زمانی که محدودیت‌های اولیه به‌طور رضایت‌بخش رعایت نشده باشند، قابل آزمایش نیستند – این محدودیت‌ها همان محدودیت‌های معنایی سخت‌گیرانه در پروتکل‌های ارتباطی هستند. محدودیت‌های معنایی به دو شکل اصلی وجود دارند. محدودیت اول، محدودیت‌های درون‌پیامی (Intra-message) که مربوط به ساختار و محتوای پیام‌های منفرد هستند و تضمین می‌کنند که فیلدهای داده به لحاظ نحوی صحیح و از نظر معنایی در چارچوب آن پیام معتبر باشند. برای مثال، در TCP، هر بخش (segment) شامل فیلدهای حیاتی‌ای مانند پورت مبدأ، پورت مقصد، شماره ترتیب، شماره تأیید دریافت، offset داده و فلگ‌های کنترلی(مانند SYN و ACK) است [96]. هر یک از این فیلدها باید قالب و قواعد خاصی را رعایت کنند. محدودیت دوم، محدودیت‌های بین‌پیامی (Inter-message) است. این محدودیت‌ها روابط و ترتیب چندین پیام را کنترل می‌کنند و می‌طلبند که پیام‌ها با ترتیب و زمینهٔ تعریف‌شده در پروتکل مطابقت داشته باشند تا مکالمه پیش رود [35]. برای مثال، برقراری اتصال TCP شامل فرایند دست تکانی (handshake) سه‌مرحله‌ای است: (۱) کلاینت یک پیام SYN ارسال می‌کند. (۲) سرور با پیام SYN-ACK پاسخ می‌دهد و (۳) کلاینت پیام ACK را ارسال می‌کند تا اتصال کامل شود. نقض هر یک از این محدودیت‌ها در طول ارتباط می‌تواند منجر به عدم پیشرفت فازینگ (non-progressive fuzzing) شود [69, 116, 142, 158, 187].

آزمون ویژگی‌های مختلف فرایند ارتباطی. علاوه بر وظیفهٔ اصلی تبادل پیام، پروتکل‌ها باید مجموعه‌ای از ویژگی‌های اضافی را نیز تضمین کنند تا ارتباط ایمن‌تر و قابل اعتمادتر باشد؛ از جمله نیازمندی‌های زمانی، احراز هویت، محرمانگی و هم‌زمانی (Concurrency) [68, 73, 75]. آزمون مؤثر این ویژگی‌ها در پیاده‌سازی‌ها نیازمند فرم پیچیده‌تری از تست است که فراتر از فازینگ معمول برنامه‌های کاربردی است، زیرا فازینگ معمول بیشتر بر تغییر ورودی‌های ساختاریافته برای کشف مشکلات تمرکز دارد [94, 185]. هر ویژگی ممکن است نیازمند تغییرات اساسی یا حتی طراحی مجدد فریم‌ورک فازینگ باشد، از جمله توسعهٔ تولیدکنندهٔ ورودی تخصصی، مکانیزم‌های بازخورد و اوراکل‌ها برای تسهیل آزمون مؤثر [31, 56, 66, 72, 92, 99, 138, 142, 158, 187]. برای مثال، در زمینهٔ طراحی یک فازر برای شناسایی حملات افزایش ترافیک (Traffic Amplification) در پیاده‌سازی‌های پروتکل [78] یک اوراکل لازم است تا نسبت حجم دادهٔ درخواست به پاسخ را شناسایی کند، که نشان‌دهندهٔ عامل افزایش (Amplification Factor) است. هم‌زمان، تولیدکنندهٔ ورودی باید به‌طور دقیق نسخه‌های خاصی از پیام‌های پروتکل را تولید کند تا حداکثر مقدار عامل افزایش ممکن ایجاد شود. علاوه بر این، عامل افزایش می‌تواند به‌عنوان مکانیزم بازخورد برای بهبود عملکرد جستجوی فازینگ استفاده شود. این مثال نشان می‌دهد که آزمون ویژگی‌های اضافی ارتباطات در فازینگ پروتکل، نیازمند سازمان‌دهی پیشرفته و توسعه ابزارهای تخصصی است تا بتواند مؤثر و کارآمد عمل کند.

      ۳.۱.۲ محیط آزمون محدود (Constrained Testing Environment)

فازینگ پروتکل معمولاً با محدودیت‌هایی در محیط آزمون مواجه است که ناشی از وابستگی نزدیک پروتکل‌ها به سخت‌افزار می‌باشد.

ابتدا، بسیاری از پروتکل‌ها یا برای ارتباط میان دستگاه‌های سطح پایین فیزیکی طراحی شده‌اند، یا برای ارتباطات در حوزه‌های تخصصی مانند پروتکل‌های موجود در لایه‌های پایین مدل مرجع OSI، یعنی لایه‌های فیزیکی و پیوند داده [1, 2, 5, 28, 139]، یا پروتکل‌هایی که برای صنایع خاص طراحی شده‌اند، مانند خودرو [14, 109, 189]، سیستم‌های کنترل صنعتی (ICS) [21, 181]، شبکه‌های برق و سامانه‌های هوانوردی. در چنین مواردی، توان عملیاتی آزمون محدود می‌شود، که ناشی از وابستگی به سخت‌افزار است، مانند کمبود خودکارسازی [113, 145] و گلوگاه در فازینگ مقیاس‌پذیر [21, 130].

علاوه بر این، این وابستگی‌های سخت‌افزاری استفاده از تکنیک‌های پیشرفتهٔ فازینگ را نیز محدود می‌کنند. بسیاری از تکنیک‌های پیشرفتهٔ فازینگ نیازمند اطلاعات جعبه خاکستری (greybox) یا جعبه سفید (whitebox) ‌از هدف آزمون هستند، اما در این سخت‌افزارهای خاص، چارچوب‌های تحلیل برنامه در دسترس نیستند و بنابراین امکان استفاده از این تکنیک‌ها فراهم نمی‌شود [133, 188, 189]. این محدودیت‌ها نشان می‌دهند که پیاده‌سازی فازینگ پروتکل در محیط‌های سخت‌افزاری تخصصی، چالش‌های عملی و تکنیکی قابل توجهی دارد که فراتر از فازینگ نرم‌افزارهای عمومی است.

   ۳.۲ خلاصه‌ای از فازرهای پروتکل موجود (Summary of Existing Protocol Fuzzers)

ما پژوهش‌های جاری در حوزهٔ فازینگ پروتکل را تحلیل کرده و تلاش‌های انجام‌شده را در قالب یک چارچوب فنی برای فازرهای پروتکل خلاصه کرده‌ایم، همان‌طور که در شکل ۴ نشان داده شده است. لازم به ذکر است که آثار فازینگ موجود همچنان مفاهیم سطح بالا فازینگ عمومی را دنبال می‌کنند، اما بهبودهای خاصی در زیرمؤلفه‌ها ارائه می‌دهند تا چالش‌های اختصاصی پروتکل را حل کنند. در این بخش، ابتدا به مفاهیم و کارکردهای کلی این مؤلفه‌ها می‌پردازیم و سپس در بخش‌های بعدی (بخش‌های ۴ تا ۶) بهبودهای خاص ارائه‌ شده توسط پژوهش‌های موجود را با جزئیات شرح می‌دهیم.

یک فازر عمومی از سه مؤلفهٔ اساسی تشکیل شده است:

  1. تولیدکنندهٔ ورودی (Input Generator)
  2. اجراکننده (Executor)
  3. جمع‌آورندهٔ باگ (Bug Collector)

در یک دورهٔ اجرای فازینگ:

  1. تولیدکنندهٔ ورودی ابتدا یک ورودی آزمون تولید می‌کند و آن را به اجراکننده می‌فرستد.
  2. اجراکننده، برنامه تحت آزمون (PUT) را با ورودی داده‌ شده اجرا می‌کند و اطلاعات زمان اجرا را برای دو مؤلفهٔ دیگر جمع‌آوری می‌کند.
  3. در نهایت، جمع‌آورندهٔ باگ، اطلاعات زمان اجرا را بررسی می‌کند تا مشخص شود آیا ورودی یک باگ را فعال کرده است یا خیر.

تولیدکنندهٔ ورودی (Input Generator). این مؤلفه به‌صورت ایده‌آل مسئول تولید ورودی‌هایی است که بتوانند آسیب‌پذیری‌های موجود در PUT را تا حد امکان آشکار کنند. برای دستیابی به این هدف، فازرهای پروتکل معمولاً مولد ورودی را با سه زیرمرحلهٔ اصلی پیاده‌سازی می‌کنند:

  1. ساخت مدل ارتباطی (Communication Model Construction):
    این مرحله مسئول یادگیری محدودیت‌های معنایی پروتکل است و دانش لازم برای سایر مراحل را فراهم می‌کند.
  2. زمان‌بندی (Scheduling):
    با بهره‌گیری از دانش حوزهٔ پروتکل، این مرحله تمام پیکربندی‌های زمان‌بندی مورد استفاده در دورهٔ بعدی تولید ورودی را مشخص می‌کند تا آسیب‌پذیری‌های بیشتری آشکار شود.
  3. ساخت موارد آزمون (Testcase Construction):
    این مرحله مسئول تولید موارد آزمون طبق دستورالعمل‌های زمان‌بندی‌کننده است تا ورودی‌ها آمادهٔ اجرا در PUT شوند.
 
 

 

 

فازرهای پروتکل
شکل ۴. جریان‌کار خلاصه‌شدهٔ فازرهای پروتکل موجود

اجراکننده (Executor). در تلاش برای طراحی یک اجراکنندهٔ ایده‌آل برای فازینگ پروتکل، پژوهش‌های معاصر بر دو جنبهٔ حیاتی تمرکز کرده‌اند:

  1. اجرای کارآمد (Efficient Execution): این بخش به توسعهٔ محیط آزمون کارآمد، خودکار و مقیاس‌پذیر می‌پردازد تا اجرای تست‌های پروتکل بهینه شود.
  2. استخراج اطلاعات زمان اجرا (Runtime Information Extraction): این جنبه تمرکز دارد بر ایجاد محیط تحلیل که اطلاعات ضروری زمان اجرا را استخراج کند و به این ترتیب فرآیند تولید ورودی و شناسایی باگ‌ها را مطلع و بهبود بخشد.

جمع‌آورندهٔ باگ (Bug Collector). هدف اصلی مؤلفهٔ جمع‌آورندهٔ باگ، افزایش تنوع انواع باگ‌های شناسایی‌ شده و دقت این شناسایی‌ها است. این مؤلفه به‌دقت تنظیم شده تا طیف گسترده‌ای از آسیب‌پذیری‌ها را شناسایی کند، از جمله باگ‌های حافظه‌ای (Memory-safety bugs) مانند Overflow  بافر و باگ‌های غیرحافظه‌ای (Non-memory-safety bugs) مانند خطاهای منطقی و نقض مشخصات پروتکل. این طراحی جامع موجب می‌شود که فازرهای پروتکل بتوانند نه تنها باگ‌های واضح، بلکه آسیب‌پذیری‌های ظریف و پنهان را نیز کشف کنند.

۴.  مولد ورودی (Input Generator)

در این بخش، به‌طور مفصل توضیح می‌دهیم که پژوهش‌های موجود چگونه تولیدکنندهٔ ورودی را برای مواجهه با چالش‌های منحصربه‌فرد فازینگ پروتکل بهبود داده‌اند. همان‌طور که در جدول ۳ نشان داده شده است، ما تکنیک‌هایی را که آثار موجود برای طراحی سه فاز کلیدیِ تولیدکنندهٔ ورودی به‌کار گرفته‌اند، جمع‌بندی کرده‌ایم.

آثار پوشش‌داده‌ شده در این بخش از میان مجموعه مقالات ما انتخاب شده‌اند؛ مشروط بر اینکه فنون اصلی آن‌ها مستقیماً به مؤلفهٔ مولد ورودی مرتبط باشد. افزون بر آمار مربوط به این سه فاز در این آثار، جدول همچنین اطلاعات بازخوردی (Feedback Information) مورد استفاده در آن‌ها را نیز فهرست می‌کند.

بر اساس شکل ۴، این اطلاعات بازخوردی می‌تواند از سوی اجراکننده (Executor) یا جمع‌آورندهٔ باگ (Bug Collector) فراهم شود. در این بخش، فقط به این می‌پردازیم که اطلاعات بازخوردی چگونه در تولیدکنندهٔ ورودی به‌کار گرفته می‌شود؛ اما جزئیات مربوط به گردآوری این بازخوردها را به بخش ۵.۲ موکول می‌کنیم.

جدول ۳- فازرهای پروتکل و راه‌حل‌های بهینه‌سازی آنها که در مولد ورودی استفاده می‌شوند.

 
 

 

 

Years

Work

Tax

Target

Comm Model Construction

Scheduling

Construction Level

Feedback

2013

BED [145]

General

Manual

Sequential

P

State

2013

Tsankov et al. [168]

General

Manual

 

P & S

 

2014

Peach [41]

General

Manual

Sequential

P

State

2015

Pulsar [57]

General

TAPL

SCHS

P

State

2015

Beurdouche et al. [18]

TLS

Manual

Random

S

State

2015

Ruiter et al. [39]

TLS

TAAL

Random

S

State

2016

TLS-Attacker [153]

TLS

Manual

Random

P & S

 

2016

Driller [158]

 

General

 

SPMS

P

Code Cov

2017

Fan et al. [44]

General

TAPL

 

P & S

 

2017

WiFuzz et al. [169]

Wi-Fi

Manual

Sequential

P & S

 

2018

TCPWN [69]

TCP

Manual

Sequential

P & S

State

2018

IoTFuzzer [28]

IoT [113, 146]

  

P

 

2018

Danial et al. [38]

OpenVPN [116]

Manual

Random

S

 

2018

DELTA [80]

OpenFlow [50]

Manual

 

P & S

 

2019

SeqFuzzer [194]

ICS

TAPL

 

P

State

2019

Polar [91]

ICS

 

SPMS

P

Code Cov

2019

IoTHunter [184]

IoT

TAAL

Sequential

P

Code Cov

2019

MoSSOT [149]

SSO [60]

Manual

Sequential

P & GUI Ops

 

2019

Chen et al. [30]

General

 

SPHS

P

State & Code Cov

2019

Fuzzowski [136]

General

Manual

 

P

State & Code Cov

2020

Exploiting Dissent [170]

TLS

 

Random

P

 

2020

DTLS-Fuzzer [47, 48]

DTLS

TAAL

Random

S

State

2020

AFLNET [123]

General

TAAL

SRHS

P

State & Code Cov

2020

SweynTooth [56]

BLE [150]

Manual

SPHS

P & S

State & # of Bugs

2020

Frankenstein [138]

Bluetooth

Manual

Random

P & S

State & Code Cov

2020

Peach* [92]

ICS

  

P

Code Cov

2020

aBBRate [122]

TCP

Manual

Sequential

S

State

2020

IJON [12]

General

PAL

Random

P

State & Code Cov

2020

FuSeBMC [6]

 

General

 

Sequential

P

Code Cov

2020

DPIFuzz [131]

QUIC [67]

Manual

Random

P & S

 

2020

Zou et al. [199]

General

  

P

 

2021

ICSFuzzer [45]

ICS [36, 42]

PAL

SCHS

P & GUI Ops

State

2021

StateAFL [110]

General

PAL

SPHS & SRHS

P

State & Code Cov & # of Bugs

2021

TCP-Fuzz [200]

TCP

Manual

Random

P & S & Syscall

State Transition

2021

Snipuzz [46]

IoT

  

P

 

2021

Z-Fuzzer [132]

Zigbee

  

P & Interrupt

Code Cov

2021

PAVFuzz [202]

AV [14, 115]

Manual

Sequential

P

Code Cov

2021

Aichernig et al. [4]

IoT

TAAL

 

P

 

2017

Owfuzz [23]

Wi-Fi

Manual

 

P

State

2022

Meng et al. [103]

General

Manual

Property-Guided

P

State

2022

Greyhound [55]

Wi-Fi

Manual

SPHS

P & S

State & # of Bugs

2022

SGFuzz [15]

General

PAL

SRMS

P

State & Code Cov

2022

Braktooth [53]

Bluetooth

TAAL

SPHS

P

State Transition

2022

L2Fuzz [120]

Bluetooth L2CAP

Manual

Sequential

P

State Cov

2022

AmpFuzz [79]

UDP

  

P

BAF

2022

FUME [121]

MQTT [113]

  

P

Response Freshness

2022

Garbelini et al. [54]

4G/5G

TAPL

 

P & S

 

2023

FeildFuzz [21]

Codesys v3 [112]

  

P

Code Cov

2023

BLEEM [90]

General

TAAL

SRHS

P & S

State

2023

Tyr [31]

Blockchain

Manual

SRHS

P

State & Code Cov

2023

CHATAFL [104]

General

LLM

LLM

P

State & Code Cov

2023

EmNetTest [8]

General

Manual

Sequential

P & S

State

2023

DYFuzzing [7]

General

Manual

SPMS

P & S

Code Cov & # of Bugs

2023

FuzzPD [77]

USBPD

Manual

 

P

State

2023

Mallory [105]

Distributed Sys

TAAL

SPMS

P & S

Event Trace

 
 

 

 

توضیحات جدول:

o : فازر جعبه سفید (Whitebox Fuzzer)
●: فازر جعبه سیاه (Blackbox Fuzzer)
◑: فازر جعبه خاکستری (Greybox Fuzzer)
Tax: رده‌بندی / طبقه‌بندی (Taxonomy)
General: فازر برای نوع خاصی از پروتکل طراحی نشده است
PAL: یادگیری با کمک تحلیل برنامه (Program-Analysis-assisted Learning)
TAAL: یادگیری فعال مبتنی بر تحلیل ترافیک (Traffic-Analysis-based Active Learning)
TAPL: یادگیری غیرفعال مبتنی بر تحلیل ترافیک (Traffic-Analysis-based Passive Learning)
SRMS: زمان‌بندی یکپارچه مبتنی بر ترجیح نادر بودن وضعیت (State Rarity-preferred Monolithic Scheduling)
SPHS: زمان‌بندی سلسله‌ مراتبی مبتنی بر ترجیح عملکرد وضعیت (State Performance-preferred Hierarchical Scheduling)
SCHS: زمان‌بندی سلسله‌ مراتبی مبتنی بر ترجیح پیچیدگی وضعیت (State Complexity-preferred Hierarchical Scheduling)
SPMS: زمان‌بندی یکپارچه مبتنی بر ترجیح عملکرد وضعیت (State Performance-preferred Monolithic Scheduling)
SRHS: زمان‌بندی سلسله‌مراتبی مبتنی بر ترجیح نادر بودن وضعیت (State Rarity-preferred Hierarchical Scheduling) 

– : پیاده‌سازی نشده (Not implemented)
GUI Ops: عملیات رابط کاربری گرافیکی (GUI Operations)
BAF: ضریب تقویت پهنای باند (Bandwidth Amplification Factor)
P: ساخت در سطح بسته (Packet-level construction)
S: ساخت در سطح دنباله پیام‌ها (Sequence-level construction)

   ۴.۱ ساخت مدل ارتباطی (Communication Model Construction)

برای توانمندسازی یک فازر سنتی با دانش محدودیت معنایی، اکثر کارهای موجود، ارتباط را به عنوان ماشین‌های حالت یا انواع آنها برای هدایت فازینگ مدل‌سازی می‌کنند. یک ماشین حالت، ساختار داده‌ای است که انتقال حالت داخلی یک پیاده‌سازی پروتکل را توصیف می‌کند. ماشین‌های حالت ذاتاً سوپرگراف‌های گراف جهت‌دار، مانند ماشین متناهی قطعی (DFA[1]) یا ماشین میلی [39، 48، 55، 56، 125، 130، 142، 160] هستند. گره‌ها (nodes) و لبه‌های (edges) موجود در ماشین حالت، به ترتیب، وضعیت داخلی موجودیت و انتقال‌های ناشی از دریافت یا ارسال پیام را نشان می‌دهند.

فازرهای پروتکل با مراجعه به ماشین وضعیت می‌توانند از وضعیت هدف فعلی آگاه باشند و بر اساس انواع پیام‌هایی که در وضعیت فعلی قابل قبول هستند، نمونه‌های آزمایشی تولید کنند و در نتیجه اثربخشی نمونه‌های آزمایشی را بهبود بخشند. توجه داشته باشید که یک پیاده‌سازی پروتکل ممکن است چندین مدل ارتباطی داشته باشد، زیرا ممکن است بسته به حالت کاری یا پیکربندی‌های آن، رفتار متفاوتی داشته باشد. برای مثال، یک دستگاه Wi-Fi می‌تواند طوری پیکربندی شود که در حالت AP، حالت STA یا حالت P2P اجرا شود [22، 166] و یک پیاده‌سازی SIP می‌تواند به عنوان یک کلاینت، سرور یا پروکسی پیکربندی شود [110]، که هر یک از آنها به درخواست‌ها واکنش متفاوتی نشان می‌دهند، بنابراین مدل ارتباطی متفاوتی خواهند داشت.

اکثر کارهای موجود، این پیاده‌سازی‌ها را که در پیکربندی‌های مختلف اجرا می‌شوند، به عنوان اهداف مختلف در نظر می‌گیرند: آنها یک مدل ارتباطی را برای یک پیکربندی مشخص می‌سازند. در این بخش، ما یک طبقه‌بندی از کارهای موجود را بر اساس روش‌های ساخت مدل ارتباطی آنها ارائه می‌دهیم. همانطور که در شکل 5 نشان داده شده است، آنها به دو دسته تقسیم می‌شوند: (۱) رویکردهای بالا به پایین، و (۲) رویکردهای پایین به بالا.

فازینگ - fuzzing
شکل ۵. طبقه‌بندی تکنیک‌های ساخت مدل ارتباطی

      ۴.۱.۱ رویکردهای بالا‌ به‌ پایین (Top-Down Approaches)

رویکردهای بالا‌ به ‌پایین مدل ارتباطی پروتکل را با یادگیری از توصیف متنی پروتکل، مانند مشخصات فنی یا سایر اسناد، ایجاد می‌کنند. این رویکردها به مشخصات پروتکل به‌عنوان ورودی نیاز دارند؛ ازاین‌رو، عمدتاً برای پروتکل‌های باز (Open Protocols) به‌ کار می‌روند.

به دلیل بهره‌مندی از دانش سراسری نسبت به پروتکل در متن مشخصات، و نیز به ‌سبب تعریف دقیق وضعیت‌ها و گذارها، مدل‌های ارتباطی ساخته‌شده با رویکردهای بالا‌ به‌ پایین معمولاً از کامل‌بودگی و دقت نسبتاً بالایی برخوردارند. با این حال، باید توجه داشت که مدل ارتباطی حاصل، همچنان ممکن است با پیاده‌سازی واقعی پروتکل تفاوت داشته باشد. دلیل این امر آن است که توسعه‌دهندگان ممکن است بر اساس شرایط عملی، طراحی توصیف ‌شده در مشخصات را سفارشی‌سازی یا گسترش دهند. چنین اختلافی می‌تواند در نهایت بر کارایی فازینگ اثر بگذارد.

از منظر روش‌شناسی، ساخت مدل ارتباطی از اسناد پروتکل به دو شیوهٔ کلی انجام می‌شود: دستی و خودکار.

ساخت دستی (در ستون ۴ جدول ۳ با برچسب “manual”):
بیشتر پژوهش‌های موجود، مدل ارتباطی را به‌صورت دستی و با اتکا به دانش تخصصی قابل‌توجه در حوزه می‌سازند [7, 8, 18, 55, 56, 63, 69, 70, 77, 113, 115, 128, 130, 138, 142, 187]. برای نمونه، Garbelini و همکاران [56] و GREYHOUND [55] با رجوع به طراحی هسته‌ایِ مشخصات پروتکل، یک ماشین وضعیت جامع برای Bluetooth Low Energy (BLE) و Wi-Fi می‌سازند تا فرایند فازینگ را هدایت کنند [1, 2, 28, 139].

اگرچه ساخت دستی ماشین حالت، کاری مستعد خطا و نیازمند صرف نیروی انسانی زیاد است، مزیت اصلی آن در این است که کارشناسان انسانی می‌توانند ماشین حالت را به‌صورت انعطاف‌پذیر سفارشی، متناسب‌سازی یا توسعه دهند تا اثر آن در راستای هدف پژوهش حداکثر شود. برای مثال، Beurdouche و همکاران [18] برای کشف باگ‌های ماشین حالت ناشی از چندگانه‌سازی نادرست (incorrect multiplexing) میان وضعیت‌های مختلف پروتکل —مانند نسخه‌های متفاوت پروتکل، افزونه‌ها (extensions)، حالت‌های احراز هویت (authentication modes)، یا روش‌های تبادل کلید (key exchange methods)— به‌ صورت دستی یک ماشین وضعیت ترکیبی (Composite State Machine) می‌سازند که همهٔ گذارهای وضعیت معتبر در میان وضعیت‌های مختلف پروتکل را در بر می‌گیرد. سپس این ماشین وضعیت ترکیبی برای تولید ردپاهای انحرافی (Deviant Traces) به‌ عنوان موارد آزمون (testcase) به‌ کار می‌رود تا گذارهای وضعیت نامعتبر شناسایی شوند.

به‌طور مشابه، FuzzBD [76] به‌ دقت برای پشتیبانی از ویژگی دو‌ نقشیِ منحصربه‌فرد در پروتکل USB Power Delivery (USBPD) طراحی شده است؛ جایی که هر دستگاه به‌ طور هم‌زمان می‌تواند هم منبع توان و هم مصرف‌کنندهٔ توان باشد. با ادغام ماشین‌های حالت این دو نقش، FuzzBD قادر است در حین فرایند فازینگ، تعویض بلادرنگ نقش توان (on-the-fly power role switching) را به‌صورت یکپارچه پشتیبانی کند.

برخلاف آثار یادشده، برخی پژوهش‌ها ترجیح می‌دهند به‌ جای ساخت یک ماشین حالت کامل، تنها بخشی از اطلاعات ماشین حالت را برای هدایت فرایند فازینگ استخراج و استفاده کنند.

Zou و همکارانش، TCP-Fuzz را پیشنهاد می‌کنند، رویکردی جدید که شامل 15 قانون وابستگی است که به صورت دستی از اسناد RFC استخراج شده‌اند. این قوانین شامل وابستگی‌های مختلفی از جمله تعاملات بسته به بسته، فراخوانی سیستمی به بسته و فراخوانی سیستمی به فراخوانی سیستمی است. با استفاده از این قوانین، TCP-Fuzz به طور ماهرانه‌ای با تولید همزمان بسته‌ها و فراخوانی‌های سیستمی وابسته، نمونه‌های آزمایشی تولید می‌کند. نمونه دیگر L2Fuzz [113] است. نویسندگان نقشه‌ای را ایجاد می‌کنند که دستورات معتبر مربوط به هر یک از 19 حالت شناسایی شده در پروتکل را مشخص می‌کند. این نقشه‌برداری، تولید نمونه‌های آزمایشی را که به طور خاص برای تولید دستورات قابل قبول در حالت فعلی طراحی شده‌اند، تسهیل می‌کند و در نتیجه ارتباط و اثربخشی فرآیند آزمایش را افزایش می‌دهد. همچنین برخی از کارها به این مشکل می‌پردازند که مدل‌های ارتباطی بین مشخصات و پیاده‌سازی کاملاً برابر نیستند. MoSSOT [138] با استفاده از پلتفرم‌های ناهمگن ورود یکپارچه (SSO[2]) به عنوان مثال، ابتدا یک ماشین وضعیت از یک فرآیند SSO معمولی می‌سازد، سپس ترافیک شبکه SSO عملی پلتفرم‌های مختلف SSO را تجزیه و تحلیل می‌کند تا جزئیات پیاده‌سازی مانند پارامترهای کلیدی در هر اقدام را بیاموزد. این جزئیات پیاده‌سازی، شرایط انتقال حالت را در ماشین‌های حالت پلتفرم‌های مختلف SSO اصلاح می‌کند.

ساخت خودکار  (Automatic Construction). برای خودکارسازی فرایند خطاپذیر و پرزحمت ساخت دستی مدل ارتباطی، برخی پژوهش‌ها تلاش کرده‌اند محدودیت‌های معنایی پروتکل را به‌صورت خودکار از مشخصات پروتکل استخراج کنند [13, 111].

برای مثال، RESTler [13] روابط وابستگی میان پیام‌ها را بر اساس نوع مقادیر بازگشتی (Return Types) در مشخصات Swagger یاد می‌گیرد. Swagger یک قالب مشخصات ساختاری است که نقاط پایانی (endpoint)، متدها، پارامترها و انواع مقادیر بازگشتی APIهای RESTful را توصیف می‌کند.

همچنین، Pacheco و همکاران پیشنهاد داده‌اند که از پردازش زبان طبیعی (NLP) برای استخراج یک ماشین حالت متناهی (Finite State Machine – FSM) از مشخصات متنی پروتکل استفاده شود [111].

لازم به ذکر است که این دو مقاله در جدول ۳ فهرست نشده‌اند، زیرا این پژوهش‌ها فازرهای پروتکل حالت‌دار ایجاد نمی‌کنند. نمونهٔ دیگری از کارهایی که از ساخت خودکار ماشین حالت استفاده می‌کند، CHATAFL [100] است. این روش از مدل‌های زبانی بزرگ (Large Language Models) بهره می‌برد تا حالت فعلی هدف را استنتاج کرده و بسته‌های مناسب برای انتقال حالت را تولید کند.

      ۴.۱.۲ رویکردهای از پایین ‌به‌ بالا (Bottom-Up Approaches)

رویکردهای پایین‌به‌بالا راه‌حل دیگری برای بازسازی مدل ارتباطی ارائه می‌دهند. این رویکردها با استفاده از اطلاعات قابل مشاهده از پیاده‌سازی پروتکل، مدل ارتباطی را بازسازی می‌کنند. از آنجا که این روش‌ها به اسناد متنی یا مشخصات رسمی پروتکل متکی نیستند، برای پروتکل‌های اختصاصی (Proprietary Protocols) مناسب‌اند.

برخلاف رویکردهای بالا ‌به ‌پایین که در آن‌ها تعریف حالت‌های پروتکل در اسناد به‌صورت روشن موجود است، در رویکردهای پایین‌به‌بالا تعریف «حالت» معمولاً وابسته به هدف بوده و ممکن است با توجه به کاربرد، روش، یا پیاده‌سازی متفاوت باشد.

برای مثال، AFLNet [116] یک حالت پروتکل را بر اساس کد وضعیتِ پاسخِ PUT تعیین می‌کند. نمونهٔ دیگر StateAFL [106] است که چیدمان حافظهٔ ماندگار (long-lived memory) را خوشه‌بندی کرده و هر خوشه را به‌ عنوان یک حالت در نظر می‌گیرد.

از منظر منبع یادگیری، این روش‌ها را می‌توان به دو دسته تقسیم کرد:

  • رویکردهای مبتنی بر تحلیل ترافیک (Traffic-Analysis-Based Approaches)
  • رویکردهای همراه با تحلیل برنامه (Program-Analysis-Assisted Approaches)

رویکردهای مبتنی بر تحلیل ترافیک:
این دسته از روش‌ها بر بازسازی مدل ارتباطی پروتکل صرفاً بر پایهٔ ردپاهای ترافیک شبکهٔ مشاهده‌ شده تمرکز دارند [39, 48, 90, 116, 162, 181]. این نوع رویکرد پیاده‌سازی ساده‌تری دارد و در شرایطی که ردیابی اجرای برنامه ممکن نیست عملکرد خوبی نشان می‌دهد؛ برای مثال، زمانی که فریمور (firmware) حاوی برنامهٔ هدف در دسترس نباشد.

رویکردهای ساخت مدل ارتباطی مبتنی بر تحلیل ترافیک را می‌توان به دو نوع تقسیم کرد: منفعل (Passive) و فعال (Active).

یادگیری منفعل (Passive Learning) – که در ستون ۴ جدول ۳ با برچسب TAPL مشخص شده است – عمدتاً به مجموعه‌ای از ردپاهای شبکه‌ای از پیش جمع‌آوری‌ شده میان برنامه‌های تحت آزمون (PUT) و سایر موجودیت‌ها تکیه دارد تا از روی آن‌ها مدل ارتباطی را استنتاج کند [45, 57, 172, 181]. الگوریتم‌های یادگیری پیشنهاد شده در پژوهش‌های موجود را می‌توان به دو دسته تقسیم کرد: الگوریتم‌های مبتنی بر آمار (Statistics-Based) و دیگری الگوریتم‌های مبتنی بر شبکهٔ عصبی (Neural-Network-Based). در دستهٔ نخست، Pulsar [57] با محاسبهٔ احتمال وقوع پیام‌های مجاور در مجموعهٔ ردپاهای شبکه، یک مدل مارکوف مرتبهٔ دوم (Second-Order Markov Model) می‌سازد و سپس این مدل مارکوف را به یک ماشین متناهی قطعی (DFA) کمینه‌سازی می‌کند. پس از دریافت یک پیام، Pulsar آن را با یکی از حالت‌های موجود در DFA استنتاج‌ شده تطبیق می‌دهد تا یک قالب پاسخ معتبر برای ساخت موارد آزمون جدید انتخاب کند. در دستهٔ دوم، Fan و همکاران [45] و SeqFuzzer [181] از LSTM برای یادگیری دستور زبان (Grammar) و ویژگی‌های زمانی (Temporal Features) پروتکل‌های حالت‌دار استفاده می‌کنند. به‌ طور مشخص، آن‌ها LSTM را به‌ عنوان رمزگذار (Encoder) و رمزگشا (Decoder) در یک مدل توالی‌ به‌ توالی (Sequence-to-Sequence / seq2seq) به‌کار می‌گیرند [154]. مدل seq2seq یک ساختار encoder-decoder است که می‌تواند دنباله‌های ورودی و خروجی با طول‌های متفاوت را پردازش کند. در این چارچوب، LSTM رمزگذار ویژگی‌های پروتکل را از طریق ردپاهای شبکه‌ای ضبط‌ شده می‌آموزد، در حالی که LSTM رمزگشا برای تولید ورودی‌های فازینگ استفاده می‌شود.

روش‌های یادگیری ماشین حالت مبتنی بر ردپاهای شبکه‌ای منفعل، از نظر اجرا ساده و سریع هستند. با این حال، کیفیت ماشین حالت ساخته‌ شده به میزان پوشش ترافیک‌های جمع‌آوری‌ شده وابسته است. در عمل، گردآوری مجموعه‌ای جامع از انواع پیام‌ها و توالی‌های ارتباطی کار دشواری است؛ در نتیجه، مدل ارتباطی ساخته‌ شده ممکن است بخشی از حالت‌ها یا گذارهای حالتیِ ثبت‌ نشده را در بر نگیرد.

یادگیری فعال (Active Learning) – که در ستون ۴ جدول ۳ با برچسب TAAL مشخص شده است – شامل یادگیری مدل ارتباطی در حین فرایند فازینگ می‌شود. این رویکردها را می‌توان بر اساس این‌ که آیا مجموعهٔ حالت‌های سراسری از پیش تعریف شده است یا نه، دسته‌بندی کرد.

دستهٔ نخست، مجموعهٔ حالت‌های سراسری را از پیش تعریف نمی‌کند؛ یعنی تعداد و ماهیت حالت‌های ممکن در ماشین حالت را از ابتدا مشخص نمی‌سازد. این رویکرد از الگوریتم‌های یادگیری فعال آتاماتا (automata active learning) برای شناسایی ماشین حالتِ هدف استفاده می‌کند. این الگوریتم‌های یادگیری به الفبای ورودی/خروجیِ تعریف‌شده توسط کاربر و نیز نگاشت‌گرهایی میان این الفباها و پیام‌های واقعی متکی هستند. این الگوریتم‌ها با شروع از یک ماشین حالت تهی، از طریق تعامل با پیاده‌سازی پروتکل هدف، به‌صورت تکراری مدل را پیشنهاد و اصلاح می‌کنند و تنها زمانی متوقف می‌شوند که دیگر مثال نقضی برای ماشین حالتِ آموخته‌ شده یافت نشود. بیشتر آثار این دسته [4, 38, 39, 48, 49, 98, 131] از الگوریتم (L^*) انگلوین استفاده می‌کنند؛ به این صورت که الفبای ورودی را بر پایهٔ مشخصات پروتکل تعریف کرده و با استفاده از قالب‌های پیام آن‌ها را به پیام‌های واقعی ترجمه می‌کنند.

در مقابل، دستهٔ دوم برای پرهیز از پیچیدگی‌های الگوریتم‌های یادگیری اتوماتا، مجموعهٔ کامل حالت‌ها را از پیش تعریف می‌کند. در این رویکرد، معمولاً مجموعهٔ حالت‌ها با یک روش قاعده‌مبنا (Rule-Based) تعیین می‌شود و سپس گذارهای میان حالت‌ها از طریق جهش روی پیام‌های شناخته‌ شده یاد گرفته می‌شود. به بیان دیگر، حالت‌های بالقوهٔ ماشین حالت (گره‌ها) از قبل مشخص شده‌اند و تمرکز اصلی بر کشف و افزودن گذارهای حالتی (یال‌ها) است.

برای مثال، AFLNet [116] از کدهای وضعیتِ پیام‌های پاسخ برای تعیین حالت فعلی پروتکل استفاده می‌کند و با جهش روی توالی‌های پیام واقعی، گذارهای جدید را کشف می‌کند. Bleem [89] از کتابخانهٔ Scapy برای تجزیهٔ پیام‌ها استفاده کرده و با نگه‌داشتن تمام فیلدهای از نوع شمارشی (Enumeration Type)، آن‌ها را به انواع مختلف پیام انتزاع می‌کند. این راهبرد بر مشاهدات تجربی از بیش از ۵۰ پروتکل پشتیبانی‌شده توسط Scapy استوار است که در آن‌ها، مقادیر متفاوت فیلدهای شمارشی معمولاً نشان‌دهندهٔ انواع متمایز بسته یا فریم هستند. سپس Bleem از این ردپاهای انتزاع‌یافتهٔ پیام برای ساخت یک گراف راهنما جهت هدایت فازینگ استفاده می‌کند.

نمونهٔ دیگر، Braktooth [53] است که بر پایهٔ ویژگی‌های پیام، هشت قاعده برای نگاشت پیام‌ها به حالت‌ها تعریف می‌کند. این سامانه به‌عنوان یک پراکسی میان PUT و یک پشتهٔ استاندارد پروتکل عمل می‌کند و با جهش در ارتباطات، گذارهای حالتی بیشتری را کاوش می‌کند. به‌طور مشابه، Garbelini و همکاران [54] نیز قواعد نگاشتی برای شناسایی حالت‌ها تعریف کرده و ماشین حالت را با استفاده از ردپاهای ضبط‌شده (یعنی فایل‌های pcap) یاد می‌گیرند.

رویکردهای همراه با تحلیل برنامه (Program-Analysis-Assisted Approaches) – که در ستون ۴ جدول ۳ با برچسب PAL مشخص شده‌اند – در مقایسه با رویکردهای مبتنی بر تحلیل ترافیک، علاوه بر داده‌های بیرونی، از اطلاعات داخلی اجرای برنامه نیز برای ساخت مدل ارتباطی استفاده می‌کنند. به‌طور کلی، این اطلاعات داخلی شامل نتایج تحلیل ایستای برنامه و تحلیل پویای برنامه است؛ بنابراین، به‌کارگیری این رویکردها نه‌ تنها مستلزم دسترسی به خود برنامه است، بلکه نیازمند در دسترس بودن چارچوب‌های تحلیل مانند ابزارگذاری برنامه (Program Instrumentation) نیز هست. بر اساس نوع اطلاعات داخلیِ مورد استفاده، آثار موجود را می‌توان به دو دسته تقسیم کرد: رویکردهای مبتنی بر ردپای اجرا (Execution-Trace-Based)و رویکردهای مبتنی بر متغیر حالت (State-Variable-Based).

رویکردهای مبتنی بر ردپای اجرا، حالت‌های داخلی متفاوت را بر اساس ردپای اجرای هدف شناسایی می‌کند. برای مثال، ICS3Fuzzer [46] نرم‌افزار نظارتی هدف را به‌صورت پویا ابزاردقیق‌سازی می‌کند تا ردپای اجرا را جمع‌آوری کند. سپس با مقایسهٔ هویت ردپاهای اجرایی، ICS3Fuzzer می‌تواند تشخیص دهد که آیا PUT در یک حالت متفاوت قرار گرفته است یا خیر.

رویکردهای مبتنی بر متغیر حالت با ردیابی تغییرات مقدار متغیرهای حالت در طول پردازش ورودی، گذارهای حالت پروتکل را شناسایی می‌کند [15, 106, 120, 148]. مبنای این رویکردها یک مشاهدهٔ ساده است: در بیشتر پیاده‌سازی‌های پروتکل، از برخی متغیرها برای ذخیرهٔ حالت فعلی استفاده می‌شود. ازاین‌رو، این روش‌ها چنین متغیرهایی را به‌عنوان متغیر حالت شناسایی کرده و از مقدار آن‌ها برای تمایز میان حالت‌های مختلف بهره می‌گیرند.

برای نمونه، StateAFL [106] با شناسایی ساختارهای دادهٔ ماندگار (long-lived) در snapshotهای حافظه، متغیرهای حالتِ محتمل را شناسایی می‌کند. به‌طور مشابه، STATEINSPECTOR [148] متغیرهای حالت را با یافتن نواحی‌ای از حافظهٔ heap شناسایی می‌کند که در اجرای هر توالی پیام، مقادیر ثابتی را حفظ کرده‌اند.

در مقابل، SGFuzz [15] متغیرهای حالت را از طریق عبارات باقاعده (regular expressions) شناسایی می‌کند، به این صورت که به‌طور خودکار تمام متغیرهای از نوع enum را که حداقل یک‌بار مقداردهی شده‌اند استخراج می‌کند. ایدهٔ اصلی این رویکرد بر این مشاهده استوار است که اکثر پیاده‌سازی‌های پروتکل از متغیرهای حالت از نوع enum استفاده می‌کنند.

   ۴.۲ زمان‌بندی وظیفه (Task Scheduling)

در پژوهش‌های اخیرِ حوزهٔ فازینگ پروتکل، فاز زمان‌بندی بر اساس روشی که برای مواجهه با پیچیدگی‌های مرتبط با وضعیت (state-related complexities) به‌کار می‌گیرد، به‌ صورت مشخص دسته‌بندی شده است. این دسته‌بندی به دو گروه اصلی منتهی می‌شود: رویکردهای سلسله‌ مراتبی (Hierarchical Approaches) و رویکردهای یکپارچه  (Monolithic Approaches). رویکردهای سلسله‌مراتبی فرایند زمان‌بندی را به دو فاز مجزا تفکیک می‌کنند:

  • زمان‌بندی درون‌حالتی (intra-state scheduling) که بر آزمون در داخل یک حالت متمرکز است.
  • زمان‌بندی بین‌حالتی (inter-state scheduling) که مدیریت گذار بین حالت‌ها را بر عهده دارد.

این دو فاز به‌ صورت مستقل پیاده‌سازی می‌شوند و در نتیجه امکان کنترل دقیق‌تر و ظریف‌تر بر فرایند فازینگ را فراهم می‌کنند. در مقابل، رویکردهای یکپارچه از یک فاز زمان‌بندی واحد و یکدست استفاده می‌کنند که در آن، اطلاعات مرتبط با حالت به‌صورت یک ضریب یا مؤلفهٔ اثرگذار در دل الگوریتم زمان‌بندی ادغام می‌شود.

علاوه بر اطلاعات مرتبط با حالت، بسیاری از پژوهش‌ها از دسته‌های دیگری از اطلاعات نیز برای اهداف زمان‌بندی بهره می‌برند. با این حال، الگوریتم‌های زمان‌بندی مبتنی بر این نوع اطلاعات عموماً ماهیتی عمومی دارند و در ادبیات پژوهشی پیش‌تر به‌خوبی بررسی شده‌اند [94, 185]. ازاین‌رو، ما در اینجا وارد بحث تفصیلی دربارهٔ آن‌ها نمی‌شویم.

رویکردهای سلسله‌مراتبی (Hierarchical Approaches). در این نمونه، زمان‌بند (scheduler) از یک الگوریتم دو مرحله‌ای استفاده می‌کند:

  1. ابتدا یک وضعیت (state) برای فازینگ با استفاده از الگوریتم زمان‌بندی وضعیت انتخاب می‌شود.
  2. سپس یک الگوریتم زمان‌بندی عمومی برای بهینه‌سازی فرآیند فازینگ در همان حالت به‌کار گرفته می‌شود.

روش‌های ابتکاری مورد استفاده در فرایند زمان‌بندی عمدتاً به سه دسته تقسیم می‌شوند:

  • ترجیح وضعیت‌های کم‌تکرار (Rarity-Preferred) – که در جدول ۳ ستون ۵ با برچسب SRHS آمده است.
  • ترجیح عملکرد (Performance-Preferred) – با برچسب SPHS در جدول ۳ ستون ۵.
  • ترجیح پیچیدگی (Complexity-Preferred) – با برچسب SCHS در جدول ۳ ستون ۵.

جزئیات این دسته‌ها در جدول ۴ ارائه شده است. در روش‌های مبتنی بر ترجیح وضعیت‌های کم‌تکرار، منابع بیشتری به وضعیت‌هایی اختصاص داده می‌شود که کمتر اجرا شده‌اند؛ زیرا فرض می‌شود این حالت‌ها احتمالاً دارای حالت‌های مجاور کشف‌ نشده یا منطق‌های کدی ناشناخته هستند [19, 106, 116, 152]. در روش‌های مبتنی بر ترجیح عملکرد، وضعیت‌هایی در اولویت قرار می‌گیرند که پوشش کد بیشتری ایجاد کرده‌اند یا نرخ کشف باگ بالاتری دارند [30, 55, 56, 106, 116].

علاوه بر این، برخی پژوهش‌ها از روش‌های مبتنی بر ترجیح پیچیدگی استفاده می‌کنند که وضعیت‌هایی با پیچیدگی بیشتر (یعنی متصل به بلوک‌های پایه‌ای بیشتر) یا حالت‌های عمیق‌تر (یعنی دورتر از حالت اولیه) را ترجیح می‌دهند [46, 57]. برای مثال، ICS3Fuzzer [46] تمایل دارد حالت‌های عمیق‌تر و حالت‌هایی را انتخاب کند که بلوک‌های پایه‌ای بیشتری را اجرا می‌کنند.

Pulsar [57] به‌ عنوان یک فازر مبتنی بر تولید (Generation-Based Fuzzer)، وزن تمام حالت‌هایی را که از حالت فعلی قابل دسترسی هستند محاسبه می‌کند و سپس حالتی را که بیشترین وزن را دارد برای آزمایش بعدی انتخاب می‌کند. به‌طور دقیق‌تر، وزن هر حالت به‌صورت مجموع تمام فیلدهای قابل جهش (mutable fields) در یک تعداد مشخص از گذارها محاسبه می‌شود.

با این حال، از آنجا که تمام این الگوریتم‌های انتخاب حالت به‌صورت جداگانه و روی پلتفرم‌ها و اهداف متفاوت پیاده‌سازی و ارزیابی شده‌اند، انجام مقایسهٔ منصفانه و دستیابی به نتایج قطعی دشوار است. در همین راستا، Liu و همکاران [87] سه الگوریتم انتخاب حالت موجود در AFLNet [116] را ارزیابی کردند:

  • الگوریتم نادر-ترجیح داده شده
  • الگوریتم انتخاب تصادفی وضعیت‌ها
  • الگوریتم انتخاب ترتیبی وضعیت‌ها

نتایج نشان داد که این الگوریتم‌ها از نظر پوشش کد عملکردی بسیار مشابه دارند. آن‌ها دلیل این موضوع را انتزاع حالت‌های درشت‌دانه (coarse-grained state abstraction) در AFLNet و برآورد نادقیق بهره‌وری حالت‌ها می‌دانند. به همین دلیل، آن‌ها الگوریتم AFLNETLEGION [87] را پیشنهاد کردند که برای رفع این مشکلات طراحی شده و بر پایهٔ گونه‌ای از الگوریتم جستجوی درخت مونت‌کارلو (Monte Carlo Tree Search) [86] ساخته شده است.

رویکردهای یکپارچه (Monolithic Approaches). در رویکردهای یکپارچه، اطلاعات مرتبط با وضعیت به‌ صورت یک ضریب یا پارامتر در الگوریتم اصلی زمان‌بندی بذرها (seed scheduling) محاسبه و در آن ادغام می‌شود. برای مثال، SGFuzz [15]، وضعیت‌ها را بر اساس تعداد دفعات اجرا به دو دسته تقسیم می‌کند:

  • وضعیت‌های نادر (Rare States)
  • وضعیت‌های معمولی (Normal States)

هنگام اختصاص انرژی به بذرها (seeds)، نسبت حالت‌های نادری که توسط هر بذر پوشش داده می‌شوند محاسبه می‌گردد و این نسبت به‌ عنوان یکی از پارامترها به الگوریتم زمان‌بندی توان (power scheduling) اولیه افزوده می‌شود.

به‌ طور مشابه، SGFuzz انرژی بیشتری به بذرهایی اختصاص می‌دهد که شامل گذارهای وضعیتی مطابق با رفتارهای مورد انتظار پروتکل هستند. دلیل این کار آن است که SGFuzz فرض می‌کند این گذارهای معتبر راحت‌تر می‌توانند به گذارهای نامعتبر دیگر جهش پیدا کنند و در نتیجه منطق‌های رسیدگی به خطا (error handling logic) فعال شوند.

به‌طور مشابه، LTL-Fuzzer [99] نیز کل بذرها را زمان‌بندی می‌کند و بذرهایی را در اولویت قرار می‌دهد که در هنگام اجرا به مکان‌های هدف در کد نزدیک‌تر هستند.

جدول ۴. دسته‌بندی اطلاعات مرتبط با زمان‌بندی

 
 

 

 

نوع زمان‌بندی

اطلاعات

سلسله مراتبی

یکپارچه

اولویت‌دهی به حالت‌های کم‌رخداد

زمان‌های اعمال‌ شده وضعیتی

[106, 116, 152]

[15]

عملکرد ترجیحی

مشارکت در پوشش کد جدید، مشارکت در پوشش وضعیت جدید، مشارکت در رفع اشکالات جدید

[30, 55, 56, 106, 116]

پیچیدگی ترجیحی

تعداد بلوک‌های پایه متصل، عمق وضعیت، فرصت‌های جهش

[46, 57]

سایر

فاصله تا دستور کلیدی

[99]

   ۴.۳ ساخت موارد آزمون (Testcase Construction)

راهبردهای ساخت مورد آزمون (Testcase) در فازینگ پروتکل به‌طور کلی به دو دسته تقسیم می‌شوند:

  • راهبردهای سطح بسته  (Packet-Level)
  • راهبردهای سطح توالی  (Sequence-Level)

      ۴.۳.۱ راهبرد ساخت در سطح بسته (Packet-Level Construction Strategy)

(در ستون ۶ جدول ۳ با برچسب Packet مشخص شده است)

راهبردهای ساخت در سطح بسته در فازرهای پروتکل، تا حد زیادی راهبردهای فازرهای عمومی مانند bit flip، set zero  و روش‌های مشابه را به ارث می‌برند. بااین‌حال، در اینجا بیشتر به راهبردهایی پرداخته می‌شود که با بهره‌گیری از ویژگی‌های خاص پروتکل تلاش می‌کنند فضای ورودی را کاهش دهند یا کارایی کشف باگ را افزایش دهند.

به منظور کاهش فضای ورودی، ابزار SPIDER [80] از یک بینش دامنه‌محور (Domain-Specific Insights) استفاده می‌کند؛ این بینش بیان می‌کند که در کنترل‌کننده‌های موجود SDN، بیشتر پیام‌های OpenFlow باعث ایجاد رویدادهای جدید سیستمی می‌شوند که بر محاسبهٔ حالت سیستم و مصرف منابع تأثیر می‌گذارند.

بر اساس این مشاهده، SPIDER به‌جای تولید مستقیم پیام‌های OpenFlow، مستقیماً توالی‌های رویداد (event sequences) را تولید می‌کند؛ رویکردی که باعث کاهش چشمگیر فضای ورودی می‌شود.

همچنین، L2Fuzz [113] قالب بستهٔ L2CAP را به دو بخش تقسیم می‌کند: فیلدهایی که قابل جهش (mutation) هستند و فیلدهایی که بدون تغییر باقی می‌مانند؛ سپس با تغییر تنها فیلدهای قابل جهش، موارد آزمونی (testcase) تولید می‌کند که احتمال رد شدن آن‌ها کمتر است.

از سوی دیگر، IPSpex [183] با ترکیب ترافیک شبکه و ردپاهای اجرای فرایند ساخت بسته‌های شبکه، معنای فیلدهای پیام در پروتکل‌های ICS را استخراج می‌کند.

راهبردهایی که هدفشان افزایش کارایی در تحریک باگ‌ها است، عمدتاً مجموعه‌ای از اکتشاف‌های حاصل از تجربه‌های عملی هستند. برای مثال، EmNetTest [8] به‌ صورت سیستماتیک بسته‌هایی با ساختار معتبر تولید می‌کند که در آن‌ها فیلدهای هدر نامعتبر یا هدرهای ناقص (truncated headers) قرار داده شده است.

بینشِ پشت این راهبرد از یک مطالعهٔ جامع روی ۶۱ آسیب‌پذیری گزارش‌ شده در پشته‌های شبکهٔ تعبیه‌ شده (Embedded Network Stacks – ENS) به دست آمده است. راهبردهای مشابهی نیز در بسیاری از آثار ارائه‌ شده در کنفرانس‌های صنعتی ذکر شده‌اند.

برای مثال، BadMesher [121] از چندین راهبرد دامنه‌ محور استفاده می‌کند؛ از جمله تنظیم فیلد طول (length field) روی مقادیر مرزی و حذف تصادفی برخی فیلدها، تا کارایی در تحریک باگ‌ها در دستگاه‌های Wi-Fi Mesh افزایش یابد.

همچنین Yen و همکاران [170] نشان داده‌اند که راهبردهایی مانند جهش در فیلد ID به یک شناسهٔ ناموجود، تغییر شمارهٔ پورت یا فیلد طول به مقادیر مرزی (مانند ‎0xFF‎ یا ‎0x00‎)، و تغییر آدرس IP به آدرس‌های تصادفی می‌توانند در فازینگ پروتکل سرویس توزیع داده (DDS – Data Distribution Service) بسیار مؤثر باشند.

به‌طور مشابه، BrokenMesh [167] نیز در فازینگ پروتکل Bluetooth Mesh از راهبردهایی مانند جهش در تعداد بسته‌ها (packet count) یا فیلد طول استفاده می‌کند.

      ۴.۳.۲ استراتژی ساخت در سطح توالی (Sequence-Level Construction Strategy)

(که در جدول ۳ ستون ۶ با عنوان «توالی» مشخص شده است)

فازرهای پروتکل ممکن است برخی از استراتژی‌های ساخت سطح توالی را اتخاذ کنند. این استراتژی‌ها به صورت پیشگیرانه توالی‌های پیامی را می‌سازند که از ماشین حالت پروتکل معمولی منحرف می‌شوند و انتظار دارند که اشکالات غیرایمنی حافظه بیشتری از برنامه‌های تحت آزمون (PUT) را ایجاد کنند. فازرهای مبتنی بر تولید و فازرهای مبتنی بر جهش در ساخت سطح توالی متفاوت عمل می‌کنند.

(۱) فازرهای مبتنی بر تولید (Generation-Based Fuzzers):

این نوع فازرها توالی پیام‌ها را با استفاده از دانش موجود پروتکل می‌سازند، مانند ماشین‌های حالت استاندارد و وابستگی‌های بین پیام‌ها (inter-message dependencies). مثال‌های شاخص شامل آثار [18, 124, 142, 158] هستند که با اعمال استراتژی‌هایی مانند اضافه یا حذف پیام‌های تصادفی پروتکل روی توالی‌های معتبر استخراج‌شده از ماشین‌های حالت استاندارد، ردپاهای پیام غیرعادی (aberrant message traces) تولید می‌کنند. پروژه‌هایی مانند Sweyntooth [56]، Greyhound [55] و Braktooth [53] با دقت گذارهای حالتی (state transitions) برنامه تحت آزمون (PUT) را رصد کرده و بسته‌های معتبر را در حالت‌های نامناسب تزریق می‌کنند تا ناهنجاری‌ها را تحریک کنند؛ این کار مطابق با مدل ماشین حالت انجام می‌شود. تحقیقات اخیر توسط Fiterau-Brostean و همکاران [50] یک روش نوین برای شناسایی باگ‌های ماشین حالت ارائه می‌دهند ابتدا یک فهرست از آتاماتای محدود (finite automatons) که نشان‌دهنده انواع خاصی از باگ‌های ماشین حالت هستند، همراه با مدل PUT وارد می‌شود. سپس این مدل‌ها تحلیل شده و موارد آزمونی تولید می‌شوند که باگ را آشکار می‌کنند.

(۲) فازرهای مبتنی بر جهش (Mutation-Based Fuzzers):

این نوع فازرها عمدتاً از استراتژی‌های ساده ولی مؤثر برای جهش (mutate) توالی پیام‌های بذرها استفاده می‌کنند. این استراتژی‌ها شامل تکنیک‌هایی مانند جابجایی بسته‌ها (packet shuffling)، درج تصادفی (random insertion) و حذف (deletion) می‌شوند. برای نمونه AFLNET [116] توالی پیام‌ها را با نگهداری یک مجموعه پیام از ترافیک شبکه می‌سازد که می‌تواند در توالی‌های موجود بذرها ادغام یا جایگزین شود. AFLNET همچنین از ترکیبی از عملگرهای سطح بایت و سطح توالی استفاده می‌کند، از جمله: جایگزینی، درج، تکرار و حذف پیام‌ها برای ساخت توالی پیام‌ها. DYFuzzing [8] بذرها را جهش می‌دهد و از استراتژی‌های مهاجم Dolev-Yao (DY) بهره می‌برد. Frankenstein [130] توالی‌های پیام شناخته‌شده را بازسازمان‌دهی می‌کند تا پوشش کد (code coverage) بهبود یابد. He و همکاران [63] یک فازر ویژه برای پروتکل 5G non-access-stratum (NAS) ارائه کرده‌اند که بسته‌ها را از ضبط کننده‌ها (capture) استخراج و در یک جدول ساختاریافته پیام‌ قرار می‌دهد. سپس استراتژی‌های جهش متفاوتی را روی فیلدهای کلیدی اعمال می‌کند که باعث افزایش هوشمندی و دقت در فرآیند جهش پیام‌ها می‌شود.

یک نکته مهم: در فازرهای مبتنی بر جهش، باید همبستگی فیلدهای خاص در توالی پیام‌ها (مانند شمارهٔ نشست، شمارنده‌ها یا برچسب‌های زمانی (timestamp)) به‌دقت مدیریت شود. جهش بی‌رویه در این فیلدها می‌تواند باعث بی‌اثر شدن ورودی و رد زودهنگام آن شود. برای رفع این چالش، AFLNET [116] کد PUT را تغییر می‌دهد تا از شماره نشست ثابت استفاده کند و بدین ترتیب اثربخشی فرآیند فازینگ تضمین شود.

Protocol Fuzzing - فازینگ پروتکل
شکل 6. گردش کار دقیق اجراکنندگان در فازینگ پروتکل

۵. اجرا کننده (Executor)

در این بخش، به تفصیل بهبودهای کلیدی فازرهای پروتکل در بخش اجراکننده (Executor) معرفی می‌شود. همان‌طور که در شکل ۶ نشان داده شده است، یک اجراکننده در فازینگ پروتکل معمولاً شامل چهار فرآیند اصلی است:

  1. آماده‌سازی محیط اجرایی (Execution Environment Preparation): ابتدا اجراکننده باید یک محیط اجرایی قابل اجرا برای PUT فراهم کند.
  2. تغذیه ورودی (Input Feeding): سپس ورودی‌ها را از طریق مکانیزم تغذیه ورودی به PUT ارسال می‌کند.
  3. استخراج اطلاعات زمان اجرا (Information Extraction): در حین پردازش ورودی‌ها، اطلاعات زمان اجرا استخراج می‌شود.
  4. بازنشانی اجرای برنامه (Execution Reset): پس از اتمام اجرای تکرار جاری، حالت اجرایی و وضعیت محیط به یک حالت مشخص بازنشانی می‌شوند.

در جدول ۵، تکنیک‌ها و بهبودهای کلیدی در اجرای بهینه (شامل مراحل ①، ②، ④) و استخراج اطلاعات زمان اجرا (③) در فازرهای پروتکل موجود جمع‌بندی شده است. آثار ذکر شده در این جدول از مجموعه مقالات انتخاب شده‌اند، زیرا به‌طور مستقیم با اجراکننده مرتبط هستند.

   ۵.۱ اجرای بهینه (Efficient Execution)

در فازینگ پروتکل، معمولاً دو مسیر برای افزایش کارایی فازینگ وجود دارد:

  1. ایجاد یک محیط اجرایی که امکان تست موازی را فراهم کند (①در شکل ۶)
  2. کاهش هزینه اجرای هر تکرار از فرآیند تست (② و ④ در شکل ۶)

      ۵.۱.۱ بهبود مقیاس‌پذیری  (Scalability Improvement)

در این زمینه، فازینگ مقیاس‌پذیر (scalable fuzzing) به توانایی ایجاد چندین محیط تست برای اجرای موازی فازینگ اشاره دارد. این مسئله در فازینگ پروتکل اهمیت ویژه‌ای دارد، زیرا بسیاری از اهداف فازینگ به سخت‌افزار خاص وابسته‌اند.

روش سنتی برای اجرای تست موازی، خرید چندین دستگاه فیزیکی است که می‌تواند از نظر اقتصادی هزینه‌بر و ناکارآمد باشد. در فازینگ پروتکل، از آنجا که بسیاری از اهداف فازینگ به محیط‌های اجرایی تخصصی نیاز دارند، اجرای همزمان این اهداف تنها با خرید دستگاه‌های متعدد ممکن است، که باعث هزینه‌های بالا و هدررفت منابع می‌شود.

در این میان، شبیه‌سازی (Emulation) به‌ عنوان یک راه‌حل کلیدی برای فازینگ مقیاس‌پذیر مطرح می‌شود. شبیه‌سازی، محیط اجرایی مجازی برای PUT فراهم می‌کند، وابستگی به سخت‌افزار تخصصی را کاهش می‌دهد و ایجاد چندین نمونه تست موازی را آسان می‌سازد. این قابلیت مقیاس‌پذیری را به‌طور قابل توجهی افزایش می‌دهد و امکان انجام عملیات گسترده فازینگ در محیط‌های متعدد را فراهم می‌کند.

برخی فازرهای پروتکل از راهکارهای شبیه‌سازی موجود برای توسعه فرآیند فازینگ استفاده می‌کنند (در جدول ۵، ستون ۴ با عنوان “CUVM” مشخص شده‌اند) [69, 115, 134, 138, 152].

جدول 5- فازرهای پروتکل و بهینه‌سازی اجرا کننده آنها

Year

Work

Tax

Target

Efficient Execution

Runtime Info Extraction

Env Prep

Input Feeding

Execution State Reset

Execution Env Reset

Runtime Info

Monitoring Method

2014

Gorenc et al. [58]

SMS/MMS [43]

HIL

OTA

VMSR

DR

  

2017

WiFuzz [169]

Wi-Fi

HIL

OTA

RM

 

State

Resp

2018

TCPWN [69]

TCP

CUVM

Socket (MiTM)

  

State

Resp

2019

SeqFuzzer [194]

ICS

HIL

Socket (P2P)

    

2019

MoSSOT [149]

SSO

CUVM

Socket (MiTM)

VMSR

VMSR

State

Resp

2019

Chen et al. [30]

General

 

File

PSR

 

State & Code Cov

SSI

2019

Fw-Fuzz [52]

General

 

Socket (P2P)

ProcR

 

Code Cov

SDI

2019

Park et al. [119]

RDP [106]

 

Virtual Channels

  

Code Cov

SDI

2020

Exploiting Dissent [170]

TLS

 

Socket (P2P)

ProcR

 

State

Resp

2020

DTLS-Fuzzer [47]

DTLS

 

Socket (P2P)

MR

 

State

Resp

2020

AFLNET [123]

General

 

Socket (P2P)

MR

UPSR

State & Code Cov

Resp & SSI

2020

SweynTooth [56]

BLE

HIL

OTA

ProcR

 

State

Resp

2020

Frankenstein [138]

Bluetooth

SE

Shared memory

VMSR

 

Code Cov

SDI

2020

Peach* [92]

ICS

 

Socket (P2P)

ProcR

UPSR

Code Cov

SSI

2020

aBBRate [122]

TCP

CUVM

Socket (MiTM)

  

State

Resp

2020

BaseSAFE [96]

LTE

SE

Shared-Memory

PSR

 

Code Cov

SDI

2020

ToothPicker [64]

Bluetooth

HIL

FHPI

ThrdR

 

Code Cov

SDI

2021

ICSFuzzer [45]

ICS

 

Socket (P2P)

ProcR

 

Exec Traces

SDI

2021

StateAFL [110]

General

 

Socket (P2P)

PSR

UPSR

State & Code Cov

SSI

2021

TCP-Fuzz [200]

TCP

 

Socket (P2P)

  

Branch Cov

SSI

2021

Snipuzz [46]

IoT

HIL

Socket (P2P)

MR & PhyR

 

Code Cov

Resp

2021

Z-Fuzzer [132]

Zigbee

SE

Socket (P2P)

ProcR

 

Code Cov

SDI

2021

PAVFuzz [202]

AV

 

Socket (P2P)

ProcR

UPSR

Code Cov

SSI

2021

Schepers et al. [141]

Wi-Fi

 

Virtual Interface

  

Code Cov

SSI

2021

Wu et al. [176]

EV Fast Charging

HIL

CAN Bus (MiTM)

    

2022

Meng et al. [103]

General

 

Socket (P2P)

PSR

 

Property-Guided

SSI

2022

Greyhound [55]

Wi-Fi

HIL

OTA

ProcR

 

State

Resp

2022

SGFuzz [15]

General

 

Shared-Memory

  

State & Code Cov

SSI

2022

Braktooth [53]

Bluetooth

HIL

OTA

ProcR

 

State

Resp

2022

SNPSFuzzer [82]

General

 

Socket (P2P)

PSR

UPSR

Code Cov

SSI

2022

Nyx-net [142]

General

CUVM

File

VMSR

VMSR

Code Cov

HA/SSI

2022

SnapFuzz [9]

General

 

UDS

PSR

IMFR

Code Cov

SSI

2022

AmpFuzz [79]

UDP

 

Socket (P2P)

  

BAF & Code Cov

Resp & SSI

2022

L2Fuzz [120]

Bluetooth L2CAP

HIL

OTA

  

State

Resp

2022

Song et al. [156]

SOME/IP [14]

HIL

CAN Bus

  

State

Resp

2022

Charon [201]

ICS

 

Socket (MiTM)

  

State & Code Cov

Resp & SSI

2023

FieldFuzz [21]

Codesys v3

CUVM

Socket

RM

 

Code Cov

Resp

2023

BLEEM [90]

General

 

Socket (MiTM)

RM

 

State

Resp

2023

NS-Fuzz [127]

General

 

Socket (P2P)

PSR

UPSR

State & Code Cov

SSI

2023

HNPFuzzer [51]

General

 

Shared-Memory

PSR

   
 
 

 

 

توضیحات جدول:

o: فازر جعبه سفید (Whitebox Fuzzer)
●: فازر جعبه سیاه (Blackbox Fuzzer)
◑: فازر جعبه خاکستری (Greybox Fuzzer)
Tax: رده‌بندی / طبقه‌بندی (Taxonomy)
HIL: سخت‌افزار در حلقه (Hardware-In-the-Loop)
General: فازر برای نوع خاصی از پروتکل طراحی نشده است
CUVM: ماشین مجازی متداول (Commonly Used Virtual Machine)
SE: شبیه‌سازی تخصصی (Specialized Emulation)
OTA: ارتباط یا انتقال از طریق هوا / بی‌سیم (Over-the-Air)
UDS: سوکت دامنه یونیکس (Unix Domain Socket)
MiTM: تزریق بسته مبتنی بر حمله مرد میانی (Man-in-the-Middle-based packet injection)
VMSR: مکانیزم Snapshot و بازیابی در سطح ماشین مجازی (Virtual Machine-level Snapshot and Recovery)
ProcR: راه‌اندازی مجدد فرایند (Process Restart)
PhyR: بازنشانی فیزیکی (Physical Reset)
ThrdR: راه‌اندازی مجدد نخ اجرایی (Thread Restart)
DR: بازنشانی پایگاه داده (Database Reset)
PSR: مکانیزم Snapshot و بازیابی در سطح فرایند (Process-level Snapshot and Recovery)
UPSR: بازنشانی با اسکریپت ارائه‌شده توسط کاربر (User-Provided Script Reset)
HA: مکانیزم مبتنی بر سخت‌افزار (Hardware-Assisted mechanism)
EOB: روش مبتنی بر رفتار قابل مشاهده خارجی (Externally-Observable-Behavior-based method)
SDI: ابزارسازی دینامیک نرم‌افزار (Software Dynamic Instrumentation)
SSI: ابزارسازی استاتیک نرم‌افزار (Software Static Instrumentation)
BAF: ضریب تقویت پهنای باند (Bandwidth Amplification Factor)

– : پیاده‌سازی نشده (Not implemented)
RM: پیام بازنشانی (Reset Message)
IMFR: بازنشانی سیستم فایل در حافظه (In-Memory Filesystem Reset)
Resp: پاسخ‌ها (Responses)

با این حال، دو چالش اصلی استفاده از شبیه‌سازی (Emulation) در فازینگ پروتکل وجود دارد:

  1. دسترسی به باینری پیاده‌سازی پروتکل: بسیاری از تصاویر فریمور (firmware) به‌صورت عمومی در دسترس نیستند.
  2. تنوع سخت‌افزار: شبیه‌سازهای موجود تنها می‌توانند بخش کوچکی از سخت‌افزارها را پشتیبانی کنند، در حالی که تنوع سخت‌افزاری بسیار بالاست.

این محدودیت‌ها باعث شده‌اند که هنوز بسیاری از پژوهش‌ها فازینگ را به روش سخت‌افزار در حلقه (Hardware-in-the-Loop) انجام دهند (در جدول ۵، ستون ۴ با عنوان “HIL” مشخص شده است) [47, 55, 56, 58, 90, 113]. برخی پژوهش‌ها نیز سعی کرده‌اند این مشکلات را با توجه به ویژگی‌های دستگاه‌های مختلف حل کنند (در جدول ۵، ستون ۴ با عنوان “SE” مشخص شده است).

برای چالش اول، پژوهش‌های موجود باینری هدف را از طریق رهگیری به‌روزرسانی‌های فریمور (firmware) از راه دور (OTA) یا استخراج با استفاده از دستورات یا پورت‌های دیباگ خاص فروشنده به‌دست می‌آورند.

به عنوان مثال، Frankenstein از مکانیزم Patchram استفاده می‌کند؛ این یک دستور اختصاصی فروشنده Broadcom است که امکان نصب موقت breakpoint روی ROM را فراهم می‌کند. با این روش، Snapshot حافظه یک چیپ بلوتوث فیزیکی گرفته شده و در نسخه بدون تغییر QEMU شبیه‌سازی می‌شود.

برای چالش دوم، اغلب از روشی به نام Rehosting استفاده می‌شود تا عملکرد بخشی از سخت‌افزار فیزیکی به‌طور جزئی شبیه‌سازی شود.

برای مثال، BaseSafe چندین تابع پردازش پیام‌های سیگنالینگ را انتخابی بازشبیه‌سازی (selectively rehost) می‌کند و از Unicorn Engine، یک شبیه‌ساز محبوب CPU، برای این منظور استفاده می‌کند [122].

      ۵.۱.۲ کاهش هزینه اجرا (Execution Cost Reduction)

جهت دیگر برای افزایش کارایی فازینگ، بهینه‌سازی مراحل میانی اجرای هر تکرار است. در ادامه، پیشرفت‌های پژوهش‌های موجود در این زمینه بررسی می‌شود که عمدتاً بر سه زیرفرآیند تمرکز دارند:

  • تغذیه ورودی (Input Feeding, ② در شکل ۶)
  • بازنشانی اجرا (Execution Reset, ④ در شکل ۶)

تغذیه ورودی (Input Feeding). مکانیزم تغذیه ورودی مانند یک خط لوله (pipeline) بین مولد ورودی (input generator) و برنامه تحت آزمون (PUT) عمل می‌کند و موارد آزمون (Testcase) را برای پردازش و اجرا به PUT منتقل می‌کند.

با توجه به مکانیزم‌های ارتباط بین فرایندی (Inter-Process Communication – IPC) که فازر و PUT از آن‌ها استفاده می‌کنند، روش‌های موجود را می‌توان تقریباً به چهار دسته تقسیم کرد:

  1. مبتنی بر OTA (OTA-based)
  2. مبتنی بر سوکت (Socket-based)
  3. مبتنی بر حافظه مشترک (Shared-memory-based)
  4. مبتنی بر فایل (File-based)

روش‌های OTA و سوکت معمولاً زمانی استفاده می‌شوند که فازر و PUT نتوانند روی یک دستگاه فیزیکی مستقر شوند. دو روش بعدی (حافظه مشترک و فایل) زمانی کاربرد دارند که PUT و فازر روی یک دستگاه قرار گیرند، زیرا سرعت تغذیه ورودی را به‌طور قابل توجهی افزایش می‌دهند.

  • تغذیه ورودی مبتنی بر OTA (OTA-Based Input Feeding)
    (در جدول ۵، ستون ۵ با عنوان “OTA” مشخص شده است). به طور کلی، مکانیزم‌های تغذیه ورودی مبتنی بر OTA عمدتاً در سناریوهایی استفاده می‌شوند که پیاده‌سازی پروتکل‌ها به‌طور طبیعی بسته و به سخت‌افزار وابسته هستند. نمونه‌هایی از این پروتکل‌ها شامل Wi-Fi [55, 141, 158]، Bluetooth (شامل کلاسیک و BLE) [53, 56, 113]، LTE [93]، 4G/5G [54, 63] و SMS/MMS [58] هستند. در این روش، PUT و فازر باید در فضاهای فیزیکی مجاور مستقر شوند و بر روی باندهای فرکانسی مشخص با یکدیگر ارتباط برقرار کنند. بنابراین، فازرهای مبتنی بر OTA نیازمند استفاده از دستگاه‌های فرستنده/گیرنده رادیویی با قابلیت ارسال و دریافت سیگنال هستند، مانند Software-Defined Radio (SDR)، که امکان پردازش سیگنال‌ها در دامنه فرکانسی وسیع را فراهم می‌کند. مزیت فازینگ مبتنی بر OTA این است که امکان آزمون کل پشته پروتکل، از جمله لایه فیزیکی (physical layer) را فراهم می‌کند. با این حال، روش‌های مبتنی بر OTA کندترین روش‌ها در میان روش‌های گفته‌شده هستند. بنابراین، بسیاری از فازرهای پروتکل بی‌سیم تلاش می‌کنند از سایر مکانیزم‌های تغذیه ورودی استفاده کنند تا عملکرد بهتری داشته باشند، که در بخش‌های بعدی معرفی خواهند شد.
  • تغذیه ورودی مبتنی بر سوکت (Socket-Based Input Feeding)
    (در جدول ۵، ستون ۵ با عنوان “Socket” مشخص شده است). مکانیزم‌های تغذیه ورودی مبتنی بر سوکت عمدتاً در پیاده‌سازی پروتکل‌های مبتنی بر زیرساخت TCP/IP استفاده می‌شوند. در حالت معمول، فازر و PUT از طریق آدرس‌های IP و مکانیزم سوکت، شامل TCP socket و UDP socket، با یکدیگر ارتباط برقرار می‌کنند. روش‌های مبتنی بر سوکت شامل دو حالت استقرار (deployment mode) می‌باشند. نخست ارتباط نقطه به نقطه (Point-to-Point, P2P) که فازر و PUT مستقیماً با هم ارتباط دارند [9, 27, 48, 81, 99, 106, 116, 159, 187].
    بسته به نقش PUT، فازر می‌تواند نقش کلاینت یا سرور را ایفا کند. دوم، ارتباط میانی (Man-in-the-Middle, MiTM) که در این حالت، فازر به‌عنوان پراکسی بین دو طرف ارتباطی عمل می‌کند و جهش (mutation) یا تزریق بسته‌ها را روی جریان عادی ارتباط انجام می‌دهد [69, 115].
    روش MiTM بیشتر زمانی کاربرد دارد که پروتکل شامل اطلاعات زمینه‌ای خاص مانند جمع‌آزما (checksum) یا ترتیب بسته‌ها باشد که با تغییر مستقیم بذرهای ایستا (static seeds) نمی‌توانند معتبر باقی بمانند. با این حال، هر دو حالت با دو چالش اصلی مواجه هستند. اولین چالش سنگینی ارتباط سوکتی است. ارتباط سوکت نیازمند سوئیچ‌های زمینه (context switch) زیادی است که هزینه بالایی دارد.
    پژوهش‌های موجود با اجتناب از توابع شبکه‌ای پرهزینه، کارایی مکانیزم‌های تغذیه ورودی مبتنی بر سوکت را بهبود داده‌اند. به عنوان مثال، SnapFuzz [9] سوکت اینترنتی اصلی را با UNIX Domain Socket [34] جایگزین می‌کند؛ این یک مکانیزم IPC سبک است که عملیات مسیریابی و محاسبه جمع‌آزما سوکت‌های IP را ندارد. چالش دوم، مشخص نبودن آمادگی PUT برای دریافت پیام بعد است. PUT ممکن است پیام‌هایی که خیلی زود ارسال شده‌اند را رد کند، زیرا هنوز آماده دریافت پیام بعدی نیست، که این موضوع باعث همگام‌نبودن فازر با ماشین حالت خود می‌شود. برای حل این مشکل، Fiterau-Brostean et al. [48] و AFLNET [116] از فواصل زمانی ایستا (static intervals) برای انتظار جهت آماده‌سازی PUT، پردازش درخواست‌ها و ارسال پاسخ‌ها استفاده کردند. با این حال، تایمرهای ایستا باعث هدررفت زمان انتظار برای timeout می‌شوند، که روند فازینگ را کند می‌کند. برای بهبود این موضوع SnapFuzz [9] و AMPFuzz [78] روش جزئی‌تر و دقیق‌تری برای بررسی وضعیت سوکت توسعه دادند. به طور مشخص، آن‌ها از فراخوانی توابع مرتبط با سیستم شبکه مانند ()recv و ()recvfrom به‌ عنوان نشانه آماده بودن برای دریافت پیام بعدی استفاده می‌کنند. این فراخوانی‌ها از طریق بازنویسی باینری و ابزارگذاری کد در زمان کامپایل (compile-time code instrumentation) رصد می‌شوند و سپس فازر برای ارسال ورودی تکرار بعدی مطلع می‌شود.
  • تغذیه ورودی مبتنی بر فایل (File-Based Input Feeding)
    (در جدول ۵، ستون ۵ با عنوان “File” مشخص شده است). مکانیزم تغذیه ورودی مبتنی بر فایل از تکنیک‌های ابزارگذاری ایستا یا پویا (static/dynamic instrumentation) استفاده می‌کند تا عملیات‌های سنگین شبکه‌ای را با عملیات فایل جایگزین کند و بهبود عملکرد را فراهم آورد. به عنوان مثال، Yurong et al. [30] در شرایطی که کد منبع هدف در دسترس نیست، با استفاده از کتابخانه‌های سفارشی پیش‌بارگذاری‌ شده  (preloading customized libraries) [175]، ارتباط سوکت را به عملیات فایل تبدیل می‌کنند. مشابه آن، Nyx-net [134] یک کتابخانه به هدف تزریق می‌کند تا توابع شبکه‌ای مربوط به ارتباط هدف را hook کند، شناسه فایل‌های مرتبط (file descriptors) را به‌دست آورد و ورودی‌های فازینگ را به مکان مناسب تزریق کند. این روش به فازر اجازه می‌دهد هزینه‌های پردازش شبکه را کاهش داده و سرعت تغذیه ورودی را افزایش دهد، بدون آنکه نیاز به تغییر در کد منبع اصلی وجود داشته باشد.
  • تغذیه ورودی مبتنی بر حافظه مشترک (Shared-Memory-Based Input Feeding)
    (در جدول ۵، ستون ۵ با عنوان “Shared-Memory” مشخص شده است). مکانیزم تغذیه ورودی مبتنی بر حافظه مشترک، ورودی فازینگ را در آدرس حافظه مشترک می‌نویسد و توابع مرتبط را hook می‌کند تا تست‌کیس‌ها از حافظه مشترک خوانده شوند [17, 51, 93, 130]. به عنوان مثال، BaseSafe [93] هر تست‌کیس تولیدشده را در یک نسخه fork شده از فرایند هدف اجرا می‌کند و ورودی هر اجرا را به آدرس مناسب در فرایند فرزند مربوطه کپی می‌کند. به طور مشابه، Frankenstein [130] یک مودم مجازی ایجاد می‌کند تا بسته‌های سفارشی را تزریق کند. ورودی‌های فاز شده در بافر دریافت در RAM نوشته می‌شوند که با استفاده از دسترسی مستقیم به حافظه (DMA) به بافر سخت‌افزار نگاشت شده است. همچنین، HNPFuzzer [51] توابع شبکه را بر اساس حافظه مشترک شبیه‌سازی می‌کند تا زمان مصرف‌ شده برای انتقال پیام بین فازر و PUT کاهش یابد. این روش به‌ طور قابل توجهی هزینه‌های اجرای ورودی و زمان ارتباط بین فرایندها را کاهش می‌دهد، مخصوصاً زمانی که فازر و PUT روی یک دستگاه فیزیکی یا مجازی قرار دارند.
  • سایر روش‌ها. برخی پژوهش‌ها نیز از کانال‌های ارتباطی تخصصی برای تغذیه ورودی فازینگ استفاده می‌کنند. به عنوان مثال، برای فازینگ کلاینت پروتکل Remote Desktop Protocol (RDP)، Park et al. [112] از کانال مجازی (virtual channel) استفاده می‌کنند؛ این یک لایه انتزاعی در RDP است که برای انتقال داده‌ها به‌کار می‌رود و آن‌ها با استفاده از آن، ورودی فازینگ را به‌صورت فعال از سرور به کلاینت ارسال می‌کنند. همچنین، Song et al. [145] از مبدل رسانه (media converter) برای تبدیل ترافیک بین Automotive Ethernet و Gigabit Ethernet استاندارد استفاده کرده و پشته پروتکل SOME/IP را در واحد کنترل الکترونیکی (ECU) فازینگ می‌کنند. SOME/IP پروتکل ارتباط کنترل بین ECUها است. این روش‌ها نشان می‌دهند که برخی فازرها برای تغذیه ورودی‌های خاص، به کانال‌های سخت‌افزاری یا نرم‌افزاری تخصصی وابسته هستند تا بتوانند ورودی‌ها را به طور مستقیم به هدف منتقل کنند و محدودیت‌های روش‌های عمومی (OTA، سوکت، فایل یا حافظه مشترک) را دور بزنند.

بازنشانی اجرا (Execution Reset). پس از هر تکرار اجرای فازینگ، بازنشانی PUT به یک حالت مشخص و آماده‌سازی برای تکرار بعدی ضروری است. دلیل این کار این است که هر مورد آزمون می‌تواند هم وضعیت داخلی اجرای PUT (مانند متغیرهای سراسری) و هم محیط اجرایی آن (مانند سیستم فایل یا پایگاه داده) را تحت تأثیر قرار دهد. اگر اجرا بدون بازنشانی انجام شود، رفتار PUT غیرقطعی‌تر (non-deterministic) می‌شود و بازتولید باگ‌ها دشوارتر خواهد بود . برای مثال، هنگام فازینگ یک سرور FTP، یک تست‌کیس ممکن است باعث ایجاد فایلی در یک پوشه مشترک شود. اگر پوشه مشترک بازنشانی نشود، سرور FTP خطا گزارش می‌دهد اگر مورد آزمون بعدی تلاش کند فایلی با همان نام ایجاد کند. در نتیجه، همان تست‌کیس می‌تواند رفتار متفاوتی از PUT ایجاد کند.

بازنشانی اجرا شامل سه مرحله کلیدی است:

  1. انتخاب زمان بازنشانی (Reset Time Selection): ابتدا اجرا کننده باید تشخیص دهد که آیا تکرار جاری به پایان رسیده است یا خیر.
  2. بازنشانی وضعیت اجرایی (Execution State Reset): پس از تأیید پایان تکرار، اجرا کننده باید وضعیت زمان اجرای داخلی PUT را بازنشانی کند.
  3. بازنشانی محیط اجرایی (Execution Environment Reset): همچنین باید تأثیر مورد آزمون روی محیط خارجی، مانند سیستم فایل یا پایگاه داده، بازنشانی شود.

در ادامه، پیشرفت‌های پژوهش‌های موجود در هر یک از این سه مرحله کلیدی به طور جداگانه جمع‌بندی شده است.

(۱) انتخاب زمان بازنشانی (Reset Time Selection). انتخاب زمان مناسب برای بازنشانی تأثیر قابل توجهی بر کارایی فازینگ دارد. بازنشانی زودهنگام ممکن است باعث شود که هدف (PUT) در حالی که هنوز در حال انجام برخی وظایف آسیب‌پذیر است، قطع شود. بازنشانی دیرهنگام می‌تواند کارایی تست را کاهش دهد. یک روش معمول، تنظیم یک بازه زمانی ثابت قبل از بازنشانی اجرا است. به عنوان مثال، AFLNET [116] به کاربر امکان می‌دهد تأخیر زمانی قبل از راه‌اندازی مجدد PUT را به صورت دستی تنظیم کند. با این حال، در این روش تعیین بازه زمانی مناسب دشوار است. برای کنترل دقیق‌تر زمان بازنشانی، برخی پژوهش‌ها از تحلیل برنامه (program analysis) استفاده می‌کنند تا مکان‌هایی که پایان اجرای یک تکرار را نشان می‌دهند شناسایی کرده و برنامه هدف را برای خاتمه در آن نقاط کد ابزارگذاری (instrument) کنند [9, 78, 120, 134]. به عنوان مثال، AMPFuzz [78] تحلیل استاتیک انجام می‌دهد و فراخوانی‌های خاتمه (termination calls) را به شاخه‌های کدی که APIهای ارسال پیام ندارند تزریق می‌کند. برخی پژوهش‌ها نیز برای افزایش کارایی تصمیم می‌گیرند پس از هر تکرار فازینگ بازنشانی اجرا انجام ندهند. Charon [188] از یک ماژول استنتاج وضعیت برنامه (program status inferring module) استفاده می‌کند تا زمانی که PUT پردازش بسته را به پایان رسانده است را تشخیص دهد، به این ترتیب پوشش ورودی‌های خاص شناسایی شده و نیاز به راه‌اندازی مجدد مکرر PUT برای جمع‌آوری بازخورد کاهش می‌یابد. مشابه آن، SGFuzz [15] در هر تکرار PUT را بازنشانی نمی‌کند، اما پس از تحلیل (post-analysis)، ورودی‌ها را بررسی می‌کند تا رفتار غیرقطعی (non-deterministic) حذف شود. به طور مشخص، همه ورودی‌هایی که PUT روی آن‌ها اجرا شده جمع‌آوری شده و لیست ورودی‌ها به یک توالی پیام حداقلی کاهش می‌یابد که قادر به تحریک باگ است.

(۲) بازنشانی وضعیت اجرا (Execution State Reset). بازنشانی وضعیت اجرایی مسئول بازگرداندن زمینه اجرای فرایند PUT به یک حالت مشخص است، که شامل داده‌های رجیسترها، حافظه و سایر اجزای مرتبط می‌شود. مکانیزم‌های موجود برای بازنشانی وضعیت اجرایی شامل چند روش مختلف است. یکی از آن‌ها بازنشانی مبتنی بر پیام است که با ارسال نوع خاصی از پیام، PUT را مجبور می‌کند جلسه جاری را خاتمه دهد و به حالت اولیه بازگردد [21, 48, 158]. به عنوان مثال، هنگام فازینگ یک Wi-Fi Access Point (AP)، WiFuzz [158] از پیام deauthentication برای بازنشانی وضعیت استفاده می‌کند. این روش ساده است، اما تنها از پروتکل‌هایی پشتیبانی می‌کند که دارای پیام بازنشانی هستند و تنها وضعیت صریح پروتکل را بازنشانی می‌کند؛ وضعیت ضمنی مانند متغیرهای سراسری یا حافظه‌ای که تخصیص داده شده اما آزاد نشده، قابل بازنشانی با این روش نیست.

روش دیگر متداول، راه‌اندازی مجدد فرایند است که در آن فرایند هدف متوقف و مجدداً راه‌اندازی می‌شود [27, 46, 91]. این روش نسبتاً سنگین است، زیرا راه‌اندازی مجدد برنامه شامل مراحل پردازشی پرهزینه‌ای مانند بارگذاری برنامه در حافظه و لینک دینامیک است که باعث کاهش کارایی فازینگ می‌شود. یک روش دیگر که اخیراً در فازینگ پروتکل‌ها کاربرد یافته، مکانیزم Snapshot & Recovery است. در این روش، PUT در یک وضعیت مشخص اجرا checkpoint می‌شود و پس از هر تکرار فازینگ، به همان وضعیت بازنشانی می‌شود. این کار باعث می‌شود از اجرای مکرر عملیات‌های زمان‌بر اولیه جلوگیری شده و کارایی فازینگ بهبود یابد. پروتکل‌ها به طور عمده stateful هستند و ورودی‌ها معمولاً شامل چند پیام پیشوند هستند که PUT را به حالت مشخصی هدایت می‌کنند قبل از اعمال پیام crafted. بسیاری از تست‌کیس‌ها دنباله پیام‌های پیشوند مشابهی دارند، به ویژه وقتی که یک حالت خاص نیاز به اکتشاف مکرر دارد. استفاده از Snapshot باعث حذف اجرای تکراری پردازش این بسته‌های مشترک می‌شود و کارایی فازینگ را به طور چشمگیری افزایش می‌دهد. روش‌های Snapshot در تحقیقات فعلی به طور کلی شامل Snapshot در سطح فرایند و Snapshot در سطح ماشین مجازی هستند.

مکانیزم‌های Snapshot در سطح فرایند (Process-Level Snapshot, PSR) که در جدول ۵ ستون ۶ با عنوان “PSR” مشخص شده‌اند، بر قابلیت‌های فراخوانی سیستمی (system call) ارائه‌ شده توسط سیستم‌عامل تکیه دارند تا عملکرد خود را پیاده‌سازی کنند. به طور کلی، بر اساس APIهای استفاده‌شده، روش‌های موجود را می‌توان به دو نوع تقسیم کرد: مکانیزم‌های مبتنی بر fork و مکانیزم‌های مبتنی بر ptrace.

مکانیزم‌های fork-based به طور گسترده در چند فازر شناخته‌شده عمومی، از جمله AFL [174] استفاده می‌شوند. به طور مشخص، AFL یک کد fork-server را در باینری برنامه PUT قرار می‌دهد که قبل از تابع ()main اجرا می‌شود. پس از دریافت سیگنال از سمت فازر AFL، fork-server یک فرایند فرزند (child process) با استفاده از تابع ()fork ایجاد می‌کند و این فرایند فرزند ادامه اجرای تابع ()main را بر عهده می‌گیرد. از آنجایی که fork-server قبلاً تمام منابع مورد نیاز را بارگذاری کرده است، هر فرایند فرزند تنها نیاز دارد کد تابع ()main را اجرا کند، که باعث عبور از مراحل پردازش اولیه پرهزینه و افزایش کارایی می‌شود.

این مکانیزم توسط بسیاری از فازرهای پروتکل برای بازنشانی حالت‌ها به کار رفته است [9, 51, 81, 90, 93, 106, 116, 120]. علاوه بر این، برخی پژوهش‌ها مکانیزم fork-server اصلی AFL را توسعه داده‌اند تا امکان چندین مقداردهی اولیه شرطی در نقاط مختلف کد فراهم شود، که اجازه می‌دهد فازر به راحتی بین حالت‌های مختلف پروتکل جابه‌جا شود و فرآیند فازینگ را بهبود بخشد [9, 30].

مکانیزم‌های ptrace-based snapshot، مانند CRIU و DMTCP، از API دیباگ ptrace() استفاده می‌کنند تا تمام اطلاعات زمینه فرایند را جمع‌آوری کرده و به صورت فایل‌های تصویری (image files) ذخیره کنند [81]. در فرآیند بازیابی، این مکانیزم‌ها فایل‌های استخراج شده را خوانده و با استفاده از فراخوانی‌های سیستمی (system call) مانند ()fork یا ()clone فرایند را بازسازی می‌کنند.

برخلاف snapshotهای مبتنی بر fork که نیازمند شرایط از پیش تعیین‌شده برای snapshot (یعنی مکان فراخوانی fork-server) قبل از اجرا هستند، snapshotهای مبتنی بر ptrace می‌توانند در هر وضعیت طی اجرای برنامه نقطه بررسی (checkpoint) ایجاد کنند.

مکانیزم‌های Snapshot در سطح ماشین مجازی (Virtual-Machine-Level Snapshot, VMSR) که در جدول ۵ ستون ۶ با عنوان “VMSR” مشخص شده‌اند، از قابلیت‌های هایپروایزر ماشین مجازی برای گرفتن Snapshot از کل ماشین مجازی در یک نقطه زمانی مشخص استفاده می‌کنند، که معمولاً از طریق hypercalls انجام می‌شود [134, 138]. زمانی که hypercall فراخوانی می‌شود، برنامه‌ای که درون ماشین مجازی اجرا می‌شود، از زمینه VM خارج شده و کنترل به هایپروایزر منتقل می‌شود.

اگرچه روش مبتنی بر هایپروایزر کاربرپسند است و نیاز به ابزارسازی ندارد، اما به دلیل دانه‌بندی بزرگ (large granularity)، کمی کم‌بازده و مصرف‌کننده فضای بیشتری است.

برای افزایش کارایی استفاده از snapshotهای سطح ماشین مجازی در فازینگ پروتکل‌ها، Nyx-net [134] یک رویکرد snapshot تدریجی (incremental snapshot) پیاده‌سازی کرده است تا بار اضافی ایجاد و حذف snapshotها کاهش یابد. به طور مشخص، Nyx-net یک snapshot ریشه‌ای (root snapshot) در حالت اولیه ایجاد می‌کند و هر تکرار اجرا از این snapshot ریشه آغاز می‌شود. در تکرارهای بعدی فازینگ، Nyx-net snapshotهای تدریجی بر اساس snapshot ریشه و پس از اجرای پیام ورودی ایجاد می‌کند.

نتیجه این روش، افزایش قابل توجه کارایی در تست‌کیس‌هایی است که دنباله پیام پیشوند مشابه دارند، زیرا بخش مشترک اجرای پروتکل دیگر به طور مکرر پردازش نمی‌شود.

(۳) بازنشانی محیط اجرایی  (Execution Environment Reset). بازنشانی محیط اجرایی عمدتاً شامل بازگرداندن سیستم فایل یا پایگاه داده است که ممکن است توسط PUT تحت تأثیر قرار گرفته باشند. بسیاری از فازرها از کاربران می‌خواهند تا اسکریپت پاک‌سازی (cleanup script) ارائه دهند تا تمامی تغییرات بازگردانده شوند [51, 81, 106, 116, 120]، که این کار نیازمند تلاش دستی قابل توجه برای تحلیل تأثیرات احتمالی PUT بر محیط خارجی است. برای حل این مشکل، SnapFuzz [9] از یک سیستم فایل در حافظه (in-memory filesystem) سفارشی استفاده می‌کند، به طوری که تغییرات به‌صورت خودکار پس از پایان هر تکرار فازینگ حذف می‌شوند. علاوه بر این، مکانیزم snapshot مبتنی بر هایپروایزر (VMSR در جدول ۵ ستون ۷)  [134]، که وضعیت کل ماشین مجازی را ضبط می‌کند، قادر است هم وضعیت اجرایی و هم محیط اجرایی را به‌طور همزمان بازنشانی کند.

۵.۲ استخراج اطلاعات زمان اجرا (Runtime Information Extraction)

به‌طور کلی، روش‌های استخراج اطلاعات زمان اجرا که در پژوهش‌های موجود استفاده شده‌اند، بر اساس میزان عمومی‌ بودن (generality) به سه دسته تقسیم می‌شوند.

روش‌های مبتنی بر سخت‌افزار (Hardware-Assisted methods) (در ستون ۹ جدول ۵ با برچسب HA مشخص شده‌اند). این روش‌ها از قابلیت‌های ویژهٔ برخی سخت‌افزارهای تخصصی برای استخراج اطلاعات زمان اجرا استفاده می‌کنند. نمونهٔ شاخص این روش در Nyx-net [134] دیده می‌شود که از Intel Processor Trace (Intel PT) بهره می‌برد. این قابلیت که در برخی پردازنده‌های پیشرفتهٔ Intel وجود دارد، امکان ثبت دقیق جنبه‌های اجرای نرم‌افزار مانند مسیرهای جریان کنترل (control flow paths) را فراهم می‌کند. در نتیجه، می‌توان اطلاعات پوشش اجرایی بسیار دقیق و عمیق را جمع‌آوری کرد.

روش‌های مبتنی بر نرم‌افزار (Software-Based). این روش‌ها از قابلیت‌های محیط اجرای نرم‌افزار مانند کامپایلر، سیستم‌عامل، ماشین مجازی یا هایپروایزر برای به‌دست‌آوردن اطلاعات زمان اجرا استفاده می‌کنند.

رایج‌ترین روش برای این کار ابزارگذاری برنامه (Program Instrumentation) است. در این روش، فراخوانی‌های جمع‌آوری اطلاعات در نقاط مشخصی از کد برنامه درج می‌شوند.

ابزارگذاری برنامه به دو نوع تقسیم می‌شود:

  • ابزارگذاری ایستا (Static Software Instrumentation – SSI)
    (در ستون ۹ جدول ۵ با برچسب SSI)
  • ابزارگذاری پویا (Static Software Instrumentation – SDI)
    (در ستون ۹ جدول ۵ با برچسب SDI)

ابزارگذاری ایستا قبل از اجرای PUT انجام می‌شود و می‌تواند به دو صورت انجام گیرد. یکی در زمان کامپایل (compile-time) [15, 81, 90, 91, 99, 106, 116, 125, 134, 187] و دیگری با بازنویسی مستقیم باینری برنامه [9]. در مقابل، ابزاردقیق‌سازی پویا در حین اجرای PUT انجام می‌شود و از ابزارهایی مانند DynamoRIO [112] یا Frida [64] استفاده می‌کند تا با تزریق توابع hook در نقاط مشخص کد، اطلاعات زمان اجرا جمع‌آوری شود.

روش‌های مبتنی بر رفتار قابل مشاهده از بیرون، عمومی‌ترین کلاس روش‌ها هستند، زیرا نیازی به پشتیبانی از محیط اجرای برنامه ندارند و می‌توانند به‌ صورت جعبه‌ سیاه (Black-Box) استفاده شوند. رفتارهای قابل مشاهدهٔ مختلفی وجود دارند، مانند خروجی برنامه (در جدول ۵ ستون ۹ با برچسب “Resp”) و اطلاعات کانال جانبی مانند مصرف انرژی و زمان پاسخ. منطق پشت این روش‌ها این است که تفاوت‌ها در این رفتارها می‌توانند نشان‌دهندهٔ این باشند که PUT در حالت‌های مختلف است یا مسیرهای اجرایی متفاوتی را طی کرده است. به‌طور مشخص، AFLNET [116] و Fieldfuzz [21] وضعیت‌های مختلف پروتکل را بر اساس کد وضعیت در پیام‌های پاسخ تشخیص می‌دهند. Snipuzz [47] و FUME [114] از این اکتشاف استفاده می‌کنند که پیام‌های پاسخ متفاوت به معنای مسیرهای اجرایی متفاوت هستند. بنابراین، ورودی‌هایی که باعث پاسخ متفاوت می‌شوند را به‌ عنوان بذر برای آزمون جهشی بعدی نگه می‌دارند تا پوشش افزایش یابد. Aafer و همکاران [3] از لاگ‌های اجرای سیستم اندروید به‌عنوان بازخورد برای بهبود گرامرهای تولید ورودی استفاده می‌کنند، زیرا توسعه‌دهندگان معمولاً عبارات لاگ را برای ارائه جزئیات در مورد اعتبارسنجی ورودی‌ها اضافه می‌کنند. با مشاهده اطلاعات کانال جانبی مانند وضعیت سیستم، مصرف انرژی و زمان پاسخ، Flowfuzz [140] تعیین می‌کند که سخت‌افزار مسیرهای اجرایی متفاوتی را طی کرده است یا خیر.

۶. جمع‌آوری‌کنندهٔ باگ (Bug Collector)

برای مقابله با چالش‌های فازینگ پروتکل‌ها، پژوهش‌های موجود هم اوراکل‌های باگ‌های مرتبط با حافظه و هم اوراکل‌های باگ‌های غیر مرتبط با حافظه را بر اساس منابع اطلاعاتی مختلف طراحی کرده‌اند.

   ۶.۱ اوراکل‌های باگ ایمنی حافظه‌ (Memory-Safety Bug Oracles)

برای مقابله با چالش‌های فازینگ پروتکل‌ها، پژوهش‌های موجود هم اوراکل‌های باگ‌های ایمنی حافظه‌ای (Memory-Safety Bug Oracles) و هم اوراکل‌های باگ‌های ایمنی غیر حافظه‌ای (Non-Memory-Safety Bug Oracles) را بر اساس منابع اطلاعاتی مختلف طراحی کرده‌اند.

باگ‌های حافظه‌ای شامل سرریز پشته (stack overflow)، سرریز هیپ (heap overflow)، استفاده مجدد از حافظه پس از آزادسازی (Use-After-Free) و غیره هستند که می‌توانند منجر به کرش (Crash) برنامه شوند. فناوری‌های موجود عمدتاً وضعیت اجرای برنامه را از طریق کانال‌های مختلف مشاهده می‌کنند تا تعیین کنند که آیا یک باگ حافظه‌ای رخ داده است یا خیر. از منظر منبع اطلاعاتی، پنج نوع رایج اوراکل برای تشخیص باگ‌های حافظه‌ای وجود دارد:

  1. سیگنال‌های مرگ‌آور و سنی‌تایزرها (Fatal Signals and Sanitizers)
  2. گزارش‌های کرش و اطلاعات دیباگ (Crash Logs and Debug Information)
  3. پیام‌های خطا (Error-Signaling Messages)
  4. بررسی‌های زمان‌بندی و زنده بودن (Timeout and Liveness Checks)
  5. رفتارهای فیزیکی غیرعادی (Abnormal Physical Behaviors)

      ۶.۱.۱ سیگنال‌های مرگ‌آور و سنی‌تایزرها (Fatal Signals and Sanitizers)

این روش‌ها به‌ طور گسترده به‌ عنوان مکانیزمی حیاتی برای تشخیص باگ در مطالعات متعدد استفاده شده‌اند [15, 90, 91, 106, 118, 125, 130, 142, 187]. به طور عمده، باگ‌های حافظه‌ای با بازنویسی داده‌ها یا اشاره‌گرهای کد با مقادیر نامعتبر ظاهر می‌شوند، که منجر به اختلالات بحرانی در فرآیند مانند خطای قطعه‌بندی (segmentation fault) یا خاتمه فرآیند می‌شوند و در نتیجه سیگنال‌های مرگ‌آوری مانند SIGSEGV، SIGABRT و دیگر سیگنال‌ها تولید می‌کنند. فازرها با بررسی اینکه آیا فرآیند PUT به موجب این سیگنال‌ها کرش (Crash) کرده است یا خیر، این خطاها را تشخیص می‌دهند.

برای بخشی از باگ‌های حافظه‌ای که فوراً باعث کرش برنامه نمی‌شوند، فازرها از سنی‌تایزرها استفاده می‌کنند. سنی‌تایزرها ابزارهای تشخیص باگ هستند که برای شناسایی دسترسی‌های ناامن یا نامطلوب به حافظه طراحی شده‌اند. هنگامی که چنین ناهنجاری‌هایی شناسایی می‌شوند، سانیتایزرها PUT را خاتمه می‌دهند و وجود باگ بالقوه را سیگنال می‌کنند [135, 136, 143, 146].

سنی‌تایزرها می‌توانند در زمان کامپایل فعال شوند [15, 90, 91, 106, 125, 130, 142, 187] یا به‌صورت پویا در زمان اجرا فعال شوند [93].

فازینگ پروتکل
شکل 7. طبقه‌بندی اوراکل‌های باگ در فازینگ پروتکل

      ۶.۱.۲ لاگ‌های کرش و اطلاعات دیباگ (Crash Logs and Debug Information)

برخی از پژوهش‌ها با تحلیل لاگ‌های سیستم یا اطلاعات دیباگ تعیین می‌کنند که آیا PUT کرش کرده است یا خیر [21, 46, 53, 56, 113, 121, 163]. این لاگ‌ها و اطلاعات دیباگ را می‌توان از کانال‌های مختلف به دست آورد. به طور مشخص ICS3Fuzzer از سرویس EventLog ویندوز برای تشخیص رخدادهای کرش در سیستم‌های ویندوز استفاده می‌کند [46]. Sweyntooth [56] و Braktooth [53] پیشنهاد می‌کنند پیام‌های راه‌اندازی یا پیام‌های کرش سیستم را با استفاده از پورت‌های دیباگ بردهای توسعه بلوتوث جمع‌آوری کنند. پیام‌های راه‌اندازی نشان‌دهنده کرش برنامه هستند، زیرا دستگاه‌های بلوتوث دارای برنامه واچ‌داگ هستند که در صورت عدم پاسخ‌دهی، Bluetooth SoC را ریست می‌کند. Wang و همکاران [163] از فناوری پردازش زبان طبیعی (NLP) برای تحلیل لاگ‌ها و شناسایی رفتارهای ناخواسته PUT استفاده می‌کنند. به طور متفاوت، L2Fuzz [113] و FieldFuzz [21] با بررسی اینکه آیا یک crash dump ایجاد شده است، کرش‌ها را شناسایی می‌کنند.

      ۶.۱.۳ پیام‌های اعلام خطا (Error-Signaling Messages – “ESM”)

بسیاری از پروتکل‌ها از پاسخ‌ها یا کدهای وضعیت خاص برای اعلام خطاهای داخلی استفاده می‌کنند و بنابراین می‌توانند برای شناسایی باگ به کار روند. به طور مثال L2Fuzz با بررسی اینکه آیا بسته دریافت شده شامل پیام‌های اعلام خطا مانند Connection Failed، Connection Aborted، Connection Reset و Connection Refused است، آسیب‌پذیری‌های Bluetooth L2CAP را تشخیص می‌دهد [113]. این پیام‌های خطا نشان می‌دهند که ممکن است PUT کرش کرده باشد. OWFuzz از فریم‌های Deauth/Disassoc و فریم‌های مدیریتی Wi-Fi برای خاتمه دادن به ارتباط استفاده می‌کند، که در طول فازینگ پروتکل Wi-Fi نشانگر رفتار غیرعادی محسوب می‌شوند [22].

      ۶.۱.۴ رفتارهای فیزیکی غیرعادی (Abnormal Physical Behaviors – “APB”)

رفتارهای فیزیکی غیرعادی دستگاه هدف، مانند صدای راه‌اندازی (startup sound)، نیز می‌تواند به عنوان oracle برای شناسایی باگ استفاده شود. به عنوان مثال هنگام فازینگ دستگاه‌های صوتی بلوتوث، Braktooth از رخداد تکرار صدای راه‌اندازی به عنوان oracle استفاده می‌کند [53]. دلیل این امر این است که دستگاه‌های بلوتوث هنگام بروز خطا توسط برنامه watchdog مجدداً راه‌اندازی می‌شوند و در طول فرآیند بوت شدن، صدای راه‌اندازی پخش می‌شود. به طور متفاوت، PCFuzzer [88] از یک اسیلوسکوپ (oscilloscope) برای جمع‌آوری سیگنال فیزیکی ماژول خروجی جهت نظارت بر وضعیت هدف استفاده می‌کند.

جدول ۶. فازرهای پروتکل و اوراکل‌های آنها

Year

Work

Tax

Target

Bug Detector

Memory-Safety Bug Oracles

Non-Memory-Safety Bug Oracles

2013

Tsankov et al. [168]

General

Sanitizer

 

2015

Doona [98]

General

Fatal Signals

 

2015

Pulsar [57]

General

Timeout

 

2015

Ruiter et al. [39]

TLS

 

Manual

2015

Beurdouche et al. [18]

TLS

Timeout

Incorrect State Transitions

2016

TLS-Attacker [153]

TLS

Sanitizer

Incorrect State Transitions

2017

WiFuzz [169]

Wi-Fi

Timeout

Incorrect Content & State Transitions

2018

TCPWN [69]

TCP

 

Abnormal Performance Indicators

2018

IoTFuzzer [28]

IoT

Liveness Check

 

2019

SeqFuzzer [194]

ICS

 

Incorrect Content & State Transitions

2019

ACT [162]

TCP

 

Abnormal Performance Indicators

2019

MoSSOT [149]

SSO

Fatal Signals

Incorrect State Transitions

2020

Exploiting Dissent [170]

TLS

 

DE

2020

SweynTooth [56]

BLE

Crash Logs / Timeout

Incorrect State Transition

2020

aBBRate [122]

TCP

 

Abnormal Performance Indicators

2020

DPIFuzz [131]

QUIC

Sanitizer

DE

2020

BaseSAFE [96]

LTE

Sanitizer

 

2021

ICSFuzzer [45]

ICS

Crash Logs

 

2021

TCP-Fuzz [200]

TCP

Fatal Signals

Inconsistency in Transmission & DE

2021

Snipuzz [46]

IoT

Liveness Check

 

2021

PAVFuzz [202]

AV

Fatal Signals

 

2021

Aichernig et al. [4]

MQTT

 

DE

2021

Roitburd et al. [135]

AnyConnect [32]

Liveness Check

 

2021

Owfuzz [23]

Wi-Fi

Liveness Check & ESM

 

2021

BadMesher [128]

Wi-Fi Mesh

Fatal Signals & Liveness Check

 

2022

Meng et al. [103]

General

Fatal Signals

Incorrect State Transitions

2022

Greyhound [55]

Wi-Fi

Fatal Signals / Timeout

Incorrect State Transitions

2022

Braktooth [53]

General

Crash Logs & APB

 

2022

L2Fuzz [120]

Bluetooth L2CAP

Crash Logs & Liveness Check & ESM

Incorrect State Transitions

2022

AmpFuzz [79]

UDP

 

Abnormal Performance Indicators

2022

BrokenMesh [179]

BLE Mesh

Timeout

 

2022

PCFuzzer [86]

PLC

Liveness Check & APB

 

2023

FieldFuzz [21]

Codesys v3

ESM & Crash Logs & Timeout

 

2023

Tyr [31]

Blockchain

 

Incorrect State Transitions

2023

LOKI [93]

Blockchain

Fatal Signals

Incorrect State Transitions

2023

Wang et al. [174]

General

Crash Logs

 

2023

DYFuzzing [7]

General

Sanitizer

Incorrect Content & State Transitions

2023

ResolFuzz [20]

DNS

 

DE

 
 

 

 

توضیحات جدول:

o: فازر جعبه سفید (Whitebox Fuzzer)
●: فازر جعبه سیاه (Blackbox Fuzzer)
◑: فازر جعبه خاکستری (Greybox Fuzzer)
Tax: رده‌بندی / طبقه‌بندی (Taxonomy)
General: فازر برای نوع خاصی از پروتکل طراحی نشده است

– : قابل تشخیص نیست (Not detectable)
ESM: پیام‌های سیگنال‌دهنده خطا (Error-Signaling Messages)
APB: رفتارهای فیزیکی غیرعادی (Abnormal Physical Behaviors)
DE: تفاوت در اجرا (Differences in Execution)

      ۶.۱.۵ بررسی Timeout و Liveness

با توجه به اینکه اکثر باگ‌های مرتبط با امنیت حافظه منجر به کرش کردن (Crash) فرآیند می‌شوند، فازرها می‌توانند با تشخیص زنده بودن (liveness)، این باگ‌ها را شناسایی کنند. یک روش رایج برای بررسی زنده بودن هدف، تنظیم Timeout ثابت برای پاسخ است [22, 27, 47, 55, 57, 121, 145]. اگر پیام پاسخ از هدف در زمان مشخص دریافت نشود، فرآیند هدف به عنوان مرده در نظر گرفته می‌شود. این روش برای محیط‌هایی با محدودیت در تکنیک‌های دیباگینگ مناسب است، مانند زمانی که سیگنال‌های فرآیند یا لاگ‌های دیباگ در دسترس نیستند.

با این حال، تنظیم یک زمان‌بندی ثابت، روشی نسبتاً جزئی است که ممکن است به دلیل نوسانات شبکه یا بار بیش از حد روی هدف، نتایج مثبت کاذب ایجاد کند. برای کاهش این مشکل، برخی پژوهش‌ها روش‌های بررسی زنده بودن فعال (active liveness check) پیشنهاد می‌کنند:

  • Snipuzz [47] ورودی‌ها را چندین بار ارسال می‌کند تا مثبت‌های کاذب کاهش یابد.
  • IoTFuzzer [27]، OWFuzz [22] و BadMesher [121] از پیام‌های heartbeat (مانند پیام‌های ICMP) برای استنتاج وضعیت PUT استفاده می‌کنند.

   ۶.۲ اوراکل‌های باگ غیرمرتبط با ایمنی حافظه (Non-Memory-Safety Bugs)

باگ‌های غیرمرتبط با ایمنی حافظه، باگ‌هایی هستند که علت آن‌ها دسترسی به حافظه نیست و منجر به نقض برخی ویژگی‌های مورد انتظار می‌شوند، مانند: باگ‌های منطقی، نقض RFCها، یا باگ‌هایی که عملکرد سیستم را تحت تأثیر قرار می‌دهند. شناسایی این نوع باگ‌ها دشوار است زیرا رفتار قابل مشاهده‌ی یکنواختی ندارند. برای کشف آن‌ها معمولاً نیاز است که اوراکل توسط کاربر تعریف شود و متناسب با ویژگی‌هایی که توسط هدف تخریب شده‌اند باشد. بر اساس ویژگی‌هایی که بررسی می‌شوند، این اوراکل‌ها به طور تقریبی به چهار دسته تقسیم می‌شوند:

  1. محتوای نادرست پیام‌ها و انتقال وضعیت‌ها
  2. ناسازگاری در انتقال داده
  3. شاخص‌های عملکرد غیرعادی
  4. تفاوت‌ها در اجرای برنامه

لازم به ذکر است که هرچند روش‌های مختلفی برای شناسایی باگ‌های غیرمرتبط با امنیت حافظه وجود دارد، اکثر این روش‌ها تنها رفتارهای مشکوک PUT را گزارش می‌کنند و برای تعیین تأثیر واقعی و قابلیت بهره‌برداری، نیاز به بررسی دستی توسط کارشناسان وجود دارد.

      ۶.۲.۱ محتوای نادرست پیام و انتقال وضعیت‌ها (Incorrect Message Content)

محتوای نادرست پیام بررسی می‌کند که آیا محتوای پاسخ‌ها قوانین معنایی را نقض کرده‌اند یا خیر. انتقال وضعیت نادرست بررسی می‌کند که آیا انتقال وضعیت‌ها معتبر و مجاز هستند یا نه. در اکثر موارد، این قوانین از مستندات پروتکل استخراج شده یا با دانش متخصصان طراحی می‌شوند. این قوانین می‌توانند به شکل‌های مختلف باشند، مانند ماشین حالت کاننیکال، خواص زمانی خطی یا محدودیت‌های پیام‌های پاسخ.

به عنوان مثال، Beurdouche و همکاران [18] یک ماشین حالت استاندارد از مستندات پروتکل ساختند و از آن به عنوان مرجع برای شناسایی رفتارهای غیرعادی برنامه‌های تحت آزمون (PUT) استفاده کردند. با استفاده از این روش، یک باگ منطقی در پیاده‌سازی TLS به نام JSSE شناسایی شد که به مهاجمان اجازه می‌داد پیام‌های مرتبط با تبادل کلید و احراز هویت را دور بزنند و ارتباط بدون رمزگذاری برقرار کنند.

LTL-Fuzzer [99] با استفاده از فازینگ هدایت شده، تست‌ها را به سمت بخش‌های خاصی از برنامه هدایت می‌کند که می‌توانند بر خواص زمانی خطی تأثیر بگذارند و بررسی می‌کند که آیا هر اجرای برنامه این خواص را رعایت می‌کند یا خیر.

Sweyntooth [56] و Greyhound [55] بررسی می‌کنند که آیا بسته پاسخ دریافتی در مجموعه نوع پیام‌های مجاز وضعیت فعلی پروتکل است یا خیر؛ پیام‌های ناسازگار به عنوان ناهنجاری علامت‌گذاری می‌شوند.

Loki [92] قوانین استخراج شده از پروتکل اجماع PBFT [24] را به عنوان اوراکل برای شناسایی باگ‌های غیرمرتبط با امنیت حافظه در پیاده‌سازی‌های بلاکچین به کار می‌گیرد. برای مثال، Loki یک باگ در Hyperledger Fabric [10] شناسایی کرد که می‌توانست برای تأیید تراکنش‌های غیرقانونی مورد سوءاستفاده قرار گیرد.

      ۶.۲.۲ ناسازگاری پیام در انتقال (Message Inconsistency in Transmission)

برخی از پژوهش‌ها بررسی می‌کنند که آیا باگ‌های غیرمرتبط با حافظه وجود دارند که می‌توانند باعث نقض یکپارچگی پروتکل شوند. به طور خاص، از آنجایی که انتقال صحیح داده یکی از ویژگی‌های پایه‌ای پروتکل TCP است، TCP-Fuzz [187] یک بررسی‌کننده داده روی سمت فرستنده و گیرنده طراحی کرده است تا نقض این ویژگی را تشخیص دهد. هر بار که پیامی ارسال یا دریافت می‌شود، بررسی‌ کننده داده بررسی می‌کند که آیا پیام ارسال‌شده و پیام دریافت‌ شده یکسان هستند یا خیر.

      ۶.۲.۳ شاخص‌های عملکرد غیرعادی (Abnormal Performance Indicators)

برخی از پژوهش‌ها به دنبال یافتن راهبردهای حمله شبکه‌ای هستند که می‌توانند عملکرد برنامه‌های تحت آزمون (PUT) را تحت تأثیر قرار دهند و اثربخشی این راهبردها را با پایش شاخص‌های عملکرد برنامه‌های تحت آزمون و بررسی اینکه آیا از محدوده‌ی عادی فراتر رفته‌اند، سنجش می‌کنند. به عنوان مثال، برای یافتن راهبردهای حمله‌ی DDoS تقویت‌شده در سرویس‌های UDP، AMPFuzz [78] از ضریب تقویت پهنای باند (BAF) [129] برای هر جفت درخواست و پاسخ استفاده می‌کند. این ضریب برابر است با نسبت مجموع طول تمام پیام‌های پاسخ به طول پیام درخواست حمله و به عنوان معیاری برای یافتن پیامی که بیشترین مصرف توان عملیاتی را ایجاد می‌کند، به کار می‌رود. همچنین TCPWN [69] و ABBrate [115] هدفشان یافتن راهبردهای حمله به پیاده‌سازی‌های کنترل ازدحام TCP است که می‌توانند اندازه‌ی پنجره‌ی ازدحام را افزایش یا کاهش دهند. برای تشخیص اینکه آیا ورودی‌ها واقعاً مکانیزم کنترل ازدحام را تحت تأثیر قرار می‌دهند، TCPWN اندازه‌ی پنجره را از لاگ‌های سیستم استخراج کرده و با یک مقدار پایه‌ی مورد انتظار مقایسه می‌کند.

      ۶.۲.۴ تفاوت در اجرا (Differences in Execution)

آزمون تفاضلی شامل مقایسه‌ی رفتارهای اجرایی پیاده‌سازی‌های مختلف یک پروتکل برای بررسی اثرات امنیتی بالقوه است. این روش مقیاس‌پذیر است زیرا وابستگی به ابزارهای داخلی یا تغییر کد ندارد. برای مثال، TCP-Fuzz [187] خروجی چند پیاده‌سازی TCP را با یکدیگر مقایسه می‌کند تا ناهماهنگی‌ها را شناسایی کند. Yang و همکاران [168] از آزمون تفاضلی برای کشف باگ‌های توافق در اتریوم (Ethereum) استفاده می‌کنند که می‌توانند منجر به حملات fork شوند. آن‌ها یک دنباله تراکنش به عنوان ورودی تولید کرده و پاسخ دو کلاینت اتریوم (Ethereum)، یکی در Golang و دیگری در Rust را بررسی می‌کنند.

چالش مهم در این حوزه، تعیین این است که کدام پیاده‌سازی از رفتار مورد انتظار پروتکل منحرف شده و اینکه آیا تفاوت‌های مشاهده شده ناشی از خطا است یا کمبود مشخصات در RFC پروتکل. به همین دلیل، اکثر پژوهش‌هایی که از آزمون تفاضلی استفاده می‌کنند [20, 168, 187] یک مرحله بررسی دستی را برای تمایز بین آسیب‌پذیری‌های واقعی و اختلافات بی‌ضرر اضافه می‌کنند.

برای افزایش کارایی کشف باگ، برخی مطالعات برنامهٔ تحت آزمون (PUT) را با یک پیاده‌سازی که از قبل به‌ خوبی آزمون شده یا به‌ صورت رسمی تأیید شده است مقایسه می‌کنند؛ که به آن «پشتهٔ مرجع» (reference stack) گفته می‌شود [187]. برای مثال، TCP-Fuzz [187] از پشته‌های TCP کلاسیک و آزمایش‌ شده در سطح کرنل، مانند Linux TCP یا FreeBSD TCP، به عنوان مرجع برای آزمون پشته‌های TCP جدیدتر استفاده می‌کند. در این شرایط، اگر ناسازگاری گزارش شود، به‌ طور قوی نشان‌ دهنده وجود باگ در پیاده‌سازی جدید است. این روش نه تنها ناهماهنگی‌ها را شناسایی می‌کند بلکه چارچوبی برای ارزیابی صحت پیاده‌سازی‌های مختلف پروتکل فراهم می‌آورد.

      ۶.۲.۵ بررسی‌های Timeout و زنده‌ بودن سیستم (Timeout and Liveness Checks)

بررسی‌های Timeout و زنده بودن سیستم (liveness) همچنین می‌توانند برای شناسایی حلقه‌های بی‌پایان مورد استفاده قرار گیرند [22, 27, 47, 55, 57, 121, 145] و روش‌های آن مشابه آنچه در بخش 6.1.5 شرح داده شد، است.

۷. مسیر تحقیقات آتی (DIRECTIONS OF FUTURE RESEARCH)

تا اینجا، ما پیشرفته‌ترین فازرهای پروتکل را بررسی کرده‌ایم. در این بخش، به سؤال پژوهشی RQ3 پاسخ می‌دهیم و روندهای تحقیقاتی و چالش‌های کنونی تکنیک‌های فازینگ را بر اساس آنچه در مرور ادبیات دیده‌ایم، بحث می‌کنیم.

   ۷.۱ پیش به‌ سوی ساخت یک مدل ارتباطی بی‌نقص (Towards Perfect Communication Model Construction)

روش‌های کنونی برای ساخت مدل‌های ارتباطی هنوز کامل نیستند و اغلب منجر به دانش ناقص یا نادرست می‌شوند و یا نیازمند تلاش گسترده دستی هستند.

به طور مشخص، همان‌طور که در بخش ۴ معرفی شد، روش‌های موجود برای ساخت مدل‌های ارتباطی را می‌توان به دو دسته از بالا به پایین (TopDown) و از پایین به بالا (Bottom-Up) تقسیم کرد. روش‌های از پایین به بالا برای یادگیری مدل‌های ارتباطی خاص پیاده‌سازی‌های مشخص پروتکل پیشنهاد شده‌اند [15, 39, 46, 48, 90, 106, 116, 120, 148, 162, 181] و نه مدل استاندارد خود پروتکل‌ها. در مقابل، در روش‌های از بالا به پایین، بیشتر کارهای موجود هنوز به شدت به فرآیندهای دستی برای ساخت ماشین حالت از مشخصات پروتکل وابسته‌اند [18, 55, 56, 63, 69, 70, 77, 113, 115, 128, 130, 138, 142, 187] که این روش نه تنها وقت‌گیر است، بلکه مستعد خطا نیز می‌باشد.

تحقیقات موجود [71, 111] تلاش کرده‌اند تا با استفاده از تکنیک‌های پردازش زبان طبیعی (NLP)، استخراج خودکار بخش‌هایی از FSMها (ماشین‌های حالت محدود) از مشخصات پروتکل را ممکن سازند. این بررسی‌ها به طور مقدماتی امکان‌پذیری خودکارسازی استخراج مدل‌های ارتباطی پروتکل را تأیید کرده‌اند. با این حال، این روش هنوز قادر به استخراج مدل ارتباطی استاندارد (canonical) از مشخصات پروتکل نیست، زیرا ابهامات و رفتارهای تعریف‌نشده در مشخصات مانع از ترجمه کامل و یک‌به‌یک متن به مدل ارتباطی می‌شوند.

برای رفع این محدودیت، می‌توان به رویکردهای مبتنی بر یادگیری ماشین برای ساخت مدل بهتر پرداخت. با توجه به پیشرفت چشمگیر اخیر مدل‌های زبان بزرگ (LLM) [29]، یک مسیر امیدوارکننده، توسعه راه‌حل‌های مبتنی بر LLM برای ساخت دقیق‌تر مدل‌ها است. مسیر دیگر، ترکیب منابع اطلاعاتی دیگر (مانند کد پیاده‌سازی پروتکل، اطلاعات کامیت یا کامنت‌ها در طول توسعه، نتایج تحلیل برنامه و غیره) برای درک بهتر محتوای مشخصات پروتکل می‌باشد.

   ۷.۲ به سوی دیدگاه‌های تست چندبعدی (Towards Multi-Dimension Testing Perspectives)

تحقیقات موجود بیشتر بر تغییر محتوای بسته‌ها یا ترتیب توالی بسته‌ها تمرکز دارند. این رویکرد، اگرچه تا حدی مؤثر است، اما این واقعیت را نادیده می‌گیرد که پروتکل‌ها دیدگاه تست چندبعدی دارند، به عنوان مثال، متغیرهایی مانند تأخیر پیام [68]، وضعیت حافظه پنهان [73]، پیکربندی‌ها [37، 180] و سطح همزمانی [75]، همانطور که در بخش 3.1 برجسته شده است. این ویژگی‌ها نقش مهمی در تصمیم‌گیری در مورد رفتار سیستم هدف دارند. برای آزمایش مؤثر این ویژگی‌ها در پیاده‌سازی‌های پروتکل، لازم است مدل‌های دقیقی ایجاد شود که هر ویژگی، از جمله تأخیر پیام، وضعیت حافظه پنهان، پارامترهای پیکربندی و سطوح همزمانی را به طور دقیق نشان دهند. علاوه بر این، اوراکل‌ها و جهش‌دهنده‌های خاصی را می‌توان برای ارزیابی صحت رفتار پروتکل تحت سناریوهای مختلفی که این جنبه‌های چندبعدی را در بر می‌گیرند، طراحی کرد. این جهت جالب است و می‌تواند به ایجاد ارزیابی جامع‌تری از تاب‌آوری و استحکام پروتکل کمک کند.

   ۷.۳ فازینگ اهداف پروتکل‌های مشخص‌ شده (Fuzzing Characterized Protocol Targets)

یک جهت‌گیری مهم و کمتر بررسی‌شده در تحقیقات آینده، فازینگ اهداف پروتکل‌های مشخص‌شده است. تحقیقات فعلی پروتکل‌های مختلف، به‌ویژه پروتکل‌هایی با ویژگی‌ها و اهمیت متمایز، را به‌طور جامع پوشش نداده است. سه حوزه زیر به‌طور خاص قابل توجه هستند:

  1. پروتکل‌های خاص دامنه. پروتکل‌های دامنه اختصاصی، مانند پروتکل‌های مورد استفاده در ارتباطات ماهواره‌ای [153]، ارتباطات وسایل نقلیه هوایی بدون سرنشین (UAV) [61] و سیستم عامل ربات (ROS) [108]، معمولاً دارای آستانه دانش بالا و ماهیت نسبتاً بسته‌ای هستند. این پروتکل‌ها نقش حیاتی در بسیاری از زیرساخت‌ها ایفا می‌کنند و تحقیقات امنیتی آنها را بسیار مهم می‌کنند. در حال حاضر، تحقیقات فازینگ برای این پروتکل‌ها نسبتاً کمیاب است و فرصتی را برای جامعه دانشگاهی فراهم می‌کند تا اثربخشی و امنیت آزمایش را از طریق توسعه تکنیک‌ها و ابزارهای جدید فازینگ بهبود بخشد.
  2. پروتکل‌های پیاده‌سازی‌شده در سخت‌افزار. یک مسیر دیگر، پروتکل‌های سخت‌افزاری است که شامل طراحی فازرها برای تست پروتکل‌هایی می‌شود که بر روی سخت‌افزارهایی مانند FPGAها پیاده‌سازی شده‌اند [156]. این پیاده‌سازی‌های سخت‌افزاری اغلب ویژگی‌های خطای متفاوتی نسبت به نسخه‌های نرم‌افزاری دارند و به همین دلیل توسعه روش‌های جدید برای شناسایی و بهره‌برداری مؤثرتر از آسیب‌پذیری‌های بالقوه ضروری است.
  3. پروتکل‌های چند حزبی. یکی دیگر از جهات ممکن فازینگ پروتکل، پشتیبانی از پروتکل‌های چند حزبی است. به طور کلی، پروتکل‌ها حالت‌های ارتباطی زیادی دارند، مانند حالت نظیر به نظیر [69، 115، 159]، حالت سرور-کلاینت (ارباب-برده) [27، 46، 158] و حالت چند حزبی [149]. فازرهای پروتکل موجود بیشتر بر روی دو حالت اول تمرکز می‌کنند و به عنوان کلاینت/سرور برای آزمایش حالت دیگر عمل می‌کنند [27، 46، 158] یا به عنوان یک گره همتا برای آزمایش PUT [69، 115، 159] ایفای نقش می‌کنند. پروتکل‌های چند حزبی مورد مطالعه قرار نگرفته‌اند. به عنوان مثال، یک گره می‌تواند به عنوان گره محاسباتی، گره اجماع یا گره مدیریتی در یک شبکه بلاکچین [10] ایفای نقش کند که هر کدام مسئول یک وظیفه متفاوت هستند. اجرای صحیح یک پروتکل قرارداد هوشمند نیاز به همکاری این نقش‌ها دارد. چگونگی آزمایش کارآمد این پروتکل‌های چندطرفه، سوالی جالب اما چالش‌برانگیز است.

   ۷.۴ ترکیب با سایر روش‌های یافتن آسیب‌پذیری (Combining with Other Vulnerability-Finding Techniques)

فراتر از فازینگ، مجموعه گسترده‌ای از تکنیک‌های یافتن آسیب‌پذیری مانند اجرای نمادین (Symbolic Execution) [11, 26, 132, 144, 150, 151] و بررسی مدل (Model Checking) [25, 59, 65, 74, 104] وجود دارد. در حالی که ترکیب این تکنیک‌ها با فازینگ در زمینه‌های عمومی بررسی شده است [147, 173]، کاربرد آن‌ها در فازینگ پروتکل‌ها هنوز نسبتاً کم بررسی شده است [144].

این موضوع یک مسیر پژوهشی امیدوارکننده را نشان می‌دهد، به‌ ویژه با توجه به این که رویکردهای ترکیبی هنوز با چالش‌های خاص تست برای ارتباطات پیچیده تعریف‌ شده در پروتکل‌ها روبه‌رو هستند. به‌طور شهودی، تحقیقات آینده می‌تواند روش‌های موجود برای یافتن آسیب‌پذیری را بهبود بخشد تا بهتر به حل چالش‌های ویژه پروتکل‌ها بپردازد. علاوه بر این، بسیاری از پروتکل‌ها با منابع یادگیری با کیفیت بالا همراه هستند، مانند مشخصات دقیق پروتکل. تحقیقات آینده می‌تواند راه‌هایی برای استفاده مؤثر از این منابع ارزشمند برای اطلاع‌رسانی و تقویت رویکردهای ترکیبی بررسی کند.

   ۷.۵ فازینگ پروتکل با رویکرد شیفت به چپ (Shift-Left Protocol Fuzzing)

اگرچه برخی تلاش‌های پژوهشی به ادغام تکنیک‌های فازینگ عمومی در چرخه توسعه پرداخته‌اند – مانند ابزارهایی همچون libFuzzer، OSS-Fuzz و تحقیقات مرتبط با فازینگ در آزمون‌های CI/CD [123] – اما مطالعات کمی به طور خاص به پر کردن فاصله بین فازینگ پروتکل و فرآیند توسعه اختصاص یافته است.

فازینگ پروتکل با فازینگ نرم‌افزار عمومی متفاوت است؛ این نوع فازینگ مستلزم آزمایش دقیق پروتکل‌های مختلفی است که امکان ارتباط و تبادل داده بین سیستم‌ها و مؤلفه‌های نرم‌افزاری مختلف را فراهم می‌کنند. اهداف پروتکل معمولاً دارای چرخه توسعه پیچیده‌تری نسبت به نرم‌افزارهای عمومی هستند. این پیچیدگی از نیاز آن‌ها به پیروی دقیق از استانداردها و مشخصات تعریف‌شده برای تطابق‌پذیری بین سیستم‌های مختلف ناشی می‌شود و چالش‌های منحصربه‌فردی در ادغام و تست ایجاد می‌کند.

این چالش‌ها نیازمند رویکردی خاص به فازینگ هستند که پیچیدگی‌های توسعه پروتکل را درک کرده و با آن سازگار شود. بنابراین، یک رویکرد شیفت به چپ (Shift-Left) در فازینگ پروتکل مورد نیاز است که تکنیک‌های خاص فازینگ پروتکل را زودتر در چرخه توسعه نرم‌افزار ادغام کند. این می‌تواند شامل طراحی تکنیک‌ها از دیدگاه توسعه‌دهنده باشد و در صورت لزوم، تکنیک‌های تعامل انسان و کامپیوتر (HCI) [23] نیز مدنظر قرار گیرد.

با این کار، آسیب‌پذیری‌ها و مشکلات در مراحل اولیه‌تر شناسایی می‌شوند، جایی که رفع آن‌ها ساده‌تر و کم‌هزینه‌تر است، و در نتیجه سیستم نرم‌افزاری پروتکل‌ها از امنیت و پایداری بالاتری برخوردار می‌شود.

پاورقی

[1] Deterministic Finite Automaton
[2] Single-Sign-On

تقدیر و تشکر

این تحقیق توسط بنیاد ملی علوم طبیعی چین (کمک هزینه شماره 62125205)، برنامه تحقیقاتی دانشگاه فناوری نانیانگ (NTU)-DESAY SV تحت کمک هزینه 2018-0980، بنیاد ملی تحقیقات سنگاپور تحت برنامه هوش مصنوعی سنگاپور (AISG2-RP-2020-019)، بنیاد ملی تحقیقات از طریق پروژه ماهواره ملی تعالی در سیستم‌های نرم‌افزاری قابل اعتماد (NSOE-TSS) تحت کمک هزینه تحقیق و توسعه ملی امنیت سایبری (NCR) با شماره NRF2018NCR-NSOE003-0001 پشتیبانی می‌شود.

مراجع

				
					[1] 2020. IEEE Standard for Local and Metropolitan Area Networks–Port-Based Network Access Control. IEEE Std 802.1X-2020 (Revision of IEEE Std 802.1X-2010 Incorporating IEEE Std 802.1Xbx-2014 and IEEE Std 802.1Xck-2018) (2020),1–289. https://doi.org/10.1109/IEEESTD.2020.9018454
[2] 2021. IEEE Standard for Information Technology–Telecommunications and Information Exchange between Systems - Local and Metropolitan Area Networks–Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. IEEE Std 802.11-2020 (Revision of IEEE Std 802.11-2016) (2021), 1–4379. https://doi.org/10.1109/IEEESTD.2021.9363693
[3] Yousra Aafer, Wei You, Yi Sun, Yu Shi, Xiangyu Zhang, and Heng Yin. 2021. Android {SmartTVs} Vulnerability Discovery via {Log-Guided} Fuzzing. In 30th USENIX Security Symposium (USENIX Security 21). 2759–2776.
[4] Bernhard K. Aichernig, Edi Muškardin, and Andrea Pferscher. 2021. Learning-Based Fuzzing of IoT Message Brokers. In 2021 14th IEEE Conference on Software Testing, Verification and Validation (ICST). 47–58. https://doi.org/10.1109/ICST49551.2021.00017
[5] ZigBee Alliance. 2015. ZigBee Specification. https://zigbeealliance.org/wp-content/uploads/2019/11/docs-05-3474-21-0csg-zigbee-specification.pdf
[6] Kaled M. Alshmrany and Lucas C. Cordeiro. 2020. Finding Security Vulnerabilities in Network Protocol Implementations. CoRR abs/2001.09592 (2020). arXiv:2001.09592 https://arxiv.org/abs/2001.09592
[7] Max Ammann, Lucca Hirschi, and Steve Kremer. 2024. DY Fuzzing: Formal Dolev-Yao Models Meet Cryptographic Protocol Fuzz Testing. In 45th IEEE Symposium on Security and Privacy.
[8] Paschal C Amusuo, Ricardo Andrés Calvo Méndez, Zhongwei Xu, Aravind Machinery, and James C Davis. 2023. Systematically Detecting Packet Validation Vulnerabilities in Embedded Network Stacks. In 2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 926–938.
[9] Anastasios Andronidis and Cristian Cadar. 2022. SnapFuzz: An Efficient Fuzzing Framework for Network Applications. CoRR abs/2201.04048 (2022). arXiv:2201.04048 https://arxiv.org/abs/2201.04048
[10] Elli Androulaki, Artem Barger, Vita Bortnikov, Christian Cachin, Konstantinos Christidis, Angelo De Caro, David Enyeart, Christopher Ferris, Gennady Laventman, Yacov Manevich, et al. 2018. Hyperledger fabric: a distributed operating system for permissioned blockchains. In Proceedings of the thirteenth EuroSys conference. 1–15.
[11] Hooman Asadian, Paul Fiterău-Broştean, Bengt Jonsson, and Konstantinos Sagonas. 2022. Applying Symbolic Execution to Test Implementations of a Network Protocol Against its Specification. In 2022 IEEE Conference on Software Testing, Verification and Validation (ICST). 70–81. https://doi.org/10.1109/ICST53961.2022.00019
[12] Cornelius Aschermann, Sergej Schumilo, Ali Abbasi, and Thorsten Holz. 2020. Ijon: Exploring Deep State Spaces via Fuzzing. In 2020 IEEE Symposium on Security and Privacy (SP). 1597–1612. https://doi.org/10.1109/SP40000.2020.00117
[13] Vaggelis Atlidakis, Patrice Godefroid, and Marina Polishchuk. 2019. RESTler: stateful REST API fuzzing. In Proceedings of the 41st International Conference on Software Engineering, ICSE 2019, Montreal, QC, Canada, May 25-31, 2019, Joanne M. Atlee, Tevfik Bultan, and Jon Whittle (Eds.). IEEE / ACM, 748–758. https://doi.org/10.1109/ICSE.2019.00083
[14] AUTOSAR. 2016. SOME/IP Protocol Specification. https://www.autosar.org/fileadmin/user_upload/standards/foundation/1-0/AUTOSAR_PRS_SOMEIPProtocol.pdf
[15] Jinsheng Ba, Marcel Böhme, Zahra Mirzamomen, and Abhik Roychoudhury. 2022. Stateful Greybox Fuzzing. arXiv preprint arXiv:2204.02545 (2022).
[16] Hari Balakrishnan, Srinivasan Seshan, Elan Amir, and Randy H Katz. 1995. Improving TCP/IP performance over wireless networks. In Proceedings of the 1st annual international conference on Mobile computing and networking. 2–11.
[17] Nils Bars, Moritz Schloegel, Tobias Scharnowski, Nico Schiller, and Thorsten Holz. 2023. Fuzztruction: Using Fault Injection-based Fuzzing to Leverage Implicit Domain Knowledge. In USENIX Security.
[18] Benjamin Beurdouche, Karthikeyan Bhargavan, Antoine Delignat-Lavaud, Cédric Fournet, Markulf Kohlweiss, Alfredo Pironti, Pierre-Yves Strub, and Jean Karim Zinzindohoue. 2015. A Messy State of the Union: Taming the Composite State Machines of TLS. In 2015 IEEE Symposium on Security and Privacy. 535–552. https://doi.org/10.1109/SP.2015.39
[19] Anne Borcherding, Mark Giraud, Ian Fitzgerald, and Jürgen Beyerer. 2023. The Bandit’s States: Modeling State Selection for Stateful Network Fuzzing as Multi-armed Bandit Problem. In 2023 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW). IEEE, 345–350.
[20] Jonas Bushart and Christian Rossow. 2023. ResolFuzz: Differential Fuzzing of DNS Resolvers. ESORICS 2023 (2023).
[21] Andrei Bytes, Prashant Hari Narayan Rajput, Michail Maniatakos, and Jianying Zhou. 2022. FieldFuzz: Enabling vulnerability discovery in Industrial Control Systems supply chain using stateful system-level fuzzing. https://doi.org/10.48550/ARXIV.2204.13499
[22] Hongjian Cao. 2021. Owfuzz: WiFi Nightmare. https://www.blackhat.com/eu-21/briefings/schedule/#owfuzz-wifi-nightmare-24338
[23] John M Carroll. 1997. Human-computer interaction: psychology as a science of design. Annual review of psychology 48, 1 (1997), 61–83.
[24] Miguel Castro, Barbara Liskov, et al. 1999. Practical byzantine fault tolerance. In OsDI, Vol. 99. 173–186.
[25] Sagar Chaki and Anupam Datta. 2009. ASPIER: An Automated Framework for Verifying Security Protocol Implementations. In 2009 22nd IEEE Computer Security Foundations Symposium. 172–185. https://doi.org/10.1109/CSF.2009.20
[26] Sze Yiu Chau, Omar Chowdhury, Endadul Hoque, Huangyi Ge, Aniket Kate, Cristina Nita-Rotaru, and Ninghui Li. 2017. SymCerts: Practical Symbolic Execution for Exposing Noncompliance in X.509 Certificate Validation Implementations. In 2017 IEEE Symposium on Security and Privacy (SP). 503–520. https://doi.org/10.1109/SP.2017.40 
[27] Jiongyi Chen, Wenrui Diao, Qingchuan Zhao, Chaoshun Zuo, Zhiqiang Lin, XiaoFeng Wang, Wing Cheong Lau, Menghan Sun, Ronghai Yang, and Kehuan Zhang. 2018. IoTFuzzer: Discovering Memory Corruptions in IoT Through App-based Fuzzing. In 25th Annual Network and Distributed System Security Symposium, NDSS 2018, San Diego, California, USA, February 18-21, 2018. The Internet Society. http://wp.internetsociety.org/ndss/wp-content/uploads/sites/25/2018/02/ndss2018_01A-1_Chen_paper.pdf
[28] Jyh-Cheng Chen, Ming-Chia Jiang, and Yi-wen Liu. 2005. Wireless LAN security and IEEE 802.11 i. IEEE Wireless Communications 12, 1 (2005), 27–36.
[29] Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, et al . 2021. Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374 (2021).
[30] Yurong Chen, Tian lan, and Guru Venkataramani. 2019. Exploring Effective Fuzzing Strategies to Analyze Communication Protocols. In Proceedings of the 3rd ACM Workshop on Forming an Ecosystem Around Software Transformation (London, United Kingdom) (FEAST’19). Association for Computing Machinery, New York, NY, USA, 17–23. https://doi.org/10.1145/3338502.3359762
[31] Yuanliang Chen, Fuchen Ma, Yuanhang Zhou, Yu Jiang, Ting Chen, and Jiaguang Sun. 2022. Tyr: Finding consensus failure bugs in blockchain system with behaviour divergent model. In 2023 IEEE Symposium on Security and Privacy (SP). IEEE Computer Society, 1186–1201.
[32] Yuanliang Chen, Fuchen Ma, Yuanhang Zhou, Yu Jiang, Ting Chen, and Jiaguang Sun. 2023. Tyr: Finding consensus failure bugs in blockchain system with behaviour divergent model. In 2023 IEEE Symposium on Security and Privacy (SP). IEEE, 2517–2532.
[33] Cisco. 2022. Cisco Secure Client Data Sheet. https://www.cisco.com/c/en/us/products/collateral/security/anyconnect-secure-mobility-client/secure-mobility-client-ds.html
[34] David Coffield and Doug Shepherd. 1987. Tutorial guide to Unix sockets for network communications. Computer Communications 10, 1 (1987), 21–29.
[35] Douglas E Comer. 2013. Internetworking with TCP/IP. Addison-Wesley Professional.
[36] Mitsubishi Electric Corporation. 2020. GX Works2 - Programmable Controllers MELSEC. https://www. mitsubishielectric.com/fa/products/cnt/plceng/smerit/gx_works2/index.html
[37] Huning Dai, Christian Murphy, and Gail Kaiser. 2010. Configuration Fuzzing for Software Vulnerability Detection. In 2010 International Conference on Availability, Reliability and Security. 525–530. https://doi.org/10.1109/ARES.2010.22
[38] Lesly-Ann Daniel, Erik Poll, and Joeri de Ruiter. 2018. Inferring OpenVPN State Machines Using Protocol State Fuzzing. In 2018 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW). 11–19. https://doi.org/10.1109/EuroSPW.2018.00009
[39] Joeri de Ruiter and Erik Poll. 2015. Protocol State Fuzzing of TLS Implementations. In 24th USENIX Security Symposium (USENIX Security 15). USENIX Association, Washington, D.C., 193–206. https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/de-ruiter
[40] T. Dierks. 2008. RFC5246: The Transport Layer Security (TLS) Protocol Version 1.2. https://www.rfc-editor.org/rfc/rfc5246
[41] Zhengjie Du and Yuekang Li. 2023. HasteFuzz: Full-Speed Fuzzing. In 2023 IEEE/ACM International Workshop on Search-Based and Fuzz Testing (SBFT). IEEE, 73–75.
[42] M. Eddington. 2014. Peach fuzzing platform. Available:http://community.peachfuzzer.com/WhatIsPeach.html 
[43] Schneider Electric. 2009. TwidoSuite Programming Software. https://www.se.com/ww/en/download/document/TwidoSuite_V0220_11_SP/
[44] ETSI. 2002. Universal Mobile Telecommunications System (UMTS); Multimedia Messaging Service (MMS); Stage 1 (3GPP TS 22.140 version 5.3.0 Release 5). https://www.etsi.org/deliver/etsi_ts/122100_122199/122140/05.03.00_60/ts_122140v050300p.pdf
[45] Rong Fan and Yaoyao Chang. 2018. Machine Learning for Black-Box Fuzzing of Network Protocols. In Information and Communications Security, Sihan Qing, Chris Mitchell, Liqun Chen, and Dongmei Liu (Eds.). Springer International Publishing, Cham, 621–632.
[46] Dongliang Fang, Zhanwei Song, Le Guan, Puzhuo Liu, Anni Peng, Kai Cheng, Yaowen Zheng, Peng Liu, Hongsong Zhu, and Limin Sun. 2021. ICS3Fuzzer: A Framework for Discovering Protocol Implementation Bugs in ICS Supervisory Software by Fuzzing. In ACSAC ’21: Annual Computer Security Applications Conference, Virtual Event, USA, December 6 - 10, 2021. ACM, 849–860. https://doi.org/10.1145/3485832.3488028
[47] Xiaotao Feng, Ruoxi Sun, Xiaogang Zhu, Minhui Xue, Sheng Wen, Dongxi Liu, Surya Nepal, and Yang Xiang. 2021. Snipuzz: Black-Box Fuzzing of IoT Firmware via Message Snippet Inference. In Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security (Virtual Event, Republic of Korea) (CCS ’21). Association for Computing Machinery, New York, NY, USA, 337–350. https://doi.org/10.1145/3460120.3484543
[48] Paul Fiterau-Brostean, Bengt Jonsson, Robert Merget, Joeri de Ruiter, Konstantinos Sagonas, and Juraj Somorovsky. 2020. Analysis of DTLS Implementations Using Protocol State Fuzzing. In 29th USENIX Security Symposium (USENIX Security 20). USENIX Association, 2523–2540. https://www.usenix.org/conference/usenixsecurity20/presentation/fiterau-brostean
[49] P. Fiterau-Brostean, B. Jonsson, K. Sagonas, and F. Taquist. 2022. DTLS-Fuzzer: A DTLS Protocol State Fuzzer. In 2022 IEEE Conference on Software Testing, Verification and Validation (ICST). IEEE Computer Society, Los Alamitos, CA, USA, 456–458. https://doi.org/10.1109/ICST53961.2022.00051
[50] Paul Fiterau-Brostean, Bengt Jonsson, Konstantinos Sagonas, and Fredrik Tåquist. 2023. Automata-Based Automated Detection of State Machine Bugs in Protocol Implementations.. In NDSS.
[51] Junsong Fu, Shuai Xiong, Na Wang, Ruiping Ren, Ang Zhou, and Bharat K Bhargava. 2023. A Framework of High-Speed Network Protocol Fuzzing Based on Shared Memory. IEEE Transactions on Dependable and Secure Computing (2023).
[52] Zicong Gao, Weiyu Dong, Rui Chang, and Yisen Wang. 2022. Fw-fuzz: A code coverage-guided fuzzing framework for network protocols on firmware. Concurrency and Computation: Practice and Experience 34, 16 (2022), e5756.
[53] Matheus E. Garbelini, Vaibhav Bedi, Sudipta Chattopadhyay, Sumei Sun, and Ernest Kurniawan. 2022. BrakTooth: Causing Havoc on Bluetooth Link Manager via Directed Fuzzing. In 31st USENIX Security Symposium (USENIX Security 22). USENIX Association, Boston, MA, 1025–1042. https://www.usenix.org/conference/usenixsecurity22/presentation/garbelini
[54] Matheus E. Garbelini, Zewen Shang, Sudipta Chattopadhyay, Sumei Sun, and Ernest Kurniawan. 2022. Towards Automated Fuzzing of 4G/5G Protocol Implementations Over the Air. In GLOBECOM 2022 - 2022 IEEE Global Communications Conference. 86–92. https://doi.org/10.1109/GLOBECOM48099.2022.10001673
[55] Matheus E. Garbelini, Chundong Wang, and Sudipta Chattopadhyay. 2022. Greyhound: Directed Greybox Wi-Fi Fuzzing. IEEE Transactions on Dependable and Secure Computing 19, 2 (2022), 817–834. https://doi.org/10.1109/TDSC. 2020.3014624
[56] Matheus E. Garbelini, Chundong Wang, Sudipta Chattopadhyay, Sun Sumei, and Ernest Kurniawan. 2020. SweynTooth: Unleashing Mayhem over Bluetooth Low Energy. In 2020 USENIX Annual Technical Conference (USENIX ATC 20). USENIX Association, 911–925. https://www.usenix.org/conference/atc20/presentation/garbelini
[57] Hugo Gascon, Christian Wressnegger, Fabian Yamaguchi, Daniel Arp, and Konrad Rieck. 2015. Pulsar: Stateful Black-Box Fuzzing of Proprietary Network Protocols. In Security and Privacy in Communication Networks - 11th International Conference, SecureComm 2015, Dallas, TX, USA, October 26-29, 2015, Revised Selected Papers (Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, Vol. 164), Bhavani M. Thuraisingham, XiaoFeng Wang, and Vinod Yegneswaran (Eds.). Springer, 330–347. https://doi.org/10.1007/978-3-319-28865-9_18
[58] Brian Gorenc and Matt Molinyawe. 2014. Blowing up the Celly: Building Your Own SMS/MMS Fuzzer. https://media.defcon.org/DEF%20CON%2022/DEF%20CON%2022%20presentations/DEF%20CON%2022%20-%20Brian-Gorenc-Matt-Molinyawe-Blowing-Up-The-Celly.pdf
[59] Jean Goubault-Larrecq and Fabrice Parrennes. 2005. Cryptographic Protocol Analysis on Real C Code. In Verification, Model Checking, and Abstract Interpretation, Radhia Cousot (Ed.). Springer Berlin Heidelberg, Berlin, Heidelberg, 363–379.
[60] The Open Group. 2018. Single Sign-On. http://www.opengroup.org/security/sso/
[61] Lav Gupta, Raj Jain, and Gabor Vaszkun. 2015. Survey of important issues in UAV communication networks. IEEE communications surveys & tutorials 18, 2 (2015), 1123–1152.
[62] Ben Hawkes. 2022. 0day In the Wild. https://googleprojectzero.blogspot.com/p/0day.html
[63] Fengjiao He, Wenchuan Yang, Baojiang Cui, and Jia Cui. 2022. Intelligent Fuzzing Algorithm for 5G NAS Protocol Based on Predefined Rules. In 2022 International Conference on Computer Communications and Networks (ICCCN). 1–7. https://doi.org/10.1109/ICCCN54977.2022.9868872
[64] Dennis Heinze, Jiska Classen, and Matthias Hollick. 2020. ToothPicker: Apple Picking in the iOS Bluetooth Stack. In 14th USENIX Workshop on Offensive Technologies (WOOT 20). USENIX Association. https://www.usenix.org/conference/woot20/presentation/heinze
[65] Endadul Hoque, Omar Chowdhury, Sze Yiu Chau, Cristina Nita-Rotaru, and Ninghui Li. 2017. Analyzing Operational Behavior of Stateful Protocol Implementations for Detecting Semantic Bugs. In 2017 47th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). 627–638. https://doi.org/10.1109/DSN.2017.36
[66] Syed Rafiul Hussain, Imtiaz Karim, Abdullah Al Ishtiaq, Omar Chowdhury, and Elisa Bertino. 2021. Noncompliance as deviant behavior: An automated black-box noncompliance checker for 4g lte cellular devices. In Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security. 1082–1099.
[67] Jana Iyengar and Martin Thomson. 2021. QUIC: A UDP-Based Multiplexed and Secure Transport. RFC 9000. https://doi.org/10.17487/RFC9000
[68] Sofiene Jelassi, Gerardo Rubino, Hugh Melvin, Habib Youssef, and Guy Pujolle. 2012. Quality of Experience of VoIP Service: A Survey of Assessment Approaches and Open Issues. IEEE Communications Surveys & Tutorials 14, 2 (2012), 491–513. https://doi.org/10.1109/SURV.2011.120811.00063
[69] Samuel Jero, Md. Endadul Hoque, David R. Choffnes, Alan Mislove, and Cristina Nita-Rotaru. 2018. Automated Attack Discovery in TCP Congestion Control Using a Model-guided Approach. In 25th Annual Network and Distributed System Security Symposium, NDSS 2018, San Diego, California, USA, February 18-21, 2018. The Internet Society. http://wp.internetsociety.org/ndss/wp-content/uploads/sites/25/2018/02/ndss2018_02A-1_Jero_paper.pdf 
[70] Samuel Jero, Hyojeong Lee, and Cristina Nita-Rotaru. 2015. Leveraging State Information for Automated Attack Discovery in Transport Protocol Implementations. In 2015 45th Annual IEEE/IFIP International Conference on Dependable Systems and Networks. 1–12. https://doi.org/10.1109/DSN.2015.22
[71] Samuel Jero, Maria Leonor Pacheco, Dan Goldwasser, and Cristina Nita-Rotaru. 2019. Leveraging Textual Specifications for Grammar-Based Fuzzing of Network Protocols. Proceedings of the AAAI Conference on Artificial Intelligence 33, 01 (Jul. 2019), 9478–9483. https://doi.org/10.1609/aaai.v33i01.33019478
[72] Ru Ji and Meng Xu. 2023. Finding Specification Blind Spots via Fuzz Testing. In 2023 IEEE Symposium on Security and Privacy (SP). IEEE Computer Society, 2708–2725.
[73] Jaeyeon Jung, Emil Sit, Hari Balakrishnan, and Robert Morris. 2001. DNS performance and the effectiveness of caching. In Proceedings of the 1st ACM SIGCOMM Workshop on Internet Measurement. 153–167.
[74] Jan Jurjens. 2006. Security Analysis of Crypto-based Java Programs using Automated Theorem Provers. In 21st IEEE/ACM International Conference on Automated Software Engineering (ASE’06). 167–176. https://doi.org/10.1109/ASE.2006.60
[75] Jonathan Katz and Ji Sun Shin. 2006. Parallel and concurrent security of the HB and HB+ protocols. In Advances in Cryptology - EUROCRYPT 2006. Springer, 73–87.
[76] Kyungtae Kim, Sungwoo Kim, Kevin RB Butler, Antonio Bianchi, Rick Kennell, and Dave Jing Tian. 2023. Fuzz The Power: Dual-role State Guided Black-box Fuzzing for {USB} Power Delivery. In 32nd USENIX Security Symposium (USENIX Security 23). 5845–5861.
[77] Seulbae Kim, Seunghoon Woo, Heejo Lee, and Hakjoo Oh. 2017. Poster: Iotcube: an automated analysis platform for finding security vulnerabilities. In Proceedings of the 38th IEEE Symposium on Poster presented at Security and Privacy.
[78] Johannes Krupp, Ilya Grishchenko, and Christian Rossow. 2022. AmpFuzz: Fuzzing for Amplification DDoS Vulnerabilities. In 31st USENIX Security Symposium (USENIX Security 22). USENIX Association, Boston, MA, 1043–1060. https://www.usenix.org/conference/usenixsecurity22/presentation/krupp
[79] Seungsoo Lee, Jinwoo Kim, Seungwon Woo, and Seungwon Shin. 2018. The Finest Penetration Testing Framework for Software-Defined Networks. https://www.blackhat.com/us-18/briefings/schedule/#the-finest-penetration-testing-framework-for-software-defined-networks--10101
[80] Ao Li, Rohan Padhye, and Vyas Sekar. 2022. SPIDER: A Practical Fuzzing Framework to Uncover Stateful Performance Issues in SDN Controllers. https://doi.org/10.48550/ARXIV.2209.04026
[81] Junqiang Li, Senyi Li, Gang Sun, Ting Chen, and Hongfang Yu. 2022. SNPSFuzzer: A Fast Greybox Fuzzer for Stateful Network Protocols using Snapshots. CoRR abs/2202.03643 (2022). arXiv:2202.03643 https://arxiv.org/abs/2202.03643
[82] Yuekang Li, Hongxu Chen, Cen Zhang, Siyang Xiong, Chaoyi Liu, and Yi Wang. 2020. Ori: A greybox fuzzer for SOME/IP protocols in automotive Ethernet. In 2020 27th Asia-Pacific Software Engineering Conference (APSEC). IEEE,495–499.
[83] Yuekang Li, Guozhu Meng, Jun Xu, Cen Zhang, Hongxu Chen, Xiaofei Xie, Haijun Wang, and Yang Liu. 2021. Vall-nut:Principled Anti-Grey box-Fuzzing. In 2021 IEEE 32nd International Symposium on Software Reliability Engineering (ISSRE). IEEE, 288–299.
[84] Yuekang Li, Yinxing Xue, Hongxu Chen, Xiuheng Wu, Cen Zhang, Xiaofei Xie, Haijun Wang, and Yang Liu. 2019. Cerebro: context-aware adaptive fuzzing for effective vulnerability detection. In Proceedings of the 2019 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering. 533–544.
[85] Hongliang Liang, Xiaoxiao Pei, Xiaodong Jia, Wuwei Shen, and Jian Zhang. 2018. Fuzzing: State of the Art. IEEE Transactions on Reliability 67, 3 (2018), 1199–1218. https://doi.org/10.1109/TR.2018.2834476
[86] Dongge Liu, Gidon Ernst, Toby Murray, and Benjamin I. P. Rubinstein. 2020. Legion: Best-First Concolic Testing. In Proceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering (Virtual Event, Australia) (ASE ’20). Association for Computing Machinery, New York, NY, USA, 54–65. https://doi.org/10.1145/3324884.3416629
[87] Dongge Liu, Van-Thuan Pham, Gidon Ernst, Toby Murray, and Benjamin I. P. Rubinstein. 2021. State Selection Algorithms and Their Impact on The Performance of Stateful Network Protocol Fuzzing. CoRR abs/2112.15498 (2021). arXiv:2112.15498 https://arxiv.org/abs/2112.15498
[88] Puzhuo Liu, Yaowen Zheng, Zhanwei Song, Dongliang Fang, Shichao Lv, and Limin Sun. 2022. Fuzzing proprietary protocols of programmable controllers to find vulnerabilities that affect physical control. Journal of Systems Architecture 127 (2022), 102483.
[89] Zhengxiong Luo, Junze Yu, Feilong Zuo, Jianzhong Liu, Yu Jiang, Ting Chen, Abhik Roychoudhury, and Jiaguang Sun. 2023. Bleem: Packet Sequence Oriented Fuzzing for Protocol Implementations. In 32nd USENIX Security Symposium (USENIX Security 23). USENIX Association, Anaheim, CA, 4481–4498. https://www.usenix.org/conference/usenixsecurity23/presentation/luo-zhengxiong
[90] Zhengxiong Luo, Feilong Zuo, Yu Jiang, Jian Gao, Xun Jiao, and Jiaguang Sun. 2019. Polar: Function Code Aware Fuzz Testing of ICS Protocol. ACM Trans. Embed. Comput. Syst. 18, 5s (2019), 93:1–93:22. https://doi.org/10.1145/3358227
[91] Zhengxiong Luo, Feilong Zuo, Yuheng Shen, Xun Jiao, Wanli Chang, and Yu Jiang. 2020. ICS Protocol Fuzzing: Coverage Guided Packet Crack and Generation. In 57th ACM/IEEE Design Automation Conference, DAC 2020, San Francisco, CA, USA, July 20-24, 2020. IEEE, 1–6. https://doi.org/10.1109/DAC18072.2020.9218603
[92] Fuchen Ma, Yuanliang Chen, Meng Ren, Yuanhang Zhou, Yu Jiang, Ting Chen, Huizhong Li, and Jiaguang Sun. 2023. LOKI: State-Aware Fuzzing Framework for the Implementation of Blockchain Consensus Protocols. In Proceedings 2023 Network and Distributed System Security Symposium.
[93] Dominik Maier, Lukas Seidel, and Shinjo Park. 2020. BaseSAFE: Baseband SAnitized Fuzzing through Emulation. CoRR abs/2005.07797 (2020). arXiv:2005.07797 https://arxiv.org/abs/2005.07797
[94] V. M. Manes, H. Han, C. Han, S. Cha, M. Egele, E. J. Schwartz, and M. Woo. 2021. The Art, Science, and Engineering of Fuzzing: A Survey. IEEE Transactions on Software Engineering 47, 11 (nov 2021), 2312–2331. https://doi.org/10. 1109/TSE.2019.2946563
[95] Eldar Marcussen. 2018. Doona - Network fuzzing tool. Available:https://github.com/wireghoul/doona
[96] B.W. Marsden. 1986. Communication Network Protocols. Chartwell-Bratt. https://books.google.com.hk/books?id=WEeOzgEACAAJ
[97] Björn Mathis, Rahul Gopinath, Michaël Mera, Alexander Kampmann, Matthias Höschele, and Andreas Zeller. 2019. Parser-Directed Fuzzing. In Proceedings of the 40th ACM SIGPLAN Conference on Programming Language Design and Implementation (Phoenix, AZ, USA) (PLDI 2019). Association for Computing Machinery, New York, NY, USA, 548–560. https://doi.org/10.1145/3314221.3314651
[98] Chris McMahon Stone, Tom Chothia, and Joeri de Ruiter. 2018. Extending Automated Protocol State Learning for the 802.11 4-Way Handshake. In Computer Security, Javier Lopez, Jianying Zhou, and Miguel Soriano (Eds.). Springer International Publishing, Cham, 325–345.
[99] Ruijie Meng, Zhen Dong, Jialin Li, Ivan Beschastnikh, and Abhik Roychoudhury. 2021. Finding Counterexamples of Temporal Logic properties in Software Implementations via Greybox Fuzzing. CoRR abs/2109.02312 (2021). arXiv:2109.02312 https://arxiv.org/abs/2109.02312
[100] Ruijie Meng, Martin Mirchev, Marcel Böhme, and Abhik Roychoudhury. 2024. Large Language Model guided Protocol Fuzzing. In NDSS. 1–17.
[101] Ruijie Meng, George Pîrlea, Abhik Roychoudhury, and Ilya Sergey. 2023. Greybox Fuzzing of Distributed Systems. In Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security (<conf-loc>, <city>Copenhagen</city>, <country>Denmark</country>, </conf-loc>) (CCS ’23). Association for Computing Machinery, New York, NY, USA, 1615–1629. https://doi.org/10.1145/3576915.3623097
[102] Microsoft. 2007. Remote Desktop Protocol: Basic Connectivity and Graphics Remoting. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpbcgr/5073f4ed-1e93-45e1-b039-6e30c385867c
[103] Barton P Miller, Lars Fredriksen, and Bryan So. 1990. An empirical study of the reliability of UNIX utilities. Commun. ACM 33, 12 (1990), 32–44.
[104] Madanlal Musuvathi and Dawson R. Engler. 2004. Model Checking Large Network Protocol Implementations. In Proceedings of the 1st Conference on Symposium on Networked Systems Design and Implementation - Volume 1 (San Francisco, California) (NSDI’04). USENIX Association, USA, 12.
[105] Paul Mutton. 2014. Half a million widely trusted websites vulnerable to Heartbleed bug. https://news.netcraft.com/archives/2014/04/08/half-a-million-widely-trusted-websites-vulnerable-to-heartbleed-bug.html
[106] Roberto Natella. 2022. Stateafl: Greybox fuzzing for stateful network servers. Empirical Software Engineering 27, 7 (2022), 191.
[107] OASIS. 2019. MQTT Version 5.0. https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html
[108] Takeshi Ohkawa, Yuhei Sugata, Harumi Watanabe, Nobuhiko Ogura, Kanemitsu Ootsu, and Takashi Yokota. 2019. High level synthesis of ROS protocol interpretation and communication circuit for FPGA. In 2019 IEEE/ACM 2nd International Workshop on Robotics Software Engineering (RoSE). IEEE, 33–36.
[109] OMG. 2018. The Real-time Publish-Subscribe Protocol (RTPS) DDS Interoperability Wire Protocol Specification. https://www.omg.org/spec/DDSI-RTPS/2.3/Beta1/PDF
[110] Fatih Ozavci. 2013. VoIP Wars : Return of the SIP. https://media.defcon.org/DEF%20CON%2021/DEF%20CON%2021%20presentations/DEF%20CON%2021%20-%20Ozavci-VoIP-Wars-Return-of-the-SIP.pdf
[111] Maria Leonor Pacheco, Max von Hippel, Ben Weintraub, Dan Goldwasser, and Cristina Nita-Rotaru. 2022. Automated Attack Synthesis by Extracting Finite State Machines from Protocol Specification Documents. CoRR abs/2202.09470 (2022). arXiv:2202.09470 https://arxiv.org/abs/2202.09470
[112] Chun Sung Park, Yeongjin Jang, Seungjoo Kim, and Ki Taek Lee. 2019. Fuzzing and Exploiting Virtual Channels in Microsoft Remote Desktop Protocol for Fun and Profit. https://www.blackhat.com/eu-19/briefings/schedule/#fuzzing-and-exploiting-virtual-channels-in-microsoft-remote-desktop-protocol-for-fun-and-profit-17789
[113] H. Park, C. Nkuba, S. Woo, and H. Lee. 2022. L2Fuzz: Discovering Bluetooth L2CAP Vulnerabilities Using Stateful Fuzz Testing. In 2022 52nd Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). IEEE Computer Society, Los Alamitos, CA, USA, 343–354. https://doi.org/10.1109/DSN53405.2022.00043 
[114] Bryan Pearson, Yue Zhang, Cliff Zou, and Xinwen Fu. 2022. FUME: Fuzzing Message Queuing Telemetry Transport Brokers. In IEEE INFOCOM 2022 - IEEE Conference on Computer Communications. 1699–1708. https://doi.org/10.1109/
[115] Anthony Peterson, Samuel Jero, Endadul Hoque, David Choffnes, and Cristina Nita-Rotaru. 2020. aBBRate: Automating BBR Attack Exploration Using a Model-Based Approach. In 23rd International Symposium on Research in Attacks, Intrusions and Defenses (RAID 2020). USENIX Association, San Sebastian, 225–240. https://www.usenix.org/conference/raid2020/presentation/peterson
[116] Van-Thuan Pham, Marcel Böhme, and Abhik Roychoudhury. 2020. AFLNET: A Greybox Fuzzer for Network Protocols. In 13th IEEE International Conference on Software Testing, Validation and Verification, ICST 2020, Porto, Portugal, October 24-28, 2020. IEEE, 460–465. https://doi.org/10.1109/ICST46399.2020.00062
[117] Van-Thuan Pham, Marcel Böhme, Andrew E Santosa, Alexandru Răzvan Căciulescu, and Abhik Roychoudhury. 2019. Smart greybox fuzzing. IEEE Transactions on Software Engineering 47, 9 (2019), 1980–1997.
[118] Clément Poncelet, Konstantinos Sagonas, and Nicolas Tsiftes. 2022. So Many Fuzzers, So Little Time: Experience from Evaluating Fuzzers on the Contiki-NG Network (Hay) Stack. In Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering. 1–12.
[119] OpenSSL Project. 2022. OpenSSL. Available:https://github.com/openssl/openssl
[120] Shisong Qin, Fan Hu, Zheyu Ma, Bodong Zhao, Tingting Yin, and Chao Zhang. 2023. NSFuzz: Towards Efficient and State-Aware Network Service Fuzzing. ACM Transactions on Software Engineering and Methodology (2023).
[121] Lewei Qu, Dongxiang Ke, Ye Zhang, and Ying Wang. 2021. BadMesher: New Attack Surfaces of Wi-Fi Mesh Network. https://www.blackhat.com/eu-21/briefings/schedule/#badmesher-new-attack-surfaces-of-wi-fi-mesh-network-24181
[122] NGUYEN Anh Quynh and DANG Hoang Vu. 2015. Unicorn: Next generation cpu emulator framework. BlackHat USA 476 (2015).
[123] Thorsten Rangnau, Remco v. Buijtenen, Frank Fransen, and Fatih Turkmen. 2020. Continuous Security Testing: A Case Study on Integrating Dynamic Security Testing Tools in CI/CD Pipelines. In 2020 IEEE 24th International Enterprise Distributed Object Computing Conference (EDOC). 145–154. https://doi.org/10.1109/EDOC49727.2020.00026
[124] Gaganjeet Singh Reen and Christian Rossow. 2020. DPIFuzz: A Differential Fuzzing Framework to Detect DPI Elusion Strategies for QUIC. In Annual Computer Security Applications Conference (Austin, USA) (ACSAC ’20). Association for Computing Machinery, New York, NY, USA, 332–344. https://doi.org/10.1145/3427228.3427662
[125] Mengfei Ren, Xiaolei Ren, Huadong Feng, Jiang Ming, and Yu Lei. 2021. Z-Fuzzer: device-agnostic fuzzing of Zigbee protocol implementation. In WiSec ’21: 14th ACM Conference on Security and Privacy in Wireless and Mobile Networks, Abu Dhabi, United Arab Emirates, 28 June - 2 July, 2021, Christina Pöpper, Mathy Vanhoef, Lejla Batina, and René Mayrhofer (Eds.). ACM, 347–358. https://doi.org/10.1145/3448300.3468296
[126] E. Rescorla. 2012. RFC6347: Datagram Transport Layer Security Version 1.2. https://datatracker.ietf.org/doc/html/rfc6347
[127] Gerbert Roitburd, Matthias Ortmann, Matthias Hollick, and Jiska Classen. 2021. Very Pwnable Network: Cisco AnyConnect Security Analysis. In 2021 IEEE Conference on Communications and Network Security (CNS). 56–64. https://doi.org/10.1109/CNS53000.2021.9705023
[128] Daniel Romero and Mario Rivas. 2019. Why you should fear your ’mundane’ office equipment. https://media.defcon.org/DEF%20CON%2027/DEF%20CON%2027%20presentations/DEFCON-27-Daniel-Romero-and-Mario-Rivas-Why-you-should-fear-your-mundane-office.pdf
[129] Christian Rossow. 2014. Amplification Hell: Revisiting Network Protocols for DDoS Abuse.. In NDSS. 1–15.
[130] Jan Ruge, Jiska Classen, Francesco Gringoli, and Matthias Hollick. 2020. Frankenstein: Advanced Wireless Fuzzing to Exploit New Bluetooth Escalation Targets. In 29th USENIX Security Symposium (USENIX Security 20). USENIX Association, 19–36. https://www.usenix.org/conference/usenixsecurity20/presentation/ruge
[131] Konstantinos Sagonas and Thanasis Typaldos. 2023. EDHOC-Fuzzer: An EDHOC Protocol State Fuzzer. In Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis. 1495–1498.
[132] Raimondas Sasnauskas, Jó Ágila Bitsch Link, Muhammad Hamad Alizai, and Klaus Wehrle. 2008. KleeNet: Automatic Bug Hunting in Sensor Network Applications. In Proceedings of the 6th ACM Conference on Embedded Network Sensor Systems (Raleigh, NC, USA) (SenSys ’08). Association for Computing Machinery, New York, NY, USA, 425–426. https://doi.org/10.1145/1460412.1460485
[133] Domien Schepers, Mathy Vanhoef, and Aanjhan Ranganathan. 2021. A Framework to Test and Fuzz Wi-Fi Devices. In Proceedings of the 14th ACM Conference on Security and Privacy in Wireless and Mobile Networks (Abu Dhabi, United Arab Emirates) (WiSec ’21). Association for Computing Machinery, New York, NY, USA, 368–370. https://doi.org/10.1145/3448300.3468261
[134] Sergej Schumilo, Cornelius Aschermann, Andrea Jemmett, Ali Abbasi, and Thorsten Holz. 2022. Nyx-Net: Network Fuzzing with Incremental Snapshots. In Proceedings of the Seventeenth European Conference on Computer Systems (Rennes, France) (EuroSys ’22). Association for Computing Machinery, New York, NY, USA, 166–180. https://doi.org/10.1145/3492321.3519591
[135] Konstantin Serebryany, Derek Bruening, Alexander Potapenko, and Dmitriy Vyukov. 2012. {AddressSanitizer}: A Fast Address Sanity Checker. In 2012 USENIX Annual Technical Conference (USENIX ATC 12). 309–318.
[136] Konstantin Serebryany and Timur Iskhodzhanov. 2009. ThreadSanitizer: data race detection in practice. In Proceedings of the workshop on binary instrumentation and applications. 62–71.
[137] Eric Sesterhenn and Martin J. Muench. 2013. Bruteforce Exploit Detector. Available:https://gitlab.com/kalilinux/packages/bed
[138] Shangcheng Shi, Xianbo Wang, and Wing Cheong Lau. 2019. MoSSOT: An Automated Blackbox Tester for Single Sign-On Vulnerabilities in Mobile Applications. In Proceedings of the 2019 ACM Asia Conference on Computer and Communications Security (Auckland, New Zealand) (Asia CCS ’19). Association for Computing Machinery, New York,NY, USA, 269–282. https://doi.org/10.1145/3321705.3329801
[139] Bluetooth SIG. 2016. Bluetooth Core Specifications. https://www.bluetooth.com/specifications/bluetooth-core-specification
[140] Manuel Sommer, Nicholas Gray, Phuoc Tran-Gia, and Thomas Zinner. 2017. FlowFuzz: A Framework for Fuzzing OpenFlow-enabled Software and Hardware Switches. https://www.blackhat.com/us-17/briefings/schedule/#flowfuzz---a-framework-for-fuzzing-openflow-enabled-software-and-hardware-switches-7642
[141] Manuel Sommer, Nicholas Gray, Phuoc Tran-Gia, and Thomas Zinner. 2018. Designing and Applying Extensible RF Fuzzing Tools to Expose PHY Layer Vulnerabilities. https://media.defcon.org/DEF%20CON%2026/DEF%20CON%2026%20presentations/DEFCON-26-Matt-Knight-and-Ryan-Speers-Designing-RF-Fuzzing-Tools-to-Expose-PHY-Layer-Vulns-Updated.pdf
[142] Juraj Somorovsky. 2016. Systematic Fuzzing and Testing of TLS Libraries. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security (Vienna, Austria) (CCS ’16). Association for Computing Machinery, New York, NY, USA, 1492–1504. https://doi.org/10.1145/2976749.2978411
[143] Dokyung Song, Julian Lettner, Prabhu Rajasekaran, Yeoul Na, Stijn Volckaert, Per Larsen, and Michael Franz. 2019. SoK: Sanitizing for security. In 2019 IEEE Symposium on Security and Privacy (SP). IEEE, 1275–1295.
[144] JaeSeung Song, Cristian Cadar, and Peter Pietzuch. 2014. SymbexNet: Testing Network Protocol Implementations with Symbolic Execution and Rule-Based Specifications. IEEE Transactions on Software Engineering 40, 7 (2014), 695–709. https://doi.org/10.1109/TSE.2014.2323977
[145] Jonghyuk Song, Soohwan Oh, and Woongjo Choi. 2022. Automotive Ethernet Fuzzing: From Purchasing ECU to SOME/IP Fuzzing. https://forum.defcon.org/node/242347
[146] Evgeniy Stepanov and Konstantin Serebryany. 2015. MemorySanitizer: fast detector of uninitialized memory use in C++. In 2015 IEEE/ACM International Symposium on Code Generation and Optimization (CGO). IEEE, 46–55.
[147] Nick Stephens, John Grosen, Christopher Salls, Andrew Dutcher, Ruoyu Wang, Jacopo Corbetta, Yan Shoshitaishvili, Christopher Kruegel, and Giovanni Vigna. 2016. Driller: Augmenting Fuzzing Through Selective Symbolic Execution. In 23rd Annual Network and Distributed System Security Symposium, NDSS 2016, San Diego, California, USA, February 21-24, 2016. The Internet Society. http://wp.internetsociety.org/ndss/wp-content/uploads/sites/25/2017/09/driller augmenting-fuzzing-through-selective-symbolic-execution.pdf
[148] Chris McMahon Stone, Sam L. Thomas, Mathy Vanhoef, James Henderson, Nicolas Bailluet, and Tom Chothia. 2021. The Closer You Look, The More You Learn: A Grey-box Approach to Protocol State Machine Learning. CoRRabs/2106.02623 (2021). arXiv:2106.02623 https://arxiv.org/abs/2106.02623
[149] Avinash Sudhodanan, Alessandro Armando, Roberto Carbone, Luca Compagna, et al . 2016. Attack Patterns for Black-Box Security Testing of Multi-Party Web Applications.. In NDSS.
[150] Wei Sun, Lisong Xu, and Sebastian Elbaum. 2017. Improving the Cost-Effectiveness of Symbolic Testing Techniques for Transport Protocol Implementations under Packet Dynamics. In Proceedings of the 26th ACM SIGSOFT International Symposium on Software Testing and Analysis (Santa Barbara, CA, USA) (ISSTA 2017). Association for Computing Machinery, New York, NY, USA, 79–89. https://doi.org/10.1145/3092703.3092706
[151] Wei Sun, Lisong Xu, and Sebastian Elbaum. 2018. Scalably Testing Congestion Control Algorithms of Real-World TCP Implementations. In 2018 IEEE International Conference on Communications (ICC). 1–7. https://doi.org/10.1109/ICC.2018.8422949
[152] Wei Sun, Lisong Xu, Sebastian Elbaum, and Di Zhao. 2019. Model-Agnostic and Efficient Exploration of Numerical State Space of Real-World TCP Congestion Control Implementations. In 16th USENIX Symposium on Networked Systems Design and Implementation (NSDI 19). USENIX Association, Boston, MA, 719–734. https://www.usenix.org/conference/nsdi19/presentation/sun
[153] Zhili Sun. 2005. Satellite networking: Principles and protocols. John Wiley & Sons.
[154] Ilya Sutskever, Oriol Vinyals, and Quoc V Le. 2014. Sequence to sequence learning with neural networks. Advances in neural information processing systems 27 (2014).
[155] Inc. Synopsys. 2014. Heartbleed Vulnerability. Available:https://heartbleed.com/
[156] Stephen M Trimberger and Jason J Moore. 2014. FPGA security: Motivations, features, and applications. Proc. IEEE 102, 8 (2014), 1248–1265.
[157] Petar Tsankov, Mohammad Torabi Dashti, and David Basin. 2013. Semi-Valid Input Coverage for Fuzz Testing. In Proceedings of the 2013 International Symposium on Software Testing and Analysis (Lugano, Switzerland) (ISSTA 2013). Association for Computing Machinery, New York, NY, USA, 56–66. https://doi.org/10.1145/2483760.2483787
[158] Mathy Vanhoef. 2017. WiFuzz: Detecting and Exploiting Logical Flaws in the Wi-Fi Cryptographic Handshake. https://www.blackhat.com/us-17/briefings/schedule/#wifuzz-detecting-and-exploiting-logical-flaws-in-the-wi-fi-cryptographic-handshake-6827
[159] Andreas Walz and Axel Sikora. 2017. Exploiting dissent: towards fuzzing-based differential black-box testing of TLS implementations. IEEE Transactions on Dependable and Secure Computing 17, 2 (2017), 278–291.
[160] Andreas Walz and Axel Sikora. 2020. Exploiting Dissent: Towards Fuzzing-Based Differential Black-Box Testing of TLS Implementations. IEEE Transactions on Dependable and Secure Computing 17, 2 (2020), 278–291. https://doi.org/10.1109/TDSC.2017.2763947
[161] Junjie Wang, Bihuan Chen, Lei Wei, and Yang Liu. 2017. Skyfire: Data-driven seed generation for fuzzing. In 2017 IEEE Symposium on Security and Privacy (SP). IEEE, 579–594.
[162] Qinying Wang, Shouling Ji, Yuan Tian, Xuhong Zhang, Binbin Zhao, Yuhong Kan, Zhaowei Lin, Changting Lin, Shuiguang Deng, Alex X. Liu, and Raheem Beyah. 2021. MPInspector: A Systematic and Automatic Approach for Evaluating the Security of IoT Messaging Protocols. In 30th USENIX Security Symposium, USENIX Security 2021, August 11-13, 2021, Michael Bailey and Rachel Greenstadt (Eds.). USENIX Association, 4205–4222. https://www.usenix.org/conference/usenixsecurity21/presentation/wang-qinying
[163] Zhuzhu Wang and Ying Wang. 2023. NLP-based Cross-Layer 5G Vulnerabilities Detection via Fuzzing Generated Run-Time Profiling. arXiv preprint arXiv:2305.08226 (2023).
[164] Huiyu Wu and Yuxiang Li. 2021. X-in-the-Middle: Attacking Fast Charging Piles and Electric Vehicles. https://www.blackhat.com/asia-21/briefings/schedule/#x-in-the-middle-attacking-fast-charging-piles-and-electric-vehicles--22055
[165] Jianliang Wu, Ruoyu Wu, Daniele Antonioli, Mathias Payer, Nils Ole Tippenhauer, Dongyan Xu, Dave (Jing) Tian, and Antonio Bianchi. 2021. LIGHTBLUE: Automatic Profile-Aware Debloating of Bluetooth Stacks. In 30th USENIX Security Symposium (USENIX Security 21). USENIX Association, 339–356. https://www.usenix.org/conference/usenixsecurity21/presentation/wu-jianliang
[166] Haikuo Xie, Ying Wang, and Ye Zhang. 2020. WIFI-Important Remote Attack Surface: Threat is Expanding. https://www.blackhat.com/asia-20/briefings/schedule/#wifi-important-remote-attack-surface-threat-is-expanding-18784
[167] Han Yan, Lewei Qu, and Dongxiang Ke. 2022. BrokenMesh: New Attack Surfaces of Bluetooth Mesh. https://www.blackhat.com/us-22/briefings/schedule/#brokenmesh-new-attack-surfaces-of-bluetooth-mesh-26853
[168] Youngseok Yang, Taesoo Kim, and Byung-Gon Chun. 2021. Finding Consensus Bugs in Ethereum via Multi-transaction Differential Fuzzing. In 15th USENIX Symposium on Operating Systems Design and Implementation (OSDI 21). USENIX Association, 349–365. https://www.usenix.org/conference/osdi21/presentation/yang
[169] Affan Yasin, Rubia Fatima, Lijie Wen, Wasif Afzal, Muhammad Azhar, and Richard Torkar. 2020. On Using Grey Literature and Google Scholar in Systematic Literature Reviews in Software Engineering. IEEE Access 8 (2020), 36226–36243. https://doi.org/10.1109/ACCESS.2020.2971712
[170] Ta-Lun Yen, Federico Maggi, Erik Boasson, Victor Mayoral-Vilches, Mars Cheng, Patrick Kuo, and Chizuru Toyama. 2021. The Data Distribution Service (DDS) Protocol is Critical Let’s Use it Securely! https://www.blackhat.com/eu-21/briefings/schedule/#the-data-distribution-service-dds-protocol-is-critical-lets-use-it-securely-24934 [171] Bo Yu, Pengfei Wang, Tai Yue, and Yong Tang. 2019. Poster: Fuzzing IoT Firmware via Multi-Stage Message Generation. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security (London, United Kingdom) (CCS ’19). Association for Computing Machinery, New York, NY, USA, 2525–2527. https://doi.org/10.1145/3319535.3363247
[172] Zhenhua Yu, Haolu Wang, Dan Wang, Zhiwu Li, and Houbing Song. 2022. CGFuzzer: A Fuzzing Approach Based on Coverage-Guided Generative Adversarial Networks for Industrial IoT Protocols. IEEE Internet of Things Journal 9, 21 (2022), 21607–21619. https://doi.org/10.1109/JIOT.2022.3183952
[173] Insu Yun, Sangho Lee, Meng Xu, Yeongjin Jang, and Taesoo Kim. 2018. {QSYM}: A practical concolic execution engine tailored for hybrid fuzzing. In 27th USENIX Security Symposium (USENIX Security 18). 745–761.
[174] Michal Zalewski. 2015. American fuzzy lop. https://github.com/google/AFL
[175] zardus. 2019. Preeny: Some helpful preload libraries for pwning stuff. https://github.com/zardus/preeny
[176] Cen Zhang, Mingqiang Bai, Yaowen Zheng, Yeting Li, Xiaofei Xie, Yuekang Li, Wei Ma, Limin Sun, and Yang Liu. 2023. Understanding large language model based fuzz driver generation. arXiv preprint arXiv:2307.12469 (2023).
[177] Cen Zhang, Yuekang Li, Hongxu Chen, Xiaoxing Luo, Miaohua Li, Anh Quynh Nguyen, and Yang Liu. 2021. BIFF: PRactical binary fuzzing framework for programs of IoT and mobile devices. In 2021 36th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 1161–1165.
[178] Cen Zhang, Yuekang Li, Hao Zhou, Xiaohan Zhang, Yaowen Zheng, Xian Zhan, Xiaofei Xie, Xiapu Luo, Xinghua Li, Yang Liu 0003, and Sheikh Mahbub Habib. 2023. Automata-Guided Control-Flow-Sensitive Fuzz Driver Generation. In 32nd USENIX Security Symposium, USENIX Security 2023, Anaheim, CA, USA, August 9-11, 2023, Joseph A. Calandrino and Carmela Troncoso (Eds.). USENIX Association, 2867–2884. https://www.usenix.org/conference/usenixsecurity23/presentation/zhang-cen
[179] Cen Zhang, Xingwei Lin, Yuekang Li, Yinxing Xue, Jundong Xie, Hongxu Chen, Xinlei Ying, Jiashui Wang, and Yang Liu. 2021. {APICraft}: Fuzz Driver Generation for Closed-source {SDK} Libraries. In 30th USENIX Security Symposium (USENIX Security 21). 2811–2828.
[180] Zenong Zhang, George Klees, Eric Wang, Michael Hicks, and Shiyi Wei. 2023. Fuzzing Configurations of Program Options. ACM Trans. Softw. Eng. Methodol. 32, 2, Article 53 (mar 2023), 21 pages. https://doi.org/10.1145/3580597 
[181] Hui Zhao, Zhihui Li, Hansheng Wei, Jianqi Shi, and Yanhong Huang. 2019. SeqFuzzer: An Industrial Protocol Fuzzing Framework from a Deep Learning Perspective. In 12th IEEE Conference on Software Testing, Validation and Verification, ICST 2019, Xi’an, China, April 22-27, 2019. IEEE, 59–67. https://doi.org/10.1109/ICST.2019.00016
[182] Yaowen Zheng, Yuekang Li, Cen Zhang, Hongsong Zhu, Yang Liu, and Limin Sun. 2022. Efficient greybox fuzzing of applications in Linux-based IoT devices via enhanced user-mode emulation. In Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis. 417–428.
[183] Yaowen Zheng and Limin Sun. 2022. IPSpex: Enabling Efficient Fuzzing via Specification Extraction on ICS Protocol. In Applied Cryptography and Network Security: 20th International Conference, ACNS 2022, Rome, Italy, June 20–23, 2022, Proceedings, Vol. 13269. Springer Nature, 356.
[184] Xiaogang Zhu, Sheng Wen, Seyit Camtepe, and Yang Xiang. 2022. Fuzzing: A Survey for Roadmap. ACM Comput. Surv. (jan 2022). https://doi.org/10.1145/3512345 Just Accepted.
[185] Xiaogang Zhu, Sheng Wen, Seyit Camtepe, and Yang Xiang. 2022. Fuzzing: A Survey for Roadmap. ACM Comput. Surv. (jan 2022). https://doi.org/10.1145/3512345 Just Accepted.
[186] Qingtian Zou, Anoop Singhal, Xiaoyan Sun, and Peng Liu. 2020. Generating Comprehensive Data with Protocol Fuzzing for Applying Deep Learning to Detect Network Attacks. CoRR abs/2012.12743 (2020). arXiv:2012.12743 https://arxiv.org/abs/2012.12743 
[187] Yong-Hao Zou, Jia-Ju Bai, Jielong Zhou, Jianfeng Tan, Chenggang Qin, and Shi-Min Hu. 2021. TCP-Fuzz: Detecting Memory and Semantic Bugs in TCP Stacks with Fuzzing. In 2021 USENIX Annual Technical Conference (USENIX ATC 21). USENIX Association, 489–502. https://www.usenix.org/conference/atc21/presentation/zou
[188] Feilong Zuo, Zhengxiong Luo, Junze Yu, Ting Chen, Zichen Xu, Aiguo Cui, and Yu Jiang. 2022. Vulnerability Detection of ICS Protocols via Cross-State Fuzzing. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 41, 11 (2022), 4457–4468. https://doi.org/10.1109/TCAD.2022.3201471
[189] Feilong Zuo, Zhengxiong Luo, Junze Yu, Zhe Liu, and Yu Jiang. 2021. PAVFuzz: State-Sensitive Fuzz Testing of Protocols in Autonomous Vehicles. 2021 58th ACM/IEEE Design Automation Conference (DAC) (2021), 823–828.
				
			

همچنین ممکن است دوست داشته باشید

پیام بگذارید

wpChatIcon
wpChatIcon