Вы думаете это невозможно?
Вы думаете, хак возможен на тех старых джтаг консолях?
GliGli & Tiro скажут вам обратное! Они разработали хак, который работает на всех последних кернелах следующих плат:
ZEPHYR, JASPER .......ииии...... TRINITY (aka SLIM!)
(не важно на каком дашборде!!!)
The Xbox 360 reset glitch хак
Некоторые факты:
tmbinc сказал лично, софтверные попытки запуска неподписанного кода на 360 в большинстве случаев неработает, она разработана таким образом что защита блокирует их.
Процессор стартует исполнение кода с ROM (1bl), который потом загружает подписанный RSA и закриптованный RC4 кусок кода из нанда (CB).
СВ затем инициализирует секьюрити движок процессора, его заданием будет шифрование в режиме реального времени и хеш-проверка физической DRAM памяти.
шифрование и сильное хеширование. Шифр разный с каждой загрузкой , потому что в него добавляется соль по минимуму из этих мест:
- Хеш фьюзов.
- Значение встроенного счетчика
- Полностью рандомное значение идет из железного генератора случайных чисел, встроенного в процессор! На толстых версиях этот генератор мог быть софтово отключен, но у нас новя проблема - проверка
рандомности. (считает до 1 бита в СВ), и ждем реально рандомное число.
СВ может выполнять некое подобие програмного движка , основанного на байт-коде, чьим заданием будет инициализация DRAM, СВ может загрузить слудующий загрузчик (CD) из нанда в него и запустить его.
Стандартно CD будет загружать основное ядро из нанда ,патчить его и запускать.
Ядро содержить маленький , привилегированный кусочек кода (гипервизор), когда консоль стартует - это единственный код у которого будет достаточно привилегий для выполнения неподписанного кода.
В версиях ядра 4532/4548, критическая уязвимость в этом месте и все известные нам методы взлома, опираются на эти ядра для запуска неподписанного кода.
На сегодняшних 360, CD содержит хеш этих 2х ядер и перестает выполнять процесс загрузки при попытке их выполнения.
Гипервизор относительно маленький кусок кода , но проверяет - используете ли Вы эти уязвимости или нет и удостоверяется что Вы несможете!
С другой стороны, tmbinc сказал, что 360 небыла разработана с защитой от некоторых видов ЖЕЛЕЗНЫХ атак и "глюков"
Глюками сдесь будем называть исполнение процессорных багов в электронных нуждах.
Этим путем мы пойдем для выполенения неподписанного кода.
Несколько слов о ресетном глюке
===============================
На толстых консолях, загрузчик имел глюк в CB , и мы могли делать с CD , что хотели.
cjak нашел это путем подачи CPU_PLL_BYPASS сигнала, частота ЦПУ понижалась намного, есть тестовый пин на материнке, который показывает сскорость ЦПУ, 200 МГц при старте даша, 66,6 Мгц при
старте загрузчика, и 520КГц при подачи сигнала.
Итак мы пошли таким путем:
- Мы подали CPU_PLL_BYPASS сигнал перед пост кодом 36 (hex).
- Мы подождали старта POST 39 (POST 39 это сравнение памяти между внутренним хешем и хешем образа), и запустили счетчик.
- Когда тот счетчик достигает точного значения (обычно около 62% длины POST 39), посылаем 100нс импульс на CPU_RESET.
- Мы ждем некоторое время и снимаем CPU_PLL_BYPASS сигнал.
- Скорость ЦПУ возвращается в норму, и с небольшим бонусом - вместо получения ошибки POST error AD, процесс продолжается и СВ загружает наш кастомный CD.
Нанд содержит пару zero-paired CB, нашу прошивку в кастомном CD и модифицированный SMC образ.
Глюк в нормальных условиях неповторить - мы испрользуем модифицированный SMC образ, который перезагружается постоянно (стоквый образ перезагружает 5 раз и дает РРОД), после консоль загружается как
положенно, в большинстве случаев глюк успешен в течении 30 секунд от запуска до конца.
Детали хака слим версии
=================
Загрузчик , который мы гличили - CB_A, и мы можем запустить CB_B, как хотим.
В слимках мы несмогли найти пин на материнке для отслеживания CPU_PLL_BYPASS.
Нашей первой идеей было удаление 27Мгц мастер-резонатора, и генерация нужных нам чатот, но это оказалось технологически сложно и мы отошли от этой идеи.
Затем мы стали искать другие пути для снижения частоты ЦПУ и обратили внимание на то, что HANA чип имеет настраиваемые PLL регистры для частоты 100 Мгц, которые ведут за собой ЦПУ и ГПУ и другие детали.
Эти регистры записываются в SMC по шине i2c.
Доступ к i2c неограничен, даже есть пин на материнке (J2C3).
Итак HANA чип стал нашим оружием замедленияя ЦПУ.
Итак, как - же это пашет?
- Мы посылаем i2c комманду HANA чипу для замедления ЦПУ на POST коде D8.
- Мы ждем старта POST DA (POST DA это сравнение памяти между внутренним хешем и хешем образа), запускаем счетчик.
- Когда счетчик достигает точного значения, посылаем 20нс сигнал на CPU_RESET.
- Ждем некоторое время и посылаем i2c комманду на HANA чип для восстановления скорости ЦПУ.
- Скорость ЦПУ восстанавливается и опять удача - вместо получение ошибки POST F2, процесс загрузки продолжается и CB_A грузит наш кастомный CB_B.
Когда CB_B стартует, DRAM не инициализируется, нам только нужно применить несколько патчей для запуска любого CD, патчи:
- Все время деактивируем режим zеro-paired, итак мы можем юзать патченный SMC.
- Не декриптуем CD, вместо планируемого плейнтекста CD в нанде.
- Не прекращаем процесс загрузки если хеш CD нехорош.
CB_B это закриптованный RC4, ключ идет из ЦПУ ключа, и какже мы можем пропатчить CB_B без знания ЦПУ ключа???
Обычный RC4:
закриптованный = плейнтекст xor псевдо-рандомный-ключпоток
Итак - если мы знаем плейнтекст и закриптованную часть - мы получим ключпоток, и с ним мы можем криптовать наш код!
Выглядит так:
угаданное-псевдорандомное-значение = закриптованное xor плейнтекст
новое-шифрованное = угаданное-псевдорандомное-значение xor плейнтекст-патч
Думаете это проблема что первее курица или яйцо? Как мы получим плейнтекст??
У нас есть плейнтекст из CB толстых консолей и мы заменив пару байт получили плейн такойже как и в CB_B, и мы можем закриптовать маленький кусочек кода для дампа ЦПУ ключа и декриптовать CB_B!!!
Нанд содержит CB_A, патченный CB_B, нашу полезную нагрузку в кастомном CD плейнтексте, и модифицированный SMC.
SMC модифицирован для бесконечной перезагрузки, и предотвращения посылки i2c , пока мы шлем наши.
И ТЕПЕРЬ ВЫ ПОНЯЛИ, ЧТО CB_A НЕ СОДЕРЖИТ ПРОВЕРОК В ФЬЮЗАХ! И ЭТО НЕПРОПАТЧИВАЕМЫЙ ХАК!!!!
Подводные камни
===============
Не все еще идеально:
- Последовательность глюков, которую мы проверили (25% успеха на попытку). Может занят пару минут на загрузку.
- Эта последовательность похоже идет изза какогото хеша модифицированного загрузчика (CD для тослстых и CD_B для слимок).
- Требуется хорошее железо для посылок ресет сигналов.
Текущее состояние дел
================
Мы использовали плату Xilinx CoolRunner II CPLD (xc2c64a), потомучто быстрая, точная, обновляемая, дешевая и может работать на 2х разных логических напряжениях одновременно.
Использовали 48 Мгц частоту дежурного режима из 360 глюкометра (прим. переводчика). Для хака слима счетчик запускается на 96 Мгц.
CPID код записан в VHDL.
Нужно отслеживать ПОСТ коды , мы использовали пост - пины , мы сейчас можем отслеживать пост через 1 пост бит , это снижает колличество проводов!
В ролях
======
GliGli, Tiros: Реверс инжинеринг и разработка хака.
cOz: Реверс инжинеринг, бета тестинг.
Razkar, tuxuser: бета тестинг.
cjak, Redline99, SeventhSon, tmbinc, и все, кого забыл... : Основной реверс инжинеринг и хаки 360.
XEO: с душею превел для вас этот фак по работе данного хака, всегда готов рассказать вам, как он работает
Ну, что тут сказать, лицензионщики на 360 официально СОСНУЛИ! 
Понимаю ещё пс3, где есть стимул не пейрадить онлайновые игры, так как прошивки с онлайном нет и всё такое, но ведь уязвимость слимок 360 так и провоцирует русских богатырей взламывать их юниты. И никто в этом не виноват, кроме тех лошков, что занимались дизайном слима... 
