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

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

این یافته‌ها حاکی از آن هستند که چرخه انتقال نتایج پژوهش‌های آکادمیک (ادبیات پژوهشی) به ابزارهای عملی محدود بوده و تنها بخش کوچکی از توسعه‌های آکادمیک ارائه ‌شده برای ++AFL یا نسخه پیشین آن، AFL، مجدداً در نسخه‌های پایه این ابزارها ادغام شده‌اند. گفت‌وگو با توسعه‌دهندگان اصلی این ابزارها نشان‌ دهنده افزایش شکاف میان پژوهش و عمل است؛ مسئله‌ای که بر ضرورت تقویت استانداردهای تکرارپذیری یا قابلیت بازتولید (reproducibility standards) و استفاده از معیارهای ارزیابی واقع‌بینانه‌تر تأکید می‌کند.

در راستای تکمیل این دیدگاه بیرونی به میزان پذیرش، دومین دستاورد این پژوهش بر یک محدودیت الگوریتمی درونی در فازرهای مدرن نظیر ++AFL متمرکز است. از این رو، پدیده سایه‌سازی ورودی (input shadowing) مورد تحلیل قرار می‌گیرد؛ یک اثر جانبی ظریف در فازرهای هدایت‌ شده با پوشش کد (coverage-guided fuzzers) که از راهبردهای مدیریت مجموعه ورودی (corpus) مبتنی بر جست‌وجوی نوآوری استفاده می‌کنند.

ما در ادامه، یک راهکار ساده اما مؤثر که راه‌اندازی مجدد دوره‌ای فازر می‌باشد را به ‌منظور بازنشانی وضعیت جست‌وجوی آن پیشنهاد می‌دهیم. با وجود سادگی این روش، نتایج بدست آمده بیانگر آن است که این رویکرد موجب بهبود اکتشاف فضای ورودی (exploration) و کشف باگ (bug) می‌گردد؛ یافته‌ای که نشان می‌دهد، مداخلات کوچک و عملی می‌توانند در برخی موارد نسبت به الگوریتم‌های پیچیده‌، کارآمدتر بوده و عملکرد بهتری داشته باشند.

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

این رساله استدلال می‌کند که آینده فازینگ نه در افزایش پیچیدگی‌های فنی، بلکه در بازتعریف مفهوم «پیشرفت» نهفته است: تکرارپذیری به‌ جای نوآوریِ صِرف، سادگی به‌جای پیچیدگی و تأثیر واقعی در دنیای عملی به‌ جای معیارهای مصنوعی.

بخش اول: زمینه پژوهش (Scientific Context)

1. مقدمه (Introduction)

فازینگ (Fuzzing) و به ‌طور کلی آزمون امنیت (security testing)، طی دهه‌های گذشته به دلیل افزایش مداوم تعداد دستگاه‌های مبتنی بر نرم‌افزار (مانند رایانه‌ها، تلفن‌های هوشمند و انواع سیستم‌های نهفته (embedded systems) تشکیل‌دهنده اینترنت اشیاء (Internet of Things)) توجه زیادی را به خود جلب کرده است. با افزایش تعداد دستگاه‌های متصل به اینترنت و گسترش سطح حمله در سامانه‌هایی که داده‌های شخصی را در رایانه‌ها و تلفن‌های هوشمند ذخیره می‌کنند، آگاهی نسبت به مخاطرات امنیتی نیز افزایش یافته و در نتیجه اهمیت امنیت بیش از پیش پررنگ شده است. سامانه‌های آسیب‌پذیر، نشت داده‌ها (data leaks) یا نرم‌افزارهای دارای باگ (Bug) می‌توانند بحران‌هایی ایجاد کنند که نه‌تنها کاربران فردی، بلکه میلیون‌ها دستگاه را تحت تأثیر قرار داده و در صورت درگیر شدن سامانه‌های حیاتی، پیامدهای اقتصادی و اجتماعی گسترده‌ای به همراه داشته باشند [44, 54, 131].

اگرچه برخی آسیب‌پذیری‌ها ممکن است به‌طور مستقیم برای کاربران عادی تهدیدآمیز و آسیب‌زا نباشند، اما در صورت بهره‌برداری توسط عوامل دولتی، مجرمان و گروه‌های تروریستی، می‌توانند به‌ عنوان ابزاری برای توسعه جاسوس‌افزار و بدافزار مورد استفاده قرار گیرند و امکان نظارت هدفمند بر روزنامه‌نگاران، فعالان مدنی و سایر افراد را فراهم کنند [53, 64, 87, 110].

در روزهای نخستین رایانش (computing) و اینترنت (internet)، رویکردهایی مانند فازینگ به‌ طور گسترده مورد استفاده قرار نمی‌گرفتند و روش‌های نظام‌مند برای شناسایی باگ‌ها رایج نبودند؛ در نتیجه، بسیاری از آسیب‌پذیری‌ها در زمان انتشار نرم‌افزار بدون شناسایی باقی می‌ماندند. با افزایش پیچیدگی سامانه‌ها و گسترش اتصال‌پذیری، آزمون پویای نرم‌افزار به پاسخی ضروری در برابر چشم‌انداز تهدیدات در حال تحول تبدیل شد. فازرهای اولیه [80] ابزارهای ساده‌ای بودند که ورودی‌های تصادفی را به برنامه تحت آزمون (program under test – PUT) ارسال می‌کردند تا احتمال وقوع کرش‌ها (Crash) را آشکار سازند؛ با این حال، این ابزارها به‌تدریج تکامل یافتند. در حالی‌که آن نخستین تولیدکننده‌های ورودی تصادفی (random input generators) ساختار ورودی را درک نمی‌کردند، رویکردهای مؤثرتری به مرور شکل گرفت از جمله فازینگ مبتنی بر جهش (mutation-based fuzzing) و روش‌های هیبریدی (hybrid) که فازینگ را با اجرای نمادین/کانکولیک (symbolic/concolic execution) [47, 122, 137] یا ردگیری آلودگی (taint tracking) [23, 45, 100, 130] ترکیب می‌کنند.

علاوه بر این، قابلیت کشف خطا با بهبود اوراکل‌های خطای (bug oracles) موجود یا توسعه اوراکل‌های جدید ارتقا یافت [106, 111, 121]. یک نقطه عطف مهم در تاریخ فازینگ، معرفی بازخورد مبتنی بر پوشش (coverage feedback) و انتشار AFL بود [138] که فازینگ مبتنی بر بازخورد (feedback-driven fuzzing) را رایج کرد و امکان خودکارسازی در مقیاس بزرگ را عملی ساخت.

بر این اساس، صنعت، استفاده از فازینگ را در مقیاسی بی‌سابقه گسترش داد؛ به‌گونه‌ای که OSS-Fuzz از گوگل [50] و OneFuzz از مایکروسافت [21]، فازینگ مداوم را در خطوط توسعه نرم‌افزار ادغام کردند. علاوه بر این، توسعه AFL موجب شکل‌گیری حجم گسترده‌ای از پژوهش‌های دانشگاهی شد که با هدف بهبود کارایی فازینگ [3, 39, 72, 74, 92]، گسترش آن به دسته‌های جدیدی از هدف‌ها [95, 109, 135] و حتی بررسی رویکردهای ضدفازینگ (counterfuzzing) [55, 65] صورت پذیرفت.

علاقه‌مندی به حوزه فازینگ در دهه گذشته همچنان در سطح بالایی باقی مانده است، با این حال پیشرفت در این حوزه به‌تدریج نشانه‌هایی از بازده نزولی را نشان می‌دهد. هرچه تکنیک‌های پیچیده‌تری پیشنهاد می‌شوند، تأثیر عملی یا میزان کارآمدی آن‌ها اغلب محل تردید است. بهبودها معمولاً تنها روی معیارهای آزمایشی مصنوعی یا با آزمون همان مجموعه محدود از اهداف دنیای واقعی نشان داده می‌شوند؛ از جمله GNU Binutils، در حالی که آزمایش‌های مربوط به کشف باگ اغلب بر نرم‌افزارهایی با نگهداری ضعیف‌تر متمرکز هستند. فازینگ چنین نرم‌افزارهایی تقریباً همواره به کشف آسیب‌پذیری منجر می‌شود؛ موضوعی که سپس می‌تواند برای ادعای «اثرگذاری در دنیای واقعی» در مقالات پژوهشی مورد استفاده قرار گیرد. این روند موجب کاهش میزان پذیرش تکنیک‌های جدید در صنعت و در نتیجه ایجاد نوعی سکون در این حوزه شده است.

نخستین دستاورد ما به بررسی این پدیده می‌پردازد و نشان می‌دهد که نه‌تنها فازرهای جامعه‌محور مانند ++AFL و LibAFL، بلکه فازر موتور جاوااسکریپت (JavaScript engine fuzzer) مورد استفاده در صنعت یعنی Fuzzilli نیز نشانه‌هایی از توقف و سکون را بروز می‌دهند. تحلیل دیگری نیز تأیید می‌کند که تعداد مشارکت‌های دانشگاهی که با موفقیت در ++AFL ادغام شده‌اند، به یک وضعیت اشباع و توقف نسبی رسیده است. در این پژوهش، عوامل اصلی این عدم پذیرش شامل بهبودهای عملی محدود، چالش‌های تکرارپذیری و بازتولید نتایج، و فرضیات غیرواقع‌بینانه در پژوهش‌های آکادمیک شناسایی می‌شوند.

به‌جای توسعه راه‌حل‌های کاملاً جدید و پیچیده برای پیشبرد فازینگ جعبه خاکستری هدایت ‌شده با پوشش کد (coverage-guided greybox fuzzing)، می‌توان رویکرد مؤثرتری را در بازبینی تکنیک‌های موجود و شناسایی ضعف‌های نهفته در روش‌های الگوریتمی فعلی جست‌وجو کرد. به عنوان مثال، فازرهایی مانند AFL و ++AFL از الگوریتمی مبتنی بر جست‌وجوی جدید و نوآوری‌محور (Novelty Search) استفاده می‌کنند تا تعیین کنند آیا یک ورودی جدید تولید شده «جالب – (interesting)» محسوب می‌شود و باید برای جهش‌های بعدی نگه‌داری شود یا خیر. با این حال، این رویکرد دارای یک پیامد پنهان است که ما آن را سایه‌سازی ورودی (input shadowing) می‌نامیم. این پدیده می‌تواند مانع تنوع‌بخشی فازر به مجموعه ورودی (corpus) خود شود و در نتیجه، کشف ورودی‌هایی را که برای جهش مناسب‌تر هستند محدود کند.

دومین دستاورد این پژوهش به تحلیل راهکار «راه‌اندازی مجدد فازر» می‌پردازد و یک روش ساده برای کاهش این مشکل ارائه می‌دهد. ما در این پژوهش نشان خواهیم داد که راه‌اندازی مجدد فازر در زمانی که پیشرفت متوقف می‌شود، در حالی که بخشی از مجموعه ورودی تولید شده قبلی حفظ شده است، می‌تواند هم پوشش (coverage) و هم نرخ کشف باگ را بهبود بخشد. در مقایسه با تکنیک‌های پیچیده و پرهزینه‌ای که معمولاً در مقالات پیشنهاد می‌شوند، این رویکرد به ‌سادگی قابل پیاده‌سازی است، با این حال به‌ صورت پایدار عملکردی بهتر از مبنای ++AFL ارائه می‌دهد. این یافته‌ها حاکی از آن هستند که نقاط کور، مانند محدودیت‌های جست‌وجوی نوآوری‌محور و جدید مبتنی بر پوشش (coverage-based novelty search)، نیازمند توجه دقیق‌تر و بررسی نظام‌مندتر در پژوهش‌های آینده می‌باشند.

چنین رویکردهای تثبیت‌ شده در فازینگ که برای نرم‌افزارهای متعارف طراحی شده‌اند، بر مجموعه‌ای از فرضیات مشخص درباره برنامه هدف متکی هستند. این فرضیات دیگر زمانی که این روش‌ها بر روی سامانه‌های پیچیده‌تر مبتنی بر سخت‌افزار اعمال می‌شوند، برقرار نیستند. دستاورد نهایی این رساله، چالش‌هایی را بررسی می‌کند که هنگام گسترش فازینگ فراتر از اهداف نرم‌افزاری سنتی و به سمت سامانه‌های اختصاصی متشکل از چندین زیرسامانه و ترکیبات ناهمگن از نرم‌افزار و میان‌افزار (firmware) پدید می‌آیند. ما این چالش‌ها را با استفاده از پهپادهای مصرفی پیشرفته موجود در بازار که توسط شرکت DJI تولید شده‌اند، نشان می‌دهیم. برخلاف معیارهای فازینگ معمولی یا اهداف نرم‌افزاری آزمایش‌ شده، این دستگاه‌ها را نمی‌توان به راحتی برای بازخورد پوشش (coverage feedback) یا اوراکل‌های باگ (bug oracles)، از جمله ASan، ابزارگذاری (instrument) کرد.

فروشنده، این امکان را محدود کرده و مجموعه‌ای متنوع از میان‌افزار (firmware) و سیستم‌عامل‌ها را در این دستگاه‌ها به‌کار گرفته است، به‌گونه‌ای که برای مثال، راهبردهای متداول فازینگ مبتنی بر بازمیزبانی مجدد (rehosting-based fuzzing) در عمل غیرقابل استفاده می‌شوند. به منظور مقابله با این محدودیت‌ها، ما یک رویکرد فازینگ مبتنی بر سخت‌افزار-در-حلقه (hardware-in-the-loop) را توسعه داده‌ایم که در آن ورودی‌ها از طریق USB به پهپاد ارسال می‌شوند و کنترل‌کننده از راه دور و برنامه همراه به ‌عنوان اوراکل‌های باگ (Bug Oracles) عمل می‌کنند. ما با استفاده از این چارچوب، آسیب‌پذیری‌هایی را کشف کردیم که می‌توانند برای دستیابی به سطح دسترسی ریشه (root access) روی این پهپادها مورد سوءاستفاده قرار گیرند.

چندین بینش کلیدی توسط این مطالعات، حاصل می‌شود. نخست آن‌که پیشرفت در فازینگ عمومی دیگر عمدتاً به فقدان تکنیک‌های جدید محدود نیست، بلکه اغلب تحت تأثیر چالش‌های مربوط تکرارپذیری یا قابلیت بازتولید، یکپارچه‌سازی و واقع‌گرایی در ارزیابی قرار دارد. دوم آن‌که، برخی از اثرگذارترین مؤلفه‌های طراحی در فازرهای مدرن، به ‌ویژه ترکیب جست‌وجوی نوآوری‌محور (novelty search) با دسته‌بندی پوشش (coverage bucketing)، محدودیت‌های ظریف اما مهمی را ایجاد می‌کنند که می‌توانند به ‌صورت پنهان فضای اکتشاف را محدود سازند.

در نهایت، به‌کارگیری فازینگ در سامانه‌های اختصاصی یا وابسته به سخت‌افزار نشان می‌دهد که محدودیت‌های دنیای واقعی مانند رابط‌های بسته (closed interfaces)، بازخورد محدود (limited feedback) و محیط‌های اجرای ناهمگن (heterogeneous execution environments) تا چه اندازه بر آنچه به ‌صورت عملی قابل دستیابی است تأثیرگذار هستند.

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

دستاوردهای رساله. مهم‌ترین دستاوردهای این رساله به شرح زیر قابل خلاصه‌سازی می‌باشند:

تکامل و پذیرش فازینگ‌های پیشرفته. ما روند تکامل فازر جامعه‌محور ++AFL را از زمان انتشار آن در سال ۲۰۱۹ تا سال ۲۰۲۵ تحلیل می‌کنیم. در ادامه، این بررسی را با یک تحلیل پژوهشی از مقالات حوزه فازینگ در کنفرانس‌های سطح A* بین سال‌های ۲۰۱۸ تا ۲۰۲۴ تکمیل می‌کنیم؛ مقالاتی که بر مبنای AFL یا ++AFL توسعه یافته‌اند. در نهایت، ما امکان‌ ادغام دستاوردهای آنها را در ابزارهای مربوطه این پژوهش‌ ارزیابی می‌کنیم (رجوع شود به مقاله: «SoK: مطالعه نظام‌مند یکپارچه‌سازی و بازتولید دستاوردهای پژوهشی فازینگ در ++AFL»).
بررسی پدیده سایه‌سازی ورودی (input shadowing). در این بخش، اثر سایه‌سازی ورودی (input shadowing) را بررسی می‌کنیم؛ پدیده‌ای که ناشی از پیاده‌سازی الگوریتم‌های مبتنی بر جست‌وجوی جدید و نوآوری‌محور (Novelty Search) در فازینگ جعبه خاکستری مبتنی بر بازخورد (feedback-driven greybox fuzzing) است. همچنین، راه‌اندازی مجدد فازر همراه با حفظ مجموعه ورودی (corpus retention) را به ‌عنوان یک راهکار ساده اما مؤثر برای کاهش این اثر پیشنهاد می‌دهیم (رجوع شود به مقاله «نوآوری یافت نشد: بررسی سایه‌سازی ورودی در فازینگ از طریق راه‌اندازی مجدد فازر تطبیقی»).
تحلیل امنیتی پهپادهای مصرفی. ما یک تحلیل امنیتی جامع از پهپادهای مصرفی پیشرفته را با استفاده از مهندسی معکوس ارائه می‌دهیم و یک فازر مبتنی بر سخت‌افزار-در-حلقه (hardware-in-the-loop) را توسعه می‌دهیم که از چندین کانال بازخورد بهره می‌گیرد (رجوع شود به مقاله: «امنیت پهپادها و پرونده اسرارآمیز DroneID شرکت DJI»).

ساختار رساله. این پژوهش یک رساله تجمیعی است که بر پایه سه مقاله داوری ‌شده (peer-reviewed) تدوین گشته و به دو بخش تقسیم می‌شود. بخش نخست، زمینه گسترده‌تر پژوهش را معرفی کرده و پیش‌نیازهای لازم را در حوزه فازینگ و پهپادهای مصرفی تشریح می‌کند. همچنین، چالش‌های موجود در حوزه فازینگ را مورد بررسی قرار می‌دهد؛ از جمله میزان پذیرش تکنیک‌های دانشگاهی فازینگ، نقاط کور الگوریتمی مانند پدیده سایه‌سازی ورودی (input shadowing) و دشواری‌های عملی به‌کارگیری فازینگ در سامانه‌های اختصاصی، از جمله پهپادهای مصرفی. این بخش با جمع‌بندی محدودیت‌های فعلی و ارائه مسیرهای آتی پژوهش به پایان می‌رسد.

بخش دوم این رساله شامل نسخه عیناً نقل‌ شده (verbatim) مقالاتی است که زیربنای این رساله را تشکیل می‌دهند و در پیوست‌های A تا C ارائه شده‌اند. اطلاعات انتشار آن‌ها به شرح زیر است:

[A] نیکو شیلر، موریتس شلوگل، نیلز بارس، تورستن هولتس. «SoK: مطالعه نظام‌مند یکپارچه‌سازی و بازتولید دستاوردهای پژوهشی فازینگ در ++AFL». در حال بررسی برای انتشار (Under Submission).

[B] نیکو شیلر، شینی شو، لوکاس برنهارد، نیلز بارس، موریتس شلوگل، تورستن هولتس. «نوآوری یافت نشد: بررسی سایه‌سازی ورودی در فازینگ از طریق راه‌اندازی مجدد فازر تطبیقی». منتشرشده در نشریه ACM Transactions on Software Engineering and Methodology، سال ۲۰۲۵.

[C] نیکو شیلر، مرلین کلوستا، موریتس شلوگل، نیلز بارس، تورستن آیزنهوفر، توبیاس شارنوفسکی، فلیکس دومکه، لیا شونهر، و تورستن هولتس. «امنیت پهپادها و پرونده اسرارآمیز DroneID شرکت DJI». ارائه‌ شده در همایش امنیت شبکه و سامانه‌های توزیع‌شده (NDSS Symposium)، سال ۲۰۲۳.

۲. پیش‌زمینه فنی (Technical Background)

این فصل، پیش‌زمینه‌های لازم برای ادامه این رساله را ارائه می‌دهد. ابتدا مفاهیم کلی و انواع مختلف فازینگ معرفی می‌شوند و سپس مروری بر معماری و پیچیدگی پهپادهای مصرفی مدرن ارائه خواهد شد.

۲.۱ فازینگ (Fuzzing)

فازینگ (Fuzzing) یا آزمون فازینگ (fuzz testing)، یک روش آزمون خودکار نرم‌افزار است که برای کشف باگ‌ها (bugs) و آسیب‌پذیری‌ها (vulnerabilities) در سامانه‌های نرم‌افزاری مختلف به کار می‌رود. اصل اساسی فازینگ، ارائه جریان پیوسته‌ای از ورودی‌ها به سامانه تحت آزمایش ( SUT – system under test) است که از ورودی‌های کاملاً تصادفی (random) تا ورودی‌های نیمه معتبر (semi-valid) یا بسیار ساختاریافته (highly structured) و در عین حال غیرمنتظره، متغیر است. این ورودی‌ها می‌توانند به‌ صورت دنباله‌های دلخواه بایتی باشند یا بر اساس دستور زبان‌ها (grammar) و مشخصات پروتکل (protocol specifications)، به‌صورت دقیق و ساخت‌یافته تولید شوند.

مفهوم تولید ورودی‌های غیرمنتظره برای آزمون پایداری نرم‌افزار به دهه ۱۹۷۰ بازمی‌گردد. در آن زمان، مهندس K.V. Hanford از شرکت IBM، ماشین نحوی (syntax machine) را معرفی کرد [57]. این ابزار به ‌صورت خودکار برنامه‌های آزمون را تولید می‌کرد که از نظر نحوی معتبر، اما از نظر معنایی برای ECMA Algol و FORTRAN IV بی‌اهمیت بودند. اگرچه این ورودی‌ها از دستور زبان پیروی می‌کردند، اما نتایج اجرای آن‌ها اغلب «غیرقابل پیش‌بینی و غیرقابل بررسی» بود. از این رو، نقص‌هایی را در کامپایلرها (compiler) و مفسرها (interpreter) آشکار می‌کردند. با این حال، اصطلاح «فازینگ» (fuzzing) به اواخر دهه ۱۹۸۰ و اوایل دهه ۱۹۹۰ و مطالعات و اقدامات Miller و همکارانش بازمی‌گردد [80].

ابزار آنها که “Fuzz” نام داشت، دنباله‌های تصادفی از کاراکترهای قابل چاپ و کنترل تولید می‌کرد که از طریق ورودی استاندارد (standard input) به ابزارهای خط فرمان UNIX ارسال می‌شدند. این رویکرد اولیه فازینگ که به‌ عنوان فازینگ جعبه ‌سیاه (black-box) یا فازینگ کور (blind fuzzing) شناخته می‌شود، برنامه هدف را به ‌عنوان یک جعبه‌ سیاه در نظر می‌گرفت و هیچ فرضی درباره ساختار ورودی مورد انتظار آن نداشت. هدف این روش، شناسایی خطاهایی مانند کرش‌ها (crash) یا حلقه‌های بی‌نهایت (infinite loops) بود. با این حال، سازوکار تشخیص خطا در این روش بسیار ابتدایی و ساده‌انگارانه بود: کرش‌ها به ‌صورت ایجاد دامپ هسته (core dump – تخلیه حافظه فرایند در زمان خطا) و هنگ‌ها به‌ صورت فرایندهای بدون پایان ظاهر می‌شدند. اگرچه این رویکرد ساده بود، اما در عمل توانست به ‌طور مؤثر باگ‌های متعددی را در ابزارهای پرکاربرد UNIX شناسایی کند.

فازینگ در سال‌های بعد، با معرفی تکنیک‌های مبتنی بر جهش (mutation-based) به‌ طور قابل توجهی تکامل یافت. فازرها در این رویکرد، به‌ جای اتکا صرف به تولید ورودی‌های کاملاً تصادفی، از مجموعه‌ای از ورودی‌های نمونه با عنوان فایل‌های بذر (seed files) استفاده کرده و با اعمال تغییراتی مانند وارون‌سازی بیت‌ها (bit flips) یا جایگزینی بایت‌ها (byte substitutions)، موارد آزمون (test case) جدید تولید می‌کردند. این استراتژی، ورودی‌های نیمه معتبری تولید می‌کرد که تا حدی ساختار ورودی صحیح را حفظ کرده و در نتیجه، احتمال رسیدن به مسیرهای عمیق‌تر کد و تحریک باگ‌های پیچیده‌تر را افزایش می‌داد. فازینگ در اواسط دهه ۲۰۰۰، به ‌تدریج شروع به بهره‌گیری از تکنیک‌های پیشرفته‌تر کرد.

پژوهشگران روش‌هایی مبتنی بر الگوریتم‌های تکاملی و مدل‌های مارکوف (Markov) را برای هدایت بهتر تولید ورودی معرفی کردند [26, 119]. علاوه بر این، رویکردهای هیبریدی (hybrid) نیز شکل گرفتند که فازینگ را با روش‌های سنگین تحلیل برنامه مانند اجرای نمادین (symbolic execution) [20, 48] و تحلیل آلودگی (taint analysis) [45, 130] ترکیب می‌کردند. همچنین، تکنیک‌های ابزارگذاری (instrumentation)، چه در سطح کد منبع و چه از طریق بازنویسی باینری (binary rewriting)، برای ردگیری پوشش (coverage) و بهبود انتخاب ورودی‌ها معرفی شدند. یک نقطه عطف مهم در این مسیر، انتشار AFL (American Fuzzy Lop) در سال ۲۰۱۳ توسط Michał Zalewski بود [138].

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

در سال‌های بعد، فازرهای متعددی بر پایه ایده‌های AFL توسعه یافتند و نسخه تکامل‌یافته آن، ++AFL، امروزه به‌ عنوان استاندارد غیررسمی و بالفعل (de facto) در فازینگ عمومی شناخته می‌شود. بخش بعدی با تکیه بر این پیش‌زمینه، اصول بنیادین و تکنیک‌های ابزارگذاری را که فازرهای مدرن بر آن‌ها استوار می‌باشند، مورد بررسی قرار می‌دهد.

فازینگ کور (Blind Fuzzing). فازینگ کور یا جعبه ‌سیاه (black-box fuzzing) به مجموعه‌ای از تکنیک‌ها اشاره دارد که در آن برنامه هدف به ‌عنوان یک جعبه ‌سیاه در نظر گرفته می‌شود؛ به این معنا که فازر تنها بازخورد بسیار محدودی دریافت می‌کند که معمولاً به کرش‌ها (Crash) یا هنگ‌های (hang) قابل مشاهده محدود است، بدون آن‌که اطلاعاتی از پوشش کد یا وضعیت اجرای داخلی در اختیار داشته باشد. فازر در غیاب بازخورد پوشش (coverage feedback)، از این‌که کدام مسیرهای کد تاکنون پیمایش شده‌اند و کدام ورودی‌ها برای کشف رفتارهای جدید مؤثرتر هستند، آگاه نیست. در نتیجه، امکان هدایت هوشمندانه جهش‌ها را از دست می‌دهد که این امر معمولاً به کاهش کارایی در پوشش کد و افت نرخ کشف باگ منجر می‌شود. این دسته از فازرها از نظر مفهومی به رویکرد اولیه‌ای که توسط Miller و همکاران معرفی شد نزدیک می‌باشند [80]. این محدودیت زمانی تشدید می‌شود که هیچ بذر ورودی اولیه‌ای (seed inputs) در اختیار فازر قرار نگیرد. فازر بدون مجموعه ورودی بذر (seed corpus)، ناگزیر است ورودی‌ها را از صفر تولید کند که معمولاً از طریق تولید کاملاً تصادفی انجام می‌شود. این تصادفی بودن، احتمال تولید ورودی‌های معتبر یا نیمه‌معتبر را که قادر به اجرای معنادار منطق برنامه باشند، به‌طور قابل‌توجهی کاهش می‌دهد. با وجود این محدودیت‌ها، فازینگ کور همچنان یک رویکرد سبک و عملی محسوب می‌شود، به ‌ویژه در سناریوهایی که هیچ اطلاعاتی از هدف در دسترس نیست، دسترسی به کد منبع وجود ندارد، یا ابزارگذاری باینری (binary instrumentation) امکان‌پذیر نیست. این موارد شامل کاربردهایی مانند فازینگ میان‌افزار (firmware) در سخت‌افزارهای نهفته (embedded hardware) یا سامانه‌های اختصاصی می‌شود که در آن‌ها تحلیل جعبه ‌سفید (white-box) امکان‌پذیر نیست [22, 38].

فازینگ جعبه خاکستری (Greybox Fuzzing). در مقابل فازینگ کور یا جعبه‌ سیاه (blind or black-box fuzzing)، که در آن هیچگونه بازخوردی وجود ندارد و یا فقط بازخورد بسیار محدودی در دسترس است، فازینگ جعبه خاکستری مبتنی بر بازخورد قرار دارد که از بازخورد پوششی (coverage feedback) استفاده می‌کند. این رویکرد از ابزارگذاری سبک (lightweight instrumentation)‌ به منظور پایش اجرای برنامه در حین فرآیند فازینگ بهره‌مند می‌شود. ابزارگذاری می‌تواند در زمان کامپایل [41, 138] و با درج مستقیم کدهای ردگیری در برنامه انجام شود و یا به‌ صورت پویا در زمان اجرا و از طریق تکنیک‌های بازنویسی باینری [28, 82, 83, 84] اعمال گردد.

این بازخورد به فازر این قابلیت را می‌دهد که تشخیص دهد آیا یک ورودی مشخص موجب فعال‌سازی مسیرهای اجرایی جدید یا نواحی تازه‌ای از کد در برنامه هدف شده است یا خیر. در صورتی که پوشش کد جدیدی شناسایی شود، آن ورودی به‌عنوان «جالب» (interesting) در نظر گرفته شده و برای جهش‌های بعدی در مجموعه ورودی (corpus) ذخیره می‌گردد. این تکنیک با عنوان جهش هدایت‌ شده با پوشش کد (coverage-guided mutation) شناخته می‌شود. یکی از تأثیرگذارترین و پرکاربردترین فازرهای جعبه خاکستری، AFL [138] به ‌همراه نسخه بهبود‌یافته آن یعنی AFL++ [41] می‌باشند.

فازینگ دستور زبان (Grammar Fuzzing). هدف اصلی یک فازر، تولید یا جهش ورودی‌ها به‌گونه‌ای است که سامانه تحت آزمون (SUT) آن‌ها را بپذیرد، اما این ورودی‌ها شامل تغییرات ظریفی می‌باشند که بتوانند رفتار نامعین (undefined behavior) را تحریک کرده و یا مسیرهای کد دارای خطا را آشکار کنند. برای قالب‌های باینری یا ساختارهای نسبتاً آزاد، چنین جهش‌هایی معمولاً به ‌صورت عملیات ساده‌ای انجام می‌شوند؛ از جمله وارون‌سازی بیت (bit flipping)، جایگزینی بایت (byte substitution)، درج (insertion) یا حذف (deletion). این تغییرات اغلب تا حدی ساختار ورودی را حفظ می‌کنند که از رد شدن فوری آن توسط سامانه جلوگیری شود و در نتیجه امکان کاوش عمیق‌تر کد فراهم گردد.

در مقابل، هنگام هدف قرار دادن برنامه‌هایی که ورودی‌های بسیار ساختاریافته مانند SQL ،XML یا سایر زبان‌های خاص دامنه را پردازش می‌کنند، جهش‌های سنتی در سطح باینری کارایی کمتری دارند. وارون‌سازی یک بیت (single-bit flip) در یک ورودی متنی ممکن است نحو (syntax) آن را خراب کند، توکن‌ها (token) را تغییر دهد یا به‌ طور کامل قواعد ساختاری را نقض کند که در نتیجه موجب رد شدن ورودی توسط تجزیه‌گر (parser) پیش از رسیدن به هرگونه منطق فراتر از مرحله تجزیه می‌شود. به منظور مقابله با این مسئله، از فازینگ مبتنی بر دستور زبان (grammar-based fuzzing) استفاده می‌شود. فازرهای دستور زبان (Grammar fuzzers) یا جهش‌دهنده‌های آگاه از دستور زبان (grammar-aware mutators) ورودی‌ها را بر اساس دستور زبان‌های صریح یا نیمه‌صریحی تولید می‌کنند که ساختار نحوی ورودی‌های معتبر را توصیف می‌کنند. این دستور زبان‌ها می‌توانند به شکل دستور زبان‌های مستقل از متن (context-free grammars) یا مجموعه‌ای از قواعد سفارشی تعریف شوند.

در این روش، از تکنیک‌هایی مانند تبدیلات درخت نحو انتزاعی (AST – Abstract Syntax Tree)، جهش‌های آگاه از توکن (token-aware mutations) و ترکیب مجدد مبتنی بر درخت (tree-based recombination) استفاده می‌شود تا ضمن ایجاد تغییرات مهم و معنادار، اعتبار ساختاری حفظ شود [46, 128]. با تضمین صحت نحوی، فازرهای مبتنی بر دستور زبان احتمال عبور ورودی‌های تولید شده از مرحله تجزیه اولیه (parsing) و رسیدن آن‌ها به بخش‌های عمیق‌تر کد را افزایش می‌دهند [2, 120]. با این حال، این رویکرد زمانی بیشترین کارایی را دارد که یک دستور زبان دقیق و جامع در دسترس باشد. یک دستور زبان بیش ‌از حد محدودکننده یا ناقص می‌تواند فضای ورودی را محدود کرده، از کشف حالت‌های مرزی جلوگیری کند و یا حتی رفتارهای غیرمنتظره ایجاد نماید.

علاوه بر این، در مورد قالب‌های نیمه‌ساختار‌یافته مانند HTML یا JSON که تا حدی عدم‌سخت‌گیری ساختاری را تحمل می‌کنند، فازرها می‌بایست میان حفظ اعتبار نحوی (syntactic validity) و جهش اکتشافی (exploratory mutation) تعادل دقیقی برقرار کنند تا بدون محدود شدن بیش از حد به دستور زبان، بتوانند آسیب‌پذیری‌های ظریف را آشکار سازند.

بازخورد پوشش (Coverage Feedback). بازخورد پوشش، سازوکار اصلی است که فازرهای جعبه خاکستری (grey-box fuzzers) را قادر می‌سازد فضای ورودی را به ‌صورت کارآمد کاوش کرده و رفتارهای جدید برنامه را کشف کنند. برای دریافت این بازخورد در زمان اجرا، لازم است برنامه هدف اطلاعاتی درباره بخش‌هایی از کد که توسط یک ورودی مشخص اجرا شده‌اند ارائه دهد؛ این اطلاعات معمولاً به‌ صورت یال‌های برنامه (program edges) یا بلوک‌های پایه (basic blocks) بیان می‌شوند. این امر از طریق ابزارگذاری (instrumentation) چه در زمان کامپایل و چه در صورتی که کد منبع در دسترس باشد و یا از طریق بازنویسی باینری (binary rewriting) زمانی که تنها فایل اجرایی در دسترس است، محقق می‌شود.

ابزارگذاری در زمان کامپایل می‌تواند با استفاده از گذرهای کامپایلر (compiler passes – یعنی مراحل پردازش در فرآیند کامپایل) انجام شود؛ برای مثال از طریق SanitizerCoverage [73] در LLVM که در نقاط کلیدی برنامه از جمله ورود به توابع، بلوک‌های پایه (basic blocks) یا یال‌های جریان کنترل (control flow edges) فراخوانی‌هایی را(callbacks) درج می‌کند.

هنگامی که در زمان اجرا به یکی از این نقاط ابزارگذاری ‌شده دسترسی پیدا شود، فراخوانی یا callback مربوطه یک ناحیه حافظه مشترک را به‌روزرسانی می‌کند که معمولاً با عنوان نقشه پوشش (coverage map) شناخته می‌شود. این نقشه پوشش معمولاً به‌ صورت یک آرایه با اندازه ثابت در حافظه مشترک بین فازر و فرایند هدف پیاده‌سازی می‌شود. هر خانه از این نقشه نمایانگر یک یال (Edge) یا بلوک (Block) مشخص در گراف جریان کنترل (control flow graph) برنامه است. زمانی که یک ورودی جدید موجب شود یک یال برای نخستین‌بار پیمایش و مشاهده شود، بیت یا بایت متناظر در این نقشه به ‌روزرسانی (تنظیم یا افزایش) می‌گردد. سپس فازر بررسی می‌کند که آیا این اجرا در مقایسه با اجراهای قبلی، پوشش جدیدی ایجاد کرده است یا خیر. در صورت مثبت بودن پاسخ، ورودی به‌ عنوان بخشی از مجموعه ورودی (corpus) ذخیره می‌شود، زیرا نشان‌ دهنده یک مسیر رفتاری جدید است و می‌تواند به ‌عنوان بذر برای جهش‌های بعدی مورد استفاده قرار گیرد.

این سازوکارِ بازخوردیِ سبک و با توان عملیاتی بالا به فازرهای جعبه خاکستری اجازه می‌دهد ورودی‌هایی را که موجب افزایش پوشش کد می‌شوند به‌طور مؤثر اولویت ‌بندی کرده و تکامل دهند؛ در نتیجه این فازرها به ‌مراتب کارآمدتر از رویکردهای کاملاً تصادفی یا کور عمل می‌کنند. تکنیک‌های متعددی در سال‌های اخیر به منظور بهبود کارایی بازخورد پوشش توسعه یافته‌اند [4, 51, 124] که به فازر کمک می‌کنند بر موانعی مانند مقادیر جادویی (magic values) یا مقایسه‌های چندبایتی (multi-byte comparisons) غلبه کند.

++AFL. فازینگ همچنان یک حوزه پژوهشی فعال است که مشارکت‌های قابل توجهی هم از سوی دانشگاه و هم صنعت در آن صورت می‌پذیرد. در میان فازرهای مدرن، AFL++ [41] به یکی از پرکاربردترین ابزارها تبدیل شده است و امروزه به‌ عنوان استاندارد غیررسمی و عملی (de facto) در فازینگ متن‌باز (open-source fuzzing) شناخته می‌شود. این ابزار به‌ عنوان جانشین مستقیم AFL، به ‌طور مکرر به ‌عنوان مبنا (baseline) در ارزیابی فازرهای عمومی مورد استفاده قرار می‌گیرد. ++AFL بر طراحی مبتنی بر پوشش AFL استوار است و از توسعه مداوم و جامعه‌محور بهره می‌برد که این امر، تداوم و اهمیت آن را در بلندمدت تضمین می‌کند.

تکنیک‌ها و بهبودهای جدیدی که از پژوهش‌های دانشگاهی نشات می‌گیرند، اغلب زمانی در ++AFL ادغام می‌شوند که نشان دهند نسبت به وضعیت موجود (فازرهای پیشرفته)، بهبودهای قابل اندازه‌گیری ارائه می‌دهند [4, 16, 141]. از زمان آغاز این پروژه در سال ۲۰۱۹، مجموعه گسترده‌ای از قابلیت‌ها در آن ادغام شده است، از جمله بهبود پشتیبانی از ابزارگذاری [62, 126]، راهبردهای زمان‌بندی مؤثرتر [19, 72, 74]، و عملگرهای پیشرفته جهش (mutation operators) [1, 2, 96, 97, 98, 120].

بازخورد پوشش در ++AFL در هسته خود، همچنان سازوکار مرکزی برای هدایت کاوش محسوب می‌شود. مطابق طراحی اولیه AFL، مسیرهای اجرایی از طریق ابزارگذاری ردیابی شده و در یک بیت‌مپ (bitmap) مشترک ثبت می‌شوند. هر ورودی در این بیت‌مپ متناظر با یک یال اجرایی است، در حالی که تعداد دفعات اجرای هر یال (hit count) در دسته‌های از پیش تعریف ‌شده (buckets) گروه‌بندی می‌شود. در این رویکرد، به‌جای آن‌که شمارش‌های یکسان به ‌عنوان مقادیر متمایز در نظر گرفته شوند، ++AFL تنها گذار بین این دسته‌ها را به‌ عنوان رفتار جدید (novel) تلقی می‌کند [41, 43, 49].

این سازوکار مبتنی بر نوآوری، در ترکیب با دسته‌بندی (bucketing)، از مسئله انفجار مسیرها (path explosion) جلوگیری کرده و در عین حال حساسیت خود را نسبت به تغییرات رفتاری معنادار حفظ می‌کند. در ادامه، یک الگوریتم با رویکرد تکاملی این ورودی‌های «جالب» را پردازش کرده و تعیین می‌کند کدام یک برای جهش‌های بعدی در مجموعه ورودی (corpus) ارتقا یابند.

اوراکل‌های باگ (Bug Oracles). اوراکل‌های باگ به مجموعه‌ای از تکنیک‌ها و سازوکارها در آزمون نرم‌افزار گفته می‌شود که تعیین می‌کنند آیا یک مورد آزمون (test case) موجب بروز خطا در برنامه هدف می‌شود یا خیر. این اوراکل‌ها را می‌توان مشابه انواع خطاها به چند دسته تقسیم کرد؛ از جمله اوراکل‌های کرش (Crash)، مبتنی بر سنی‌تایزر (sanitizer)، و مبتنی بر گزاره تاییدی (assertion). اوراکل کرش ورودی‌هایی را شناسایی می‌کند که موجب خاتمه غیرعادی برنامه هدف می‌شوند، مانند خطای قطعه‌بندی (segmentation fault) یا دریافت سیگنال‌ها. این نوع اوراکل به‌ صورت سنتی در فازرهایی مانند AFL و ++AFL برای تشخیص اولیه خطاها استفاده می‌شود. فراتر از کرش‌ها، بسیاری از تنظیمات از ابزارهای سنی‌تایزر (sanitizer) مانند AddressSanitizer (یا ASan)، ThreadSanitizer (یا TSan) یا سنی‌تایزر رفتار نامشخص (Undefined Behavior Sanitizer) استفاده می‌کنند تا نقض‌های ایمنی حافظه، شرایط رقابتی داده (data races) و سایر انواع رفتار نامعین را آشکار کنند [111, 117].

در عمل، انتخاب اوراکل (oracle) به سامانه تحت آزمون (PUT) نیز وابسته است؛ از جمله این‌که آیا کد منبع برای ابزارگذاری در دسترس است یا هدف صرفاً به ‌صورت باینری ارائه شده است [40, 75]. علاوه بر اوراکل‌های مربوط به ایمنی حافظه، اوراکل‌های وابسته به هدف مانند آزمون تفاضلی (differential testing) [13, 63, 90]، و همچنین اوراکل‌های ساده تشخیص زنده ‌بودن/هنگ (liveness/hang) مانند زمان ‌انقضا (timeout) و نیز بررسی‌های assertion / قرارداد (contract checks) وجود دارند که معانی مورد انتظار را رمزگذاری می‌کنند [6].

هنگام فازینگِ دستگاه‌های نهفته (embedded) یا اینترنت اشیاء (Internet of Things)، تشخیص قابل اعتماد خطا نسبت به محیط‌های عمومی بسیار پیچیده‌تر است؛ زیرا این اهداف اغلب به‌ گونه‌ای کرش نمی‌کنند که قابل مشاهده باشد و در بسیاری از موارد نیز فاقد سیستم‌عاملی هستند که بتواند سیگنال‌های خطا را تولید کند [33, 81]. در صورت وقوع خطا، سیستم معمولاً بدون ارائه نشانه مشخصی خاموش می‌ماند یا با انجام یک بازنشانی (reset) به ‌صورت خودکار بازیابی می‌شود.

به منظور افزایش قابلیت مشاهده‌پذیری (observability)، یک روش رایج این است که میان‌افزار (firmware)، باز‌میزبانی (rehost) گردد و از اوراکل‌های سمت شبیه‌ساز (emulator-side oracles) استفاده شود [37, 104]. همچنین در فازینگِ مستقیمِ دستگاه، می‌توان از رابط‌های اشکال‌زدایی (debug interface) سخت‌افزاری استفاده کرد تا رویه‌های مدیریت خطا (fault handlers) رهگیری شوند، وقوع بازنشانی (reset) یا پیام‌های آغاز راه‌اندازی (boot banners) شناسایی گردد و مواردی که سیستم دیگر پیشروی اجرایی (عدم پیشرفت رو به جلو هنگام فازینگ) ندارد نیز تشخیص داده شوند [33].

فراتر از بررسی‌های صرفاً مبتنی بر کرش و ابزارهای سنی‌تایزر کننده (sanitization)، برخی پژوهش‌ها از اثرات بصری یا رابط کاربری (UI) به ‌عنوان اوراکل خطا استفاده کرده‌اند. به عنوان مثال، تعدادی از مطالعات از رابط کاربری اپلیکیشن‌های موبایل بهره می‌گیرند تا از طریق مقایسه سلسله‌ مراتب نماها (view hierarchy) و تصاویر صفحه (screenshots)، ناسازگاری‌ها و خطاهای رابط گرافیکی را شناسایی کنند [36]. رویکردهای مرتبط، این ایده را با به‌کارگیری آزمون تفاضلی (differential testing) یا آزمون دگرریختی (metamorphic testing) بر خروجی‌های بصری گسترش داده‌اند؛ روشی که امکان شناسایی نقص‌های عملکردی و خطاهای رندرینگ (rendering defects) را حتی در شرایطی که برنامه کرش نمی‌کند، فراهم می‌سازد [5].

۲.۲ فازینگ دستگاه‌های نهفته (Fuzzing Embedded Devices)

دستگاه‌های نهفته (embedded devices) امروزه در جنبه‌های مختلف زندگی روزمره حضور دارند. این سامانه‌های محاسباتی تخصصی می‌توانند از حسگرهای ساده دما تا ربات‌های صنعتی پیچیده را شامل شوند که چندین رابط سخت‌افزاری و نرم‌افزاری را با یکدیگر یکپارچه می‌کنند. به‌طور کلی، دستگاه‌های نهفته را می‌توان به دو دسته اصلی تقسیم کرد:

سامانه‌های یکپارچه (monolithic systems): سامانه‌هایی که فاقد لایه انتزاعی سیستم‌عامل هستند و مستقیماً میان‌افزار را اجرا می‌کنند (مستقیماً روی سخت‌افزار و بدون واسطه سیستم‌عامل اجرا می‌شوند).
سامانه‌های مبتنی بر سیستم‌ عامل نهفته (embedded OS-based systems): سامانه‌هایی که از سیستم‌عامل‌های سبک و یا حتی سیستم‌عامل‌های عمومی استفاده می‌کنند.

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

روش‌های متداول در این حوزه شامل (۱) میزبانی مجدد (rehosting) [104, 105] است که در آن میان‌افزار (firmware) با استفاده از ابزارهایی مانند QEMU یا Unicorn شبیه‌سازی شده و در یک محیط کنترل‌ شده و مقیاس‌پذیر تحت فازینگ قرار می‌گیرد [104, 105]؛ (۲) فازینگ روی دستگاه (on-device fuzzing) که در آن ورودی‌ها مستقیماً به دستگاه در حال اجرا تزریق می‌شوند؛ و (۳) فازینگ مبتنی بر سخت‌افزار-در-حلقه (Hardware-in-the-Loop / HIL) [22, 33] است که در آن سخت‌افزار واقعی با یک چارچوب فازینگ ترکیب می‌شود تا آزمون در شرایطی نزدیک به محیط عملیاتی واقعی انجام گیرد [22, 33].

هر یک از این رویکردها با مجموعه‌ای از تعادل‌ها (موازنه‌های فنی – trade-offs) همراه می‌باشند. همان‌طور که Muench و همکاران [81] نشان می‌دهند، در روش‌های مبتنی بر سخت‌افزار، تشخیص خطا پیچیده‌تر می‌شود. مشاهده کرش‌ها یا رفتارهای غیرعادی در محیط‌های شبیه‌سازی‌ شده نسبتاً ساده است، اما در تنظیمات سخت‌افزار در حلقه (HIL) به‌ مراتب دشوارتر می‌شود، زیرا این محیط‌ها اغلب فاقد قابلیت درون‌نگری (introspection) هستند.

همچنین، کارایی (Performance) و مقیاس‌پذیری (scalability)، ارتباط مستقیمی با راهبرد فازینگ دارند؛ میزبانی مجدد (rehosting) امکان موازی‌سازی و خودکارسازی در مقیاس بالا را فراهم می‌کند [104]، در حالی که روش‌های سخت‌افزار در حلقه به‌طور ذاتی به تعداد دستگاه‌های فیزیکی موجود و میزان پاسخ‌گویی آن‌ها محدود هستند [22].

در نهایت، ابزارگذاری (instrumentation) که برای پایش پوشش و هدایت تولید ورودی ضروری است، به دسترسی به کد منبع وابسته است. اگر کد منبع در دسترس باشد، می‌توان از ابزارگذاری در زمان کامپایل استفاده کرد؛ در غیر این صورت، در مورد میان‌افزارهای صرفاً باینری باید از روش‌های جایگزینی مانند بازنویسی باینری (binary rewriting) [83] یا ابزارگذاری پویای باینری (dynamic binary instrumentation) [12] بهره گرفت تا فازینگ به‌صورت مؤثر امکان‌پذیر شود.

در نهایت، ابزارگذاری (instrumentation) که نقش اساسی در پایش پوشش و هدایت فرایند تولید ورودی دارد به میزان دسترسی به کد منبع وابسته است. چنانچه کد منبع در دسترس باشد، می‌توان از ابزارگذاری در زمان کامپایل (compile-time instrumentation) استفاده کرد؛ اما در مورد میان‌افزارهایی که تنها نسخه باینری آن‌ها در دسترس است، برای ایجاد یک فازینگ مؤثر می‌بایست از روش‌های جایگزین مانند بازنویسی باینری (binary rewriting) [83] یا ابزارگذاری باینری پویا (dynamic binary instrumentation) [12] بهره‌مند شد.

سیستم‌عامل‌های نهفته (Embedded Operating Systems). سیستم‌عامل‌های نهفته اغلب از سیستم‌عامل‌های عمومی (general-purpose) مشتق می‌شوند که برای پاسخ‌گویی به محدودیت‌های محیط‌های نهفته بازطراحی شده و ارتقاء یافته‌اند. این سازگاری‌ها معمولاً بر حداقل‌گرایی (minimalism) تمرکز دارند و از مؤلفه‌هایی مانند هسته لینوکس (Linux kernel) در کنار محیط‌های کاربری سبک‌ مانند BusyBox [18] و uClibc [123] استفاده می‌کنند. هسته لینوکس نیز از قابلیت‌های بلادرنگ (real-time) پشتیبانی می‌کند که آن را برای کاربردهای نهفته حساس به زمان مناسب می‌سازد. پردازنده‌های مبتنی بر معماری ARM نیز به ‌طور گسترده در این سامانه‌ها به کار می‌روند؛ زیرا هزینه پایین، مصرف انرژی کمتر و تولید حرارت محدود آن‌ها با نیازمندی‌های سامانه‌های نهفته سازگاری بالایی دارد.

از جمله توزیع‌های محبوب مبتنی بر لینوکس که برای سامانه‌های نهفته طراحی شده‌اند می‌توان به OpenWrt [93] اشاره کرد که به‌طور گسترده در تجهیزات شبکه مورد استفاده قرار می‌گیرد، و همچنین Buildroot که به‌ عنوان یک زنجیره ابزار(toolchain) برای ایجاد سامانه‌های لینوکسی نهفته (embedded Linux systems) سفارشی به کار می‌رود.

این سیستم‌عامل‌ها همچنین می‌توانند به‌عنوان لایه هماهنگ‌ساز (orchestration layer) برای چندین مؤلفه میان‌افزار بدون سیستم‌عامل (bare-metal firmware) عمل کنند و امکان یکپارچه‌سازی سامانه‌های پیچیده را فراهم سازند.

اندروید (Android) نیز که همراه با یک هسته مبتنی بر لینوکس (Linux) ارائه می‌شود، نقش مهمی در حوزه سامانه‌های نهفته (mbedded systems) ایفا می‌کند، به‌ ویژه در دستگاه‌های لمسی مانند تلفن‌های هوشمند، تبلت‌ها و دستگاه‌های پوشیدنی. ماهیت متن‌باز و قابلیت سفارشی‌سازی بالای آن موجب شده است که کاربرد آن فراتر از محاسبات موبایلی گسترش یافته و در طیف گسترده‌ای از تجهیزات الکترونیکی نهفته، از جمله سیستم‌های اطلاعات-سرگرمی (infotainment systems)، تلویزیون‌های هوشمند (smart TV) و هاب‌های اینترنت اشیا (IoT hubs) نیز مورد استفاده قرار گیرد.

۲.۳ پهپادهای مصرفی (Consumer Drones)

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

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

امروزه پهپادهای مدرن کاربردهای متنوعی دارند؛ از فیلم‌سازی حرفه‌ای و عکاسی تفننی گرفته تا کاربردهای تجاری مانند نقشه‌برداری جغرافیایی [34]، نمایش‌های نوری پهپادی (drone light shows) [114]، مأموریت‌های ایمنی عمومی و امداد و نجات با استفاده از دوربین‌های حرارتی [35]، و همچنین نظارت پلیسی یا تعقیب مظنونان. علاوه بر این، شرکت‌هایی مانند Amazon و DHL در حال برنامه‌ریزی برای استقرار ناوگان‌های تحویل مبتنی بر پهپاد در حوزه لجستیک بسته‌ها در آینده نزدیک هستند [27].

با این حال، دسترسی آسان و قیمت نسبتاً پایین این دستگاه‌ها، امکان سوءاستفاده از آن‌ها را برای فعالیت‌های غیرقانونی نیز فراهم کرده است. پهپادهای مصرفی برای نظارت غیرمجاز بر املاک خصوصی، تعقیب افراد، و ورود به حریم‌های هوایی ممنوع مانند فرودگاه‌ها، تأسیسات دولتی و زندان‌ها مورد استفاده قرار گرفته‌اند. همچنین موارد متعددی از قاچاق اقلام ممنوعه به داخل زندان‌ها با استفاده از پهپادها گزارش شده است [86, 102].

مشاهده پهپادها در اطراف فرودگاه‌ها در برخی موارد منجر به توقف موقت پروازها شده و در نتیجه، خسارات اقتصادی قابل توجهی برای بهره‌برداران فرودگاه و تأخیرهای گسترده برای شرکت‌های هواپیمایی و مسافران به همراه داشته است [10, 132].

فراتر از حوزه‌های غیرنظامی و تجاری، پهپادهای ارزان‌قیمت و در عین حال توانمند، در بحران‌های انسانی و همچنین درگیری‌های مسلحانه نیز مورد استفاده قرار گرفته‌اند. به‌ دلیل هزینه پایین، برد عملیاتی بالا (که در برخی موارد تا حدود ۱۵ کیلومتر می‌رسد) و قابلیت تصویربرداری با کیفیت بالا، پهپادهای مصرفی به‌طور فزاینده‌ای برای شناسایی و حتی به‌ عنوان سکوی پروازی غیررسمی برای حمل مواد منفجره به کار گرفته می‌شوند. نمونه‌هایی از این کاربرد شامل استفاده گسترده از پهپادها در جریان تهاجم روسیه به اوکراین [17, 56, 66, 113] و همچنین استفاده آن‌ها توسط گروه‌های تروریستی مانند داعش در سوریه و عراق است [88, 94].

با این حال، این پهپادهای آماده (off-the-shelf) به‌ ندرت الزامات سطح نظامی را برآورده می‌کنند و معمولاً فاقد رمزنگاری ارتباطی مقاوم و تاب‌آوری در برابر اخلال (jamming) یا شنود سیگنال هستند. با توجه به دسترسی گسترده و افزایش پتانسیل تهدید آن‌ها، کاهش سوءاستفاده از پهپادها یک دغدغه جدی ایمنی محسوب می‌شود. به منظور مقابله با این مسئله، تولیدکنندگان مجموعه‌ای از تدابیر کنترلی را معرفی کرده‌اند؛ از جمله حصار جغرافیایی (geofencing)، مناطق پرواز ممنوع (no-fly zones)، ردیابی دستگاه (device tracking)، محدودیت‌های ارتفاع و برد پرواز (altitude and range restrictions)، و همچنین ویژگی‌های ایمنی مبتنی بر سخت‌افزار مانند ماژول‌های گیرنده ADS-B که برای شناسایی هواگردهای نزدیک به کار می‌روند [32].

علاوه بر این، تولیدکنندگان پهپاد معمولاً دستگاه‌ها را به‌صورت بسته (locked-down) ارائه می‌دهند و دسترسی کاربران نهایی برای تغییر یا تحلیل میان‌افزار (firmware) را محدود می‌سازند. این رویکرد ‌منبع بسته (closed-source) به گونه‌ای طراحی شده است که خطر دستکاری را به حداقل برساند و انطباق با سیاست‌های ایمنی را تضمین کند. با این حال، این تدابیر نرم‌افزاری و سخت‌افزاری باید به ‌صورت دقیق طراحی و به‌طور امن پیاده‌سازی شوند تا از غیرفعال‌سازی یا دور زدن آن‌ها توسط مهاجمان جلوگیری شود. در صورت نبود حفاظت‌های قوی و به‌روزرسانی‌های منظم، مهاجمان ممکن است بتوانند این مکانیزم‌ها را شکسته و بدین ترتیب، امنیت عمومی و حریم هوایی را تضعیف کنند.

۲.۳.۱ پهپادها – سیستم‌های پیچیده سایبری-فیزیکی (Drones – Complex Cyber-Physical Systems)

در طول چند سال گذشته، پهپادهای مصرفی از اسباب‌بازی‌های ساده به سیستم‌های سایبری-فیزیکی بسیار پیچیده‌ای مجهز به رابط‌های بی‌سیم متنوع و طیف وسیعی از حسگرها، از جمله مادون قرمز (infrared)، اولتراسونیک (ultrasonic)، GPS، تصویربرداری حرارتی (thermal imaging)، واحدهای اندازه‌گیری اینرسی (IMU – inertial measurement units) و دوربین‌هایی برای تشخیص مانع و جلوگیری از برخورد، تکامل یافته‌اند. این پیچیدگی فزاینده، سطح حمله را گسترش می‌دهد و تلاش‌ها برای ایمن‌سازی کامل این دستگاه‌ها را پیچیده می‌کند. بردارهای حمله بالقوه، لایه سخت‌افزار (به عنوان مثال اصلاح سخت‌افزار یا مهندسی معکوس)، لایه نرم‌افزار (مانند معکوس کردن میان‌افزار، تحلیل ایستا و پویا) و لایه بی‌سیم/فیزیکی (مانند استراق سمع، پارازیت یا جعل لینک‌های رادیویی) را در بر می‌گیرد.

حتی یک معماری حداقلی از پهپاد نیز شامل چندین مؤلفه حیاتی است. یک پهپاد ساده معمولاً از یک باتری برای تأمین انرژی، یک میکروکنترلر کنترل کننده پرواز (flight controller MCU) که سیگنال‌های کنترلی دریافتی از طریق امواج رادیویی از کنترل از راه دور خلبان را پردازش می‌کند، و کنترل‌کننده‌های سرعت الکترونیکی (ESCs) که موتورها را برای هدایت پهپاد به حرکت درمی‌آورند، تشکیل شده است.

این مدل ساده به‌خودیِ خود نیز خطرات متعددی را آشکار می‌کند. برای مثال، یک مهاجم می‌تواند با دستکاری یا جایگزینی مؤلفه‌های سخت‌افزاری، کنترل غیرمجاز دستگاه را به دست آورد و یا ارتباطات بی‌سیم را رهگیری کند. شنود (eavesdropping) لینک کنترل رادیویی می‌تواند به مهاجم امکان دهد مسیر پرواز پهپاد را ردیابی کند، در حالی که ایجاد اختلال (jamming) یا بازپخش سیگنال‌ها (replay attacks) می‌تواند موجب محروم‌سازی از سرویس (denial-of-service) یا حتی ربودن کنترل پهپاد از طریق غلبه بر سیگنال خلبان قانونی شود.

پهپادهای پیشرفته‌تر با افزودن ماژول‌های پیچیده‌تر، این ساختار را بیش از پیش گسترش می‌دهند؛ از جمله ماژول‌های downlink برای ارسال داده‌های تله‌متری و جریان‌های ویدئویی، حسگرهای پیشرفته برای پرواز خودکار، و پردازنده‌های داخلی به منظور پیاده‌سازی قابلیت‌های مبتنی بر بینایی ماشین. تمامی این مؤلفه‌ها به‌طور هم‌زمان سطح حمله را افزایش داده و آسیب‌پذیری‌های جدیدی را ایجاد می‌کنند [85, 91, 116]. در ادامه، لایه‌های مختلف این سامانه‌ها (لایه سخت‌افزار، نرم‌افزار، و لایه بی‌سیم/فیزیکی) با جزئیات بیشتری بررسی می‌شوند.

۲.۳.۲.۱ لایه سخت‌افزار (Hardware Layer)

پهپادها دستگاه‌های سایبری-فیزیکی هستند که از معماری‌های ساده‌ای که در بخش قبل توضیح داده شد تا سیستم‌های بسیار پیچیده‌ای که شامل چندین حسگر، تراشه‌های مجتمع روی یک چیپ (SoC) و پروتکل‌های ارتباطی گوناگون می‌باشند، متغیر هستند. پهپادهای مصرفی مدرن معمولاً ازSoCهای اختصاصی برای کنترل پرواز، اجتناب از موانع و همچنین فرستنده/گیرنده‌هایی برای مدولاسیون (modulating – تبدیل داده‌های دیجیتال به سیگنال رادیویی قابل ارسال از طریق هوا) و دمدولاسیون (demodulating – تبدیل سیگنال رادیویی دریافتی دوباره به داده قابل فهم برای سیستم) سیگنال‌های رادیویی بهره می‌برند.

علاوه بر این، این دستگاه‌ها معمولاً به یک دوربین با وضوح بالا برای ثبت تصاویر و ویدئو مجهز هستند که می‌تواند به ‌صورت زنده نیز تصویر را به کنترل‌کنندهٔ از راه دور ارسال کند. فراتر از این اجزای اصلی، پهپادها از چندین واحد میکروکنترلر (MCU) برای انجام وظایف تخصصی مانند کنترل پایداری دوربین از طریق گیمبال (gimbal) یا مدیریت ارتباطات Wi-Fi و Bluetooth استفاده می‌کنند.

این اجزای ناهمگن (heterogeneous) از طریق پروتکل‌های سخت‌افزاری مختلف مانند UART، USB یا I2C با یکدیگر ارتباط برقرار می‌کنند و در مجموع یک معماری سخت‌افزاری کاملاً یکپارچه (tightly integrated) را تشکیل می‌دهند. شکل ۲.۱ اجزای سخت‌افزاری متداول یک پهپاد تجاری را با استفاده از مدل DJI Mini 2 نشان می‌دهد؛ این مدل یکی از محصولات شرکت DJI است که به‌ عنوان یکی از پیشگامان بازار پهپادهای مصرفی شناخته می‌شود.

کنترل‌کننده پرواز (Flight Controller). کنترل‌کننده پرواز وظیفه دارد فرمان‌های ارسال ‌شده از کنترل از راه دور (remote control) خلبان را تفسیر کرده و آن‌ها را به خروجی‌های دقیق برای موتورها تبدیل کند تا حرکت پهپاد به ‌درستی کنترل شود. این سیستم، داده‌ها را از طیف وسیعی از حسگرهای داخلی، از جمله واحد اندازه‌گیری اینرسی (IMU)، قطب‌نما، گیرنده GPS و سیستم موقعیت‌یابی بصری (VPS) ترکیب و یکپارچه می‌کند تا پایداری پرواز، ناوبری دقیق و اصلاح اختلالات را حفظ کند. با توجه به نقش مرکزی آن در پردازش ورودی‌های حسگری و هماهنگ‌سازی خروجی‌های موتورها، کنترل‌کننده پرواز، حیاتی‌ترین مؤلفه پهپاد محسوب می‌شود.

علاوه بر این، در صورتی که پهپاد از قابلیت‌هایی مانند حصار جغرافیایی (geofencing) یا محدودیت‌های مناطق پرواز ممنوع (No-Fly Zone) پشتیبانی کند، کنترل‌کننده پرواز باید به‌صورت مداوم موقعیت مکانی خود را با این پایگاه‌های داده مقایسه کرده و از ورود غیرمجاز به حریم هوایی ممنوع جلوگیری کند. برای تضمین رفتار سریع و قطعی (deterministic) در شرایط پویای پرواز، کنترل‌کننده پرواز معمولاً بر روی یک میکروکنترلر اختصاصی (MCU) با قابلیت‌های بلادرنگ (real-time) و تأخیر کم پیاده‌سازی می‌شود.

SoC رمزگذاری ویدئو و جلوگیری از برخورد (Video Encoding & Collision Avoidance SoC). پهپادهای مدرن برای جلوگیری از برخورد با موانع اطراف مانند درختان، ساختمان‌ها و سطح زمین از مجموعه‌ای از مکانیزم‌های ایمنی استفاده می‌کنند. این مکانیزم‌ها معمولاً شامل حسگرهای اولتراسونیک (ultrasonic sensors) برای اندازه‌گیری فاصله عمودی (مثلاً برای تشخیص نزدیکی به زمین) و همچنین چندین دوربین نصب ‌شده در بخش‌های جلو، طرفین و عقب پهپاد هستند که برای تشخیص موانع در سطح پرواز به کار می‌روند.

این دوربین‌ها از تکنیک‌های بینایی ماشین (computer vision) برای شناسایی و تخمین فاصله اشیای اطراف استفاده می‌کنند و امکان اجتناب از برخوردهای بلادرنگ (real-time collision) را فراهم می‌سازند. به‌ طور هم‌زمان، دوربین اصلی پهپاد وظیفه ثبت ویدئو با وضوح بالا را بر عهده دارد که به ‌صورت پیوسته رمزگذاری شده و به‌عنوان جریان زنده (live stream) به کنترل‌کننده از راه دور ارسال می‌شود. بار محاسباتی این وظایف مستلزم یک SoC اختصاصی با پردازنده چند‌هسته‌ای، حافظه کافی و یک پردازشگر تخصصی سیگنال تصویر (ISP) است تا بتواند پردازش بلادرنگ ویدئو و تشخیص اشیا را به‌ صورت کارآمد انجام دهد. علاوه بر این وظایف اصلی، SoC اغلب نقش یک هماهنگ‌کننده مرکزی را نیز ایفا می‌کند و زیرسامانه‌های مختلف را مدیریت می‌نماید. به عنوان مثال، ممکن است پیام‌های سیستمی و گزارش‌های وضعیت سایر مؤلفه‌ها (components) را جمع‌آوری و ثبت کند تا امکان عیب‌یابی یا پایش عملکرد فراهم شود.

فرستنده-گیرنده (Transceiver). فرستنده-گیرنده یک سیستم روی چیپ (SoC) است که وظیفه انجام هر دو عملیات مدولاسیون (modulation) و دمدولاسیون (demodulation) سیگنال‌های رادیویی را بر عهده دارد و امکان ارسال و دریافت داده را در لایه فیزیکی بی‌سیم فراهم می‌کند. این واحد با آنتن‌های پهپاد در ارتباط است و سیگنال‌های دیجیتال را برای ارسال به امواج رادیویی تبدیل می‌کند و بالعکس، سیگنال‌های دریافتی رادیویی را دوباره به داده‌های دیجیتال قابل پردازش تبدیل می‌نماید.

فرستنده-گیرنده‌ها جزء جدایی‌ناپذیر تمامی ارتباطات بی‌سیم هستند و تقریباً در تمام دستگاه‌های مدرن مبتنی بر ارتباط رادیویی، از جمله تلفن‌های هوشمند، رایانه‌ها و دستگاه‌های اینترنت اشیاء (IoT) تعبیه شده‌اند. فرستنده-گیرنده در پهپادها، نقش حیاتی در حفظ یک لینک پایدار به منظور کنترل پرواز و همچنین انتقال جریان ویدئویی بین پهپاد و کنترل‌کننده از راه دور ایفا می‌کند.

کنترل از راه دور (Remote Control). پهپادها معمولاً از طریق یک کنترل‌کننده اختصاصی یا یک رابط مبتنی بر جوی‌استیک (joystick) هدایت می‌شوند که با استفاده از فرکانس رادیویی و یک پروتکل بی‌سیم اختصاصی با پهپاد ارتباط برقرار می‌کند. علاوه بر این روش استاندارد، برخی از پهپادهای مصرفی از کنترل از طریق Wi-Fi یا Bluetooth نیز پشتیبانی می‌کنند؛ با این حال، این روش‌های جایگزین معمولاً منجر به کاهش قابل توجه برد کنترل و کاهش قابلیت اطمینان می‌شوند. در پهپادهایی که از ارسال زنده تصویر (live video feed) از دوربین داخلی پشتیبانی می‌کنند، کنترل‌کننده از راه دور یا دارای نمایشگر داخلی است یا امکان اتصال یک تلفن هوشمند برای مشاهده جریان ویدئویی را فراهم می‌سازد. خود کنترل‌کننده نیز مجهز به یک فرستنده-گیرنده (transceiver) است که از نظر عملکرد و طراحی سخت‌افزاری مشابه نمونه نصب‌ شده روی پهپاد می‌باشد. این واحد وظیفه ارسال دستورات کنترلی و دریافت داده‌های تله‌متری و همچنین جریان ویدئویی زنده را از طریق یک کانال downlink اختصاصی بر عهده دارد.

۲.۳.۲.۲ لایه نرم‌افزار (Software Layer)

با توجه به تنوع و پیچیدگی اجزای سخت‌افزاری در پهپاد، معماری نرم‌افزاری آن از چندین لایه میان‌افزار (firmware) و سیستم‌عامل تشکیل شده است که هر یک برای وظایف متفاوتی طراحی شده‌اند. برای مؤلفه‌های حساس به زمان مانند کنترل‌کننده پرواز (flight controller) یا فرستنده-گیرنده (transceiver)، معمولاً از سیستم‌عامل‌های بلادرنگ (real-time operating systems) مانند ThreadX یا حتی میان‌افزارهای کاملاً سفارشی و بدون سیستم‌عامل (bare-metal) استفاده می‌شود تا رفتار قطعی (deterministic) و پاسخ‌دهی با تأخیر بسیار کم تضمین شود. در مقابل، برای مؤلفه‌هایی که حساسیت زمانی کمتری دارند مانند رمزگذاری ویدئو، پایش سیستم، انتقال فایل‌ها (برای مثال تصاویر و ویدئوهای ضبط‌شده)، و وظایف مدیریتی نظیر به‌روزرسانی میان‌افزار معمولاً از سیستم‌عامل‌های عمومی مانند لینوکس (Linux) یا اندروید (Android) استفاده می‌شود.

علاوه بر این لایه‌های نرم‌افزاری در سطح سیستم، پهپادها از ترکیبی از پروتکل‌های ارتباطی اختصاصی (proprietary) و متن‌باز به منظور تسهیل تعامل میان زیرسامانه‌ها استفاده می‌کنند. در بخش کاربرمحور، اپلیکیشن‌های همراه موبایل (companion apps) امکاناتی مانند پخش زنده ویدئو، مدیریت رسانه‌ها، پایش داده‌های تله‌متری، و به‌روزرسانی میان‌افزار (firmware) از راه دور (over-the-air) برای اجزای مختلف پهپاد را فراهم می‌کنند.

۲.۳.۲.۳ لایه فیزیکی بی‌سیم (Wireless Physical Layer)

لایه فیزیکی (physical layer) مشخص می‌کند که دستگاه‌ها چگونه از طریق یک بستر انتقال (transmission medium) به‌ صورت فیزیکی به یکدیگر متصل می‌شوند و دادهٔ خام چگونه در این بستر منتقل می‌گردد. این بستر انتقال در ارتباطات بی‌سیم، هوا است و جریان بیت‌ها (bitstream) بر روی امواج رادیویی تنظیم می‌شود (modulated) تا امکان ارتباط از راه دور (over-the-air) فراهم گردد. این نوع انتقال بی‌سیم امروزه بسیار رایج است و به ‌طور گسترده در فناوری‌هایی مانند Wi-Fi و Bluetooth مشاهده می‌شود. لایه فیزیکی بی‌سیم در زمینه پهپادها، به پیوند (لینک) ارتباطی میان پهپاد و کنترل‌کننده از راه دور اشاره دارد.

این لینک برای انتقال دستورات کنترلی (uplink) و دریافت داده‌های تله‌متری و جریان‌های ویدئویی زنده (downlink) ضروری است. برای پشتیبانی از ارتباط دوسویه، پهپادها از باندهای فرکانسی مختلفی استفاده می‌کنند، از جمله باندهای ISM مانند ۴۰ و ۴۳۳ مگاهرتز و همچنین باندهای پرکاربردتر ۲٫۴ گیگاهرتز و ۵ گیگاهرتز که در شبکه‌های Wi-Fi نیز مورد استفاده قرار می‌گیرند.

فرستنده-گیرنده (transceiver) وظیفه دارد داده‌های دیجیتال را با استفاده از یک پروتکل ارتباط بی‌سیم مشخص بر روی این باندهای فرکانسی تنظیم (modulated) کرده و سیگنال‌های دریافتی را نیز دمدولاسیون (demodulating) کند. این پروتکل‌ها می‌توانند از پیاده‌سازی‌های سبک و اختصاصی تا استانداردهای پیچیده‌تری مانند Wi-Fi یا LTE متغیر باشند که برای پشتیبانی از پهنای باند بالاتر جهت انتقال ویدئو و داده‌های تله‌متری به کار می‌روند.

۲.۳.۲ رهبر بازار پهپادها: DJI(Drone Marked Leader: DJI)

DJI رهبر بازار در صنعت پهپادهای مصرفی است [112, 115] و پهپادهایی را ارائه می‌دهد که مجهز به دوربین‌هایی با وضوح بالا، مجموعه‌ای از قابلیت‌های ایمنی و امنیتی، و یک بسته نرم‌افزاری جامع برای کنترل و خودکارسازی هستند. سبد محصولات DJI طیفی گسترده را پوشش می‌دهد؛ از پهپادهای تفننی (hobbyist) برای عکاسی هوایی گرفته تا مدل‌های حرفه‌ای برای فیلم‌سازان، و همچنین راهکارهای سازمانی (enterprise-grade) که برای کاربردهایی مانند کشاورزی، ایمنی عمومی و امداد و نجات، نقشه‌برداری زمینی و تحویل کالا طراحی شده‌اند [34, 35]. علاوه بر خط تولید پهپادها، DJI سامانه‌ای با نام Aeroscope را نیز توسعه داد که برای استفاده توسط نهادهای عمومی و بهره‌برداران زیرساخت‌های حیاتی مانند فرودگاه‌ها عرضه شده بود [29]. این سامانه برای شناسایی و رهگیری پهپادهای DJI و اپراتورهای آن‌ها طراحی شده بود و قادر بود پهپادها را تا فاصله حدود ۵۰ کیلومتری شناسایی و ردیابی کند.

پروتکل ارتباطی داخلی: DUML (Internal Communication Protocol: DUML). پهپادهای DJI از یک پروتکل ارتباطی اختصاصی با نام زبان نشانه‌گذاری جهانی DJI (DUML – DJI Universal Markup Language) استفاده می‌کنند [31]. این پروتکل برای برقراری ارتباط هم بین اجزای داخلی پهپاد و هم بین پهپاد و سیستم‌های خارجی، مانند یک رایانه متصل، به کار می‌رود. DUML امکان هدف‌گیری دقیق دستورات را فراهم می‌کند؛ به این صورت که می‌توان هم فرستنده و هم گیرنده موردنظر را در میان زیرسامانه‌های پهپاد مشخص کرد. این ویژگی موجب می‌شود هر فرمان به مؤلفه صحیح هدایت شده و پاسخ‌ها نیز به منبع مربوطه قابل انتساب باشند. با این حال، مشخصات رسمی قالب بسته‌های DUML و دستورات مرتبط با آن توسط DJI به ‌صورت عمومی منتشر نشده است. در نتیجه، بخش عمده‌ای از درک موجود درباره DUML از طریق مهندسی معکوس میان‌افزار (firmware reverse engineering) و تلاش‌های جمعی در جامعه پژوهشگران و توسعه‌دهندگان حوزه مهندسی معکوس DJI به دست آمده است [77]. DUML به دو نوع اصلی تقسیم می‌شود: V1 که برای ارتباطات خارجی به کار می‌رود (به عنوان مثال بین پهپاد و یک رایانه متصل) و Logic که ارتباطات داخلی میان زیرسامانه‌های نهفته را کنترل می‌کند.

پروتکل ارتباطی بی‌سیم: OcuSync. پهپادهای DJI از یک پروتکل ارتباطی اختصاصی به نام OcuSync برای برقراری ارتباط میان پهپاد و کنترل کننده آن از راه دور استفاده می‌کنند. OcuSync به‌ طور ویژه برای ایجاد لینک‌هایی با پهنای باند بالا و تأخیر پایین طراحی شده است که برای پخش ویدئو بلادرنگ و کنترل از راه دور در بردهایی تا ۳۰ کیلومتر تحت شرایط ایده‌آل مناسب می‌باشند [30]. این پروتکل در باندهای فرکانسی 2.4 گیگاهرتز و 5 گیگاهرتز ISM عمل می‌کند و از تکنیک‌های پیشرفته مدولاسیون (modulation) و انتقال (transmission) الهام‌گرفته از استانداردهای سلولی مانند LTE بهره می‌برد. این تکنیک‌ها شامل مدولاسیون تقسیم فرکانسی عمود برهم (OFDM – Orthogonal Frequency Division Multiplexing) برای استفاده کارآمد از طیف فرکانسی و نیز طیف گسترده با پرش فرکانسی (FHSS) برای کاهش تداخل و افزایش پایداری اتصال در محیط‌های پرتراکم و دارای تداخل بالا هستند [25].

۳. چالش‌های حوزه فازینگ (Challenges in the Field of Fuzzing)

فازینگ (Fuzzing) در سال‌های اخیر، به یکی از حوزه‌های محوری پژوهش در زمینه کشف آسیب‌پذیری در امنیت سامانه‌های نرم‌افزاری، هم در محیط‌های دانشگاهی و هم در صنعت، تبدیل شده است. شرکت‌های پیشرو فناوری، از جمله Google، Meta و Apple، منابع محاسباتی قابل‌توجهی را به آزمون و ارزیابی نرم‌افزارهای خود با هدف شناسایی آسیب‌پذیری‌ها اختصاص می‌دهند. برای نمونه، شرکت Google علاوه بر به‌کارگیری فازینگ در فرآیندهای داخلی خود، یک زیرساخت فازینگ در مقیاس بزرگ برای نرم‌افزارهای متن‌باز با نام OSS-Fuzz را نیز راه‌اندازی کرده است. این زیرساخت تاکنون موفق به شناسایی بیش از ۱۳٬۰۰۰ آسیب‌پذیری و ۵۰٬۰۰۰ باگ در بیش از ۱٬۰۰۰ پروژه متن‌باز (open-source projects) شده است [50].

جامعه دانشگاهی نیز سهم قابل‌توجهی در توسعه این حوزه داشته و تعداد مقالات پژوهشی در این زمینه به‌صورت مستمر در حال افزایش است. پژوهش‌های موفق یا با معرفی روش‌های نوآورانه برای فازینگِ نرم‌افزارهایی که پیش‌تر کمتر مورد بررسی قرار گرفته‌اند [14, 22, 109] انجام می‌شوند، یا با بهبود فرآیند فازینگ در اهدافی که به ‌خوبی مطالعه شده‌اند [7, 60]، زمینه کشف آسیب‌پذیری‌های جدید و عمیق را در نرم‌افزارهای به‌طور گسترده استقرار یافته فراهم می‌کنند. تولیدکنندگان نرم‌افزارهای پرکاربرد، مانند nginx و Google Chrome نیز معمولاً از طریق برنامه‌های جایزه‌ی کشف آسیب‌پذیری (bug bounty programs)، پژوهشگرانی را که آسیب‌پذیری‌های جدید را شناسایی و گزارش می‌کنند، مورد حمایت و تشویق قرار می‌دهند. فازرهای جامعه‌محور نظیر AFL++ [41] با هدف ایجاد پیوند میان دستاوردهای پژوهشی و کاربردهای عملی توسعه یافته‌اند و می‌کوشند تکنیک‌های دانشگاهی اثبات‌ شده را در سناریوهای واقعی و عملیاتی ادغام و یکپارچه‌سازی کنند.

با وجود این پیشرفت‌ها، حوزه فازینگ همچنان با چالش‌های اساسی و قابل‌توجهی روبه‌رو است. در بخش‌های آتی، برخی از این چالش‌ها از طریق بررسی نقاط ضعف بالقوه (pitfalls)، نواحی کور (blind spots) و همچنین محدودیت‌های عملی موجود، مورد تحلیل قرار می‌گیرند. این چالش‌ها شامل سکون و توقف در توسعه و کارایی فازرهای عمومی (general-purpose fuzzing)، نقاط کور الگوریتمی نظیر پدیده سایه‌سازی ورودی (input shadowing)، و همچنین دشواری‌های به‌کارگیری و انطباق فازینگ در سیستم‌های سایبر-فیزیکی پیچیده، به‌ویژه پهپادها است.

۳.۱ پذیرش فازینگ دانشگاهی (Adoption of Academic Fuzzing)

مقالات علمی که در کنفرانس‌ها، کارگاه‌های تخصصی یا نشریات علمی منتشر می‌شوند، صرف‌نظر از حوزه علمی موردنظر، عموماً با هدف ارائه تکنیک‌های نوین، پیشنهاد راهکار برای مسائل حل ‌نشده، یا تجمیع و نظام‌مند‌سازی دانش موجود در آن حوزه نگارش می‌شوند. پیشرفت علمی معمولاً ماهیتی تدریجی و انباشتی دارد و بر پایه دستاوردها و پژوهش‌های پیشین شکل می‌گیرد. پژوهشگران از ایده‌های پیشین الهام می‌گیرند، رویکردهای موجود را متناسب‌سازی و بهینه‌سازی می‌کنند، یا از طریق بازتولید (reproduction) و اعتبارسنجی (validation) نتایج پیشین، به ارزیابی انتقادی آن‌ها می‌پردازند [11, 89].

تکرارپذیری یا قابلیت بازتولید نتایج (Reproducibility) تحقیقات و پژوهش‌ها یکی از ارکان بنیادین پیشرفت علمی محسوب می‌شود؛ زیرا در غیاب آن، «پیشرفت‌های» گزارش ‌شده ممکن است بر فرضیات نادرست، ناقص، یا نتایجی غیرقابل بازتولید استوار باشند. افزون بر این، نظام‌مند‌سازی دانش (Systematization of Knowledge) نقش بسزایی در شناسایی نقاط ضعف و چالش‌های موجود ایفا می‌کند و پژوهشگران را در جهت اتخاذ روش‌شناسی‌های دقیق، شفاف، و قابل بازتولید هدایت می‌نماید [67, 107].

حوزه فازینگ نمونه‌ای بارز از این نوع پیشرفت تدریجی در پژوهش‌های علمی به شمار می‌رود. پژوهشگران معمولاً فازرهای پیشنهادی خود را در مقایسه با خطوط مبنای پیشرفته (state-of-the-art baselines) ارزیابی کرده و بهبودهای حاصل را بر اساس معیارهای متداولی نظیر پوشش کد (code coverage) و توانایی کشف باگ یا همان آسیب‌پذیری (bug-finding capability) گزارش می‌دهند. ++AFL نمونه‌ شاخص‌ چنین خط مبنایی است؛ زیرا با ادغام مستمر دستاوردهای پژوهشی جدید در پایگاه کد خود، همواره به‌روز باقی مانده و بستری استاندارد و قابل‌اندازه‌گیری برای ارزیابی پژوهش‌های بعدی فراهم می‌کند. نکته حائز اهمیت، آن است که توسعه ++AFL صرفاً تحت تأثیر جامعه دانشگاهی نبوده، بلکه از مشارکت‌های صنعت و متخصصان مستقل نیز بهره‌مند شده است.

این مشارکت‌ها شامل بهبودهای الگوریتمی در راهبردهای جهش (mutation strategies) و مکانیزم‌های بازخورد (feedback mechanisms) [4, 72, 96, 124, 141]، ارتقای روش‌های زمان‌بندی و انتخاب بذرهای ورودی (seed scheduling) [16, 59, 127]، افزودن پشتیبانی از اهداف اجرایی جدید (new targets) [8, 9, 99, 101, 108]، و همچنین بهبود پردازش و مدیریت ورودی‌های ساخت‌یافته (structured inputs) [2, 120, 128] می‌باشد.

در بازه زمانی ۲۰۱۸ تا ۲۰۲۳، تعداد ۶۶ مقاله علمی منتشر شده در برترین مجامع علمی حوزه امنیت و مهندسی نرم‌افزار، فازرهای پیشنهادی خود را با AFL یا نسخه تکامل‌یافته آن، ++AFL، مقایسه کرده‌اند [107]. امروزه، ++AFL به استاندارد عملی (de facto standard) در فازینگ اهداف عمومی و همه منظوره تبدیل شده است و به دلیل سابقه موفق و قابل‌اتکای آن در کشف باگ‌ها و آسیب‌پذیری‌ها، در هر دو حوزه دانشگاه و صنعت به ‌طور گسترده مورد استفاده قرار می‌گیرد [61].

علاوه بر این، در فاصله سال‌های ۲۰۱۸ تا ۲۰۲۴، حدود ۵۸ مقاله پژوهشی (معادل ۱۵٪ از مقالات حوزه فازینگ در این مجامع علمی) ابزارهای پیشنهادی خود را مستقیماً بر پایه AFL یا ++AFL توسعه داده‌اند؛ موضوعی که جایگاه محوری این چارچوب را به‌عنوان نقطه مرجع اصلی در جامعه پژوهشی فازینگ به‌ خوبی نشان می‌دهد.

در این بخش، مروری بر روند تکامل ++AFL ارائه می‌شود. به‌طور مشخص، ویژگی‌ها و قابلیت‌هایی که در طول سال‌های گذشته تأثیر قابل‌ اندازه‌گیری و معناداری بر عملکرد این فازر داشته‌اند، بررسی شده و همچنین روند پیشرفت فازینگ عمومی از زمان نخستین انتشار ++AFL در سال ۲۰۱۹ تحلیل می‌شود.

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

به‌ منظور بررسی روند تکامل فازینگ اهداف عمومی، از ++AFL به ‌عنوان یک مطالعه موردی نمونه (representative case study) استفاده می‌کنیم. در این مطالعه، معیار اصلی ارزیابی بهبود عملکرد، پوشش کد (code coverage) در نظر گرفته شده است. بدین منظور، نسخه‌های منتخب از ++AFL به همراه مجموعه‌ای از قابلیت‌های مرتبط با فازینگ اهداف عمومی و همه منظوره، بر روی ۱۵ هدف اجرایی مختلف در قالب یک مطالعه جامع مورد ارزیابی قرار گرفته‌اند.

به‌منظور جداسازی اثر ناشی از بهبودهای موتور فازینگ (fuzzing engine)، تمامی اهداف با استفاده از یک کامپایلر مدرن کامپایل شده‌اند، در حالی که نسخه‌های مختلف موتور فازینگ در طول آزمایش تغییر داده شده‌اند. این رویکرد امکان مشاهده و تحلیل بهبودهای واقعی فازر را بدون تأثیرپذیری از نویز ناشی از بهینه‌سازی‌های کامپایلر فراهم می‌سازد.

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

در نهایت، ارزیابی تجربی انجام‌ شده با مطالعه نظام‌مند پژوهش‌های حوزه فازینگ تکمیل گردید که شامل مقالات منتشر شده بین سال‌های ۲۰۱۸ تا ۲۰۲۴ در برترین مجامع علمی حوزه امنیت و مهندسی نرم‌افزار بود. از میان این مجموعه، تمامی پژوهش‌هایی که ابزارها یا روش‌های پیشنهادی خود را بر پایه AFL یا ++AFL توسعه داده‌اند، استخراج شده و امکان‌سنجی‌ یکپارچه‌سازی (integration feasibility) آن‌ها مورد تحلیل قرار گرفته است. علاوه بر این، بررسی شد که کدام‌یک از این دستاوردهای پژوهشی پیش‌تر در ++AFL ادغام و پیاده‌سازی شده‌اند. به ‌منظور تفسیر دقیق‌تر یافته‌های حاصل و ارائه تصویری جامع‌تر از وضعیت این حوزه، نتایج به‌ دست‌آمده همچنین با نگهداران و توسعه‌دهندگان اصلی ++AFL مورد بحث و ارزیابی قرار گرفت. بدین ترتیب، این مطالعه دیدگاهی جامع ارائه می‌دهد که اندازه‌گیری‌های تجربی، تحلیل نظام‌مند پژوهش‌های علمی و تجربیات عملی متخصصان را به‌صورت یکپارچه ترکیب می‌کند.

۳.۱.۱ نتایج کلیدی (Key Results)

نخستین نسخه از ++AFL در سال ۲۰۱۹ منتشر شد و با گسترش و ارتقای AFL، مجموعه‌ای از قابلیت‌های جدید به آن اضافه گردید. در بازه زمانی ۲۰۱۹ تا اواسط ۲۰۲۵، تعداد ۳۸ نسخه انتشار یافت که هر یک شامل افزودن قابلیت‌های جدید [4, 69, 74, 141]، رفع اشکالات نرم‌افزاری (bug fixes)و همچنین پشتیبانی از اهداف اجرایی و محیط‌های جدید [99, 108] بودند. در طول این سال‌ها، منابع محاسباتی بیشتری به بازارزیابی مؤلفه‌های اصلی فازر، از جمله زمان‌بندها (schedulers) [16] و راهبردهای جهش (mutation strategies)، اختصاص یافته است. این امر منجر به تغییرات مکرر در تنظیمات پیش‌فرض موتور فازینگ (default engine configuration) و به‌ روزرسانی مداوم سیاست‌های داخلی آن شده است.

به منظور بررسی این روند تکاملی شش ویژگی نمونه برای ارزیابی انتخاب شدند. این قابلیت‌ها شامل بهبودهای ابزارگذاری (instrumentation) و بازخورد (feedback) مانند CmpLog ،dict2file و CompCov و همچنین ویژگی‌های مرتبط با جهش (mutation) و زمان‌بندی (scheduling) شامل mOpt ،Fast و Explore هستند. به‌ عنوان یک مبنا (baseline)، فازر به‌گونه‌ای پیکربندی و تنظیم شد که صرفاً به مرحله غیرقطعی (Havoc) برای انجام جهش‌ها متکی باشد و جهش‌های قطعی (deterministic mutations) در آن حذف شوند؛ زیرا نتایج آزمایش‌های مقدماتی نشان داد که بسیاری از نسخه‌های منتشر شده ++AFL در این پیکربندی ،عملکرد به ‌مراتب بهتری دارند. علاوه بر این، هشت حالت مختلف ابزارگذاری ارائه ‌شده در ++AFL نیز مورد ارزیابی قرار گرفت که شامل رویکرد کلاسیک AFL، مکانیزم PCGuard در LLVM، حالت CTX و نسخه توسعه‌یافته PCGuard در ++AFL می‌باشد.

نتایج آزمایش‌های ما نشان می‌دهد که پیشرفت فازینگ از نسخه 3.0c به بعد تا حد زیادی دچار رکود (stagnation) شده است و تنها پیشرفت‌های جزئی در نسخه‌های بعدی مشاهده می‌شود؛ همان‌گونه که در شکل ۳.۱ با استفاده از SQLite3 به‌ عنوان یک هدف نماینده (representative target) نمایش داده شده است. در واقع، نسخه 3.0c در برخی موارد عملکرد بهتری نسبت به نسخه‌های جدیدتر مانند 4.21c داشته و حتی در یکی از دو هدف مورد آزمایش، طی یک کمپین بلندمدت هفت‌ روزه، از آخرین نسخه موجود یعنی 4.32c نیز پیشی گرفته است. بیشترین بهبودهای پایدار و قابل‌تکرار عمدتاً ناشی از ویژگی‌هایی نظیر CmpLog ،dict2file، CompCov و همچنین «مرحله قطعی سریع» (fast deterministic stage) [141] بوده‌اند که در تمامی اهداف و نسخه‌های مورد بررسی، منجر به افزایش‌های قابل اندازه‌گیری و تکرارپذیر در عملکرد فازینگ شده‌اند.

در مقابل، تکنیک‌هایی مانند mOpt یا راهبردهای زمان‌بند (scheduling strategies) جایگزین تنها بهبودهای جزئی یا وابسته به هدف (target-specific) ارائه داده‌اند. نکته قابل‌توجه این است که برخی از مؤثرترین بهبودها نه از دل پژوهش‌های دانشگاهی، بلکه از تغییرات ساده و جامعه‌محور (community-driven) ناشی شده‌اند؛ از جمله انتقال نمونه‌های آزمایشی از طریق حافظه مشترک (shared memory) یا یک توسعه شش‌خطی در کد برای گسترش جهش‌های مرحله غیرقطعی (havoc). به‌طور کلی، میزان بهبودها به ‌شدت وابسته به هدف است: در حالی که برخی قابلیت‌ها عملکرد مناسبی بر روی برنامه‌هایی مانند Freetype2 یا cURL نشان می‌دهند، هیچ ‌یک از نسخه‌های مورد آزمایش پیشرفت قابل توجه و معناداری بر روی OpenSSL ایجاد نکرده‌اند.

این نتایج با تعداد بالای مقالات علمی منتشر شده در سال‌های اخیر که در آن‌ها بهبودهای دورقمی نسبت به خطوط مبنای (baselines) مورد استفاده گزارش شده است در تضاد قرار دارد. از این رو، یک تحلیل نظام‌مند از پژوهش‌های صورت گرفته، انجام شد تا مشخص گردد کدام‌یک از نتایج دانشگاهی واقعاً در ++AFL ادغام شده‌اند. با اعمال فیلتر بر روی پژوهش‌هایی که بین سال‌های ۲۰۱۸ تا ۲۰۲۴ بر روی AFL یا ++AFL توسعه یافته و تکنیک‌های جدیدی را ارائه داده‌اند، در مجموع ۵۸ مقاله مرتبط از میان ۴۰۳ مقاله شناسایی شد. با حذف آثاری که کد منبع آن‌ها در دسترس نبود، ۴۴ پژوهش باقی ماند که شامل ۳۱ کار مبتنی بر AFL و ۱۳ کار مبتنی بر ++AFL بود.

در ادامه، این آثار به ‌صورت دستی مورد تحلیل قرار گرفتند؛ از جمله بررسی مخازن کد (repositories)، گزارش‌ مشکلات (issues) و درخواست‌های ادغام (pull requests) و سپس یک نظام امتیازدهی برای ارزیابی امکان‌پذیری ادغام (integration feasibility) آن‌ها در ++AFL اعمال شد. این فرایند در نهایت ۱۷ مقاله را به‌ عنوان قابل ادغام و یکپارچه‌سازی (integrable) شناسایی کرد، در حالی که ۲۷ مورد باقی‌مانده به ‌عنوان قابل ادغام با سطوح مختلفی از پیچیدگی و امکان‌پذیری متغیر (varying feasibility) طبقه‌بندی شدند.

برخی از این پژوهش‌ها، از جمله mOpt [74] ،SAND [69] و مرحله قطعی سریع (fast deterministic stage) [141]، در حال حاضر در ++AFL ادغام شده‌اند. بررسی دقیق مخزن کد ++AFL نشان داد که تنها شش کار پژوهشی دانشگاهی از مجموعه داده ما در این پروژه ادغام شده‌اند؛ چهار مورد در مرحله اولیه توسعه (۲۰۱۸–۲۰۱۹) و دو مورد در سال‌های بعدی (۲۰۲۴–۲۰۲۵).

این آثار ادغام ‌شده تنها بخش کوچکی از ۱۷ مقاله‌ای هستند که در تحلیل ما به‌ عنوان امکان‌پذیر برای ادغام و یکپارچه‌سازی (feasible for integration) شناسایی شده‌اند. بررسی دقیق‌تر گزارش‌ مشکلات (issues) و درخواست‌های ادغام (pull requests) نیز نشان داد که شش کار دیگر پیش‌تر برای ادغام مورد بررسی قرار گرفته‌اند. از میان این موارد چهار مورد به دلیل آن که نتایج گزارش ‌شده آنها فاقد اهمیت آماری بودند و یا بر فرضیات غیرواقعی متکی بودند، رد شدند، در حالی که دو مورد دیگر به دلیل نیاز به تغییرات عمیق و تهاجمی در کد (invasive code changes) یا ارائه مزایای عملی محدود، امکان ادغام نیافتند.

ما همچنین تمامی قابلیت‌هایی را که در ++AFL ادغام شده‌اند، بدون توجه به محل انتشار یا منشأ آن‌ها مورد بررسی قرار دادیم. این تحلیل نشان می‌دهد که در بازه زمانی ۲۰۲۰ تا ۲۰۲۵، تنها ۱۲ کار پژوهشی جدید در این پروژه ادغام شده‌اند؛ که بخش عمده آن‌ها به مسائل محدود و خاص (narrow use cases) از جمله فازینگ صرفاً باینری (binary-only fuzzing)، فازینگ مبتنی بر اسنپ‌شات (snapshot)، یا استفاده از جهش‌دهنده‌های سفارشی (custom mutators) مربوط می‌شوند (رجوع شود به شکل ۳.۲). این نتایج با یافته‌های تجربی ما هم‌راستا هستند و مشاهده سکون و توقف در پیشرفت فازینگ اهداف عمومی و همه منظوره (general-purpose fuzzing) را تقویت می‌کنند.

۳.۱.۱ تعمیم‌پذیری مشاهدات (Generalizability of Observations)

آزمایش‌های تجربی ما تاکنون بر روی ++AFL به ‌عنوان یک فازر با ریشه دانشگاهی متمرکز بوده‌اند. نتایج به ‌دست‌آمده نشان می‌دهد که این ابزار در سال‌های اخیر پیشرفت محدودی داشته است. به منظور بررسی آن که آیا این نتایج قابلیت تعمیم به سایر فازرها را نیز دارند یا خیر، دو فازر دیگر نیز مورد ارزیابی قرار گرفتند: LibAFL به‌ عنوان تنها فازر عمومی همه ‌منظوره فعال در حال توسعه که به‌طور مستمر دستاوردهای پژوهشی را ادغام می‌کند، و Fuzzilli به ‌عنوان یک فازر موتور جاوااسکریپت که توسط شرکت‌های Google و Mozilla مورد استفاده قرار می‌گیرد. هر دو فازر مذکور نیز مشابه ++AFL در طول زمان به ‌روزرسانی‌های مستمر و قابلیت‌های جدید دریافت کرده‌اند.

LibAFL: جایگزین ++AFL. فازر LibAFL که در سال ۲۰۲۱ توسط Fioraldi و همکاران معرفی گردید [42] یک چارچوب فازینگ ماژولار (modular fuzzing framework) است که به پژوهشگران اجازه می‌دهد فازرهای سفارشی را با ترکیب مؤلفه‌های قابل‌استفاده مجدد از جمله ناظرها (observers)، مکانیزم‌های بازخورد (feedback mechanisms)، جهش‌دهنده‌ها (mutators) و اجراکننده‌ها (executors) ایجاد کنند.

این معماری به سبک لگو (Lego-style)، امکان ساخت فازرهای عمومی همه منظوره (مانند libafl-generic [42]) و گونه‌های بسیار تخصصی و هدف‌محور [14] را فراهم می‌سازد. افزون بر این، LibAFL به ‌طور مستمر از سوی جامعه توسعه‌دهندگان به ‌روزرسانی شده و به ‌صورت فعال، دستاوردهای موفق پژوهشی جدید را در خود ادغام می‌کند. با این حال، از آنجا که LibAFL به‌عنوان یک کتابخانه فازینگ (fuzzing library) و نه یک فازر کامل طراحی شده است، خود شامل یک پیاده‌سازی کامل فازر یا تنظیمات و پیکربندی‌های پیش‌فرض آماده استفاده (default configurations) نمی‌باشد.

شکل 3.3a، به‌ صورت خلاصه بهبود پوشش کد (coverage improvement) در مهار LibAFL (یا LibAFL harness) را در تمامی اهداف آزمایشی نشان می‌دهد. میانگین (median) بهبود نسبی در نسخه‌های ابتدایی به‌ صورت چشمگیری افزایش یافته و در بازه نسخه‌های 0.4.0 تا 0.9.0 به حدود ۱۶ درصد می‌رسد، در حالی که چارک بالایی (upper quartile) تا ۲۵ درصد نیز افزایش می‌یابد؛ با این حال، پس از این دوره اولیه، روند بهبود عمدتاً به حالت اشباع یا سکون (plateau) خواهد رسید.

این جهش اولیه هم‌زمان با ادغام تکنیک‌های تثبیت‌ شده فازینگ و اصلاحات عمده در پیاده‌سازی رخ داده است. بررسی روند رگرسیون (regression analysis) در طول نسخه‌ها نشان‌دهنده یک روند صعودی خفیف در سطح کلی است که حاکی از ادامه بهبودها، اما با نرخ کاهشی (diminishing returns) می‌باشد؛ به ‌طوری‌که میزان این بهبودها بسته به هدف مورد آزمایش، متفاوت است.

Fuzzilli: فازینگ مورد حمایت صنعت. Fuzzilli یک فازر متن‌باز هدایت‌ شده با پوشش کد (coverage-guided) است که برای کشف آسیب‌پذیری‌ها در موتورهای جاوااسکریپت (JavaScript) طراحی شده است؛ موتورهایی که به دلیل استفاده گسترده از کامپایل در لحظه (همزمان با) اجرا (Just-In-Time; JIT compilation) به‌ طور فزاینده‌ای پیچیده شده‌اند.

این ابزار از یک رویکرد خاص استفاده می‌کند که مبتنی بر یک زبان میانی سفارشی (custom intermediate language) با نام FuzzIL است [52]. این طراحی امکان تولید و جهش مؤثرتر کد جاوااسکریپت (JavaScript) را فراهم می‌سازد و در نتیجه، توانایی فازر را در تولید ورودی‌های حائز اهمیت و معنادار و ساختارمند به‌ طور قابل‌توجهی افزایش می‌دهد. چنین رویکردی به Fuzzilli اجازه می‌دهد تا باگ‌های پیچیده‌ای را شناسایی کند که معمولاً از دید تکنیک‌های فازینگ سنتی پنهان می‌مانند.

Fuzzilli با تمرکز ویژه بر رفتار کامپایلرهای JIT، موفق به کشف آسیب‌پذیری‌های امنیتی متعددی در موتورهای مختلف جاوااسکریپت از جمله JavaScriptCore، V8 و SpiderMonkey شده است. در حال حاضر، این ابزار به ‌صورت فعال توسط گوگل (Google) توسعه داده می‌شود و به ‌طور گسترده نیز توسط توسعه‌دهندگان مرورگر برای آزمون مداوم و مستمر موتورهای جاوااسکریپت مورد استفاده قرار می‌گیرد [139].

به همین دلیل، بسیاری از پژوهش‌های دانشگاهی یا بر پایه Fuzzilli توسعه یافته‌اند یا آن را به ‌عنوان خط مبنای ارزیابی استفاده کرده‌اند، چرا که این ابزار به‌ عنوان یکی از رویکردهای پیشرفته (state-of-the-art) در حوزه فازینگ جاوااسکریپت محسوب می‌شود [103, 125, 129, 134].

شکل 3.3b، نتایج آزمایش‌های مربوط به Fuzzilli را در دو هدف SpiderMonkey و V8 خلاصه می‌کند. پوشش کد (code coverage) در مراحل اولیه توسعه به‌ صورت پیوسته افزایش یافته و به حدود ۲٪ می‌رسد، سپس در سال ۲۰۲۲ یک جهش قابل‌توجه تا حدود ۶.۵٪ مشاهده می‌شود. پس از این مرحله، پیشرفت‌ها و بهبودها تا حد زیادی متوقف شده و عمدتاً دچار رکود (stagnation) می‌شوند. تحلیل رگرسیون (regression analysis) در طول نسخه‌ها یک روند کلی صعودی را نشان می‌دهد که بیانگر افزایش پیوسته پوشش کد در طول زمان است؛ با این حال، این بهبودها عمدتاً به تعداد اندکی از تغییرات ثبت شده (commit) محدود شده‌اند و به ‌صورت یکنواخت در کل دوره توسعه توزیع نشده‌اند.

۳.۱.۲ بحث‌ها و محدودیت‌ها (Discussion and Limitations)

در ادامه، پیامدهای یافته‌های این پژوهش و همچنین محدودیت‌های مطالعه حاضر مورد بحث و بررسی قرار می‌گیرد.

کامل‌بودن ویژگی‌ها و تنظیمات پیش‌فرض. ارزیابی ما بر تحلیل تأثیر مجموعه‌ای از ویژگی‌های منتخب در ++AFL متمرکز می‌باشد، اما هدف آن پوشش کامل تمامی قابلیت‌های این فازر نیست. به‌طور مشخص، دامنه مطالعه به فازینگ عمومی مبتنی بر کد منبع (general-purpose source-based fuzzing) محدود شده و عمداً حالت‌هایی که برای باینری‌های بسته (closed-source binaries) طراحی شده‌اند از جمله فازینگ مبتنی بر QEMU یا رویکردهای مبتنی بر اسنپ‌شات (snapshot) مانند Nyx [108] از تحلیل حذف شده‌اند.

تمامی ویژگی‌ها به ‌صورت مجزا (in isolation) مورد آزمون قرار گرفتند تا سهم و تأثیر هر یک به ‌صورت مستقل ارزیابی شود. با این حال، در عمل، فازرها اغلب از ترکیب چندین ویژگی به‌صورت هم‌زمان بهره‌مند می‌شوند. برای مثال، ترکیب CmpLog با dict2file می‌تواند به‌طور قابل‌توجهی عملکرد را بهبود بخشد، زیرا امکان مدیریت مؤثرتر قالب‌های ورودی پیچیده را فراهم می‌سازد.

به‌ طور مشابه، از تنظیمات پیش‌فرض، در تمامی ویژگی‌های مورد ارزیابی استفاده شده است. اگرچه این رویکرد امکان مقایسه‌پذیری (comparability) نتایج را تضمین می‌کند، اما ممکن است بازتاب دقیقی از کاربردهای واقعی نباشد؛ زیرا در سناریوهای عملی، متخصصان معمولاً پارامترها را به‌ صورت هدفمند و دقیق تنظیم (fine-tuning) می‌کنند.

برای مثال، ویژگی‌هایی مانند CmpLog دارای گزینه‌های خط فرمان (command-line options) هستند که می‌توانند کارایی و اثربخشی آن‌ها را بهبود دهند، اما بررسی آن‌ها خارج از محدوده این مطالعه بوده است. در نتیجه، نتایج ما تنها یک دید پایه (baseline view) از اثربخشی ویژگی‌های منفرد تحت پیکربندی‌های پیش‌فرض ارائه می‌دهد و ممکن است توان بالقوه آن‌ها را در صورت تنظیم دقیق (fine-tuning) یا استفاده ترکیبی از مجموعه ویژگی‌ها، کمتر از مقدار واقعی برآورد کرده باشد.

کارهای آینده می‌تواند دامنه ارزیابی ما را گسترش داده و به‌صورت نظام‌مند به بررسی ترکیب ویژگی‌ها (feature combinations) و تنظیم پارامترها (parameter tuning) بپردازد. چنین توسعه‌ای می‌تواند بینش‌های ارزشمندی درباره نحوه تعامل تکنیک‌های مختلف در عمل ارائه دهد و به تدوین دستورالعمل‌هایی برای انتخاب مجموعه ویژگی‌های مناسب‌تر با توجه به نوع برنامه هدف یا قالب‌های ورودی مختلف کمک کند.

علاوه بر این، پژوهش‌های آینده می‌توانند به‌طور عمیق‌تری به بررسی حالت‌های فازینگ صرفاً باینری (binary-only fuzzing modes) در ++AFL بپردازند. این حالت‌ها در عمل، به ‌ویژه در شرایطی که کد منبع در دسترس نیست، به‌طور گسترده مورد استفاده قرار می‌گیرند؛ با این حال، با چالش‌های خاصی همراه هستند، از جمله سربار عملکردی بالاتر (higher performance overhead)، محدودیت در میزان جزئیات بازخورد (limited feedback granularity)، و پیچیدگی بیشتر در مکانیزم‌های ابزارگذاری (instrumentation mechanisms). درک نحوه رفتار مجموعه ویژگی‌های ++AFL در سناریوهای صرفاً باینری می‌تواند به تعمیم‌پذیری بیشتر یافته‌های این مطالعه در زمینه فازینگ دنیای واقعی کمک کند.

معیارهای مورد استفاده. معیار اصلی ما برای اندازه‌گیری پیشرفت و بهبودها در طول زمان، پوشش کد (code coverage) است که به ‌عنوان معیار استاندارد عملی (de facto standard) در ارزیابی‌های فازینگ پذیرفته شده است [67, 107]. با وجود اینکه پوشش کد یک شاخص ارزشمند محسوب می‌شود، تنها تصویری ناقص از عملکرد فازر ارائه می‌دهد؛ زیرا هدف نهایی فازینگ صرفاً پیمایش مسیرهای عمیق‌تر در کد نیست، بلکه فعال‌سازی و آشکارسازی باگ‌ها و آسیب‌پذیری‌ها است.

به منظور تکمیل آزمایش‌های مبتنی بر پوشش کد، یک مطالعه کشف باگ (bug-finding study) بر روی شش هدف از مجموعه FuzzBench انجام شده است. با این حال، این دامنه محدود امکان انجام ارزیابی‌های گسترده‌تر را فراهم می‌کند. پژوهش‌های آتی می‌توانند ابعاد این مطالعه را با استفاده از معیارهای کشف باگ (bug benchmarks) در مقیاس بزرگ‌تر، مانند MAGMA [58] یا چارچوب‌های مشابه، گسترش دهند.

کامل‌بودن مطالعات پژوهشی و نظام امتیازدهی. مطالعات ما به ‌صورت هدفمند به کنفرانس‌های سطح‌بالا (*A) در حوزه مهندسی نرم‌افزار و امنیت محدود شده است، زیرا این مجامع معمولاً پژوهش‌های پراستناد در زمینه فازینگ را منتشر می‌کنند. با این حال، این تمرکز ممکن است منجر به حذف برخی آثار مرتبط منتشر شده در کنفرانس‌ها یا مجلات کوچک‌تر شده باشد؛ آثاری که در برخی موارد به‌ صورت تاریخی تکنیک‌هایی را معرفی کرده‌اند که بعدها در ++AFL نیز مورد استفاده قرار گرفته‌اند [40, 62, 126].

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

علاوه بر این، ما تنها آثاری را بررسی کردیم که به‌ صورت مستقیم بر پایه AFL یا ++AFL توسعه یافته بودند. این فیلترگذاری اگرچه فرآیند امتیازدهی برای ادغام (integration scoring) را ساده‌تر می‌کند، اما ممکن است پژوهش‌های مهمی را که مبتنی بر AFL نیستند ولی همچنان از نظر قابلیت ادغام بسیار مرتبط هستند، حذف کرده باشد (RedQueen [4]).

ارزیابی ما همچنین دارای محدودیت‌های روش‌شناختی (methodological limitations) است: ما مخازن کد ارائه ‌شده را بررسی و مقایسه کردیم، اما تلاش نکردیم که آثار و خروجی‌های تولید شده (artifacts) آن را کامپایل یا اجرا کنیم. در نتیجه، امتیازهایی که اختصاص داده‌ایم ( بر اساس شاخص‌هایی مانند در دسترس بودن مخزن، پیچیدگی کد، وجود فایل‌های build، وابستگی‌ها، میزان مستندسازی، تاریخچه به‌روزرسانی، و عملکرد گزارش‌ شده) بایستی به ‌عنوان شاخص‌ تقریبی (indicative) و نه قطعی در نظر گرفته شوند. از آنجا که امتیازدهی ذاتاً شامل قضاوت ذهنی (subjective judgment) است، ممکن است دو ارزیاب متفاوت به همان شواهد وزن‌دهی متفاوتی بدهند. بنابراین، امتیازهای ارائه ‌شده بهتر است به ‌عنوان راهنمای تقریبی برای قابلیت ادغام (integrability) تفسیر شوند، نه به‌ عنوان نتیجه‌گیری‌های قطعی و نهایی.

۳.۲ سایه‌سازی ورودی در فازینگ هدایت‌ شده با پوشش کد (Input Shadowing in Coverage-Guided Fuzzing)

معرفی فازینگ هدایت‌ شده با پوشش کد (coverage-guided fuzzing) توسط AFL در سال ۲۰۱۳، حوزه فازینگ جعبه‌ خاکستری (greybox fuzzing) را متحول کرد. این رویکرد با ترکیب ابزارگذاری هدف سبک (lightweight target instrumentation)، یک بیت‌مپ پوششی مبتنی بر حافظه مشترک (shared-memory coverage bitmap)، و یک الگوریتم مبتنی بر جستجوی نوآوری‌محور و جدید (novelty-search-based algorithm) برای تعیین «جذابیتِ» (interestingness) نمونه‌های آزمایشی، پایه‌گذار بسیاری از تکنیک‌های فازینگ بعدی شد.

از آن زمان تاکنون، پژوهش‌های متعددی با هدف بیشینه‌سازی پوشش کد (code coverage) و افزایش توان کشف باگ (bug-finding ability)، این الگوی بازخوردمحور (feedback-driven paradigm) را گسترش داده و یا برای اهداف جدید تطبیق داده‌اند. با این حال، همانطور که در فصل قبل نشان داده شد، پیشرفت کلی در فازینگ عمومی‌ همه منظوره (general-purpose fuzzing) در سال‌های اخیر به ویژه هنگام بررسی ++AFL به ‌عنوان یک نمونه نماینده، ثابت و متوقف مانده و به حالت اشباع یا سکون (plateau) رسیده است.

در حالی که مقالات علمی همچنان تکنیک‌های پیچیده‌تری را پیشنهاد می‌دهند، این رویکردها اغلب یا در عمل قادر به تحقق بهبودهای وعده‌ داده ‌شده نیستند، یا به قدری پیچیده و غیرعملی هستند که ادغام آن‌ها در گردش‌کارهای واقعی فازینگ دشوار می‌شود. در مقایسه با پیشرفت‌های سریع سال‌های ابتدایی پس از معرفی AFL، نوآوری‌های اخیر عمدتاً بازده نزولی (diminishing returns) داشته‌اند.

این سکون نشان می‌دهد که محدودیت‌ها لزوماً تنها ناشی از فقدان تکنیک‌های جدید نیست، بلکه می‌تواند از ضعف‌های نادیده‌گرفته ‌شده در مکانیزم‌های موجود نیز باشد. یکی از این نقاط مبهم و کور ناشناخته و بررسی ‌نشده و یا کمتر بررسی شده (underexplored blind spots) به یکی از مهم‌ترین سازوکارهای AFL که پیاده‌سازی الگوریتم جستجوی نوآوری‌محور و جدید (novelty search algorithm) نام دارد، مربوط می‌شود. اگرچه این مکانیزم نقش کلیدی در موفقیت AFL و مشتقات آن داشته است، اما در عین حال می‌تواند یک نقص ظریف (subtle pitfall) ایجاد کند که به ‌طور بالقوه بر روند پیشرفت فازینگ اثر منفی می‌گذارد.

جستجوی نوآوری‌محور (Novelty Search). جستجوی نوآوری‌محور (Novelty Search) الگوریتمی است که نخستین بار توسط Lehman و همکارانش معرفی شد [71]. این الگوریتم یک تابع هدف تکاملی (evolutionary objective function) محسوب می‌شود که برخلاف تابع برازندگی (fitness function) که معمولاً میزان پیشرفت به سمت یک هدف مشخص در فضای جستجو را اندازه‌گیری می‌کند، از «رفتارهای جدید و نوآوری‌محور» (novel behavior) به‌ عنوان معیاری برای گام‌های میانی (stepping stones) استفاده می‌کند. در این رویکرد، سیستم برای یافتن نمونه‌هایی پاداش می‌گیرد که بر اساس معیار نوآوری‌محور (novelty metric)، به ‌طور قابل‌توجهی با آنچه پیش‌تر مشاهده شده متفاوت می‌باشند [70].

AFL یک الگوریتم جستجوی نوآوری‌محور (novelty search) سریع را به‌کار می‌گیرد تا تعیین کند آیا یک ورودی «جالب» (interesting) می‌باشد یا قبلاً مشاهده شده است، و در نتیجه مشخص شود که آیا باید در مجموعه ورودی‌ها (corpus) ذخیره شود یا خیر [41, 138]. با استفاده از این معیار، فازر برای کشف یال‌های جدید (new edges) و در نتیجه افزایش پوشش کد (code coverage) در برنامه هدف، پاداش دریافت می‌کند.

این جستجوی نوآوری‌محور (novelty search) یکی از عناصر کلیدی موفقیت فازرهای مبتنی بر AFL محسوب می‌شود، زیرا به فازر امکان می‌دهد به‌ جای نگهداری ورودی‌هایی با پوشش یکسان، بر اکتشاف (exploration) تمرکز کند و در نتیجه با حذف موارد تکراری، اندازه مجموعه ورودی‌ها (corpus) را کوچک نگه دارد.

با این حال، الگوریتم جستجوی نوآوری‌محور (Novelty Search)، یک محدودیت ظریف اما مهم نیز ایجاد می‌کند که می‌تواند بر روند پیشرفت فازینگ اثر بگذارد. به دلیل طراحی ذاتی آن، برخی رفتارهای جدید ممکن است شناسایی نشوند یا تحت‌الشعاع ورودی‌هایی قرار گیرند که پیش‌تر کشف شده‌اند. این محدودیت تا حدی از مشکل انفجار مسیرها (path explosion problem) شناخته ‌شده ناشی می‌شود:

حتی برنامه‌های کوچک نیز می‌توانند تعداد نمایی (exponential) از مسیرهای اجرایی متفاوت تولید کنند که بخش زیادی از آن‌ها دارای هم‌پوشانی در پوشش (overlapping coverage) هستند. از آنجا که AFL و مشتقات آن نمی‌توانند به ‌صورت عملی همه این مسیرها را از یکدیگر تفکیک کنند، پوشش کد به مجموعه محدودی از شمارنده‌ها (counters) تجمیع می‌شود که هر یک نماینده یک یال اجرایی (execution edge) یا یک باکت انتقالی (transition bucket) هستند. این فرایند که با عنوان دسته‌بندی (bucketing) شناخته می‌شود، مجموعه بزرگی از مسیرهای ممکن را به یک بیت‌مپ (bitmap) بسیار کوچک‌تر نگاشت می‌کند؛ به‌طوری‌که چندین مسیر اجرایی متمایز ممکن است در یک دسته (bucket) واحد با هم برخورد کنند. اگرچه این مکانیزم (bucketing) امکان ردگیری پوشش در زمان اجرا را فراهم می‌سازد، اما در عین حال تمایزهای رفتاری را نیز مبهم (blur) می‌کند و در نتیجه معیار جدید فازر ممکن است ورودی‌های متفاوت را به ‌اشتباه مشابه در نظر بگیرد.

کلاس‌های هم‌ارزی نوآوری‌محور و سایه‌سازی ورودی (Novelty Equivalence Classes and Input Shadowing). یک برنامه هدف (P) دارای فضای حالت (S) است که از طریق ورودی‌های فضای ورودی (I) و با تغذیه آن‌ها به فازر (f)، قابل دسترسی می‌باشد. اگر دو ورودی متفاوت i₁ و i2 برای i₁ , i₂ ∈ I در برنامه هدف پوشش (coverage) و انتقال‌های باکت (bucket transitions) یکسانی را فعال کنند، آنگاه هر دو ورودی در یک کلاس هم‌ارزی نوآوری‌محور (Novelty Equivalence Class) مشترک ν قرار می‌گیرند. این وضعیت در صورتی که پس از اعمال فرایند دسته‌بندی (bucketing) در فازر (f) پوشش یکسانی تولید کنند، برای تمام ورودی‌های i ∈ I صدق خواهد کرد.

از آنجا که هر دو ورودی i₁ و i₂ متفاوت هستند، اعمال جهش (mutation) بر روی آن‌ها توسط فازر می‌تواند به نتایج متفاوتی منجر شود. به ‌عنوان مثال، ممکن است i₂ دارای ساختاری باشد که برای متصل شدن (splice) مناسب‌تر بوده و یا از نظر جهش‌های سطح بایت (byte-level mutations) به وضعیت‌هایی نزدیک‌تر باشد که بتوانند رفتار جدیدی را در برنامه هدف فعال کنند، در حالی که i₁دارای چنین ویژگی نباشد.

با این حال، به دلیل نحوه پیاده‌سازی الگوریتم جستجوی جدید و نوآوری‌محور (novelty search) در AFL و مشتقات آن، هر دو ورودی در یک کلاس هم‌ارزی نوآوری‌محور (novelty equivalence class) مشترک ν قرار می‌گیرند. در نتیجه، نخستین ورودی اجرا شده که رفتار جدیدی را فعال می‌کند i₁ در صف (queue) ذخیره شده و برای جهش‌های بعدی مورد استفاده قرار می‌گیرد، در حالی که ورودی دوم کشف ‌شده i₂ حذف و کنار گذاشته می‌شود. بنابراین، i₂ توسط i₁ سایه‌گذاری (shadowed)؛ پدیده‌ای که آن را سایه‌سازی ورودی (input shadowing) می‌نامیم. شکل ۳.۴ این رفتار را نمایش می‌دهد.

والنرلب - vulnerlab- فازینگ - Fuzzing - فازرهای هدایت‌ شده با پوشش کد - coverage-guided fuzzers — شکل ۳.۴: فضای ورودی یک برنامه هدف. نواحی خاکستری مربوط به ورودی‌هایی هستند که پوشش یکسانی تولید می‌کنند. دایره‌های قرمز، فضای ورودی قابل ‌دسترسی از طریق جهش‌های اعمال‌ شده بر ورودی‌های متناظر را نمایش می‌دهند. همان‌طور که نشان داده شده است، i1 و i2به یک کلاس هم‌ارزی جدید (novelty equivalence class) تعلق دارند؛ با این حال، تنها جهش‌های مشتق ‌شده از i2 قادر به تولید ورودی (t) هستند.

در ادامه، اثرات سایه‌سازی ورودی (input shadowing) با استفاده از ++AFL به ‌عنوان مطالعه موردی بررسی و تحلیل می‌شود. بدین منظور، ۱۵ هدف از مجموعه FuzzBench به‌صورت گسترده مورد مطالعه قرار گرفتند و برای مقابله با پدیده سایه‌گذاری ورودی، از یک راهکار ساده استفاده شد: راه‌اندازی مجدد فازر (fuzzer restarting) در زمانی که پوشش کد دچار توقف و سکون می‌شود، با هدف بازنشانی وضعیت جستجوی (search state) فازر.

این ایده از ماهیت ذاتاً تصادفی (stochastic) فازینگ نشأت می‌گیرد؛ به‌گونه‌ای که هر اجرای فازینگ، به دلیل عوامل غیرقطعی مانند عملیات جهش (mutation operations)، ترتیب پردازش فایل‌های بذر (seed files)، و تأثیرات جستجوی جدید (novelty search)، می‌تواند نتایج اندک متفاوتی را تولید کند. این مؤلفه‌های تصادفی ممکن است موجب شوند فازر به‌ صورت زودهنگام همگرا (premature convergence) شده و در یک بهینه محلی (local optimum) گرفتار شود؛ وضعیتی که در آن دیگر قادر به اکتشاف مسیرهای عمیق‌تر یا مسیرهای جایگزین در برنامه هدف نیست.

علاوه بر این، راهبردهای راه‌اندازی مجدد تطبیقی (adaptive restart strategies) پیش‌تر در سایر حوزه‌های پژوهشی، از جمله سنتز برنامه (program synthesis)، با موفقیت برای غلبه بر پدیده‌های مشابهِ سکون یا اشباع عملکرد به‌کار گرفته شده‌اند [68].

راه‌اندازی مجدد فازر (fuzzer restarting) موجب بازنشانی کامل وضعیت داخلی فازینگ از جمله بیت‌مپ پوششی (coverage bitmap) می‌شود. این کار امکان کشف مجدد شاخه‌هایی که پیش‌تر پیمایش و بازدید شده‌اند را فراهم و یا یک نقطه شروع جدید برای فرایند اکتشاف (exploration) ایجاد می‌کند. در نتیجه، احتمال کشف ورودی‌های جدید و عبور از بهینه‌های محلی (local optima) افزایش می‌یابد.

با این حال، چنین راه‌اندازی‌های مجددی غیرمنطقی و از نظر محاسباتی پرهزینه هستند؛ زیرا تا زمانی که تصمیم به راه‌اندازی مجدد گرفته شود، منابع محاسباتی قابل‌توجهی پیش‌تر برای رسیدن به وضعیت توقف (stalled state) صرف شده است.

به منظور پرداختن به این موضوع، مجموعه‌ای از راهبردهای نگهداشت مجموعه ورودی‌ها (corpus retention strategies) طراحی و ارزیابی گردید که در آن‌ها بخشی از مجموعه ورودی‌های تولید شده به ‌صورت انتخابی در طول راه‌اندازی‌های مجدد فازینگ حفظ می‌شود.

عناصر حفظ ‌شده از مجموعه ورودی‌ها (corpus) سپس در اجراهای بعدی به‌عنوان ورودی‌های بذر (seed inputs) مجدداً مورد استفاده قرار می‌گیرند. این رویکرد به فازر امکان می‌دهد بدون از دست دادن کامل پیشرفت‌های قبلی، فرایند جستجو را از یک نقطه شروع مهم و معنادار ادامه دهد. از آنجا که نتایج تمامی اجراهای پیشین فازینگ ثبت (log) و ذخیره می‌شوند، هیچ داده‌ای از دست نخواهد رفت. راهبردهای نگهداشت (retention) در سیاست انتخاب خود با یکدیگر متفاوت هستند؛ به عنوان مثال، برخی راهبردها ورودی‌های انتخاب‌ شده به ‌صورت تصادفی را حفظ می‌کنند، برخی دیگر فرزندان (offspring) تولید شده از یک ورودی خاص را نگه می‌دارند، و برخی نیز از یک سیاست مبتنی بر زمان استفاده می‌کنند که در آن تمامی ورودی‌های تولید شده پس از یک نقطه زمانی مشخص حذف می‌شوند.

۳.۲.۱ نتایج کلیدی (Key Results)

نتایج آزمایش‌های ما حاکی از آن است که فازینگ مبتنی بر راه‌اندازی مجدد (restart-based fuzzing)، یک رویکرد عملی و در عین حال ساده برای مقابله با سایه‌سازی ورودی (input shadowing) و کاهش اثرات آن است. در میان راهبردهای مختلف نگهداشت (retention strategies) که مورد ارزیابی قرار گرفتند، هرس کردن مجموعه ورودی (corpus pruning) مؤثرترین روش بود. در این راهبرد، بین ۵ تا ۹۵ درصد از ورودی‌های تولید شده به ‌صورت تصادفی در میان اجراهای مختلف حفظ می‌شوند.

با حذف بخشی از مجموعه ورودی (corpus) انباشته ‌شده و در عین حال حفظ زیرمجموعه‌ای از آن، راهبرد هرس کردن مجموعه ورودی (corpus pruning) از یک سو از اثرات سکون ناشی از نگهداشت کامل جلوگیری می‌کند و از سوی دیگر هزینه‌های ناشی از کشف مجدد مسیرها در بازنشانی کامل را کاهش می‌دهد.

این رویکرد متعادل، به‌ صورت پایدار عملکردی بهتر از سایر راهکارها نشان داد و توانست پوشش شاخه‌ای (branch coverage) را در ۱۵ هدف آزمایشی به‌ طور میانگین ۹.۵٪ افزایش دهد؛ این میزان در برخی معیارهای منفرد به ۲۵٪ نیز رسید. شکل ۳.۵ تأثیر راهبردهای نگهداشت پیشنهادی را بر روی دو هدف نمونه نشان می‌دهد.

فراتر از مقادیر پوشش خام، مشاهده کردیم که هرس کردن مجموعه ورودی (corpus pruning) باعث افزایش تنوع در فرایند اکتشاف (exploration diversity) می‌شود. راه‌اندازی‌های مجدد موجب بازتوزیع فرایند اکتشاف پوشش در سراسر پایگاه کد (code-base) شده و فراوانی پیمایش بلوک‌های پایه کمیاب (rare basic blocks) را افزایش می‌دهند؛ بلوک‌هایی که فازرهای بدون راه‌اندازی مجدد معمولاً آن‌ها را نادیده می‌گیرند.

در عمل، این بدان معناست که هرس مجموعه ورودی (corpus pruning) به فازر اجازه می‌دهد مسیرهایی را که پیش‌تر تحت تأثیر سایه‌سازی ورودی (input shadowing) قرار گرفته‌اند، با استفاده از ورودی‌های جدید دوباره بررسی کند و در نتیجه، وضعیت‌های عمیق‌تر برنامه را فعال سازد؛ وضعیت‌هایی که در شرایط عادی ممکن است هرگز قابل دسترسی نباشند. تحلیل‌های مبتنی بر نقشه حرارتی (heatmap) و تابع توزیع تجمعی (cumulative distribution function – CDF) نیز این موضوع را تأیید کردند که راه‌اندازی‌های مجدد، سوگیری فازر به سمت مسیرهای بیش‌ازحد پرتکرار را کاهش داده و حتی پس از رسیدن پوشش به حالت توقف، به حفظ روند پیشرفت کمک می‌کنند (به شکل ۳.۶ مراجعه شود).

نکته مهم این است که این بهبودها به افزایش توان کشف باگ (bug-finding ability) نیز منجر شدند. در آزمایش‌های مربوط به کشف باگ، هرس کردن مجموعه ورودی (corpus pruning) نه‌ تنها موجب شد کرش‌های (Crash) شناخته ‌شده با قابلیت اطمینان بیشتری در اجراهای مختلف دوباره کشف شوند، بلکه در مقایسه با خط مبنای ++AFL، باگ‌های منحصربه‌فرد بیشتری نیز شناسایی شد. در برخی اهداف آزمایشی، این بهبود قابل‌توجه بود؛ به ‌طوری‌ که باگ‌هایی که در فازینگ پایه تنها به‌ صورت پراکنده ظاهر می‌شدند، پس از فعال‌سازی راهبردهای مبتنی بر راه‌اندازی مجدد (restart-based strategies) به‌ طور پایدار قابل فعال‎سازی (trigger) بودند. این موضوع نشان می‌دهد که توزیع گسترده‌تر اجرای موارد آزمایشی (broader distribution of test case executions) می‌تواند به ‌طور مستقیم اثربخشی یک فازر را به ‌عنوان ابزار کشف آسیب‌پذیری (vulnerability discovery tool) تقویت کند.

در نهایت، اگرچه فازینگ مبتنی بر راه‌اندازی مجدد (restart-based fuzzing) تنها سربار زمانی (runtime overhead) محدودی ایجاد می‌کند، اما بسته به راهبرد نگهداشت (retention strategy)، در صورت حفظ مجموعه‌های ورودی بزرگ می‌تواند موجب مصرف قابل‌توجه فضای دیسک شود. در مقابل، هرس کردن مجموعه ورودی (corpus pruning) با انتخاب تصادفی میزان داده‌ای که باید در مجموعه حفظ شود، هزینه‌های ذخیره‌سازی را بدون آنکه کارایی سیستم به‌طور قابل توجه و معناداری کاهش یابد، در سطح قابل مدیریت نگه می‌دارد.

در مجموع، نتایج ما نشان می‌دهد که راه‌اندازی مجدد فازرها (fuzzer-restarts) یک مکانیزم ساده اما قدرتمند برای کاهش اثر سایه‌سازی ورودی (input shadowing)، افزایش تنوع در اکتشاف پوشش (coverage exploration diversity)، و بهبود قابلیت اطمینان در کشف باگ (bug-finding reliability) است.

۳.۲.۲ بحث و محدودیت‌ها (Discussion and Limitations)

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

فازرهای هدایت‌ شده با پوشش کد - coverage-guided fuzzers — شکل ۳.۶: نقشه‌های حرارتی (heatmaps) که فراوانی برخورد با بلوک‌های پایه (basic block hits) را در اجرای میانگین (median run) فازینگ با ++AFL و همچنین در حالت هرس مجموعه ورودی (corpus pruning) بر روی هدف libpng نشان می‌دهند. هر سلول نمایانگر یک بلوک پایه است؛ بلوک‌های آبی نشان می‌دهند که اجرای میانگین در حالت خط مبنا، این بلوک پایه را با فراوانی بیشتری پیمایش کرده است، و بلوک‌های قرمز خلاف آن را نشان می‌دهد.

قابلیت اجرا به نسخه‌های جدیدتر ++AFL در مقایسه با بهبودهای متوقف ‌شده. در آزمایش‌های ما، عمدتاً از ++AFL در نسخه‌های 4.04c و 4.06c استفاده شد. به منظور ارزیابی آن که آیا یافته‌های ما برای نسخه‌های جدیدتر نیز معتبر می‌باشند یا خیر، راهبرد زمان‌بند راه‌اندازی مجدد (restart scheduler) را روی نسخه 4.32c، یکی از جدیدترین نسخه‌های موجود در زمان نگارش این متن آزمایش کردیم.

++AFL در فاصله بین نسخه‌های 4.04c تا 4.32c، شامل مجموعه‌ای از اصلاحات باگ (bug fixes)، بهینه‌سازی‌های موتور و زمان‌بند (engine and scheduler optimizations) و همچنین چندین ویژگی جدید شده است که به‌طور بالقوه می‌توانند اثر راه‌اندازی‌های مجدد را کاهش داده و در نتیجه شدت پدیده سایه‌سازی ورودی (input shadowing) را کمتر کنند.

به منظور تکمیل نتایج پیشین، آزمایش‌ها را روی ۱۰ هدف مختلف، هم با نسخه پایه و بدون تغییر ++AFL و هم با راهبرد هرس کردن مجموعه ورودی همراه با راه‌اندازی مجدد (restart corpus-pruning strategy) دوباره اجرا کردیم. اگرچه اثربخشی نسبی راه‌اندازی‌های مجدد در نسخه جدیدتر کاهش یافته است، اما فازرِ مبتنی بر راه‌اندازی مجدد همچنان تعداد برابر یا بیشتری از شاخه‌های برنامه را نسبت به خط مبنا پوشش می‌دهد. شکل ۳.۷ نتایج مربوط به دو هدف نمونه را نشان می‌دهد که در آن، فازرِ راه‌اندازیِ مجدد ‌شده حدود ۳٪ پوشش بیشتر به دست آورده است. هرچند این بهبود ممکن است در ظاهر نسبتا کم به نظر برسد، اما با یک روش ساده حاصل شده است که تنها سربار عملکردی (performance overhead) بسیار ناچیزی به سیستم تحمیل می‌کند.

نکته مهم‌تر اینکه، با بررسی مجدد مقادیر پوشش در نسخه‌های اولیه ++AFL که در فصل ۳.۱ (پذیرش فازینگ آکادمیک یا دانشگاهی) مورد بحث قرار گرفتند، مشاهده می‌شود که در هدف OpenSSL از سال ۲۰۱۹ به بعد در هیچ ‌یک از نسخه‌های آزمایش ‌شده، بهبود قابل‌توجهی حاصل نشده است.

در مقابل، نسخه بازراه‌اندازی‌شده‌ی ++AFL که در این رساله معرفی شده است، به بهبودهای ذکرشده دست می‌یابد و این موضوع نشان‌دهنده‌ی قابلیت کاربرد رویکرد پیشنهادی ما حتی در شرایطی است که فازینگ پایه به حالت سکون رسیده است.

محدودیت‌ها. اساس رویکرد راه‌اندازی مجدد (restarting) ما بر تشخیص بهینه‌های محلی (local optima) در فرایند فازینگ استوار است؛ این تشخیص از طریق پایش این موضوع انجام می‌شود که آیا فازر در یک بازه زمانی مشخص قادر به تولید ورودی‌های جدید می‌باشد یا خیر. در صورتی که پیشرفت متوقف گردد، یک راه‌اندازی مجدد فعال می‌شود.

با این حال، این معیار ابتکاری (heuristic) به ‌شدت وابسته به هدف (target-dependent) است. در ارزیابی‌های آکادمیک فازینگ که معمولاً دارای زمان اجرای پیش‌فرض ۲۴ ساعته هستند، اهداف با رشد آهسته اما مداوم ممکن است در زیر آستانه قرار بگیرند و در نتیجه، راه‌اندازی‌های مجدد زودهنگام فعال شوند؛ امری که می‌تواند روند پیشرفت بلندمدت را مختل سازد. در مقابل، اهداف پیچیده‌ای که در بازه زمانی ارزیابی متوقف نمی‌شوند، ممکن است هرگز وارد فاز راه‌اندازی مجدد نشوند، حتی اگر این راه‌اندازی‌ها سودمند باشند.

اگرچه راه‌اندازی‌های مجدد اجباری (forced restarts) امکان‌پذیر است، اما تأثیر آنها وابسته به هدف است، آنها ممکن است در برخی موارد یک آغاز مجدد مفیدی را برای اکتشاف فراهم کنند، اما در برخی موارد هم ممکن است موجب کاهش کارایی شوند. از این رو، اثربخشی راه‌اندازی مجدد به ‌شدت به هدف بستگی دارد و در صورت اعمال نادرست، حتی می‌تواند نتایجی بدتر از اجرای فازر بدون راه‌اندازی مجدد ایجاد کند.

یکی دیگر از محدودیت‌های ارزیابی ما این است که تنها فازینگ تک‌نمونه‌ای (single-instance fuzzing) را در نظر می‌گیرد. در عمل، معمولاً چندین نمونه فازر به‌ صورت موازی اجرا می‌شوند و در طول اجرا، مجموعه‌های ورودی (corpora) خود را با یکدیگر همگام‌سازی (synchronize) می‌کنند. این همگام‌سازی ممکن است به طور طبیعی اثر سایه‌سازی ورودی (input shadowing) را کاهش دهد، یا در حالتی دیگر اگر برخی نمونه‌ها از راه‌اندازی مجدد (restart) استفاده کنند و برخی دیگر نه، حتی می‌تواند موجب تقویت بیشتر روند پیشرفت شود. بررسی تعامل بین راه‌اندازی‌های مجدد و فازینگ چندنمونه‌ای همگام‌سازی ‌شده (synchronized multi-instance fuzzing) همچنان به‌عنوان یک موضوع باز برای پژوهش‌های آینده باقی می‌ماند.

نتایج ما نشان می‌دهد که سایه‌سازی ورودی (input shadowing) می‌تواند یکی از عوامل محدودکننده در فازینگ‌های رایج باشد و راهبردهای ساده مبتنی بر راه‌اندازی مجدد (restart strategies) قادر هستند، تاثیر آن را کاهش دهند. با این حال، برنامه‌ریز یا زمان‌بند (scheduler) نمونه ما به‌ صورت یک رابط پایتونی روی ++AFL پیاده‌سازی شده است؛ این پیاده‌سازی برای یک اثبات مفهوم (proof of concept) در سطح آکادمیک کافی است، اما سربار اضافی ایجاد می‌کند. از این رو، کارهای آینده باید منطق راه‌اندازی مجدد را به‌صورت بومی (native) در ++AFL ادغام کنند تا این سربار حذف شود و رویکرد پیشنهادی برای استفاده گسترده‌تر در عمل، کاربردی‌تر و کارآمدتر گردد.

۳.۳ فازینگ سامانه‌های سایبر-فیزیکی اختصاصی (Fuzzing of Proprietary Cyber-Physical Systems)

در حالی که بخش‌های قبلی بر تکنیک‌های فازینگ در حوزه‌های نرم‌افزاری مرسوم متمرکز بودند، بسیاری از سامانه‌های دنیای واقعی فراتر از باینری‌های فضای کاربری (user-space binaries) عمل می‌کنند. به‌طور خاص، سامانه‌های سایبر-فیزیکی اختصاصی (proprietary cyber-physical systems) با چالش‌های منحصربه‌فردی مواجه هستند. این سامانه‌ها به شدت با سخت‌افزار یکپارچه شده‌اند، اغلب فاقد قابلیت‌های مشاهده‌پذیری (introspection) هستند، و تنها رابط‌های محدود یا مستندسازی ‌نشده برای تعامل خارجی ارائه می‌دهند. این شرایط، فازینگ چنین سامانه‌هایی را به‌طور قابل توجهی دشوار می‌سازد.

در این بخش، چالش‌های فازینگ سامانه‌های سایبر-فیزیکی مالکیتی (Proprietary Cyber-Physical Systems) را با استفاده از پهپادهای DJI به‌ عنوان مطالعهٔ موردی بررسی می‌کنیم. موانع کلیدی در مسیر اجرای فرایند فازینگ، شامل بازمیزبانی (Rehosting)، استخراج میان‌افزار (Firmware Extraction)، و قابلیت مشاهده و دسترسی به رابط‌ها (Interface Visibility) را جمع‌بندی کرده و نشان می‌دهیم چرا به‌کارگیری رویکردهای سنتی فازینگ در چنین سامانه‌هایی با دشواری‌های جدی مواجه است. به منظور فازینگ چنین دستگاه‌هایی، ابتدا لازم است آن‌ها به ‌صورت نظام‌مند تحلیل گردند تا سطوح بالقوه حمله (Potential Attack Surfaces) شناسایی شوند؛ به عنوان مثال، نقاطی که یک فازر (Fuzzer) بتواند به آن‌ها متصل شده و فرایند آزمون را آغاز کند.

نقطه شروع طبیعی در چنین سناریویی، دستیابی به میان‌افزار (firmware) و تلاش برای بازمیزبانی (rehosting) آن در یک محیط قابل‌کنترل است [15, 24, 104]. با این حال، در پهپادهای DJI، این مسیر تقریباً در هر مرحله با موانع جدی مواجه می‌شود.

تصاویر میان‌افزار (firmware images) اغلب به ‌صورت مستقیم در دسترس نیستند و استخراج آن‌ها معمولاً نیازمند روش‌هایی در سطح سخت‌افزار، مانند جداسازی و خارج‌کردن تراشه از برد (chip desoldering) یا رهگیری کانال‌های به‌روزرسانی (intercepting update channels) است. حتی در صورتی که تصویر میان‌افزار به ‌دست آید، معمولاً به‌صورت رمزگذاری‌ شده (encrypted) ذخیره شده است. علاوه بر این، حتی اگر رمزگشایی آن نیز امکان‌پذیر باشد، خروجی حاصل معمولاً یک فایل اجرایی منفرد و ساده نیست، بلکه یک سیستم‌عامل کامل (full-fledged operating system) مانند لینوکس (Linux) یا اندروید (Android) است که تعداد باینری فضای کاربری (user-space binaries) را میزبانی می‌کند.

اجرای این مؤلفه‌ها (components) در محیط شبیه‌سازی (emulation) نیز با موانع متعددی همراه است، زیرا عملکرد آن‌ها به مجموعه‌ای از حسگرها، کنترل‌کننده‌ها، و زیرسامانه‌های (subsystems) سخت‌افزاری از دوربین‌ها و شتاب‌سنج‌ها گرفته تا خود کنترل‌کننده پرواز وابسته است. در نبود این مؤلفه‌ها، نرم‌افزار معمولاً از ادامه اجرا خودداری می‌کند و اغلب پیش از آنکه هرگونه ورودی فازینگ به سیستم تزریق شود، با خطا متوقف می‌گردد. علاوه بر این، هنگام تلاش برای فازینگ مستقیم سخت‌افزار در آزمایش‌های ما، دو مشکل عملی دیگر نیز مشاهده شد.

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

دوم، پهپادها در صورتی که برای چندین ساعت بدون جریان هوایی که در هنگام پرواز به‌طور طبیعی وجود دارد روشن بمانند، دچار گرمای بیش از حد (overheating) می‌شوند. این مشکل را می‌توان تا حدی توسط فن‌های هدایت ‌شده (directed fans) برطرف کرد، در حالی که مشکل اول در آزمایش‌های ما به‌ صورت عملیاتی و از طریق تعویض و شارژ مجدد باتری‌ها مدیریت می‌شود. گذشته از این ملاحظات عملیاتی، چالش‌های بنیادی‌تر مربوط به نحوه‌ی فازینگ دستگاه است.

ما دستگاه را به‌ منظور شناسایی رابط‌های قابل دسترس (accessible interfaces) مورد بررسی قرار دادیم و مشاهده کردیم که پهپادهای DJI از یک پروتکل ارتباطی اختصاصی (proprietary communication protocol) بر بستر رابط USB استفاده می‌کنند که قابلیت دریافت ورودی را دارد. با این حال، در این مرحله نیز چالش‌های جدیدی مطرح می‌شوند: ورودی‌های پذیرفته شده توسط این پروتکل مستندسازی نشده‌اند، بازخورد دریافتی از دستگاه بسیار محدود بوده و یا در برخی موارد اصلا وجود ندارند، و دستگاه ممکن است داده‌های ناقص (malformed data) را بدون هیچ اثر جانبی قابل مشاهده‌ای بی‌سروصدا رد کند.

این محدودیت‌ها، زمینه روش‌شناختی (methodological backdrop) پژوهش حاضر را شکل می‌دهند؛ چارچوبی که در آن پهپادهای شرکت DJI به‌ عنوان یک مطالعه موردی گویا مورد استفاده قرار می‌گیرند.

۳.۳.۱ نتایج کلیدی (Key Results)

برای غلبه بر چالش‌های مطرح ‌شده، بخش‌هایی از میان‌افزار (firmware) را مهندسی معکوس (reverse engineering) کردیم و با بهره‌گیری از اطلاعات عمومی موجود درباره پروتکل DUML (DJI Universal Markup Language) [31, 78]یک فازر مبتنی بر سخت‌افزار-در-حلقه (hardware-in-the-loop fuzzer) اختصاصی توسعه دادیم.

نمای کلی مؤلفه‌های مختلف حلقه فازینگ (fuzzing loop) در شکل ۳.۱۰ نشان داده شده است. فازر از ساختار پروتکلDUML آگاه است و بسته‌های DUML ناقص یا ناهنجار (malformed DUML packets) تولید می‌کند. این بسته‌ها سپس از طریق رابط USB به پهپاد ارسال می‌شوند. (۱) میان‌افزار (firmware) پهپاد در مرحله نخست، فرایند تجزیه و تحلیل (parsing) را انجام می‌دهد که شامل بررسی ساختار بسته و اعتبارسنجی مقدار جمع‌آزمای (checksum) CRC پیش از ادامه پردازش است. برای عبور از این مرحله تجزیه، بسته‌های تولید شده باید هم دارای ساختار معتبر و هم مقدار جمع‌آزمای (checksum) صحیح باشند. شکل ۳.۹ ساختار یک بسته DUML را نمایش می‌دهد و فیلدهای اصلی و کلیدی (key fields) آن را برجسته می‌کند.

همان‌طور که در شکل نشان داده شده است، چندین فیلد برای مشخص‌کردن فرستنده، گیرنده، و دستور قابل اجرا تعریف شده‌اند. از آنجا که بسته‌های DUML به‌ صورت صریح اجزای فرستنده و گیرنده را نام‌گذاری می‌کنند، این پروتکل امکان تعامل با زیرسامانه‌های مختلفی مانند دوربین، کنترل‌کننده پرواز و سایر ماژول‌ها (modules) را فراهم می‌سازد. به منظور حفظ اعتبار نحوی (syntactic validity) بسته‌ها، فازر تنها فیلدهای مشخصی را دچار جهش (mutation) می‌کند؛ از جمله فیلدهای منبع (source)، مقصد (destination)، نوع دستور (command type)، مجموعه دستور (command set)، شناسه دستور (command id) و پیلود (payload). سایر فیلدها با مقادیر صحیح و معتبر مقداردهی می‌شوند تا ساختار کلی بسته همچنان مطابق انتظار سیستم باقی بماند.

یکی از چالش‌های اصلی در این زمینه، به‌دست آوردن بازخورد عملی و قابل‌استفاده (actionable feedback) در حین فرایند فازینگ است. فازر می‌تواند برخی بررسی‌های ابتدایی را مستقیماً روی پهپاد انجام دهد؛ برای مثال، ارسال دوره‌ای پیام‌های ping از طریق رابط USB جهت (۳) بررسی پاسخ‌گو بودن دستگاه. این نوع بازخورد سبک (lightweight feedback) را می‌توان با دفعات بالا و سرعت زیاد اجرا کرد، اما در مقابل، هیچ اطلاعاتی درباره وضعیت‌های خطا (error states) یا رفتارهای تعریف ‌نشده (undefined behavior) در اختیار فازر قرار نمی‌دهد.

به منظور دریافت بازخورد غنی‌تر، از کنترل کننده از راه دور (remote controller) و اپلیکیشن موبایل همراه به‌عنوان یک (۲) اوراکل باگ (bug oracle) استفاده کردیم؛ در حالی که هر دو از طریق پروتکل ارتباطی اختصاصی OcuSync (به بخش 2.3.2.3 مراجعه شود) به پهپاد متصل هستند. به‌ طور مشخص، یک (۴) خزنده رابط کاربری (UI crawler) روی یک دستگاه اندرویدی که اپلیکیشن DJI را اجرا می‌کند، پیاده‌سازی شده است. این خزنده به ‌صورت خودکار رابط کاربری را پیمایش می‌کند، انحراف از حالت‌های پیش‌فرض را شناسایی و پیام‌های هشدار یا رفتارهای غیرعادی را علامت‌گذاری می‌کند.

این روش امکان شناسایی دستورهای DUML را فراهم کرد که موجب تغییرات غیرمنتظره در رابط کاربری یا بروز خطاهای سیستمی می‌شدند. با این حال، این رویکرد، سربار قابل‌توجهی (significant overhead) به همراه داشت؛ زیرا بازتولید و تأیید چنین خطاهایی اغلب موجب توقف چند دقیقه‌ای در فرایند فازینگ می‌شدند. فازر ما با استفاده هم‌زمان از مکانیزم بازخورد (feedback mechanism) و ساختار آگاه از پروتکل (protocol-aware structure)، موفق به کشف ۱۶ آسیب‌پذیری شد. از این میان، سه مورد از طریق تغییرات غیرعادی در رابط کاربری (UI) شناسایی شدند و بخش عمده موارد دیگر از طریق رخدادهای قطع اتصال USB به‌ دست آمد که موجب راه‌اندازی مجدد پهپاد می‌شدند.

یکی از مشکلات بحرانی زمانی شناسایی شد که سرور ADB (Android Debug Bridge) به ‌طور غیرمنتظره روی پهپاد در دسترس قرار گرفت و از طریق زنجیره‌ای از دستورات فعال گردید. از آنجا که ADB توسط سازنده برای دیباگ یا همان اشکال‌زدایی (debug) استفاده می‌شود و دسترسی سطح بالا (privileged access) فراهم می‌کند، وجود آن روی یک دستگاه عملیاتی (production device) به‌ عنوان یک آسیب‌پذیری امنیتی شدید تلقی می‌شود.

۳.۳.۲ بحث و محدودیت‌ها (Discussion and Limitations)

بخش قبل، چشم‌اندازی از چالش‌های فازینگ دستگاه‌های پیچیده و اختصاصی در دنیای واقعی را با استفاده از پهپادهای مصرفی شرکت DJI به ‌عنوان نمونه موردی ارائه کرد. مطالعه موردی (case study) ما نشان می‌دهد که فازینگ مبتنی بر سخت‌افزار-در-حلقه (hardware-in-the-loop fuzzing) می‌تواند مسیر عملی و قابل‌اجرا برای تحلیل سامانه‌های سایبر-فیزیکی اختصاصی حتی در شرایطی که کد منبع یا میان‌افزار (firmware) قابل دسترس نیست، فراهم کند. ما با بررسی نظام‌مند سطوح حمله (attack surfaces) و ترکیب چندین راهبرد بازخورد، موفق به شناسایی چندین آسیب‌پذیری‌ در یک محصول مصرفی پراستفاده شدیم. رویکرد بازخورد دوگانه (dual-feedback approach) شامل بررسی‌های درشت‌دانه (coarse-grained) از طریق USB و در کنار آن سیگنال‌های غنی‌تر مبتنی بر رابط کاربری (UI) توسط اپلیکیشن همراه، نقش کلیدی در ایجاد تعادل و توازن بین توان عملیاتی (throughput) و عمق تحلیل (depth of analysis) ایفا می‌کند.

با این حال، این روش‌شناسی با برخی محدودیت‌ها مواجه است. این رویکرد به ‌شدت به اکوسیستم شرکت DJI وابسته بوده و نمی‌توان آن را به ‌صورت مستقیم به سایر پلتفرم‌های اختصاصی که فاقد پروتکل ساخت‌یافته‌ای مانند DUML هستند تعمیم داد. بازخورد (feedback) همچنان یک گلوگاه اصلی بود: اگرچه خزنده رابط کاربری (UI crawling) امکان شناسایی وضعیت‌های ظریف‌تر سیستم را فراهم کرد، اما این کار به بهای کاهش سرعت انجام شد و بسیاری از خطاهای نهفته، مانند خرابی‌های خاموش حافظه (silent memory corruptions)، همچنان خارج از دسترس ما باقی ماندند. علاوه بر این، در غیاب ابزارگذاری (instrumentation)، تکنیک‌های رایج فازینگ جعبه خاکستری (greybox fuzzing) مانند جهش ورودی هدایت ‌شده با پوشش کد (coverage-guided input mutation) قابل استفاده نبودند و در نتیجه، فرایند تولید ورودی تا حد زیادی بدون هدایت و کور (blind) باقی ماند.

این محدودیت‌ها چند مسیر بالقوه برای کارهای آینده را نشان می‌دهند. نخست، نیاز به کانال‌های بازخورد غنی‌تر (richer feedback channels) وجود دارد. کانال‌های جانبی مانند مصرف توان (power consumption)، رفتار زمانی (timing behavior) یا الگوهای ارتباطات بی‌سیم (wireless communication patterns) می‌توانند در شرایطی که ابزارگذاری (instrumentation) متداول در دسترس نیست، سیگنال‌های اضافی و مفیدی فراهم کنند.

دوم، رویکردهای هیبریدی (hybrid approaches) که در آن‌ها میزبانی مجدد جزئی (partial rehosting) باینری‌های منفرد یا تجزیه‌کننده‌های پروتکل (protocol parser) با فازینگ سخت‌افزار-در-حلقه ترکیب می‌شوند، می‌توانند ضمن حفظ واقع‌گرایی سیستم، سربار اجرایی را کاهش دهند. در نهایت، اعمال این روش‌شناسی به سایر دسته‌های سامانه‌های سایبر-فیزیکی مانند وسایل نقلیه خودران، تجهیزات پزشکی یا محصولات خانه هوشمند می‌تواند هم تعمیم‌پذیری آن را مورد آزمون قرار دهد و هم چالش‌های خاص هر حوزه را آشکار کند.

۴. نتیجه‌گیری و چشم‌انداز (Conclusions and Outlook)

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

در حالی‌که با توجه به حجم بالای مقالات منتشر شده در حوزه فازینگ، انتظار می‌رود پیشرفت این حوزه از روندی مستمر و رو به رشد برخوردار باشد، نتایج این پژوهش نشان می‌دهد که در مجموع نوعی رکود (stagnation) در آن قابل مشاهده است. ریشه این وضعیت عمدتاً به نرخ پایین پذیرش رویکردهای نوین در ++AFL بازمی‌گردد؛ نرخی که در مقایسه با انتظارات، بسیار کمتر است. این مسئله در تحلیل‌های تکمیلی پژوهش نیز مورد تأیید قرار گرفته و به‌ عنوان یکی از عوامل کلیدی در کندی پیشرفت این حوزه مطرح شده است.

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

دومین مشارکت ما به بررسی پدیده‌ی سایه‌سازی ورودی (input shadowing) و ارائه‌ی یک راهکار ساده برای کاهش آن پرداخت. این پدیده به‌ طور طبیعی از رویکرد مبتنی بر جست‌وجوی نوآوری‌محور (novelty search) ناشی می‌شود که در ++AFL و نسخه‌ی پایه‌ی آن به کار گرفته شده است. ما یک زمان‌بند (Scheduler) معرفی کردیم که در شرایطی که فرایند فازینگ دچار اشباع شده و به حالت سکون می‌رسد،یعنی در یک بهینه محلی (Local Optimum) گرفتار می‌شود، فرآیند را مجدداً راه‌اندازی (Restart) می‌کند. نتایج حاکی از آن است که این راه‌اندازی‌های مجدد می‌توانند اکتشاف فازر در فضای حالت برنامه را متنوع‌تر کنند، امکان کشف ورودی‌های جدید را فراهم سازند و در نهایت منجر به دستیابی به پوشش بیشتر نسبت به خط مبنا شوند. در این زمینه، مسیر امیدوارکننده‌ای برای کارهای آتی، بهبود نحوه برخورد جست‌وجوی جدید با ورودی‌های تکراری (redundant inputs) وجود دارد. در رویکردهای فعلی مبتنی بر جست‌وجوی جدید (novelty search)، نخستین ورودی که یک ناحیه از کد را اجرا می‌کند نگه داشته می‌شود، در حالی که ورودی‌های بعدی که همان پوشش را به دست می‌آورند حذف (کنار گذاشته) می‌شوند. با این حال، این ورودی‌های دیرتر کشف ‌شده ممکن است با وجود پوشش یکسان، از نظر پتانسیل جهش (mutation potential) قوی‌تر باشند و در نتیجه بتوانند به کشف رفتارهای جدیدتری منجر شوند.

فازر به‌ جای کنار گذاشتن کامل ورودی‌های قدیمی‌تر، می‌تواند به‌ صورت دوره‌ای ورودی‌های قدیمی موجود در مجموعه ورودی (corpus) را با ورودی‌های جدیدتر و مناسب‌تر برای جهش (mutation-friendly) جایگزین کند. این رویکرد می‌تواند بدون نیاز به راه‌اندازی مجدد کامل، اثر سایه‌سازی ورودی (input shadowing) را کاهش دهد. ایده‌ی مرتبط دیگر، کشف مجدد انتخابی (selective rediscovery) از طریق هرس کردن ورودی‌های بیت‌مپ (bitmap) است. در این حالت، اگر یک ورودی بعداً دوباره یک یال (edge) حذف‌ شده را فعال کند، به‌ عنوان ورودی جدید تلقی شده و مجدد به مجموعه ورودی (corpus) اضافه می‌شود. چنین مکانیزمی می‌تواند بین مزایا و نقاط قوت جست‌وجوی جدید و فرصت‌های بهتر برای اکتشاف، تعادل برقرار کند.

در نهایت، سومین مشارکت ما یک مطالعه موردی درباره عملی بودن و چالش‌های به‌کارگیری فازینگ در دستگاه‌های پیچیده دنیای واقعی ارائه می‌دهد که با استفاده از پهپادهای شرکت DJI به‌ عنوان نمونه بررسی شده است. این چالش‌ها شامل دسترسی‌ناپذیری میان‌افزار (inaccessible firmware) و همچنین کانال‌های بازخورد محدود یا ابتدایی هستند. به منظور مقابله با این مسائل، یک فازر مبتنی بر سخت‌افزار-در-حلقه (hardware-in-the-loop) توسعه دادیم که از طریق USB و با استفاده از یک پروتکل مهندسی معکوس ‌شده، ورودی‌ها را به سیستم پهپاد تزریق می‌کند. این تنظیمات در ترکیب با یک مکانیزم بازخورد که رابط کاربری اپلیکیشن همراه را پایش می‌کند، توانست آسیب‌پذیری‌های متعددی را در دستگاه‌های آزمایش‌ شده شناسایی کند.

اگرچه پیاده‌سازی این رویکرد به‌طور قابل توجهی وابسته به هدف و فروشنده (target- and vendor-specific) است، اما روش‌شناسی کلی و طراحی سازوکار بازخورد (Feedback Design) آن به‌ صورت گسترده برای سایر سامانه‌های پیچیده و مالکیتی قابل تعمیم و اجرا است. علاوه بر این، رویکردهای موجود مانند میزبانی مجدد (Rehosting) هنوز برای پهپادها یا دستگاه‌های مشابه با پیچیدگی بالا که از شامل چندین زیرسامانه و میان‌افزارهای ناهمگون (Heterogeneous Firmware) هستند، قابل استفاده نیستند، موضوعی که نشان‌ دهنده یک فرصت مهم برای پژوهش‌های آتی در این حوزه است.

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

مشارکت‌های آکادمیک اغلب بر معیار‌ها، آزمایش‌های مصنوعی و فرضیات نظری متکی هستند. با این حال، انتقال این دانش به عمل در بسیاری از موارد با شکست مواجه می‌شود. یک فازر که در یک معیار مشخص عملکرد بهتری نسبت به سایرین دارد، مکن است تنها در آن محیط مصنوعی موفق شود، در حالی که در عمل، حتی در همان اهداف، هیچ بهبود معنادار و حائز اهمیتی را نشان نمی‌دهد. علاوه بر این، تکنیک‌های فازینگ معمولاً بر مجموعه‌ای از فرضیات ضمنی درباره هدف و محیط اجرای آن متکی هستند؛ فرضیاتی که موجب می‌شوند تطبیق این روش‌ها با سیستم‌های پیچیده‌تر، مانند سخت‌افزارها یا دستگاه‌های نهفته (embedded devices) دشوار شود.

در مقابل، زمانی که پژوهشگران بر کاربردپذیری عملی (practical relevance) تمرکز می‌کنند (برای مثال با ترکیب تکنیک‌های موجود به‌ منظور امکان‌پذیر ساختن فازینگ یک کلاس جدید از اهداف)، کار آنها گاهی اوقات در ارزیابی‌های دانشگاهی کمتر بدیع و نوآورانه تلقی می‌شود. با این حال، حتی گام‌های کوچک و تدریجی نیز می‌توانند الهام‌بخش مسیرهای پژوهشی جدید برای دیگران باشند. در نهایت، هدف اصلی پژوهش در حوزه فازینگ بایستی بررسی و توسعه روش‌های جدید برای کشف آسیب‌پذیری‌ها (vulnerabilities) باشد.

چنانچه یک تکنیک بتواند منجر به کشف باگ‌های جدید شود و در نتیجه اثر عملی (practical impact) خود را نشان دهد (حتی گر بر ترکیبی از ایده‌های موجود بنا شده باشد) چنین کاری مسلماً ارزشمندتر از رویکردهای ظاهراً بدیع اما غیرعملی است.

برای دستیابی به این هدف، جامعه پژوهشی فازینگ نیازمند شاخص‌ها (metrics) و روش‌شناسی‌های (methodologies) بهتری است تا بتواند فازرهای جدید را به ‌صورت عینی و منصفانه در مقایسه با تکنیک‌های موجود ارزیابی کند. یکی از رویکردهای ممکن، برگزاری رقابت‌های دوره‌ای (regular competitions) است که در آن ابزارهای مختلف روی مجموعه‌ای مشترک از اهداف دنیای واقعی یا تحت شرایط از پیش تعریف‌ شده آزمایش شوند. رقابت‌های مشابه پیش‌تر در حوزه‌های علمی مرتبط مانند راستی‌آزمایی نرم‌افزار (software verification) و بررسی مدل (model checking) نیز برگزار شده‌اند [76, 118].

این یافته‌ها هم دستاوردها و هم محدودیت‌های پژوهش‌های فعلی در حوزه فازینگ را برجسته می‌کنند و زمینه‌ای برای تأمل درباره آینده این حوزه فراهم می‌سازند. به نظر می‌رسد در سال‌های اخیر، پژوهش در فازینگ وارد مرحله‌ای از سکون (plateau) شده است. سکونی که ما در ++AFL مشاهده کردیم، نشانه‌ای از یک روند گسترده‌تر است، چرا که هم نمونه‌های اولیه دانشگاهی و هم ابزارهای صنعتی مانند Fuzzilli پیشرفت‌های رو به کاهشی را نشان می‌دهند.

این موضوع صرفاً به کمبود پذیرش یا استفاده از تکنیک‌های جدید محدود نمی‌شود، بلکه نشان می‌دهد فازینگ مبتنی بر بازخورد (feedback-driven fuzzing) ممکن است به محدودیت‌های خود نزدیک شده باشد؛ به این معنا که «میوه‌های در دسترس‌تر» (low-hanging fruits) تا حد زیادی برداشت شده‌اند و دستاوردهای قابل توجه در پوشش به طور فزاینده‌ای نادر هستند. آخرین پیشرفت بنیادین در این حوزه، معرفی بازخورد پوششی سبک (lightweight coverage feedback) در AFL بود که پایه‌گذار یک دهه پیشرفت بعدی شد. از آن زمان تاکنون، عمدتاً شاهد بهبودهای تدریجی و ویژگی‌های افزایشی بوده‌ایم، بدون آنکه نوآوری‌های تحول‌آفرین (disruptive innovations) در ‌سطح آن ظهور کرده باشد. برای عبور از این سقف، این حوزه اساسا به مسیرهای کاملاً جدیدی نیاز دارد؛ چه از طریق سیگنال‌های بازخورد جایگزین، چه از طریق اوراکل‌های باگ (bug oracles)، و چه حتی از طریق الگوهای کاملاً متفاوت در فازینگ.

در سال‌های اخیر، حوزه گسترده‌تر آزمون نرم‌افزار (software testing) به ‌طور فزاینده‌ای به سمت استفاده از یادگیری ماشین (machine learning) و رویکردهای مبتنی بر شبکه‌های عصبی (neural network) برای هدایت اکتشاف و خودکارسازی تصمیم‌گیری حرکت کرده است. تلاش‌های اولیه برای به‌کارگیری چنین روش‌هایی در فازینگ مانند استنباط دستورزبان (grammar inference) یا استفاده از یادگیری تقویتی (reinforcement learning) برای استراتژی‌های جهش تنها به بهبودهای تدریجی منجر شدند [89].

با این حال، در سال‌های اخیر پژوهش‌ها به بررسی پتانسیل مدل‌های زبانی بزرگ (large language models- LLMs) برای کمک به فازینگ پرداخته‌اند. این مدل‌ها قادرند ورودی‌های ساخت‌یافته تولید کنند، معناشناسی ضمنی برنامه‌ها را استنتاج و ساخت درایورهای آزمون را خودکارسازی کنند؛ در نتیجه، بخشی از کارهای دستی که پیش‌تر مانع مقیاس‌پذیری بودند کاهش یافته است.

اگرچه نتایج فعلی هنوز اولیه هستند، اما این مدل‌ها مسیرهای جدیدی را برای ترکیب استدلال معنایی (semantic reasoning) با کاوش هدایت ‌شده با بازخورد (feedback-guided exploration) باز می‌کنند [79, 133, 136, 140]. تا زمانی که چنین پیشرفت‌های بنیادی به ثمر برسند، به نظر می‌رسد مسیر اصلی پیشرفت در توسعه فازرهای مختص دامنه (domain-specific fuzzers) باشد که به‌جای تمرکز بر بهبود فازرهای عمومی و همه منظوره (General-Purpose Fuzzers)، کلاس‌های مشخصی از سامانه‌ها را مورد هدف قرار می‌دهند.

منابع

				
					[1] akihe. Radamsa – Fuzzer for Testing Software by Generating Inputs from Sample Data. https://gitlab.com/akihe/radamsa. Accessed: January 20, 2026. 
