تصور کنید یک آرایه RAID مدل Drobo 5D که ۱۴ سال است خاک می‌خورد، ناگهان با یک درایور دست‌ساز که توسط Claude از صفر نوشته شده، دوباره به زندگی برگردد. این پروژه که در ۲۰ اوت ۲۰۲۶ توسط fetzu.ch با جزئیات منتشر شد، ثابت می‌کند که مدل‌های زبانی بزرگ (LLM) اکنون می‌توانند در محیط‌های بسیار حساس «افزونه‌های هسته» (Kernel Extensions) و مهندسی معکوس باینری پیمایش کنند، حتی در حالی که اپراتور انسانی تخصص عمیقی در هک سخت‌افزار ندارد.
برای بسیاری از کاربران حرفه‌ای، پدیده‌ای به نام «یتیم شدن سخت‌افزار» زمانی رخ می‌دهد که یک شرکت ورشکست شده و به‌روزرسانی درایورها را متوقف می‌کند. شرکت Drobo رسماً در سال ۲۰۲۳ وارد مرحله تصفیه شد و مالکان آرایه‌های RAID آن را در برابر به‌روزرسانی‌های macOS بی‌دفاع گذاشت، زیرا آپدیت‌های سیستم‌عامل سازگاری قدیمی را از بین می‌بردند. توسعه‌دهنده این پروژه با یک ضرب‌الاجل سخت روبرو بود: نسخه macOS 27 با نام «Golden Gate» آخرین نسخه‌ای است که از Rosetta 2 پشتیبانی می‌کند و این یعنی عملاً تمام نرم‌افزارهای قدیمی باقی‌مانده از کار خواهند افتاد. سخت‌افزار خاص این توسعه‌دهنده ۱۴ سال بدون نقص فایل‌ها را ذخیره کرده بود و تنها یک حادثه جزئی در حدود سال ۲۰۱۹ داشت که در آن آداپتور برق دستگاه سوخته بود.
سعی کنید صحبت کردن به زبانی فراموش‌شده با سخت‌افزاری را تصور کنید که از همکاری با سیستم‌عامل‌های مدرن سر باز می‌زند. این دقیقاً چالشی بود که در اینجا وجود داشت. توسعه‌دهنده برای حل این مشکل از روشی به نام Vibe Coding (برنامه‌نویسی بر اساس حس و شهود) استفاده کرد؛ یعنی به‌جای تکیه بر یک نقشه معماری دقیق و سخت‌گیرانه، بر شهود مدل زبانی و اصلاحات تکراری تکیه کرد. او با صراحت اعتراف می‌کند که «تنبل و نادان» است و حتی برای اتوماتیک کردن دم کردن قهوه هم از LLMها استفاده می‌کند، اما با این حال، این پروژه مرزهای برنامه‌نویسی سطح سیستم را جابه‌جا کرد.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی توانایی‌های استدلالی مدل‌های زبانی اشاره کردیم، جابه‌جایی از کدنویسی خطی به رویکرد تکرار شونده، نتایج غیرمنتظره‌ای دارد. در این مورد، توسعه‌دهنده از مدل زبانی بزرگ — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — برای تحلیل پروتکل‌های بسته استفاده کرد.
فرآیند مهندسی معکوس
پروژه با یک تخلیه متنی (Context Dump) عظیم شروع شد. توسعه‌دهنده آخرین پنج نسخه از درایورها و نرم‌افزار Dashboard شرکت Drobo، از جمله یادداشت‌های انتشار (Release Notes) در قالب PDF را در اختیار Claude قرار داد. او در ابتدا از مدل Fable 5 روی تنظیمات High استفاده کرد، اما پس از اینکه درخواست‌ها پرچم‌گذاری شدند، به مدل Opus 5 روی تنظیمات Max (و در برخی مراحل Opus 4.8) تغییر وضعیت داد. این فایل‌ها از طریق یک شخص ثالث کمک‌رسان تهیه شده بود که نرم‌افزارهای قدیمی را آپلود و فهرست کرده بود. هدف نهایی این بود که تحلیل شود چرا سخت‌افزار در نسخه‌های جدید macOS شکست می‌خورد و آیا بازنویسی کامل آن ممکن است یا خیر.
Claude یک برنامه اجرایی پنج‌مرحله‌ای را پیشنهاد داد و طبق عادت مهندسان، شمارش را از عدد ۰ شروع کرد:
- فاز ۰: اولویت مطلق با حفاظت از داده‌ها در ابتدای کار.
- فاز ۱: اعتبارسازی پروتکل از طریق مقایسه خروجی داده‌ها بین یک دستگاه دارای درایور (یک iMac مدل ۲۰۱۷ که macOS 13 را اجرا می‌کرد) و یک دستگاه بدون درایور (یک MacBook Pro M5 Pro با macOS 26).
- فاز ۲: رمزگشایی محموله‌های رکورد (Record Payloads) با هدف اعتبارسنجی و استخراج مشخصات دقیق پروتکل.
- فاز ۳: ارائه یک رابط خط فرمان (CLI) کاربردی برای نمایش اطلاعاتی که معمولاً داشبورد Drobo نشان می‌داد.
- فاز ۴: ساخت درایور زنده (یک جایگزین واقعی برای Drobo Dashboard).
- فاز ۵: توسعه یک رابط گرافیکی (GUI) کامل برای جایگزینی دائمی داشبورد Drobo.
در فاز ۱، توسعه‌دهنده از یک ابزار کاربردی به زبان C به نام droboprobe استفاده کرد که توسط AI نوشته شده بود. برای کمک به تحلیل، Claude از توسعه‌دهنده خواست تا از وضعیت فعلی Drobo 5D در داخل داشبورد اصلی اسکرین‌شات بگیرد تا نیاز به تایپ دستی داده‌ها نباشد. این کار یک تضاد بحرانی را آشکار کرد: در حالی که دستگاه متصل (Mount) می‌شد، اما اندازه حجم (Volume Size) را به شدت اشتباه گزارش می‌کرد.
تضاد در اندازه حجم
مقایسه داده‌ها تفاوت فاحشی را در نحوه شناسایی سخت‌افزار نشان داد:
- داشبورد (iMac): کل ۵.۴۲ ترابایت | استفاده شده ۴.۲۵ ترابایت | آزاد ۱.۱۷ ترابایت
- macOS (مک جدید): کل ۱۷.۶ ترابایت | استفاده شده ۴.۷ ترابایت | آزاد ۱۲.۹ ترابایت
این موضوع تایید کرد که برای مدیریت منطق آرایه، حتماً به یک درایور درست نیاز است، زیرا اتصال پیش‌فرض (Native Mount) سیستم‌عامل داده‌های ظرفیت نادرستی را ارائه می‌داد.
عبور از موانع سیستمی
مانع فنی اصلی SCSITaskUserClient بود که در سخت‌افزارهای جدید خطای kIOReturnUnsupported برمی‌گرداند. Claude تشخیص داد که فراخوانی IOCreatePlugInInterfaceForService شکست می‌خورد چون هیچ سرویسی در مک جدید SCSITaskDeviceCategory را منتشر نمی‌کرد. دلیل این اتفاق در هدرهای (Headers) خود اپل نهفته بود: SCSITaskLib فقط برای دستگاه‌هایی خدمات ارائه می‌دهد که درایور داخلی در هسته (In-kernel driver) ندارند (و همچنین برای رایترهای نوری). چون Drobo توسط IOSCSIPeripheralDeviceType00 اپل شناسایی شده بود، دسترسی آن به کلاینت فضای کاربر (User-space client) مسدود می‌شد. توسعه‌دهنده همچنین احتمال وجود درهای پشتی (Back doors) را بررسی کرد اما متوجه شد تنها یک رابط USB و یک LUN وجود دارد که هر دو توسط سیستم اشغال شده بودند.
برای دور زدن این مشکل، AI جدول توزیع (Dispatch Table) کامل را از باینری موجود در iMac قدیمی استخراج کرد. این کار سلکتورهای خاصی را آشکار کرد:
- سلکتور ۲ (
sGetESAModePage): دریافت ۲ اسکالر در ورودی و خروجی یک استراکت ۱۳۰۸ بایتی (عملیات خواندن). - سلکتور ۳ (
sSetESAModePage): دریافت ۳ اسکالر به همراه یک استراکت ۱۳۰۸ بایتی در ورودی (عملیات نوشتن).
این تحلیل منجر به ساخت droboesa شد؛ ابزاری که رکوردهای ESA (معماری ذخیره‌سازی الکترونیکی) را استخراج می‌کرد. پس از دو تلاش — که یکی به دلیل نیاز به sudo برای اجرای launchctl list شکست خورد — Claude موفق شد «پروتکل مدیریت ESA دروبو» را بازسازی کند و نقشه راه دقیق درایور جدید را ترسیم نماید.
نبرد با امنیت macOS
پیاده‌سازی درایور که DroboDext نام گرفت، نیازمند یک ریسک بزرگ بود. توسعه‌دهنده مجوزهای خاص SCSIPeripheralsDriverKit را از اپل نداشت — و اشاره کرد که احتمالاً هرگز به عنوان یک «آقای هیچ‌کس از کوه‌های آلپ» که در حال مهندسی معکوس محصولی احتمالاً دارای پتنت است، این مجوز را دریافت نمی‌کند. بنابراین، او مجبور شد «حفاظت یکپارچگی سیستم» (SIP) را غیرفعال کند. برای جلوگیری از ریسک در دستگاه اصلی، او از یک MacMini M1 قدیمی با بتای macOS 27 استفاده کرد.
فرآیند نصب زنجیره‌ای از شکست‌ها و ری‌بوت‌ها بود. او با ۸ تله مختلف در بسته‌بندی و چرخه حیات (Lifecycle) مواجه شد، از جمله:
- مشکلات مجوز (Entitlement): کرش‌های اولیه به دلیل نبود دسترسی‌های لازم.
- چیدمان باندل: پیدا نشدن افزونه در داخل باندل اپلیکیشن.
- تضاد نام‌گذاری: مشکل در قراردادهای نام‌گذاری باندل dext.
- عدم تطابق معماری: کامپایل شدن dext برای
x86_64 arm64e(با احراز هویت اشاره‌گر) به‌جایarm64استاندارد. - امضای کد: شکست‌های مکرر در تایید امضای باینری.
در یک لحظه، AI حتی پیشنهاد داد که توسعه‌دهنده «دست از تلاش بردارد و استراحت کند»، اما پافشاری منجر به موفقیت شد. مقصر نهایی IOClass شناسایی شد، هرچند توسعه‌دهنده و AI درباره اینکه آیا این یک مشکل مجوز است یا خیر، بحث کردند. در نهایت با استفاده از روش جست‌وجوی باینری (Binary Search) برای تست ۱۲ کاندیدای مختلف مجوز در ۴ دور، تیم بالاخره ارتباط را برقرار کرد.
ویژگی‌های نهایی و تحویل
محصول نهایی با نام ReDrobo 1.0.0 از یک درایور ساده به یک اپلیکیشن همراه کامل تبدیل شد. توسعه‌دهنده یک رابط در نوار منو (Menu bar)، سیستم اعلانات و نظارت دقیق بر سلامت درایوها را اضافه کرد. ویژگی‌های نهایی شامل موارد زیر است:
- اطلاعات سطحی درایو: نمایش وضعیت سلامت، شماره سریال و نسخه فرم‌ور برای هر دیسک.
- داده‌های SMART: تلاش شد اما در نهایت بازیابی آن‌ها از آرایه غیرممکن بود.
- پرچم‌های ویژگی: پشتیبانی از حالت Read-only در نسخه ۱.۰.۰.
- پشتیبانی از چند دستگاه: قابلیت داخلی برای اتصال چندین دستگاه به یک کامپیوتر (هرچند تست نشده است).
- سازگاری مدل‌ها: پشتیبانی از سایر مدل‌های Drobo (فراتر از 5D تست نشده است).
- عیب‌یابی: یک ابزار اختصاصی برای خروجی گرفتن از گزارش‌های تشخیص.
- لاگ‌گذاری: ثبت وقایع در سمت اپلیکیشن با چهار سطح مختلف.
- نگهداری: یک حذف‌کننده (Uninstaller) کامل برای پاک کردن درایورهای باقی‌مانده.
کل این فرآیند تقریباً یک بعدازظهر و چند ساعت پرداخت نهایی زمان برد. کد منبع در گیت‌هاب در مسیر fetzu/ReDrobo برای کاربرانی که حاضرند SIP را غیرفعال کنند، منتشر شده است.
اپیلوگ: پس از تولد
این آزمایش تغییری بنیادین در تجربه توسعه‌دهندگان را نشان می‌دهد. نویسنده اعتراف می‌کند فرآیند آنقدر «بدون دخالت» (Hands-off) بود که او حتی جزئیات داخلی درایورهای macOS را یاد نگرفت و اشاره می‌کند که اگر هر مرحله را با دقت بیشتری بررسی می‌کرد، بینش بیشتری به دست می‌آورد. اما در عوض، نتیجه‌ای گرفت که به تنهایی در این بازه زمانی غیرممکن بود.
این اتفاق، LLM را از یک دستیار کدنویسی به یک مهندس ارشد سیستم تبدیل می‌کند که می‌تواند در پروتکل‌های باینری مستند نشده پیمایش کند. برای کاربر عادی، این یعنی طول عمر سخت‌افزارهای «مرده» دیگر به بقای شرکت سازنده گره نخورده است. اگر یک مدل زبانی بتواند پروتکل را رمزگشایی کند، جامعه می‌تواند سخت‌افزار را برای همیشه نگه دارد. این کار عملاً کاربرد سخت‌افزار را از طول عمر شرکتی جدا می‌کند. در حالی که این پروژه بر قدرت ابزارهای محلی تأکید دارد، برخی کاربران ترجیح می‌دهند برای مدیریت داده‌های خود از ترکیب ابزارهای متن‌باز مانند n8n و Ollama روی مک استفاده کنند تا کنترل کاملی بر حریم خصوصی داشته باشند.
اگر سخت‌افزار قدیمی دارید که پس از به‌روزرسانی سیستم‌عامل از کار افتاده، می‌توانید از رویکرد تکراری مشابه با یک مدل با قدرت استدلال بالا برای بررسی الگوهای ارتباطی دستگاه استفاده کنید.
گام بعدی شما
- اگر سخت‌افزار قدیمی دارید که پس از به‌روزرسانی سیستم‌عامل از کار افتاده، از مدل‌های استدلالی برای تحلیل الگوهای ارتباطی آن استفاده کنید.
- برای درک بهتر نحوه تعامل با هسته سیستم‌عامل، مستندات DriverKit اپل را مطالعه کنید.
- در صورت استفاده از ReDrobo، حتماً ابتدا از داده‌های خود نسخه پشتیبان تهیه کنید زیرا غیرفعال کردن SIP ریسک‌های امنیتی دارد. در این زمینه، توجه به نحوه مدیریت داده‌ها توسط هوش مصنوعی ضروری است؛ برای مثال، گزارش‌هایی درباره ذخیره‌سازی متنی تاریخچه فعالیت کاربران مک توسط OpenAI نشان می‌دهد که امنیت داده‌ها در محیط‌های AI همواره یک چالش است.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو