что такое rgh xbox 360
В последнее время меня стали часто спрашивать про принцип действия Reset Glitch Hack. Чем был вызван такой интерес именно сейчас, мне не особо понятно. Но раз хотите, вот вам статья..
Сначала разберемся с процессом загрузки Xbox 360. Он состоит из нескольких загрузчиков, запускающих друг друга по цепочке: 
(более подробно можно почитать здесь )
Самый первый, 1BL, сидит в самом процессоре и никогда не меняется. Он один и тот же во всех приставках Xbox 360 (за исключением, возможно, Winchester)
Второй загрузчик (CB) привязан к Fuse #02 в процессоре. Таким образом, MS прикрывает уязвимые загрузчики — достаточно повысить значение этого фьюза и старый загрузчик просто не запустится. Так прикрыли JTAG. (подробнее про возможные конфигурации Fuse #02 читайте здесь)
Все они перед запуском следующего по очереди загрузчика, проверяют его на валидность. Если хоть немного изменить код, подпись оказывается нарушена и процесс загрузки оборвётся. Чтобы запустить свой код, необходимо подписать модифицированный загрузчик (что невозможно без секретного ключа) или каким-то способом обойти проверку. Последнюю идею и реализует RGH.
- Что такое POST BUS?
Это восьмибитная параллельная шина, в которую легко записать некоторое число прямо из кода загрузчика. Используется для отладки, проверки работоспособности процессора после изготовления, ну и для RGH 🙂
Благодаря тому, что в процессе загрузки в определенных участках кода происходит запись в эту шину, мы можем определить, на каком этапе исполнения находится процессор! Например, перед началом проверки подписи CB_B, значение шины меняется на 0xDA
- Как запускается неподписанный код?
Основная цель — запустить свой неподписанный загрузчик CD. В случае с одиночным загрузчиком CB, достаточно было «пропустить» лишь одну проверку. В двойной версии, поделённой на CB_A и CB_B, проверки были значительно усилены, так что без модификации CB_B не обойтись. Но CB_B зашифрован ключом CPU, который неизвестен! Как же его модифицировать? К счастью, особенности шифрования RSA таковы, что зная дешифрованные данные, можно поменять их даже не зная ключа. Модифицированный CB_B, конечно же, не будет проходить проверку в CB_A, но мы её «обходим» 🙂
- И как же мы обходим проверки?
- Ок, как это происходит?
Для выключения процессора, чип посылает сигнал ‘0’ на точку CPU_RST. Подать нужно в определенный момент и на определенное время. Необходима очень высокая точность, поэтому процессор желательно замедлить. В RGH1 для этого использовалась точка PLL, она замедляла процессор в 128 раз, так достигалась превосходная точность и высокая стабильность. На Slim подобной точки найти не смогли, поэтому замедление происходит по шине i2c, всего лишь в 3.1764 раза. Почему так мало? i2c позволяет замедлять и сильнее, но процессор начинает противиться, работая не на той частоте, что задали! При замедлении в 3 раза всё работает более-менее стабильно, так и оставили.
Какртинка в заголовке статьи показывает как примерно должен выглядеть импульс глича моей прошивки под x360ace 
- Хм. Тогда почему бы не использовать PLL в случае с RGH2?
При таком сильном замедлении выполнения кода CB_B, процессор перестает работать. Причина мне неизвестна.
- А что такое R-JTAG?
Как я уже писал, JTAG был прикрыт путём повышения значения Fuse #02. Старый загрузчик не запускается, потому что проваливается проверка этого самого фьюза. Вот в R-JTAG эта проверка и обходится с помощью чипа.
- MS ведь пыталась прикрыть RGH?
Да, конечно. Начиная с обновления 14717, в CB_A и CB_B отсутствует запись в POST_BUS, что должно было оставить RGH без точки отсчёта. Обошли эту проблему быстро — проверка Fuse #02 происходила в CB_B, так что хакеры использовали старый CB_A и ещё больше модифицировали CB_B.
Обновление 15572 принесло новый вид шифрования CB_B и невозможность его модификации без ключа CPU. Первое решение было от Team Xecuter — DGX чип. Он позволял запускать незашифрованный CB_B, пропуская сначала процедуру расшифровки, а затем и проверку подписи. Такой двойной обход был очень нестабилен, но всё же работал. Получив ключ CPU, можно было вернуться к старым чипам.
Ну а дальнейшее вам известно — ушлые китайцы добыли сервисный загрузчик MS, который запускал CB_B, зашифрованный нулевым ключом. И больше не было необходимости модифицировать родной CB_B, получился унивесальный образ для любых приставок.
После неудачи с программным отключением POST_BUS, летом 2012 MS просто убрали доступ к шине, убрав дорожки к точкам. Но после нашего релиза и эта проблема была решена. TX выпустили постфикс, китайцы успешно его скопировали, все счастливы.
Наконец, самая последняя ревизия Xbox 360, Winchester на данный момент считается невзламываемой. Обычных сигналов на шине POST нет даже с сервисным загрузчиком. Необходимо искать новую опорную точку. Но кому уже нужна консоль десятилетней давности?
Защита и взлом Xbox 360 (Часть 3)
В 2011 году, через 6 лет после выпуска игровой приставки Xbox 360, исследователями был обнаружен занимательный факт — если на вывод RESET центрального процессора на очень короткое время подать сигнал «0», процессор не сбросит своё состояние (как должно быть), но вместо этого изменит своё поведение! На основе этой «особенности» был разработан Reset Glitch Hack (RGH), с помощью которого удалось полностью скомпрометировать защиту Xbox 360, запустить неподписанный код, тем самым открыв путь к взлому самой системы и победе над «невзламываемыми» приводами DG-16D5S.
Давайте же рассмотрим в деталях, как работал RGH, как разработчики пытались залатать дыру и как эти заплатки смогли обойти!
Что вообще за глич атака?
Процессор — штука довольно глупая, что бы ни говорили маркетологи. Весь высокоуровневый код, написанный программистами, сводится к исполнению простых команд — арифметика с числами, перемещение данных, условные и безусловные прыжки. Предполагается, что процессор всегда исполняет эти команды без ошибок, а результат соответствует документации.
Действительно, компилируя код
вы полагаетесь на то, что значение переменной i увеличится ровно на 2, даже не представляя себе, как может быть иначе.
Глич-атаки нарушают эту уверенность — их цель направлена на то, чтобы процессор «сглючил» и повёл себя не так, как надо. Способов «глюкнуть» процессор несколько, например:
В случае же с 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), чтобы не страдала фигнёй и перезагружала приставку до посинения:
Итак, получаем алгоритм:
И получаем вот такую конструкцию на базе недорогого 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»:
Список нововведений не оставляет ни одного шанса для RGH. Но обратим внимание на последний пункт списка — до этого в «CB_A» не было проверки фьюзов! Фатальный недостаток. Более того, как мы помним, в расшифровке «CB_A» ключ процессора не участвует. А это значит, что уязвимый к RGH загрузчик «CB_A» можно запустить на любой приставке, и запретить это нельзя.
А вот чтобы что-то запустить с помощью этого уязвимого «CB_A», нужно несколько извернуться. Если мы не знаем ключа CPU, всё, что нам остаётся — патчить существующий «CB_B». Но что, если вместо модификации единичных участков, мы заXOR’им весь загрузчик целиком? И за счёт этого «запишем» старый загрузчик, который мы уже умеем патчить, на место нового? Так и поступили:
Всё, мы снова, не зная ключа, успешно подменили шифрованное содержимое, ещё и уязвимый загрузчик засунули. Приставки взламываются, 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):
И только тогда у вас будет возможность лицезреть в «сведениях о системе» кастомной оболочки такую вот надпись:
А на этом всё! Как обычно, готов ответить на ваши вопросы в комментариях 🙂
Freeboot [JTAG/RGH]
В обновленной версии статьи я постараюсь описать большую часть информации по теме установки Freeboot на консоль от Microsoft.
Взлому JTAG поддаются следующие виды консолей:
Xenon, Zephyr, Opus, Falcon, Jasper (дата выпуска до 15 июня 2009)
Основное условие — версия дашборда 2.0.7371, либо ниже. Версии 2.0.8498 — 2.0.15574 не подходят!
Взлому RGH (Reset Glitch Hack) поддаются:
Xenon, Zephyr, Opus, Falcon, Jasper, Trinity
Условие — версия дашборда 2.0.8498 — 2.0.14699. Версии 2.0.14717 — 2.0.15574 не подходят!
Взлому RGH2 поддаются
Zephyr, Opus, Falcon, Jasper, Trinity
Нужна версия дашборда 2.0.14717 — 2.0.14719.
Для установки Freeboot этим методом на приставки с дашбордом 2.0.15572-2.0.15574 необходимы заранее снятые ключ процессора и дамп памяти с версией дашборда 2.0.14717-2.0.14719!
Внимание. В процессе установки, требуются хорошие навыки пайки! К тому же, приставки Jasper часто выходят из строя при установке RGH. Я не рекомендую браться за установку RGH на чужую консоль. Свою — терзайте на здоровье.
Ну и да, я ни разу не устанавливал Freeboot на Xbox 360, так что инструкция больше затрагивает программную часть, чем пайку и оптимизацию (колдовство всякое). Удачи!
Модель материнской платы Phat приставки можно узнать по разъему питания и наличию HDMI выхода:
Модель материнской платы Slim приставки легко распознается по наклейке сзади, несущей информацию об энергопотреблении приставки: 
Версию Dashboard приставки можно посмотреть в настройке консоли — сведения о системе: 
В любом случае, перед началом действий, необходимо считать содержимое NAND приставки.
Это можно сделать несколькими способами. Если у вас уже стоит Freeboot (или XeLL), можно считать программно. Если консоль не подвергалась модификациям, можно считать по LPT или через специальное устройство — флешер.
2. XeLL
Новые версии XeLL позволяют считывать NAND по HTML. Чтобы запустить XeLL на freeboot приставках, нужно запустить приставку с кнопки лотка (иногда — запустить с открытым или полуоткрытым лотком).
Перед запуском, подключите приставку к роутеру (или компьютеру).
Если приставка была подключена к роутеру, на экране покажется полученный от него IP адрес. Если была подключена к компьютеру — необходимо будет указать в настройках сети компьютера IP и маску подсети (IP должен отличаться от указанного на экране последним значением). 
В итоге, после настройки сети, вбив адреc в браузер, попадаем на страницу, где можно «скачать» содержимое NAND. 
Но почти всегда приходится считывать память напрямик, с припаиванием проводов.
3. Чтение через компьютер
Паяльник и припой с флюсом нужны обязательно 
Самый простой вариант — LPT порт 
Надёжнее и быстрее будет использование SPI Flasher, но ради одного раза его покупать накладно. 
Как собрать SPI USB флешер
Также, можно приобрести ещё более быстрый Super NAND Flasher
Схема пайки флешера к Phat приставке:
Для Slim всё точно так же, схема расположения контактов:
В итоге, должно получиться нечто вроде этого:
Итак. Все припаяли, можно начинать.
Подключаем питание к приставке, но не включаем её, подключаем LPT или USB к компьютеру.
Запускаем компьютер, запускаем командную строку (Win+R — cmd), переходим в папку с Nandpro командой cd (например, cd C:/NandPro)
Далее, нужно считать содержимое NAND приставки. Можно считать полностью, а можно только первые 50 блоков. Это намного быстрее, но потом нужно будет считать оставшуюся часть через XeLL.
Размер памяти на всех приставках, кроме Jasper — 16 мегабайт (128 мегабит).
На Jasper Arcade (без HDD в комплекте) — 256 или 512 мегабайт. На элитках с HDD, опять же, 16 мегабайт.
Аналогично, для чтения больших NAND на джасперах, нужно вводить -r64 (системная информация находится только в первых 64 мегабайтах)
Если вы решили сэкономить время и считать только первые 0х50 блоков, нужна команда
Если в случае с LPT выдало 
То, возможно, у вас плохо (или неверно) припаяны провода.
Если не хочет действовать, перепаивайте, укорачивайте и утолщайте провода, либо ищите USB SPI Flasher. Важно, чтоб провода имели одинаковую длину.
Если же все нормально, программа начнет читать Nand. На 16 мегабайтных флешках этот процесс длится около 40 минут (по USB — 5 минут). На 256 и 512 (где мы снимаем только 64 мб) — около двух с половиной часов (по USB — минут 20).
В процессе чтения возможны ошибки. Зачастую, это так называемые бэд блоки — ошибочные сектора памяти. Это нормально, данные с этих блоков находятся в конце памяти. Но если вы считываете только первые 50 блоков, перенесенные данные не будут считаны! Поэтому, лучше точно проверять дамп на корректность.
Для проверки считанного дампа, можно использовать мою программу — NandCheck
Для проверки, достаточно перетащить файл дампа на иконку файла программы.
В отчете будут показаны все ошибки, ошибочные блоки, заремаплены они или нет. Ну и в конце, показывает общий статус дампа, корректный или нет. В случае ошибки, будет выдан результат ERROR. В таком случае, нужно будет считать дамп заново. Вполне вероятно, что в программе есть баги — если найдете, сообщите.
Если выдало статус ОК, повторно считывать не нужно. Так вы сэкономите время и нервы.
Дальше, для разных случаев, нужно действовать по-разному.
Для JTAG XeLLous один — его можно скачать здесь
А вот для RGH/RGH2 его нужно собирать отдельно.
Затем запускаем сам 360 Multi Builder (Run.exe)
Следуем указаниям программы:
Сначала подтверждаем выбор nanddump.bin в папке 
Затем выбираем модель материнской платы 
Потом подтверждаем желание собрать XeLL 
В процессе программа может предупредить о замене CB из-за того, что текущий загрузчик не подходит для RGH — это нормально. Также возможны предупреждения о сборке XeLL для RGH2, т.к. текущий загрузчик не подходит для RGH
После сборки, XeLL будет находиться в папке Data/_my_Images. Осталось записать его в приставку.
Записывать в приставку XeLL нужно через NandPro:
Остается лишь вопрос о CPLD и его модификации.
Со времен разработки первой версии Reset Glitch Hack, использовался чип от Xilinx. Но некоторые умельцы портировали его на другие чипы, такие как Actel. Судя по отзывам, они действительно зачастую (но не всегда) шустрее. К сожалению, команда, занимающаяся взломом консолей на данный момент, Team Xecuter, стремится к монополии и не выкладывает исходные коды прошивок, поэтому, гличи на Actel не подходят для Phat RGH2 и Xenon.
Итого, сейчас самые универсальные платы для глича — Matrix Glitcher I (от 5$) и Xecuter Coolrunner (от 9$)
Для Trinity есть ещё X360Pro на Actel. А его третья и четвертая версии еще и содержат функционал DualNAND 
Есть и отечественные разработки:
Слева — глич от Freeplex, справа — от kim095 
В версии от kim095 есть очень много возможностей для точной подстройки.
Также, можно купить заготовки вроде таких: 
Но их необходимо «допиливать» до нужного состояния, потому они уже не популярны.
Также, можно собрать самостоятельно:
Для тех, кто хочет собрать самостоятельно, прилагаю простейшие схемки для плат
Slim (Phat RGH2) версия / Phat RGH1 версия 
Конденсаторы, выделенные пунктиром, необязательны.
Для улучшения запуска, многие прибегают к различным модификациям — ставят конденсаторы куда ни попадя, резисторы и прочее. К примеру, для RGH2 на Phat ставят резистор 10Ком, соединенный параллельно с конденсатором на 470pf, в разрыв провода CPU_RST.
Как я понял, всё это колдовство с конденсаторами, длиной проводов и диодами означает лишь нестабильность и ненадежность любых Glitch устройств.
1.8v можно взять с платы приставки (грейфрутовый цвет на рисунке – на всякий случай, проверьте мультиметром). 
А можно и прикрутить на свою плату стабилизатор питания на 1.8v
Для программирования CPLD через LPT, понадобится 360gcprog 1.5
Для программирования через Super NAND Flasher сойдёт и NandPro 3.0
Отдельно прошивки для программирования можно скачать здесь
Для RGH используются прошивки xenon, zephyr, opus, falcon, jasper, trinity1.1 и slimpluspost (последняя — как альтернатива)
Для RGH2 используются trinity1.1, slimpluspost и набор прошивок для Phat:
Falcon/Opus — B, C и E версии
Jasper — A и D версии
Zephyr — D и C версии
Вот схема для подключения CPLD к компьютеру по LPT: 
Внимание! В некоторых случаях, для корректной работы, приходилось уменьшать резистор до 3 КОм.
Вместо батареек можно использовать 3.3в с матплаты компьютера. VCC – это вывод 3.3в на схеме платы CPLD.
Подключив по LPT к компьютеру, смотрим номер порта: 
Теперь запускаем 360gcProg и вписываем порт в настройки: 
Теперь нажимаем Connect и подключаемся к устройству 
Выбираем из списка нужный тип прошивки и записываем его в Glitch 
Через NandPro 3.0 всё делается командой
nandpro xsvf: firmware.xsvf, где firmware.xsvf — имя прошивки для чипа 
Ну теперь осталось припаять CPLD к приставке. Расположение точек на Slim приставке:
Распайка для Phat, RGH 1
Распайка для Xenon, RGH 1. Немного поменял формат исходной картинки
Как написано на картинке, для улучшения запуска, нужно добавить конденсатор на 47нф.
Распайка для Phat RGH2 похожа на распайку для Slim: 
Рекомендуется добавление резистора 10 Ом на CPU_RST.
Распайка для JTAG намного проще. Понадобятся диоды.
Схема для Xenon: 
Схема для остальных: 
Так. Если вы считывали только 0х50 блоков, не забываем дочитать оставшееся через XeLL! (см начало статьи)
Ну что, осталось лишь собрать фрибут.
Если собранный фрибут не запустится, используйте 360 Multi Builder 0.94 (последний xebuild почему — то некорректно собирает некоторые дампы, да и в самой версии 0.95 имеются косяки)
Скриншоты оставлю старые, в сборке фрибута ничего сложного нет. В процессе сборки, будет вопрос про отключение FCRT — если у вас привод родной, делать этого не нужно. Также это лишь помешает на приставках с приводами 1071 и 1125.
Выбираем сборку Glitch Hack Image (или JTAG Image) 
Можно и с дашланчем, не помешает 
Программа сообщает, что всё собрано. Готовый файл nandflash.bin находится в папке Data 
Рекомендуют писать через XeLL. Так и поступим 
Для записи, понадобится rawflash4
Полученный файл nandflash.bin кидаем на USB флешку вместе с содержимым архива rawflash4.
Запускаем XeLL с вставленной флешкой – прошивка запишется в приставку 
После перезагрузки приставки появится Freeboot. Если не запустился — пробуйте собрать через предыдущий мультибилдер.
На этом всё.