Взлом Nintendo Switch 2: как пробить систему защиты

Исполнение кода как встроенного системного модуля

Единственный обычный модуль с правом отображать исполняемый код — это ro. Все модули имеют CFI, PAC и XOM, поэтому логичнее искать логическую ошибку, чем взлом памяти.

При загрузке программы ldr просит fs открыть ExeFS (файловую систему внутри контейнера NCA). Модуль fs возвращает два криптографических элемента: хеш заголовка NCA и подпись разработчика этого хеша. Загрузчик проверяет:

• валидна ли подпись Nintendo для прав доступа процесса и публичного ключа разработчика
• валидна ли подпись разработчика для хеша заголовка NCA

На бумаге это выглядит надёжно: сигнатура NPDM фиксирует права процесса и ключ, ключ фиксирует сигнатуру NCA, сигнатура фиксирует хеш, хеш фиксирует содержимое заголовка. Но на практике есть проблема: ответственность за совпадение файловой системы с хешем из заголовка NCA лежит на модуле fs, а у нас уже есть произвольное чтение/запись в fs.

От произвольного чтения/записи к исполнению нативного кода

Решение: заменить объект ExeFS, стоящий за IPC дескриптором загрузчика, на собственную временную файловую систему. Она должна содержать оригинальный main.npdm (чтобы прошла первая проверка подписи), но исполняемый файл main может быть произвольным. Вторая проверка пройдёт, потому что fs уже отправила валидный хеш и подпись оригинальной файловой системы.

Нужны две записи:

• Поместить временный объект файловой системы в таблицу доменов для ExeFS загрузчика
• Поместить оригинальный ExeFS в таблицу доменов временной файловой системы (для корректного подсчёта ссылок и стабильности)

Записи должны произойти после запроса загрузчиком ExeFS, но до обработки fs последующих запросов к файлам. Контроль над временем даёт замена дескриптора события, который fs использует для ожидания IPC сообщений от загрузчика, на событие, контролируемое из SmileBASIC.

Таким образом получено исполнение произвольного кода с правами любой программы, для которой известны данные main.npdm. А они известны для всех: благодаря произвольному чтению/записи можно скопировать NPDM любого модуля или игры.

Использован main.npdm модуля ro, так как его NPDM даёт права на вызовы системных функций: SetProcessMemoryPermission, MapProcessCodeMemory, MapProcessMemory. Команда MapProcessMemory создаёт записываемое отображение существующего кода fs. Для получения дескриптора на процесс fs использован трюк: перезаписан 4-байтовый дескриптор в IEventNotifier на значение 0xffff8001 (интерпретируется ядром как дескриптор текущего процесса), и после вызова GetEventHandle из SmileBASIC получен дескриптор на KProcess модуля fs.

Этот дескриптор передан собственному процессу ro, который патчит код fs.

Итог

Произвольное исполнение кода с правами обычного системного модуля открывает значительные возможности. Можно исследовать железо консоли без необходимости эксплуатировать драйверы каждого девайса отдельно. Это должно ускорить разработку полнофункционального CFW сообществом.

В ближайшее время стоит рассмотреть несколько направлений:

• Перенос эксплуатации fs на WebKit. Теперь, когда известна целевая ошибка, произвольные IPC вызовы менее критичны — можно попробовать вызвать ARW в fs через модификацию данных, используемых кодом работы с файловой системой в WebKit.
• Jailbreak в текущей форме привязан к компьютеру и не компрометирует встроенные системные модули кроме fs. Поиск ошибок в других встроенных модулях мог бы расширить возможности.
• С исполнением нативного кода в fs открывается доступ к криптографическому оборудованию консоли для работы, например, с дешифровкой NCA4.
• Эксплуатация протестирована и на Switch 1, но её упаковка в готовый вид требует дополнительной работы. Она не обеспечит возможностей модчипа, но работает без внешнего оборудования.

Предстоит увидеть, какой homebrew, эмуляцию и моды создаст сообщество для Switch 2.