جیلبریک سوئیچ 2

می توانید یک کپی از اکسپلویت را از مخزن ns2jb دریافت کنید.

ns2jb یک جیلبریک فقط نرم‌افزاری است که برای سوییچ 2 استفاده می‌شود. این امکان اجرای کد بومی دلخواه را به عنوان هر سیستم معمولی و به‌عنوان سیستم داخلی fs فراهم می‌کند. این به ما امکان می‌دهد بازی‌های Homebrew، Reverse Engineer و Mod Switch 2 را اجرا کنیم، از فایل‌های ذخیره شده از سوییچ نسخه پشتیبان تهیه کنیم و از طریق MMIO به اکثر لوازم جانبی Switch 2 دسترسی داشته باشیم. طبق اطلاعات من، این اولین سوء استفاده از سوییچ 2 است.

برای نشان دادن قابلیت‌های این جیلبریک، Codex یک انحصاری Switch 2، Mario Kart World را اصلاح کرد. با تشکر از دوستانم در Dabney House که به من کمک کردند تا شخصیت هایی را برای اضافه کردن و آزمایش بازی انتخاب کنم.

اولین کاری که انجام دادم این بود که یک مهار در اطراف سوییچ 1 و 2 راه اندازی کردم تا Codex در حالت ایده آل بتواند بدون من Switch 2 را جیلبریک کند:

ویرایش: بسیاری از مردم از من می‌پرسند که آیا واقعا از این دستور استفاده کرده‌ام. نه، این فقط یک شرح احمقانه است. من یک هدف / برای اجرای کد userland تعیین کردم، اما موفق نشد. خود فرار از زندان به مدت 2 هفته تلاش زیادی کرد. با این حال، Mario Kart World در یک روز به طور کامل کدگذاری شد و فقط برای سرگرمی بود.

JetKVMها به Codex اجازه می‌دهند تا ورودی‌های کنترلر را از طریق USB به سوییچ‌ها ارسال کند و خروجی ویدیو را از طریق HDMI دریافت کند. ما همچنین به روشی برای فشار دادن دکمه پاور نیاز داریم - وقتی سوئیچ 2 خراب می شود، برای راه اندازی مجدد نیاز به فشار دادن دکمه دارد.

این همان چیزی است که سوئیچ چراغ بلوتوث آمازون برای آن است. وقتی اهرم پایین می آید، دکمه پاور را فشار می دهد. هنگامی که دکمه پاور به طور کامل فشار داده شد، بقیه گشتاور اهرم مکانیسم را بالا می برد.

WebKit یک هدف محبوب برای جیلبریک های کنسول است، بنابراین جای تعجب نیست که Codex آن را برای اجرای کد اولیه انتخاب کرده است.

ادعا می‌کند که با بهره‌گیری از WebKit n-day بارگیری شده از طریق یک پورتال اختصاصی Wi-Fi، «ربایش جریان کنترل بومی» دارد.

ما می‌خواهیم اجرای کد را در سرویس‌های میکروکرنل (یا «sysmodules» در سوییچ دریافت کنیم)، بنابراین می‌توانیم Homebrew، بازی‌های مود، ذخیره‌سازی‌های دانلود و غیره را اجرا کنیم. متأسفانه، این رویکرد جایگزینی یک شی تابع جاوا اسکریپت با دیگری فراتر از توابع موجود تعمیم نمی‌یابد — ما به روش جدیدی برای برقراری تماس‌های IPC دلخواه نیاز داریم. که سخت به نظر می رسد.

Codex هدف را برای تکمیل این مراحل بازنشانی کرده است. این یک شرط جانبی است؛ ممکن است موفق شود 1، اما بیایید واقعی باشیم: دسترسی به WebKit و پاداش نینتندو BBP احتمالا بسیاری را قبل از من ترغیب کرده است که به اینجا نگاه کنند.

در حالی که اجرا می شود، بیایید گزینه های دیگر را بررسی کنیم.

ایده من این بود که بازی های Switch 1 را هدف قرار دهم، به دو دلیل:

شاید هنوز بتوانیم نقاط مثبت سطح حمله مرورگر را دریافت کنیم - هماهنگی از جاوا اسکریپت، استفاده از n-days موجود و غیره - در حالی که با یافتن یک بازی Switch 1 که یک مرورگر را تعبیه می کند، از جنبه های منفی کاهش WebKit جلوگیری کنیم؟ چیزی شبیه به Electron، اما برای بازی‌ها، بنابراین می‌توانیم سوءاستفاده‌ای مانند Discord RCE را انجام دهیم. در حال حاضر نمی‌توانم یافته‌های این رویکرد را به صورت عمومی فاش کنم، اما خوشبختانه، بازی‌های سوییچ 1 دیگری نیز وجود دارد.

به طور خاص، من به SmileBASIC علاقه مند هستم. این به این دلیل است که قبلا در smilehax pwn شده است و امکان اجرای کد فضای کاربران در 3DS را می دهد. این یک پایگاه کد غول پیکر ++C است. مطمئنا، اگر یک خرابی حافظه قابل بهره برداری در مفسر BASIC وجود داشته باشد، می تواند دیگری وجود داشته باشد.

Codex یک سرریز اعداد صحیح 32 بیتی مفید در مفسر پیدا کرد. هنگام حذف موارد از یک آرایه، مفسر موقعیت + count <= array.length را بررسی می‌کند، اما مجموع می‌تواند بسته شود و منفی شود. برای پر کردن شکاف ایجاد شده با حذف عناصر، قرار است عناصر باقی مانده را به سمت چپ جابجا کند، مانند:

فرض کنید یک آرایه رشته ای R به طول 4 داریم و REMOVE R,&H60000000,&H3FFFFFFF را اجرا می کنیم. موقعیت + تعداد به 0x9ffffffff می رسد. به عنوان یک عدد صحیح ۳۲ بیتی با علامت منفی، کمتر از array.length است. ضرب در 8 نیز بسته می شود، بنابراین ما در نهایت با انجام memmove (پشتیبانی، پشتیبان - 8، 32)، 8 بایت قبلی را به آرایه می کشیم. این فرمان خطای Out of memory را گزارش می کند، اما مهم نیست، زیرا کپی قبلا اتفاق افتاده است.

این مفید است زیرا 8 بایت قبل از هر آرایه در SmileBASIC حاوی یک اشاره گر به خود آرایه است! پس از REMOVE، عملیات R[0] با پشتوانه آرایه مانند یک رشته برخورد می کند.

از آنجایی که یک اشاره گر چه اندازه میدان طول R[0] را اشغال می کند، طول رشته بسیار زیاد است و می توانیم خواندن و نوشتن را خارج از محدوده انجام دهیم. ما با کپی کردن و از زیر رشته های R[0] در حافظه می خوانیم و می نویسیم.

این یک بازی سوییچ 1 بود، بنابراین عامل SmileBASIC می‌توانست روی اکسپلویت روی سوییچ 1 من کار کند، در حالی که عامل WebKit روی سوییچ 2 کار می‌کرد. پس از مدتی، ROP دریافت کرد.

بسیار خوب، اکنون ما نیاز داریم که روند ممتازتری را به خطر بیاندازیم. ما به sysmodules معمولی و sysmodules داخلی علاقه مند هستیم.

کدام سیستم را باید دنبال کنیم؟ ما کد آنها را نداریم، بنابراین مشخص نیست که کدام سیستم‌ها دارای چه امتیازاتی هستند.

من چند نمونه از Codex را برای اجرای کد سیستمی ارائه کردم. بیشتر آنها تمرکز خود را روی صدا و ldn انتخاب کردند. فکر می‌کنم این به این دلیل است که صدا و ldn در سوییچ 2 باگ‌هایی داشته‌اند. Codex همچنین سرویس NV را بررسی کرده است، احتمالا به این دلیل که درایورهای GPU به طور کلی مثمر ثمر هستند؟

در همین حین، من شروع به نگاه کردن به سیستم fs داخلی کردم، زیرا:

دلیل اول برای من جذاب ترین است. حتی اگر نتوانیم یک جیلبریک مفید از fs دریافت کنیم، حداقل می‌توانیم برخی از سایر سیستم‌ها را رمزگشایی کنیم تا Codex بتواند باگ‌هایی را در آنها پیدا کند. سایر سیستم‌ها مانند ldr و ro جذاب به نظر می‌رسند زیرا مجوز نقشه‌برداری از حافظه اجرایی 3 را دارند، اما سطوح حمله بزرگی ندارند، به خصوص از SmileBASIC. بعدا به آنها باز خواهیم گشت.

یک دسته IFileSystem دارای یک فرمان IPC، GetEntryType است. این یک رشته مسیر را می گیرد که با Path::Normalize نرمال شده است.

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

ما به یک تخصیص قربانی خوب برای سرریز کردن نیاز داریم. Codex دریافت که شی BufferedStorage یک ورودی کش برای فایل های خود اختصاص می دهد. اگر بیت کثیف آن ورودی تنظیم شده باشد، فایل را می‌خواند و می‌نویسد و به دنبال اشاره‌گر به داده‌های ذخیره‌شده در حافظه پنهان می‌رود. ما می توانیم آن را برای خواندن/نوشتن دلخواه ربودیم 4 .

از اینجا، از طریق حافظه اسکن کردم تا شیء اتصال SmileBASIC را پیدا کنم و PID ذخیره شده را روی 1 تنظیم کنم. اکنون، فرآیند من "FullPermission" دارد، به این معنی که می توانم اقدامات سیستم فایل ممتاز را انجام دهم. من حافظه داخلی و همه کدهای معمولی سیستم را کنار گذاشتم، بنابراین Codex می‌توانست آنالیز آفلاین را انجام دهد و می‌توانستم بفهمم کجا باید بروم.

Homebrew و modding معمولا به اجرای کد بومی خودمان متکی هستند. با نگاهی به dump ها، تنها سیستم معمولی با اجازه نقشه برداری کدهای اجرایی ro است. همه این سیستم‌ها دارای CFI، PAC و XOM هستند. رابط کاربری ماژول نیز بسیار کم به نظر می رسد. به نظر می رسید که دنبال کردن یک اشکال منطقی مفیدتر از جستجوی مستقیم خرابی حافظه در رو باشد.

بیایید اولین نکته در مورد ارائه کد رمزگشایی شده توسط fs را دوباره مرور کنیم. این برای تخلیه کد برای sysmodules معمولی مفید بود. عملکرد مورد نظر این رابط چیست؟ در حال بارگذاری برنامه ها؟

بازی‌ها و سیستم‌های معمولی به‌عنوان بایگانی محتوای نینتندو یا NCA توزیع می‌شوند که حاوی یک تصویر سیستم فایل به نام ExeFS هستند. این شامل یک فایل برای ابرداده اصلی اجرایی، اصلی و برنامه، main.npdm است.

برای بارگذاری یک برنامه، سیستم ldr داخلی از fs می‌خواهد ExeFS را باز کند و fs با یک دسته IPC به سیستم فایل پاسخ می‌دهد. fs همچنین دو بخش از اطلاعات رمزنگاری را در مورد هدر NCA ارائه می‌کند: هش هدر SHA-256 و امضای توسعه‌دهنده آن هش. لودر از این اطلاعات برای انجام دو بررسی امضا استفاده می کند:

به نظر من از نظر رمزنگاری مناسب است، زیرا در تئوری:

با این حال، در عمل، من در مورد آخرین ادعای خود تردید دارم، زیرا این وظیفه ماژول fs است که اطمینان حاصل کند که سیستم فایل ارائه شده با هش سیستم فایل هدر NCA مطابقت دارد و ما ARW در آن داریم.

در واقع، با ARW، می‌توانیم شی ExeFS پشت دسته IPC لودر را با سیستم فایل موقت خود جایگزین کنیم. این فایل سیستم هنوز نیاز به ارائه یک main.npdm توسعه دهنده معتبر برای اولین بررسی بارگذار دارد، اما اصلی اجرایی خود می تواند دلخواه باشد. بررسی دوم انجام می شود زیرا تا زمانی که لودر سیستم فایل را باز می کند، fs قبلا هش هدر NCA و امضای معتبر را برای سیستم فایل اصلی ارسال کرده است.

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

فرآیند fs لیستی از اتصالات IPC خود را حفظ می کند. هنگامی که یک اتصال دارای یک پیام IPC جدید است، fs آن را پردازش می کند. با استفاده از خواندن/نوشتن دلخواه خود، می‌توانیم دستگیره fs منتظرها برای اتصال IPC لودر را با دسته رویدادی که از SmileBASIC کنترل می‌کنیم، جایگزین کنیم. این به ما امکان می دهد کنترل کنیم که fs یک پیام لودر را پردازش می کند.

با این کار، می توانیم کد دلخواه را مانند هر برنامه ای که برای آن main.npdm داریم، اجرا کنیم!

چه main.npdm داریم؟ خوب، همه آنها. با ARW، می‌توانیم از اتصال fsp-srv لودر برای کپی کردن NPDM هر سیستم یا بازی معمولی استفاده کنیم.

ما از این قابلیت برای راه اندازی کد خود با استفاده از NPDM ro استفاده خواهیم کرد. همانطور که قبلا ذکر شد، NPDM ro به آن اجازه فراخوانی SVCهای هسته مانند SetProcessMemoryPermission، MapProcessCodeMemory و MapProcessMemory را می دهد. در این مورد، ما از MapProcessMemory برای ایجاد نمای قابل نوشتن از کدهای موجود fs استفاده خواهیم کرد. همچنین می‌توانیم با خواندن این نما، کد fs را حذف کنیم.

با این حال، این فراخوان ها به یک دسته KProcess برای پردازش نیاز دارند. برای دستیابی به fs، از ARW خود برای بازنویسی دسته 4 بایتی IEventNotifier با 0xffff8001 استفاده می کنیم و سپس GetEventHandle را از SmileBASIC فراخوانی می کنیم. هسته این مقدار را به معنای "دسته فرآیند جاری" تفسیر می کند، بنابراین SmileBASIC دسته KProcess fs را دریافت می کند.

سپس می‌توانیم این دسته را به فرآیند ro سفارشی خود بفرستیم، که کد fs را اصلاح می‌کند.

اجرای کد دلخواه با مجوزهای هر سیستم مدول معمولی واقعا قدرتمند به نظر می رسد. ما می توانیم سخت افزار را بدون استفاده از درایور هر دستگاه بررسی کنیم. من امیدوارم که این به جامعه هومبرو کمک کند تا به سمت CFW پیشرفت کند.

در کوتاه مدت، چند مرحله بعدی وجود دارد که فکر می کنم جالب باشد:

در حال حاضر، من برای دیدن همه نسخه های خانگی، شبیه سازی و مودینگ سوییچ 2 هیجان زده هستم.

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

نمی‌دانم آیا روزی نینتندو سیستم‌های معمولی و حتی کدهای بازی را از طریق حباب‌های رمزگذاری‌شده ترسیم خواهد کرد که فقط هسته یا مانیتور امن می‌تواند رمزگشایی کند. سپس، هیچ فرآیند فضای کاربری نمی تواند هیچ کدی را در سیستم مشاهده کند - هرگز نمی توان نگاشت RX در فضای کاربر وجود داشت. حتی ماژول لودر که فرآیندهای جدیدی را شروع می کند، از یک سطح استثنا بالاتر برای بارگیری حباب های رمزگذاری شده ای که عرضه می کند، درخواست می کند. معاوضه هایی وجود دارد، مانند اینکه بازی ها قادر به خواندن کد خود در زمان اجرا نیستند. با این حال، نینتندو در حال حاضر شروع به حذف ویژگی های کد پویا، مانند سیستم JIT کرده است.

من تعجب می کنم که آیا این جهتی است که سوییچ در حال حرکت است. خوشبختانه آن روز امروز نیست. ↩

در ابتدا، خواندن/نوشتن اولیه Codex، هر بار که می خواست نشانگر بافر پشتیبان را تغییر دهد، سرریز بافر را روی شیء کش تکرار می کرد. این به ثبات لطمه می زند، به ویژه هنگامی که چندین نشانگر را به طور متوالی دنبال کنید، زیرا هر تغییر فرصتی برای از کار انداختن سیستم است. می‌توانیم از ترفند مشابهی در اینجا استفاده کنیم. می‌توانیم از برخی سرریزها استفاده کنیم تا نشانگر بافر پشتیبان اولین ورودی حافظه پنهان را به سمت ابرداده ورودی حافظه پنهان دیگر قرار دهیم. سپس می‌توانیم نشانگر ورودی حافظه پنهان دوم را بدون خطر سرریز بیشتر جایگزین کنیم. ↩