نرم‌افزارهای مدرن اغلب ورودی‌هایی با دستور زبان‌های (grammars) بسیار پیچیده را می‌پذیرند. برای انجام فازینگ جعبه خاکستری (greybox fuzzing) و کشف باگ‌های امنیتی (security bugs) در چنین نرم‌افزارهایی، تولید ورودی‌هایی که با دستور زبان‌ ورودی نرم‌افزار مطابقت داشته باشند، ضروری است. با این حال، این یک کار چالش‌برانگیز شناخته شده است زیرا نیاز به درک عمیقی از گرامر دارد که اغلب در دسترس نیست و استنباط آن دشوار است. پیشرفت‌های اخیر در مدل‌های زبان بزرگ (LLM) نشان داده است که می‌توان از آنها برای ترکیب متن و کد زبان طبیعی با کیفیت بالا که با دستور زبان‌ یک قالب‌بندی ورودی (input format) مشخص مطابقت دارد، استفاده کرد. با این وجود، LLMها اغلب قادر به تولید خروجی‌های غیرمتنی، مانند تصاویر، ویدیوها و فایل‌های PDF نیستند یا برای تولید آنها بسیار پرهزینه هستند. این محدودیت مانع از کاربرد LLMها (large language models) در فازینگ آگاه از دستور زبان می‌شود. ما یک رویکرد جدید برای فعال کردن فازینگ آگاه از گرامر بر روی ورودی‌های غیرمتنی ارائه می‌دهیم. از LLMها برای ترکیب و همچنین جهش مولدهای ورودی، به شکل اسکریپت‌های پایتون، استفاده می‌کنیم که داده‌هایی مطابق با دستور زبان یک قالب‌بندی ورودی داده شده تولید می‌کنند. سپس، داده‌های غیرمتنی حاصل از مولدهای ورودی (input generators) توسط فازرهای سنتی (++AFL) بیشتر جهش (mutate) می‌یابند تا فضای ورودی نرم‌افزار را به طور موثر جستجو کنند. رویکرد ما، یعنی G2FUZZ، دارای یک استراتژی ترکیبی است که یک “جستجوی جامع (holistic search)” هدایت شده توسط LLMها و یک “جستجوی محلی (local search)” هدایت شده توسط فازرهای با کیفیت صنعتی را ترکیب می‌کند. دو مزیت کلیدی عبارتند از:

LLM (1)هایی که در ترکیب و جهش مولدهای ورودی و امکان پرش از بهینه‌های محلی (local optima) خوب هستند، بنابراین در ترکیب با فازرهای مبتنی بر جهش، به یک اثر هم افزایی دست می‌یابند.

LLM (2)ها کمتر مورد استفاده قرار می‌گیرند مگر اینکه واقعاً مورد نیاز باشند، بنابراین هزینه استفاده از LLM را به طور قابل توجهی کاهش می‌دهند.

ما G2FUZZ را روی انواع قالب‌بندی‌های ورودی، از جمله تصاویر TIFF، فایل‌های صوتی MP4 و فایل‌های PDF ارزیابی کرده‌ایم. نتایج نشان می‌دهد که G2FUZZ از نظر پوشش کد و یافتن باگ در اکثر برنامه‌های آزمایش شده روی سه پلتفرم UNIFUZZ، FuzzBench و MAGMA، از ابزارهای SOTA مانند ++AFL و Fuzztruction و FormatFuzzer بهتر عمل می‌کند. G2FUZZ همچنین 10 باگ منحصر به فرد را در جدیدترین نرم‌افزارهای دنیای واقعی کشف می‌کند که 3 مورد از آنها توسط CVE تأیید شده‌اند.

1. مقدمه (Introduction)

نرم‌افزارهای مدرن اغلب ورودی‌هایی با دستور زبان‌های بسیار پیچیده، مانند تصاویر، فایل‌های پیکربندی و بسته‌های شبکه (network packets) را می‌پذیرند. فازینگ چنین نرم‌افزاری به چالش‌برانگیز بودن [14، 19، 23، 27، 33، 47] معروف است، زیرا برای جستجوی کامل فضای ورودی، نیاز به درک عمیقی از دستور زبان نرم‌افزار دارد. اغلب، قبل از فازینگ جعبه خاکستری (greybox fuzzing) [6، 15، 28، 35، 36، 48، 56] و کشف باگ‌های امنیتی، باید ورودی‌های نمونه‌ای را تهیه کرد که با دستور زبان قالب ورودی مطابقت داشته باشند و همچنین ویژگی‌های متنوعی را نشان دهند.

فازرهای اخیر آگاه از ساختار، راه‌حل‌هایی را برای کاهش چالش‌های فوق با فازینگ مبتنی بر استنتاج و فازینگ آگاه از دستور زبان (grammar-aware fuzzing) بررسی کرده‌اند، اما هنوز محدودیت‌هایی دارند. فازرهای مبتنی بر استنتاج، مانند ProFuzzer [55] ،FuzzIn-Mem [32] و WEIZZ [15]، می‌توانند دستور زبان‌های ورودی را استنتاج کرده و ورودی‌ها را در لحظه تولید کنند. با این حال، آنها اغلب با استنتاج فیلدهای ورودی ساده و تلاش برای تغییر ساختارهای فایل، از دقت پایین و مقیاس‌پذیری ضعیف رنج می‌برند. ProFuzzer و WEIZZ برای ورودی‌های طولانی زمان‌بر هستند، در حالی که FuzzIn-Mem به برنامه‌هایی نیاز دارد که دارای توابع چاپگری هستند که ساختارهای داده درون حافظه را به فایل تبدیل می‌کنند. فازرهای جعبه خاکستری آگاه از دستور زبان [5، 8، 21، 39، 51] اغلب نیاز به پیش‌آگاهی از دستور زبان ورودی (مثلاً ارائه شده توسط کاربران) دارند.

چنین اطلاعاتی اغلب در دسترس نیست یا ناقص است، و درک جامع فیلدهای ورودی و روابط آنها را مبهم می‌سازد. علاوه بر این، رویکردهای فازینگ فعلی در درجه اول فیلدهای ساختاری اساسی مانند اندازه و جمع‌آزماها (Checksum) را در قالب‌های فایل اعتبارسنجی می‌کنند، اما ویژگی‌های پیچیده را نادیده می‌گیرند. این ویژگی‌ها می‌توانند منطق پیچیده‌تری را ایجاد کنند و اشکالات عمیق‌تری را آشکار کنند. ویژگی‌های پیچیده اغلب شامل تکه‌های پیچیده یا محدودیت‌های بین تکه‌ها هستند که چالش‌هایی را برای روش‌های فازینگ سنتی ایجاد می‌کنند. Fuzztruction [7] با تزریق خطا به برنامه‌های مولد برای تولید ورودی‌هایی با قالب‌های بسیار پیچیده، این چالش را از دیدگاهی متفاوت کاهش می‌دهد. با این حال، Fuzztruction به در دسترس بودن یک برنامه مولد مناسب متکی است که هنوز هم نیاز به شناسایی محققان باتجربه دارد. مدل‌های زبان بزرگ LLM شبکه‌های عصبی مبتنی بر مبدل (transformer-based neural networks) هستند و می‌توان انتظار داشت که LLMها بتوانند نمونه‌های ورودی با دستور زبان‌های (grammars) معتبر مختلف تولید کنند و در نتیجه فازینگ آگاه از دستور زبان (grammar-aware fuzzing) را به تنهایی پیش ببرند.

در واقع، ما برخی از کارهای اخیر را دیده‌ایم که از LLMها برای تولید ورودی برای فازینگ استفاده می‌کنند [9، 10، 37، 53]. با این وجود، ما روشن می‌کنیم که اگرچه LLMها قادر به تولید خروجی‌های متنی، مانند متن و کد زبان طبیعی هستند، اما متوجه می‌شویم که LLMها اغلب در تولید نمونه‌های داده غیرمتنی که مورد نیاز بسیاری از نرم‌افزارها است، ناتوان یا بسیار پرهزینه هستند. ما در بخش 3 تجزیه و تحلیل دقیقی ارائه می‌دهیم.

به جای آموزش LLMها برای تولید مستقیم ورودی‌های فازینگ غیرمتنی، این مقاله دیدگاه دیگری را برای تقویت فازینگ مبتنی بر جهش با LLMها بررسی می‌کند. ایده اصلی، استفاده از LLMها برای ترکیب و جهش خودکار مولدهای ورودی (اغلب به شکل اسکریپت‌های پایتون) است که با ویژگی‌ها و ساختارهای خاص قالب فایل هدف سفارشی شده‌اند. با اجرای این مولدها، می‌توانیم ورودی‌هایی تولید کنیم که طیف گسترده‌ای از ویژگی‌ها و ساختارها را نشان می‌دهند و به طور بالقوه منطق برنامه متفاوتی را فعال کرده و نواحی کدی را که قبلاً آزمایش نشده‌اند، جستجو می‌کنند. علاوه بر این، این ورودی‌های غیرمتنی تولید شده را می‌توان به سرعت توسط فازرهای سنتی مبتنی بر جهش، مانند ++AFL، جهش داد تا فضای ورودی را به طور مؤثر جستجو کنند.

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

ما رویکرد فوق را در یک چارچوب فازی جدید، یعنی G²Fuzz، پیاده‌سازی می‌کنیم. هنگامی که کاربران نام قالب‌بندی ورودی مثلاً TIFF را مشخص می‌کنند، G²Fuzz از LLMهای بالفعل، مانند GPT-3.5 و llama-3-70b-instruct، برای ترکیب خودکار مولدهای ورودی در اسکریپت‌های پایتون که تصاویر TIFF تولید می‌کنند، استفاده می‌کند. G²Fuzz چندین استراتژی را برای جهش بیشتر مولدهای ترکیب شده آسان می‌کند. سپس، G²Fuzz مولدهایی را برای تولید مجموعه‌ای متنوع از ورودی‌های غیرمتنی اجرا می‌کند و همچنین از ++AFL برای جهش ورودی‌های ترکیب شده استفاده می‌کند. هنگامی که فازرهای به کار رفته تا حدی نتوانند پوشش دهی کد جدید را کشف کنند، G²Fuzz LLMها را برای ترکیب مولدهای ورودی جدید و متمایز فراخوانی می‌کند و سپس ورودی‌های غیرمتنی تولید شده را با استفاده از ++AFL جهش بیشتری می‌دهد. این فرآیند تا زمانی که نرم‌افزار هدف به طور کامل پوشش دهی داده شود ادامه می‌یابد.

ما G²Fuzz را روی ۳۴ قالب‌بندی ورودی، از جمله تصاویر JPEG، تصاویر TIFF و ویدیوهای MP4 ارزیابی می‌کنیم. نتایج حاکی از آن است که G²Fuzz به‌طور پیوسته عملکردی بهتر از فازرهای مبتنی بر جهشِ پیشرفته روز (SOTA) مانند ++AFL و همچنین چندین فازر آگاه از ساختار (structure-aware fuzzer) مبنا دارد — چه از نظر پوشش دهی کد (code coverage) و چه از نظر کشف باگ‌ها (Bug). ما این چارچوب را روی سه معیار (third-party benchmarks)، شامل UNIFUZZ [30]، FuzzBench [38] و MAGMA [22] ارزیابی کردیم. نتایج نشان می‌دهند که G²Fuzz در هر سه پلتفرم، بهترین عملکرد را در زمینه پوشش‌دهی کد و کشف آسیب‌پذیری‌ها به دست می‌آورد.

ما دریافتیم که G²Fuzz با کمک LLMها، قادر به کشف بسیاری از پوشش‌های منحصر به فرد لبه/تابع است که سایر فازرها نمی‌توانند آنها را پیدا کنند. علاوه بر این، ما نشان می‌دهیم که G²Fuzz هزینه بسیار کمی در استفاده از LLM دارد، به‌گونه‌ای که فازینگ یک نرم‌افزار هدف با GPT-3.5 به‌ مدت ۲۴ ساعت، کمتر از ۰٫۲ دلار هزینه دارد. ما از G²Fuzz برای یافتن 10 اشکال منحصر به فرد در جدیدترین نرم‌افزارهای دنیای واقعی استفاده کرده‌ایم که 3 مورد از آنها توسط CVE تأیید شده‌اند. در مجموع، سهم ما به شرح زیر است:

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

2. مفاهیم اولیه (Preliminaries)

مدل‌های زبان بزرگ (Large Language Models – LLMs): شبکه‌های عصبی مبتنی بر مبدل (transformer-based neural networks)، به عملکرد SOTA در وظایف مختلف NLP، از جمله ترجمه و خلاصه‌سازی، دست یافته‌اند. مدل‌هایی مانند GPT و مدل‌سازی زبان ماسک‌ شده (masked language modeling) مانند BERT برای خروجی متنی ضروری هستند، در حالی که مدل‌هایی مانند CLIP [29] و DALL-E [44] داده‌های غیرمتنی را مدیریت می‌کنند و دامنه کاربردهای آنها را افزایش می‌دهند. LLMها پتانسیل تقویت فازینگ نرم‌افزار را دارند [12].

فازینگ جعبه خاکستری (Greybox Fuzzing): فازینگ جعبه خاکستری تکنیکی برای یافتن باگ‌های امنیتی نرم‌افزار، به ابزارگذاری سبک (lightweight instrumentation) برای بازخورد اجرا متکی است تا ورودی‌ها را به طور مؤثرتری تغییر دهد. فازینگ‌هایی مانند AFL [57] ،AFL++ [16] و Honggfuzz [2] این زمینه را توسعه داده‌اند. ++AFL، با بهینه‌سازی‌هایی مانند Redqueen، به عنوان فازر استاندارد بالفعل شناخته می‌شود که به طور گسترده توسط جامعه امنیتی برای شناسایی باگ‌ها استفاده می‌شود.

فازینگ آگاه از دستور زبان (Grammar-Aware Fuzzing): فازینگ آگاه از دستور زبان، نوعی فازینگ جعبه خاکستری (greybox fuzzing) است که ورودی‌هایی را بر اساس قوانین دقیق دستور زبان تولید می‌کند و به طور موثر آسیب‌پذیری‌ها را در نرم‌افزارهایی که ساختارهای ورودی پیچیده را مدیریت می‌کنند، شناسایی می‌کند. ابزارهایی مانند FormatFuzzer [13] ،Gramatron [49] و Superion [51] از دستور زبان‌های ارائه شده برای کشف باگ‌های امنیتی در نرم‌افزارهای دنیای واقعی استفاده می‌کنند.نرم‌افزار، برای تولید ورودی‌ها در قالب‌های بسیار پیچیده، Fuzztruction [7] عمداً خطاها را به برنامه‌های مولد تزریق می‌کند.

فازینگ مبتنی بر استنتاج (Inference-Based Fuzzing): فازینگ مبتنی بر استنتاج، مانند ProFuzzer [55] ،GreyOne [17] و WEIZZ [15]، از روابط استنتاجی بین بایت‌های ورودی و محدودیت‌های مسیر برای تولید ورودی‌های آزمایشی هدفمند استفاده می‌کند. این روش منطق داخلی و قالب‌های داده را برای ایجاد موارد آزمایشی مرتبط، افزایش پوشش دهی و کاهش نویز در نتایج، تجزیه و تحلیل می‌کند.

3. انگیزه (Motivation)

3.1 کارهای مرتبط و محدودیت‌ها (Related Work and Limitations)

روش‌های موجود را می‌توان بر اساس نوع ورودی که با آن سروکار دارند به دو دسته تقسیم کرد:

فازینگ با قالب‌بندی متنی (Text-format fuzzing)
فازینگ با قالب‌بندی باینری (Binary-format fuzzing)

فازینگ با قالب‌بندی متنی در درجه اول برنامه‌هایی را آزمایش می‌کند که از ورودی‌های متنی مانندSuperion [51] ، Nautilus [5] و Grimoire [8] استفاده می‌کنند. این روش‌ها انواع ورودی‌های متنی معتبر را بر اساس مشخصات ارائه شده، از جمله قالب‌بندی‌هایی مانند XML، Ruby، SQL و SMT تولید می‌کنند. از سوی دیگر، فازینگ با قالب‌بندی‌ باینری، برنامه‌هایی را با ورودی‌های باینری، مانند FormatFuzzer [13]، FuzzInMem [32] ،WEIZZ [15] و AFLS-mart [41]، آزمایش می‌کند. این روش‌ها ورودی را به چندین تکه تقسیم می‌کنند و جهش‌هایی را روی این تکه‌ها انجام می‌دهند تا ورودی‌های متنوعی مانند JPEG، PDF، TIFF، MP3 و MP4 ایجاد کنند. G²Fuzz به دسته دوم تعلق دارد و فایل‌های با قالب‌بندی باینری را با ویژگی‌های پیچیده برای جستجوی عمیق‌تر در کد می‌سازد. با وجود پیشرفت‌های قابل توجه حاصل از روش‌های موجود، آنها هنوز با سه چالش زیر روبرو هستند:

چالش اول: تولید فایل‌ها با ویژگی‌های پیچیده (Generating Files with Complex Features).

رویکردهای فعلی در درجه اول بر ساختار اساسی قالب‌بندی‌های فایل هدف، مانند تولید فیلدهای ساختاری اساسی معتبر مانند فیلدهای اندازه، جمع‌آزماها (checksum) و فیلدهای بیتی تمرکز دارند. با این حال، یک قالب‌بندی‌ فایل باینری هدف اغلب شامل ویژگی‌های پیچیده مختلفی است و طبق مشاهدات ما ، فایل‌هایی با ویژگی‌های پیچیده اغلب پتانسیل ایجاد منطق برنامه پیچیده‌تر را دارند و در نتیجه احتمالاً اشکالات عمیق‌تری را کشف می‌کنند. در مقایسه با ساختارهای اساسی، این ویژگی‌های پیچیده عمدتاً از دو جنبه متفاوت هستند: 1) ویژگی‌های پیچیده احتمالاً تکه‌های پیچیده‌تری را در فایل باینری معرفی می‌کنند و 2) محدودیت‌های مختلفی (مثلاً محدودیت‌های عددی ایجاد شده توسط مجموع کنترلی) ممکن است در بین تکه‌های فایل باینری معرفی شوند. علاوه بر این، وابستگی‌های خاصی بین ویژگی‌های مختلف (پایه/پیچیده) وجود دارد، که در آن یک ویژگی برای پیاده‌سازی به ویژگی دیگری وابسته است. به عنوان مثال، برای فعال کردن فشرده‌سازی JPEG در یک فایل TIFF، فایل ابتدا باید از ویژگی “فضای رنگی YCbCr/RGB” پشتیبانی کند. همه این سناریوها چالش‌های بزرگی را برای فازرهای موجود در قالب‌بندی‌ باینری ایجاد می‌کنند. برای مثال، فازرهای فعلی به دلیل استنتاج نادرست مثلاً WEIZZ یا دستور زبان‌های ناقص فاقد سینتکس LZW مثلاً FormatFuzzer، AFLSmart در تولید فایل‌های TIFF با داده‌های LZW شکست می‌خورند و قابلیت‌های تجزیه و جهش خود را محدود می‌کنند.

چالش دوم: نیاز به مشخصات قالب‌بندی‌ و کدگذاری دستی (Require Format Specifications and Manual Coding).

کارهای قبلی اغلب به مشخصات قالب‌بندی‌ ارائه شده یا تلاش انسانی برای تغییر کد متکی هستند، همانطور که در FormatFuzzer [13] مشاهده می‌شود. FormatFuzzer قالب‌بندی‌ را از مخزن ویرایشگر 010 دریافت می‌کند و از آنها برای تجزیه استفاده می‌کند. با این حال، کدگذاری دستی هنوز برای فرآیند تولید مورد نیاز است.

علاوه بر این، Fuzztruction می‌تواند با تزریق خطا به برنامه‌های مولد، فایل‌های متنوعی تولید کند. با این حال، برای شناسایی و ابزارسنجی دستی برنامه‌های مولد مناسب، به محققان باتجربه متکی است و یافتن مولدهای مناسب برای قالب‌بندی‌‌های کمتر رایج اغلب چالش برانگیز است. در اینجا، ما در GitHub به دنبال برنامه‌های مولد برای هر 34 قالب‌بندی‌ ذکر شده در جدول 5 می‌گردیم. جستجو از کلمات کلیدی FORMATconverter/transformer/generator language: C++ stars:>5″ استفاده می‌کند، که در آن “FORMAT ” به عنوان یک نگهدارنده برای قالب‌بندی‌‌های خاص عمل می‌کند.

به عنوان مثال، برای فایل‌های JPG، یکی از عبارات جستجو JPG converter language:C++ stars:>5″ است. مولدهایی برای 21 قالب‌بندی‌ (قابلیت استفاده آزمایش نشده) یافت شد، در حالی که هیچ مولدی برای 13 فرمت باقی مانده در دسترس نبود.

چالش سوم: پردازش همزمان چندین قالب‌بندی‌ (Simultaneously Process Multiple Formats).

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

یک راه حل ممکن است راه‌اندازی چندین فازر به صورت موازی باشد، که هر کدام بر روی یک قالب‌بندی‌ ورودی تمرکز می‌کنند و سپس نتایج فازینگ فردی در پایان جمع بندی می‌شود. با این حال، برنامه‌ها اغلب شامل کدهای روتین برای پیش‌پردازش و مدیریت خطا هستند که مستقل از قالب‌بندی‌های فایل خاص هستند. موازی‌سازی می‌تواند منجر به تلاش‌های تکراری در این روال‌های رایج شود که نه تنها زمان زیادی را صرف می‌کند، بلکه منابع را نیز هدر می‌دهد. ما می‌بینیم که محدودیت‌های ذکر شده را می‌توان با استفاده هوشمندانه از LLMها برطرف کرد. نظر ما به شرح زیر است: برای تولید فایل‌هایی با ویژگی‌های پیچیده (چالش اول)، کتابخانه‌های متعددی برای تولید فایل به صورت آنلاین در دسترس هستند. این کتابخانه‌ها APIهایی را برای ساخت مستقیم ویژگی‌های پیچیده قالب‌بندی‌ هدف ارائه می‌دهند. از آنجایی که LLMها بر روی مجموعه داده‌های وسیعی که احتمالاً شامل این پایگاه‌های کد آنلاین هستند، آموزش دیده‌اند، می‌توانند اسکریپت‌های تولید فایل باینری (کد در پایتون) متناسب با ویژگی‌های فایل مورد نیاز را تولید کنند. با اجرای این مولد، می‌توانیم فایل‌هایی تولید کنیم که ویژگی‌های مورد نظر را نشان می‌دهند. به عنوان مثال، به منظور پیاده‌سازی فشرده‌سازی LZW برای TIFF، می‌توانیم از LLMها برای ساخت مولد مربوطه با 3 خط کد، مانند شکل 11، استفاده کنیم. با LLMها، ساختارهای فایل پیچیده رایج را می‌توان با مقدار متوسطی از کد تولید کرد. استفاده از LLMها برای تولید مولدها، آشکارا تلاش‌های انسانی یا نیاز به تهیه مشخصات قالب را از بین می‌برد. این امر امکان یک فرآیند آزمون کاملاً خودکار را فراهم می‌کند، در حالی که روش‌های موجود نیاز به کدنویسی دستی و آماده‌سازی قالب‌بندی‌ دارند.

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

۳.۲ مطالعه آزمایشی LLMها (The Pilot Study of LLMs)

LLMها به طور گسترده با استفاده از مجموعه داده‌های در مقیاس بزرگ آموزش دیده‌اند که آنها را قادر می‌سازد الگوهای پیچیده را یاد بگیرند و خروجی‌های با کیفیت بالا تولید کنند. این پیش‌آموزش گسترده، LLMها را قادر می‌سازد تا در وظایف مختلف تولید داده‌های ساختاریافته و باز، مانند تکمیل و تولید کد [3، 11، 11، 20، 31، 40، 42، 50، 54، 58]، ترجمه متن به تصویر [4، 18، 24، 34، 43] و وظایف تضمین کیفیت برای پشتیبانی مشتری [26، 45، 46]، عملکرد بهتری داشته باشند. اعتقاد بر این است که حجم عظیم داده‌های آموزشی به LLMها کمک می‌کند تا ظرافت‌های زبان را درک کرده و نتایج دقیق و متناسب با متن تولید کنند.

محدودیت LLMهای بالفعل (Limitation of De Facto LLMs). ما اطمینان داریم که مدل‌های زبانی بزرگ (LLMs) می‌توانند برای تقویت فازینگ مبتنی بر جهش مورد استفاده قرار گیرند، چرا که این مدل‌ها از دانش گرامری پیچیده‌ای برخوردارند که می‌تواند فرایند تست پیوسته نرم‌افزارهایی با قالب‌بندی‌‌های ورودی پیچیده را تسهیل کند.

با این حال، ما دریافتیم که LLMها اغلب توانایی کمتری دارند یا حتی قادر به تولید خروجی‌های غیرمتنی نیستند. به طور خاص، در حالی که تست فازینگ مدرن اغلب ورودی‌های غیرمتنی مانند کتابخانه‌های پردازش تصویر را هدف قرار می‌دهد، LLMهای همه منظوره برای تولید چنین داده‌های غیرمتنی طراحی نشده‌اند. علاوه بر این، در حالی که LLMهای پیشرفته مانند DALL-E [1] می‌توانند تصاویر تولید کنند، بررسی آزمایشی ما نشان می‌دهد که قالب‌بندی‌ تصویر به مجموعه کوچکی از قالب‌بندی‌های از پیش تعریف شده محدود می‌شود. DALL-E فقط از تولید تصاویر در قالب‌بندی‌های رایج تصویر، مانند PNG و GIF، پشتیبانی می‌کند، حتی اگر در اعلان‌ها به قالب‌بندی‌های دیگری (TIFF، RAW، BMP و غیره) نیاز داشته باشیم. علاوه بر این، استفاده از DALL-E برای هر 1000 تصویر 40.00 دلار هزینه دارد که آن را برای فازینگ در مقیاس بزرگ گران می‌کند. تولید یک نمونه ورودی می‌تواند چندین ثانیه طول بکشد و به طور قابل توجهی بر توان عملیاتی فازینگ تأثیر بگذارد. علاوه بر تصاویر، سایر انواع فایل‌های غیرمتنی، مانند MP4 برای ویدیو، MP3 برای صدا، PDF برای اسناد و Binary Large Object (BLOB)، اغلب توسط LLMهای موجود پشتیبانی نمی‌شوند. یافتن همه LLMهای سفارشی می‌تواند چالش برانگیز باشد.

ما توزیع قالب‌بندی‌ ورودی برنامه‌های FuzzBench را تجزیه و تحلیل می‌کنیم. FuzzBench [38] یکی از پرکاربردترین پلتفرم‌های معیار است که توسط گوگل برای ارزیابی فازینگ توسعه داده شده است. این برنامه شامل بسیاری از پروژه‌های متن‌باز پرکاربرد است که انواع قالب‌بندی‌های ورودی را پردازش می‌کنند. ما معتقدیم که نتایج تجزیه و تحلیل به دلیل اندازه و تنوع معیارها قابل تعمیم خواهد بود. همچنین دریافتیم که 73٪ از برنامه‌ها فقط ورودی‌های غیرمتنی را می‌پذیرند. برنامه‌هایی که ورودی‌های غیرمتنی را می‌پذیرند، رایج‌تر از برنامه‌هایی هستند که ورودی‌های متنی را در فازینگ سنتی می‌پذیرند. برای این برنامه‌ها، LLMهای عمومی نمی‌توانند مستقیماً ورودی‌های فازینگ تولید کنند (دلایلی که قبلاً مورد بحث قرار گرفته است). علاوه بر این، در حالی که برخی از LLMهای پیشرفته می‌توانند ورودی‌های PNG و JPEG تولید کنند، قالب‌بندی‌های دیگر هنوز پشتیبانی نمی‌شوند.

فرصت فعال‌سازی LLM (LLM-Enabled Opportunity). ما مشاهده می‌کنیم که اکثر فایل‌های باینری را می‌توان با استفاده از کتابخانه‌های پایتون تولید کرد. به عنوان مثال، می‌توانیم از PIL برای تولید فایل‌های JPEG با ساختارهای مختلف و از CV2 برای تولید فایل‌های PNG استفاده کنیم. از آنجایی که اسناد مربوط به این کتابخانه‌ها احتمالاً در داده‌های آموزشی LLM گنجانده شده‌اند، منطقی است که انتظار داشته باشیم LLMها بتوانند مولدهایی برای فایل‌های باینری بر اساس این کتابخانه‌ها سنتز کنند. در این مرحله، ما آزمایش‌هایی را روی قالب‌بندی‌های موجود در UNI-FUZZ، FuzzBench و MAGMA انجام دادیم تا بررسی کنیم که آیا LLM ها می‌توانند برای هر قالب‌بندی‌ یک مولد تولید کنند یا خیر. برای جزئیات بیشتر، به بخش 5.1.5 مراجعه کنید. به طور خلاصه، همه این داده‌های غیرمتنی را می‌توان توسط اسکریپت‌های پایتون تولید کرد. در نتیجه، می‌توانیم از LLMها برای سنتز مولدهای مختلف، تولید ورودی‌های ساختاریافته مختلف و کاوش در مناطق کد عمیق‌تر استفاده کنیم. با این حال، ما باید به دو چالش زیر بپردازیم.

چالش فنی اول: تنوع (Diversity). ما دریافتیم که خروجی‌های LLM اغلب تنوع کمتری دارند و کنترل آنها دشوار است. این امر در فازینگ نامطلوب است، زیرا انتظار می‌رود تعداد زیادی مولد که متنوع هستند و تا حد امکان فضای ورودی را پوشش می‌دهند، وجود داشته باشد.

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

در طول مطالعه اولیه خود، ما سعی کردیم تنوع مولدهای ترکیب شده را با چندین تاکتیک، مانند کنترل دما و نمونه‌برداری top-k، تنظیم کنیم، اما نتایج رضایت‌بخش نبود. به عنوان مثال، در حالی که ممکن است به LLMها دستور داده شود که “100 مولد تصویر JPEG تولید کنند که تا حد امکان متنوع باشند”، متوجه می‌شویم که بسیاری از تصاویر تولید شده به سادگی تکرار می‌شوند و “100” در حال حاضر برای LLM برای پردازش یکجا بسیار بزرگ است. کارهای اخیر نشان می‌دهند که استفاده از LLMها به تنهایی برای تولید نمونه‌های متنوع ذاتاً چالش‌برانگیز است [25، 52]؛ این اغلب به عنوان “پدیده دم (tail phenomena)” شناخته می‌شود، که در آن LLMها تمایل دارند تعداد زیادی نمونه مشابه و تنها تعداد کمی نمونه فرعی تولید کنندنمونه‌های rse.

چالش فنی دوم: سربار (Overhead). کمپین‌های فازینگ در دنیای واقعی نیاز به تولید و آزمایش نمونه‌های ورودی زیادی دارند و مدت زمان فازینگ پیشنهادی اغلب در حد چند روز یا چند هفته است. این موضوع نگرانی شدیدی را در مورد سربار ایجاد می‌کند. به عنوان مثال، هزینه استفاده از GPT-4 Turbo برای هر 1 میلیون توکن 10.00 دلار و هزینه استفاده از DALL-E برای هر 1000 تصویر 40.00 دلار تخمین زده می‌شود. با توجه به اینکه یک کمپین فازینگ ممکن است به میلیون‌ها توکن یا تصویر نیاز داشته باشد، هزینه استفاده از LLMها می‌تواند بسیار بالا باشد. هزینه زمانی استفاده از LLMها نیز بالا است، زیرا تولید یک نمونه ورودی واحد ممکن است بسته به پیچیدگی قالب ورودی و کیفیت نمونه تولید شده، چند ثانیه یا تا بیست ثانیه طول بکشد. این برای فازینگ عملی نیست، زیرا انتظار می‌رود فازر تعداد زیادی نمونه ورودی را در مدت زمان کوتاهی تولید و آزمایش کند. فرض کنید تولید هر تصویر JPEG ده ثانیه طول می‌کشد و فازر باید 1,000,000 تصویر تولید کند. تکمیل این کار 115 روز طول خواهد کشید که در فازینگ دنیای واقعی عملی نیست.

۴. طراحی (Design)

در راستای چالش‌های ذکر شده در بخش ۳، ما G²Fuzz را ارائه می‌دهیم، یک رویکرد جدید و کارآمد برای تقویت فازینگ مبتنی بر جهش با LLMها. شکل ۱ طراحی سطح بالای G²Fuzz را نشان می‌دهد. G²Fuzz دارای یک استراتژی ترکیبی است که ترکیبی از “جستجوی جامع (holistic search)” هدایت شده توسط LLMها و “جستجوی محلی یا لوکال (local search)” هدایت شده توسط فازرهای مبتنی بر جهش با کیفیت صنعتی است. ایده اصلی این است که از LLMها برای ترکیب خودکار مولدهای ورودی که برای ویژگی‌ها، ساختارها و دستور زبان خاص فرمت فایل هدف سفارشی شده‌اند، استفاده کنیم. ما مولدهای سنتز شده را بیشتر جهش می‌دهیم تا تنوع آنها را افزایش دهیم (به بخش ۴.۱ مراجعه کنید).

با اجرای این مولدها، G²Fuzz می‌تواند بذرهایی (seed) با ساختارها و ویژگی‌های متنوع به دست آورد. سپس، آن ورودی‌های تولید شده را می‌توان توسط فازرهای مبتنی بر جهش سنتی ++AFL جهش داد تا فضای ورودی را به طور مؤثرتری جستجو کند (به بخش ۴.۲ مراجعه کنید). وقتی G²Fuzz نتواند مسیر جدیدی را در طول جستجوی لوکال شناسایی کند، به جستجوی جامع باز می‌گردد تا مولدهای ورودی جدید تولید کند.

G²Fuzz شامل دو جزء اصلی است: سنتز مولد ورودی (nput generator synthesis) و جهش مولد ورودی (input generator mutation). در ترکیب مولد ورودی، G²Fuzz ابتدا ویژگی‌های فایل را برای فرمت هدف تجزیه و تحلیل می‌کند و برای هر ویژگی یک مولد ورودی ترکیب می‌کند. در این مرحله، ما برخی مولدهای اولیه و نسبتاً ساده را به دست می‌آوریم.

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

به جز مشخص کردن قالب فایل هدف (که نیاز به ارائه توسط کاربر دارد)، کل فرآیند G²Fuzz خودکار است. نمودار جریان پایین در شکل 1، خط لوله فازینگ استاندارد مبتنی بر جهش را مشخص می‌کند. ما با بذرهای اولیه (Seed) شروع می‌کنیم، آنها را به صف بذر اضافه می‌کنیم و سپس یک بذر را برای جهش انتخاب می‌کنیم. در نهایت، بذر هدف را تحت استراتژی جهش از پیش تعریف شده جهش می‌دهیم و بررسی می‌کنیم که آیا ورودی‌های جهش یافته باعث ایجاد اشکالات می‌شوند یا خیر.

G²Fuzz با ترکیب دو مؤلفه مبتنی بر LLM فوق، خط لوله استاندارد را تقویت می‌کند. قبل از انتخاب بذر (Seed)، وضعیت فازینگ را بر اساس عملکرد فازینگ به دست می‌آوریم.

اگر این اولین چرخه فازینگ باشد، ما هم ترکیب مولد ورودی و هم جهش مولد ورودی را برای تکرار ویژگی‌های اساسی و غنی‌سازی مجموعه بذر اولیه خود انجام می‌دهیم. اگر فرآیند فازینگ نتواند برای مدت طولانی مسیر جدیدی پیدا کند، G²Fuzz مستقیماً مولدهای ورودی را جهش می‌دهد و از طریق ترکیب ویژگی‌ها، مولدهای پیچیده‌تری ایجاد می‌کند و احتمالاً کمپین فازینگ را قادر می‌سازد تا از “بهینه لوکال” فرار کند.

اثر هم‌افزایی (Synergy Effect). ما تأکید می‌کنیم که G²Fuzz هنگام ترکیب با فازرهای مبتنی بر جهش، یک اثر هم‌افزایی دارد. LLMها از اطلاعات گرامری فرمت‌های مختلف ورودی آگاه هستند، اما توانایی کمتری در تولید مستقیم آن ورودی‌های غیرمتنی دارند. از سوی دیگر، فازرهای مبتنی بر جهش در انجام جهش‌های بذر و در سطح بایت و کاوش سیستماتیک فضای ورودی با هزینه کم خوب هستند. با این حال، فازرهای مبتنی بر جهش مرسوم اغلب فاقد دانش گرامری برای تولید نمونه‌های ورودی با کیفیت بالا هستند و اغلب فاقد “تصویر بزرگ” برای کاوش تدریجی فضای ورودی هستند. می‌توان به یک هم‌افزایی خوب بین LLMها و فازرهای مبتنی بر جهش دست یافت، که در آن LLMها در ترکیب مولدهای ورودی و امکان فرار از بهینه‌های محلی و فازرهای مبتنی بر جهش در کاوش عمیق فضای ورودی محلی برتری دارند. این امر محدودیت‌های LLMها و فازرهای مبتنی بر جهش مرسوم را کاهش می‌دهد و عملکرد بهتری نسبت به استفاده از هر یک از آنها به تنهایی دارد؛ به ارزیابی‌ها در بخش 5 مراجعه کنید.

بررسی چالش فنی 1:

چالش اول مربوط به کمبود تنوع در خروجی‌های تولیدشده توسط LLMها است. LLMها ذاتاً مستعد “پدیده دنباله” هستند و اغلب خروجی‌هایی تولید می‌کنند که تکرار شده یا بسیار شبیه به یکدیگر هستند. G²Fuzz به جای اینکه مستقیماً از LLMها بخواهد مولدهای “متنوع” تولید کنند، ابتدا ویژگی‌های احتمالی یک فرمت فایل هدف را تجزیه و تحلیل می‌کند و سپس از LLMها برای ترکیب مولدهای ورودی متناسب با ویژگی‌ها/ساختارهای خاص فرمت فایل هدف استفاده می‌کند. ما همچنین مجموعه‌ای از استراتژی‌ها را برای گسترش و جهش مولدهای سنتز شده پیشنهاد می‌کنیم.

بررسی چالش فنی 2:

چالش ۲، مربوط به هزینه بالای استفاده از LLM است. ما این چالش را به شیوه‌ای اصولی بررسی می‌کنیم، به طوری که فقط در صورت نیاز، LLMها را برای تولید مولدهای ورودی جدید فراخوانی می‌کنیم. به طور کلی، LLMها فقط زمانی فراخوانی می‌شوند که جستجوی محلی (که توسط ++AFL انجام می‌شود) نتواند لبه‌های جدید را شناسایی کند. این امر تا حد زیادی هزینه استفاده از LLM را از 15.16 دلار به مراجعه کنید) به 0.124 دلار کاهش می‌دهد، بنابراین G²Fuzz را در کمپین‌های فازینگ دنیای واقعی عملی و مقرون به صرفه می‌کند.

دامنه کاربرد (Application Scope):

G²Fuzz به گونه‌ای طراحی شده است که برای اهداف عمومی و برای طیف وسیعی از کاربردها قابل استفاده باشد. ما G²Fuzz را روی انواع فرمت‌های ورودی، از جمله تصاویر JPEG، تصاویر TIFF، ویدیوهای MP4 و ۳۱ فرمت دیگر ارزیابی کرده‌ایم. طراحی G²Fuzz مختص هیچ فرمت ورودی خاصی نیست و می‌توان آن را به راحتی برای پشتیبانی از فرمت‌های ورودی جدید گسترش داد. با توجه به اینکه LLMهای مدرن به طور فزاینده‌ای قادر به کسب دانش گرامری پیچیده و مقابله با انواع داده‌های پیشرفته (مانند ویدیو و صدا) هستند، ما مطمئن هستیم که G²Fuzz می‌تواند برای تقویت فازینگ مبتنی بر جهش برای طیف وسیعی از قالب‌های ورودی استفاده شود. بررسی این انواع داده‌های پیشرفته را به کارهای آینده واگذار می‌کنیم.

۴.۱ سنتز مولد ورودی (Input Generator Synthesis)

زمان استفاده (When to Use). قبل از ورود به حلقه رسمی فازینگ، G²Fuzz ابتدا قالب فایل ورودی هدف را از کاربر دریافت می‌کند (برای مثال «TIFF»؛ این تنها اطلاعات مورد نیاز است)، ویژگی‌های آن را استخراج و سپس تولیدکننده‌های متناظر را ترکیب می‌نماید. سپس، این مولدها که قبلاً توسط LLM سنتز شده‌اند، اجرا می‌شوند تا بذرهای جدید و متنوع تولید شده و به صف بذرها اضافه شوند. شایان ذکر است که اگر یک نرم‌افزار چندین قالب ورودی را می‌پذیرد، G²Fuzz هر قالب را به‌صورت جداگانه تحلیل می‌کند تا تولیدکننده‌های متناظر برای هر قالب به دست آید.

ملاحظات طراحی: ویژگی‌ها در مقابل ساختارها (Design Consideration: Features vs. Structures). برای توصیف یک فایل، می‌توان دو جنبه اصلی را در نظر گرفت: ویژگی و ساختار. “ویژگی فایل” به ویژگی‌ها یا مشخصه‌هایی اشاره دارد که می‌توانند جزئیات خارجی در مورد فایل ارائه دهند. “ساختار فایل” به نحوه سازماندهی و قالب‌بندی داده‌ها در یک فایل اشاره دارد و جزئیات داخلی در مورد نحوه چیدمان داده‌ها در داخل فایل را ارائه می‌دهد. استفاده از ساختار فایل برای توصیف ورودی فایل مورد نظر، رویکردی ساده‌تر است. با این حال، بین مشخص کردن ساختار و تهیه کد پایتون مولد، شکافی وجود دارد. سند کتابخانه‌های فایل پایتون اغلب فاقد جزئیاتی در مورد نحوه نوشتن کد برای تولید یک ساختار فایل خاص است. در پایتون، ساخت یک فایل با ساختار خاص مانند ساخت با بلوک‌ها نیست، که در آن می‌توان یک تکه را در یک زمان اضافه کرد. در عوض، فایل اغلب از یک دیدگاه جامع‌تر ساخته می‌شود. این امر درک و استفاده از کتابخانه‌ها را برای دستیابی به ساختارهای خاص برای یک LLM دشوار می‌کند. همچنین، روابط بین تکه‌ها می‌تواند پیچیده باشد و وابستگی‌های پیچیده‌ای داشته باشد. مطالعه آزمایشی ما نشان می‌دهد که ایجاد مولدها بر اساس ساختارها، نرخ شکست بالایی دارد، زمان زیادی را صرف می‌کند و بر توان عملیاتی فازینگ تأثیر منفی می‌گذارد.

ما دریافتیم که کتابخانه‌های فایل پایتون مربوطه اغلب APIهایی را برای پیاده‌سازی ویژگی‌هایی برای فرمت‌های فایل خاص، مانند فلگ فشرده‌سازی در libtiff برای ذخیره فایل‌های TIFF، ارائه می‌دهند. در این موارد، ویژگی‌ها و کد دارای یک نقشه مستقیم هستند، زیرا سند این کتابخانه‌ها شامل توضیحات مربوطه است.

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

الگوریتم ۱: رویه مولد

				
					Input: The target file format, t⁢a⁢r⁢g⁢e⁢t⁢_⁢f⁢o⁢r⁢m⁢a⁢t.
Output: A set of (generator, feature description), G.
1 p⁢r⁢o⁢m⁢p⁢t←c⁢o⁢n⁢s⁢t⁢r⁢u⁢c⁢t⁢_⁢p⁢r⁢o⁢m⁢p⁢t⁢(t⁢a⁢r⁢g⁢e⁢t⁢_⁢f⁢o⁢r⁢m⁢a⁢t) // Based on Fig. 2
2 f⁢e⁢a⁢t⁢u⁢r⁢e⁢s←L⁢L⁢M⁢(p⁢r⁢o⁢m⁢p⁢t)
3 for f in f⁢e⁢a⁢t⁢u⁢r⁢e⁢s do
4       g←g⁢e⁢n⁢e⁢r⁢a⁢t⁢o⁢r⁢_⁢g⁢e⁢n⁢e⁢r⁢a⁢t⁢i⁢o⁢n⁢(t⁢a⁢r⁢g⁢e⁢t⁢_⁢f⁢o⁢r⁢m⁢a⁢t,t⁢a⁢r⁢g⁢e⁢t⁢_⁢f⁢e⁢a⁢t⁢u⁢r⁢e)
5       // Based on Alg. 2
6       if g≠n⁢o⁢n⁢e then
7             s⁢e⁢e⁢d⁢s←r⁢u⁢n⁢(g)
8             a⁢d⁢d⁢_⁢t⁢o⁢_⁢q⁢u⁢e⁢u⁢e⁢(s⁢e⁢e⁢d⁢s)
9             G←(g,f)
10

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

ویژگی‌ها (خطوط ۱-۲). برای هر ویژگی، G²Fuzz از یک LLM برای ایجاد یک مولد برای آن استفاده می‌کند (خطوط ۳-۴). سپس، G²Fuzz مولدهای را برای به دست آوردن بذرهایی (Seed) با ویژگی‌های مختلف اجرا می‌کند و این بذرها را در فازینگ به صف بذر اضافه می‌کند (خطوط ۶-۸).

تحلیل ویژگی. از آنجا که مستندات کتابخانه‌های پایتون شامل توضیحات متعددی درباره ویژگی‌ها (feature descriptions) است، مدل زبانی بزرگ (LLM) می‌تواند یک مولد بسازد که فایلی با ویژگی مشخص تولید کند. برای به‌دست آوردن ویژگی‌های یک قالب‌بندی‌ فایل مشخص، ما LLM را موظف می‌کنیم تا ویژگی‌های ممکن را خلاصه کند. نمونه prompt در شکل ۲ نشان داده شده است.

فشرده‌سازی بدون افت (فایل‌های TIFF پشتیبانی می‌کنند)
چند لایه‌ای بودن

ما تعداد ویژگی‌ها را محدود نمی‌کنیم، زیرا قالب‌بندی‌‌های مختلف فایل دامنه‌های متفاوتی از ویژگی‌ها دارند. هدف ما در این مرحله ثبت ویژگی‌های رایج است و ویژگی‌های غیرمعمول در بخش ۴.۲ بررسی می‌شوند.

سنتز مولد (Generator Synthesis). پس از اینکه ویژگی‌های یک قالب فایل (file format) خاص را به دست آوردیم، برای هر ویژگی یک مولد ترکیب می‌کنیم. برای مولد، دو الزام داریم: (۱) باید به زبان پایتون نوشته شده باشد و (۲) باید قابل اجرا باشد. به دست آوردن یک مولد پایتون برای LLMها ساده است. با این حال، چندین چالش برای اجرای روان مولدها وجود دارد.

