Новый взлом Xbox 360 - Glitch Hack

Нужно переделать белую платку x360glitch из jaspera в slim.
Удалил все не нужные детали, но резюка C1B на джаспере нет, а на слим есть.
Нужен ли он на слиме, если да, то на сколько он?

 

Нужна помощь. Не могу сделать хелл нанд считал раз 5 проверил сходится, а вот хелл не делает вылетает такая ошибка.
Что делать ???

 

Привет товарищ по несчастью!
А ты то нафига обновился?
Это у тебя новый Dashboard 14719, в нем лазейку для XELL прикрыли.
Вот сборщик и не находит нужных параметров для сборки.
Ждем вместе пока новый даш взломают, а пока сидим на взломаных DVD приводах, спасибо c4eva
--- добавлено: Mar 3, 2012 7:55 AM ---
Следи за новостями на этом сайте
http://team-xecuter.com/team-xecuter-presents-rgh-2-0/

 

К сажелению я его такой купил. И с приводом проблемы DG-16D5S

 

Про прошивку для чипа никто не скажет ?
Пост 2978 первая половина.

 

У меня jasper!

Вопрос! по кондерам! Так поставили 2? Один 47nF PLL-GND - параллельно, а другой 680pF в ресет - в зазрыв (межжду точкой крепления на чипе и ппл) ???

