Autogg xbox 360 инструкция

Инструкция по установке FreeBoot.

Что нам понадобится:
1. Программатор (X360 Squirt slave programmer, Super nand flasher, Matrix NAND Programmer, Xecuter J-R Programmer, один из них, на ваше усмотрение, можно даже самому собрать на микросхеме PIC)
1.1 Если у вас Corona 4gb to вам потребуется карт-ридер и адаптер microSD-SD и резистор 68 Ом
2. Чип (X360Run (если у вас материнская плата Trinity или Corona) или  Matrix Glitcher v3 (подходит для всех ревизий включая старые приставки phat) )
2.1 Post fix adapter (или подпаяться к шарику процессора напрямую, об этом позже)
3. Провода (МГТФ желательное с меньшим сечением или AWG24/AWG26)
4. Флюс, паяльник, спирт, припой
5.  AutoGG  из программного обеспечения, качать тут

Если у вас приставка ревизии Corona (16mb)  или Trinity то нужно подпаяться к  флешеру по схеме ниже.

Если у вас Corona 4gb, то  паяем по схеме указанной ниже

На материнских платах Corona (если не ошибаюсь начиная с 07.2012) отсутствуют резисторы, на их месте делаем маленькие перемычки из проводов

Запускаем программу AutoGG, подключаем питание к вашей приставке (включать не нужно).

Выбираем программатор (в зависимости от того что у вас есть) для материнских плат объем памяти которых составляет 16 мб

Для всех новых материнских плат надо указать версию NandPro 2.0b или 2.0b ArmV3

В случае с 4Гб памятью (только материнские платы Corona) выбираем MMC/SD

Считываем содержимое NAND

программа спросит сколько Мб ей нужно считать (если 16 мб Corona\Trinity выбираем 16, если 4 Гб Corona то 48 Мб) и сколько раз (выбираем 2). Если по окончании чтения программа выдаст сообщение что все в порядке с вашим Nand, то переходим к следующему пункту, если же нет, то повторите чтение несколько раз пока хотя бы 2 копии вашего NAND не совпадут.

Затем нам создать Xell и записать его в приставку, для этого:
1) нажимаем кнопку Create
2) Затем Flash

После заливки Xell я рекомендую отпаять флешер. У кого Corona 4 Гб надо только отпаять провод которые идет от кварца к резистору, если вы его забудете отпаять то приставка не запустится.

Если вы купили чип Matrix Glitcher v3, то вам нужно его прошить предварительно (подпаявшись к нему) (у кого чип X360Run смело пропускают этот пункт).

1) Жмем Flash Glitch
2) выбираем тип материнской платы, так же нужно в разделе Chip выбрать Xilinx
3) жмем Flash Glitch Usb

Стрелочками я обозначил самые удачные на мой взгляд прошивки для материнской платы Corona (для Trinity там всего одна)

Теперь нам надо запаять наш чип (см. картинки на примере X360Run, мат.плата Corona)

Установка чипа X360Run на Trinity идентична Corona, их отличает только точка D. И еще нужно выпаять керамический конденсатор на 331 пФ и поставить 221 пФ, в некоторых случаях помогает так же установка конденсаторов на 251 и 271 пФ.

На картинке ниже отображены типы памяти и пояснение, т.к. Microsoft убрала точку С (в данном случае, если Matrix Glitcher V3 то точка В) то нам нужно будет подпаяться напрямую к шару процессора или поставить PostFix adapter.

Установка PostFix адаптера

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

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

Если вы устанавливаете X360 run на мат.плату Corona, то не нужно ничего трогать на чипе, если ставите на Trinity, то ниже приведены тайминги, S- short (запаян), O — open (открыт, не запаян)
M1-S D2-O D1-S D0-S
W2-O W0-O W1-O M0-O
M2-0

Схема по установке Matrix Glitcher на материнскую плату Trinity. Т.к. вы скорее всего купите Matrix Glitcher V3 с кварцем, то точку С можно не припаивать.

Установка Matrix Glitcher v3  на материнскую плату Corona идентична с Trinity, единственное, что их отличает это то что на Corona нет точки FT4R2, вместо нее там точка R4P4.

После этого запускаем приставку, старт приставки может быть как моментальным так и достигать до 2 минут (в этом нет ничего страшного, всегда можно оптимизировать запуск), на экране должно появится следующее

и самая нужная строчка является строка с вашим ключом процессора (на картинке ключ специально затерт, у вас же там будет набор цифр и букв)

Вводим эти символы в раздел CPU-KEY в программе

Если вы ввели цифры правильно, то программа сохранит ваш оригинальный NAND в своей папке вместе с вашим ключом, если вы ввели какой-то символ не верно, то AutoGG выдаст ошибку.
Далее ставим галочку на DashLaunch и нажимаем кнопку Create

В папке  AutoGG_0.9.3\output вы найдете свой готовый  файл с названием nandflash.bin, вот его нам и нужно прошить в приставку.

Рассмотрим несколько способов как прошить приставку

1. Прошивка с помощью флешки (для Corona\Trinity 16 Mb)
а) Подключаем флешку (FAT-32) к компьютеру
б) Нажимаем RawFlash

Выбираем вашу флешку и жмем ОК

В корне флешки должны находится файлы nandflash.bin и xenon.elf. Вытаскиваем ее из компьютера, вставляем в Xbox 360 и включаем его, после того как загрузится Xell, он подхватит файл xenon.elf и прошьет вашу приставку. Желательно пользоваться флешкой со световой индикацией работы, потому как после того как ваша прошивка зальется индикатор перестанет моргать, что будет свидетельствовать окончанию процесса.

2. Прошивка с помощью программатора (для Corona\Trinity 16 Mb)
а) Запаиваем все по схеме (схема в самом верху)
б) Нажимаем кнопку Flash и соглашаемся на прошивку с текущими данными

3. Прошивка с помощью карт-ридера (только для Corona 4Gb)
а) подпаиваем наш переходник MicroSD-SD к приставке (схема была выше)
б) нажимаем кнопку Flash и соглашаемся на прошивку с текущими данными

Вот в принципе и все, осталось только установить на консоль ПО.
Я постарался кратко и своими словами объяснить Вам как установить FreeBoot на приставку Xbox 360 Slim.

P.S. Я не несу ответственности за то, что вы можете сломать вашу консоль, это ваше личное дело следовать моей инструкции или нет. В тексте возможны некоторые опечатки, возможно я упустил из виду некоторые мелочи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И если с первыми двумя пунктами исследователи справились сами, подвиг перевода в «Mode B» предстояло повторить всем

юным

прошивальщикам.

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

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

насиловали

прошивали.

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

Ответ Microsoft

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

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

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

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

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

• Для Hitachi нашли разблокировку режима прошивки через специальный аудио диск

• Samsung ms28 и BenQ VAD6038 отлично заходили в режим прошивки через недорогие SATA контроллеры VIA 6421
  

  Картинка с сайта: habr.com

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

Ломаем ось!

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

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

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

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

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

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

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

//в %r0 – номер системного вызова
13D8: cmplwi %r0, 0x61 //сравниваем с максимальным допустимым ID
13DC: bge illegal_syscall //если переданный номер больше 0x61, говорим, что неверный
...
13F0: rldicr %r1, %r0, 2, 61 //умножаем номер системного вызова на 4
13F4: lwz %r4, syscall_table(%r1) //достаём адрес обработчика из таблицы
13F8: mtlr %r4 //помещаем адрес обработчика в регистр lr
...
1414: blrl //прыгаем на этот адрес

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

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

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

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

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

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

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

Даунгрейд!

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

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

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

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

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

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

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

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

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

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

JTAG Hack!

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

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

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

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

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

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

• При запуске, южный мост по GPU JTAG лезет на PCI Express и настраивает контроллер NAND
• Теперь контроллер NAND при чтении будет записывать данные в нужную нам область памяти
• Ядро системы запускается и сообщает южному мосту, что система запустилась
• Южный мост дёргает NAND контроллер, перезаписывая ОЗУ в нужном месте и эксплуатирует уязвимость гипервизора!
• Передаётся управление на наш код, делаем что хотим

Короче, сделали всё то же, как в King Kong Shader Exploit, но круче — нет необходимости запускать игру и менять диски.

На базе JTAG Hack создали модифицированные версии системы — XBReboot, Freeboot, с отключенной проверкой подписи, где уже разгулялись пираты. Игры можно было запускать не только с USB носителей и дисков, но и по SMB протоколу прямо с компьютера.

Что немаловажно, полноценный взлом системы давал шанс тем, кто потерял ключ DVD и не мог играть — имея ключ процессора, извлечь ключ DVD было несложно.

