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

اگر امروز قصد دارید از مدل‌های محلی برای مهندسی معکوس سخت‌افزارهای ناشناخته استفاده کنید، باید انتظار توهم‌های گسترده را داشته باشید. طبق گزارشی که در ۴ آگوست ۲۰۲۶ منتشر شد، مدل‌هایی مثل qwen3-coder:30b و dolphinMistral24b به‌جای اینکه مانند یک فیلتر دقیق عمل کنند، به عنوان طبقه‌بندی‌کننده‌هایی بیش از حد سهل‌گیر عمل می‌کنند و نتایج گمراه‌کننده‌ای ارائه می‌دهند. این مدل‌ها در تحلیل باینری‌های خام (Bare-metal)، ناتوان از تفکیک بین یک معماری پردازنده درست و یک رشته تصادفی از دستورات هستند که صرفاً ظاهر معتبری دارند.

این مدل‌های مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — در تشخیص تفاوت بین کد واقعی و توهمات ساختاری ناتوان‌اند. این ضعف در تحلیل دقیق و تمایل به تایید بدون دلیل، یادآور چالش‌های گسترده‌تری در توسعه است که در تغییر نقش دستیاران کدنویسی از اطاعت مطلق به نظارت فنی مورد بررسی قرار گرفته است. در واقع، صنعتی کردن فرآیند دیس‌اسمبل کردن یک پردازنده مستندنشده از یک باینری خام، یک چالش پیچیده است که به چهار مرحله صنعتی تقسیم می‌شود:
۱. تأیید اینکه باینری به هیچ‌یک از پردازنده‌های شناخته‌شده تعلق ندارد.
۲. تأیید اینکه باینری مربوط به کدهای مبهم‌شده (Obfuscated)، فشرده یا رمزگذاری شده از یک پردازنده شناخته‌شده نیست.
۳. ساخت یک مولد پردازنده مستندنشده (Undocumented Processor Generator).
۴. توسعه گردش کار تحلیل و خط لوله تولید دیس‌اسمبلی.

این پروژه خاص بر روی مرحله اول تمرکز داشت: ارزیابی استراتژی‌های مختلف برای شناسایی مؤثرترین روش جهت تعیین معماری هدف از یک باینری خام. همان‌طور که در تحلیل قبلی ما درباره‌ی روش‌های WaveMaker AI و استفاده از کامپایل دو مرحله‌ای برای توقف توهمات اشاره کردیم، این آزمایش بررسی می‌کند که آیا منطق مشابهی را می‌توان در دنیای پرهرج‌ومرجِ دیس‌اسمبل (Disassembly) به کار برد یا خیر. در یک گردش کار معمولی، پژوهشگر ممکن است سعی کند یک پردازنده را حدس بزند، اما صنعتی کردن این فرآیند نیازمند روشی سیستماتیک برای رد کردن بهینه بیش از ۱۷۰ کاندیدای نادرست است.

به نقل از مستندات این پروژه، دو استراتژی متمایز برای شناسایی پردازنده مورد آزمایش قرار گرفت:

استراتژی اول: جداول تبدیل (Transcodification Tables). هدف این روش، مپ کردن توالی‌های بایتی به دستورات اسمبلی برای دیس‌اسمبلی استاتیک و دینامیک بود. این فرآیند تا زمانی ادامه می‌یابد که یک بایت با هیچ دستور شناخته‌شده‌ای تطبیق نیابد یا دیس‌اسمبلی کامل شود. برای ساخت این جدول، پژوهشگر سه متد را تست کرد: تولید جدول تبدیل در Ghidra (شکست خورد)، تولید توسط دیس‌اسمبلرهای بومی (شکست خورد) و استفاده از Gemini برای تولید جدول از توالی‌های خام (موفقیت‌آمیز بود).

استراتژی دوم: برون‌ریزی گسترده معماری (Massive Architecture Brute-Forcing). این روش شامل استفاده از Ghidra برای دیس‌اسمبل کردن باینری در برابر تعداد زیادی از معماری‌های هدف (۱۷۷ پردازنده) و سپس بهره‌گیری از یک LLM برای تحلیل خروجی‌ها جهت تعیین تطابق واقعی است.

برای اجرای این تست، پژوهشگر از PyGhidra و یک اسکریپت Headless سفارشی در جاوا استفاده کرد تا فایل‌های خروجی دیس‌اسمبلی را به‌صورت دسته‌ای تولید کند. این خروجی‌ها سپس به پنج مدل محلی ارسال شدند: dolphinMistral24b، dolphin3-cyber، gemma4:26b، qwen3-coder:30b و qwen2.5-coder.

برای حفظ ثبات، هر مدل دقیقاً همین پرامپت سیستمی (System Prompt) را دریافت کرد: «شما متخصص مهندسی معکوس و معماری پردازنده هستید. وظیفه شما تأیید سازگاری دیس‌اسمبلی یک فیرم‌ور خام است. دستورات ارائه شده را بررسی کنید، اعتبار سینتکس معماری را تأیید نمایید و تعیین کنید که آیا دستورات منسجم به نظر می‌رسند (نبود دستورات نامعتبر تکراری، اپ‌کدهای غیرعادی و غیره) یا خیر. پاسخ را دقیقاً در قالب JSON معتبر ارسال کنید.»

مدل‌ها موظف بودند خروجی را در یک اسکیمای JSON سخت‌گیرانه شامل processor_id (شناسه پردازنده)، یک فلگ بولی is_valid (معتبر بودن)، confidence_score (امتیاز اطمینان)، یک summary (خلاصه کوتاه) و لیستی از detected_anomalies (ناهماهنگی‌های شناسایی شده) ارائه دهند.

سه سناریوی خاص با استفاده از باینری‌های تولید شده از یک فایل سورس C واحد و یک تول‌چین خودکار برای حدود ۳۰ پردازنده مختلف (در هر دو قالب Raw Bare-metal و ELF استاندارد) تست شد:

• فیرم‌ور ۱: پردازنده هدف به‌طور بومی توسط Ghidra پشتیبانی می‌شود.
• فیرم‌ور ۲: پردازنده هدف توسط Ghidra پشتیبانی نمی‌شود.
• فیرم‌ور ۳: یک فایل ELF که صراحتاً به عنوان باینری خام دیس‌اسمبل شد تا پارس کردن بایتی اجباری شود.

بر اساس بررسی نتایج، نرخ «مثبت کاذب» (False Positive) تکان‌دهنده بود. مدل‌ها نتوانستند به عنوان یک فیلتر اکتشافی انتخابی عمل کنند و اغلب تقریباً هر کاندیدای تست شده را تأیید کردند.

نتایج فیرم‌ور ۱ (پردازنده شناخته‌شده):

• مدل dolphin3-cyber: ۱۶۸ مورد از ۱۷۷ کاندیدا را به عنوان تطابق احتمالی شناسایی کرد.
• مدل dolphinMistral24b: ۱۱۴ کاندیدای احتمالی را شناسایی کرد.
• مدل qwen2.5-coder: ۶۹ کاندیدای احتمالی را شناسایی کرد.
• مدل qwen3-coder:30b: избираکننده‌ترین مدل بود اما باز هم ۳۵ کاندیدا را علامت‌زد.
• مدل gemma4:26b: دچار شکست شدید در فرمت‌بندی شد و تنها برای یک فایل گزارش معتبر تولید کرد.

نتایج فیرم‌ور ۲ (پردازنده ناشناخته):

• مدل dolphin3-cyber: ۱۷۲ مورد مثبت کاذب شناسایی کرد.
• مدل dolphinMistral24b: ۱۰۵ مورد مثبت کاذب شناسایی کرد.
• مدل qwen2.5-coder: ۶۷ مورد مثبت کاذب شناسایی کرد.
• مدل qwen3-coder:30b: ۳۲ مورد مثبت کاذب شناسایی کرد.
• مدل gemma4:26b: کاملاً شکست خورد و نتوانست حتی یک گزارش تولید کند.

نتایج فیرم‌ور ۳ (ELF به عنوان Bare Metal):
به دلیل عملکرد ضعیف مدل‌های محلی دیگر، این تست منحصراً روی qwen3-coder:30b انجام شد که ۴۲ پردازنده کاندید احتمالی را شناسایی کرد.

دلیل این توهمات، تفاوت بین «تأیید دستوری سطحی» (Superficial Syntax Validation) و «راستی‌آزمایی معنایی» (Semantic Verification) است. اکثر مدل‌های کدنویس فقط چک می‌کنند که آیا دیس‌اسمبل شده، قواعد گرامری آن معماری را دارد یا نه. چون Ghidra به زور خروجی تولید می‌کند، رشته‌هایی مثل "MOV R0, R1" ساخته می‌شوند که برای مدل جذاب و معتبر به نظر می‌رسند. مدل‌ها دستورات معتبر از نظر سینتکس را با کدهای منطقی از نظر معنایی اشتباه می‌گیرند و پرچم‌های قرمز مثل جریان کنترل غیرمنطقی یا تخصیص‌های غیرممکن در استک‌فریم (Stack Frame) را نادیده می‌گیرند.

سایر شکست‌های فنی بحرانی عبارتند از:

• محدودیت‌های اندازه پنجره (Window-Size Constraints): نمونه‌برداری تنها از ۵۰ دستور اول باعث ایجاد سوگیری می‌شود. در باینری‌های خام یا فایل‌های ELF که به عنوان بایت پارس می‌شوند، آفست معمولاً با بردارهای وقفه، پدینگ یا متادیتای هدر (مثل \x7fELF) شروع می‌شود. مدل‌های زبانی یا این زباله‌ها را به عنوان مقداردهی اولیه معتبر می‌پذیرند یا پرو لوگ‌های واقعی توابع (مانند PUSH {LR}) را که پایین‌تر قرار دارند، از دست می‌دهند.
• اطمینان کالیبره نشده (Uncalibrated Confidence): مدل‌های محلی کوانتیده شده مکرراً امتیازات اطمینان بین ۰.۸۰ تا ۱.۰۰ می‌دهند، صرفاً به این دلیل که هیچ دایرکتیو صریح .byte unknown در پنجره ۵۰ نمونه‌ای ظاهر نشده است.
• تورم اسکیمای JSON: مدل‌هایی مانند gemma4:26b توکن‌های استدلال داخلی یا توکن‌های کانال (مانند "...thought") را به جریان JSON نشت دادند که باعث تخریب پارس کردن خروجی شد.

برای تبدیل این فرآیند به یک خط لوله صنعتی، نویسنده پیشنهاد می‌کند به سمت یک رویکرد ترکیبی (Hybrid) حرکت کنیم که تحلیل استاتیک را با تأیید LLM ترکیب کند.

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

• نسبت دستورات نامعتبر: رد معماری‌هایی که در آن‌ها دایرکتیوهای .byte یا ?? بیش از ۵٪ از کل خروجی را تشکیل می‌دهند.
• تراکم جریان کنترل (Control Flow Density): اندازه‌گیری نسبت دستورات جریان کنترل (JMP, CALL, BRANCH) به جابجایی داده‌ها (MOV, LDR). دیس‌اسمبل‌های نادرست معمولاً تراکم پرش‌های غیرعادی یا نامنظم نشان می‌دهند.
• آنتروپی و آرتیفکت‌های رشته‌ای: استفاده از محاسبات آنتروپی برای رد کردن هدرهای استاتیک پیش از نمونه‌برداری.

مهندسی پرامپت و خط لوله:
بهبودهای بیشتر شامل موارد زیر است:

• پرامپت‌نویسی با چند نمونه (Few-Shot Prompting): ارائه مثال‌های صریح که دیس‌اسمبلی‌های معتبر (عملیات استک منسجم، حلقه‌های ساختاریافته) را در مقابل دیس‌اسمبلی‌های زباله (اپ‌کدهای تکراری، پرش‌های مرده) قرار دهد.
• پنجره نمونه‌برداری دینامیک: به‌جای ۵۰ دستور اول، استخراج ۵۰ دستور از نقاط ورودی توابع شناسایی شده یا اهداف CALL. برای فایل‌های ELF، طول هدرهای اولیه باید به‌طور خودکار نادیده گرفته شود.
• استدلال زنجیره تفکر (Chain-of-Thought): الزام مدل به یک مرحله تحلیل متنی (بررسی جریان کنترل و سازگاری رجیسترها) پیش از تولید شیء JSON نهایی برای جلوگیری از سرکوب قابلیت‌های تحلیلی داخلی.
• تورنمنت‌های حذفی (Elimination Tournaments): درخواست از مدل برای مقایسه جفت‌وار قطعات دیس‌اسمبلی (معماری A در مقابل B) برای انتخاب موردی که انسجام معماری برتری دارد.

این شکست‌ها نشان می‌دهد که مدل‌های محلی آماده‌به‌کار (Out-of-the-box) هنوز برای مهندسی معکوس در محیط‌های حساس آماده نیستند. آن‌ها فاقد عمق معنایی برای تشخیص این موضوع هستند که یک دستور از نظر سینتکسی درست، همچنان می‌تواند از نظر منطقی در معماری یک پردازنده غیرممکن باشد. ارزیابی بعدی تعیین خواهد کرد که آیا مهندسی دقیق‌تر یا مدل‌های زبانی سطح ابری (Cloud-grade) می‌توانند این شکاف را پر کنند یا خیر.

گام بعدی شما

• اگر از مدل‌های محلی برای تحلیل کد استفاده می‌کنید، هرگز به امتیاز Confidence مدل اعتماد نکنید و حتماً خروجی را با ابزارهای استاتیک چک کنید.
• برای کاهش توهم، خروجی دیس‌اسمبلر را تکه‌تکه نکنید و سعی کنید نقاط ورودی توابع (Function Entry Points) را شناسایی و فقط آن‌ها را به مدل بدهید.
• متد «تورنمنت حذف» را امتحان کنید؛ یعنی از مدل بخواهید دو معماری را با هم مقایسه کند و بگوید کدام‌یک انسجام ساختاری بیشتری دارد.