الگوریتم ۲: الگوریتم ترکیب مولد

				
					1 i⁢n⁢i⁢t⁢_⁢c⁢n⁢t←0
2 while i⁢n⁢i⁢t⁢_⁢c⁢n⁢t&lt;I⁢N⁢I⁢T⁢_⁢M⁢A⁢X do
3       d⁢i⁢a⁢l⁢o⁢g⁢u⁢e←[ ]
4       p⁢r⁢o⁢m⁢p⁢t←c⁢o⁢n⁢s⁢t⁢r⁢u⁢c⁢t⁢_⁢p⁢r⁢o⁢m⁢p⁢t⁢(t⁢a⁢r⁢g⁢e⁢t⁢_⁢f⁢o⁢r⁢m⁢a⁢t,t⁢a⁢r⁢g⁢e⁢t⁢_⁢f⁢e⁢a⁢t⁢u⁢r⁢e)
5       // Based on Fig. 3
6       d⁢i⁢a⁢l⁢o⁢g⁢u⁢e.a⁢p⁢p⁢e⁢n⁢d⁢(p⁢r⁢o⁢m⁢p⁢t)
7       g←L⁢L⁢M⁢(d⁢i⁢a⁢l⁢o⁢g⁢u⁢e)
8       s⁢t⁢a⁢t⁢u⁢s,m⁢s⁢g←e⁢x⁢e⁢c⁢(g)
9       d⁢e⁢b⁢u⁢g⁢_⁢c⁢n⁢t←0
10       while d⁢e⁢b⁢u⁢g⁢_⁢c⁢n⁢t&lt;D⁢E⁢B⁢U⁢G⁢_⁢M⁢A⁢X do
11             if status==SUCCESS then
12                   r⁢u⁢t⁢u⁢r⁢n⁢g
13            e⁢r⁢r⁢o⁢r⁢_⁢i⁢n⁢f⁢o←g⁢e⁢t⁢_⁢m⁢s⁢g⁢(m⁢s⁢g)
14            
15            while T⁢R⁢U⁢E do
16                   if &quot;⁢M⁢o⁢d⁢u⁢l⁢e⁢N⁢o⁢t⁢F⁢o⁢u⁢n⁢d⁢E⁢r⁢r⁢o⁢r⁢&quot; not in e⁢r⁢r⁢o⁢r⁢_⁢i⁢n⁢f⁢o then
17                         b⁢r⁢e⁢a⁢k
18                  l⁢i⁢b⁢r⁢a⁢r⁢y⁢_⁢p⁢r⁢o⁢m⁢p⁢t←c⁢o⁢n⁢s⁢t⁢r⁢u⁢c⁢t⁢_⁢p⁢r⁢o⁢m⁢p⁢t⁢(e⁢r⁢r⁢o⁢r⁢_⁢i⁢n⁢f⁢o)
19                   // Based on Fig. 4
20                   r⁢e⁢l⁢i⁢e⁢d⁢_⁢l⁢i⁢b⁢r⁢a⁢r⁢y←L⁢L⁢M⁢(l⁢i⁢b⁢r⁢a⁢r⁢y⁢_⁢p⁢r⁢o⁢m⁢p⁢t)
21                   f⁢l⁢a⁢g,g=a⁢u⁢t⁢o⁢m⁢a⁢t⁢i⁢c⁢_⁢i⁢n⁢s⁢t⁢a⁢l⁢l⁢a⁢t⁢i⁢o⁢n⁢(r⁢e⁢l⁢i⁢e⁢d⁢_⁢l⁢i⁢b⁢r⁢a⁢r⁢y)
22                  
23                  if flag==0 then
24                         // Failed to install the library
25                         r⁢u⁢t⁢u⁢r⁢n⁢N⁢o⁢n⁢e
26                  s⁢t⁢a⁢t⁢u⁢s,m⁢s⁢g←e⁢x⁢e⁢c⁢(g)
27                   if status==SUCCESS then
28                         r⁢u⁢t⁢u⁢r⁢n⁢g
29                  else
30                         e⁢r⁢r⁢o⁢r⁢_⁢i⁢n⁢f⁢o←g⁢e⁢t⁢_⁢m⁢s⁢g⁢(m⁢s⁢g)
31                        
32            d⁢i⁢a⁢l⁢o⁢g⁢u⁢e.a⁢p⁢p⁢e⁢n⁢d⁢(g)
33             d⁢i⁢a⁢l⁢o⁢g⁢u⁢e.a⁢p⁢p⁢e⁢n⁢d⁢(e⁢r⁢r⁢o⁢r⁢_⁢i⁢n⁢f⁢o+`⁢`⁢R⁢e⁢g⁢e⁢n⁢e⁢r⁢a⁢t⁢e⁢&quot;)
34             G←L⁢L⁢M⁢(d⁢i⁢a⁢l⁢o⁢g⁢u⁢e)
35             s⁢t⁢a⁢t⁢u⁢s,m⁢s⁢g←e⁢x⁢e⁢c⁢(g)
36             d⁢e⁢b⁢u⁢g⁢_⁢c⁢n⁢t←d⁢e⁢b⁢u⁢g⁢_⁢c⁢n⁢t+1
37            
38      i⁢n⁢i⁢t⁢_⁢c⁢n⁢t←i⁢n⁢i⁢t⁢_⁢c⁢n⁢t+1
39

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

همان‌طور که در الگوریتم ۲ نشان داده شده است، الگوریتم ترکیب ابتدا یک مولد اولیه بر اساس قالب فایل هدف و ویژگی موردنظر می‌سازد و آن را اجرا می‌کند تا وضعیت اجرای برنامه به‌دست آید (خطوط ۳ تا ۷). الگوی اعلان مورد استفاده در شکل ۳ نشان داده شده است. چنانچه اجرا با شکست مواجه شود، پیغام خطای خاصی استخراج می‌شود (خط ۱۲).

اگر خطا شامل یک ماژول مفقود باشد، الگوریتم تلاش می‌کند کتابخانه مورد نیاز را نصب کند. این فرآیند شامل ساخت یک اعلان بر اساس اطلاعات خطا، استفاده از LLM برای شناسایی کتابخانه‌ی مفقود شده، و سپس تلاش برای نصب خودکار (خطوط ۱۴-۱۸) است. الگوی اعلان در شکل ۴ آمده است. چنانچه نصب موفقیت‌آمیز باشد، مولد دوباره اجرا می‌شود و اگر وضعیت اجرا SUCCESS باشد، مولد معتبر، باز گردانده می‌شود (خطوط ۲۲-۲۳). در غیر این صورت، حلقه‌ی مدیریت خطا ادامه می‌یابد. پس از حل مشکل وابستگی کتابخانه، اطلاعات خطا به LLM بازگردانده می‌شود تا برنامه‌ای را که می‌تواند خطای فعلی را حل کند، بازسازی کند (خطوط ۲۶-۲۸). در صورت دیباگ اگر تا زمان DEBUG_MAX هنوز نتواند یک مولد معتبر تولید کند، الگوریتم تلاش می‌کند تا یک مولد اولیه جدید تولید کند (به خط ۳ برگردید). این بسیار مهم است زیرا به دلیل ماهیت تصادفی LLMها، همان اعلان می‌تواند مولدهایی با کیفیت متفاوت تولید کند و به جلوگیری از گیر افتادن در «حداقل‌های محلی یا local minima» کمک کند (خطوط ۹-۱۲ و خطوط ۲۶-۳۰). بر اساس بررسی اولیه ما، INIT _MAX را روی ۲ و DEBUG_MAX را روی ۳ تنظیم می‌کنیم تا تعادل بین کیفیت مولد تولید شده و هزینه زمانی برقرار شود.

۴.۲ جهش مولد (Generator Mutation)

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

جهش هدایت‌ شده با ویژگی نادر (Rare-Feature Directed Mutation):

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

جهش تخریبی ساختار-ویژگی (Feature-Structure Havoc Mutation):

ما یک ویژگی/ساختار تصادفی را به مولدهای موجود اضافه می‌کنیم، با هدف آزادسازی قابلیت حد بالای بالقوه LLM .

جهش مبتنی بر الگو (Pattern-Based Mutation):

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

الگوریتم ۳: الگوریتم جهش مولد

				
					Input: The target file format, f⁢o⁢r⁢m⁢a⁢t.
Output: A generator, gm.
1
2s⁢t⁢a⁢t⁢e←g⁢e⁢t⁢_⁢f⁢u⁢z⁢z⁢_⁢s⁢t⁢a⁢t⁢e⁢()
3 if state==init then
4       p⁢r⁢o⁢m⁢p⁢t←c⁢o⁢n⁢s⁢t⁢r⁢u⁢c⁢t⁢_⁢p⁢r⁢o⁢m⁢p⁢t⁢(t⁢a⁢r⁢g⁢e⁢t⁢_⁢f⁢o⁢r⁢m⁢a⁢t) // Based on Fig. 5
5       f⁢e⁢a⁢t⁢u⁢r⁢e⁢s←L⁢L⁢M⁢(p⁢r⁢o⁢m⁢p⁢t)
6       for f in f⁢e⁢a⁢t⁢u⁢r⁢e⁢s do
7             g←g⁢e⁢n⁢e⁢r⁢a⁢t⁢o⁢r⁢_⁢s⁢e⁢l⁢e⁢c⁢t⁢()
8             p⁢r⁢o⁢m⁢p⁢t←c⁢o⁢n⁢s⁢t⁢r⁢u⁢c⁢t⁢_⁢p⁢r⁢o⁢m⁢p⁢t⁢(f⁢o⁢r⁢m⁢a⁢t,g,f) // Based on Fig. 6
9             gm←L⁢L⁢M⁢(p⁢r⁢o⁢m⁢p⁢t)
10             gm←s⁢e⁢l⁢f⁢_⁢d⁢e⁢b⁢u⁢g⁢(gm) // Reuse the code lines 9 - 30 in Alg. 2
11             s⁢e⁢e⁢d⁢s←r⁢u⁢n⁢(gm)
12             a⁢d⁢d⁢_⁢t⁢o⁢_⁢q⁢u⁢e⁢u⁢e⁢(s⁢e⁢e⁢d⁢s)
13if state==stall then
14       g←g⁢e⁢n⁢e⁢r⁢a⁢t⁢o⁢r⁢_⁢s⁢e⁢l⁢e⁢c⁢t⁢()
15       m⁢u⁢t⁢a⁢t⁢o⁢r←m⁢u⁢t⁢a⁢t⁢o⁢r⁢_⁢c⁢h⁢o⁢o⁢s⁢e⁢()
16       if mutator==feature or mutator==structure then
17             p⁢r⁢o⁢m⁢p⁢t←c⁢o⁢n⁢s⁢t⁢r⁢u⁢c⁢t⁢_⁢p⁢r⁢o⁢m⁢p⁢t⁢(f⁢o⁢r⁢m⁢a⁢t,g,m⁢u⁢t⁢a⁢t⁢o⁢r) // Based on Fig. 13
18            
19      else if mutator==pattern then
20             e⁢x⁢a⁢m⁢p⁢l⁢e←p⁢r⁢e⁢_⁢m⁢u⁢t⁢a⁢t⁢i⁢o⁢n⁢_⁢s⁢e⁢l⁢e⁢c⁢t⁢()
21             p⁢r⁢o⁢m⁢p⁢t←c⁢o⁢n⁢s⁢t⁢r⁢u⁢c⁢t⁢_⁢p⁢r⁢o⁢m⁢p⁢t⁢(g,e⁢x⁢a⁢m⁢p⁢l⁢e) // Based on Fig. 7
22            
23      gm←L⁢L⁢M⁢(p⁢r⁢o⁢m⁢p⁢t)
24       gm←s⁢e⁢l⁢f⁢_⁢d⁢e⁢b⁢u⁢g⁢(gm) // Reuse the code lines 9 - 30 in Alg. 2
25       s⁢e⁢e⁢d⁢s←r⁢u⁢n⁢(gm)
26       a⁢d⁢d⁢_⁢t⁢o⁢_⁢q⁢u⁢e⁢u⁢e⁢(s⁢e⁢e⁢d⁢s)

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

مرور کلی: هنگامی که فازینگ متوقف می‌شود یا مقداردهی اولیه می‌شود، G²Fuzz از جهش مولد برای تولید ورودی‌های پیچیده‌تر استفاده می‌کند. الگوریتم در الگوریتم 3 است. G²Fuzz حالت فازینگ فعلی را به دست می‌آورد (خط 1). اگر مقداردهی اولیه باشد، G²Fuzz جهش هدایت‌ شده با ویژگی‌های نادر را انجام می‌دهد. برای انجام این کار، G²Fuzz از LLMها می‌خواهد که ویژگی‌های تحلیل نشده را بر اساس اطلاعات تاریخی استخراج کنند (خطوط 3-4). برای هر ویژگی تحلیل نشده، G²Fuzz به طور تصادفی یک مولد را انتخاب می‌کند و از LLMها می‌خواهد که ویژگی تحلیل نشده را در آن بگنجانند تا ورودی‌های جدید ایجاد کنند (خطوط ۵-۱۱).

اگر یک وقفه باشد، G2FUZZ جهش تخریب ساختار ویژگی یا جهش مبتنی بر الگو را انجام می‌دهد. G²Fuzz به طور تصادفی یک مولد را از یک پایگاه داده حاوی تمام مولدهای اجرایی انتخاب می‌کند (خطوط ۱۳). سپس به طور تصادفی یک جهش‌دهنده را برای اعمال به این مولد انتخاب شده انتخاب می‌کند (خطوط ۱۴). در مرحله بعد، G²Fuzz بر اساس مولد و جهش‌دهنده انتخاب شده، یک prompt می‌سازد (خطوط ۱۵-۱۹). در نهایت، G²Fuzz یک مولد جهش‌یافته را از LLM بازیابی می‌کند، آن را برای به دست آوردن یک بذر جدید اجرا می‌کند و این بذر را برای جهش بیشتر به صف اضافه می‌کند (خطوط ۲۰-۲۳).

جهش هدایت‌ شده با ویژگی‌های نادر. برای بهبود جامعیت آزمایش ما، پوشش دهی ویژگی‌های نادری که مولدهای بخش ۴.۱ ممکن است نادیده گرفته باشند، ضروری است. مطالعه آزمایشی ما نشان می‌دهد که LLMها اغلب نمی‌توانند تمام ویژگی‌های مرتبط با یک قالب‌بندی‌ فایل را در یک درخواست واحد شناسایی کنند. معمولاً، آنها حدود ده ویژگی را به طور همزمان ارائه می‌دهند، اما اغلب ویژگی‌های نادر را نادیده می‌گیرند و نمی‌توانند آنها را مستقیماً تولید کنند.

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

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

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

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

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

فضای ویژگی یک قالب‌بندی‌ فایل اغلب وسیع است و هر ویژگی منحصر به فرد، منطق پردازش متمایزی را در برنامه هدف ایجاد نمی‌کند. تکرار همه احتمالات ناکارآمد است. در عوض، ما بر روی ویژگی‌هایی که برنامه هدف به آنها علاقه دارد، یعنی ویژگی‌های “مرتبط با برنامه”، تمرکز می‌کنیم. بذرهایی (seed) با ویژگی‌های مرتبط با برنامه، توسط برنامه هدف به طور متفاوتی پردازش خواهند شد. اگر یک بذر به دست آمده از یک مولد جهش‌یافته، مسیر جدیدی را کشف کند، استنباط می‌کنیم که این بذر حاوی ویژگی‌های مرتبط با برنامه است. در نتیجه، ما تاپل <مولد اصلی، مولد جهش‌یافته> را حاوی اطلاعات مفید در نظر می‌گیریم و آن را در پایگاه داده الگوی مفید خود قرار می‌دهیم.

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

5. ارزیابی (Evaluation)

G²Fuzz بر اساس ++AFL ساخته شده است که امکان ادغام روش ما با سایر تکنیک‌های موجود را فراهم می‌کند. برای اطمینان از دقت و منصفانه بودن نتایج، آزمایش‌هایی را روی سه پلتفرم آزمایشی انجام دادیم: UNIFUZZ، MAGMA و FuzzBench. آزمایش‌ها روی سه سیستم با سیستم عامل اوبونتو ۲۲.۰۴ انجام شد که هر کدام مجهز به ۶۴ هسته (پردازنده Intel(R) Xeon(R) Gold 6444Y) و ۲۵۶ گیگابایت حافظه بودند. ما سوالات تحقیقاتی (RQ) زیر را بررسی می‌کنیم:

پرسش پژوهشی اول (RQ1): آیا این ابزار می‌تواند از نظر پوشش دهی کد و تعداد باگ‌های منحصر به فرد از SOTA بهتر عمل کند؟

پرسش پژوهشی دوم (RQ2): آیا عملکرد G2Fuzz می‌تواند از فازرهای آگاه به ساختار (structure-aware fuzzers) پیشی بگیرد؟

پرسش پژوهشی سوم (RQ3): هنگام فاز کردن یک برنامه به مدت ۲۴ ساعت، چند توکن مصرف می‌شود؟ RQ4: کدام بخش از G²Fuzz بیشترین سهم را دارد؟

۵.۱ پوشش‌دهی کد و باگ‌های منحصر به فرد (Code Coverage and Unique Bugs)

پوشش‌دهی کد و باگ‌های منحصر به فرد، معیارهای رایجی برای ارزیابی فازرها هستند. به منظور اطمینان از انصاف (fairness) و تکرارپذیری (reproducibility)، آزمایش‌های خود را روی UNIFUZZ، MAGMA و FuzzBench انجام می‌دهیم. تمام تنظیمات زمان اجرا، از جمله بذرهای اولیه، از پیکربندی پیش‌فرض پیروی می‌کنند.

5.1.1 آزمایش‌ها روی UNIFUZZ (Experiments on UNIFUZZ)

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

مقایسه فازرها (Compared Fuzzers). عملکرد ++AFL نشان می‌دهد که پیاده‌سازی فازر به‌ طور قابل توجهی بر کارایی آزمون اثر می‌گذارد. برای جلوگیری از تأثیر تفاوت‌های پیاده‌سازی، ما G²Fuzz را بر پایه ++AFL توسعه داده‌ایم و آن را به‌ عنوان یک حالت درون ++AFL ادغام کرده‌ایم. از آنجا که ++AFL در حال حاضر بسیاری از فازرهای پیشرفته (SOTA) را در خود دارد، این امکان را فراهم می‌کند که مقایسه‌ای آسان و منصفانه بین G²Fuzz و سایر فازرهای پیاده‌سازی‌شده در ++AFL انجام شود. با توجه به این‌که دامنه ویژگی‌های گنجانده‌ شده در ++AFL از محدوده این مقاله فراتر می‌رود، ما G²Fuzz را با چهار پیکربندی پرکاربرد ++AFL مقایسه کردیم:

AFL++(cmplog): فعال‌سازی جهش دهنده REDQUEEN
AFL++(mopt): فعال‌سازی جهش دهنده MOPT
AFL++(fast): فعال‌سازی زمانبندی بذر AFLFast
AFL++(rare): اولویت‌دهی به بذرهایی که کمتر توسط بذرهای دیگر پوشش دهی داده می‌شوند.

برای G²Fuzz، حالت cmplog فعال شده است تا جهش سطح پایین کارآمد را تسهیل سازد.

انتخاب برنامه‌ها. از آنجایی که G²Fuzz برای آزمون برنامه‌هایی با ورودی‌های غیرمتنی طراحی شده است، ما برنامه‌هایی را انتخاب کردیم که این معیار را برآورده کنند. برنامه‌های هدف که در جدول ۱۷ فهرست شده‌اند، شامل ۱۰ برنامه با بیش از ۲۰ نوع قالب‌بندی‌ ورودی مختلف هستند.

جدول ۱: میانگین پوشش کد و کل خرابی‌های منحصر به فرد یافت شده توسط G2Fuzz با فازرهای مقایسه شده GPT-3.5/GPT-4 و ۶

نتایج آزمایش (Experiment Results). جدول ۱ پوشش‌دهی لبه‌ای (edge coverage) به‌ دست‌ آمده توسط هشت فازر را نشان می‌دهد. G2Fuzz (GPT-4) در مجموع ۵۹,۶۴۲ لبه کشف می‌کند که ۱۵,۴۳۷ لبه بیشتر از بهترین فازر پایه، AFL++(cmplog) است. G²Fuzz (GPT-4) و G²Fuzz (GPT-3.5) در ۹ برنامه از ۱۰ برنامه عملکرد بالاتری دارند، در حالی که AFL++(cmplog) تنها در یک برنامه عملکرد برجسته‌ای دارد.

علاوه بر این، G²Fuzz (GPT-4) قادر است بیشتر باگ‌های منحصربه‌فرد را نسبت به سایر فازرهای پایه کشف کند. به‌طور مشخص، G²Fuzz (GPT-4) تعداد ۱۴۳ باگ منحصربه‌فرد را پیدا می‌کند، که ۳۲ باگ بیشتر از بهترین فازر مقایسه‌ای (AFL++(cmplog)) است. علاوه بر این، ما پوشش دهی کد منحصر به فرد جفتی را نیز محاسبه کردیم. ما پوشش دهی کد منحصر به فرد را برای هر جفت فازر در تمام برنامه‌ها خلاصه کردیم که در شکل ۸ نشان داده شده است.

G²Fuzz (GPT-4) و G²Fuzz (GPT-3.5) کاملاً مشابه هستند و هر دو قادر به شناسایی پوشش دهی کد منحصر به فرد بیشتری نسبت به چهار فازر باقی مانده هستند. این نتیجه نشان می‌دهد که با کمک LLMها، ورودی‌هایی که ما تولید کردیم و دارای ویژگی‌های پیچیده‌ای هستند، قادر به راه‌اندازی منطق برنامه پیچیده‌تری هستند. در نتیجه، این امر منجر به کشف میزان بیشتری از پوشش کد منحصر به فرد می‌شود. G²Fuzz مراحل اضافی را در ++AFL، مانند ترکیب مولد و اجرا، گنجانده است. برای ارزیابی تأثیر این مراحل بر توان عملیاتی فازینگ (یعنی سرعت اجرا)، تعداد کل اجراها را برای هر فازر اندازه‌گیری می‌کنیم.

شکل 14 تعداد کل اجراهای انجام شده توسط تمام برنامه‌هایی را که فازرها پس از 24 ساعت اجرا می‌کنند، نشان می‌دهد. نتایج نشان می‌دهد که توان عملیاتی G²Fuzz در مقایسه با سایر فازرها به طور قابل توجهی کاهش نمی‌یابد. ما همچنین برنامه‌های خاصی را به مدت 48 ساعت فازی کردیم تا عملکرد G²Fuzz را در مراحل بعدی فازینگ مشاهده کنیم. در طول دوره ۲۴ تا ۴۸ ساعته، G²Fuzz به ترتیب ۳۲، ۵، ۱، ۳۳ و ۸۹ لبه جدید در imginfo ،jhead، mp3gain ،mp42aac و tiffsplit کشف کرد. علاوه بر این، ما هزینه‌های توکن LLMها را برای فازینگ ارزیابی کردیم. G²Fuzz با کاهش وابستگی به LLMها برای جهش، استفاده از توکن را به حداقل می‌رساند. GPT-3.5 هزینه‌هایی کمتر از ۰.۲ دلار و GPT-4 کمتر از ۱۳ دلار برای فازینگ ۲۴ ساعته متحمل می‌شود. علاوه بر این، مطالعه فرسایش نشان می‌دهد که هر دو مؤلفه G²Fuzz مؤثر هستند، به طوری که ترکیب مولد و جهش به ترتیب ۸۲۰۰۱ و ۱۴۱۳۴۰ مسیر جدید ایجاد می‌کنند. رویکردهای فقط LLM با هم رقابت می‌کنند و ضرورت ادغام را برجسته می‌کنند.

5.1.2 آزمایش‌ها روی FuzzBench (Experiments on FuzzBench)

ما همچنین برای انجام آزمایش‌های جامع‌تر، G²Fuzz را با استفاده از FuzzBench ارزیابی می‌کنیم.

تنظیمات آزمایش (Experiment Setup)، FuzzBench برای هر جفت fuzzer-benchmark یک تصویر Docker می‌سازد تا آزمایش‌ها را اجرا کند. با این حال، کانتینر حاصل اتصال اینترنتی ندارد. بنابراین، ما شرط اجرای الگوریتم تولید LLM را از «توقف/شروع» به «شروع» تغییر می‌دهیم تا یک نوع از G²Fuzz ایجاد کنیم. به طور خاص، ما ترکیب مولد ورودی و جهش مولد را زمانی اجرا می‌کنیم که فرآیند فازینگ برای اولین بار وارد حلقه فازینگ می‌شود. این به ما امکان می‌دهد الگوریتم را از قبل اجرا کنیم و نتایج را در کانتینر ساخته شده توسط FuzzBench آپلود کنیم. در نتیجه، می‌توانیم آزمایش‌ها را بدون نیاز به اتصال اینترنتی انجام دهیم. برای کاهش تصادفی بودن در تولید LLM، ما سه دوره را انجام می‌دهیم .

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

انتخاب برنامه‌ها (Programs Selection). از آنجایی که G²Fuzz فقط برای ورودی‌های غیر متنی مناسب است، برنامه‌هایی با ورودی‌های متنی را حذف کردیم و 11 برنامه را برای آزمایش G²Fuzz باقی گذاشتیم، همانطور که در جدول 17 ذکر شده است.

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

نتایج آزمایش (Experiment Results). همان‌طور که در جدول ۲ نشان داده شده است، عملکرد G²Fuzz در گروه‌های مختلف آزمایشی پایدار باقی می‌ماند. G²Fuzz در هر سه گروه آزمایشی بهترین رتبه‌ها را کسب می‌کند که به ترتیب ۲.۰۹، ۲.۱۸ و ۲.۱۸ هستند.

دومین فازر برتر، ++AFL، به ترتیب در این گروه‌ها رتبه‌های ۲.۷۳، ۲.۷۳ و ۲.۹۱ را کسب می‌کند. در شکل ۹، همچنین توزیع پوشش دهی کد برای همه فازرها در تمام برنامه‌های یک گروه آزمایشی ارائه شده است. گزارش کامل از اینجا قابل دسترس می‌باشد. G²Fuzz بهترین عملکرد را در ۵ برنامه از ۱۱ برنامه دارد، در حالی که LibAFL و ++AFL هر کدام در دو برنامه عملکرد برجسته‌ای دارند و LibFuzzer و FairFuzz هر کدام در یک برنامه عملکرد برتری نشان می‌دهند.

الگوریتم تولید توسط LLM اثربخشی قابل توجهی در برخی برنامه‌ها نشان می‌دهد، مانند vorbis_decode_fuzzer. ما میانگین تغییرات پوشش دهی کد در طول زمان برای vorbis_decode_fuzzer را در شکل ۱۵ نشان داده‌ایم. قابل توجه است که مشاهده می‌کنیم G²Fuzz پس از ۱۵ دقیقه پوشش دهی کد بالاتری نسبت به همه فازرهای مقایسه‌ای پس از ۲۳ ساعت به دست می‌آورد. این موضوع توانایی G²Fuzz در تولید ساختارهای متنوع و پیچیده را برجسته می‌کند و امکان کشف بخش‌های کدی را فراهم می‌آورد که برای فازرهای متداول دشوار است.

جدول 2: رتبه‌بندی فازرهای Fuzzbench. این جدول میانگین رتبه فازرها را پس از رتبه‌بندی آنها در هر معیار بر اساس میانگین پوشش‌دهی کد رسیده آنها (کمتر بهتر است) گزارش می‌دهد.

زمان تحلیل اضافی (Additional Analysis Time). از آنجایی که ما الگوریتم تولید LLM را قبل از آزمایش‌ها اجرا می‌کنیم، G²Fuzz در مقایسه با سایر فازرها زمان فازینگ بیشتری دارد. برای ارزیابی تأثیر آن، زمان تحلیل اضافی را برای هر برنامه، همانطور که در جدول 18 نشان داده شده است، تجزیه و تحلیل می‌کنیم. برنامه‌ای که بیشترین زمان اضافی را دارد، bloaty_fuzz_target با 925 ثانیه (1.06٪ از 23 ساعت زمان فازینگ) است، در حالی که zlib_zlib_uncompress_fuzzer کمترین زمان را با 163 ثانیه (0.19٪) نیاز دارد. هشت برنامه از 11 برنامه به کمتر از 500 ثانیه (0.6٪) نیاز دارند. ما همچنین دریافتیم که ۱۵ دقیقه اضافی مورد نیاز برای تولید LLM هیچ تاثیری بر پوشش دهی کد میانه پس از ۲۳ ساعت نداشته است، همانطور که در جدول ۱۹ نشان داده شده است.

۵.۱.۳ آزمایش‌ها روی MAGMA (Experiments on MAGMA)

پوشش دهی کد و باگ‌های منحصربه‌فرد از جمله معیارهای کلیدی هستند، اما کشف CVEهای واقعی به‌طور مستقیم توانایی یک فازر در یافتن آسیب‌پذیری‌های امنیتی با تأثیر واقعی را نشان می‌دهد. برای جلوگیری از سوگیری، ما آزمایش‌ها را روی MAGMA انجام می‌دهیم، یک بنچمارک فازینگ با حقیقت زمینه (ground-truth) که شامل باگ‌های واقعی است و امکان ارزیابی دقیق عملکرد را فراهم می‌کند.

ما G²Fuzz را در MAGMA ادغام کرده و آن را با پنج فازر دیگر مقایسه می‌کنیم: AFL++، MOPT، AFLFast، LibFuzzer، و Entropic. تمامی فازرهای مرتبط با ++AFL در این آزمایش بر اساس AFL++ (commit 1d17210) بوده و جهش دهنده RedQueen فعال شده است. برنامه‌هایی با ورودی‌های متنی مستثنی شده‌اند. جدول ۱۷ برنامه‌های هدف استفاده‌شده در MAGMA را نشان می‌دهد. نوع قالب‌بندی‌ ورودی با توجه به پسوند نام فایل‌های بذرهایی اولیه تعیین شده است. برای openssl، از آنجا که دانه‌های اولیه MAGMA فاقد پسوند هستند، از نظر آزمایش حذف شده است. برای کاهش اثر تصادفی، آزمایش‌ها پنج بار تکرار شده‌اند.

ما تعداد CVEهای کشف‌ شده توسط هر فازر را تحلیل می‌کنیم که نتایج آن در جدول ۳ ارائه شده است. نتایج نشان می‌دهد که G²Fuzz بهترین عملکرد را در بنچمارک MAGMA دارد و بیشترین باگ‌ها را در همه برنامه‌ها کشف کرده است. به طور مشخص، G²Fuzz در libpng_read_fuzzer، tiff_read_rgba_fuzzer، tiffcp، pdf_fuzzer، pdftoppm و pdfimages بهترین عملکرد را دارد و به ترتیب ۳، ۵، ۷، ۵، ۶ و ۶ باگ را آشکار می‌کند.

جدول ۳: مجموع CVEهای کشف‌شده (روی MAGMA). G²Fuzz بهترین عملکرد را در کشف CVEهای واقعی دارد

۵.۱.۴ کشف باگ‌ها در نسخه‌های جدید برنامه‌ها (Finding Bugs in Latest Program Versions)

برای ارزیابی توانایی G²Fuzz در کشف باگ‌های واقعی، ما جدیدترین نسخه‌های پروژه‌ها از UNIFUZZ را همراه با تمام برنامه‌های اجرایی دیگر موجود در این پروژه‌ها که برای فازینگ مناسب هستند آزمایش می‌کنیم. هر جفت فازر-برنامه به مدت ۲۴ ساعت اجرا شده و ۵ بار تکرار می‌شود. مطابق با توصیه UNIFUZZ، از سه تابع برتر خروجی ASAN برای حذف باگ‌های تکراری (de-duplicate uncovered bugs) استفاده می‌کنیم. نتایج در جدول ۴ ارائه شده است. G²Fuzz در مجموع ۱۰ باگ کشف می‌کند، در حالی که بهترین فازر مقایسه‌ای، AFL++(cmplog)، تنها ۵ باگ را شناسایی می‌کند.

قابل توجه است که ۴ باگ منحصراً توسط G²Fuzz کشف شده و توسط هیچ یک از فازرهای مقایسه‌ای دیگر شناسایی نشده‌اند. تا زمان نگارش این مقاله، این باگ‌ها به توسعه‌دهندگان گزارش شده‌اند و ۳ مورد از آن‌ها توسط CVE تأیید شده‌اند:

CVE-2024-57509 (در mp42avc)
CVE-2024-57510 (در mp42avc)
CVE-2024-57513 (در mp42hevc)

جدول ۴: باگ‌های واقعی کشف‌ شده توسط هر فازر

۵.۱.۵ طبقه‌بندی قالب‌های فایل پردازش‌ شده (Classification of Handled File Formats)

در آزمایش‌های فوق در سه پلتفرم، ما از G²Fuzz برای ارزیابی کارایی آن در پردازش قالب‌بندی‌ مختلف فایل استفاده کرده‌ایم. همان‌طور که در جدول ۵ نشان داده شده است، G²Fuzz با موفقیت انواع قالب‌بندی‌‌های تصویر شامل JPG، GIF، BMP و PNG و همچنین چند قالب‌بندی‌ صوتی و ویدیویی مانند MP3 ،WAV ،MP4 و FLV را پردازش می‌کند. علاوه بر این، G²Fuzz توانایی پردازش اسناد PDF و قالب‌های مختلف فونت مانند TTF و OTF را نشان می‌دهد. از نظر قالب فایل، این ابزار از قالب‌هایی مانند ELF، Mach_O و WebAssembly نیز پشتیبانی می‌کند. تمامی برنامه‌های مرتبط با این ۳۴ قالب در آزمایش‌های قبلی ارزیابی شده‌اند. این یافته‌ها نشان‌دهنده عملکرد قوی G²Fuzz در فازینگ طیف متنوعی از انواع فایل‌ها است. شرایط ساخت قالب‌بندی‌‌های مختلف فایل متفاوت است: برخی قالب‌بندی‌‌ها توسط کتابخانه‌های خاص پشتیبانی می‌شوند، در حالی که برخی دیگر نه. ما این شرایط را به سه سطح طبقه‌بندی می‌کنیم:

L1: قالب هدف دارای کتابخانه‌های خاصی است که می‌توانند به‌ طور مستقیم فایل تولید کنند.
L2: برخی اجزای قالب را می‌توان با استفاده از کتابخانه‌های موجود تولید کرد و سپس این اجزا بر اساس قواعد نحوی قالب هدف سازماندهی می‌شوند.
L3: فایل‌ها به‌طور کامل از صفر تولید می‌شوند و تنها بر اساس قواعد نحوی قالب‌بندی‌ هدف ساخته می‌شوند.

از میان ۳۴ قالب‌بندی‌ آزمایش‌ شده، ۲۳ قالب در L1 و ۳ قالب در L2 و ۸ قالب‌بندی‌ در L3 قرار دارند. قالب‌بندی‌های سطح L1 معمولاً تولیدکننده‌های باکیفیت‌تری ایجاد می‌کنند، زیرا کتابخانه‌های پشتیبان که اغلب با مستندات، نمونه کد و منابع دیگر همراه هستند در داده‌های آموزش LLM گنجانده شده‌اند، که باعث افزایش تنوع و دقت فایل‌های تولید شده می‌شود. با این حال، ما همچنین تولیدکننده‌های با کیفیت مناسب برای قالب‌بندی‌های L2 و L3 مشاهده کرده‌ایم، که مقاومت و توانایی G²Fuzz در پردازش قالب‌بندی‌های مختلف را نشان می‌دهد.

جدول ۵: طبقه‌بندی قالب‌های مدیریت‌ شده توسط G²Fuzz

۵.۲ مقایسه با فازرهای آگاه به ساختار (Compared with Structure-Aware Fuzzers

ما G²Fuzz را با FormatFuzzer فازر آگاه از دستور زبان SOTA، و فازر مبتنی بر استنتاج SOTA، WEIZZ، با استفاده از معیار UNIFUZZ مقایسه می‌کنیم. ما با AFLSmart مقایسه‌ای انجام نمی‌دهیم، زیرا این فازر قبلاً در FuzzBench مقایسه شده است و G²Fuzz عملکرد قابل توجهی بهتر از AFLSmart دارد. میانگین رتبه پوشش دهی کد G²Fuzz برابر با ۲.۱۵ و AFLSmart برابر با ۶.۷۳ است. با توجه به فاصله قابل توجه، آزمایش‌های اضافی در اینجا انجام نشده است. ما با Superion، Nautilus و Grimoire مقایسه نمی‌کنیم، زیرا این فازرها تنها بر روی قالب‌بندی‌ ورودی دستور زبان مبتنی بر متن ارزیابی شده‌اند. علاوه بر این، FuzzInMem، ProFuzzer و GreyOne نیز شامل مقایسه نمی‌شوند، زیرا این فازرها متن‌باز نشده‌اند.

جدول ۶: میانگین پوشش دهی خط کشف شده توسط G²Fuzz ، FormatFuzzer و WEIZZ

جدول ۷: توابعی که منحصراً توسط هر فازر کشف می‌شوند

از آنجا که G²Fuzz ،FormatFuzzer و WEIZZ از روش‌های ابزارگذاری (instrumentation) متفاوت استفاده می‌کنند، ممکن است با ورودی‌های یکسان سطح پوشش دهی لبه (edge coverage) متفاوتی داشته باشند. برای اندازه‌گیری دقیق پوشش دهی خطوط کد (line coverage)، از afl-cov استفاده می‌کنیم. نتایج در جدول ۶ ارائه شده است. برای روشن شدن موضوع، ما با اجرای برخی برنامه‌ها با FormatFuzzer و WEIZZ با مشکلاتی مواجه شدیم. به طور مشخص:

FormatFuzzer هنگام تستmp42aac تعداد زیادی فایل core*. تولید کرد که بیش از ۵۰۰ گیگابایت حافظه در عرض ۱۰ ساعت مصرف شد.
همچنین هنگام ساخت تولیدکننده‌های MP3 برای mp3gain مطابق دستورالعمل‌های FormatFuzzer با خطا مواجه شدیم.
FormatFuzzer برای تست pdftotext،tiffsplit و flvmeta مناسب نیست، زیرا از قالب‌های PDF ،TIFF و FLV پشتیبانی نمی‌کند.
در مورد WEIZZ، قادر به کامپایل gdk-pixbuf نبودیم.

در ۹ برنامه از ۱۰ برنامه، G²Fuzz پوشش دهی خطوط کد بالاتری نسبت به FormatFuzzer و WEIZZ کسب می‌کند. به عنوان مثال، در برنامه‌های exiv2، ffmpeg، imginfo و gdk ،G²Fuzz بیش از دو برابر پوشش‌دهی خطوط کد FormatFuzzer را به دست می‌آورد.

بر خلاف FormatFuzzer که مبتنی بر دستور زبان است، G²Fuzz مقیاس‌پذیر بوده و قابلیت پشتیبانی از طیف گسترده‌تری از برنامه‌ها با قالب‌بندی‌‌های مختلف ورودی را دارد. علاوه بر این، معمولاً یک برنامه چندین قالب‌بندی‌ ورودی را می‌پذیرد، در حالی که FormatFuzzer تنها قادر به پردازش یک قالب‌بندی‌ در هر زمان است، که می‌تواند تنوع ورودی‌های تولید شده را کاهش دهد.

برای تأیید بیشتر این که فایل‌های تولید شده توسط G²Fuzz با ویژگی‌های پیچیده به کشف منطق‌های پیچیده‌تر برنامه کمک می‌کنند، ما تعداد توابعی که منحصراً توسط هر فازر کشف شده‌اند را اندازه‌گیری می‌کنیم. در اینجا، «منحصراً» به توابعی اشاره دارد که توسط هیچ فازر دیگری کشف نشده‌اند. فازری که توابع منحصربه‌فرد بیشتری پیدا کند، نشان‌دهنده توانایی آن در فعال‌سازی منطق‌های ظریف‌تر برنامه است.

نتایج در جدول ۷ ارائه شده است. در ۹ برنامه از ۱۰ برنامه، G²Fuzz بیشترین تعداد توابع منحصربه‌فرد را شناسایی کرده است، که اثربخشی استفاده از LLMها برای تولید ورودی‌های باینری پیچیده را تأیید می‌کند.

5.3 مقایسه G²Fuzz با Fuzztruction (Compared with Fuzztruction)

ما به منظور مقایسه با Fuzztruction، از G²Fuzz برای تولید دسته‌ای از بذرهای اولیه و انجام آزمایش‌ها در محیط Docker ارائه شده توسط Fuzztruction استفاده کردیم و اطمینان حاصل نمودیم که همه پارامترهای آزمایشی ثابت می‌مانند. ما 9 برنامه استفاده شده توسط Fuzztruction را آزمایش کردیم. با این حال، سه برنامه فاقد پسوند فایل ورودی واضح بودند و با G²Fuzz سازگار نمی‌باشند.

آزمایش‌ها به مدت 6 ساعت اجرا و 5 مرتبه تکرار شدند و نسخه‌های همه برنامه‌های آزمایشی با نسخه‌های آزمایش شده توسط Fuzztruction سازگار هستند. میانگین پوشش دهی در جدول 8 نشان داده شده است. به طور کلی، G²Fuzz در هفت برنامه از نُه برنامه، از Fuzztruction بهتر عمل می‌کند. G²Fuzz از نظر معنایی فایل‌هایی با ساختارهای مختلف را از ابتدا می‌سازد، در حالی که مولد Fuzztruction (که در درجه اول یک مبدل (converter) است) هنوز به بذرهای اولیه ساختاریافته نیاز دارد و جهش سطح بیتی آن فقط تنظیمات ظریفی را انجام می‌دهد.

با این حال، Fuzztruction در برنامه‌هایی که از فایل‌های zip استفاده می‌کنند، عملکرد بهتری دارد. ما معتقدیم که G²Fuzz به دلیل عملکرد محدود کتابخانه‌های پایتون برای ساخت فایل‌های zip، که پوشش دهی ویژگی‌های فایل را محدود می‌کند، باگ‌های کمتری پیدا می‌کند. ما کیفیت بذر G²Fuzz و Fuzztruction را با اندازه‌گیری پوشش‌دهی ویژگی مقایسه می‌کنیم. در این آزمایش، G²Fuzz فقط در مرحله اولیه بذر تولید می‌کند، در حالی که Fuzztruction به طور مداوم بذر (seed) تولید می‌کند. برای اطمینان از انصاف، پوشش دهی ویژگی G²Fuzz و Fuzztruction را با استفاده از تعداد بذرهای تولید شده یکسان مقایسه می‌کنیم، و تعداد بذرهای تولید شده توسط G²Fuzz به عنوان پایه عمل می‌کند.

ما برای انتخاب برنامه، تمام برنامه‌هایی را که ورودی‌های تصویر یا سند، از جمله pngtopng، pdftotext و qpdf را دریافت می‌کنند، هدف قرار می‌دهیم. در Fuzztruction، فایل‌های PDF تولید شده توسط مولد qpdf به دلیل گزینه‌های رمز عبور غیرقابل تجزیه، حذف می‌شوند. نتایج در جدول 9 نشان داده شده است که نشان می‌دهد G²Fuzz ویژگی‌های منحصر به فرد بیشتری نسبت به Fuzztruction کشف می‌کند. از نظر نسبت اعتبار، G²Fuzz نسبت اعتبار بالاتری برای PNGها و PDFها در مقایسه با Fuzztruction به دست می‌آورد. علاوه بر این، G²Fuzz ویژگی‌های نادرتری مانند Properties-Digital Signature- و Properties-png:PLTE.number_colors را در فایل‌های PNG کشف می‌کند که Fuzztruction نمی‌تواند آنها را پوشش دهد.

بجدول 8: میانگین پوشش (در بلوک‌های پایه) و باگ‌های کشف شده توسط Fuzztruction و G²Fuzz. قالب ورودی برنامه Fuzztruction G²Fuzz

جدول ۹: توابعی که منحصراً توسط هر فازر کشف می‌شوند

۵.۴ پوشش‌دهی ویژگی (Feature Coverage)

ما به منظور تأیید اینکه آیا G²Fuzz می‌تواند ویژگی‌های فایلی (file features) را تولید کند که سایر فازرها نمی‌توانند پوشش دهند، پوشش ویژگی (feature coverage) هر فازر را مقایسه می‌کنیم. محاسبه پوشش ویژگی به دلیل عدم وجود یک روش کمّی‌سازی یکپارچه چالش برانگیز است. بنابراین، ما از ImageMagick برای استخراج ویژگی‌های هر بذر، مانند نوع فشرده‌سازی (compression type)، استفاده می‌کنیم و هر ویژگی را به عنوان یک ویژگی در نظر می‌گیریم. سپس ویژگی‌های نامربوطی را که در اکثر فایل‌ها متفاوت هستند، مانند نام فایل، به صورت دستی حذف می‌کنیم.

ما چهار قالب‌بندی‌ TIFF ،JPG ،MP4 و PDF را از بخش 5.1.1 برای تجزیه و تحلیل انتخاب می‌کنیم که شامل فایل‌های تصویری، فایل‌های ویدیویی و اسناد پیچیده می‌شود. نتایج در جدول 10 نشان داده شده است. G2Fuzz (با استفاده از GPT-4) به بالاترین پوشش ویژگی برای TIFF ،JPG و MP4 دست می‌یابد. ++AFL بیشتر بر جهش‌های سطح پایین تمرکز دارد که برای اصلاح ویژگی‌های سطح بالا تلاش می‌کنند. تغییر ویژگی‌های سطح بالا نیاز به مدیریت محدودیت‌های چندین بخش به طور همزمان دارد که برای جهش سطح بایت بسیار چالش برانگیز است.

در مقابل، G²Fuzz می‌تواند مولد را از نظر معنایی جهش دهد یا بذرهایی با ویژگی‌های هدف از ابتدا تولید کند و پوشش وسیع‌تری از ویژگی‌های فایل سطح بالا را فراهم کند. توجه داشته باشید که ImageMagick فقط می‌تواند ورودی‌های معتبر را تجزیه کند، در حالی که اکثر بذرهای تولید شده توسط جهش‌های ++AFL نامعتبر هستند و در نتیجه پوشش ویژگی کمتری برای ++AFL ثبت می‌شود. به عنوان مثال، جهش‌های ++AFL نمی‌توانند فایل‌های MP4 معتبر تولید کنند و در نتیجه پوشش ویژگی برابر با 0 است.

++AFL (نادر) و ++AFL (سریع)، در قالب PDF، ویژگی‌های بیشتری را از نظر چولگی یا کج‌شکلی (skewness)، کشیدگی (kurtosis) و انحراف معیار (standard deviation) در کانال‌های آبی/سبز/قرمز پوشش می‌دهند. بذرهایی با چنین ویژگی‌هایی وزن‌های بالاتری در ++AFL (نادر) و ++AFL (سریع) دریافت می‌کنند که منجر به جهش‌های مکررتر و در نتیجه پوشش بالاتر این ویژگی‌ها می‌شود. با این حال، از منظر پوشش نهایی کد، اختصاص انرژی بیش از حد برای بررسی چنین ویژگی‌هایی ناکارآمد است.

G²Fuzz می‌تواند برخی از ویژگی‌های نادر مانند Properties-tiff:timestamp، Properties-tiff:copyright و Properties-Contact را در فایل‌های TIFF ایجاد کند. علاوه بر این، G²Fuzz برای فشرده‌سازی Chromaticity، می‌تواند هر چهار روش فشرده‌سازی Zip، RLE، JPEG و LZW را پوشش دهد، در حالی که سایر فازرها فقط می‌توانند RLE و JPEG را پوشش دهند. ما مشاهده می‌کنیم که پوشش ویژگی‌های نادر می‌تواند منطق برنامه خاص را در برنامه هدف بهتر فعال کند و در نتیجه پوشش کد را بهبود بخشد.

جدول 10: پوشش ویژگی تحت پوشش دهی هر فازر

5.5 تعمیم‌پذیری در LLMها (Generalizability Across LLMs)

برای نشان دادن تعمیم‌پذیری G²Fuzz در LLMهای مختلف، مدل‌های منبع باز llama-3-8b-instruct و llama-3-70b-instruct را برای آزمایش‌های خود انتخاب می‌کنیم. تحت همان تنظیمات، این مدل‌ها برای پنج قالب‌بندی‌ فایل، دانه‌های اولیه تولید می‌کنند و ترکیب مولد ورودی و جهش مولد را در مرحله مقداردهی اولیه تکمیل می‌کنند. برای GPT-3.5 و GPT-4، ما از بذرهای اولیه تولید شده از اولین دوره آزمایش‌ها برای JPG، TIFF، MP3، MP4 و PDF با G²Fuzz روی exiv2، tiffsplit، mp3gain، mp42aac و pdftotext دوباره استفاده می‌کنیم. فقط فایل‌هایی با پسوند قالب‌بندی‌ هدف در نظر گرفته می‌شوند، زیرا مولد ممکن است فایل‌هایی با قالب‌های دیگر تولید کند. نتایج در جدول 11 نشان داده شده است. GPT-4 به بالاترین پوشش‌دهی ویژگی برای JPG و PDF دست می‌یابد، در حالی که مدل‌های متن‌باز llama-3-8b-instruct و llama-3-70b-instruct به ترتیب به بالاترین پوشش دهی ویژگی برای TIFF و MP4 دست می‌یابند. نکته قابل توجه این است که llama-3-70b-instruct در هر چهار قالب‌بندی‌ از GPT-3.5 بهتر عمل می‌کند. این نتایج، مقیاس‌پذیری G²Fuzz و توانایی آن در تولید مولدهای با کیفیت بالا با استفاده از مدل‌های متن‌باز را نشان می‌دهد.

ما همچنین اثربخشی اعلان مورد استفاده توسط G²Fuzz را با 10 فرمت مختلف (از جمله تصاویر، ویدیوها و اسناد) ارزیابی می‌کنیم و متوجه می‌شویم که GPT-4 در اکثر قالب‌بندی‌‌ها عملکرد خوبی دارد. جزئیات بیشتر را می‌توانید در پیوست D بیابید. علاوه بر این، ما تأثیر کتابخانه‌های مختلف را بر کیفیت مولد تجزیه و تحلیل می‌کنیم و متوجه می‌شویم که همکاری بین چندین کتابخانه کارآمدترین رویکرد است.

جدول 11: توابعی که منحصراً توسط هر فازر کشف می‌شوند

1 -: GPT-3.5 به دلیل تصادفی بودن نمی‌تواند فایل‌های MP4 معتبر را در طول دور اول تولید کند.

6. بحث (Discussion)

G²Fuzz فقط از قالب‌بندی‌‌های فایلی پشتیبانی می‌کند که کتابخانه‌های مولد همراه آنها موجود است. با این وجود، می‌تواند با مشخصات قالب‌بندی‌ فایل نوشته شده توسط کاربر (با استفاده از دستوراتی مانند “کد مولد پایتون را بر اساس مشخصات قالب‌بندی‌ ارائه شده تولید کنید”) ادغام شود. بنابراین، پشتیبانی از موارد گوشه‌ای یا قالب‌بندی‌های فایل جدید فقط به مهندسی اضافی و تلاش دستی نیاز دارد. مهمتر از همه، ما شاهد روند دلگرم‌کننده‌ای از کتابخانه‌های پایتون نوظهور برای تولید فایل هستیم (جستجوی JPEG و MP4 در GitHub به ترتیب ۲۱ و ۲۶ کتابخانه تولید/ویرایش فایل را نشان می‌دهد که در سه سال گذشته ایجاد شده‌اند)؛ این نشان دهنده قابلیت بالای توسعه‌پذیری G²Fuzz برای سازگاری با قالب‌های جدید بدون تغییر کد است. به طور کلی، با استفاده از کتابخانه‌های موجود و نوظهور، G²Fuzz می‌تواند از قالب‌های فایل بیشتری پشتیبانی کند، در نتیجه کارایی فازینگ را در طیف وسیع‌تری از سناریوها و به صورت مداوم بهبود می‌بخشد. علاوه بر این، G²Fuzz در حال حاضر قادر به مدیریت قالب‌بندی‌‌های سفارشی نیست. این محدودیت را می‌توان با افزودن قابلیت‌های تجزیه سند، که به LLMها اجازه می‌دهد تا نحو سفارشی را یاد بگیرند و با آن سازگار شوند، کاهش داد. ما این را به کارهای آینده موکول می‌کنیم.

۷. نتیجه‌گیری

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

منابع

				
					[1] Dall-e-3. https://openai.com/index/dall-e-3/.
[2] honggfuzz. https://github.com/google/honggfuzz.
[3] Baleegh Ahmad, Shailja Thakur, Benjamin Tan, Ramesh Karri, and Hammond Pearce. On hardware security bug code fixes by prompting large language models. TIFS, 2024.
[4] Maria Alabdulrahman, Renad Khayyat, Kawthar Almowallad, and Zahra Alharz. Sarid: Arabic storyteller using a fine-tuned llm and text-to-image generation. In ICCAE, 2024.
[5] Cornelius Aschermann, Tommaso Frassetto, Thorsten Holz, Patrick Jauernig, Ahmad-Reza Sadeghi, and Daniel Teuchert. Nautilus: Fishing for deep bugs with grammars. In NDSS, 2019.
[6] Cornelius Aschermann, Sergej Schumilo, Tim Blazytko, Robert Gawlik, and Thorsten Holz. Redqueen: Fuzzing with input-to-state correspondence. In NDSS, 2019.
[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, 2023.
[8] Tim Blazytko, Matt Bishop, Cornelius Aschermann, Justin Cappos, Moritz Schlögel, Nadia Korshun, Ali Abbasi, Marco Schweighauser, Sebastian Schinzel, Sergej Schumilo, et al. {GRIMOIRE}: Synthesizing structure while fuzzing. In USENIX Security, 2019.
[9] Yinlin Deng, Chunqiu Steven Xia, Haoran Peng, Chenyuan Yang, and Lingming Zhang. Large language models are zero-shot fuzzers: Fuzzing deep-learning libraries via large language models. In ISSTA, 2023.
[10] Yinlin Deng, Chunqiu Steven Xia, Chenyuan Yang, Shizhuo Dylan Zhang, Shujing Yang, and Lingming Zhang. Large language models are edge-case generators: Crafting unusual programs for fuzzing deep learning libraries. In ICSE, 2024.
[11] Tuan Dinh, Jinman Zhao, Samson Tan, Renato Negrinho, Leonard Lausen, Sheng Zha, and George Karypis. Large language models of code fail at completing code with potential bugs. NeurIPS, 2024.
[12] Brendan Dolan-Gavitt. Is “ai” useful for fuzzing? (keynote). In FUZZING Workshop, 2024.
[13] Rafael Dutra, Rahul Gopinath, and Andreas Zeller. Formatfuzzer: Effective fuzzing of binary file formats. TOSEM, 2023.
[14] Martin Eberlein, Yannic Noller, Thomas Vogel, and Lars Grunske. Evolutionary grammar-based fuzzing. In SSBSE, 2020.
[15] Andrea Fioraldi, Daniele Cono D’Elia, and Emilio Coppa. Weizz: Automatic grey-box fuzzing for structured binary formats. In ISSTA, 2020.
[16] Andrea Fioraldi, Dominik Maier, Heiko Eißfeldt, and Marc Heuse. {AFL++}: Combining incremental steps of fuzzing research. In WOOT, 2020.
[17] Shuitao Gan, Chao Zhang, Peng Chen, Bodong Zhao, Xiaojun Qin, Dong Wu, and Zuoning Chen. {GREYONE}: Data flow sensitive fuzzing. In USENIX Security, 2020.
[18] Hanan Gani, Shariq Farooq Bhat, Muzammal Naseer, Salman Khan, and Peter Wonka. Llm blueprint: Enabling text-to-image generation with complex and detailed prompts. arXiv, 2023.
[19] Patrice Godefroid, Adam Kiezun, and Michael Y. Levin. Grammar-based whitebox fuzzing. In Proceedings of the 29th ACM SIGPLAN Conference on Programming Language Design and Implementation, PLDI ’08, pages 206–215. ACM, 2008.
[20] Daya Guo, Canwen Xu, Nan Duan, Jian Yin, and Julian McAuley. Longcoder: A long-range pre-trained language model for code completion. In ICML, 2023.
[21] Tao Guo, Puhan Zhang, Xin Wang, and Qiang Wei. Gramfuzz: Fuzzing testing of web browsers based on grammar analysis and structural mutation. In ICIA, 2013.
[22] Ahmad Hazimeh, Adrian Herrera, and Mathias Payer. Magma: A ground-truth fuzzing benchmark. POMACS, 2020.
[23] Renáta Hodován, Ákos Kiss, and Tibor Gyimóthy. Grammarinator: a grammar-based open source fuzzer. In A-TEST, 2018.
[24] Hui Huang, Shuangzhi Wu, Xinnian Liang, Bing Wang, Yanrui Shi, Peihao Wu, Muyun Yang, and Tiejun Zhao. Towards making the most of llm for translation quality estimation. In NLPCC, 2023.
[25] Nikhil Kandpal, Haikang Deng, Adam Roberts, Eric Wallace, and Colin Raffel. Large language models struggle to learn long-tail knowledge. In ICML, 2023.
[26] Jaehyung Kim, Dongyoung Kim, and Yiming Yang. Learning to correct for qa reasoning with black-box llms. arXiv, 2024.
[27] Xuan-Bach D Le, Corina Pasareanu, Rohan Padhye, David Lo, Willem Visser, and Koushik Sen. Saffron: Adaptive grammar-based fuzzing for worst-case analysis. SEN, 2021.
[28] Caroline Lemieux and Koushik Sen. Fairfuzz: A targeted mutation strategy for increasing greybox fuzz testing coverage. In ASE, 2018.
[29] Manling Li, Ruochen Xu, Shuohang Wang, Luowei Zhou, Xudong Lin, Chenguang Zhu, Michael Zeng, Heng Ji, and Shih-Fu Chang. Clip-event: Connecting text and images with event structures. In CVPR, pages 16420–16429, 2022.
[30] Yuwei Li, Shouling Ji, Yuan Chen, Sizhuang Liang, Wei-Han Lee, Yueyao Chen, Chenyang Lyu, Chunming Wu, Raheem Beyah, Peng Cheng, et al. {UNIFUZZ}: A holistic and pragmatic {Metrics-Driven} platform for evaluating fuzzers. In USENIX Security, 2021.
[31] Fang Liu, Ge Li, Yunfei Zhao, and Zhi Jin. Multi-task learning based pre-trained language model for code completion. In ASE, 2020.
[32] Xuwei Liu, Wei You, Yapeng Ye, Zhuo Zhang, Jianjun Huang, and Xiangyu Zhang. Fuzzinmem: Fuzzing programs via in-memory structures. In ICSE, 2024.
[33] Yuwei Liu, Siqi Chen, Yuchong Xie, Yanhao Wang, Libo Chen, Bin Wang, Yingming Zeng, Zhi Xue, and Purui Su. Vd-guard: Dma guided fuzzing for hypervisor virtual device. In ASE, 2023.
[34] Yujie Lu, Xianjun Yang, Xiujun Li, Xin Eric Wang, and William Yang Wang. Llmscore: Unveiling the power of large language models in text-to-image synthesis evaluation. NeurIPS, 2024.
[35] 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, 2019.
[36] Chenyang Lyu, Shouling Ji, Xuhong Zhang, Hong Liang, Binbin Zhao, Kangjie Lu, and Raheem Beyah. Ems: History-driven mutation for coverage-based fuzzing. In NDSS, 2022.
[37] Ruijie Meng, Martin Mirchev, Marcel Böhme, and Abhik Roychoudhury. Large language model guided protocol fuzzing. In NDSS, 2024.
[38] Jonathan Metzman, László Szekeres, Laurent Simon, Read Sprabery, and Abhishek Arya. Fuzzbench: an open fuzzer benchmarking platform and service. In FSE, 2021.
[39] Soyeon Park, Wen Xu, Insu Yun, Daehee Jang, and Taesoo Kim. Fuzzing javascript engines with aspect-preserving mutation. In SP, 2020.
[40] Hammond Pearce, Benjamin Tan, Baleegh Ahmad, Ramesh Karri, and Brendan Dolan-Gavitt. Examining zero-shot vulnerability repair with large language models. In SP, 2023.
[41] Van-Thuan Pham, Marcel Böhme, Andrew E Santosa, Alexandru Răzvan Căciulescu, and Abhik Roychoudhury. Smart greybox fuzzing. TSE, 2019.
[42] Jonathan Pilault, Raymond Li, Sandeep Subramanian, and Christopher Pal. On extractive and abstractive neural document summarization with transformer language models. In EMNLP, 2020.
[43] Leigang Qu, Haochuan Li, Tan Wang, Wenjie Wang, Yongqi Li, Liqiang Nie, and Tat-Seng Chua. Unified text-to-image generation and retrieval. arXiv, 2024.
[44] Aditya Ramesh, Mikhail Pavlov, Gabriel Goh, Scott Gray, Chelsea Voss, Alec Radford, Mark Chen, and Ilya Sutskever. Zero-shot text-to-image generation. In ICML, 2021.
[45] Aryan Rangapur and Aman Rangapur. The battle of llms: A comparative study in conversational qa tasks. arXiv, 2024.
[46] Kuniaki Saito, Kihyuk Sohn, Chen-Yu Lee, and Yoshitaka Ushiku. Unsupervised llm adaptation for question answering. arXiv, 2024.
[47] Sevak Sargsyan, Shamil Kurmangaleev, Matevos Mehrabyan, Maksim Mishechkin, Tsolak Ghukasyan, and Sergey Asryan. Grammar-based fuzzing. In IVMEM, 2018.
[48] Dongdong She, Adam Storek, Yuchong Xie, Seoyoung Kweon, Prashast Srivastava, and Suman Jana. Fox: Coverage-guided fuzzing as online stochastic control. In CCS, 2024.
[49] Prashast Srivastava and Mathias Payer. Gramatron: Effective grammar-aware fuzzing. In ISSTA, 2021.
[50] Liyan Tang, Zhaoyi Sun, Betina Idnay, Jordan G Nestor, Ali Soroush, Pierre A Elias, Ziyang Xu, Ying Ding, Greg Durrett, Justin F Rousseau, et al. Evaluating large language models on medical evidence summarization. npj Digital Medicine, 2023.
[51] Junjie Wang, Bihuan Chen, Lei Wei, and Yang Liu. Superion: Grammar-aware greybox fuzzing. In ICSE, 2019.
[52] Yizhong Wang, Yeganeh Kordi, Swaroop Mishra, Alisa Liu, Noah A Smith, Daniel Khashabi, and Hannaneh Hajishirzi. Self-instruct: Aligning language model with self generated instructions. arXiv, 2022.
[53] Chunqiu Steven Xia, Matteo Paltenghi, Jia Le Tian, Michael Pradel, and Lingming Zhang. Fuzz4all: Universal fuzzing with large language models. In ICSE, 2024.
[54] Frank F Xu, Uri Alon, Graham Neubig, and Vincent Josua Hellendoorn. A systematic evaluation of large language models of code. In MAPS, 2022.
[55] Wei You, Xueqiang Wang, Shiqing Ma, Jianjun Huang, Xiangyu Zhang, XiaoFeng Wang, and Bin Liang. Profuzzer: On-the-fly input type probing for better zero-day vulnerability discovery. In SP, 2019.
[56] Tai Yue, Pengfei Wang, Yong Tang, Enze Wang, Bo Yu, Kai Lu, and Xu Zhou. {EcoFuzz}: Adaptive {Energy-Saving} greybox fuzzing as a variant of the adversarial {Multi-Armed} bandit. In USENIX Security, 2020.
[57] Michal Zalewski. American fuzzy lop, 2017.
[58] Tianyi Zhang, Faisal Ladhak, Esin Durmus, Percy Liang, Kathleen McKeown, and Tatsunori B Hashimoto. Benchmarking large language models for news summarization. TACL, 2024.

پیوست A: چالش‌های تولید فایل‌های پیچیده: مطالعه موردی TIFF

شکل ۱۰: مقایسه دو فایل TIFF با فشرده‌سازی LZW فعال یا غیرفعال، که هر دو حاوی داده‌های تصویری یکسان هستند. تکه‌های جدید اضافه شده مربوط به LZW در شکل ۱۰ از (0x000, 0x08) تا (0x100, 0x1D) بدون مشخصات قابل تجزیه نیستند.

در بخش ۳، استدلال می‌کنیم که تولید فایل‌هایی با ویژگی‌های پیچیده برای فازرهای فعلی چالش‌برانگیز است. برای روشن شدن این موضوع، یک مثال ارائه می‌دهیم. TIFF، که مخفف Tagged Image File Format است، یک فرمت فایل انعطاف‌پذیر و سازگار برای ذخیره تصاویر است. توجه داشته باشید که فایل‌های TIFF از الگوریتم‌های فشرده‌سازی مختلفی پشتیبانی می‌کنند. در اینجا، استفاده از داده‌های فشرده‌شده LZW در فایل‌های TIFF را تجزیه و تحلیل می‌کنیم تا روشن کنیم که چرا تولید فایل‌ها با ویژگی‌های پیچیده برای فازرهای موجود دشوار است. شکل ۱۰ تفاوت‌های بین دو فایل TIFF با داده‌های تصویر یکسان را نشان می‌دهد: شکل ۱۰ فایل TIFF اصلی را نشان می‌دهد، در حالی که شکل ۱۰ فایلی را که فشرده‌سازی LZW در آن فعال است، نشان می‌دهد. دو تفاوت اصلی وجود دارد: ۱. معرفی بلوک‌های داده (تجزیه‌نشده). در شکل ۱۰، یک بلوک داده بزرگ معرفی شده است. توجه داشته باشید که “تجزیه‌نشده” است زیرا مشخصات LZW در الگوی ویرایشگر ۰۱۰ که توسط FormatFuzzer استفاده می‌شود، وجود ندارد، که از تجزیه و جهش بیشتر جلوگیری می‌کند. ۲. تغییرات در مقادیر داده‌ها و محدودیت‌های جدید: بسیاری از مقادیر داده‌ها در شکل ۱۰ تغییر کرده‌اند و این تغییرات محدودیت‌های جدیدی (مانند آفست‌ها و اندازه‌ها) ایجاد کرده‌اند که باید رعایت شوند. به عنوان مثال، هنگام اضافه کردن ویژگی‌های Exif به یک فایل TIFF، یک برچسب ExifIFDPointer به IFD اصلی اضافه می‌شود تا به داده‌های Exif ارجاع داده شود. داده‌های Exif، مانند فضای رنگ، باید با داده‌های موجود در داده‌های TIFF هم‌تراز شوند و محدودیت‌های جدیدی بین داده‌های Exif و IFD اصلی ایجاد کنند.

بر اساس کاوش ما، فازرهای فعلی با فرمت دودویی نمی‌توانند فایل‌های TIFF حاوی داده‌های LZW تولید کنند. این روش‌ها را می‌توان به دو نوع طبقه‌بندی کرد: ۱. فازینگ مبتنی بر استنتاج، مانند WEIZZ. WEIZZ فیلدهای ورودی و ساختار تقریبی تکه‌ها را در حین جهش استنتاج می‌کند. نتایج استنتاج می‌تواند نادرست باشد، نتواند روابط بین تکه‌ها را به طور دقیق ثبت کند و آن را برای ساخت فایل‌هایی با ویژگی‌های پیچیده نامناسب می‌کند. ۲. فازینگ آگاه از گرامر، مانند FormatFuzzer و AFLSmart. آن‌ها برای تجزیه و تغییر ورودی‌ها به گرامرهای ارائه شده توسط کاربر متکی هستند. با این حال، مشخصات استاندارد TIFF می‌تواند اغلب ناکافی باشد و مشخصات فرمت‌های دیگر مورد نیاز است. به طور خاص، به دلیل عدم وجود نحو LZW در فایل‌های گرامر ارسال شده توسط FormatFuzzer و AFLSmart، آن‌ها نمی‌توانند فایل‌های TIFF حاوی داده‌های LZW تولید کنند. بنابراین، حتی اگر یک سید TIFF اولیه حاوی داده‌های فشرده‌سازی باشد، روش‌های موجود هنوز نمی‌توانند آن را تجزیه و تغییر دهند.

به طور کلی، ویژگی‌های پیچیده در قالب‌های مختلف فایل در حوزه‌های مختلف بسیار رایج هستند، مانند داده‌های پیچیده Exif در فایل‌های JPEG، قابلیت‌های شفافیت در PNGها و رمزگذاری و محافظت DRM در فایل‌های MP4. شایان ذکر است که این ویژگی‌های پیچیده اغلب شامل منطق و مدیریت وضعیت پیچیده‌تری هستند که احتمالاً منجر به آسیب‌پذیری‌های امنیتی می‌شود. بنابراین، ساخت فایل‌های ورودی تست با ویژگی‌های پیچیده مختلف برای بهبود فازینگ بسیار مهم است.

جدول ۱۲: تحلیل مصرف و هزینه توکن برای ۲۴ ساعت فازینگ در UNIFUZZ

پیوست B: تحلیل توکن و هزینه

ما هزینه توکن LLMها را برای فازینگ بیشتر ارزیابی می‌کنیم. در مجموع، از آنجایی که برای انجام موتورهای جهش به LLMها متکی نیستیم، G2Fuzz به توکن‌های زیادی نیاز ندارد. ما میزان مصرف توکن GPT-3.5 و GPT-4 را در آزمایش‌های UNIFUZZ جمع‌آوری می‌کنیم. نتایج در جدول 12 نشان داده شده است. در تمام برنامه‌ها، G2Fuzz(GPT-3.5) برای یک فرآیند فازینگ 24 ساعته کمتر از 0.2 دلار هزینه دارد، در حالی که G2Fuzz(GPT-4) کمتر از 13 دلار هزینه دارد. ما تفسیر می‌کنیم که هزینه توکن برای فازینگ قابل قبول است.

پیوست C: مطالعه حذفیات

C-1: سهم هر مؤلفه

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

نتایج در جدول 13 ارائه شده است. به طور متوسط، هم ترکیب مولد ورودی و هم جهش مولد مؤثر بوده‌اند. در مجموع، ترکیب مولد ورودی 82001 مسیر جدید ایجاد می‌کند، در حالی که جهش مولد 141340 مسیر ایجاد می‌کند. به طور خاص، در jhead، ترکیب مولد ورودی مسئول کشف تقریباً همه مسیرهای جدید است. در tiffsplit، ffmpeg، exiv2 و mp3gain، جهش مولد بیشترین سهم را در کشف مسیرهای جدید دارد.

جدول ۱۳: تعداد مسیرهای جدید ایجاد شده توسط اجزای مختلف G2Fuzz

ج.۲: مقایسه

ما در G2Fuzz، از LLMها برای تولید بذرهای متنوع و انجام جهش‌ها با استفاده از تکنیک‌های سنتی سطح بایت استفاده می‌کنیم. آزمایش‌های قبلی اثربخشی LLM را در تولید بذر تأیید می‌کنند. برای ارزیابی نیاز به ترکیب LLMها با روش‌های سنتی، ما G2Fuzz(LLM-Only) را ایجاد کردیم که صرفاً برای جهش بذر به LLMها متکی است. آزمایش روی UNIFUZZ نشان می‌دهد که G2Fuzz(LLM-Only) لبه‌های کمتری پیدا می‌کند و توان عملیاتی کمتری دارد، اغلب کمتر از 1٪ از G2Fuzz، همانطور که در جدول 14 نشان داده شده است. همچنین با جهش‌های سطح پایین مشکل دارد و به طور قابل توجهی گران‌تر است، که ادغام LLMها و فازینگ سنتی را هم ضروری و هم کارآمد می‌کند.

جدول ۱۴: ارزیابی G2Fuzz (فقط LLM)

پیوست D: اثربخشی Promptها

به منظور ارزیابی اثربخشی Promptهایی که استفاده کردیم، سه ویژگی را تجزیه و تحلیل می‌کنیم. ۱) اعتبار: مولد تولید شده توسط G2Fuzz باید بتواند بذرهای معتبری بسازد. ۲) نسبت بذرها با ویژگی هدف (PSTF): بذرهایی که حاوی کد لازم برای تولید ویژگی هدف هستند، دارای آن در نظر گرفته می‌شوند. ۳) نسبت ویژگی‌های منحصر به فرد و مفید (PUUF).

ما تمام مولدهای بخش ۵.۱.۱ را از نظر اعتبار تجزیه و تحلیل می‌کنیم و مولدهای تولید شده در طول ترکیب مولد ورودی را برای دو ویژگی دیگر به صورت دستی بررسی می‌کنیم. به طور خاص، فایل‌هایی را که پسوند آنها با قالب هدف مطابقت دارد، حذف می‌کنیم و از ImageMagick برای تجزیه و تحلیل استفاده می‌کنیم. توجه داشته باشید که ImageMagick می‌تواند قالب‌های مختلف تصویر و همچنین PDF و MP4 را پردازش کند (به جدول ۱۵ مراجعه کنید). به عنوان مثال، برای TIFF، بذرهایی را که پسوند TIFF دارند از همه برنامه‌ها حذف می‌کنیم، سپس هر یک را با ImageMagick تجزیه و تحلیل می‌کنیم. بذرهایی که می‌توانند تجزیه شوند، معتبر در نظر گرفته می‌شوند و برعکس. نتایج در جدول ۱۵ نشان داده شده است. GPT-4 در هر ۱۰ قالب به نرخ اعتبار بیش از ۸۰٪ دست می‌یابد، PSTF در ۵ قالب بیش از ۷۰٪ و PUUF در ۸ قالب بالای ۷۰٪ است. این یافته‌ها اثربخشی دستورالعمل‌های G2Fuzz را در انجام کارآمد وظایف هدف نشان می‌دهد.

نتایج ناموفق را می‌توان به چهار دلیل نسبت داد: ۱) توهمات LLM ویژگی‌هایی را ایجاد می‌کنند که وجود ندارند. ۲) اشکال‌زدایی (Alg. 2) LLM را به حذف کد مربوط به ویژگی هدف برای اجرای صحیح سوق می‌دهد. ۳) تولید ویژگی‌های نادر دشوارتر است. ۴) برخی از ویژگی‌ها در تمام فایل‌های یک نوع خاص وجود دارند و آنها را بی‌فایده می‌کنند. ما تأثیر توهمات LLM را بر G2Fuzz بیشتر تجزیه و تحلیل می‌کنیم. در طول مرحله تولید ویژگی، توهمات نسبتاً نادر هستند و بیشتر ویژگی‌های بی‌فایده مانند «ویژگی‌های پیش‌فرض که قالب هدف را توصیف می‌کنند» یا «ویژگی‌های زائد» وجود دارند. توهمات عمدتاً در طول ترکیب مولد رخ می‌دهند، که اغلب به توابع یا ویژگی‌های ناموجود اشاره می‌کنند و باعث ایجاد استثنائاتی مانند AttributeError یا NotImplementedError می‌شوند. با این حال، به دلیل استراتژی اشکال‌زدایی ما (الگوریتم ۲)، این خطاهای ناشی از توهمات هنگام اجرای مولد به سرعت شناسایی می‌شوند. سپس LLM تلاش می‌کند تا آنها را برطرف کند و به طور مؤثر تأثیر توهمات را کاهش دهد.

جدول ۱۵: تحلیل اثربخشی prompt برای قالب‌های مختلف

پیوست E: تأثیر کتابخانه

برای ارزیابی تأثیر کتابخانه‌های مختلف بر کیفیت مولد، آزمایش‌هایی را در چهار قالب هدف انجام می‌دهیم. به طور خاص، ما از GPT-4 برای ساخت مولدها استفاده می‌کنیم و کتابخانه‌ای را که باید در اعلان استفاده شود، مشخص می‌کنیم، مانند “شما باید از cv2 برای ایجاد این مولد پایتون استفاده کنید.” برای هر قالب، دو کتابخانه را که قادر به تولید فایل‌ها در قالب مربوطه هستند، انتخاب می‌کنیم.

نتایج در جدول 16 ارائه شده است. در بیشتر موارد، کتابخانه‌های مختلف، همانطور که در موارد JPG، MP4 و PDF مشاهده می‌شود، تغییرات زیادی در پوشش ویژگی‌ها نشان می‌دهند. نکته قابل توجه این است که ترکیب چندین کتابخانه منجر به پوشش کلی بالاتر ویژگی‌ها می‌شود زیرا قابلیت‌های مکمل آنها امکان ساخت مولدهای پیچیده‌تر را فراهم می‌کند.

جدول ۱۶: پوشش ویژگی حاصل از استفاده از کتابخانه‌های مختلف

جدول ۱۷: برنامه‌های معیارهای انتخاب‌ شده از UNIFUZZ، FuzzBench و MAGMA

جدول ۱۸: زمان تحلیل اضافی LLMGenFuzz. واحد آن ثانیه است

جدول ۱۹: میانگین پوشش کد به‌دست‌آمده توسط G2Fuzz در ۲۳ ساعت و ۲۳ ساعت و ۴۵ دقیقه

تسهیل فازینگ جامع و مقرون‌به‌صرفه آگاه از دستور زبان با بهره‌گیری از مدل‌های زبانی بزرگ

Enabling Low-Cost and Comprehensive Grammar-Aware Fuzzing with Large Language Models