Xbox 360 microsoft xbox 360 прошивка. Как прошить Xbox 360 и зачем это нужно? – Пошаговая инструкция

Защита и взлом Xbox 360 (Часть 1)

1543216 марта 2020 в 09:24

Вы наверное слышали про игровую приставку Xbox 360, и что она «прошивается». Под «прошивкой» тут имеется в виду обход интегрированных устройств защиты для пуска копий игр и самописного софта. И вот тут появляются вопросы! Каких устройств, как они обходятся? Что же наворотили создатели, как это смогли обойти? На самом деле, тема чрезвычайно широкая и увлекательная, в особенности для Xbox 360 — тут можно встретить уязвимости в ПО, аппаратные недостатки, и совершенно уж волшебную магию. Интересно? Заглядываем! В первой части у нас знакомство с гипервизором, приводами и прошивками…

Знакомимся с подопытным

Игровая приставка Xbox 360 увидела свет аж в 2005 году и с тех пор не претерпевала конфигураций в свойствах железа. Всё время, что она выпускалась, это были те же самые:

  • 3.2 GHz PowerPC CPU, / 3 ядра
  • 500 MHz GPU
  • 512 MB RAM
  • SATA DVD-ROM
  • SATA HDD (опционально)

Да, со временем изменялся дизайн, уменьшались нанометры:

Тем не наименее, все игры идиентично отлично работали на всех «ревизиях» приставок – это как раз тот вариант, когда современные игры можно запустить на оборудовании 2005 года.

В момент релиза было изготовлено громкое заявление, что консоль разрабатывалась как можно наиболее защищённой – кастомные чипы с защитой на аппаратном уровне, и вообщем, хакеры такового ещё не видывали:

There are going to be levels of security in this box that the hacker community has never seen before

Что же выдумали разработчики?

Во-первых, они сделали всё, чтоб программный код системы нельзя было достать. В центральный процессор встроили ROM на 32 КБ, содержащий первичный загрузчик (1BL) и SRAM на 64 КБ, в котором он исполнялся. Из кристалла CPU содержимое ROM достать чрезвычайно и чрезвычайно непросто:

Во-вторых, в тот же процессор запихнули особые фьюзы – пережигаемые (в буквальном смысле, высочайшим напряжением) перемычки, типичная однократно программируемая память. Фьюзы содержали:

  • биты блокировки JTAG интерфейса
  • биты, определяющие назначение приставки (retail / devkit / testkit)
  • уникальный 128-битный ключ процессора
  • счётчики Lock-Down Value (LDV) для запрета даунгрейда

Да-да, количество фьюз ограничено. Ежели вы умудрились обновить свою приставку 80 раз попорядку, счётчик CFLDV кончится и … не знаю, я не пробовал так делать. Возможно, приставка больше не сумеет обновляться.

В-третьих, создатели реализовали цепочку доверия. Для проверки подлинности загрузчиков использовалась композиция современных (на тот момент) алгоритмов SHA-1 и RSA-2048, что исключало возможность пуска собственного кода либо неавторизованной модификации загрузчиков даже в случае, ежели вы каким-то образом достали все ключи из приставки и смогли пересобрать систему.

В-четвёртых, создатели решили пойти далее по принципу «никому не доверяй» и запихнули в тот же несчастный CPU особый аппаратный модуль защиты ОЗУ! С его помощью все области с программным кодом шифровались, а для более принципиальных областей (гипервизор) врубался контроль целостности!

Сиим создатели защищались от DMA атак, когда через наружные устройства, имеющие доступ к оперативной памяти, изменяют программный код системы в ОЗУ.

Наконец, разграничением прав на регионы памяти занимался гипервизор. Лишь он мог сделать странички исполняемыми, естественно, перед сиим он инспектировал цифровую подпись, так что загрузить неподписанный код либо исполнить что-то из области данных нельзя было даже через уязвимость в каком-нибудь драйвере либо игре (ось и игры запускались с правами kernel).

В итоге, операционная система Xbox 360 была отлично защищена, и поэтому в качестве первого вектора атаки был избран DVD-ROM.

Запускаем… бэкапы!

В Xbox 360 главным носителем для игр был избран двухслойный DVD-диск. Естественно, и тут присутствовали защитные механизмы:

  • обмен данными с DVD-ROM шифровался неповторимым ключом
  • в начале диска были особые «Security Sectors» для доказательства лицензионности
  • исполняемые файлы на диске имели цифровую подпись

Но защите DVD-привода было уделено еще меньше внимания, чем основной системе. Игровая приставка оказывала DVD-приводу очень огромное доверие — конкретно DVD-ROM определял лицензионность диска. Наиболее того, прошивка хранилась во наружной памяти и могла быть считана программатором:

В итоге, 14 мая 2006 года commodore4eva (c4eva) выпустил первую измененную прошивку для привода модели TS-H943:

README к релизу прошивки

— Xtreme firmware for TS-H943 Xbox 360
— Here it is, the long awaited World first Xbox 360 backup firmware modification to boot all game backups!

Features
— Boots all Xtreme Xbox 360 backups
Boots all Xtreme Xbox 1 backups
Boots all Xbox 360 originals
Boots all Xbox 1 originals on Xbox 360
Xtreme0800 extraction firmware enables drive to function natively under Windows without any hardware conversion/adaptors
Use on Xbox Live at own risk

Technical details
— Reads Xbox 360 security sector from PSN 04FB1F (Layer 0)
Reads Xbox 1 security sector from PSN 605FF (Layer 0)
Security sector must be extrated using Xtreme0800 360 firmware for Xbox360 games and Xbox 1 games
Will not boot Xbox 1 backups made with Xbox1 605b 0800 firmware (maybe in future release)

Прошивка читала сектора сохранности из фиксированных областей на DVD-болванке и обманывала приставку, заставляя ту мыслить, что вставлен лицензионный диск.

Читайте также  Как обойти блокировку яндекса в украине. Как обойти блокировку ВК, Одноклассников и Яндекса в Украине

Сразу с сиим была выпущена прошивка «0800», предназначенная для сотворения копий игр и чтения секторов сохранности. Привод Xbox 360, прошитый таковой прошивкой, определялся в компе и мог на сто процентов читать сектора диска с игрой.

README по использованию 0800 прошивки

Extracting Security Sector
— Ensure DVD drive has been flashed with Xtrm0800.bin firmware. Drive can now work under Windows.
Insert original game disk into drive and wait for windows to detect disk change
Run DVDinfoPro
Enter the following four custom cdb commands:

AD 00 FF 02 FD FF FE 00 08 00 01 C0
AD 00 FF 02 FD FF FE 00 08 00 03 C0
AD 00 FF 02 FD FF FE 00 08 00 05 C0
AD 00 FF 02 FD FF FE 00 08 00 07 C0

Then save hexadecimal display as bin file as SS.bin

Creating a game backup
— Ensure DVD drive has been flashed with Xtrm0800.bin firmware. Drive can now work under Windows.
Extract Isobuilder.rar
Insert original game disk into drive and wait for windows to detect disk change
Run DVDinfoPro
Enter the following custom cdb command to unlock drive: (game data visable)

FF 08 01 01

Run Isobuster
Right click on DVD and select Extract From-To
Click Length and enter number of LBAs as follows:

Xbox 1 Original Number of LBA to read 3431264 decimal
or
Xbox 360 Original Number of LBA to read 3567872 decimal
Select User Data (2048 bytes/block)
Click Start Extraction
Enter filename as game.iso and click Save
Upon read error dialogue box choose fill with blank zeros for sector and select use this selection for all errors
Copy game.iso and ss.bin to the relevent isobuilder directory (Depending on Xbox 360 or Xbox 1 game)
Run build360.bat (Xbox 360 game) or build.bat (xbox 1 game)
Ensure your burner will set the booktype of DVD+R DL to DVDRom
Burn with CloneCd and choose the image.dvd file

Ещё игру можно было отчасти скопировать последующим трюком:

  • ставим в компьютерный DVD-ROM обыденный двухслойный диск
  • ждём, пока успокоится и закончит крутиться
  • скрепкой открываем лоток и меняем диск на игру от Xbox 360
  • закрываем лоток и делаем образ диска!

(Срабатывало не на всех моделях DVD-ROM)

Самое принципиальное, что прошивался привод только программно, особыми ATA-командами. В комплекте шла особая программа для считывания уникальной прошивки и записи измененной. В уникальной прошивке хранился свещенный ключ, которым привод был привязан к Xbox 360:

Утрата ключа означала невозможность пуска даже лицензионных дисков, так что некие записывали ключ в блокноте, сохраняли его везде, где лишь можно, это было самым свещенным знанием.

Отдельной темой шла паника по поводу игры онлайн. Все боялись, что Microsoft выяснит, что привод изменен и дистанционно отключит приставку. Некие даже делали аппаратный мод для переключения меж заводской и измененной прошивкой:

На уникальной прошивке игрались «в лицензии» и с подключением в сеть, на измененной интернет-кабель стыдливо отключали. Кстати, паника была не напрасно, а вот такие моды были совсем напрасны, всё логировалось и без подключения к сети.

Ровно через месяц (15 июня 2006 г.) прошивку портировали на другую модель привода, что ставили в те времена в Xbox 360 — Hitachi GDR3120L. У него также была наружная флешка, содержащая прошивку:

Этот привод был лучше защищён:

  • прошивка хранилась в ПЗУ в зашифрованном виде
  • в прошивке был контроль целостности
  • для перезаписи прошивки, необходимо было входить в особый «Mode B»

И ежели с первыми 2-мя пт исследователи совладали сами, подвиг перевода в «Mode B» предстояло повторить всем прошивальщикам.

Действо это предлагалось выполнить с помощью специального загрузочного диска со Slax Linux, или закорачиванием проводов при старте. Закорачивать необходимо было контакты 0 и 9 коннектора питания привода. К примеру, булавками!

В обоих вариантах, опосля таковых измывательств, привод определялся в Windows как обыденный DVD-дисковод, где его подхватывали и прошивали.

Опосля первого релиза кастомные прошивки дорабатывались, повышалась стабильность, добавлялась поддержка новейших игр, в общем, всё как обычно.

Читайте также  Как восстановить то что удалил на андроиде. Восстановление удаленных файлов с телефона или планшета на Андроид

Ответ Microsoft

Создатели на обвинения, что «невзламываемую» консоль взломали, ответили просто:

Систему не взламывали, просто научились запускать копии игр, мы работаем над этим

оригинал ответа

The core security system has not been broken. However, it is reported that the authentication protocol between the optical disc drive and the console may be attacked, which if accurate could allow people to play illegally copied games. Our security team is aware of this and we are investigating potential solutions to this issue. The Xbox 360 platform was designed to be updated, and we are prepared to respond appropriately should any unauthorized activity be identified.

Что реально было изготовлено для исправления ситуации:

  • Samsung TS-H943 стали поставляться с прошивкой ms28, которая не входила в режим прошивки по известной ATA команде
  • Появились Hitachi GDR3120L с прошивками 0078 и 0079, не прошивающиеся даже в режиме Mode B
  • Появились новейшие приводы BenQ-LiteOn VAD6038
  • Начались 1-ые точечные «баны» пиратов в Xbox Live, пиратам запрещалось играться онлайн навсегда

Ежели с банами всё было однозначно и непоправимо (на тот момент времени), то с приводами исследователи в скором времени разобрались:

  • Для Hitachi отыскали разблокировку режима прошивки через особый аудио диск
  • Samsung ms28 и BenQ VAD6038 непревзойденно заходили в режим прошивки через дешевые SATA контроллеры VIA 6421

На время оставим поле битвы за прошивки привода, там был не очень увлекательный период, когда исследователи пробовали сделать «Stealth» прошивки, чтоб не забанили в Xbox Live, подстраивались под новейшие игры с новенькими «волнами» — версиями обновления системы и портировали результаты на всё расширяющееся обилие прошивок и приводов. Всё равно всё прошивалось, «бэкапы» удачно запускались, Xbox 360 набирала популярность у народа…

Ломаем ось!

Как вы помните из первой части повествования, в системе Xbox 360 был гипервизор, контролирующий всё и вся. Так вот. В одной из версий системы в нём нежданно возникла уязвимость! Как конкретно исследователи получили эталоны кода гипервизора мне доподлинно непонятно. Но факт – уже в конце 2006 г. исследователи запустили на Xbox 360 неподписанный код, а в начале 2007 уязвимость была устранена разработчиками:

Timeline:
Oct 31, 2006 — release of 4532 kernel, which is the first version containing the bug
Nov 16, 2006 — proof of concept completed; unsigned code running in hypervisor context
Nov 30, 2006 — release of 4548 kernel, bug still not fixed
Dec 15, 2006 — first attempt to contact vendor to report bug
Dec 30, 2006 — public demonstration
Jan 03, 2007 — vendor contact established, full details disclosed
Jan 09, 2007 — vendor releases patch
Feb 28, 2007 — full public release

Гипервизор имел одну изюминка – в отличие от остального кода, он исполнялся не в виртуальном адресном пространстве, а в физическом (Real Mode). Трансляция не использовалась, обращения велись впрямую (адреса вида 0x00000000’xxxxxx). То ли это было изготовлено для скорости, то ли для простоты… И тут крылась одна изюминка адресного места Xbox 360.

Режим доступа к памяти определялся по её физическому адресу. А конкретно — старшие биты адреса имели служебное назначение. К примеру, адресок 0x0000000’0000201C означал прямой доступ к адресу 0x201C, а 0x00000100’0000201C означал, что требуется «на лету» расшифровать и проверить целостность при чтении того же самого физического адреса 0x201C.

Соответственно, чтоб выполнение велось с включёнными шифрованием и защитой, необходимо обращаться к адресам вида 0x00000100’xxxxxxxx. Лишь тогда аппаратный модуль включал защитные механизмы. Потому на аппаратном уровне подходящий бит добавлялся автоматом (за это отвечал особый регистр HRMOR – Hypervisor Real Mode Offset Register)!

Ещё раз – как лишь гипервизор обращается к адресу вида 0x0000000’xxxxxxxx, MMU автоматом меняет этот адресок на 0x00000100’xxxxxxxx, включая шифрование и защиту! Так что любые пробы исполнить код «напрямик» из физической памяти, без защиты и шифрования, обречены на неудачу … либо нет?

Давайте поглядим на уязвимый код гипервизора версии 4532:

Видите суслика? А он есть! Аннотация cmplwi работает с 32-битными значениями, а вот rldicr – с 64-битными! То есть мы можем подать в качестве номера системного вызова значение 0x20000000’0000002A, оно пройдёт проверку (потому что младшая 32-битная часть меньше 0x61), и в итоге заместо адреса 0x10EC, адресок обработчика будет браться из 0x80000000’000010EC!

А далее, как говорится, смотрите за руками. Старшие биты адреса не равны нулю, соответственно, HRMOR не добавляется! А так как реальное адресное место 32-битное, выставленный нами 63 бит просто игнорируется. Мы перенаправили гипервизор в незашифрованную и незащищённую память, просто подав неправильный номер системного вызова!

Но подождите, чтоб было куда прыгать, нам необходимо уметь записывать в физическую память свои данные. Как этого достичь?

Читайте также  Почему компьютер не подключается к вай фай. Что делать, если ПК видит Wi-Fi, но не подключается

Тут в дело вступает 2-ой фактор – GPU в Xbox 360 был умным, даже чересчур умным. Он поддерживал специальную шейдерную аннотацию «MemExport» для выгрузки данных геометрии в физическую память. То есть вы могли скомпилировать шейдер, исполнить его на GPU и тем самым записать что угодно куда угодно! И самое основное, что шейдеры не были подписаны, ежели вы любым образом модифицируете диск с игрой, то просто можете подменить код шейдера.

Оставался один вопросец. Как подменить код шейдера на диске с игрой? И вот тут чрезвычайно понадобился взлом DVD привода приставки. Написали шейдер, подменили в виде игры, записали на болванку и запустили Linux!

Да, для пуска приходилось каждый раз запускать игру, дожидаться срабатывания эксплойта, ставить загрузочный диск с Linux, но это уже было хоть что-то!

Как уже говорилось, Microsoft выпустили обновление системы, в котором поправили уязвимость гипервизора. Но что, ежели вернуть уязвимое ядро?

Даунгрейд!

Вообщем, в архитектуру Xbox 360 были заложены механизмы защиты от даунгдейда. В аппаратных фьюзах процессора каждый раз при обновлении выжигался очередной бит (повышался Lock Down Value, LDV), и при несоответствии этого самого LDV в фьюзах и в системе, консоль просто не запускалась.

Разглядим структуру загрузчиков Xbox 360, а конкретно «Bootloader Sections»:

Видно, что в виде есть несколько наборов загрузчиков, каждому из которых соответствует какой-либо LDV. В примере это 1888 для LDV 0, 16767 для LDV 3 и 16756 для LDV 2

Так вот, все обновления самой системы записывались в секции 6BL/7BL и просто «накладывались» в виде патчей на базисное «ядро» 5BL 1888. А вот какой набор патчей применить, выбиралось согласно прописанному LDV в фьюзах и заголовкам загрузчика! И как раз у 5BL заголовок можно было модифицировать, с одним огромным НО — корректность заголовка проверялась по HMAC-SHA-1 хеш-сумме, записанной в нём же. И проверялась она обыденным memcmp.

Ежели вы ещё не сообразили, куда идёт дело, тут умудрились применить атаку по времени (Timing Attack). Обычная функция memcmp завершает сопоставление сходу опосля первого расхождения. Потому изменяя 1-ый б хеша и засекая время выполнения memcmp, можно подобрать необходимое значение (с ним время проверки увеличится). Продолжая дальше, можно подобрать все байты хеш-суммы!

Для замера употребляли отладочную шину POST_OUT. Работает она приблизительно как на ПК, в различные моменты загрузки выводится однобайтное значение, по которому можно судить, где на данный момент исполняется процессор и какая ошибка произошла. По сущности это 8 точек на матплате, любая из которых отвечает за определенный бит значения:

Подпаявшись к сиим точкам, можно как раз-таки замерять время выполнения каждого из шагов загрузки и глядеть, произошла ли ошибка.

Весь процесс подбора хеша занимает около часа:

В итоге получаем образ, в котором для базисного ядра установлен текущий LDV, из-за чего же никакие патчи не используются и запускается самая старая версия системы 1888! Откуда уже можно обновиться на уязвимую версию 4532:

Естественно же, Microsoft поправили эту уязвимость обновлением самого первого обновляемого загрузчика (2BL, «CB») и прожигом фьюза CBLDV, что сделало даунгрейд неосуществимым опять. Сейчас заместо memcmp использовалась его безопасная версия, с схожим временем выполнения независимо от входных значений.

JTAG Hack!

Но и тут исследователи не сдались и отыскали лазейку. Да такую, что создатели и представить не могли.

В обыкновенном режиме работы приставки, все загрузчики соединены друг с другом по цепочке. В итоге что расшифровка каждого загрузчика зависит от области данных в заголовке предшествующего загрузчика (Pairing Data). Дополнительно, шифрование кода зависит от неповторимого ключа процессора, потому нельзя взять и собрать рабочий образ, не зная CPU_Key. Либо можно?

На шаге производства консоли (когда ключ процессора ещё не прожжён во фьюзах) употребляется особый режим пуска Xbox 360, когда Pairing Data равна нулю (Zero-Pairing). И вот таковой образ (с уязвимым ядром!) можно запустить на хоть какой приставке, даже не зная ключа процессора!
К огорчению, настоящего пуска не будет, получится вот таковая ошибка:

То есть игру King Kong не запустить, эксплойт через шейдеры не активировать… Но уязвимое ядро-то уже запускается! Может, есть иной метод записать оперативку? Оказалось, что есть.

Для начала, припаиваем три вольных GPIO южного моста приставки к выводам JTAG графического процессора:

Потом модифицируем прошивку южного моста (она зашифрована, но не подписана) и собираем образ с уязвимым ядром. Опосля что происходит магия:

  • При запуске, южный мост по GPU JTAG лезет на PCI Express и настраивает контроллер NAND
  • Теперь контроллер NAND при чтении будет…

Оставьте комментарий