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



    В 2011 году, через 6 лет после выпуска игровой приставки Xbox 360, исследователями был обнаружен занимательный факт — если на вывод RESET центрального процессора на очень короткое время подать сигнал «0», процессор не сбросит своё состояние (как должно быть), но вместо этого изменит своё поведение! На основе этой «особенности» был разработан Reset Glitch Hack (RGH), с помощью которого удалось полностью скомпрометировать защиту Xbox 360, запустить неподписанный код, тем самым открыв путь к взлому самой системы и победе над «невзламываемыми» приводами DG-16D5S.

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

    Что вообще за глич атака?

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

    Действительно, компилируя код
    i = i + 2;
    вы полагаетесь на то, что значение переменной i увеличится ровно на 2, даже не представляя себе, как может быть иначе.

    Глич-атаки нарушают эту уверенность — их цель направлена на то, чтобы процессор «сглючил» и повёл себя не так, как надо. Способов «глюкнуть» процессор несколько, например:

    • Просадить напряжение питания ЦПУ
    • Дать лишний импульс в опорную частоту ЦПУ
    • «Посветить» на проц радиацией

    Есть специальные устройства для проведения подобных атак — например, ChipWhisperer предлагает широкий ассортимент атак по частоте и питанию:



    В случае же с Xbox 360, «глюк» происходит в результате воздействия на линию RESET. Процессор начинает процедуру сброса, но из-за очень краткой длительности сигнала, не успевает её завершить и продолжает работать как ни в чём ни бывало. Но именно на этот краткий миг, пока сигнал RESET активен, его поведение изменяется!

    Глючим процессор

    Защита Xbox 360 держится на том, что загрузчики проверяют друг друга по цепочке. В конечном итоге, проверка на каждом этапе сводится к вызову функции сравнения хеш-суммы с «образцом». Тут-то и применили глич-атаку, заставив процессор проигнорировать несовпадение. Импульс на линию RESET сразу после вызова процедуры memcmp заставляет процессор «пойти» по другой ветке и продолжить загрузку, даже если хеш-сумма неверна:


    Наилучшее место для атаки нашлось в загрузчике второго этапа, «CB». Более поздние этапы атаковать сложнее (да и легко пофиксят), а на первом этапе загрузки («1BL», ROM) из-за несколько иного построения программного кода атака не удалась.

    Звучит просто, но на деле при попытке осуществить атаку, обнаружилось множество нюансов.

    Для начала, чтобы успешно провести глич-атаку, необходимо очень точно определить момент времени, когда следует подавать RESET импульс. Если ошибиться хотя бы на микросекунду, послать слишком короткий или длинный импульс, атака не срабатывает.

    К счастью, в Xbox 360 каждый этап загрузки сопровождается изменением значения на отладочной шине POST_OUT. Более того, отладочный вывод настолько часто расставлен, что новое значение POST задаётся сразу перед сравнением хеш-суммы:


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


    Также выяснилось, что из-за высокой частоты работы процессора, почти невозможно попасть в нужный момент по точности и длительности. Время воздействия должно быть очень мало, порядка времени исполнения одной инструкции процессором. Но чем медленнее работает процессор, тем больший временной промежуток нас устраивает. Поэтому берём и замедляем процессор!

    На обычном ПК частота CPU определяется как произведение внешней, «опорной» частоты и множителя:


    Так и в Xbox 360, к процессору подходят внешние линии опорной частоты, а внутри эта частота умножается с помощью PLL. И на старых, «толстых» ревизиях приставки механизм PLL можно было отключить, замедлив процессор аж в 128 раз:


    На «Slim» версиях трюк с PLL провернуть нельзя (линия не разведена на плате), и раз на множитель в «Slim» мы повлиять не можем, то уменьшим «опорную» частоту!

    Она генерируется чипом HANA, и его можно конфигурировать по шине I2C:


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

    Всё? Нет, не всё. Далеко не факт, что атака сработает с первого раза (особенно на Slim). А при неудачном запуске, приставка перезагружается и пробует запуститься снова. На запуск даётся всего 5 попыток, после чего приставка останавливается и начинает моргать «красным кольцом смерти». Поэтому патчим ещё и прошивку южного моста (SMC), чтобы не страдала фигнёй и перезагружала приставку до посинения:


    Итак, получаем алгоритм:

    1. патчим SMC
    2. замедляем проц (через PLL или I2C)
    3. ждём триггера POST
    4. ждём N микросекунд
    5. шлём импульс на RESET
    6. ускоряем проц обратно

    Для большей точности подсчётов, частоту берём с того же HANA (48 МГц):


    И получаем вот такую конструкцию на базе недорогого CPLD Xilinx XC2C64A:


    Не забудем пошаманить с длиной и расположением проводка на RESET (обратите внимание на «катушку» снизу фото) и вперёд, надеяться, что запуск получится в течение минуты.

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

    Патчим загрузчики


    Как я уже упоминал, атакуется загрузчик второго уровня, «CB». Этот загрузчик шифруется фиксированным ключом, одинаковым для всех приставок, но как раз «CB» модифицировать нельзя, его мы только атакуем. А вот следующий за ним уже зашифрован ключом CPU, уникальным для каждой приставки. И чтобы его модифицировать, нужно знать этот ключ…
    Или нет?

    В старых «толстых» ревизиях Xbox 360 в загрузчике «CB» поддерживался так называемый «Zero-Pairing» режим, использующийся на этапе производства приставки. В заголовке каждого загрузчика по смещению 0x10 находится случайный набор данных «Pairing Data», используемый как часть ключа при расшифровывании. И если этот набор данных состоял целиком из нулей («Zero-Pairing»), то ключ процессора игнорировался и вместо него использовался фиксированный, нулевой ключ!


    С помощью этого трюка можно было собрать образ с оригинальным «CB», зашифровать нулевым ключом следующий загрузчик, «CD» (уже со своим кодом) и запустить его с помощью RGH!


    В приставках «Slim» и этот трюк завернули, убрав «Zero-Pairing» режим и поделив «CB» на две части. Здесь «CB» делился на очень простой и небольшой «CB_A» и шифрованный ключом процессора «CB_B»:


    Но шифрование алгоритмом RC4 (а именно этим алгоритмом зашифрован «CB_B»), имеет одну особенность. В процессе шифрования на основе ключа генерируется псевдослучайный поток данных, который бинарно «складывается» (операция 'исключающее или', 'xor') с исходными данными. При расшифровывании, соответственно, происходит то же самое, сложение с этим же псевдослучайным потоком возвращает данные в исходное значение:


    Но операция бинарного сложения коммутативна и ассоциативна, что означает, что мы можем модифицировать зашифрованные данные, не зная ключа, просто заxor'ив зашифрованный код с нужным нам патчем!


    В итоге, мы можем зашифровать «CB_A», пропатчить зашифрованный «CB_B» (чтобы он не выполнял расшифровку вообще) и положить в открытом виде «CD» со своим кодом!


    Короче, если собрать воедино, то запуск выглядит как-то так:
    (XeLL — загрузчик хоумбрю, линукса, а ещё он ключи CPU показывает)


    Microsoft наносит ответный удар


    Конечно, Microsoft постарались всё залатать.

    В новом системном обновлении все старые приставки перевели на «раздельную» загрузку с «CB_A» и «CB_B», тем самым окончательно закрыв «Zero-Paired» режим. На «Slim» загрузчики тоже подверглись обновлению. Новые загрузчики серьёзно доработали для защиты от RGH, наибольший упор при этом был сделан на защиту «CB_A»:

    • Полностью убрали отладочный вывод в POST
    • Проверку хеш-суммы переделали и продублировали для надёжности
    • По всему коду расставили sleep() на случайное время (зависящее от ключа CPU!!)
    • Добавили проверку фьюза CBLDV для возможности отзыва «CB_A»


    Список нововведений не оставляет ни одного шанса для RGH. Но обратим внимание на последний пункт списка — до этого в «CB_A» не было проверки фьюзов! Фатальный недостаток. Более того, как мы помним, в расшифровке «CB_A» ключ процессора не участвует. А это значит, что уязвимый к RGH загрузчик «CB_A» можно запустить на любой приставке, и запретить это нельзя.

    А вот чтобы что-то запустить с помощью этого уязвимого «CB_A», нужно несколько извернуться. Если мы не знаем ключа CPU, всё, что нам остаётся — патчить существующий «CB_B». Но что, если вместо модификации единичных участков, мы заXOR’им весь загрузчик целиком? И за счёт этого «запишем» старый загрузчик, который мы уже умеем патчить, на место нового? Так и поступили:

    1. Шифруем уязвимый «CB_A» точно так же, как в исходном образе
    2. XOR’им наш «CB_B» с новым, получая «разницу»
    3. Накладываем её на шифрованный «CB_B»!


    Всё, мы снова, не зная ключа, успешно подменили шифрованное содержимое, ещё и уязвимый загрузчик засунули. Приставки взламываются, Microsoft удивляются.

    Разработчики напряглись, и в очередном системном обновлении … чуть изменили метод шифрования «CB_B», теперь ключ шифрования стал зависеть ещё и от версии «CB_A»:


    Теперь при попытке заxor’ить и подсунуть данные уязвимому «CB_A» старой версии, загрузчик расшифровывал мусор из-за различий в ключах. А новый загрузчик взломать нельзя, он хорошо защищён от глич атак. Пока что победа за Microsoft!

    Проблем подкинула Corona

    Тем временем, на рынок вышла новая ревизия Xbox 360 — Corona, и принесла она моддерам проблем:


    Маловато чипов на плате, не находите? Всё верно, чип HANA «спрятали» в южный мост. Больше неоткуда брать частоту 48 MHz для мод-чипа, прежние команды замедления по I2C не срабатывают. Да что уж там, NAND-флеш на 16 MB, все эти годы служившую в качестве системного хранилища Xbox 360, вероломно заменили на 4 GB чип с интерфейсом eMMC! (правда, только в более дешёвой версии приставки, но всё же):


    Но ничего, со всем справились. Придумали как читать/писать флеш-память через картридер:


    Нашли новые I2C команды замедления, внешний 48 MHz кварцевый генератор заменил HANA:


    Доделали скрипты для сборки, добавили поддержку 4 GB NAND…


    Но Microsoft продолжали вставлять палки в колёса. Например, на новых платах пропали некоторые резисторы, без которых мод-чип переставал работать:


    Правда, исправлялось это установкой перемычек паяльником:


    Серьёзнее дела пошли, когда с платы пропали дорожки POST_OUT:


    Но и здесь Microsoft не повезло, нужные для RGH «шары» CPU находились на крайнем ряду:


    И, естественно, к ним смогли подключиться. Сначала самые рукастые, чуть подсверлив край процессора и подпаявшись проводком прямо к шарику:



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


    Последний рубеж


    После того, как одолели «корону», осталась одна проблема — новые версии системы так и не поддавались взлому. Чтобы запустить RGH, нужно знать ключ CPU, а чтобы узнать ключ CPU, нужно хотя бы раз запустить RGH. Проблема курицы и яйца, в общем.

    И тут возникла мысль — а давайте не только проверку подлинности «глюкнем», но и расшифровку пропустим! Если получится, то нам не нужно знать ключа, положим «CB_B» в открытом виде, да и всё. Именно эта идея легла в основу Double Glitch Hack (DGX):


    Этот чип «глючил» проц дважды, первым импульсом пропускался этап расшифровки загрузчика, а уже второй импульс пропускал проверку подлинности. Работало куда менее стабильно, благо требовался хотя бы один успешный запуск — дальше получаем ключ CPU и действуем по-старинке.

    Актуален DGX был недолго, спустя 3 месяца китайцы вбросили релиз «DGX R.I.P» с образами, которые запускались на любых приставках, работали со стандартным RGH и, естественно, запускались куда стабильнее:


    Эти образы содержали специальную версию загрузчика «CB_A», используемую на производстве Xbox 360 и, по сути, являющуюся полным аналогом старого доброго «Zero-Pairing» режима. Вместо ключа процессора, этот «CB_A_mfg» расшифровывал «CB_B» фиксированным нулевым ключом:


    И вот здесь Microsoft всё. В этом «сервисном» варианте «CB_A» тоже не было проверки фьюз и забанить его было невозможно. Достаточно было записать образ согласно ревизии Xbox 360, припаять чип — и всё работало.


    Winchester!


    Полностью пофиксили RGH только в новой ревизии приставки под кодовым именем Winchester. Впервые процессоры CPU и GPU совместили в одном кристалле, плату максимально упростили:


    Дорожки POST_OUT не просто убрали. Даже если подпаяться на площадки под процессором:



    И даже, если запаять процессор на специальную версию платы для разработчиков, XDK, где эти дорожки всё ещё есть:


    На POST_OUT виден только один импульс при запуске приставки. Шина заблокирована:


    Более того, она блокируется только на этапе производства. Если взять «чистый» процессор с фабрики, где ещё не успели прожечь фьюзы — на нём POST_OUT работает!


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

    Post Scriptum


    Выходит, последнюю ревизию Xbox 360 взломать невозможно?

    И да, и нет. На данный момент известен только один способ запустить модифицированную систему на ревизии Winchester.

    В наборе ПО для разработчиков (XDK) есть различные приватные ключи для подписи скомпилированного кода. И так вышло, что среди них затесался ключ подписи «shadowboot», загрузчика третьего уровня для XDK систем. И с его помощью можно собрать легитимный подписанный образ с модифицированной прошивкой. Вот только работать на обычных, «магазинных» приставках он не будет. Нужен процессор с XDK версии приставки, либо «чистый» CPU с непрожжёными фьюзами (можно было встретить на Aliexpress):


    И только тогда у вас будет возможность лицезреть в «сведениях о системе» кастомной оболочки такую вот надпись:


    А на этом всё! Как обычно, готов ответить на ваши вопросы в комментариях :)

    Защита и взлом Xbox 360, Часть 1
    Защита и взлом Xbox 360, Часть 2
    Защита и взлом Xbox 360, Часть 3
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 62

      +5
      Собственно вопрос только, что стимулирует такие инженерные подвиги. Любопытство, принцип, деньги?
        +6
        Большинство подвигов совершается, в первую очередь, из интереса. Запустить линукс, написать свою программу на чужом железе. Понять, как оно работает. Часто ещё стимулом является получение прибыли — команда Team Xecuter неслабо заработала на продаже модчипов и аксессуаров.
        +8
        Спасибо за эту серию статей, написанных понятным языком. Получился самый настоящий технодетектив. Интересно, найдут ли подход к Winchester с прожжёными фьюзами или фокус тех, кто ищет лазейки в консолях, сместился к исследованию следующего поколения?
        Нет в планах написать подобное для прямого конкурента приставки — Playstation 3? Там история будет покороче благодаря получению хакерами ключей LV0, но тем не менее были и интересные моменты. Например, откладывание выпуска Gran Turismo 5 из-за взлома прошивки. И сама архитектура консоли довольно необычна.
          +4

          Проблема с Winchester в том, что эта ревизия появилась уже на закате Xbox 360, и выпущено было их не так много. Новые уязвимости искать нецелесообразно — кто хочет взломанную, найдет б/у Corona или даже Jasper.
          А про PS3 я не настолько много знаю, так что писать не планировал, но всё возможно.

            +2
            У Вас хорошо получается. Думаю про PS3 получиться не менее увлекательно.
              0
              Кстати, какой самый актуальный способ взлома Jasper обновленного на последнюю версию дашбоард на сегодняшний момент?
                +1
                RGH 1.2 на чипах Matrix или CR3 очень стабильно запускается (замедление PLL + загрузчики RGH2)
              +1
              Нет в планах написать подобное для прямого конкурента приставки — Playstation 3?

              В момент актуальности этих событий, тут в комментариях даже сам kmeaw иногда отписывался, правда про взлом практически ничего не раскрывал. Вот уж кто мог бы многое поведать.
              Хотя, про взлом Ps3 по-моему изначально больше информации было доступно, например есть вот такое: www.youtube.com/watch?v=DUGGJpn2_zY
              +10
              Платка для глитч-хака была моей первой покупкой на Али. Я купил БУ фатку на излёте жизненного цикла консоли как самый дешёвый способ поиграть в GTA V. Если не ошибаюсь, это была ревизия Falcon. У неё был уже прошит привод, но сам привод был стар и нестабилен, да и писать болванки в то время уже казалось муторным. И я решился на авантюру с глитчем, только FreeBoot меня устраивал. Паяльник я держать умел, поэтому было очень интересно провернуть всё самому.

              Довольно сложно оказалось найти точную информацию по процедуре для такой старой консоли. Многие источники в интернете потеряли картинки, другие были на французском или ещё каких-то странных языках, да и платы менялись, так что пришлось компилировать информацию. У меня всё получилось, хотя времени на подбор параметров для стабильного запуска я потратил изрядно. Сейчас оглядываюсь, и удивляюсь удаче. Процедура очень непростая, многостадийная, ненадёжная ни разу. Приставка и сейчас жива, я иногда играю, когда бываю у родителей.

              С тех пор я перестал быть мамкиным хакером, купил Xbox One S, и даже честно купил GTA V под неё. Так что, надеюсь, моя совесть очищена, зато интересный опыт остался.

              Огромное спасибо вам за этот цикл статей, было очень увлекательно. Поражает упорство и уровень мастерства инженеров, которые всё это изобретали.
                +2

                Я купил "корону" (да, в нынешнее время это уже странно звучит) в 2013-м, в "чёрную пятницу" на Амазоне, за смешные $199.99 (полный комплект, с кинектом). А потом уже возник вопрос, что с ней делать (очевидно — детям). Как раз исходя из того, что xbox 360 на тот момент уже достаточно давно был на рынке, а потому информации об особенностях, хаках и т.д. — полный интернет. Только вот обилие различных версий поиск этой самой информации немного усложнило.
                О да, это был реальный челлендж — раскопать нужное, подпаяться к флешке, состыковать это с кардридером на системнике, слить прошивку, слить ключи, пропатчить, купить и прошить платку гличхака (правильную платку — потому что их тоже уже пучок был разных на али). А потом подбирать длину провода, чтобы добиться наиболее стабильного запуска.
                Да, как пропатчить SMC я по итогу так и не разобрался, поэтому работает родной. Т.е. 5 попыток запуска, потом красное кольцо. Надо выключать и снова запускать. Но обычно хватает двух попыток.
                Получился очень классный лайтовый опыт (лайтовый — потому что я не разбирался в тонкостях сам, использовал готовый опыт). Хоть и пришлось попаять, но ровно столько, чтобы по шагам дойти до финиша и при этом не потерять интерес. Это примерно, как собирать лего-техник со схемой в два-три тома, или икеевскую мебель.

                  +10

                  Когда я купил Xbox 360 в 2008, информацию пришлось собирать настолько по крупицам, что забурился в это дело на десяток лет, что вылилось в мою сегодняшнюю профессию. Так что могу смело поблагодарить Xbox 360 за интересное времяпровождение

                +7
                Огромное спасибо за цикл статей!
                Доступно, познавательно, на интересную тематику и, самое главное: с обилием технических деталей и без утаивания самых интересных моментов (на зарубежных форумах хакеры до сих пор бывает жмутся все секреты взлома PS1 раскрывать, которой 30 лет уже, а здесь X360!).

                Сперва вот такой вопрос: после появления RGH было много сообщений, что этот взлом (в отличие от старого JTAG) очень быстро выводит из строя процессор: постоянные попытки его сглючить, мол, быстро приводят к деградации и отвалу/сгоранию. Действительно подобное имеет место, или это очередные страшилки из серии «приставка сажает кинескоп»?

                Ну и вопрос, который невозможно не задать: а XOne ковырять не пробовали?
                И почему, по вашему мнению, там всё совсем глухо? Абсолютно непробиваемая защита, хакеры нынче перевелись и/или их всех скупила/запугала Microsoft, или ломать просто неинтересно благодаря новой лояльной к homebrew политике компании, etc?
                  +4

                  Рад стараться :) Это я ещё часть информации не указываю, иначе уж слишком много всего получится.
                  Процессор действительно мог выйти из строя, но не от самого RGH, а из-за колдовства с PLL — встречал случаи, когда PLL отключался навсегда и процессор так и оставался в улиточном режиме. Случаев, когда процессор со временем ломался сам по себе от RGH2 — не знаю.
                  В Xbox One я не лазил, но по тому что знаю, в нём учли все описанные ошибки и он действительно очень надёжно защищён. Даже если кто взломает, очередным обновлением с большой вероятностью всё закроют. Отсюда у людей нет особого желания этим заниматься — полгода делаешь эксплоит, а он будет актуален неделю максимум.

                    0
                    Спасибо, ответ ещё интереснее!
                    Насколько я понял из статьи, с PLL возможно было колдовать только на старых ревизиях, где он позволял замедляться аж в 128 раз. И именно здесь оказалось слабое место?
                    А починить этот PLL как-то представлялось возможным, пусть перепайкой чипа, или вообще с концами?
                    И, в итоге получается, что парадоксально, но RGH безопаснее для новых консолей, где в PLL залезть нельзя?

                    В Xbox One я не лазил, но по тому что знаю, в нём учли все описанные ошибки и он действительно очень надёжно защищён

                    Ясно, наверное так и есть. Ведь если проанализировать, то X360 по факту получился защищеннее той же PS3 (про нинтедовские консоли, которые, как кажется, не ломает только ленивый, и не говорю). Да, он был взломан раньше, и казалось, что его вот «постоянно ломают», а PS3 неприступная. Но, весь взлом X360 был направлен именно на привод. Уязвимостей, которые позволяли запускать произвольный код, там было кот наплакал (JTAG, ну и RGH потом), и все они требовали сложной процедуры с раскурочиванием консоли и тонкой пайки. Для сравнения, у PS3 оказалась огромная программная дыра, позволяющая взломать ранние ревизии штатной установкой прошивки с флешки (только поначалу были донглы, также используемые без пайки, просто вставлявшиеся в USB).
                    Да и для любых моделей PS3 недавно был выпущен полный взлом HEN — опять чисто программный, через веб-эксплойт. И Сони не может закрыть его уже несколькими обновлениями прошивок (хотя, на сегодняшний день это для нее наверное уже и не особо актуально, пс3 давно мертва, но всё же) — там просто берут, и заменяют часть модулей в прошивке на старые версии, и всё опять взламывается.
                    Для X360 же никаких подобных «легких» программных взломов нет и скорее всего не предвидится — только пайка, только хардкор.
                    Единственное, когда на пс3 надо было что-то паять — это в период до HEN, когда ставили аппаратные эмуляторы BD-привода, по типу Cobra ODE.
                      0
                      Тот PLL, что ломался — он внутри процессора, так что только замена CPU. Получается, для самой приставки замедление с I2C безопаснее, зато с PLL запуск гораздо стабильнее. Старые приставки тоже можно замедлять через I2C (кроме Xenon, но там отдельный случай), это уже на выбор. Да и смертей от PLL всё равно очень мало, оно стоило того.
                      По поводу уязвимостей — весь взлом системы X360 начался с простого программного бага в гипервизоре, для запуска достаточно было игру одну запустить (см первую часть серии статей). JTAG Hack — тот же самый программный баг, но похитрее завёрнутый.
                        0
                        в свое время ps3 для downgrade на 3,55 надо было чуток попаять, особенно старые NAND версии ~ 40 проводков, в NOR поменьше, для NAND также требовалось склеить дамп и вычитать ключ на всякий случай. Далее уже патчился NAND и шился обратно, с него можно было откатиться на 3,55 а с 3,55 на любую другую прошивку =)
                        Для всего этого пришлось собрать teensy программатор с рассыпухи, влить в него фирмварь)
                        Щас как вспомню… проще было заплатить за прошивку мастеру чем так парится. Зато какой челендж, опыт :)
                          0
                          В том и дело, что ключевое слово «downgrade» — если по глупости/незнанию обновили прошивку выше заветной 3.55.
                          Но даже здесь, изначально прошиваемую приставку (заводская <3.55) всё равно можно было взломать после обновления ПО, пусть и с пайкой.
                          Для сравнения, X360 если обновить даш — всё, с концами, из-за фьюзов даунгрейд невозможен, и JTAG уже никогда на эту консоль не поставить.
                          Т.е. MS смог закрыть программную дырку апдейтом ПО даже на уязвимых консолях, на консоли от Sony — это невозможно, дыру закрыли только в новых аппаратных ревизиях приставки.
                          Потому и говорю, что у Майков на самом деле гораздо лучше вышла защита, привод разве что подвел.

                          И, кстати, для PS3 сейчас придумали и полностью программный даунгрейд, даже при обновлении на последнюю официальную прошивку — всё откатывается через эксплойт, паять ничего не надо.
                            0
                            Кстати для Xbox 360 тоже придумали, через глич пропускать проверку фьюзов и запускать тот самый JTAG хак (R-JTAG, R-JTAG+), но метод не получил большого распространения.
                              0
                              Друг отдал trinity c 4gb памятью вместо жесткого, после вашей статьи захотелось попробовать повозиться =)
                              вопрос чем читать\шить нанд?
                              переделать arduino,
                              найти комп с LPT,
                              другой JTAG пограмматор(например stlinkv2).
                              или есть другие варианты патча нанд?
                                0
                                Там SPI протокол. MTX SPI Flasher стоит 4 бакса, самый недорогой и поддерживаемый вариант. через nandpro читать/писать

                                SPI/JTAG адаптер на FT232H стоит 5 баксов, более полезная штука, софт от 360Squirt должен подойти

                                клоны JR Programmer чуть подороже, но и пошустрее будут. работает через JRunner
                                  0
                                  Я вот сморю и думаю ведь spi же, но у схем что я нашел — pinout для «mtx spi flasher»(tms tdi tdo tck gnd/vcc) т.е JTAG
                                  а для SPI(sck rst mosi miso gnd/vcc), у меня «ведро» разных spi программаторов и покупать еще один не хотелось бы, в любом случае можно попробовать через LPT или купить MTX накрайняк
                                  Вам спасибо за ответ, буду пробовать =)

                                    0

                                    MTX SPI Flasher народ умудряется для прошивки глич-платки XC2C64A использовать (она как раз по JTAG шьётся) — вы, наверное, эту схему нашли. Сам NAND Xbox 360 читается по SPI через южный мост. Наверняка можно что-то сварганить на Arduino или CH341A, но это возиться надо и кодить :) правда, не искал, может уже и появились готовые проекты для этого

                      +1
                      www.youtube.com/watch?v=U7VwtOrwceo

                      Все очень плохо/хорошо, смотря с какой стороны смотреть. Постарались они там на славу. Пс4 вон смогли нагнуть и все оказалось там не особо наворочено. К xbox one я даже не видел, чтобы кто-то подступился.
                      +2
                      где и как они это всё находят? ну с адресными шинами понятно, найти можно, но всё остальное? неужели методом тыка.
                        +6
                        Сам RGH — известный тип атак, просто попробовали на новом объекте (Xbox 360) и получилось. Всё остальное — долгое изучение системы и реверс-инжиниринг. При полном понимании как и что работает, становится видно, какие варианты есть и где слабое место
                          +1
                          а как они нашли метод со сверлением чипа в приводе двд? я сам несколько ключей так получил. до сих пор 360 коробка работает с эмулятором привода.
                            +1
                            Растворили чип кислотой, наметили точку, где проходит проводок Write Protect, написали софт, подающий команду разблокировки. Тут единственное, что сложно вообразить — что это в принципе возможно сделать и не сломать привод.
                            А насчет ваших ключей — очень странно, ключи читаются полностью программным методом, сверлить для установки эмулятора не требуется.
                              0
                              тогда, когда я сверлил, это был единственный метод получения ключей. сначала прошивку в приводе менял, а потом 360key, который до сих пор прекрасно работает.
                                0

                                Сверление требовалось для записи прошивки, это так. А вот ключ получался перед этим, программно. Более подробно про это описано во второй части.

                                  +1
                                  а. действительно. забылось уже по давности лет. файлики с ключами все еще рассованные переодически попадаются :-)
                                    0
                                    что интересно. повторная перепрошивка производилась просто намоченной водой ваткой, без сверла уже.
                            +3

                            Эх, где мои годы. Моя статьи по прошивкам на xboxland всё еще живы.


                            Помню как народ ждал возрождение железного взлома и как появился rgh.


                            Переводил статью автора взлома и сразу платы разводил под xilinx.

                              +1
                              Ого какие люди! А сейчас чем занимаешься?
                                +1

                                В телекоме себя нашел.

                              0
                              прекрасная серия статей, большое спасибо. все понятно и хорошим языком написано.
                                +1
                                tl;dr. помню взламывал дома. с иголкой сидел и тыкал в контакт на плате, получилось с первого раза, страшно было жесть )) ибо там (в старых мануалах) говорили что если выключиться питание коробка станет реальной
                                  +5
                                  Кстати, на заглавном фото — самопальный сокет для быстрой замены проца без пайки. Вот так выглядит в собранном состоянии
                                  image
                                    +1
                                    Наилучшее место для атаки нашлось в загрузчике второго этапа, «CB».
                                    Как именно "нашлось"? На первый взгляд для проведения атаки нужно иметь листинг загрузчика, что бы все проанализировать, посчитать такты и пробовать.
                                      +2
                                      Расшифрованные загрузчики получить несложно — нужна консоль с известным ключом (например, ранее полученным через JTAG Hack), обновлённая до последней версии. Дальше — мощный и быстрый микроконтроллер (или FPGA) для банального перебора таймингов. Перебираем все возможные моменты посылки импульса на определённом POST коде и все возможные длины импульса. Сработает — отлично, не сработает — пробуем другую идею. Парень полгода с этим возился.
                                        0
                                        JTAG Hack позволяет получить ключи и код загрузчика без знания устройства "черного ящика"?
                                          +2

                                          Нет, всё началось с эксплоита для гипервизора. Как был изначально получен код гипервизора не раскрывается. Полагаю, его получили из средств разработчика Xbox 360 (Xbox Development Kit, XDK), в этом наборе было много информации о приставке, даже символьная информация о внутренних функциях.

                                      0
                                      very very intresting :)
                                        +1
                                        Тот самый случай, когда Хабр — торт! Спасибо за заметку, на одном дыхании!
                                          +1
                                          Я сразу понял, что подобную статью мог написать только один человек (на твоем форуме у тебя был другой никнейм). До сих пор в моем запылившимся драндулете стоит x360ace с твоей прошивкой.
                                          Спасибо за статьи и за все, что сделал для комьюнити 360.
                                            0
                                            Спасибо за замечательную статью!
                                            У меня, что-то из отдаленного, вспомнилось — BenqSiemens E71, разблокировка иголкой какой-то ноги проца на массу, ельфы… было время)
                                              0
                                              «И все таки убийца — это дворецкий!»
                                              Большое спасибо, за заключительную часть этого технотриллера, с кровавыми чудесными расчленёнками подробностями!
                                                0
                                                А как работал DGX если там навтыкали слипов и убрали POST?

                                                В итоге, мы можем зашифровать «CB_A», пропатчить зашифрованный «CB_B» (чтобы он не выполнял расшифровку вообще) и положить в открытом виде «CD» со своим кодом!

                                                Вот это тоже не понятно.
                                                Если вы не знаете ключа, как можно «зашифровать CB_A»?
                                                Я так понял он не меняется? Или его тоже можно подменить?
                                                  +1
                                                  А как работал DGX если там навтыкали слипов и убрали POST?
                                                  Вместо нового «CB_A» записывали старый, уязвимый. + такой же старый CB_B в незашифрованном виде.

                                                  как можно «зашифровать CB_A»
                                                  Он шифруется фиксированным ключом, одинаковым для всех (1BL Key). Потому и можно его в любую приставку записать было. Проблема была запустить CB_B из этого CB_A, не зная уникального ключа CPU
                                                  0
                                                  обратите внимание на «катушку» снизу фото
                                                  Да там не только на конденсаторе намотано, а даже и на радиаторе…
                                                    0
                                                    А вообще каким образом люди изначально доходили, что вот нужно подать на ресет кратковременный сигнал в определенный момент? Ведь документации же нет?
                                                      +2

                                                      А документация такое не описывает, это глюк, недокументированное поведение, нарушение нормальной работы процессора. Изначально находили, пытаясь воздействовать на объект разными методами на грани адекватного — например, CLK-глич вносит сбой в частоту работы процессора, нарушается конвейер исполнения, происходит глюк. Просадка по питанию нарушает работу компараторов внутри проца, изменяя логические уровни. Так и с линией RESET — кто-то однажды подумал, а что, если жахнуть на него совсем короткий импульс — перезагрузится или нет? В документации, к примеру, говорится, что для сброса нужно занулить линию на 1мс. В таком случае зануление на 1мкс явно будет граничной ситуацией с неопределенным поведением. Вот и глюки

                                                        +2
                                                        В документации этого, конечно, нет. В статье есть упоминание откуда это всё берётся. Из опыта отладки. В документации описано, как система себя ведёт в нормальных условиях, и эти самые условия там тоже описаны. А вот при выходе за эти пределы она ведёт себя в общем случае неопределённо. С такими ситуациями инженеры сталкиваются при разработке. Питание просело, сигнал сброса оказался слишком коротким, уровень сигнала в неопределённой зоне между нулём и единицей — система глючит. Изучение этих глюков позволяет выяснить закономерности поведения. Обычно это нужно, чтобы отловить баг, но зная об этом можно попытаться делать это целенаправленно, чтобы баг создать. Опять же в статье даже есть фотка платы для подобных издевательств.
                                                          +1
                                                          Это стандартный и распространенный метод атаки для любого процессора, исполняющего код. Послать какой-нить сигнал в нужный момент, чтобы процессор перепрыгнул инструкцию или еще как изменил нормальное поведение. Залил ты свой образ прошивки, ресетнул в нужный момент проц, а он перепрыгнул проверку подписи и пошел дальше выполняться. И вот у тебя уже доступ к ключам и всему на свете. Можно банальным перебором искать нужный момент глитча. Вопрос конечно еще найти линию, которая подвержена этому.
                                                          0

                                                          В сообществе возникала мысль, что кто-то в Микрософт постоянно сливает информацию о внутреннем устройстве очередных плат?
                                                          И сколько всего разных плат получилось в итоге?

                                                            +1

                                                            А что именно, по предположениям сообщества, сливалось? На плате и так видно расположение компонентов. Сомневаюсь, что были сливы.
                                                            Мажорных ревизий 8:
                                                            Xenon, Zephyr, Opus, Falcon, Jasper, Trinity, Corona, Winchester
                                                            Но, к примеру, тех же Corona минимум 3 ревизии самой платы и 6 видов вообще.
                                                            А ещё для каждой ревизии есть XDK вариант для разработчиков.

                                                            +1
                                                            Отличный цикл статей, написано хорошо понятным языком, читается как художественное произведение.

                                                            Довольно необычно выглядит удаление POST шины с платы — просто удалили дорожки в PCB-редакторе, оставив переходные отверстия.

                                                            Году в 2013 ковырял свой Jasper Elite сам. Привод легко поддался iXtreme 3.0 (резистор 22 Ома), а вот FreeBoot не получился — аппаратно все модификации провел, мод-чип напаял и настроил, флешку через LPT-порт древнего компа аж за полтора часа прочитал, а вот прошивка, которую собрал и залил обратно, стартовать упорно отказывалась — по вращению кулеров было слышно, как чип постоянно и бесконечно перезагружает процессор. Убив два выходных, вернул всё в сток и всё снова заработало. Позже отнес в контору, где за 1 день и 3000 рублей всё сделали, ещё сказали, что очень удачная консоль попалась, всё легко получилось. Что я сделал не так — так и осталось загадкой, да и не вспомнить уже за давностью лет. Ну, за то другу в PS2 чип установил вслепую, и оно сразу заработало.

                                                            В общем, в итоге консоли перестали взламывать не потому, что это сложно, а потому, что игры стали выходить кривые и с 15FPS, что сделало обязательным подключение к интернету и регулярные обновления. А какие времена интересные были.
                                                              0
                                                              Интересно, в «чистый» проц случаем нельзя прошить свои ключи? Или вообще не прошивать или не активировать проверку подписей/шифрование? Чтоб можно было залить полностью свою ОС.
                                                                0

                                                                Можно свой ключ CPU зашить, можно самостоятельно фьюзы выставить как захочется, но проверку подписи в ROM отключить нельзя.
                                                                Свою ОС — можно и через RGH. Линукс, к примеру, запускается.

                                                                  0
                                                                  Ключ CPU — это который для шифрования? А ключ для проверки подписи тоже можно зашить? RGH — жуткий костыль же.
                                                                    +1
                                                                    Нет, ключ проверки подписи намертво зашит в ROM. А насчет костыля, см последний абзац, на нулевом CPU или XDK консоли можно подписать образ и запустить что угодно.
                                                                      0
                                                                      Т.е. в «чистом» проце уже есть какая-то прошивка, совсем не прошитых не бывает? Ключ проверки подписи отличается в релизной и девелоперской версии? Как это достигается — изначально зашито несколько ключей, затем часть блокируется фьюзами?
                                                                        +1
                                                                        Под «чистым» процом подразумевается, что его фьюзы ещё не прожжены (см фото в конце). Код первичного загрузчика 1BL находится в масочной памяти ROM. Масочная память вытравливается вместе с остальным чипом и не может быть перезаписана.
                                                                        Загрузчик второго уровня shadowboot (2BL SB), для которого имеются приватные ключи, при запуске проверяет конфигурацию фьюзов и если выставлен бит «Production», прекращает загрузку. Поэтому его запуск возможен только на XDK и нулевых CPU, где этот бит не стоит. Это если совсем по-простому.

                                                                        1BL проверяет 2BL через RSA-2048, дальше в релизной цепочке CB->CD->CE->CF->CG просто проверяют друг друга по хеш-суммам, кроме последнего этапа CF-CG, где тоже RSA-2048.
                                                                        А вот в дебажных SB->SC->SD… уже на ранних этапах RSA-2048, и для этапа SB->SC есть ключ.

                                                              Only users with full accounts can post comments. Log in, please.