اگر توسعه‌دهنده‌ای هستید که با سخت‌افزارهای قدیمی سروکار دارید، سد ورود به دنیای مهندسی معکوس سفت‌افزار همین حالا فرو ریخت. در ۹ ژوئن ۲۰۲۶، یکی از مشارکت‌کنندگان پروژه coreboot شرح داد که چگونه Claude Opus 4.6 فرآیندی را که به‌طور معمول ۳ تا ۶ ماه زمان می‌برد، به پروژه‌ای تبدیل کرد که تنها در چند هفته به پایان رسید.
به نقل از مستندات این پروژه، لپ‌تاپ IBM/Lenovo ThinkPad x61 برای دهه‌ها یک حفره در اکوسیستم سفت‌افزارهای متن‌باز بود. این دستگاه روی پل شمالی GM965 و پل جنوبی ICH8 متکی است؛ پلتفرم‌هایی که هیچ مستندات لو رفته‌ای برای آن‌ها وجود ندارد. تا پیش از این، مهندسی معکوس این سخت‌افزار نیازمند تلاش‌های دستی طاقت‌فرسا یا ابزارهای تخصصی مانند SerialICE بود که سفت‌افزار را در QEMU اجرا کرده و ورودی/خروجی‌ها را به سخت‌افزار واقعی می‌فرستاد، هرچند تلاش‌های قبلی منجر به یک پورت موفق نشد.
این تلاش در زمانی رخ می‌دهد که جامعه‌ی توسعه‌دهندگان به دنبال سخت‌افزارهای «آزاد» (Libre) بیشتری هستند. با حذف BIOS اختصاصی سازنده، توسعه‌دهندگان کنترل کامل روی فرآیند بوت و امنیت به دست می‌آورند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، کنترل لایه‌های زیرین سخت‌افزار کلید دستیابی به اعتماد کامل است. پروژه x61 اکنون به عنوان یک مطالعه‌ی موردی عمل می‌کند تا بفهمیم آیا هوش مصنوعی می‌تواند خسته‌کننده‌ترین بخش این مسیر، یعنی درک بلوک‌های باینری (Binary Blobs) را خودکار کند یا خیر.
اعتیاد به ThinkPad
سفر این توسعه‌دهنده به دنیای سفت‌افزار بیش از ۱۰ سال پیش با یک ThinkPad x60 شروع شد. علاقه به نرم‌افزارهای آزاد که از صفحه‌ی «درباره‌ی GNU» در Emacs شروع شد، او را به سوی libreboot کشاند. این مسیر در نهایت منجر به مشارکت در coreboot و استخدام در شرکت 9elements شد.
در طول سال‌ها، کلکسیون او برای نیازهای فنی مختلف رشد کرد. یک ThinkPad x200 برای سرعت ۶۴ بیتی و سپس یک x220 خریداری شد چون تراشه‌ی Sandy Bridge به‌طور قابل‌توجهی سریع‌تر از Core 2 Duo در x200 بود. برای بهبود پورت‌های موجود، مدل‌های x201 و R500 را هم اضافه کرد. اخیراً یک ThinkPad t480 به لیست اضافه شد، چرا که ابزار «deguard» راهی برای دور زدن Boot Guard در پردازنده‌های Intel Skylake/Kabylake فراهم کرده بود.
گردش کار مبتنی بر هوش مصنوعی
توسعه‌دهنده کار را با استخراج مقادیر صحیح (Known Good Values) از یک سیستم فعال با استفاده از ابزارهای coreboot آغاز کرد. این مقادیر زمانی که DRAM آموزش نمی‌بیند یا USB از کار می‌افتد، مرجعی برای مقایسه هستند. او از inteltool برای بررسی جامع فضای پیکربندی PCI و رجیسترهای پل شمالی/جنوبی استفاده کرد. ابزار lspci نیز برای بررسی سریع دیدگاه لینوکس نسبت به ماشین به کار رفت.
برای ACPI، توسعه‌دهنده از acpidump برای استخراج جداول، acpixtract برای تفکیک و iasl -d برای دکامپایل آن‌ها استفاده کرد. این کار نمایی خوانا از نحوه‌ی توصیف دستگاه‌ها، مدیریت توان و متدهای EC توسط سفت‌افزار سازنده ارائه داد. ابزار ectool برای بررسی RAM و رفتار EC استفاده شد، زیرا ThinkPadها اغلب جزئیات خاص برد را در آنجا پنهان می‌کنند. اطلاعات CPU و کدک HDA نیز ذخیره شدند تا در طول تحلیل کد گم نشوند.
برای پردازش BIOS سازنده، او از bios_extract برای تفکیک تصویر Phoenix BIOS به ماژول‌های مجزا استفاده کرد. سپس یک عامل هوش مصنوعی (AI Agent) را مستقر کرد که به ابزارهای خاصی برای تعامل با کد مجهز بود:
- ghidra-cli: با ادغام در SKILL.md، به هوش مصنوعی اجازه داد بدون نیاز به هدایت دستی رابط گرافیکی، از Ghidra سوال بپرسد. این ابزار برای ماژول‌های PE32 مانند کد مرجع حافظه (MRC) اینتل که دکامپایل به سبک C در آن‌ها مفید بود، استفاده شد.
- radare2: برای بخش‌های ۱۶ بیتی Real Mode سفت‌افزار به کار رفت، جایی که عامل هوش مصنوعی در نوشتن کدهای رابط (Glue Code) موفق‌تر بود.
یافته‌های سفت‌افزاری و چیدمان حافظه
یک کشف غافلگیرکننده در طول تحلیل، وجود حداقل سه نسخه از raminit در تصویر بود. توسعه‌دهنده حدس می‌زند که یک چیدمان A/B وجود دارد که شامل یک نسخه‌ی بازیافت (Recovery) فقط-خواندنی است. این نسخه‌ی RO بخش زیادی از جریان عادی raminit را نادیده می‌گیرد و احتمالاً فقط برای بازیابی ماشین جهت فلش مجدد BIOS طراحی شده است. این موضوع با رفتار مستند شده‌ی لنووو مطابقت دارد که در آن ۶۴ کیلوبایت بالای فلش برای بازیافت، محافظت شده است.
واقعیت «مهندسی بر اساس حس» (Vibe Engineering)
اگرچه توسعه‌دهنده به شوخی ادعا کرد که پورت بعد از دو پرامپت در حالی که در باشگاه ورزش می‌کرد، در اولین تلاش کار کرد، اما واقعیت بسیار پیچیده‌تر بود. مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — به «دست‌گیری» و هدایت مداوم بر اساس دانش عمیق توسعه‌دهنده از نسل‌های x60 و x200 نیاز داشت.
هوش مصنوعی با چندین نکته‌ی حیاتی سخت‌افزاری مشکل داشت. مدل نتوانست یک GPIO mux برای SMBUS روی GPIO42 را تشخیص دهد؛ این یعنی نمی‌توانست تفاوت بین دیده‌شدن SPD و EEPROM را بفهمد. وقتی سیستم‌عامل بوت می‌شود، تنها EEPROM قابل مشاهده است.
سایر شکست‌های فنی عبارت بودند از:
- اشتباه در شناسایی کنترل‌کننده حافظه: هوش مصنوعی پشتیبانی DDR2 533MT/s و 666MT/s را با 666MT/s و 800MT/s اشتباه گرفت.
- خطاهای رجیستری: مدل سعی کرد فرکانس GMCH FSB را به جای رجیستر MCHBAR، از یک رجیستر PCI بخواند.
- عدم تطبیق اندازه دسترسی: هوش مصنوعی خواندن/نوشتن‌هایی با اندازه اشتباه انجام داد؛ مثلاً نوشتن یک مقدار ۳۲ بیتی در یک رجیستر ۱۶ بیتی که می‌توانست ۱۶ بیت بالایی را که باید دست‌نخورده می‌ماندند، تخریب کند.
- سردرگمی معنایی: مدل در درک تفاوت نحوه‌ی کدگذاری معنای CAS در coreboot در مقابل MRC دچار مشکل شد.
- آشفتگی در چیدمان: وجود چندین raminit در سفت‌افزار، مدل را به‌شدت گیج کرد.
برای ردیابی این مشکلات، توسعه‌دهنده از ردپاها (Traces) و تخلیه مقادیر (Value Dumps) استفاده کرد. کارهای قبلی Lubomir Rintel که از SerialICE برای ردیابی raminit استفاده کرده بود، با وجود دشواری در اجرای SerialICE، مفید واقع شد.
فلش کردن و آزمایش
تست‌ها نیازمند یک چیدمان فیزیکی شامل داکینگ استیشن با کانکتور RS232 UART بود. کد فعال‌سازی این بخش دقیقاً مشابه ThinkPad x60 است. برای فلش کردن تراشه، توسعه‌دهنده از یک گیره روی تراشه فلش SOIC8 در پایین برد استفاده کرد. اگرچه گیره برای SOIC16 طراحی شده بود، اما پین‌های بزرگتر برای تراشه کوچک‌تر هم کار کردند.
او از flashprog با پرچم‌های زیر استفاده کرد: flashprog -p ch341a_spi --ifd -i bios -w build/coreboot.rom. این دستور ناحیه BIOS را هدف قرار داد در حالی که نواحی Intel descriptor، GBE و ME را حفظ کرد. توسعه‌دهنده اشاره کرد که مشابه ICH9 و ICH10، می‌توان تصویر را تنها به نواحی IFD، GBE و BIOS کاهش داد و سفت‌افزار ME را حذف کرد تا فضای بیشتری برای coreboot باز شود.
پورت کردن libgfxinit به GM965
به‌کارگیری libgfxinit برای GM965 ساده بود زیرا سخت‌افزار بسیار شبیه به نسل بعدی است. تفاوت‌ها شامل محدودیت‌های ساعت PLL کمی متفاوت و یک رجیستر GMS متفاوت برای GTT و حافظه استول شده بود. برای دستیابی به این هدف، توسعه‌دهنده عامل LLM را به منابع لینوکس ارجاع داد که می‌توانند این سخت‌افزار را بدون سفت‌افزار به‌طور کامل modeset کنند. هوش مصنوعی به‌سرعت این را به کد قابل استفاده تبدیل کرد و تنها به چند راهنمایی درباره‌ی معنای GTT نیاز داشت.
دشواری‌های ارسال به مخزن اصلی (Upstreaming)
هنگام انتقال کد به مخزن رسمی coreboot، بررسی‌های سخت‌گیرانه توسط مهندس Angel Pons باگ‌های متعددی را فاش کرد که از نوع «روی سیستم من کار می‌کند» بودند. هوش مصنوعی معنای بلوک‌های رجیستر در محدوده 0xa00 MCHBAR در GM965 را توهم زده بود؛ بررسی دقیق‌تر نشان داد که این بخش در واقع به موارد کانال EP/ME در سایر چیپ‌ست‌های اینتل شبیه‌تر است.
شکست‌های خاص شناسایی شده در بررسی عبارت بودند از:
- نام‌گذاری نادرست: نام رجیسترها به‌اشتباه از چیپ‌ست‌های مجاور کپی شده بود یا بر اساس «حس دکامپایلر» انتخاب شده بودند.
- خطاهای بیتی: بیت‌های رزرو شده به عنوان بیت‌های واقعی در نظر گرفته شده بودند و اندازه‌ی دسترسی‌ها اشتباه بود.
- باگ‌های منطقی: جداول زمان‌بندی به‌صورت معکوس ایندکس شده بودند، میدان‌های بیتی معنای غلط داشتند و برخی محاسبات فقط به‌خاطر شانس با DIMMهای تست شده کار می‌کردند.
- کدگذاری سخت (Hardcoding): بخش زیادی از کد پل جنوبی فرض کرده بود که دستگاه یک ThinkPad x61 است و از بیت‌های مقداردهی اولیه سخت‌افزاری استفاده می‌کرد که عمومی نبودند.
فراتر از کد، توسعه‌دهنده با clangfmt درگیر شد. هم LLM و هم Emacs به‌طور پیش‌فرض از آن استفاده می‌کردند، اما ابزار نتایج ضعیفی در پایگاه کد coreboot می‌داد. او در نهایت از روی عصبانیت، پچی برای حذف کامل پیکربندی clang-format از coreboot ارسال کرد.
تحلیل: تغییر در مهندسی سفت‌افزار
این پروژه ثابت می‌کند که LLMها می‌توانند به عنوان یک ضربه‌زننده (Force Multiplier) عظیم برای مهندسی معکوس عمل کنند. با نگاه به هوش مصنوعی به عنوان یک تولیدکننده‌ی سریع نمونه‌های اولیه (Prototype) و نه یک مهندس نهایی، توسعه‌دهنده زمان پروژه را از چندین ماه به چند هفته کاهش داد.
با این حال، «شکاف توهم» همچنان یک ریسک حیاتی است. بدون یک متخصص انسانی برای تأیید اندازه‌ی رجیسترها و جداول زمان‌بندی، کد تولید شده توسط AI یک هک شکننده باقی می‌ماند. این نشان می‌دهد که هوش مصنوعی جایگزین مهندسان معکوس نمی‌شود، بلکه نقش آن‌ها را از «نویسنده کد» به «بازبین ارشد» تغییر می‌دهد.
برای صنعت گسترده‌تر، این یک چرخش در امکان‌پذیری حمله به بلوک‌های باینری بسته است. توسعه‌دهنده پیشنهاد می‌کند که Intel FSP (بسته پشتیبانی سفت‌افزار اینتل) که کدهای PE ۳۲ بیتی هستند و Ghidra به‌خوبی آن‌ها را می‌فهمد، اکنون هدفی ایده‌آل است. در حالی که شهروندان آمریکا با محدودیت‌هایی روبرو هستند، شهروندان اتحادیه اروپا صراحتاً اجازه مهندسی معکوس دارند. این موضوع ممکن است در نهایت انگیزه‌ی سازندگان سیلیکون برای ارائه سفت‌افزارهای بسته و فقط-باینری را از بین ببرد.
گام بعدی شما
- اگر با سخت‌افزارهای قدیمی سروکار دارید، از ترکیب Ghidra و مدل‌های استدلالی برای تحلیل سریع باینری‌ها استفاده کنید.
- برای کاهش توهمات AI در کدنویسی سخت‌افزاری، حتماً مقادیر صحیح (Known Good Values) را از سیستم‌های فعال استخراج کرده و به عنوان مرجع به مدل بدهید.
- بررسی کنید که آیا سخت‌افزارهای مورد استفاده شما تحت قوانین مهندسی معکوس اتحادیه اروپا قرار می‌گیرند یا خیر.
اما این تنها آغاز ماجراست؛ پورت این پلتفرم به عنوان یکی از اولین‌های x86 در fstart — جایگزین Rust-based برای coreboot — در گزارش بعدی بررسی خواهد شد.
گفتگو