فازینگ (fuzzing) روشی مؤثر برای کشف آسیب‌پذیری‌هاست، اما در مواجهه با اهداف پیچیده‌ای مانند کامپایلرها، مفسرها و موتورهای پایگاه داده با چالش مواجه می‌شود؛ چراکه این سیستم‌ها ورودی‌های متنی را می‌پذیرند که باید قیود نحوی و معنایی پیچیده‌ای را رعایت کنند. با وجود آنکه مدل‌های زبانی (LMها یا Language Models) به‌دلیل دانش نهفته‌ی گسترده و توانایی بالقوه در استدلال، توجه زیادی را برای این وظیفه جلب کرده‌اند، کاربرد عملی آن‌ها تاکنون محدود بوده است.

چالش‌های اصلی ناشی از کاوش ناکافی در منطق عمیق برنامه‌ها در میان پایگاه‌های کد دنیای واقعی و همچنین هزینه بالای بهره‌گیری از مدل‌های بزرگ‌تر است. برای غلبه بر این چالش‌ها، ما R1-Fuzz را پیشنهاد می‌کنیم؛ نخستین چارچوبی که از یادگیری تقویتی (RL یا Reinforcement Learning) برای تخصصی‌سازی مدل‌های زبانی کم‌هزینه و یکپارچه‌سازی آن‌ها در فرایند تولید ورودی‌های فازینگ متنی پیچیده بهره می‌گیرد. R1-Fuzz دو طراحی کلیدی را معرفی می‌کند: ساخت پرسش مبتنی بر برش پوشش (coverage-slicing-based question construction) و محاسبه پاداش مبتنی بر فاصله (distance-based reward calculation). R1-Fuzz از طریق آموزش پس از یادگیری (post-training) مبتنی برRL، یک مدل با مجموعه داده ساخته شده توسط ما، یک گردش کار فازینگ طراحی میکند کهLMها را به طور تنگاتنگ ادغام میکند تا در طول فازینگ، معانی عمیق برنامه را استدلال کند.

ارزیابی‌ها بر روی اهداف متنوع دنیای واقعی نشان می‌دهد که طراحی پیشنهادی ما به یک مدل کوچک، با نام R1-Fuzz-7B، امکان می‌دهد با مدل‌های بسیار بزرگ‌تر در فازینگ دنیای واقعی برابری کرده یا حتی از آن‌ها پیشی بگیرد. به‌طور قابل‌توجه، R1-Fuzz تا ۷۵٪ پوشش بالاتر نسبت به فازرهای پیشرفته موجود دست یافته و ۲۹ آسیب‌پذیری پیش‌تر ناشناخته را کشف کرده است که کارایی عملی آن را به‌خوبی نشان می‌دهد.

کلمات کلیدی: R1-Fuzz، مدل‌های زبانی، فازینگ متنی، یادگیری تقویتی

1. مقدمه

آزمون فازینگ نرم‌افزار، یا به‌اختصار فازینگ (fuzzing)، روشی مؤثر برای کشف آسیب‌پذیری‌های امنیتی پنهان است که با تولید ورودی‌های متنوع و اجرای برنامه‌های تحت آزمون، با هدف کاوش در منطق معناشناختی عمیق آن‌ها انجام می‌شود [4، 24، 28]. یکی از پایدارترین چالش‌ها در فازینگ، تولید ورودی برای برنامه‌های هدفی است که ورودی‌های ساخت‌یافته و پیچیده را پردازش می‌کنند؛ از جمله کامپایلرهای زبان، مفسرها، پایگاه‌های داده و موارد مشابه. این اهداف، ورودی‌هایی را انتظار دارند که با دستورزبان‌های پیچیده سازگار بوده، قواعد معنایی غنی را در بر گیرند و منطق عمیق برنامه را درگیر کنند. رویکردهای موجود [5، 9، 14، 30] معمولاً با مشکلات مقیاس‌پذیری و سازگاری مواجه‌اند. افزون بر نیاز به صرف تلاش دستی قابل‌توجه برای هر هدف، هرگونه تکامل در برنامه هدف مانند افزودن قابلیت‌های جدید به زبان می‌تواند مشخصات دست‌ساخت، جهش‌دهنده‌ها (mutators) یا قواعد موردی آن‌ها را ناکامل سازد و در نتیجه، بخش‌هایی از وضعیت‌های برنامه بدون کاوش باقی بمانند. ما در این مقاله، فازینگ چنین اهدافی را «فازینگ متنی (Textual Fuzzing)» می‌نامیم؛ حالتی که پیچیدگی ورودی ناشی از قالب‌های چاپ‌پذیر ساخت‌یافته است و تمرکز آن بر چالش محوری تولید ورودی‌های فازینگ باکیفیت برای اهداف متنی پیچیده قرار دارد.

در فازینگ متنی، مدل‌های زبانی بزرگ (LLMها)ظرفیت تحول‌آفرینی برای غلبه بر این محدودیت‌ها ارائه می‌دهند. نخست آن‌که این مدل‌ها به‌واسطه پیش‌آموزش بر روی مجموعه‌داده‌های عظیم از کدهای برنامه‌نویسی و زبان طبیعی، از دانش نهفته‌ی گسترده‌ای برخوردارند؛ دانشی که نوعی «پیکره جامع» را شکل می‌دهد و نحو (syntax)، معناشناسی و الگوهای رایج اهداف تحت آزمون را در خود رمزگذاری می‌کند. دوم آن‌که LLMها از توانمندی بالایی در درک معناشناختی برخوردارند. آن‌ها قادرند بر پایه سرنخ‌های معنایی غنی، درباره هدف برنامه استدلال کنند؛ نه‌تنها از ساختار کد، بلکه همچنین از معناشناسی زبان طبیعی موجود در نام نمادهای کد یا توضیحات (comments)، که بهره‌برداری از آن‌ها برای روش‌های متعارف بسیار دشوار است. این قابلیت به LLMها امکان می‌دهد ورودی‌هایی معنادار، از نظر نحوی صحیح و از نظر معنایی مرتبط تولید کنند که به شاخه‌های عمیق برنامه دست یابند. برای نمونه، لیست ۱ مثالی است که در جریان آزمایش‌های ما مشاهده شده است. در برنامه هدف SQLite، شاخه شرطی پس از خط ۹ به‌طور مداوم توسط فازرهای سنتی دست‌نخورده باقی می‌ماند، در حالی که یک LLM می‌تواند به‌سادگی ورودی‌های مرتبط (خط ۱۳) را برای برآورده‌سازی شرط تولید کرده و پوشش کد فازینگ را بهبود بخشد. دلیل این امر آن است که توضیحات موجود در خطوط ۴ تا ۸، شرح عملکرد شاخه بعدی (پرس‌وجوهای SQL با ‎RANGE BETWEEN a FOLLOWING AND b FOLLOWING که در آن a برابر b است) را ارائه می‌دهند و LLM قادر است این اطلاعات را درک کرده و از آن‌ها بهره‌برداری کند.

با این حال، ظرفیت استدلالی مدل‌های زبانی بزرگ هنوز در عمل به‌طور کامل مورد بهره‌برداری قرار نگرفته است. یکی از موانع اصلی، دشواری به‌کارگیری مؤثر آن‌ها در پایگاه‌های کد بزرگ و دنیای واقعی است. اگرچه چنین پایگاه‌هایی حاوی اطلاعات معناشناختی غنی‌ای هستند که برای درک انسان طراحی شده‌اند، مقیاس آن‌ها محدودیت‌های شناخته‌شده LLMها را تشدید می‌کند؛ از جمله موازنه میان توهم‌زایی و اندازه پنجره زمینه (context window) [18].

لیست 1. نمونه‌ای از نشانه‌های معنایی فراگیر اما کمتر مورد استفاده (مانند توضیحات درون کد و نام نمادها) که برای مدل‌های زبانی مناسب‌اند تا در فرایند تولید ورودی فازینگ از آن‌ها بهره ببرند؛ برگرفته از SQLite:

				
					// sqlite /src/window .c
static int windowCodeOp ( WindowCodeArg *p, ...
/* If this is a (RANGE BETWEEN a FOLLOWING AND b
** FOLLOWING ) or (RANGE BETWEEN b PRECEDING AND
** a PRECEDING ) frame , ensure the start cursor
** does not advance past the end cursor within the
** temporary table. ... */
	if( pMWin -&gt;eStart == pMWin -&gt;eEnd &amp;&amp; regCountdown &amp;&amp; pMWin -&gt; eFrmType == TK_RANGE
// A part of test input successfully generated by LLMs (by understanding the comments above) to satisfy and test the conditional branch:
SELECT b OVER w FROM t WINDOW w AS (ORDER BY b RANGE BETWEEN 10 AND 10);

افزون بر این، سرنخ‌های معنایی (semantic cues) موردنیاز برای دست‌یابی به شاخه‌های خاص برنامه، غالباً در زنجیره‌های فراخوانی عمیق یا تودرتو پراکنده‌اند، که جداسازی و ارائه معنادار آن‌ها به LLMها را دشوار می‌سازد. ازاین‌رو، ساخت اعلان‌های هدفمند که بتوانند به‌طور قابل‌اعتماد LLMها را برای کاوش در منطق عمیق برنامه در فرایند فازینگ هدایت کنند، همچنان مسئله‌ای حل‌نشده باقی مانده است. در نتیجه، رویکردهای موجود اغلب با بهره‌گیری از LLMها بر روی مستندات گزینش‌شده و هدفمند [23، 34] یا ورودی‌های فازینگ ایزوله [12، 13] با اندازه‌ای قابل‌مدیریت، از این چالش عبور می‌کنند. تا آنجا که ما اطلاع داریم، هیچ پژوهش پیشینی وجود ندارد که از LLMها برای فازینگ از طریق استدلال مستقیم بر روی پایگاه‌های کد هدف استفاده کرده باشد. به‌طور خلاصه، چالش اساسی در این حوزه عبارت است از: ساخت پرسش‌های معقول از پایگاه‌های کد بزرگ و دنیای واقعی به‌منظور کاوش در منطق عمیق برنامه (C1).

علاوه بر این، به‌کارگیری LLMها ذاتاً با نگرانی‌های مربوط به هزینه و مقیاس‌پذیری (C2) مواجه است. راهبردهای موجود عموماً برای دستیابی به عملکرد بهتر، به پرس‌وجوی مدل‌های بزرگ‌تر متکی هستند. با این حال، فراخوانی مکرر مدل‌های بزرگ، به‌ویژه در وظایف محاسبات‌بر مانند تولید ورودی‌های فازینگ، هزینه‌بر است. ازاین‌رو، برخی پژوهش‌ها ترجیح می‌دهند LLMها را خارج از حلقه فازینگ به کار گیرند؛ برای مثال، با تولید آفلاین کدهای جهش‌دهنده (mutator) [26، 37] یا کدهای راه‌انداز (driver) [10، 22].

خوشبختانه، پژوهش‌های اخیر الگوی نویدبخشی را معرفی کرده‌اند که از پس‌آموزش مبتنی بر یادگیری تقویتی (RL-based post-training) [15] برای هم‌ترازسازی توانمندی‌های استدلالی مدل‌های کوچک‌تر بهره می‌گیرد و آن‌ها را قادر می‌سازد در وظایف حوزه‌محور تخصص یابند [17، 21، 27، 33، 36]. چنین چارچوب یادگیری تقویتی برای مدل‌های زبانی مستلزم وجود پرسش‌های ساخت‌یافته و مناسب به‌منظور استخراج پاسخ‌های باکیفیت، و نیز یک سازوکار پاداش هم‌راستا با هدف است تا بتواند این پاسخ‌ها را ارزیابی کرده و به‌روزرسانی پارامترهای مدل را هدایت کند. با این حال، راهبردهای پاداش‌دهی موجود برای مدل‌های زبانی عمدتاً به تطبیق الگوهای متنی [35] یا مقایسه‌های ساده خروجی اجرا [20] متکی هستند که یا دقت کافی ندارند یا بیش از حد پراکنده‌اند و در نتیجه نمی‌توانند به‌طور مؤثر تولید ورودی‌های فازینگ را هدایت کنند. این امر، چالش کلیدی طراحی یک سیگنال پاداش دقیق و اطلاع‌رسان را برجسته می‌سازد (C3).

با بهره‌گیری از LLMها همراه با پس‌آموزش مبتنی بر یادگیری تقویتی، R1-Fuzz ابتدا یک مدل کم‌هزینه را برای تخصصی‌سازی در وظیفه تولید ورودی‌های متنی آموزش می‌دهد (پرداختن به C2) و این کار را با استفاده از یک سیگنال پاداش نوآورانه انجام می‌دهد، و سپس از آن برای تولید ورودی‌های باکیفیت در کمپین‌های فازینگ دنیای واقعی بهره می‌گیرد. به‌طور مشخص، R1-Fuzz دو طراحی کلیدی را معرفی می‌کند: ساخت پرسش مبتنی بر برش پوشش (coverage-slicing-based question construction) و محاسبه پاداش مبتنی بر فاصله (distance-based reward calculation).

R1-Fuzz برای پرداختن به C1، برنامه را با اجرای یک بذر یا ورودی اولیه (seed input) تجزیه می‌کند تا شاخه‌های نزدیک‌ کشف ‌نشده (یعنی مسیرهای شرطی که طی نشده‌اند) را شناسایی کند. برای هر شاخه هدف، یک پرسش متمرکز با برش زدن کد منبع در طول مسیر اجرای برنامه از نقطه ورود تا آن شاخه ساخته می‌شود. این روش ساخت پرسش هم در تولید مجموعه‌داده برای آموزش و هم در تولید پرسش‌های فوری در طول فرایند فازینگ مورد استفاده قرار می‌گیرد.

سپس، برای پرداختن به C3، مکانیزم پاداش مبتنی بر فاصله ما یک سیگنال دقیق‌تر ارائه می‌دهد؛ این کار با محاسبه فاصله بین مسیر اجرای ورودی تولیدشده توسط LLM و شاخه هدف انجام می‌شود. این رویکرد، سیگنال آموزشی دقیق‌تر و کمتر پراکنده‌ای فراهم می‌آورد و الهام‌گرفته از پژوهش‌های مرتبط با فازینگ هدایت‌شده (directed fuzzing) [8] است.

بر پایه این دو طراحی، R1-Fuzz شامل سه مرحله است.

۱. ساخت مجموعه‌داده (Dataset Construction): با استفاده از روش ساخت پرسش مبتنی بر برش پوشش، R1-Fuzz می‌تواند با در اختیار داشتن یک برنامه هدف و یک بذر یا ورودی اولیه (seed)، مجموعه‌ای از پرسش‌ها تولید کند. برای یک مجموعه ورودی اولیه مشخص (یعنی یک پیکره یا corpus)، R1-Fuzz قادر است انواع پرسش‌ها را تولید کند که منجر به مسیرهای عمیق و متنوعی در کد برنامه هدف می‌شوند. افزون بر این، با ادغام برنامه‌های هدف بیشتر، R1-Fuzz می‌تواند مجموعه‌داده‌ای جامع شامل کدهای منبع متنوع دنیای واقعی بسازد که دامنه گسترده‌ای از معناشناسی برنامه‌ها را در بر می‌گیرد.

۲. پس‌آموزش مبتنی بر یادگیری تقویتی (RL-based Post-training): R1-Fuzz با استفاده از الگوریتم Group Relative Policy Optimization (GRPO) [15]، مدل زبانی را برای تسلط بر وظیفه مورد نظر آموزش می‌دهد. با ادغام مکانیزم پاداش پیشنهادی، R1-Fuzz پتانسیل یک مدل کوچک و کم‌هزینه، با نام R1-Fuzz-7B، را برای تولید مؤثر ورودی‌های فازینگ هدفمند فعال می‌کند.

مرحله سوم در R1-Fuzz عبارت است از: ۳. حلقه فازینگ با قدرت مدل‌های زبانی بزرگ (LLM-powered Fuzzing Loop). ما یک جریان کاری فازینگ طراحی کرده‌ایم که مدل‌های زبانی را به‌طور تنگاتنگ در حلقه فازینگ هدایت‌شده توسط پوشش کد (coverage-guided) ادغام می‌کند. به‌طور مشخص، این حلقه یک پیکره فازینگ در حال تحول از بذر یا ورودی‌های اولیه (input seeds) را حفظ می‌کند که پوشش کد جدید ایجاد می‌کنند، و R1-Fuzz از این ورودی‌ها برای ساخت مستمر پرسش‌ها استفاده می‌کند، که شاخه‌های کشف‌نشده توسط فازر را بیان می‌کنند.

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

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

برای ارزیابی طراحی خود، ما R1-Fuzz را پیاده‌سازی کرده و آزمایش‌های جامع را به‌منظور سنجش اثربخشی آموزش و فازینگ در دنیای واقعی انجام دادیم. مجموعه‌ای متنوع از اهداف متنی انتخاب شد، شامل مفسرهای زبان (PHP، Lua، Ruby، QuickJS، NJS)، کامپایلرها (CPython، Solidity) و موتورهای پایگاه داده (SQLite، DuckDB). سپس تمامی سه مرحله R1-Fuzz بر روی این اهداف اجرا شد، شامل تولید مجموعه‌داده‌ای متشکل از ۱۶۳۳۸ پرسش، آموزش یک مدل کم‌هزینه (R1-Fuzz-7B) مبتنی بر Qwen2.5-7B-Instruct [31] و مقایسه عملکرد بین مدل‌های مختلف و فازرهای پیشرفته موجود.

علاوه بر این، مطالعه تحلیل اجزایی (ablation study) نیز انجام شد تا اثربخشی مؤلفه‌های کلیدی در R1-Fuzz نشان داده شود. نتایج آزمایش‌ها نشان داد که R1-Fuzz-7B می‌تواند در وظیفه تولید ورودی‌های فازینگ عملکرد برجسته‌ای داشته باشد، به‌گونه‌ای که با مدل‌های بزرگ و پرهزینه‌تر (DeepSeek-V3 [15]، GPT-o4mini [25]) در فازینگ دنیای واقعی قابل مقایسه بوده و حتی از آن‌ها پیشی بگیرد. افزون بر این، حلقه فازینگ با قدرت LLM ما عملکرد چشمگیری در هر دو شاخص پوشش کد و کشف آسیب‌پذیری‌ها نشان داد. در اهداف انتخاب‌شده، R1-Fuzz پوششی تا ۷۵٪ بالاتر نسبت به فازرهای پیشرفته موجود [5، 9، 16، 28، 30] به دست آورد و ۲۹ آسیب‌پذیری پیش‌تر ناشناخته را کشف کرد، که ۲۴ مورد از آن‌ها توسط توسعه‌دهندگان رفع یا تأیید شد.

در نهایت، مطالعه تحلیل اجزایی نشان داد که قالب پرسش و زمان‌بندی پیشنهادی ما، نسبت به استراتژی‌های ساده، به‌ترتیب ۸٪ و ۳.۸٪ برتری در نسبت پاسخ‌های صحیح و پوشش کد دارد.

در خاتمه، ما مشارکت‌های زیر را ارائه می‌کنیم:

طراحی روش ساخت پرسش مبتنی بر برش پوشش (coverage-slicing-based question construction): این روش بزرگ‌کدهای پیچیده را به اعلان‌های هدفمند تجزیه می‌کند و مجموعه‌داده‌ای برای مدل‌های زبانی فراهم می‌آورد تا بتوانند در مورد معناشناسی عمیق برنامه برای فازینگ استدلال کنند.
طراحی مکانیزم پاداش مبتنی بر فاصله (distance-based reward mechanism): این مکانیزم سیگنال آموزشی دقیق و ریزدانه‌ای ارائه می‌دهد و امکان پس‌آموزش مبتنی بر یادگیری تقویتی مؤثر یک مدل کم‌هزینه (R1-Fuzz-7B) را برای تخصصی شدن در تولید ورودی‌های فازینگ فراهم می‌سازد.
پیاده‌سازی حلقه فازینگ نوآورانه با قدرت LLM و هدایت شده توسط پوشش کد (coverage-guided LLM-powered fuzzing loop): این حلقه پوشش کد تا ۷۵٪ بالاتر و کشف ۵ برابر بیشتر باگ‌های پیش‌تر ناشناخته نسبت به فازرهای پیشرفته موجود را به همراه دارد.
متن‌باز کردن مدل و پیاده‌سازی خود: مدل و پیاده‌سازی ما با نام R1-Fuzz (https://github.com/HKU-System-Security-Lab/R1-Fuzz) به‌عنوان چارچوبی جامع برای پس‌آموزش، استقرار و ارزیابی مدل‌های زبانی مختلف در وظایف فازینگ دنیای واقعی ارائه شده است.

۲. پیش‌زمینه و انگیزه

۲.۱ فازینگ اهداف متنی

بسیاری از سیستم‌های نرم‌افزاری با متون ساخت‌یافته و پیچیده کار می‌کنند، مانند کامپایلرها، مفسرها و موتورهای پایگاه داده. این سیستم‌ها از خطوط لوله چندمرحله‌ای استفاده می‌کنند که در آن ورودی‌ها (برای مثال، کد منبع یا پرس‌وجوهای SQL) ابتدا باید از نظر نحوی معتبر باشند و سپس از نظر معنایی معنادار باشند تا منطق اجرای عمیق برنامه فعال شود. فازینگ چنین اهداف متنی به‌طور ویژه‌ای چالش‌برانگیز است: برای تحریک رفتارهای عمیق، ورودی‌ها باید قواعد نحوی پیچیده و محدودیت‌های معنایی (برای مثال، سیستم‌های نوع، حوزه‌های متغیر) را رعایت کنند. افزون بر این، این اهداف با افزودن ویژگی‌ها و گویش‌های جدید زبان به سرعت تکامل می‌یابند و در نتیجه تنظیمات تست مبتنی بر دستورزبان ایستا را منسوخ می‌کنند. ما چنین سیستم‌هایی را که پیچیدگی ورودی آن‌ها ناشی از متن قابل چاپ است، به‌عنوان اهداف متنی (textual targets) تعریف می‌کنیم.

رویکردهای سنتی برای تست اهداف متنی شامل موارد زیر است:

جهش‌دهنده‌های آگاه به دستورزبان (Grammar-aware mutators)، مانند Nautilus [5] و Gramatron [30]، اعتبار نحوی ورودی‌ها را حفظ می‌کنند اما ممکن است صحت معنایی را نادیده بگیرند، به‌عنوان مثال تولید متغیرهای تعریف‌نشده یا خطاهای نوع که منجر به رد زودهنگام ورودی در طول اجرا می‌شوند.
مشخصات دست‌ساخت (Handcrafted specifications)، قواعد نحوی و معنایی را رمزگذاری می‌کنند (برای نمونه، Polyglot [9] از دستورزبان‌های ANTLR/Flex همراه با قواعد موردی اضافی استفاده می‌کند). با این حال، نگارش و نگهداری چنین مشخصاتی نیازمند کار دستی زیاد است و غالباً قادر به پوشش کامل رفتارهای اهداف پیچیده نیست.
پیکره‌های اولیه دستی گردآوری‌شده (Manually curated seed corpora)، مانند [1، 9]، ورودی‌های اولیه خاص دامنه را برای هدایت جهش‌ها فراهم می‌کنند، اما اثربخشی آن‌ها محدود به دامنه و کیفیت ورودی‌های موجود است و بسیاری از مسیرهای کد مرتبط با ویژگی‌های خاص برنامه بدون آزمون باقی می‌مانند.

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

۲.۲ مثال‌های انگیزشی

برای نشان دادن قابلیت منحصربه‌فرد مدل‌های زبانی بزرگ (LLMها) در فازینگ متنی، مثال ارائه‌شده در لیست ۲ را در نظر بگیرید. این مثال از کامپایلر زبان برنامه‌نویسی قرارداد هوشمند Solidity استخراج شده است. تابع isImplicitlyConvertibleTo که از خط ۴ آغاز می‌شود، بررسی می‌کند که آیا یک نوع ساختاری (struct) می‌تواند به‌طور ضمنی به نوع دیگری (_convertTo) تبدیل شود یا خیر. شاخه شرطی موجود در خط ۱۰ در طول فازینگ در آزمایش‌های ما با فازرهای پیشرفته همواره بدون کاوش باقی ماند، در حالی که حلقه فازینگ با قدرت LLM ما به‌طور موفقیت‌آمیز ورودی (خطوط ۱۴ تا ۲۱) تولید کرد تا این شرط برآورده شود و پوشش کد را بهبود بخشد.

قسمت حیاتی، ایجاد یک متغیر جدید foo است که در مکان Storage عمومی قرار دارد (خط ۱۵، مشابه یک متغیر سراسری) و اختصاص دادن آن به متغیر bar که در مکان Memory قرار دارد (خطوط ۱۸ تا ۱۹، مشابه یک متغیر محلی) است، که تبدیل ضمنی را فعال می‌کند. این کار برای فازرهای سنتی مبتنی بر جهش دشوار است، زیرا نیازمند انجام چندین گام هماهنگ است (تعریف متغیرها، تضمین سازگاری نوع، انجام عملیات تخصیص). افزون بر این، فراخوانی این تابع در عمق زنجیره اجرای برنامه قرار دارد (با عمق ۲۱)، که باعث می‌شود تکنیک‌های تست مانند symbolic یا concolic execution به دلیل انفجار مسیر یا وضعیت [7] به‌سادگی شکست بخورند.

لیست ۲. نمونه‌ای از به‌کارگیری مدل زبانی بزرگ (LLM) برای استنتاج ورودی‌های مرتبط با استفاده از سرنخ‌های معنایی (semantic cues) موجود در توضیحات کد و نام نمادها، که به شاخه عمیق برنامه دست می‌یابد و ابزارهای تست سنتی را ناکام می‌گذارد:

				
					// solidity / libsolidity /ast/Types.cpp
BoolResult StructType :: isImplicitlyConvertibleTo (Type const&amp; _convertTo ) const
{
	if ( _convertTo . category () != category ())
		return false;
	auto&amp; convertTo = dynamic_cast (_convertTo );
	// memory / calldata to storage can be converted , but only to a direct storage reference
	if ( convertTo . location () == DataLocation :: Storage &amp;&amp; location () != DataLocation :: Storage &amp;&amp; convertTo . isPointer ())
// Correctly generated input from our language model to satisfy this conditional branch
contract test {
	struct S { uint x; }
	S public foo;
	function test () public {
		S memory bar = S({x: 1});
		foo = bar; // convert data type located in memory to storage
	}
}

در مقابل، این مثال برای افرادی که دارای دانش پیش‌زمینه‌ای از Solidity هستند کاملاً بدیهی است؛ چراکه تنها کافی است از سرنخ‌های ارائه‌شده در توضیح خط ۹ استفاده کنند. به‌طور مشابه، مدل‌های زبانی بزرگ نیز می‌توانند از چنین سرنخ‌های صریحی بهره‌برداری کرده و با اتکا به دانش پیش‌آموزش‌دیده خود از زبان‌های برنامه‌نویسی، ورودی‌های مناسب را استنتاج کنند. ما همچنین آزمایشی انجام دادیم که در آن توضیح موجود در خط ۹ حذف شد. نتایج نشان داد که LLMها همچنان قادر به تولید ورودی موردنظر هستند، زیرا می‌توانند رفتار مورد انتظار را از نام نمادهای موجود در کد منبع (برای مثال، ‎ConvertibleTo‎، ‎Storage‎، ‎isPointer‎ و غیره) استنباط کنند. قابل توجه آن‌که چنین سرنخ‌های معناشناختی در سراسر سیستم‌های نرم‌افزاری پیچیده به‌وفور یافت می‌شوند، چراکه کدها برای خوانایی انسان نوشته می‌شوند. ازاین‌رو، LLMها با برخورداری از توانایی‌های شبه‌انسانی در تفسیر معناشناختی، به‌طور منحصربه‌فردی در موقعیتی قرار دارند که بتوانند این سیگنال‌ها را برای وظیفه تولید ورودی‌های فازینگ به‌کار گیرند.

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

C1: ساخت پرسش‌های معقول از پایگاه‌های کد بزرگ دنیای واقعی به‌منظور کاوش در منطق عمیق برنامه. برنامه‌های بزرگ شامل هزاران شاخه هستند و استخراج اعلان‌های مرتبطی که منطق خاص کد را برجسته کرده و امکان استدلال مؤثر LLM را فراهم آورند، کاری غیر بدیهی است. تا آنجا که ما اطلاع داریم، هیچ پژوهش پیشینی وجود ندارد که از LLMها برای فازینگ از طریق استدلال مستقیم بر روی پایگاه‌های کد هدف به‌منظور آشکارسازی منطق عمیق برنامه استفاده کرده باشد. روش‌های موجود اغلب LLMها را بر روی مستندات با دقت انتخاب‌ شده [23، 34] یا ورودی‌های فازینگ ایزوله [12، 13] به کار می‌گیرند که از نظر اندازه مدیریت‌پذیرتر هستند.

C2: مدیریت هزینه استنتاج و مقیاس‌پذیری. مدل‌های زبانی بزرگ‌تر عموماً عملکرد بهتری ارائه می‌دهند، اما استفاده از آن‌ها در حلقه فازینگ محاسبات‌بر، به‌ناگزیر پرهزینه است. برخی پژوهش‌های موجود [26، 37] برای اجتناب از پرس‌وجوی مکرر و پرهزینه LLMها، ترجیح می‌دهند آن‌ها را خارج از حلقه فازینگ به کار گیرند؛ برای نمونه، با تولید آفلاین کدهای جهش‌ دهنده.

در این مقاله، ما C1 را با طراحی یک تکنیک برش پوشش (coverage slicing) مورد توجه قرار می‌دهیم که برنامه‌ها را به اعلان‌های فشرده و شاخه‌محور تجزیه می‌کند. این تکنیک به‌اندازه‌ای سبک است که می‌تواند در طول فازینگ اجرا شود و مهم‌تر از آن، می‌تواند برای ساخت مجموعه‌داده آموزشی مورد استفاده قرار گیرد، همان‌طور که در بخش فرعی بعدی نشان داده شده است. برای پرداختن به C2، ما یک چارچوب پس‌آموزش مبتنی بر یادگیری تقویتی (RL-based post-training) برای مدل‌های زبانی کوچک‌تر طراحی کرده‌ایم، که آن‌ها را قادر می‌سازد تا عملکردی قابل مقایسه یا حتی بهتر از مدل‌های بزرگ‌تر ارائه دهند و به‌طور چشمگیری هزینه استقرار را کاهش دهند. در ادامه، انگیزه‌های ما برای پس‌آموزش مبتنی بر یادگیری تقویتی و چالش‌های مرتبط با آن را مورد بحث قرار می‌دهیم.

۲.۳ پس‌آموزش مبتنی بر یادگیری تقویتی (RL-based post-training)

مدل در تنظیمات معمول یادگیری تقویتی (RL) برای مدل‌های زبانی بزرگ، یک اعلان (prompt) دریافت می‌کند (مثلاً یک پرسش)، پاسخی تولید و سپس پاداشی دریافت می‌کند که میزان تطابق پاسخ با هدف تعیین‌شده را نشان می‌دهد. این پاداش سپس برای به‌روزرسانی پارامترهای مدل از طریق روش‌های گرادیان سیاست (policy gradient) مانند PPO یا GRPO [15] استفاده می‌شود. تلاش‌های پیشین [17، 21، 27، 33، 35، 36] نشان داده‌اند که پس‌آموزش مبتنی بر یادگیری تقویتی بر روی مدل‌های کوچک‌تر می‌تواند عملکرد آن‌ها را به‌طور قابل‌توجهی بهبود دهد و آن‌ها را با مدل‌های بسیار بزرگ‌تر در رقابت قرار دهد، در حالی که تنها بخش کوچکی از هزینه را می‌طلبد. الهام‌گرفته از این مطالعات، هدف ما استفاده از RL برای آموزش LLMها به منظور تولید ورودی‌های فازینگ است.

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

دومین مؤلفه حیاتی در یادگیری تقویتی، مکانیزم پاداش است. بیشتر پژوهش‌های موجود در زمینه RL برای مدل‌های زبانی بزرگ از سیگنال‌های پاداشی مانند تطبیق الگوی متنی (string pattern matching) [15، 35] یا مقایسه خروجی اجرا [20] استفاده می‌کنند. این سیگنال‌ها در فازینگ ناکافی هستند، زیرا هدف فازینگ، تطبیق با یک خروجی ثابت نیست، بلکه بیشینه‌سازی کاوش در وضعیت‌های متنوع برنامه است. ازاین‌رو، ما به پاداشی نیاز داریم که نشان دهد یک ورودی تا چه حد به رسیدن به موقعیت برنامه‌ای مطلوب «نزدیک» است، که این منجر به چالش C3 می‌شود: طراحی یک تابع پاداش دقیق و غیر پراکنده که آموزش مدل را هدایت کند.

به‌طور خلاصه، فازینگ اهداف متنی به دلیل محدودیت‌های نحوی (syntax) و معنایی (semantic) عمیق، چالش‌های منحصر‌به‌فردی ایجاد می‌کند. استفاده از LLMها همچنین با نیاز به پرسش‌های معناشناختی مرتبط (C1) و محدودیت‌های عملی هزینه استفاده از مدل‌های بزرگ در طول فازینگ (C2) مواجه است. در حالی که یادگیری تقویتی مسیر امیدوارکننده‌ای برای حل C2 ارائه می‌دهد، چالش جدیدی در طراحی مکانیزم پاداش مؤثر ایجاد می‌کند (C3). این چالش‌ها انگیزه طراحی R1-Fuzz در این مقاله را فراهم می‌آورند؛ چارچوبی که این مسائل را از طریق ساخت پرسش مبتنی بر برش پوشش (§3.2) و پس‌آموزش مبتنی بر یادگیری تقویتی (§3.3) حل می‌کند. در نهایت، R1-Fuzz مدل تخصصی و کم‌هزینه ما را در یک حلقه فازینگ با قدرت LLM (§3.4) به‌کار می‌گیرد تا تست‌های دنیای واقعی و کشف آسیب‌پذیری‌ها را تسهیل کند.

۳. طراحی R1-Fuzz

۳.۱ نمای کلی

شکل ۱ نمای کلی چارچوب R1-Fuzz ما را نشان می‌دهد. این چارچوب مدل‌های زبانی (LMها) را آموزش می‌دهد تا در تولید ورودی‌های متنی برای فازینگ و کشف آسیب‌پذیری‌ها عملکرد برجسته‌ای داشته باشند.

مرحله نخست R1-Fuzz، ساخت مجموعه‌داده (مرحله ۱، §3.2) است. پس‌آموزش مبتنی بر یادگیری تقویتی (RL-based post-training) معمولاً به مجموعه‌داده‌ای باکیفیت، وظیفه‌محور و اطلاع‌رسان نیاز دارد. برای پاسخ به این نیاز، ما روشی خودکار برای ساخت مجموعه‌داده از ابتدا طراحی کرده‌ایم. این مجموعه‌داده شامل مجموعه‌ای از پرسش‌هاست که کد منبع مرتبط را در بر می‌گیرند تا مدل بتواند بر پایه آن‌ها استدلال کند. برای ساخت این پرسش‌ها، R1-Fuzz با گردآوری یک پیکره اولیه از ورودی‌ها برای هر برنامه هدف آغاز می‌کند. با اجرای برنامه هدف روی این ورودی‌ها، مرحله ۱ برش کد مبتنی بر پوشش زمان اجرا را انجام می‌دهد تا چندین ردّ اجرای کد استخراج شود؛ بدین معنا که کد منبع به‌همراه مسیرهای اجرای متناظر به دست می‌آید.

هر ردّ اجرای کد از نقطه ورود برنامه آغاز شده و به یک شرط شاخه‌ای (برای مثال، if یا case درون یک switch) ختم می‌شود که در طول اجرا توسط ورودی پیمایش شده است. ما شاخه‌هایی را استخراج می‌کنیم که توسط ورودی داده‌شده پوشش داده نشده‌اند؛ به‌طور مشخص، شاخه‌هایی که در آن‌ها شرط به یک نتیجه (مثلاً False) ارزیابی شده، در حالی که نتیجه جایگزین (مثلاً True) همچنان بدون کاوش باقی مانده است. سپس با ارائه ردّ اجرای کد و ورودی اولیه به مدل زبانی، پرسشی تشکیل می‌دهیم و از آن می‌خواهیم ورودی جدیدی تولید کند که نتیجه ارزیابی این شرط شاخه‌ای را معکوس کند (از False به True). بدین ترتیب، هدف مدل زبانی تولید ورودی‌هایی است که تصمیم شاخه را وارونه کرده و کاوش را به نواحی کشف‌نشده کد هدایت کند.

پس از ساخت مجموعه‌داده، مرحله ۲ شامل پس‌آموزش از طریق یادگیری تقویتی (RL-based post-training) است، که در آن مدل زبانی (LM) به‌طور مکرر به پرسش‌های ما پاسخ می‌دهد و بازخورد پاداش دریافت می‌کند (§3.3). مکانیزم پاداش مؤثر برای تولید پاسخ‌های هم‌راستا با هدف حیاتی است. برای حل این مسئله، ما مکانیزم جدیدی با نام پاداش مبتنی بر فاصله (distance-based reward) طراحی کرده‌ایم (§3.3)، که ورودی‌های تولیدشده توسط LM را اجرا می‌کند و پاداش را بر اساس نزدیکی مسیر اجرای آن‌ها به شاخه هدف مشخص محاسبه می‌کند.

در مرحله ۳، یک LM پس‌آموزش‌دیده (post-training) در حلقه فازینگ برای ارزیابی عملی یکپارچه می‌شود (§3.4). همان‌طور که در شکل مشاهده می‌شود، نیمه راست حلقه جریان کاری سنتی را دنبال می‌کند: فازر، بذر یا ورودی‌های اولیه (seeds) موجود در پیکره را جهش می‌دهد، برنامه هدف را اجرا می‌کند و ورودی‌هایی که پوشش جدید ایجاد می‌کنند را نگه می‌دارد تا پیکره تکامل یابد.

برای ادغام LM، نیمه چپ این فرآیند را تقویت می‌کند. R1-Fuzz پیکره را تحلیل می‌کند تا شاخه‌هایی که هنوز توسط فازر کاوش نشده‌اند شناسایی شوند، و سپس با استفاده از برش پوشش (coverage slicing) پرسش‌هایی از این شاخه‌ها ایجاد می‌کند تا مدل را مورد پرسش قرار دهد. با پاسخ‌دهی مدل به این پرسش‌ها در طول فازینگ، ورودی‌های باکیفیت تولید می‌شوند که مناطق خاصی از کد را هدف قرار می‌دهند و همچنین پیکره را برای جهش‌های بعدی غنی می‌کنند.

۳.۲ ساخت مجموعه‌ داده

مجموعه‌ داده R1-Fuzz شامل مجموعه‌ای از پرسش‌ها برای پس‌آموزش مبتنی بر یادگیری تقویتی (RL-based post-training) است. در فازینگ متنی، اهداف معمولاً شامل پایگاه‌های کد بزرگ با تعداد زیادی شرط شاخه‌ای هستند که ورودی‌های متنی پیچیده را پردازش می‌کنند. ازاین‌رو، تعیین یک قالب پرسش مختصر و مؤثر برای به‌کارگیری توانمندی استدلال مدل‌های زبانی اهمیت حیاتی دارد.

در R1-Fuzz، ما نحوه دیباگ و استدلال انسان‌ها درباره معناشناسی برنامه را شبیه‌سازی می‌کنیم: با استفاده از یک ورودی مشخص مسیرهای اجرا را دنبال کرده و درباره مکان‌های خاص برنامه استدلال می‌کنیم. الهام‌گرفته از این رویکرد، ما روش ساخت پرسش مبتنی بر برش پوشش (coverage-slicing-based question construction) را توسعه دادیم.

هر پرسش ساخته‌شده شامل موارد زیر است:

یک مسیر اجرای کد منبع برش‌خورده یا بخش‌بندی ‌شده (sliced source code trace)
یک موقعیت شاخه مشخص (specific branch position)
محتوای ورودی اصلی (original input)
و دستورالعمل‌های راهنما (instruction prompts)

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

				
					Function ConstructQuestion(Branch):
	functions ← ExtractSlice(Branch.function);
	question.prompt ← SYSTEM_PROMPT ∥ Concat(functions) ∥ SUFFIX _PROMPT ;
	question.branch ← Branch;
	return question;
Function ConstructDataset(Program, Seeds):
	dataset, Coverage, BranchSet ← ∅;
	foreach seed ∈ Seeds do
		feedback ← Execute(Program, seed);
		Coverage ←
			Coverage ∪ feedback.CoveredBranches;
		foreach
			branch ∈ feedback.UncoveredBranches do
				BranchSet.Add(branch);
		foreach branch ∈ BranchSet do
			if branch ∈ Coverage then
				question ←
				ConstructQuestion(branch);
				dataset.append(question);
	return dataset;

الگوریتم ۱ فرایند ساخت مجموعه‌ داده را توصیف می‌کند. تابع ConstructDataset ابتدا برنامه هدف و مجموعه‌ای از بذرها (seed) یا همان پیکره (corpus) را به‌عنوان ورودی دریافت می‌کند. سپس ساخت مجموعه‌داده با اجرای برنامه روی هر ورودی اولیه و جمع‌آوری پوشش کد انباشته‌شده (خطوط ۸ تا ۱۲) آغاز می‌شود. برای هر ورودی، شاخه‌های کاوش‌ نشده (uncovered branches) آن به‌طور یکتا بر اساس مکان کد منبع شناسایی شده و در BranchSet ذخیره می‌شوند؛ به این معنا که اجرای این ورودی هرگز به این شاخه‌ها نمی‌رسد.

سپس، پس از اجرای تمام ورودی‌ها، الگوریتم هر شاخه کاوش‌نشده را بررسی می‌کند تا بسنجد آیا به مجموعه Coverage تعلق دارد یا خیر، یعنی آیا ورودی‌های دیگر به این شاخه دسترسی دارند (خط ۱۴). این کار اطمینان می‌دهد که تمامی پرسش‌های ساخته‌شده دارای پاسخ هستند، یعنی ورودی قابل اجرایی وجود دارد که شرط را برآورده کند (کد مرده یا dead code نیست).

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

ورودی‌هایی که یک شاخه را پوشش می‌دهند، به‌عنوان پاسخ‌های مرجع (ground-truth answers) به پرسش مربوط به آن شاخه خدمت می‌کنند. اگرچه این پاسخ‌ها در RL (مرحله ۲) که بر سیگنال‌های پاداش به‌جای برچسب‌های مرجع متکی است استفاده نمی‌شوند، اما این ورودی‌ها در پیکره اولیه فازینگ وارد می‌شوند تا از افشای داده (data leakage) جلوگیری کرده و ارزیابی منصفانه قابلیت تعمیم مدل را تضمین کنند (§5.2).

سپس، تابع ConstructQuestion یک پرسش را برای هر شاخه کاوش‌نشده تولید می‌کند (خطوط ۱ تا ۵). ابتدا پشته فراخوانی زمان اجرا (runtime call stack) استخراج می‌شود تا توابعی که به شاخه منتهی می‌شوند شناسایی گردند. برای ارائه زمینه دقیق (accurate context)، برنامه به‌صورت ایستا تحلیل و پارس می‌شود تا اطلاعات زمینه‌ای حفظ شود، شامل گراف‌های فراخوانی (call graphs)، بدنه توابع، مکان‌های فراخوانی (call site locations) و غیره.

سپس بدنه پرسش با ادغام دستورالعمل‌ها (instruction prompts) و کد استخراج‌شده ساخته می‌شود. System prompt مدل‌های زبانی را با شرح هدف و قالب مورد نیاز برای استخراج ورودی‌های تولیدشده هدایت می‌کند. Suffix prompt یا user prompt شرط شاخه هدف و نتیجه اصلی و مطلوب را مشخص می‌کند:

«یک ورودی جدید تولید کن تا نتیجه شرط شاخه COND را از False/True به True/False معکوس کند». علاوه بر این دستورالعمل‌ها و کد، ورودی اصلی نیز ارائه می‌شود تا مدل بتواند از آن به‌عنوان مرجع برای تولید ورودی جدید استفاده کند.

سپس، تابع ConstructQuestion یک پرسش را برای هر شاخه کاوش‌نشده تولید می‌کند (خطوط ۱ تا ۵). ابتدا پشته فراخوانی زمان اجرا (runtime call stack) استخراج می‌شود تا توابعی که به شاخه منتهی می‌شوند شناسایی گردند. برای ارائه زمینه دقیق (accurate context)، برنامه به‌صورت ایستا تحلیل و پارس می‌شود تا اطلاعات زمینه‌ای حفظ شود، شامل گراف‌های فراخوانی (call graphs)، بدنه توابع، مکان‌های فراخوانی (call site locations) و غیره.

«یک ورودی جدید تولید کن تا نتیجه شرط شاخه COND را از False/True به True/False معکوس کند.»

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

صحت پرسش (Question Validity): طراحی قالب پرسش ما تلاش می‌کند تعادلی بین طول معقول و اعتبار یا کامل بودن زمینه (context validity/completeness) برقرار کند؛ به این معنا که ممکن است تمام زمینه لازم در بدنه پرسش ارائه نشده باشد. برای مثال، توابعی که اجرا شده و مقدار بازگشتی دارند اما در پشته فراخوانی فعلی نیستند، ممکن است برای استدلال درباره شرط شاخه هدف ضروری یا حتی مفیدتر باشند. چنین توازنی (trade-off) به دلیل محدودیت توکن‌های مدل‌های زبانی، مقیاس پایگاه‌های کد واقعی و نیازهای کارایی آموزش RL لازم است.

با این حال، با توجه به اینکه LLMها بر روی مجموعه‌های عظیم و متنوعی از داده‌ها پیش‌آموزش دیده‌اند، دانش نهفته آن‌ها می‌تواند جایگزین زمینه‌ی ناقص شود و استدلال مؤثر را ممکن سازد. آزمایش‌های ما (§5.3) تأثیر قالب پرسش‌ها را بررسی کردند و نشان دادند که طراحی ما می‌تواند زمینه مؤثری برای LLMها فراهم کند تا عملکرد فازینگ در تست‌های دنیای واقعی بهبود یابد. بررسی قالب‌های پرسش مؤثرتر به‌عنوان کار آینده (future work) باقی گذاشته شده است.

۳.۳ آموزش مدل سیاست (Policy Model Training)

در مرحله ۲، R1-Fuzz از مجموعه‌داده ساخته‌شده در مرحله ۱ برای پس‌آموزش مبتنی بر یادگیری تقویتی (RL) استفاده می‌کند، با بهره‌گیری از الگوریتم Generative Reinforcement Policy Optimization (GRPO) [15]. اثربخشی این آموزش به شدت به طراحی تابع پاداش (reward function) وابسته است، که باید مدل را هدایت کند تا ورودی‌هایی تولید کند که شاخه‌های خاصی را کاوش کنند.

مکانیزم‌های پاداش موجود—مانند بازخورد انسانی، تطبیق الگوهای مبتنی بر قواعد، یا مقایسه دقیق خروجی اجرای برنامه—برای این وظیفه ایده‌آل نیستند. پاداش‌های مبتنی بر تطبیق الگو با پاسخ‌های مرجع جمع‌آوری‌شده (§3.2) محدودکننده‌اند و توانایی تعمیم را کاهش می‌دهند، زیرا چندین ورودی معتبر می‌توانند یک شاخه را معکوس کنند. بازخورد اجرای دودویی (binary execution feedback) مانند پاداش‌دهی تنها بر اساس رسیدن به شاخه، برای آموزش مؤثر بسیار پراکنده است.

برای حل این مشکل، ما پاداش فاصله پوشش (coverage distance reward) را معرفی می‌کنیم که بازخورد متراکم و افزایشی ارائه می‌دهد. الهام‌گرفته از فازینگ هدایت‌شده (directed fuzzing) [8]، تابع پاداش ما r(x,y)r(x, y)r(x,y) میزان نزدیکی مسیر اجرای ورودی تولیدشده yyy به شاخه هدف را نسبت به ورودی اصلی xxx کمّی‌سازی می‌کند.

به‌طور رسمی، فرض کنید T(x)T(x)T(x) و T(y)T(y)T(y) مسیر اجرای سطح تابع (function-level execution traces) برای ورودی اصلی و ورودی تولیدشده باشند، FFF تابعی باشد که شاخه هدف را در بر دارد، و CCC (!C!C!C) نتیجه اصلی (معکوس‌شده) شرط شاخه باشد. ما فاصله پوشش سطح تابع (function-level coverage distance) آن‌ها را به‌صورت زیر تعریف می‌کنیم:

و تابع پاداش r(x,y) به‌صورت زیر تعریف می‌شود:

به عنوان مثال، اگر مسیر اجرای تابع ورودی اصلی به سمت یک شرط شاخه به شکل زیر باشد:

main -> f1 -> f2 -> f3 : condition1 : False

و مسیر اجرای ورودی جدید به شکل زیر باشد:

main -> f1 -> f2 -> f4 -> f5

فاصله آن‌ها با شمردن تعداد توابع مشترک اجرا شده اندازه‌گیری می‌شود، که در این مثال برابر با 3/4=0.75 است.

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

قابل توجه است که، از آنجا که ورودی اصلی داده شده و طبق فرمول ۱ پاداش مثبت دریافت می‌کند، ما به مدل دستور می‌دهیم با همان ورودی پاسخ ندهد و چنین رفتاری را با کاهش پاداش به ۰.۱ جریمه می‌کنیم تا از سوءاستفاده در پاداش جلوگیری شود. در نتیجه، مجموع پاداش r(x,y) قبل از نرمال‌سازی در GRPO [15] در بازه [0,2] قرار دارد.

۳.۴ حلقه فازینگ مبتنی بر LLM

در مرحله ۳ از R1-Fuzz، ما یک حلقه فازینگ مبتنی بر مدل‌های زبانی بزرگ (LLM-powered fuzzing loop) طراحی می‌کنیم تا با هدف افزایش پوشش کد و کشف آسیب‌پذیری‌ها از LLMها در فازینگ دنیای واقعی بهره‌برداری شود. این مرحله امکان ارزیابی عملی و جامع LLMها را در وظیفه تولید ورودی‌های فازینگ فراهم می‌کند، زیرا به R1-Fuzz اجازه می‌دهد نه‌تنها دقت مدل را روی مجموعه‌داده ایستای تولیدشده بسنجد، بلکه عملکرد آن را در کمپین‌های فازینگ واقعی نیز اندازه‌گیری کند.

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

در هر تکرار، فازر یک بذر (seed) را از پیکره فازینگ (fuzzing corpus) انتخاب کرده، آن را دچار جهش می‌کند و اجرا می‌نماید (خطوط ۳ تا ۵). برای هر بذر جهش‌یافته، فازر بررسی می‌کند که آیا پوشش کد جدیدی که پیش‌تر پوشش داده نشده بود ایجاد شده است یا خیر؛ در صورت مثبت بودن، پیکره با بذر جدید به‌روزرسانی شده و مجموعه پوشش‌داده‌شده (Coverage) نیز متناسب با آن به‌روزرسانی می‌شود؛ در غیر این صورت، حلقه به تکرار بعدی ادامه می‌یابد (خطوط ۷ تا ۱۰).

الگوریتم ۲: حلقه فازینگ مبتنی بر LLM

				
					Coverage ← ∅;
Queue ← ∅;
	while Fuzzer.NotStopped() do
		seed ← Corpus.ScheduleNext();
		newSeed ← Fuzzer.Mutate(seed);
		feedback ← Execute(Program, newSeed);
		hasNewCov ←
			Corpus.CheckSave(newSeed, feedback);
		if ¬hasNewCov then
			continue;
		Coverage ←
			Coverage ∪ feedback.CoveredBranches;
		foreach ub ∈ feedback.UncoveredBranches do
			if ub ∉ Coverage then
				question, priority ←
					ConstructQuestion(ub);
				Queue.Enqueue(question, priority);

در ادامه، برای یکپارچه‌سازی LLMها، R1-Fuzz شاخه‌های پوشش‌نیافته را برای هر بذر (Seed) استخراج می‌کند (خط ۱۱) و بررسی می‌کند که آیا این شاخه‌ها توسط بذرهای قبلی نیز پوشش داده نشده‌اند یا خیر (خط ۱۲). این بررسی با بررسی انجام‌شده در الگوریتم ۱، خط ۱۴ متفاوت است؛ زیرا در فازینگ دنیای واقعی، هدف R1-Fuzz کاوش شاخه‌هایی است که همچنان پوشش داده نشده‌اند.

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

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

برخی جزئیات در الگوریتم حذف شده‌اند، از جمله وجود یک ریسمان مصرف‌کننده (consumer thread) برای دریافت پرسش‌ها از صف، پرس‌وجو از LLMها برای اجرا و ذخیره بذرها، و پایش کرش‌ها و سایر موارد اجرایی.

۴ پیاده‌سازی

ما الگوریتم ۱ و ۲ را در R1-Fuzz با تقریباً ۵۰۰۰ خط کد پایتون پیاده‌سازی کردیم. مرحله آموزش بر اساس چارچوب یادگیری تقویتی Verl [29] اجرا شده است، که در آن محاسبه پاداش مبتنی بر فاصله پوشش (coverage distance) خود را یکپارچه کرده‌ایم.

محاسبه پاداش بر اساس پوشش کد مبتنی بر منبع در LLVM [2] انجام می‌شود، که ما آن را اصلاح کردیم تا شاخه‌های پوشش‌داده‌شده و پوشش‌نیافته را به‌طور مؤثرتر جمع‌آوری کند. حلقه فازینگ (الگوریتم ۲) بر اساس ادغام فازر در FuzzBench [24] پیاده‌سازی شده است.

5. ارزیابی

در ارزیابی R1-Fuzz، هدف ما پاسخ به پرسش‌های پژوهشی زیر است:

RQ1: آیا آموزش مبتنی بر RL می‌تواند عملکرد مدل‌های زبانی را روی مجموعه‌داده تولید ورودی فازینگ ما بهبود بخشد (§5.1)؟
RQ2: آیا LMهای آموزش‌دیده می‌توانند در فازینگ دنیای واقعی عملکرد برتری داشته باشند (§5.2)؟
RQ3: انتخاب‌های طراحی R1-Fuzz تا چه اندازه مؤثر هستند (§5.3)؟

مجموعه‌ داده‌ها. برای ساخت مجموعه‌داده تولید ورودی فازینگ متنی (مرحله ۱)، ما در مجموع ۱۰ هدف واقعی انتخاب کردیم. این اهداف شامل کامپایلرها، مفسرها و موتورهای پایگاه داده هستند، از جمله: PHP، CPython، Lua، mruby، NJS، QuickJS، Solidity، SQLite، Sql-parser و DuckDB. تمامی این اهداف دارای درایورهای فازینگ دستی (manually crafted) توسط کارشناسان و تحت نگهداری OSS-Fuzz [4] هستند، که نقاط ورود یکسان برای انجام آزمایش‌های منصفانه فراهم می‌کند.

برای آماده‌سازی پیکره ساخت مجموعه‌داده مورد نیاز الگوریتم ۱، ما مستقیماً از پیکره فازینگ اولیه ارائه‌شده توسط OSS-Fuzz استفاده کردیم. برای اهدافی که پیکره اولیه ارائه نشده بود، ما یک فازر پایه (AFL++ [16]) را به مدت ۲۴ ساعت اجرا کرده و پیکره حاصل را به‌عنوان پیکره ساخت مجموعه‌داده استفاده کردیم.

برای محدود کردن حجم مجموعه‌داده، وقتی اندازه پیکره اولیه از ۱۰۰۰ بذر بیشتر بود، به‌صورت تصادفی حداکثر ۱۰۰۰ بذر نمونه‌گیری شد. در نتیجه، ما یک مجموعه‌داده شامل ۱۶۳۳۸ پرسش برای این ۱۰ هدف ساختیم.

۵.۱ ارزیابی پس‌آموزش مبتنی بر RL

در این بخش، نتایجی را ارائه می‌کنیم که اثربخشی پس‌آموزش مبتنی بر RL (یا RL-based post-training) روی مجموعه‌ داده ما را نشان می‌دهند. در مرحله آموزش (مرحله ۲)، ما از Qwen2.5-7B-Instruct [31] به‌عنوان مدل پایه استفاده کردیم. مجموعه‌داده آماده‌شده به‌صورت تصادفی با نسبت ۹:۱ به مجموعه‌های آموزش و آزمون تقسیم شد و از مجموعه آموزش برای آموزش مدل با استفاده از GRPO (§3.3) با اندازه دسته (batch size) برابر ۱۲۸ استفاده گردید.

برای تعادل بین ثبات و کاوش (stability and exploration)، ما منظم‌سازی KL را با یک تخمین‌گر واریانس کم و ضریب 0.001 فعال کردیم. Rolloutها با هشت نمونه تولیدی (candidate generations) برای هر پرسش و temperature = 1.0 انجام شد. امتیازهای پاداش هر دو گام آموزشی روی مجموعه آزمون محاسبه شدند.

شکل ۲ آمارهای مربوط به آموزش را نشان می‌دهد، شامل میانگین امتیازهای پاداش روی مجموعه‌های آموزش و آزمون در طول ۱۰۰۰ گام آموزشی. امتیازهای پاداش در بازه [0,2][0, 2][0,2] بر اساس فرمول ۲ قرار دارند. همان‌طور که روندها نشان می‌دهند، امتیازهای آموزش و آزمون به‌صورت پیوسته افزایش یافته و به تدریج به مقادیر پایدار همگرا شدند، که نشان می‌دهد مدل با موفقیت خروجی خود را با هدف هم‌راستا کرده است.

علاوه بر این، امتیازهای پاداش مجموعه آزمون به‌طور نزدیکی با امتیازهای آموزش همگام شدند و انحراف قابل توجهی مشاهده نشد، که نشان می‌دهد مدل به مجموعه آموزش بیش‌برازش نکرده و به داده‌های دیده‌نشده نیز تعمیم خوبی دارد. مدل آموزش‌دیده پس از ۱۰۰۰ گام آموزش RL را R1-Fuzz-7B نامیدیم.

جدول ۱ آمارهای عملکرد مدل‌های مختلف روی مجموعه‌داده ما را نشان می‌دهد. علاوه بر Qwen2.5-7B و R1-Fuzz-7B، ما مدل‌های متن‌باز (open-source) شامل Qwen2.5-32B [31] و Deepseek-V3 [15] و همچنین یک مدل مالکیتی (closed-source) یعنی GPT-o4mini [25] را نیز بررسی کردیم.

هر مدل با پاسخ‌دهی به تمام پرسش‌های مجموعه آزمون ارزیابی گردید و دقت آن‌ها با استفاده از Pass@1 و Pass@5 اندازه‌گیری شد که به ترتیب نشان‌دهنده نسبت پرسش‌هایی است که در اولین تلاش و در پنج تلاش اول به درستی پاسخ داده شدند.

نتایج نشان می‌دهند که R1-Fuzz-7B نه‌تنها از مدل پایه خود Qwen2.5-7B پیشی گرفته است (با تقریباً ۵ برابر امتیاز بالاتر) بلکه نسبت به مدل‌های بزرگ‌تر نیز عملکرد بهتری دارد (با تقریباً ۶۰٪ امتیاز بالاتر)، که اثربخشی آموزش مبتنی بر RL ما را در افزایش توانایی استدلال روی مجموعه‌داده نشان می‌دهد.

۵.۲ ارزیابی فازینگ

در این بخش، نتایج ارزیابی R1-Fuzz-7B در کمپین‌های فازینگ عملی روی اهداف انتخاب‌شده ما ارائه می‌شود. ما دو مجموعه آزمایش انجام دادیم:

مقایسه عملکرد مدل‌های زبانی مختلف در فازینگ (§5.2.1)
مقایسه حلقه فازینگ مبتنی بر LLM ما (مرحله ۳ در شکل ۱) با فازرهای پیشرفته موجود (§5.2.2)

در نهایت، نتایج آسیب‌پذیری‌های تازه کشف‌شده در (§5.2.3) ارائه شد. تمام آزمایش‌های فازینگ برای هر هدف به مدت ۲۴ ساعت اجرا شدند و ما پنج تکرار انجام دادیم تا میانگین پوشش کد را محاسبه کنیم. تمامی آزمایش‌ها روی یک سرور مجهز به پردازنده Intel Xeon Gold 5418Y (۱۲۸ هسته) و ۵۱۲ گیگابایت حافظه RAM انجام شد.

جلوگیری از نشت داده (Data Leakage Prevention) – علاوه بر استفاده از پیکره اولیه ارائه‌شده توسط OSS-Fuzz [4] برای همه فازرها در شروع فازینگ، ما این پیکره را با «بذرهای پاسخ‌ داده‌ شده» (answered seeds) استخراج‌ شده از مجموعه‌ داده آموزشی ساخته‌ شده خود تقویت کردیم. همان‌طور که در §3.2 توضیح داده شد، هر پرسش ساخته‌ شده می‌تواند با یک یا چند بذر پاسخ صحیح مرتبط باشد که به‌عنوان حقایق مرجع (ground truth) عمل می‌کنند. با گنجاندن این بذرهای پاسخ‌داده‌شده در پیکره اولیه، اطمینان حاصل می‌کنیم که شاخه‌های مربوطه از ابتدا پوشش داده شده‌اند و از نشت داده به مدل جلوگیری می‌شود.

در نتیجه، پرسش‌هایی که در طول آموزش ساخته شده‌اند در حین فازینگ دوباره ظاهر نمی‌شوند، زیرا شاخه‌های مرتبط با آن‌ها دیگر به‌عنوان کد پوشش‌داده‌نشده محسوب نمی‌شوند. به عبارت دیگر، تمام پرسش‌هایی که R1-Fuzz-7B در طول فازینگ با آن‌ها مواجه می‌شود خارج از مجموعه‌داده آموزشی آن هستند، که این کار از نشت داده جلوگیری کرده و ارزیابی منصفانه‌ای از توانایی تعمیم مدل فراهم می‌کند.

۵.۲.۱ مقایسه مدل‌ها

ما از یکی از موتورهای فازینگ پرکاربرد و به‌خوبی نگهداری‌شده، AFL++ [16] به‌عنوان موتور فازینگ پایه برای مرحله ۳ استفاده کردیم. سپس، نمونه‌های مختلفی از فازرهای مبتنی بر LLM ایجاد کردیم که نام آن‌ها بر اساس مدل زبانی مورد استفاده تعیین شد، مانند AFL++Qwen2.5-7B یا AFL++R1-Fuzz-7B و غیره. در این زیرمجموعه، برای اختصار، پیشوند “++AFL” حذف شده است.

جدول ۲ نتایج را نشان می‌دهد، که در آن Baseline به معنای ++AFL اصلی بدون طراحی حلقه مبتنی بر LLM است.

Cov نشان‌دهنده تعداد نواحی کد پوشش‌داده‌شده است که با استفاده از پوشش مبتنی بر منبع در LLVM [2] محاسبه شده است.
Ratio نسبت پرسش‌هایی را نشان می‌دهد که به‌درستی پاسخ داده شده‌اند به تعداد کل پرسش‌های مطرح‌شده در طول ۲۴ ساعت فازینگ.

برای مثال، R1-Fuzz-7B برای PHP در مجموع ۵۷۷۲ پرسش در طول ۲۴ ساعت ساخت، که از این تعداد ۴۷۳ بذر ورودی (۸.۲٪) تولیدشده توسط مدل، به‌درستی به پرسش پاسخ دادند، یعنی به شاخه‌هایی که پیش‌تر پوشش داده نشده بودند، رسیدند.

اول، تمام فازرهای تحت حلقه‌های فازینگ مبتنی بر LLM از Baseline پیشی گرفته‌اند، که اثربخشی طراحی مرحله ۳ در R1-Fuzz را تأیید می‌کند. به‌طور متوسط، پوشش کدی که R1-Fuzz به‌دست می‌آورد تقریباً ۴۰٪ بیشتر از Baseline است، که نشان‌دهنده سود قابل توجه از یکپارچه‌سازی LLMها است.

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

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

Qwen2.5-7B < Qwen2.5-32B < DeepSeek-V3 < R1-Fuzz-7B < GPT-o4mini

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

علاوه بر این، مدل‌های بزرگ مالکیتی (closed-source) هزینه‌ای معادل ۴۰ دلار به ازای هر هدف برای ۲۴ ساعت دارند، در حالی که R1-Fuzz-7B ما به‌طور مؤثر روی سخت‌افزار محلی اجرا می‌شود و تعادل مطلوبی بین عملکرد و هزینه ارائه می‌دهد.

برای برخی موارد خاص، به‌عنوان مثال روی هدف Lua، Qwen2.5-7B کمی بهتر از Qwen2.5-32B عمل می‌کند، با وجود اینکه نسبت پاسخ‌های صحیح آن‌ها مشابه است، زیرا مدل کوچک‌تر پرسش‌های بیشتری را پاسخ داده است؛ این نکته اهمیت بهره‌وری مدل در سناریوهای فازینگ فشرده را نشان می‌دهد. برای اهداف CPython و NJS، R1-Fuzz-7B حتی از GPT-o4mini پیشی می‌گیرد، که شواهد بیشتری بر لزوم فعال‌سازی قابلیت‌های نهفته در LLMهای کم‌هزینه برای فازینگ ارائه می‌دهد.

با مقایسه بین اهداف مختلف، عملکرد تمام مدل‌ها متفاوت است: برخی نسبت‌های بالاتری دارند و برخی دیگر کمتر رضایت‌بخش هستند. ما این اختلافات را به سه عامل احتمالی نسبت می‌دهیم:

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

در خلاصه، حلقه فازینگ مبتنی بر LLM در R1-Fuzz در فازینگ دنیای واقعی موثر است و به دستاوردهای قابل توجهی نسبت به Baseline دست می‌یابد. علاوه بر این، پس‌آموزش مبتنی بر RL ما امکان می‌دهد یک مدل 7B کم‌هزینه به عملکرد مدل‌های بزرگ‌تر دست یابد یا حتی آن‌ها را پشت سر بگذارد. این یافته‌ها هم اثربخشی عملی روش ما و هم پتانسیل گسترده آموزش RL برای فعال‌سازی توانایی‌های LLMها در فازینگ را نشان می‌دهند.

۵.۲.۲ مقایسه با فازرهای پیشرفته

در مرحله بعد، عملکرد AFL++R1-Fuzz-7B را با یک فازر عمومی (general-purpose) به نام libFuzzer [28] و چند فازر پیشرفته دیگر از جمله فازرهای آگاه به دستور زبان (grammar-aware fuzzers) مانند Polyglot [9]، Nautilus [5] و Gramatron [30]، روی زیرمجموعه‌ای از اهداف انتخاب‌شده ما که در دسترس بودند مقایسه کردیم.

جدول ۳ تعداد نواحی کد پوشش‌داده‌شده توسط هر روش را نشان می‌دهد. اهدافی که در جدول ۳ حضور ندارند و ورودی‌های N/A نشان‌دهنده مواردی هستند که پیاده‌سازی متن‌باز فازر مبتنی بر دستور زبان، فایل دستور زبان یا مشخصات مورد نیاز برای زبان برنامه‌نویسی مربوطه را ارائه نمی‌دهد.

در مقابل، روش ما بر پایه فازر عمومی AFL++ [16] ساخته شده و به مشخصات دست‌ساز وابسته نیست، که توانایی تعمیم حلقه فازینگ مبتنی بر LLM ما را برجسته می‌کند. نتایج نشان می‌دهند که AFL++R1-Fuzz-7B به‌طور مداوم از تمام فازرهای مقایسه‌شده پیشی می‌گیرد. میانگین بهبود پوشش کد تقریباً ۷۵٪ است، که اثربخشی قابل توجه ادغام LLMها در حلقه فازینگ (مرحله ۳) را نشان می‌دهد.

۵.۲.۳ کشف آسیب‌پذیری‌ها

ما همچنین اثربخشی فازرهای R1-Fuzz (مدل‌های مختلف یکپارچه‌شده با AFL++ [16]) را در کشف آسیب‌پذیری‌ها ارزیابی کردیم. تمامی فازرها روی جدیدترین نسخه اهداف انتخاب‌شده اجرا شدند تا باگ‌های ناشناخته قبلی کشف شوند. نتایج در جدول ۴ نشان داده شده‌اند.

اعداد داخل پرانتز نشان‌دهنده آسیب‌پذیری‌های منحصر به فردی هستند که توسط فازرها یا مدل‌های دیگر کشف شده‌اند اما توسط R1-Fuzz-7B کشف نشده‌اند.

فازرهای عمومی سنتی، شامل ++AFL و libFuzzer، دو باگ کشف کردند.
فازرهای پیشرفته آگاه به دستور زبان (Nautilus, Gramatron, Polyglot) پس از تحلیل دستی، در مجموع پنج باگ یافتند.

در مقابل، حلقه فازینگ مبتنی بر LLM در R1-Fuzz عملکرد بهتری داشت و ۲۹ آسیب‌پذیری منحصر به فرد و پیش‌تر ناشناخته را کشف کرد. این آسیب‌پذیری‌ها در پروژه‌های متنوعی شامل PHP, Lua, mruby, NJS, QuickJS, Solidity و DuckDB قرار دارند، که ۲۴ مورد از آن‌ها توسط توسعه‌دهندگان تأیید یا رفع شده‌اند (جدول ۶).

نسبت به فازرهای غیرLLM، R1-Fuzz بیش از ۵ برابر آسیب‌پذیری‌های بیشتری را آشکار کرد، که مزیت عملی ادغام مدل‌های زبانی در فازینگ را برجسته می‌سازد.

در میان مدل‌های مختلف در حلقه فازینگ مبتنی بر LLM ما، مدل پس‌آموزش‌دیده (post-trained model) ما، R1-Fuzz-7B، هم از مدل‌های کوچک‌تر و هم از مدل‌های بزرگ‌تر غیرتخصصی عملکرد بهتری دارد. در حالی که چند باگ همچنان منحصر به مدل‌های دیگر باقی مانده‌اند، بیشتر آسیب‌پذیری‌ها توسط مدل ما کشف شده‌اند.

مقایسه با مدل‌های کوچک تنظیم‌نشده این نکته را برجسته می‌کند:

Qwen2.5-7B تنها ۱ باگ و Qwen2.5-32B تنها ۵ باگ را شناسایی کردند،
در حالی که R1-Fuzz-7B مجموعاً ۲۳ باگ را کشف کرد.

این امر نشان می‌دهد که آموزش مبتنی بر RL ما، توانایی تخصصی هدفمند را به یک مدل کوچک می‌دهد. ترکیب این توانایی با بهره‌وری مدل کوچک، این رویکرد را برای وظایف فازینگ فشرده بسیار مؤثر می‌سازد.

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

۵.۳ مطالعه حذف مولفه‌ها

در این بخش، آزمایش‌های حذف مولفه ها انجام شد تا اثربخشی انتخاب‌های کلیدی طراحی در R1-Fuzz ارزیابی شود، از جمله ساخت پرسش مبتنی بر برش پوشش (coverage-slicing) و طراحی زمان‌بندی پرسش‌ها در حلقه فازینگ مبتنی بر LLM.

۵.۳.۱ ساختار پرسش

ابتدا تأثیر استخراج مسیر اجرای توابع (function-trace) در فرایند ساخت پرسش بررسی شد. به‌طور خاص، یک نسخه حذفیات با عنوان w/o Trace در نظر گرفته شد، که در آن تابع ConstructQuestion (به الگوریتم‌های ۱ و ۲ مراجعه شود) طوری تغییر یافت که رد اجرای call-stack شاخه هدف را حذف کند.

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

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

سپس نسبت پاسخ صحیح (answer ratio) محاسبه گردید، یعنی کسر پرسش‌های پاسخ داده‌شده صحیح نسبت به کل پرسش‌ها، و تفاوت نسبی بین دو نسخه گزارش شد.

نتایج جدول ۵ نشان می‌دهد که حذف اطلاعات رد اجرای توابع، عملکرد مدل را به طور میانگین ۸٪ کاهش می‌دهد. در اکثر اهداف، کاهش نرخ پاسخ صحیح تأیید می‌کند که ارائهٔ زمینهٔ اجرای گسترده‌تر به مدل —فراتر از کد تابع محلی— برای استدلال مؤثر در رسیدن به شاخه‌های کشف‌نشده ضروری است.

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

۵.۳.۲ زمان‌بندی پرسش‌ها

ما همچنین تأثیر مکانیزم زمان‌بندی پرسش‌ها را بررسی کردیم، که مشخص می‌کند پرسش‌های ساخته‌شده هنگام فازینگ چگونه برای پرسش به مدل‌های زبانی اولویت‌بندی شوند. همان‌طور که در §3.4 توضیح داده شد، R1-Fuzz در طول فازینگ به‌طور مداوم شاخه‌های کشف‌نشده را استخراج کرده و پرسش می‌سازد.

به جای این که پرسش‌ها بلافاصله به مدل ارائه شوند، R1-Fuzz آن‌ها را در یک صف اولویت‌دار (priority queue) قرار می‌دهد تا زمان‌بندی شود. ما دو نسخه را مقایسه کردیم:

استراتژی ساده (w/o Prio): پرسش ساخته‌شده فوراً به مدل ارائه می‌شود.
مکانیزم زمان‌بندی پیش‌فرض R1-Fuzz: اولویت‌ها بر اساس معکوس تعداد دفعات پرسش تعیین می‌شوند. در این نسخه، شاخه‌هایی که با وجود تلاش‌های مکرر هنوز کشف نشده‌اند، به تدریج کم‌اولویت می‌شوند و این امر کاوش شاخه‌های تازه‌وارد را تشویق می‌کند.

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

نتایج نشان می‌دهند که زمان‌بندی مبتنی بر اولویت به‌طور مداوم نسبت پاسخ صحیح بالاتری را به دست می‌دهد و باعث پوشش کد بالاتری می‌شود، با تفاوت‌های ۳.۵٪ و ۳.۸٪ به‌ترتیب. این نشان می‌دهد که مکانیزم زمان‌بندی ما می‌تواند کارایی پرسش‌دهی را با جلوگیری از تلاش‌های تکراری و افزایش تنوع مسیرهای کاوش‌شده، بهبود بخشد.

6. کارهای مرتبط

۶.۱ مدل‌های زبانی بزرگ (LLM) برای فازینگ

از زمان رواج مدل‌های زبانی بزرگ (LLM)، بسیاری از کارهای مرتبط به کاربرد LLMها در حوزه فازینگ انجام شده است، از جمله:

تولید ورودی‌های فازینگ [6, 12, 13, 19, 23, 32, 34]
تولید کد درایور فازینگ یا تست واحد (unit test) [3, 10, 11, 22]
تولید کد مواد یا جهش دهنده (mutator) [26, 37]

برای مثال:

PromptFuzz [22] از LLMها برای تحلیل کد منبع کتابخانه‌ها و تولید و تکامل کد درایور فازینگ استفاده می‌کند، به طوری که APIهای کتابخانه برای تست بهره‌برداری شوند.
MetaMut [26] از LLMها برای تولید کد جهش دهنده (mutator) آگاه به دستور زبان جهت تست کامپایلرهای زبان C استفاده می‌کند.
G2Fuzz [37] از LLMها برای نوشتن کد مولد ورودی برای فرمت‌های خاص مانند PDF، ELF و PNG استفاده می‌کند تا پردازنده‌های متناظر را تست کند.

در زمینه تولید ورودی‌های فازینگ:

Fuzz4All [34] از LLMها برای خواندن مستندات و تولید ورودی‌های ویژگی‌محور (feature-guided) استفاده می‌کند.
Asmita et al. [6] از LLMها برای تولید ورودی‌های BusyBox با استراتژی‌های بازاستفاده از کرش‌ها بهره می‌برد.
Clozemaster [13] و CovRL-Fuzz [12] از LLMها برای تکمیل یا تغییر بخشی از ورودی‌های فازینگ برای Rust و JavaScript استفاده می‌کنند.

در مقایسه با این روش‌ها، که به مستندات اضافی یا خود بذر ورودی وابسته‌اند، R1-Fuzz اولین چارچوبی است که با پس‌آموزش (post-training) مدل‌های کوچک، آن‌ها را قادر می‌سازد تا به طور مؤثر روی کد منبع عمیق برنامه استدلال کرده و ورودی‌های فازینگ تولید کنند.

۶.۲ پس‌آموزش (Post-training) مدل‌های زبانی بزرگ

در سال‌های اخیر، بسیاری از پژوهش‌ها از یادگیری تقویتی (RL) به‌عنوان یک روش پس‌آموزش (post-training) برای افزایش توانایی استدلال، هم‌راستایی (alignment) و تخصص دامنه‌ای مدل‌های زبانی بزرگ بهره برده‌اند:

DeepSeek-R1 [15] پتانسیل RL خالص (با الگوریتم GRPO) را در توانمندسازی LLMها برای استدلال و استفاده از زنجیره‌های فکری نشان می‌دهد، که هم نقاط قوت در حل مسئله و هم چالش‌هایی در کنترل و ایمنی را آشکار می‌کند.
Compiler-R1 [27] از RL برای بهینه‌سازی خودکار کامپایلر استفاده می‌کند و کاهش تعداد دستورالعمل‌های نمایندگی میانی را به دست می‌آورد.
Memory-R1 [36] LLMها را با عامل‌های آموزش‌دیده با RL برای مدیریت و استفاده تطبیقی از حافظه مجهز می‌کند.
SWE-RL [33] استدلال مبتنی بر RL را روی مهندسی نرم‌افزار واقعی اعمال می‌کند، با آموزش روی داده‌های بزرگ تکامل نرم‌افزار، به طوری که یک مدل متوسط توانست عملکرد سطح-بالا روی SWE-bench داشته باشد و به استدلال خارج از دامنه نیز تعمیم یابد.
RLSF [17] از بازخورد نمادین (symbolic feedback) از حل‌کننده‌ها (solver) و اثبات‌کننده‌ها (prover) به عنوان سیگنال‌های دقیق RL استفاده می‌کند و مدل‌های کوچک‌تر را قادر می‌سازد تا بر مدل‌های بزرگ‌تر در برنامه‌سازی، شیمی و استدلال منطقی پیشی بگیرند.

در مقایسه با این‌ها، R1-Fuzz اولین چارچوبی است که نشان می‌دهد پس‌آموزش مبتنی بر RL در تولید ورودی‌های فازینگ عملیاتی مؤثر است، فراتر از بنچمارک‌های ایستا، و با کشف آسیب‌پذیری‌های واقعی و ناشناخته پیشین، قابلیت کاربرد عملی خود را اثبات می‌کند.

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

در این مقاله، R1-Fuzz را معرفی کردیم، یک چارچوب مبتنی بر یادگیری تقویتی (RL) برای پس‌آموزش مدل‌های زبانی به منظور بهبود فازینگ متنی پیچیده. R1-Fuzz با ارائه دو تکنیک کلیدی، چالش‌های اصلی استفاده از LLMها برای تست نرم‌افزارهای پیچیده و دارای محدودیت‌های غنی را برطرف می‌کند، یکی ساخت پرسش مبتنی بر برش پوشش کد (coverage-slicing-based question construction) که منطق عمیق برنامه را به پرسش‌های منطقی و قابل استفاده برای مدل تجزیه می‌کند و دیگری مکانیزم پاداش مبتنی بر فاصله (distance-based reward) که بازخورد دقیق و ریزبینانه‌ای در طول پس‌آموزش مبتنی بر RL ارائه می‌دهد.

با تخصصی کردن یک مدل ۷ میلیارد پارامتری کم‌هزینه به جای اتکا به مدل‌های بزرگ و پرهزینه، R1-Fuzz دسترس‌پذیری و مقیاس‌پذیری را به شکل قابل توجهی افزایش داده و در عین حال عملکرد رقابتی در فازینگ را حفظ می‌کند.

ارزیابی‌های ما نشان می‌دهد که R1-Fuzz نه تنها پوشش کد بیشتری تا ۷۵٪ نسبت به فازرهای پیشرفته ایجاد می‌کند، بلکه عملکرد عملی بالایی دارد و ۲۹ آسیب‌پذیری ناشناخته پیشین را در پروژه‌های واقعی کشف می‌کند. این نتایج پتانسیل مدل‌های سبک و تخصصی‌شده را برای استدلال درباره معنای برنامه و منطق آن و پیشبرد وضعیت هنر در فازینگ اهداف متنی پیچیده نشان می‌دهد.

8. منابع

				
					[1] 2024. Fuzzilli in Google. https://github.com/v8/v8/tree/main/test/fuzzilli.
[2] 2025. Source based code coverage. https://clang.llvm.org/docs/SourceBasedCodeCoverage.html.
[3] Juan Altmayer Pizzorno and Emery D. Berger. 2025. CoverUp: Effective High Coverage Test Generation for Python. Proc. ACM Softw. Eng. 2, FSE, Article FSE128 (June 2025), 23 pages. https://doi.org/10.1145/3729398
[4] Abhishek Arya, Oliver Chang, Jonathan Metzman, Kostya Serebryany, and Dongge Liu. [n. d.]. OSS-Fuzz. https://github.com/google/oss-fuzz
[5] Cornelius Aschermann, Tommaso Frassetto, Thorsten Holz, Patrick Jauernig, Ahmad-Reza Sadeghi, and Daniel Teuchert. 2019. NAUTILUS: Fishing for deep bugs with grammars.. In NDSS, Vol. 19. 337.
[6] Asmita, Yaroslav Oliinyk, Michael Scott, Ryan Tsang, Chongzhou Fang, and Houman Homayoun. 2024. Fuzzing BusyBox: Leveraging LLM and Crash Reuse for Embedded Bug Unearthing. In 33rd USENIX Security Symposium (USENIX Security 24). USENIX Association, Philadelphia,PA, 883–900. https://www.usenix.org/conference/usenixsecurity24/ presentation/asmita
[7] Roberto Baldoni, Emilio Coppa, Daniele Cono D’elia, Camil Demetrescu, and Irene Finocchi. 2018. A survey of symbolic execution techniques. ACM Computing Surveys (CSUR) 51, 3 (2018), 1–39.
[8] Marcel Böhme, Van-Thuan Pham, Manh-Dung Nguyen, and Abhik Roychoudhury. 2017. Directed greybox fuzzing. In Proceedings of the 2017 ACM SIGSAC conference on computer and communications security. 2329–2344.
[9] Yongheng Chen, Rui Zhong, Hong Hu, Hangfan Zhang, Yupeng Yang, Dinghao Wu, and Wenke Lee. 2021. One engine to fuzz’em all: Generic language processor testing with semantic validation. In 2021 IEEE Symposium on Security and Privacy (SP). IEEE, 642–658.
[10] Xiang Cheng, Fan Sang, Yizhuo Zhai, Xiaokuan Zhang, and Taesoo Kim. 2025. Rug: Turbo Llm for Rust Unit Test Generation. In 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). 2983–2995. https://doi.org/10.1109/ICSE55347.2025.00097
[11] Yinlin Deng, Chunqiu Steven Xia, Haoran Peng, Chenyuan Yang, and Lingming Zhang. 2023. Large Language Models Are Zero-Shot Fuzzers: Fuzzing Deep-Learning Libraries via Large Language Models. In Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis (Seattle, WA, USA) (ISSTA 2023). Association for Computing Machinery, New York, NY, USA, 423–435. https://doi.org/10.1145/3597926.3598067 
[12] Jueon Eom, Seyeon Jeong, and Taekyoung Kwon. 2024. Fuzzing JavaScript Interpreters with Coverage-Guided Reinforcement Learning for LLM-Based Mutation. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis (Vienna, Austria) (ISSTA 2024). Association for Computing Machinery, New York, NY, USA, 1656–1668. https://doi.org/10.1145/3650212.3680389 
[13] Hongyan Gao, Yibiao Yang, Maolin Sun, Jiangchang Wu, Yuming Zhou, and Baowen Xu. 2025. Clozemaster: Fuzzing Rust Compiler by Harnessing Llms for Infilling Masked Real Programs. In 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). 1422–1435. https://doi.org/10.1109/ICSE55347.2025.00175 
[14] Patrice Godefroid, Adam Kiezun, and Michael Y Levin. 2008. Grammar based whitebox fuzzing. In Proceedings of the 29th ACM SIGPLAN conference on programming language design and implementation. 206–215.
[15] Daya Guo, Dejian Yang, Haowei Zhang, Junxiao Song, Peiyi Wang, Qihao Zhu, Runxin Xu, Ruoyu Zhang, Shirong Ma, Xiao Bi, and etal. 2025. Deepseek-R1 incentivizes reasoning in llms through reinforcement learning. Nature 645, 8081 (Sep 2025), 633–638. https: //doi.org/10.1038/s41586-025-09422-z 
[16] Marc Heuse, Heiko Eißfeldt, Andrea Fioraldi, and Dominik Maier. 2022. AFL++. https://github.com/AFLplusplus/AFLplusplus 
[17] Piyush Jha, Prithwish Jana, Pranavkrishna Suresh, Arnav Arora, and Vijay Ganesh. 2024. RLSF: Fine-tuning LLMs via Symbolic Feedback.arXiv preprint arXiv:2405.16661 (2024).
[18] Ziwei Ji, Nayeon Lee, Rita Frieske, Tiezheng Yu, Dan Su, Yan Xu, Etsuko Ishii, Ye Jin Bang, Andrea Madotto, and Pascale Fung. 2023. Survey of hallucination in natural language generation. ACM computing surveys 55, 12 (2023), 1–38. 
[19] Caroline Lemieux, Jeevana Priya Inala, Shuvendu K. Lahiri, and Siddhartha Sen. 2023. CodaMosa: Escaping Coverage Plateaus in Test Generation with Pre-trained Large Language Models. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). 919–931. https://doi.org/10.1109/ICSE48619.2023.00085 
[20] Junlong Li, Daya Guo, Dejian Yang, Runxin Xu, Yu Wu, and Junxian He.2025. Codei/o: Condensing reasoning patterns via code input-output prediction. arXiv preprint arXiv:2502.07316 (2025). 
[21] Zhaowei Liu, Xin Guo, Fangqi Lou, Lingfeng Zeng, Jinyi Niu, Zixuan Wang, Jiajie Xu, Weige Cai, Ziwei Yang, Xueqian Zhao, et al . 2025. Fin-r1: A large language model for financial reasoning through reinforcement learning. arXiv preprint arXiv:2503.16252 (2025). 
[22] Yunlong Lyu, Yuxuan Xie, Peng Chen, and Hao Chen. 2024. Prompt Fuzzing for Fuzz Driver Generation. In Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security (Salt Lake City, UT, USA) (CCS ’24). Association for Computing Machinery, New York, NY, USA, 3793–3807. https://doi.org/10.1145/3658644.3670396 
[23] Ruijie Meng, Martin Mirchev, Marcel Böhme, and Abhik Roychoudhury. 2024. Large language model guided protocol fuzzing. In Proceedings of the 31st Annual Network and Distributed System Security Symposium (NDSS), Vol. 2024.
[24] Jonathan Metzman, László Szekeres, Laurent Maurice Romain Simon,Read Trevelin Sprabery, and Abhishek Arya. 2021. FuzzBench: An Open Fuzzer Benchmarking Platform and Service. In Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE 2021). Association for Computing Machinery, New York, NY, USA,1393–1403. https://doi.org/10.1145/3468264.3473932 
[25] OpenAI. [n. d.]. Introducing OpenAI o3 and o4-mini — openai.com.https://openai.com/index/introducing-o3-and-o4-mini/. 
[26] Xianfei Ou, Cong Li, Yanyan Jiang, and Chang Xu. 2025. The Mutators Reloaded: Fuzzing Compilers with Large Language Model Generated Mutation Operators. In Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 4 (Hilton La Jolla Torrey Pines, La Jolla, CA, USA) (ASPLOS ’24). Association for Computing Machinery, New York, NY, USA, 298–312. https://doi.org/10.1145/3622781.3674171 
[27] Haolin Pan, Hongyu Lin, Haoran Luo, Yang Liu, Kaichun Yao, Libo Zhang, Mingjie Xing, and Yanjun Wu. 2025. Compiler-R1: Towards Agentic Compiler Auto-tuning with Reinforcement Learning. arXiv preprint arXiv:2506.15701 (2025).
[28] Kosta Serebryany. 2016. Continuous fuzzing with libfuzzer and addresssanitizer. In 2016 IEEE Cybersecurity Development (SecDev). IEEE, 157–157.
[29] Guangming Sheng, Chi Zhang, Zilingfeng Ye, Xibin Wu, Wang Zhang, Ru Zhang, Yanghua Peng, Haibin Lin, and Chuan Wu. 2025. Hybridflow: A flexible and efficient rlhf framework. In Proceedings of the Twentieth European Conference on Computer Systems. 1279–1297. 
[30] Prashast Srivastava and Mathias Payer. 2021. Gramatron: Effective grammar-aware fuzzing. In Proceedings of the 30th acm sigsoft international symposium on software testing and analysis. 244–256. 
[31] Qwen Team. 2024. Qwen2.5: A Party of Foundation Models. https://qwenlm.github.io/blog/qwen2.5/
[32] Jincheng Wang, Le Yu, and Xiapu Luo. 2024. LLMIF: Augmented Large Language Model for Fuzzing IoT Devices. In 2024 IEEE Symposium on Security and Privacy (SP). 881–896. https://doi.org/10.1109/SP54263. 2024.00211 
[33] Yuxiang Wei, Olivier Duchenne, Jade Copet, Quentin Carbonneaux, Lingming Zhang, Daniel Fried, Gabriel Synnaeve, Rishabh Singh, and Sida I Wang. 2025. Swe-rl: Advancing llm reasoning via reinforcement learning on open software evolution. arXiv preprint arXiv:2502.18449 (2025). 
[34] Chunqiu Steven Xia, Matteo Paltenghi, Jia Le Tian, Michael Pradel, and Lingming Zhang. 2024. Fuzz4All: Universal Fuzzing with Large Language Models. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering (Lisbon, Portugal) (ICSE ’24). Association for Computing Machinery, New York, NY, USA, Article 126, 13 pages. https://doi.org/10.1145/3597503.3639121
[35] Tian Xie, Zitian Gao, Qingnan Ren, Haoming Luo, Yuqian Hong, Bryan Dai, Joey Zhou, Kai Qiu, Zhirong Wu, and Chong Luo. 2025. Logicrl: Unleashing llm reasoning with rule-based reinforcement learning. arXiv preprint arXiv:2502.14768 (2025). 
[36] Sikuan Yan, Xiufeng Yang, Zuchao Huang, Ercong Nie, Zifeng Ding, Zonggen Li, Xiaowen Ma, Hinrich Schütze, Volker Tresp, and Yunpu Ma. 2025. Memory-R1: Enhancing Large Language Model Agents to Manage and Utilize Memories via Reinforcement Learning. arXiv preprint arXiv:2508.19828 (2025).
[37] Kunpeng Zhang, Zongjie Li, Daoyuan Wu, Shuai Wang, and Xin Xia. 2025. Low-Cost and Comprehensive Non-textual Input Fuzzing with LLM-Synthesized Input Generators. arXiv preprint arXiv:2501.19282 (2025).

R1-Fuzz: تخصصی‌سازی مدل‌های زبانی برای فازینگ متنی با استفاده از یادگیری تقویتی

R1-Fuzz: Specializing Language Models for Textual Fuzzing via Reinforcement Learning