Подскажите пожалуйста! а то хелл не стартует(

 

C той системой проблемка выявилась, иногда, редко но не стартовал. Сейчас 47нф плл-гнд, 100пф рст-гнд. В разрыв пихать оказывается ЗАПРЕЩЕНО! Недавно только эта инфа всплыла. Никаких кондеров в разрез ресета! Это опасно!

 

leihto, еще вопросик на разных схемах смотрел провод cpu -ppl -rst это же одно и то же почему ты пишешь про 2 кондера?

 

PLL и RST это разные провода. Вот на них и 2 кондера. Один вывод на точку, другой на землю

 

В общем, на старом даше (какой-то из 13ххх), и с белой платой глитча кселл так и не стартовал. В итоге глитч был успешно запорот, и заказан новый. Сейчас залил в бокс ориг. даш, обновил его до 14699, все норм, но в некоторых меню нет надписей, просто белые полоски. Уже настройки сбросил на заводские, все так же. В чем дело может быть?

 

Ребят, кто нибудь допиливал матрикс глитчер? Подскажите пожалуйста как это сделать.

 

добрый вечер . помогите пожалуйста с проблемой записали на диск игру вставили диск в приставку запросил установить обновление согласились и выдал ошибку (код состояния 3151-351F-B800-0F00-C000-0059) помогите плиз

 

кастян, ты не в ту тему стучишь. Скопируй обновление с диска на флешку и суй ее в консоль. А после ГО прошивать привод заного. Эта ошибка аналогична С000-0013 из этой статьи.

 

аналогично белым чипам. там легко понять что к чему

 

Да мне не понятно от куда мне брать 1.8 V и 1.1 V. И безопасно ли это, ведь от контакта VCC на точку где 1.1V, приходит порядка 3-х V. А катод диода 1N4148 куда припаивать на глитчере? Если не трудно, кто-нибудь сделайте подробную схемку, я думаю она многим пригодится в будущем.

 

На каждой плате есть стаб 1,8в, матрикс не исключение. Вот с него и подать на 15 ногу 1,8вольт, а на 7 через один диод 1,1в. Резистор 1ком удалить на пару с конденсатором.
--- добавлено: Mar 3, 2012 8:20 PM ---
И что опасного в VCC, с него на стаб идет 3,3в, а на выходе как раз 1,8

 

Теперь, кажется начинаю понимать. Резистор и кандей, это как я понимаю, которые стоят паралельно после трех диодов и соединяют линию VCC и GND? А три диода нужно менять или оставить?

 

Да там все эти 5 элементов в одной куче с краю, их удалить. Диод лучше взять нормальный выводной

 

есть,вопрос...ксенон..когда нибудь,можно будет ЗАГЛЮЧИТЬ?

 

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

***************************************
* The Xbox 360 reset glitch hack *
***************************************

Введение / некоторые важные факты
=================================
Лично Tmbinc сказал, что софтверные попытки запуска неподписанного кода на Xbox360 в большинстве случаев не удаются, т.к. приставка разработана таким образом, что защита блокирует их. (Прим. ЦПУ Xbox360 использует технологию eFuse и содержит ROM для хранения 1BL (First Boot Loader) и защитных ключей Microsoft, используемых для расшифровки данных. Кроме этого, в ROM хранится ключ процессора (CPU Key), которым проверяется перед запуском код второго загрузчика ("CB"), находящегося во флеш-памяти приставки. Так как ключ процессора находится внутри ROM (неперезаписываемой памяти), и только у Microsoft есть приватный ключ, то выполнить произвольный код во время нормальной загрузки невозможно.)
Процессор стартует исполнение кода из "1BL", который потом загружает из NANDа кусок кода, подписанный RSA и закриптованный RC4: "CB" (2-й загрузчик). "СВ" затем инициализирует движок безопасности процессора, задачей которого будет шифрование в режиме реального времени и хеш-проверка физической DRAM памяти.
Исходя из того, что мы обнаружили, он использует AES128 для шифрования и сильного хеширования (?ToeplitzHashFunction?). Шифр разный при каждой загрузке, так как он образуется по меньшей мере из:
- хэша фьюзов (Прим. фьюзами обычно называют "переключатели" внутренних параметров микроконтроллеров. У ЦПУ Xbox360 есть 12 фьюзов и они образуют фундамент безопасности гипервизора. Фьюзы расположены внутри процессора и, следовательно, их трудно изменить).
- значения встроенного счетчика времени
- полностью случайного значения, которое поступает от встроенного в процессор аппаратного генератора случайных чисел. (На FAT-версиях этот генератор мог быть электронно отключен, но в "CB" присутствует проверка "истинной случайности" (простой подсчет "1"-х бит), и он ждет реально рандомное число.
После этого "СВ" может запустить некое подобие несложного програмного движка, основанного на байт-коде, задачей которого будет инициализация DRAM, а затем "СВ" может загрузить из NANDа в DRAM следующий загрузчик ("CD") и запустить его. В сущности, "CD" будет загружать основное ядро из NANDа, патчить его и запускать.
Это ядро содержит маленький привилегированный кусочек кода (гипервизор), и когда консоль стартует - это единственный код у которого будет достаточно привилегий для выполнения неподписанного кода. В версиях ядра 4532/4548 была выявлена критическая уязвимость, и всем известным до этого методам взлома Xbox360 было необходимо запустить одно из этих ядрер и использовать эту уязвимость для запуска неподписанного кода. На сегодняшних Xbox360 "CD" содержит хеш этих 2-х ядер и остановит процесс загрузки, если вы попытаетесь загрузить их. Гипервизор - это относительно маленький кусок кода для проверки на присутствие уязвимостей в существующих и, предположительно, новых версиях ядер, которые могли бы позволить запуск неподписанного кода.
С другой стороны, Tmbinc сказал, что Xbox360 не была разработана противостоять некоторым видам аппаратных атак, таких как атака по времени и глитчинг (glitching - "глюченье"). Глитчингом здесь будем называть процесс запуска багов процессора электронными средствами. Этот подход мы будем использовать для выполенения неподписанного кода.
(Прим. Boot-up консоли - начиная от включения питания:
1. "1BL"(1й загрузчик, хранится в ROM процессора). Он загружает, расшифровывает и запускает пункт 2.
2. "CB" (2й загрузчик, хранится в NAND). Он загружает, расшифровывает и запускает пункт 3.
3. "CD" (хранится в NAND). Он загружает, расшифровывает и распаковывает "CE", в котором хранится базовое ядро и базовый гипервизор (HV). Он также загружает, расшифровывает и запускает пункт 4.
4. "CF" (хранится в NAND). Он загружает, расшифровывает и распаковывает "CG", который содержит исправления для ядра и HV. Затем он применяет патчи к HV и ядру, запускает исправленный HV, а потом исправленное ядро. После этого он запускает DashBoard.
Таким образом, в основном, процесс проходит так: 1й загрузчик -> 2й загрузчик -> патч для ядра и HV и их старт -> загрузка даша. При этом, конечно же, на каждом шаге производится проверка подписи для следующего шага.
Хранилище ключей (KeyVault) расшифровывается гипервизором, используя ключ процессора.
Всего во время загрузки используется 3 вида проверки:
- RSA подписи. "CB" и "CF" подписанны RSA подписями. Ломать бесполезно, в основном, потому, что используется асимметричное шифрование (у MS есть секретный ключ). Это не позволяет нам изменять сам загрузочный код.
- SHA1 хэш: "CD", "CE", "CG". Эти хеш-значения содержатся в подписанной RSA части предыдущих разделов и, поэтому, мы не можем взломать их (атака по времени также не применима). По существу, они могут рассматриваться как расширения RSA подписей в "CB" и "CF". Опять же это препятствует изменению нами самого загрузочного кода.
- SHA1-HMAC аутентификация. Она также реализована в "CB" и "CF" (но у вашего процессора есть ключ). Это не позволяет вам выбирать между выпущенными версиями загрузочных разделов / дашбордов и т.д. Однако она поддавалась атаке по времени.)

Несколько слов о глюке сброса (reset glitch)
==============================================
Мы обнаружили, что отправка очень кратковременного импульса сброса на центральный процессор, в то время как он замедлен, не сбрасывает его, а вместо этого изменяет способ исполнения кода и похоже, что это очень действенно приводит к тому, что функции MEMCMP загрузчика всегда возвращают "нет различий". MEMCMP часто применяется для проверки соответствия SHA хэша следующего загрузчика с хранящимся значением, позволяя запускать загрузчик если они совпадают. Поэтому мы можем записать в NAND загрузчик, который не пройдет проверку хэша, заглитчить предыдущий, и наш загрузик запустится, позволяя запускать практически любой код.

Детали хака фэт версии
======================
На толстых консолях загрузчик, который мы глитчим - "CB", поэтому мы можем запустить такой "CD", который захотим. cjak обнаружил, что при установке в активное состояние сигнала CPU_PLL_BYPASS, тактовая частота процессора значительно понижается. (Прим. PLL - фазовая автоподстройка частоты (ФАПЧ), используется для частотной модуляции и демодуляции, умножения и преобразования частоты и т.п. Сигнал CPU_PLL_BYPASS, предположительно, отключает умножитель частоты). На материнке есть тестовая точка, которая отражает долю тактовой частоты процессора, она 200МГц при старте даша, 66,6Мгц когда консоль загружается, и 520КГц когда подан сигнал (CPU_PLL_BYPASS).
Итак, все проходит следующим образом:
- Мы устанавливаем в активное состояние сигнал CPU_PLL_BYPASS приблизительно во время POST кода 0x36 (Прим. POST 0x36 это запуск этапа расшифровки "CD").
- Мы ждем старта POST 0x39 (POST 0x39 это MEMCMP между сохраненным хешем и хешем образа "CD"), и запускаем счетчик.
- Когда счетчик достигнет определённого значения (зачастую около 62% полной длительности POST 0x39), мы посылаем 100нс импульс на CPU_RESET.
- Мы ждем некоторое время и затем переводим сигнал CPU_PLL_BYPASS в пассивное состояние.
- Тактовая частота процессора возвращается в норму и, при некотором везении, вместо получения ошибки POST 0xAD (Прим. POST 0xAD это отказ при авторизации "CD"), процесс загрузки продолжается и "СВ" загружает наш самопальный (кастомный) "CD".
NAND содержит непривязанный (ZeroPaired) "CB" (Прим. ZeroPaired образ - это образ, в который не внедрен индивидуальный ключ процессора, а соответствующие участки образа заполнены нулями), нашу "полезную нагрузку" (payload) в кастомном "CD" (Прим. payload - обычно означает саму функциональную часть эксплоита, в отличие от той части кода, которая ее доставляет) и модифицированный SMC образ (Прим. SMC - System Management Controller является частью южного моста и всегда активен. В основном, отвечает за обработку и управление датчиками, таймером, вентиляторами и т.п., в том числе и за изначальный процесс запуска консоли). Глитч ненадежен по своей природе, и мы испрользуем модифицированный образ SMC, который перезагружает консоль неограниченное число раз (т.к. оригинальный образ перезагружает 5 раз и затем уходит в RROD), пока консоль не загрузится должным образом. (Прим. Red Ring Of Death - "Красное Кольцо Смерти" - является общим сигналом индикации аппаратного сбоя Xbox360). В большинстве случаев, этот метод глитча срабатывает менее чем за 30 секунд от момента запуска консоли.

Детали хака слим версии
=======================
Загрузчик, который мы глитчим - "CB_A", поэтому мы можем запустить такой "CB_B", который захотим. (Прим. в отличие от фэт-консолей, у слимок загрузчик "CB" состоит из двух частей - "CB_A" и "CB_B"). В слимках мы не смогли найти на материнке дорожку для CPU_PLL_BYPASS. Нашей первой идеей было удаление 27Мгц главного тактового генератора консоли и генерация нужной нам тактовой частоты вместо него, но это было сложной модификацией и не дало хороших результатов. Затем мы стали искать другие пути для снижения тактовой частоты процессора и обнаружили, что чип HANA (Прим. HANA отвечает за вывод видео - преобразует картинку в буфере в разные форматы: композитный, S-Video, RGB SCART, компонентный YUV, VGA и HDMI) имеет настраиваемые PLL регистры на частоту 100 Мгц, которая подается на дифференциальные пары центрального и графического процессоров (Прим. дифференциальные пары часто применяют для передачи высокоскоростных тактовых сигналов для большей временной точности и меньшей восприимчивости к электромагнитным помехам). По всей видимости, SMC записывает эти регистры (PLL) по шине I2C (Прим. I2C - последовательная шина данных для связи интегральных схем). К шине I2C можно легко получить доступ, она даже доступна на пробнике (J2C3). Значит, теперь чип HANA станет нашим предпочтительным орудием замедления процессора (прости, tmbinc, ты не можешь всегда быть правым, это довольно нескучно и он подвязан на интересную шину).
Итак, все проходит следующим образом:
- Мы посылаем I2C-комманду чипу HANA замедлить процессор на POST коде 0xD8.
- Мы ждем старта POST код 0xDA (POST 0xDA это MEMCMP между сохраненным хешем и хешем образа) и запускаем счетчик.
- Когда этот счетчик достигает точного значения, мы посылаем 20нс импульс на CPU_RESET.
- Мы ждем некоторое время и потом посылаем I2C-комманду чипу HANA восстановить нормальную тактовую частоту процессора.
- Тактовая частота процессора возвращается в норму и, при некотором везении, вместо получения ошибки POST 0xF2, процесс загрузки продолжается и "СВ_A" загружает наш самопальный (кастомный) "CB_B".
Во время запуска "CB_B" память DRAM не инициализирована, поэтому мы решили всего лишь применить к ней несколько патчей для того, чтобы она смогла запустить любой "CD". А именно:
- Все время активируем непривязанный (ZeroPaired) режим, чтобы мы могли использовать измененный образ SMC.
- Не расшифровываем "CD", а вместо этого предполагаем наличие в NAND памяти нешифрованного "CD".
- Не останавливаем процесс загрузки, если хэш "CD" неправильный.
"CB_B" зашифрован алгоритмом RC4, ключ создается из ключа центрального процессора, следовательно как мы изменим "CB_B" без знания ключа ЦПУ?
По существу, алгоритм RC4 это:
ШифрованныеДанные = НешифрованныеДанные XOR ПсевдослучайныйКлючевойПоток
Поэтому, если мы знаем незашифрованную и зашифрованную части, мы можем получить ключевой поток (гамму шифра), а с гаммой мы можем зашифровать наш собственный код. Все происходит следующим образом:
РазгаданныйПсевдослучайныйКлючевойПоток = ШифрованныеДанные XOR НешифрованныеДанные
НовыеШифрованныеДанные = РазгаданныйПсевдослучайныйКлючевойПоток XOR ИзмененныеНешифрованныеДанные
Вы могли бы подумать, что тут есть проблема курицы и яйца - как мы с самого начала получим нешифрованные данные? Легко: у нас имеются открытые загрузчики "CB" от фэт консолей и мы решили, что первые несколько байт кода будут такими же как и у нового "CB_B", поэтому мы могли бы зашифровать очень маленький кусочек кода, чтобы получить дамп кюча ЦПУ и расшифровать "CB_B"!
NAND содержит "CB_A", пропатченный "CB_B", нашу "полезную нагрузку" (payload) в кастомном незашифрованном "CD" и модифицированный образ SMC. Образ SMC модифицирован так, чтобы получить неограниченное число перезагрузок, и чтобы не допустить периодическую отправку I2C-комманд в то время, как мы отправляем наши. Сейчас, возможно, вы еще не осознали, но "CB_A" не содержит проверок фьюзов отмены (revocation fuses), так что это непропатчиваемый хак! (Прим. часть фьюзов центрального процессора Xbox360 применяется для хранения так называемого LDV - Lock Down Value - значения специального счетчика обновлений, а сравнивая значения LDV из процессора и из NAND можно пресекать попытки загрузки более ранних прошивок, т.н. даунгрейд)