[2] Cornelius Aschermann, Tommaso Frassetto, Thorsten Holz, Patrick Jauernig, Ahmad-Reza Sadeghi, and Daniel Teuchert. NAUTILUS: Fishing for Deep Bugs with Grammars. In Network and Distributed System Security (NDSS) Symposium, 2019.
[3] Cornelius Aschermann, Sergej Schumilo, Ali Abbasi, and Thorsten Holz. Ijon: Exploring Deep State Spaces via Fuzzing. In IEEE Symposium on Security and Privacy (S&P), 2020.
[4] Cornelius Aschermann, Sergej Schumilo, Tim Blazytko, Robert Gawlik, and Thorsten Holz. REDQUEEN: Fuzzing with Input-to-State Correspondence. In Network and Distributed System Security (NDSS) Symposium, 2019.
[5] Kesina Baral, John Johnson, Junayed Mahmud, Sabiha Salma, Mattia Fazzini, Julia Rubin, Jeff Offutt, and Kevin Moran. Automating GUI-based Test Oracles for Mobile Apps. In Proceedings of the 21st International Conference on Mining Software Repositories, 2024.
[6] Earl T Barr, Mark Harman, Phil McMinn, Muzammil Shahbaz, and Shin Yoo. The Oracle Problem in Software Testing: A Survey. IEEE transactions on software engineering, 41(5):507–525, 2014.
[7] Nils Bars, Moritz Schloegel, Tobias Scharnowski, Nico Schiller, and Thorsten Holz. Fuzztruction: Using Fault Injection-based Fuzzing to Leverage Implicit Domain Knowledge. In USENIX Security Symposium, 2023.
[8] Nils Bars, Moritz Schloegel, Nico Schiller, Lukas Bernhard, and Thorsten Holz. No Peer, No Cry: Network Application Fuzzing via Fault Injection. In ACM Conference on Computer and Communications Security (CCS), 2024.
[9] Battelle. afl-unicorn - AFL with Unicorn CPU emulator support. https://github.com/Battelle/afl-unicorn. Accessed: January 20, 2026.
[10] BBC. Gatwick Airport: Drones ground flights. https://www.bbc.com/news/uk-england-sussex-46623754, 2018.
[11] Bachir Bendrissou, Rahul Gopinath, and Andreas Zeller. “Synthesizing Input Grammars”: A Replication Study. In ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI), 2022.
[12] Andrew R. Bernat and Barton P. Miller. Anywhere, Any-time Binary Instrumentation. In ACM SIGPLAN-SIGSOFT Workshop on Program Analysis for Software Tools (PASTE), 2011.
[13] Lukas Bernhard, Tobias Scharnowski, Moritz Schloegel, Tim Blazytko, and Thorsten Holz. JIT-Picking: Differential Fuzzing of JavaScript Engines. In ACM Conference on Computer and Communications Security (CCS), 2022.
[14] Lukas Bernhard, Nico Schiller, Moritz Schloegel, Nils Bars, and Thorsten Holz. DarthShader: Fuzzing WebGPU Shader Translators & Compilers. In Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, 2024.
[15] Moritz Bley, Tobias Scharnowski, Simon Wörner, Moritz Schloegel, and Thorsten Holz. Protocol-Aware Firmware Rehosting for Effective Fuzzing of Embedded Network Stacks. In ACM Conference on Computer and Communications Security (CCS), 2025.
[16] Marcel Böhme, Van-Thuan Pham, and Abhik Roychoudhury. Coverage-based Greybox Fuzzing as Markov Chain. In ACM Conference on Computer and Communications Security (CCS), 2016.
[17] Julian Borger. The drone operators who halted Russian convoy headed for Kyiv. https://www.theguardian.com/world/2022/mar/28/the-drone-operators-who-halted-the-russian-armoured-vehicles-heading-for-kyiv, 2022.
[18] busybox.net. BusyBox. https://busybox.net/. Accessed: January 20, 2026. 
[19] Marcel Böhme, Valentin J. M. Manès, and Sang Kil Cha. Boosting Fuzzer Efficiency: An Information Theoretic Perspective. In ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE), 2020.
[20] Cristian Cadar, Daniel Dunbar, and Dawson R Engler. KLEE: Unassisted and Automatic Generation of High-Coverage Tests for Complex Systems Programs. In Symposium on Operating Systems Design and Implementation (OSDI), 2008.
[21] Justin Campbell and Mike Walker. Microsoft announces new Project One-Fuzz framework, an open source developer tool to find and fix bugs at scale. https://www.microsoft.com/en-us/security/blog/2020/09/15/microsoft-onefuzz-framework-open-source-developer-tool-fix-bugs/,2020.
[22] Jiongyi Chen, Wenrui Diao, Qingchuan Zhao, Chaoshun Zuo, Zhiqiang Lin, XiaoFeng Wang, Wing Cheong Lau, Menghan Sun, Ronghai Yang, and Kehuan Zhang. IoTFuzzer: Discovering Memory Corruptions in IoT Through App-based Fuzzing. In Network and Distributed System Security (NDSS) Symposium, 2018.
[23] Peng Chen and Hao Chen. Angora: Efficient Fuzzing by Principled Search. In IEEE Symposium on Security and Privacy (S&P), 2018.
[24] Abraham A. Clements, Eric Gustafson, Tobias Scharnowski, Paul Grosen, David Fritz, Christopher Kruegel, Giovanni Vigna, Saurabh Bagchi, and Mathias Payer. HALucinator: Firmware Re-hosting Through Abstraction Layer Emulation. In USENIX Security Symposium, 2020.
[25] Federal Communications Commission. FCC ID SS3-MT2WD2007. https:// fccid.io/SS3-MT2WD2007. Accessed: January 20, 2026. 
[26] Jared DeMott, Richard Enbody, and William F Punch. Revolutionizing the Field of Grey-box Attack Surface Testing with Evolutionary Fuzzing. BlackHat and Defcon, 2007.
[27] DHL. Future of Freight: The Use of Drones in Logistics. https://dhl-freight-connections.com/en/solutions/future-of-freight-the-use-of-drones-in-logistics/. Accessed: January 20, 2026.
[28] Sushant Dinesh, Nathan Burow, Dongyan Xu, and Mathias Payer. RetroWrite:Statically Instrumenting COTS Binaries for Fuzzing and Sanitization. In IEEE Symposium on Security and Privacy (S&P), 2020.
[29] DJI. DJI AeroScope. https://www.dji.com/aeroscope. Accessed: January 20, 2026.
[30] DJI. DJI Mavic 3 - Specs. https://www.dji.com/mavic-3/specs. Accessed: January 20, 2026.
[31] DJI-SDK. Onboard-SDK. https://github.com/dji-sdk/Onboard-SDK/blob/master/osdk-core/advanced-sensing/ori-osdk-core/protocol/inc/dji_crc.hpp, 2020.
[32] DJI.com. DJI Airsense. https://www.dji.com/flysafe/airsense. Accessed: January 20, 2026.
[33] Max Eisele, Daniel Ebert, Christopher Huth, and Andreas Zeller. Fuzzing Embedded Systems using Debug Interfaces. In Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis, 2023.
[34] DJI Enterprise. DJI Enterprise - Geospacial. https://enterprise.dji.com/ geospatial. Accessed: January 20, 2026.
[35] DJI Enterprise. DJI Enterprise - Public Safety. https://enterprise.dji.com/public-safety. Accessed: January 20, 2026.
[36] Mattia Fazzini and Alessandro Orso. Automated Cross-platform Inconsistency Detection for Mobile Apps. In 2017 32nd IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 2017.
[37] Bo Feng, Alejandro Mera, and Long Lu. P2IM: Scalable and Hardware-independent Firmware Testing via Automatic Peripheral Interface Modeling. In USENIX Security Symposium, 2020.
[38] Xiaotao Feng, Ruoxi Sun, Xiaogang Zhu, Minhui Xue, Sheng Wen, Dongxi Liu, Surya Nepal, and Yang Xiang. Snipuzz: Black-box Fuzzing of IoT Firmware via Message Snippet Inference. In ACM Conference on Computer and Communications Security (CCS), 2021.
[39] Andrea Fioraldi, Daniele Cono D’Elia, and Davide Balzarotti. The Use of Likely Invariants as Feedback for Fuzzers. In USENIX Security Symposium, 2021.
[40] Andrea Fioraldi, Daniele Cono D’Elia, and Leonardo Querzoni. Fuzzing Binaries for Memory Safety Errors with QASan. In 2020 IEEE Secure Development (SecDev). IEEE, 2020.
[41] Andrea Fioraldi, Dominik Maier, Heiko Eißfeldt, and Marc Heuse. AFL++: Combining Incremental Steps of Fuzzing Research. In USENIX Workshop on Offensive Technologies (WOOT), 2020.
[42] Andrea Fioraldi, Dominik Christian Maier, Dongjia Zhang, and Davide Balzarotti. LibAFL: A Framework to Build Modular and Reusable Fuzzers. In ACM Conference on Computer and Communications Security (CCS), 2022.
[43] Andrea Fioraldi, Alessandro Mantovani, Dominik Maier, and Davide Balzarotti. Dissecting American Fuzzy Lop: A Fuzzbench Evaluation. ACM Transactions on Software Engineering and Methodology (TOSEM), 32(2):1–26, 2023.
[44] Andres Freund. Backdoor in upstream xz/liblzma leading to ssh server compromise. https://www.openwall.com/lists/oss-security/2024/03/29/4,2024.
[45] Vijay Ganesh, Tim Leek, and Martin Rinard. Taint-based Directed Whitebox Fuzzing. In International Conference on Software Engineering (ICSE), 2009.
[46] Patrice Godefroid, Adam Kiezun, and Michael Y. Levin. Grammar-based White-box Fuzzing. In ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI), 2008.
[47] Patrice Godefroid, Michael Y Levin, and David Molnar. SAGE: Whitebox Fuzzing for Security Testing. Communications of the ACM (CACM), 55(3):40–44, 2012.
[48] Patrice Godefroid, Michael Y Levin, David A Molnar, et al. Automated Whitebox Fuzz Testing. In Ndss, 2008.
[49] Google. American Fuzzy Lop. https://github.com/google/AFL. Accessed: January 20, 2026.
[50] Google. OSS-Fuzz: Continuous Fuzzing for Open Source Software. https://github.com/google/oss-fuzz.
[51] Google Project Zero. CompareCoverage. https://github.com/googleprojectzero/CompareCoverage, 2019.
[52] Samuel Groß, Simon Koch, Lukas Bernhard, Thorsten Holz, and Martin Johns. FUZZILLI: Fuzzing for JavaScript JIT Compiler Vulnerabilities. In Network and Distributed System Security (NDSS) Symposium, 2023.
[53] The Guardian. Saudis behind NSO spyware attack on Jamal Khashoggi’s family, leak suggests. https://www.theguardian.com/world/2021/jul/18/nso-spyware-used-to-target-family-of-jamal-khashoggi-leaked-data-shows-saudis-pegasus, 2021.
[54] The Guardian. Slow recovery from IT outage begins as experts warn of futurerisks. https://www.theguardian.com/australia-news/article/2024/jul/19/microsoft-windows-pcs-outage-blue-screen-of-death, 2024.
[55] Emre Güler, Cornelius Aschermann, Ali Abbasi, and Thorsten Holz. AntiFuzz: Impeding Fuzzing Audits of Binary Executables. In USENIX Security Symposium, 2019.
[56] David Hambling. How Small Drones Could Win The Fight In Ukraine’s Cities (And The Truth About That Anti-Drone Pickle Jar Story). https://www.forbes.com/sites/davidhambling/2022/03/08/how-small-drones-could-win-the-fight-in-ukraines-cities-and-the-truth-about-that-anti-drone-pickle-jar-story/, 2022.
[57] Kenneth V. Hanford. Automatic Generation of Test Cases. IBM Systems Journal, 9(4):242–257, 1970.
[58] Ahmad Hazimeh, Adrian Herrera, and Mathias Payer. Magma: A Ground-Truth Fuzzing Benchmark. ACM on Measurement and Analysis of Computing Systems (POMACS), 4(3):49:1–49:29, 2020.
[59] Adrian Herrera, Hendra Gunadi, Shane Magrath, Michael Norrish, Mathias Payer, and Antony L Hosking. Seed Selection for Successful Fuzzing. In International Symposium on Software Testing and Analysis (ISSTA), 2021. 
[60] Adrian Herrera, Mathias Payer, and Antony L. Hosking. DatAFLow: Toward a Data-Flow-Guided Fuzzer. ACM Transactions on Software Engineering and Methodology (TOSEM), 32(5), 2023. 
[61] Marc Heuse, Dominik Maier, Andrea Fioraldi, and Heiko Eissfeldt. American Fuzzy Lop plus plus (AFL++). https://github.com/AFLplusplus/AFLplusplus.
[62] Chin-Chia Hsu, Che-Yu Wu, Hsu-Chun Hsiao, and Shih-Kun Huang. Instrim: Lightweight Instrumentation for Coverage-guided Fuzzing. In Symposium on Network and Distributed System Security (NDSS), Workshop on Binary Analysis Research, 2018.
[63] Jaewon Hur, Suhwan Song, Dongup Kwon, Eunjin Baek, Jangwoo Kim, and Byoungyoung Lee. DifuzzRTL: Differential Fuzz Testing to Find CPU Bugs. In IEEE Symposium on Security and Privacy (S&P), 2021.
[64] Amnesty International. Serbia: Authorities using spyware and Cellebrite forensic extraction tools to hack journalists and activists . https://www.amnesty.org/en/latest/news/2024/12/serbia-authorities-using-spyware-and-cellebrite-forensic-extraction-tools-to-hack-journalists-and-activists/, 2024.
[65] Jinho Jung, Hong Hu, David Solodukhin, Daniel Pagan, Kyu Hyung Lee, and Taesoo Kim. Fuzzification: Anti-Fuzzing Techniques. In USENIX Security Symposium, 2019.
[66] Ben Kesslen. Ukrainians develop drone that drops Molotov cocktails. https://nypost.com/2022/03/10/ukrainians-develop-drone-that-drops-molotov-cocktails/, 2022.
[67] George Klees, Andrew Ruef, Benji Cooper, Shiyi Wei, and Michael Hicks. Evaluating Fuzz Testing. In ACM Conference on Computer and Communications Security (CCS), 2018.
[68] Jason R Koenig, Oded Padon, and Alex Aiken. Adaptive Restarts for Stochastic Synthesis. In ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI), 2021.
[69] Ziqiao Kong, Shaohua Li, Heqing Huang, and Zhendong Su. Sand: Decoupling Sanitization from Fuzzing for Low Overhead. In International Conference on Software Engineering (ICSE), 2025.
[70] Joel Lehman and Kenneth O Stanley. Abandoning Objectives: Evolution Through the Search for Novelty Alone. Evolutionary computation, 19(2):189–223, 2011.
[71] Joel Lehman, Kenneth O Stanley, et al. Exploiting Open-endedness to Solve Problems Through the Search for Novelty. In ALIFE, 2008.
[72] Caroline Lemieux and Koushik Sen. FairFuzz: A Targeted Mutation Strategy for Increasing Greybox Fuzz Testing Coverage. In ACM/IEEE International Conference on Automated Software Engineering (ASE), 2018.
[73] LLVM. SanitizerCoverage. https://clang.llvm.org/docs/ SanitizerCoverage.html. Accessed: January 20, 2026.
[74] Chenyang Lyu, Shouling Ji, Chao Zhang, Yuwei Li, Wei-Han Lee, Yu Song, and Raheem Beyah. MOPT: Optimized Mutation Scheduling for Fuzzers. In USENIX Security Symposium, 2019.
[75] Matteo Marini, Daniele Cono D’Elia, Mathias Payer, Leonardo Querzoni, et al.QMSan: Efficiently Detecting Uninitialized Memory Errors During Fuzzing. In Proceedings of the Network and Distributed System Security (NDSS) Symposium 2025, 2025.
[76] mcc.lip6.fr. Model Checking Contest 2025. https://mcc.lip6.fr/2025/. Accessed: January 20, 2026.
[77] Original Gangsters Mefistotelis. comm_mkdupc.py. https://github.com/o-gs/dji-firmware-tools/blob/master/comm_mkdupc.py, 2019.
[78] Original Gangsters Mefistotelis. DJI-Firmware-Tools. https://github.com/o-gs/dji-firmware-tools, 2021.
[79] Ruijie Meng, Martin Mirchev, Marcel Böhme, and Abhik Roychoudhury. Large Language Model Guided Protocol Fuzzing. In Proceedings of the 31st Annual Network and Distributed System Security Symposium (NDSS), volume 2024, 2024.
[80] Barton P. Miller, Lars Fredriksen, and Bryan So. An Empirical Study of the Reliability of UNIX Utilities. Communications of the ACM (CACM), 33(12):32–44,1990.
[81] Marius Muench, Jan Stijohann, Frank Kargl, Aurélien Francillon, and Davide Balzarotti. What You Corrupt Is Not What You Crash: Challenges in Fuzzing Embedded Devices. In Network and Distributed System Security (NDSS) Symposium, 2018.
[82] Stefan Nagy and Matthew Hicks. Full-Speed Fuzzing: Reducing Fuzzing Overhead through Coverage-Guided Tracing. In IEEE Symposium on Security and Privacy (S&P), 2019.
[83] Stefan Nagy, Anh Nguyen-Tuong, Jason D. Hiser, Jack W. Davidson, and Matthew Hicks. Breaking Through Binaries: Compiler-quality Instrumentation for Better Binary-only Fuzzing. In USENIX Security Symposium, 2021.
[84] Stefan Nagy, Anh Nguyen-Tuong, Jason D. Hiser, Jack W. Davidson, and Matthew Hicks. Same Coverage, Less Bloat: Accelerating Binary-only Fuzzing with Coverage-preserving Coverage-guided Tracing. In ACM Conference on Computer and Communications Security (CCS), 2021.
[85] Ben Nassi, Raz Ben-Netanel, Adi Shamir, and Yuval Elovici. Drones’ Cryptanalysis - Smashing Cryptography with a Flicker. In IEEE Security & Privacy, 2019.
[86] BBC News. Drugs, weapons ’smuggled to prisoners by drone’. https://www.bbc.com/news/world-us-canada-60262715, 2022.
[87] The Hacker News. Meta Confirms Zero-Click WhatsApp Spyware Attack Targeting 90 Journalists, Activists. https://thehackernews.com/2025/02/meta-confirms-zero-click-whatsapp.html, 2025.
[88] newsshooter.com / Matthew Allard. DJI stops their drones from being used in Syria and Iraq. https://www.newsshooter.com/2017/04/29/dji-stops-their-drones-from-being-used-in-syria-and-iraq/, 2017.
[89] Maria Irina Nicolae, Max Eisele, and Andreas Zeller. Revisiting Neural Program Smoothing for Fuzzing. In ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE), 2023.
[90] Shirin Nilizadeh, Yannic Noller, and Corina S. Pasareanu. DifFuzz: Differential Fuzzing for Side-channel Analysis. In ACM/IEEE International Conference on Automated Software Engineering (ASE), 2019.
[91] Juhwan Noh, Yujin Kwon, Yunmok Son, Hocheol Shin, Dohyun Kim, Jaeyeong Choi, and Yongdae Kim. Tractor Beam: Safe-Hijacking of Consumer Drones with Adaptive GPS Spoofing. ACM Trans. Priv. Secur., 22(2), 2019.
[92] Yannic Noller, Corina S. Pasareanu, Marcel Böhme, Youcheng Sun, Hoang Lam Nguyen, and Lars Grunske. HyDiff: Hybrid Differential Software Analysis. In ACM/IEEE International Conference on Automated Software Engineering (ASE), 2020.
[93] openwrt.org. Welcome to the OpenWrt Project. https://openwrt.org/. Accessed: January 20, 2026.
[94] Chris Owen. Drone dropping small bomb. https://twitter.com/ChrisO_wiki/status/1520561969153073153, 2022.
[95] Gaoning Pan, Xingwei Lin, Xuhong Zhang, Yongkang Jia, Shouling Ji, Chunming Wu, Xinlei Ying, Jiashui Wang, and Yanjun Wu. V-Shuttle: Scalable and Semantics-Aware Hypervisor Virtual Device Fuzzing. In ACM Conference on Computer and Communications Security (CCS), 2021.
[96] Van-Thuan Pham, Marcel Böhme, Andrew E Santosa, Alexandru Răzvan Căciulescu, and Abhik Roychoudhury. Smart Greybox Fuzzing. IEEE Transactions on Software Engineering, 47(9):1980–1997, 2019.
[97] Sebastian Poeplau and Aurélien Francillon. Symbolic execution with SymCC:Don’t interpret, compile! In USENIX Security Symposium, 2020.
[98] Sebastian Poeplau and Aurélien Francillon. SymQEMU: Compilation-based Symbolic Execution for Binaries. In Network and Distributed System Security (NDSS)Symposium, 2021.
[99] Quarkslab. QBDI - A Dynamic Binary Instrumentation framework. https://github.com/QBDI/QBDI. Accessed: January 20, 2026.
[100] Sanjay Rawat, Vivek Jain, Ashish Kumar, Lucian Cojocar, Cristiano Giuffrida, and Herbert Bos. VUzzer: Application-aware Evolutionary Fuzzing. In Network and Distributed System Security (NDSS) Symposium, 2017.
[101] RICSecLab. coresight-trace - ARM CoreSight-based tracing framework. https://github.com/RICSecLab/coresight-trace. Accessed: January 20, 2026.
[102] Michael S. Rosenwald. Prisons Try to Stop Drones from Delivering Drugs, Porn and Cellphones to Inmates. https://www.washingtonpost.com/local/prisons-try-to-stop-drones-from-delivering-drugs-porn-and-cellphones-to-inmates/2016/10/12/645fb102-800c-11e6-8d0c-fb6c00c90481_story.html, 2016.
[103] Christopher Salls, Chani Jindal, Jake Corina, Christopher Kruegel, and Giovanni Vigna. Token-Level Fuzzing. In USENIX Security Symposium, 2021.
[104] Tobias Scharnowski, Nils Bars, Moritz Schloegel, Eric Gustafson, Marius Muench, Giovanni Vigna, Christopher Kruegel, Thorsten Holz, and Ali Abbasi. Fuzzware: Using Precise MMIO Modeling for Effective Firmware Fuzzing. In USENIX Security Symposium, 2022.
[105] Tobias Scharnowski, Simon Woerner, Felix Buchmann, Nils Bars, Moritz Schloegel, , and Thorsten Holz. Hoedur: Embedded Firmware Fuzzing using Multi-Stream Inputs. In USENIX Security Symposium, 2023.
[106] Joschua Schilling, Andreas Wendler, Philipp Görz, Nils Bars, Moritz Schloegel, and Thorsten Holz. A Binary-level Thread Sanitizer or Why Sanitizing on the Binary Level is Hard. In 33rd USENIX Security Symposium (USENIX Security 24), 2024.
[107] Moritz Schloegel, Nils Bars, Nico Schiller, Lukas Bernhard, Tobias Scharnowski, Addison Crump, Arash Ale Ebrahim, Nicolai Bissantz, Marius Muench, and Thorsten Holz. SoK: Prudent Evaluation Practices for Fuzzing. In IEEE Symposium on Security and Privacy (S&P), 2024.
[108] Sergej Schumilo, Cornelius Aschermann, Ali Abbasi, Simon Wörner, and Thorsten Holz. Nyx: Greybox Hypervisor Fuzzing using Fast Snapshots and Affine Types. In USENIX Security Symposium, 2021.
[109] Sergej Schumilo, Cornelius Aschermann, Robert Gawlik, Sebastian Schinzel, and Thorsten Holz. kAFL: Hardware-assisted Feedback Fuzzing for OS Kernels. In USENIX Security Symposium, 2017.
[110] Sea-Watch.org. Spy attacks on human rights activists. https://sea-watch.org/en/spy-attacks-on-human-rights-activists/, 2025.
[111] Konstantin Serebryany, Derek Bruening, Alexander Potapenko, and Dmitriy Vyukov. AddressSanitizer: A Fast Address Sanity Checker. In USENIX Annual Technical Conference (ATC), 2012.
[112] Ishveena Singh. DroneAnalyst report reveals dramatic drop in DJI’s commercial drone market share . https://dronedj.com/2021/09/14/droneanalyst-dji-market-share-2021/, 2021.
[113] Ishveena Singh. Finnish volunteers deliver 140 DJI Mavic Mini drones to Ukraine military. https://dronedj.com/2022/03/03/finland-140-dji-mini-drone-ukraine-military, 2022.
[114] Antoni Slodkowski, Elaine Lies, and Kiyoshi Takenakac. Olympics-Superstar Osaka lights Flame as Japan’s COVID-hit Games Open. https://www.reuters.com/lifestyle/sports/slimmed-down-ceremony-open-pandemic-hit-tokyo-games-2021-07-23/, 2021.
[115] Daniel Slotta. China’s Thriving Drone Industry. https://www.asiaperspective.com/china-thriving-drone-industry/, 2022.
[116] Yunmok Son, Hocheol Shin, Dongkwan Kim, Youngseok Park, Juhwan Noh, Kibum Choi, Jungwoo Choi, and Yongdae Kim. Rocking Drones with Intentional Sound Noise on Gyroscopic Sensors. In USENIX Security Symposium,2015.
[117] Dokyung Song, Julian Lettner, Prabhu Rajasekaran, Yeoul Na, Stijn Volckaert, Per Larsen, and Michael Franz. SoK: Sanitizing for Security. In 2019 IEEE Symposium on Security and Privacy (SP). IEEE, 2019.
[118] sosy lab.org. Competition on Software Verification (SV-COMP). https://sv-comp.sosy-lab.org/. Accessed: January 20, 2026.
[119] Sherri Sparks, Shawn Embleton, Ryan Cunningham, and Cliff Zou. Automated Vulnerability Analysis: Leveraging Control Flow for Evolutionary Input Crafting. In Annual Computer Security Applications Conference (ACSAC). IEEE, 2007. 
[120] Prashast Srivastava and Mathias Payer. Gramatron: Effective Grammar-aware Fuzzing. In International Symposium on Software Testing and Analysis (ISSTA), 2021.
[121] Evgeniy Stepanov and Konstantin Serebryany. MemorySanitizer: Fast Detector of Uninitialized Memory Use in C++. In IEEE/ACM International Symposium on Code Generation and Optimization (CGO), 2015.
[122] Nick Stephens, John Grosen, Christopher Salls, Andrew Dutcher, Ruoyu Wang, Jacopo Corbetta, Yan Shoshitaishvili, Christopher Kruegel, and Giovanni Vigna. Driller: Augmenting Fuzzing through Selective Symbolic Execution. In Network and Distributed System Security (NDSS) Symposium, 2016.
[123] uclibc.org. uClibc. https://uclibc.org/. Accessed: January 20, 2026.
[124] Unknown Authors. LAF-Intel: Circumventing Fuzzing Roadblocks with Compiler Transformations. https://lafintel.wordpress.com/, 2016.
[125] Jiming Wang, Yan Kang, Chenggang Wu, Yuhao Hu, Yue Sun, Jikai Ren, Yuanming Lai, Mengyao Xie, Charles Zhang, Tao Li, et al. OptFuzz: Optimization Path Guided Fuzzing for JavaScript JIT Compilers. In USENIX Security Symposium, 2024.
[126] Jinghan Wang, Yue Duan, Wei Song, Heng Yin, and Chengyu Song. Be Sensitive and Collaborative: Analyzing Impact of Coverage Metrics in Greybox Fuzzing. In International Symposium on Recent Advances in Intrusion Detection (RAID), 2019.
[127] Jinghan Wang, Chengyu Song, and Heng Yin. Reinforcement learning-based hierarchical seed scheduling for greybox fuzzing. In 28th Annual Network and Distributed System Security Symposium, NDSS 2021, virtually, February 21-25, 2021. The Internet Society, 2021.
[128] Junjie Wang, Bihuan Chen, Lei Wei, and Yang Liu. Superion: Grammar-aware Greybox Fuzzing. In ACM/IEEE International Conference on Automated Software Engineering (ASE), 2019.
[129] Junjie Wang, Zhiyi Zhang, Shuang Liu, Xiaoning Du, and Junjie Chen. FuzzJIT: Oracle-Enhanced Fuzzing for JavaScript Engine JIT Compiler. In USENIX Security Symposium, 2023.
[130] Tielei Wang, Tao Wei, Guofei Gu, and Wei Zou. TaintScope: A Checksum-aware Directed Fuzzing Tool for Automatic Software Vulnerability Detection. In IEEE Symposium on Security and Privacy (S&P), 2010.
[131] David Weston/Microsoft. Helping our customers through the CrowdStrike outage. https://blogs.microsoft.com/blog/2024/07/20/helping-our-customers-through-the-crowdstrike-outage/, 2024.
[132] BBC Tabby Wilson. Copenhagen and Oslo airports forced to close temporarily due to drone sightings. https://www.bbc.com/news/articles/cn4lj1yvgvgo,2025.
[133] Chunqiu Steven Xia, Matteo Paltenghi, Jia Le Tian, Michael Pradel, and Lingming Zhang. Fuzz4all: Universal Fuzzing with Large Language Models. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering, 2024.
[134] Haoran Xu, Zhiyuan Jiang, Yongjun Wang, Shuhui Fan, Shenglin Xu, Peidai Xie, Shaojing Fu, and Mathias Payer. Fuzzing JavaScript Engines with a Graph-based IR. In ACM Conference on Computer and Communications Security (CCS), 2024.
[135] Wen Xu, Hyungon Moon, Sanidhya Kashyap, Po-Ning Tseng, and Taesoo Kim. Fuzzing File Systems via Two-Dimensional Input Space Exploration. In IEEE Symposium on Security and Privacy (S&P), 2019.
[136] Chenyuan Yang, Zijie Zhao, and Lingming Zhang. Kernelgpt: Enhanced Kernel Fuzzing via Large Language Models. In Proceedings of the 30th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2, 2025.
[137] Insu Yun, Sangho Lee, Meng Xu, Yeongjin Jang, and Taesoo Kim. QSYM: A Practical Concolic Execution Engine Tailored for Hybrid Fuzzing. In USENIX Security Symposium, 2018.
[138] Michał Zalewski. American Fuzzy Lop. https://lcamtuf.coredump.cx/afl/,2013.
[139] Google Project Zero. Fuzzilli. https://github.com/googleprojectzero/fuzzilli. Accessed: January 20, 2026.
[140] Cen Zhang, Yaowen Zheng, Mingqiang Bai, Yeting Li, Wei Ma, Xiaofei Xie, Yuekang Li, Limin Sun, and Yang Liu. How Effective are they? Exploring Large Language Model Based Fuzz Driver Generation. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, 2024.
[141] Han Zheng, Flavio Toffalini, Marcel Böhme, and Mathias Payer. MendelFuzz:The Return of the Deterministic Stage. In ACM SIGSOFT Symposium on the Foundations of Software Engineering (FSE), 2025.

بخش دوم این مقاله: SoK: مطالعه نظام‌مند یکپارچه‌سازی و بازتولید دستاوردهای پژوهشی فازینگ در AFL++

بخش سوم این مقاله: نوآوری یافت نشد: بررسی سایه‌سازی ورودی در فازینگ از طریق راه‌اندازی مجدد فازر تطبیقی

بخش چهارم این مقاله: امنیت پهپادها و پرونده اسرارآمیز DroneID شرکت DJI

چالش‌های حل نشده حوزه فازینگ: دام‌ها، نقاط کور و درس‌های آموخته ‌شده از دنیای واقعی

Open Challenges in the Field of Fuzzing: Pitfalls, Blind Spots, and Real-World Lessons