Конечно же, и здесь Microsoft быстро закрыла уязвимость, снова обновив 2BL и повысив значение CBLDV. На этом эпопея уязвимого гипервизора закончилась, народ побежал скупать остатки «совместимых с JTAG» приставок в магазины — всем хотелось без проблем играть с USB флешек. На форумах велись обсуждения, какие бандлы с какой датой выпуска годятся для взлома…

Тема модификаций системы Xbox 360 заглохла почти на два года, а вот тема прошивок продолжала развиваться. И как раз в прошивке приводов LiteOn разыгралась самая обширная битва исследователей и Microsoft. Но об этом в следующей статье

Ссылки:

доклад GoogleTechTalks
King Kong Hack
Timing Attack
JTAG / SMC Hack

Защита и взлом Xbox 360, Часть 1
Защита и взлом Xbox 360, Часть 2
Защита и взлом Xbox 360, Часть 3

P.S. Кому интересны подробности, отвечу на любые интересующие вопросы по теме в комментах!

Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку

Услуги по установке freeboot на Xbox 360 оказывают специализированные мастерские. Но если у вас есть паяльник и вы умеете им пользоваться, то вы можете установить freboot на свою приставку самостоятельно. Ниже приведена инструкция, как это сделать.

В зависимости от ревизии приставки, процесс установки freeboot может немного отличаться. В статье рассматривается установка на материнскую плату Corona (Xbox 360 Slim и E).

В наших мастерских производится установка Freeboot на Xbox 360 . Вы можете смело довериться многолетнему опыту наших специалистов. Звоните и записывайтесь!

Необходимые чипы

Для установки фрибута вам нужно будет купить:

1. Super Nand Flasher, либо аналогичные программаторы

2. X360Run — подходит только для плат Corona или Trinity. Есть универсальный аналог Matrix Glitcher v3, который подходит для всех плат, но требует прошивки перед установкой.

3. Post Fix Adapter. На нём можно сэкономить и припаяться к процессору приставки напрямую.

К плате Corona 4 ГБ вам нужно будет подпаять SD-карту:

Все эти чипы можно купить в специализированных магазинах. Также вам потребуется программа AutoGG, которую можно найти в интернете.

Подготовьте паяльник, флюс, припой и чистящий раствор (можно заменить спиртом).

Подключение Super Nand Flasher

Припаяйте к приставке Super Nand Flasher по этой схеме:

Если на вашей плате отсутствуют резисторы R2C6, R2C7, R2C10, вставьте на их место перемычки из проводов:

Считывание NAND

После того, как вы припаяли Super Nand Flasher, вставьте в приставку кабель питания (саму консоль запускать не нужно) и подключите её к компьютеру.

На компьютере запустите AutoGG и выберите программатор:

Для Corona 4GB необходимо указать MMC/SD.

Затем в разделе Nandpro version выберите NandPro 2.0b или 2.0b ArmV3

Для считывания содержимого NAND нажмите кнопку READ:

На экране появится запрос: какой объем необходимо считать. Для Corona 16 MB укажите 16, если у вас приставка с 4 ГБ внутренней памяти, указывайте 48 МБ.

Считывание необходимо произвести, как минимум, 2 раза. Если программа выдала ошибку, необходимо повторять процесс до тех пор, пока вы не получите 2 идентичных копии NAND вашей приставки.

Теперь создайте Xell (нажмите Create) и запишите его на приставку (кнопка Flash):

После этого Super Nand Flasher можно отпаять от приставки

Установка X360Run и PostFix adapter

Припаяйте к плате X360Run:

Затем установите PostFix adapter

Создание DashLaunch

Запустите вашу консоль нажатием кнопки привода. Через некоторое время (запуск занимает до двух минут) на экране появится заставка XELL, затем информация о вашей приставке:

Вам нужно списать CPU-key и ввести его в программу AutoGG:

Затем поставьте галочку напротив DashLaunch и нажмите кнопку Create:

Программа создаст файл nandflash.bin и сохранит его в папке AutoGG_0.9.3/output. Этот файл вам нужно записать на приставку. Сделать это можно с помощью флешки.

Запись DashLaunch на Xbox 360

Возьмите флешку со световым индикатором работы. Отформатируйте её в FAT32. В программе нажмите RawFlash и выберите вашу флешку: