تصور کنید پروژه‌ای که پیش از این سال‌ها زمان می‌برد، حالا در کمتر از سه ماه به نتیجه برسد. این دقیقاً همان اتفاقی است که در بازسازی کد منبع بازی Snowboard Kids رخ داده است.
یک توسعه‌دهنده توانسته است ۱۰۰٪ کد بازی Snowboard Kids برای کنسول نینتندو ۶۴ را بازسازی (Decompile) کند. او این پروژه را تنها در ۸۴ روز به پایان رساند. به این معنا که هر تابع در بازی اکنون یک پیاده‌سازی به زبان C دارد که وقتی کامپایل شود، کد ماشینی تولید می‌کند که با نسخه اصلی سال ۱۹۹۹ کاملاً یکسان است.
کریس لوئیس (Chris Lewis) در ۲۷ اوت ۲۰۲۶ در یادداشتی منتشر کرد که این موفقیت حاصل ترکیب مدل‌های پیشرو هوش مصنوعی با یک چارچوب عامل‌محور (Agentic) و تخصص جامعه‌ی مهندسی معکوس است. این بازه زمانی در مقایسه با ۵۹۶ روزی که برای بازسازی دنباله این بازی (Snowboard Kids 2) لازم بود، یک جهش خیره‌کننده است. بازی اول با ۲۱۴۵ تابع، کوچک‌تر از نسخه دوم بود که ۲۹۹۵ تابع داشت.
مهندسی معکوس سخت‌افزارهای قدیمی معمولاً فرآیندی طاقت‌فرسا از آزمون و خطا است. در مورد N64، چالش اصلی استفاده از ابزارهای اختصاصی است. در حالی که بسیاری از بازی‌ها از کامپایلر متن‌باز GCC استفاده می‌کردند (مانند GCC 2.7.2 که در نسخه دوم بازی به کار رفت)، Snowboard Kids از IDO 5.3 استفاده کرده است؛ یک کامپایلر بسته از شرکت SGI که تحلیل و استدلال درباره آن بسیار دشوار است.
زمینه و تاریخچه IDO
کامپایلر IDO شرکت SGI به‌طور جدایی‌ناپذیری با تاریخچه نینتندو ۶۴ گره خورده است. از آنجایی که سورس‌کد این کامپایلر در دسترس نبود و محیط اصلی آن به سخت‌افزارها و نرم‌افزارهای منسوخ SGI وابسته بود، جامعه‌ی بازسازی مجبور شد ابتدا خودِ این زنجیره ابزار (Toolchain) را مهندسی معکوس کند. این تلاش‌ها شامل بازکامپایل استاتیک مجموعه‌های IDO 5.3 و 7.1 بود تا بتوان آن‌ها را روی سخت‌افزارهای مدرن اجرا کرد.
برخلاف کامپایلرهای متن‌باز، IDO فرآیند بهینه‌سازی و تولید کد را در چندین مرحله (Pass) مختلف تقسیم می‌کند. این کامپایلر کدها را به‌شدت تغییر می‌دهد؛ به این معنا که تغییرات بسیار کوچک در سورس C می‌تواند در این مراحل اثر انگشتی ایجاد کند و منجر به تخصیص کاملاً متفاوتی از ثبات‌ها (Register Allocation) شود. این موضوع باعث می‌شود بازسازی کد بیشتر شبیه به یک هنر باشد تا علم، چرا که مدل‌های زبانی (LLMs) اغلب در بازتولید دقیق خروجی‌های خاص این کامپایلر شکست می‌خورند.
چالش ابزارهای بسته
به دلیل اختصاصی بودن IDO، استدلال درباره آن بسیار سخت‌تر از کامپایلری مانند GCC است. جامعه‌ی توسعه‌دهندگان مجبور شدند با این کامپایلر مانند یک «جعبه سیاه» رفتار کنند و ویژگی‌های عجیب آن را از طریق مشاهده و تجربه کشف کنند. گردش کار معمول برای هر دو گروه انسان و عامل‌های هوش مصنوعی این بود که ابتدا هدف و عملکرد یک تابع را تعیین کنند، سپس کدی به زبان C بنویسند که آن هدف را شبیه‌سازی کند و در نهایت از یک ابزار تغییردهنده (Permuter) برای رفع تفاوت‌های باقی‌مانده استفاده کنند.
با این حال، برای اینکه این روش جواب دهد، ساختار زیربنایی کد باید درست باشد. شما نمی‌توانید صرفاً با استفاده از Permuter به تطابق برسید اگر منطق کد اساساً غلط باشد. رفتار خاص IDO باعث شد این گردش کار در مقایسه با GCC بسیار غیرقابل‌پیش‌بینی‌تر باشد.
گردش کار عامل‌محور (Agentic Workflow)
لوئیس به‌جای استفاده از یک چت‌بات ساده، سیستمی از عامل‌ها را در چهار محیط کاری (Worktree) مجزا مستقر کرد تا توابع را به‌صورت موازی پردازش کنند. هر محیط کاری، یک کپی مستقل از مخزن کد را در اختیار عامل قرار می‌داد. عامل‌ها یک حلقه مشخص را دنبال می‌کردند: شناسایی عملکرد تابع، نوشتن کد C تقریبی و سپس استفاده از Permuter برای تغییر جزئی کد تا زمانی که با باینری اصلی تطبیق یابد.
برای جلوگیری از گیر افتادن عامل‌ها در حلقه‌های بی‌نهایت، لوئیس ضرب‌الاجل‌های زمانی (Deadlines) صریحی برای هر وظیفه تعیین کرد. در پروژه Snowboard Kids 2، ابزار Permuter تا زمانی که تطابق ۱۰۰٪ حاصل می‌شد یا به‌صورت دستی متوقف می‌شد، اجرا می‌شد. اما ضرب‌الاجل‌های صریح به عامل‌ها اجازه داد تا زمان‌های انتظار (Timeout) معقولی تعیین کنند و بین زمان صرف‌شده برای Permuting و سایر استراتژی‌های حل مسئله تعادل برقرار کنند. این امر به مدیر انسانی اجازه داد تا روی دشوارترین توابع تمرکز و مداخله کند.
همگام‌سازی و مقیاس‌پذیری
برای مدیریت چهار محیط کاری، لوئیس از گزینه --shard در ابزار Nigel استفاده کرد که از هشینگ ساده برای تقسیم کاندیداها بین کارکنان بهره می‌برد. با این حال، این کار یک مشکل همگام‌سازی ایجاد کرد: تطابق یافته در یک محیط کاری تا زمان ادغام (Merge)، برای سایر محیط‌ها نامرئی بود و ادغام دوره‌ای در شاخه اصلی می‌توانست بیش از یک ساعت زمان ببرد.
برای کاهش این مشکل، لوئیس جست‌وجوی شباهت را به‌روزرسانی کرد تا هر محیط کاری را به‌طور مستقیم بررسی کند. این تغییر اجازه داد تا یک تابعِ تازه تطبیق‌یافته، بلافاصله به عنوان مرجع برای عامل‌های دیگر عمل کند. برای مثال، سیستم می‌توانست اطلاع دهد که تابعی مانند func_80094A94 اصلاح شده است و بدون نیاز به ادغام کامل، از آن در سایر محیط‌ها استفاده شود. این کار از واگرایی محیط‌های کاری جلوگیری کرد و زمان تلف‌شده روی تلاش‌های تکراری را کاهش داد.
جزئیات فنی و ابزارها
به دلیل بهینه‌سازی‌های تهاجمی IDO که تغییرات کوچک C را به تخصیص‌های متفاوت ثبات تبدیل می‌کند، تیم از ابزارهای تخصصی زیر استفاده کرد:
- N64 Decomp Workbench: مجموعه‌ای از ابزارها و مستندات برای عیب‌یابی ناهماهنگی‌های نهایی MIPS. این ابزار به عامل‌ها اجازه داد تا ناهماهنگی‌ها را طبقه‌بندی کنند، جابه‌جایی‌ها (Relocations) را محاسبه کنند و مراحل کامپایلر را بازپخش (Replay) کنند. بازپخش مراحل نیازمند باینری‌های خاص کامپایلر است، اما اطلاعاتی را فاش می‌کند که یک Diff ساده اسمبلی نمی‌تواند. این ابزار به عامل‌ها کمک کرد تا تفاوت‌های ساختاری را از تفاوت‌های تخصیص ثبات تشخیص دهند.
- DECOMPILATION_LEARNINGS.md: عامل‌ها موظف بودند رفتارهای تکراری و عجیب IDO را در یک فایل مارک‌داون مشترک ثبت کنند. هرگاه عاملی یک نکته کلی درباره کامپایلر کشف می‌کرد، شواهد را آنجا ثبت می‌کرد و یک حلقه بازخورد ایجاد می‌شد که یادگیری یک عامل را به عملکرد بقیه منتقل می‌کرد. این کار به هوش مصنوعی اجازه داد تا درس‌ها را از طریق حافظه‌های محلی بین وظایف جابه‌جا کند.
- N64Sym: این ابزار به شناسایی توابع کتابخانه استاندارد نینتندو (libultra با بیش از صد بخش سورس) و کتابخانه صوتی libmus کمک کرد. به عامل‌ها دستور داده شد که سورس‌های موجود در SDK را به عنوان نقطه شروع در نظر بگیرند و تمام نسخه‌های احتمالی SDK، گزینه‌های کامپایلر و مسیرهای کامپایل شرطی را پیش از تلاش برای پیاده‌سازی از صفر، بررسی کنند.
- اسکریپت‌نویسی m2c: یک عامل اسکریپتی نوشت تا ابزار
m2cرا روی تمام توابع تطبیق‌نیافته اجرا کند. هرچند نرخ موفقیت پایین بود (۱۷ تابع از ۱۸۳۰ تابع، یا ۰.۹۳٪)، اما این روش بسیار مقرون‌به‌صرف‌تر از مصرف توکن‌های گران‌قیمت مدل‌های زبانی بود.
هم‌افزایی انسان و هوش مصنوعی
با وجود این سرعت، پروژه یک پیروزیِ صرفاً ماشینی نبود. طبق مستندات، حدود ۴.۸٪ از کامیت‌های تطبیقی نیاز به دخالت متخصصانی چون inspectredc، Bl00D4NGEL و queueRAM داشت. لوئیس همچنین از iFuzzle، JamesBLewis و douglasjv برای فراهم کردن توکن‌ها تشکر کرد. او تأکید کرد که هیچ مقدار از هوش مصنوعی نمی‌توانست جایگزین شهود انسانی برای پیچیده‌ترین بخش‌های منطقی کد شود.
برای مقایسه، بازسازی بازی Pilotwings 64 — یکی از عناوین زمان عرضه N64 و یک اثر کلاسیک — تنها ۷۴ روز زمان برد. اگرچه Pilotwings حدود ۱۶٪ توابع کمتری نسبت به Snowboard Kids داشت، اما در مجموع حجم کد کامپایل‌شده بیشتری داشت. این موضوع نشان می‌دهد که زمان‌بندی Snowboard Kids یک معیار واقعی برای توانمندی‌های مهندسی معکوس به کمک هوش مصنوعی است، هرچند به دلیل تفاوت در حجم کد، مقایسه کاملاً دقیق نیست.
عملکرد مدل‌ها
لوئیس مدل‌های پیشرو متعددی از جمله GPT-5.5، GPT-5.6، Claude 4.5 و Fable را آزمایش کرد. در تجربه او، مدل Codex (به‌ویژه نسخه Sol xhigh) همچنان در این نوع خاص از کارهای کدنویسی سطح پایین، عملکرد بهتری نسبت به Claude داشت.
در مقابل، مدل GLM 5.2 از طریق z.ai ناامیدکننده توصیف شد. در حالی که پیش از این به دلیل محدودیت‌های استفاده سخاوتمندانه محبوب بود، اما این مدل از تأخیر (Latency) بسیار زیاد و محدودیت‌های جدیدتر رنج می‌برد. چرخه‌های بازخورد چنان طولانی شد که لوئیس در نهایت اشتراک خود را لغو کرد.
مسیر پیش رو
رسیدن به تطابق ۱۰۰٪ تنها گام اول است. تطابق کامل به این معناست که تیم برای هر تابع کد C دارد، اما لزوماً به این معنا نیست که عملکرد هر تابع را به‌طور کامل درک کرده‌اند. اولویت فعلی، جایگزینی نام‌های تولیدشده توسط AI با نام‌های معنادار، شناسایی فیلدهای ناشناخته در ساختارها (Structures)، پاک‌سازی تطبیق‌های نامناسب و توصیف حجم زیادی از داده‌ها است.
این اقدامات، مادینگ (Modding) پیشرفته‌تر و بازکامپایل استاتیک برای سخت‌افزارهای مدرن را ممکن می‌سازد. به‌طور خاص، سورس‌کد فعال به Speedrunnerها کمک می‌کند تا مسیرهای CPU و عوامل دقیق اثرگذار بر سرعت بازیکن را درک کنند.
اهداف آینده عبارتند از:
- توسعه یک بازکامپایل کامل برای Snowboard Kids با بهره‌گیری از پچ‌هایی که پیش‌تر برای Snowboard Kids 2: Recompiled ایجاد شده است.
- پورت کردن مراحل و محتوای بازی اول به موتور بازی دوم.
- تلاش برای بازسازی Snowboard Kids Plus، نسخه گسترش‌یافته‌ای که منحصراً برای پلی‌استیشن در ژاپن عرضه شد و دارای شخصیت‌ها و مراحل اضافی است.
این پروژه ثابت می‌کند که اگرچه هوش مصنوعی هنوز نمی‌تواند جایگزین مهندس معکوس خبره شود، اما می‌تواند به عنوان یک «ضریب قدرت» عظیم عمل کند. با خودکارسازی کارهای تکراری تطبیق الگوهای باینری، متخصص انسانی می‌تواند بر روی پازل‌های معماری سطح بالا تمرکز کند که هوش مصنوعی هنوز در حل آن‌ها مشکل دارد.
گام بعدی شما
- بررسی مستندات بازسازی Snowboard Kids برای درک نحوه تعامل عامل‌های AI با ابزارهای MIPS.
- مطالعه درباره تفاوت‌های خروجی کامپایلرهای بسته (مانند IDO) در برابر کامپایلرهای متن‌باز.
- دنبال کردن پروژه‌های بازسازی Snowboard Kids Plus برای کنسول پلی‌استیشن.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو