Поделитесь бинарным файлом загрузчика 1bl

[lprot 0]

Некоторые высказывания - просто полный АХТУНГ.

 

"EFUSES восстанавливаемые!!! Инфа 100500%"

Технология Efuses, находящихся on die (на одном кристалле) с самим чипом отработана фирмой IBM задолго до появления Xbox360, году в 2000м. Основная идея - прожигаемые физически перемычки. Прям как в древних советских микросхемах ROM, только на микроуровне. Достоинства - необратимость, не требует питание для хранения информации, удобно при массовом производстве.

Доказательства в гугле по ключевым словам IBM, efuses. Гдето был pdf документ - презентация - самой IBM с микрофотками процесса.

 

Идем дальше.

"перешивается ли ПЗУ в процессоре..."

Не перешивается пресловутый 1BL. Потому как находится опять же on die - на одном кристалле - с таким непредсказуемым устройством, как трехядерный процессор. 32Кб ROM печатаются офсетом. Те же достоинства - надежность (невозможность убить прошивку), дешевизна, не требует питания для хранения.

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

Да и далеко ходить от бокса не надо. В том же ДВД-РОМ сделан микроконтроллер с флешпамятью на разных кристаллах, но упакованных в один корпус. Для чего? Чтобы хакерам было удобнее с помощью кислоты получить доступ к кристаллу флешпамяти?!

 

 

Не ставятся перед 1BL какието сверхзадачи, в которых вы его подозреваете. Процессор запускается на пониженной частоте (около 800МГц, если не ошибаюсь) и только одно ядро. Оно и выполняет код 1BL с целью протестировать целостность внутренних и внешних шин, распаковать 2BL в SRAM и передать ей управление.

Всё остальное - инициализация всех трёх ядер, вывод на рабочую (но всё ещё пониженную) частоту, менеджмент питания процессора и т.п. - выполняет уже 2BL.

Четко, грамотно и конкретно объяснено. :good:

 

Вопрос как к специалисту. Известно что джитаг на рассматриваемом нами процессоре отключен. Есть ли пути его включить, или при изготовлении процессора его попросту не реализовали?

 

[RichY 0]

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

[lprot 0]

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

Так он может не пахать из-за других напряжений питания. Техпроцесс ведь другой и т.д. Хотя вполне возможно что есть разные 1BL(зефир, фалькон, джаспер и т.д.) под которые соотвествующие 2BL.

 

Но принцип работы у них одинаковый. И находятся они в ROM. Иначе быть не может.

[RichY 0]

не, питание проверяли. идентично.

[HOMiE7 0]

EFUSE can be reconnected using a FIB (Focused Ion Beam) machine, which costs highly over $1 Million, that is if you are able to decap it, and transplant the modified CPU die into a new housing. Also, there are no damn ways in the world that LiteOn will impliment efuse into a microcontroller. Such technology is too expensive and too complicated to be used into a simple drive controller.

Да, что-то я перестарался)

Насчет eFuses извиняюсь)

[lprot 0]

Да, что-то я перестарался)

Насчет eFuses извиняюсь)

Насчет EEPROM в проце тоже :)

[RichY 0]

Да, что-то я перестарался)

Насчет eFuses извиняюсь)

Эт ты на хбоксхакере спросил у народа?

[Chook 0]

Есть несколько вопросов.

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

А зачем читать фусы, достаточно их (ключ проца) прожечь до состояния FF .... FF и получим ключ проца...

 

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

Кстати, я согласен, что 1bl в ROM лежит. Имея 2 степени защиты на запуск внешнего кода он со своей задачей справляется, зачем его трогать.

[RichY 0]

Фьюзы как я понял, нельзя расшифровать без ключа. Ключ лежит тоже в фьюзах но нерасшифрованный.. Либо это все не так

[Cluster 0]

lprot

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

 

Chook

Не совсем так - чтобы считать фьюзы, нужно иметь возможность запустить свой код (xell например).

А так, много у кого есть CPU-key, после считывания которого консоль обновлена до нового дашборда. Это дает возможность разбана консоли подменой kv, но вот запустить свой код и считать фьзы возможности уже нет...

[lprot 0]

А зачем читать фусы, достаточно их (ключ проца) прожечь до состояния FF .... FF и получим ключ проца...

 

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

Если ты прошьеш фузы в FF.. Получиш брик. Так как в NAND многое пошифровано ключем CPU. А если ты его сделаешь FF.. то что будет? Понимаешь сам.

 

Насчет доступа к фузам. Он может быть организован по разному. Как точно, думаю на хакере могут дать точный ответ.

 

По поводу программного взлома. Сейчас много у кого есть девкиты. Они ведь подписывают код? Насколько я понимаю, используются ключи(подписи) для игрового кода? Можно ли создать какой-либо эксплоит при помощи кода подписанного в девките?

 

По поводу того как сдампили 1BL. Скорей всего купили девкит, написали код в шейдер, который сдампил 1BL, гипервизор и т.д.

 

На а дальше IDA и т.д. Не думаю что использовалась химия для послойного сканирования проца.

 

Потом нашли баг в гипервизоре, ну а дальше все расписано в вики.

 

 

[ZEV1416 0]

Есть соображения:

1. Не смысла даже пытаться трогать 1BL - он записал в ROM и процессор при старте все равно его выполнит. Он прочтет 2BL, выполнит сравнение подписи 2BL с ключем, вшитым в 1BL и с текущим состоянием FUSE. Т.к. эл. подпись мы не знаем - сделать что-то свое подписанное, тем более совпадающее с текущим FUSE, у нас точно не получится.

2. Хотелось бы понять, как именно выполняется сравнение 2BL на соответствие текущим FUSE - сравнивается весь блок FUSE или какая-то его часть? Если часть - где указано, какая именно. Ведь если это понять и найдется способ шить FUSE - можно прошить еще один "ряд" и сделать его текущим. Прошив его аналогично состоянию старых прошивок, мы получим возможность их запуска. Достаточно будет просто внять ключ проца и сделать жтаг.

3. Еще вопрос - у нас определенно есть возможность писать в некоторые области флеш-памяти, где эл. подпись не проверяются (тот же разбан записи на диск это подтверждает). Можно попробовать записать по некоемому адресу нужный нам код в таком виде: забить все NOPами, а в конце сделать нужную нам работу. При этом если будет найдена возможность изменить текущий адрес памяти, откуда процессор берет команды, на наш (например посадим нужные нам ноги проца на землю и питание соответственно, добившись чтения из нужного блока памяти вне зависимости от желание процессора). В нашем коде мы говорим процессору перейти на выполнение в том же блоке памяти и крутим цикл на 10 секунд. На 7 секунде мы убираем "посадку на землю или питание" с ног процессора и он на 10 секунде возращается к нормальной работе, но уже по нашему адресу. А дальше делаем что хотим. Вариант сложный, но он может пригодиться на 1 раз, для изменения FUSE на старую версию, чтоб заработал JTAG.

Извините, если несу бред :)

[asdfghjkl 0]

lprot

dev консоли не подписывают исполняемые файлы для работы на retail приставках,данную задачу выполняют Microsoft,у них есть сверхсекретный ключ,которым они и подписывают xex-ы.

На Dev консолях код может быть неподписанным,он и без подписи запускается :)

Можно попробовать написать эксплойт в xna game studio,можно писать приложенимя прямо на retail боксе

(xna game studio для xbox 360 студентам на год бесплатно дают)

Изменено 12 декабря 2010 пользователем asdfghjkl

[lprot 0]

Есть соображения:

2. Хотелось бы понять, как именно выполняется сравнение 2BL на соответствие текущим FUSE - сравнивается весь блок FUSE или какая-то его часть? Если часть - где указано, какая именно. Ведь если это понять и найдется способ шить FUSE - можно прошить еще один "ряд" и сделать его текущим. Прошив его аналогично состоянию старых прошивок, мы получим возможность их запуска. Достаточно будет просто внять ключ проца и сделать жтаг.

3. Еще вопрос - у нас определенно есть возможность писать в некоторые области флеш-памяти, где эл. подпись не проверяются (тот же разбан записи на диск это подтверждает). Можно попробовать записать по некоемому адресу нужный нам код в таком виде: забить все NOPами, а в конце сделать нужную нам работу. При этом если будет найдена возможность изменить текущий адрес памяти, откуда процессор берет команды, на наш (например посадим нужные нам ноги проца на землю и питание соответственно, добившись чтения из нужного блока памяти вне зависимости от желание процессора). В нашем коде мы говорим процессору перейти на выполнение в том же блоке памяти и крутим цикл на 10 секунд. На 7 секунде мы убираем "посадку на землю или питание" с ног процессора и он на 10 секунде возращается к нормальной работе, но уже по нашему адресу. А дальше делаем что хотим. Вариант сложный, но он может пригодиться на 1 раз, для изменения FUSE на старую версию, чтоб заработал JTAG.

Извините, если несу бред :)

п.2 eFuse - память типа PROM. Однократное программирование. Если перемычка (бит) прожглась, то ее уже не восстановить.

В 2BL (CB) в заголовке находится значение eFuse с которым он работает. Если значение отличается, 2BL (CB) заканчивает работу. Так что программирование eFuse, ничего хорошего не даст.

 

п.3 идея интересная, только процессору говорит куда перейти - гипервизор. Он сидит между процом и любым выполняемым на xbox кодом. Он выполняет только подписаный код. Если удастся обойти гипервизор, считай получилось.

 

lprot

dev консоли не подписывают исполняемые файлы для работы на retail приставках,данную задачу выполняют Microsoft,у них есть сверхсекретный ключ,которым они и подписывают xex-ы.

На Dev консолях код может быть неподписанным,он и без подписи запускается :)

Можно попробовать написать эксплойт в xna game studio,можно писать приложенимя прямо на retail боксе

(xna game studio для xbox 360 студентам на год бесплатно дают)

Почитал на досуге о XNA и о dev консолях. Насколько я понял, для их работы нужен лайв? Созданный код отправляется на лайв сервак майкрософта, там подписывается, и затем ты его видишь в консоли как Live приложение, скачиваешь и запускаешь? Кто знает, публичный RSA ключ на подпись CB и подпись Xex - один и тотже?

Изменено 13 декабря 2010 пользователем lprot

[SaNcHoZ 0]

Дев консоли вроде как только должны держать постоянное соединение с лайвом, на подпись в мс они ничего не отправляют.

[asdfghjkl 0]

Почитал на досуге о XNA и о dev консолях. Насколько я понял, для их работы нужен лайв? Созданный код отправляется на лайв сервак майкрософта, там подписывается, и затем ты его видишь в консоли как Live приложение, скачиваешь и запускаешь? Кто знает, публичный RSA ключ на подпись CB и подпись Xex - один и тотже?

приложение компилится и хранится на консоли на жестком диске,в контейнере,который подписывает MS

Кстате Xna не запускается без лайва и наработки сделанные в нем тоже

Изменено 13 декабря 2010 пользователем asdfghjkl

[ZEV1416 0]

п.2 eFuse - память типа PROM. Однократное программирование. Если перемычка (бит) прожглась, то ее уже не восстановить.

В 2BL (CB) в заголовке находится значение eFuse с которым он работает. Если значение отличается, 2BL (CB) заканчивает работу. Так что программирование eFuse, ничего хорошего не даст.

Согласен. Но тогда, если 1BL использует для сравнения eFuse целиком - по сути у MS есть число итераций, равное битности eFuse, для перехода из 000...000 до 111...111. Причем каждое следующее состояние eFuse имеет 1-цы во всех тех битах, где и предыдущее, плюс в некоторых доп. разрядах (чтоб были отличия).

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

 

п.3 идея интересная, только процессору говорит куда перейти - гипервизор. Он сидит между процом и любым выполняемым на xbox кодом. Он выполняет только подписаный код. Если удастся обойти гипервизор, считай получилось.

Пусть гипервизор - он читает данные с носителя, проверяет их подписанность и если все ок - перемещае указатель следующей выполняемой команды на точку входа в программу. Далее процессор просто выполняет размещенные по указанному адресу машинные коды. Самому процессору все равно, пописаны они или нет. Если вовремя выполнения переключить страницу памяти, откуда идет выполнение (или, если работа с памятью идет не постранично - на шине адреса выставить некоторые биты так, чтоб выполнение продолжилось в нужном нам диапазоне) - процессор продолжит выполнять записанный туда код. Подготавливаем достаточно большую область памяти своими данными (те же ресурсы в игре правим на свои), и во время выполнения принудительно выставляем на шину свои значения. Для минимизации вероятности сбоя забиваем подменную область nop-ами, а в конце блока делаем следующее:

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

- записываем следующий адрес выполнения, лежащий в нашей 2-ой области (там и будет основная работа)

- записываем в текущей области по смещению, аналогичному 2-ой области, цикл ожидания

- переходим на цикл ожидания

Теперь, как только будет снято принудительное выставление адреса с шины адреса, выполнение перейдет на аналогичное смещение 2-ой области памяти.

2. Убираем левый адрес с шины - процессор переходит на нужную нам страницу памяти и продолжает выполнение оттуда. Далее делать можно все, что угодно.

Например, выяснить серийник проца.

 

Далее, если публичный ключ MS записан в перезаписываемой (или хотя бы "дожигаемой" памяти) - можно всем миром попробовать сгенерить пару ключей так, чтоб открытый ключ имел 1-цы во всех битах, где 1-цы у оригинального открытого ключа MS. Тогда, прошив свой открытый ключ, мы вообще получим возможность самостоятельно пописывать прошивки.

 

[Cluster 0]

если 1BL использует для сравнения eFuse целиком - по сути у MS есть число итераций, равное битности eFuse, ...

Не целиком. Представляйте EFUSE просто как ещё одно устройство постоянной памяти.

 

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

Не продолжит по некольким причинам.

1. Согласен, для 8086го процессора такое прокатит, но уже 80386 процессор умеет работать в защищенном режиме, а современные процессоры имеют аппаратную защиту от подобных сбоев в защищенном режиме. Гипервайзор, и только он, на боксе работает в кольце RING0.

2. Память ВСЯ зашифрована.

3. Надеюсь вы понимаете, что мы говорим об исполняемом коде в SRAM? Которая находится на одном кристалле со всеми тремя ядрами. Чем вы будете "менять страницы" и "выставлять биты на шине адреса" в пределах кристалла CPU?

[3D Gluk 0]

Может быть какие нибудь сдвиги покажут на конференции хакеров 28 декабря

http://psx-scene.com/forums/f6/new-ps3-exp...nference-73258/

Написано что соберутся самые лучшие хакеры

[alxxbx 0]

Не целиком. Представляйте EFUSE просто как ещё одно устройство постоянной памяти.

 

 

Не продолжит по некольким причинам.

1. Согласен, для 8086го процессора такое прокатит, но уже 80386 процессор умеет работать в защищенном режиме, а современные процессоры имеют аппаратную защиту от подобных сбоев в защищенном режиме. Гипервайзор, и только он, на боксе работает в кольце RING0.

2. Память ВСЯ зашифрована.

3. Надеюсь вы понимаете, что мы говорим об исполняемом коде в SRAM? Которая находится на одном кристалле со всеми тремя ядрами. Чем вы будете "менять страницы" и "выставлять биты на шине адреса" в пределах кристалла CPU?

 

у ХЕНОНа шина адреса и данных единая в процессоре для всех устройств, в т.ч. и вне процессора, но адрес исполняемого кода в SRAM проца - 64 бита, а адрес оперативной памяти - 32 бита. Получается, что невозможно подвесить к процессору любое запоминающее устройство с 64 бит адресом.

[darkrogua 221]

Дело совсем заглохло?

[spor666 0]

по ходу,да

Хотя меня этот вопрос очень интересует :nea:

[darkrogua 221]

по ходу,да

Хотя меня этот вопрос очень интересует :nea:

Да я думаю это многим интересно только некому засунуть свои руки в бокс и все тестировать это. Были бы боксы которые можно ломать тестировать на них все и лежала бы куча было бы шикарно=) Но не каждый сможет себе стоко =) Да и всем жалко свою коробку=)

Изменено 5 января 2011 пользователем darkrogua1992

[spor666 0]

Я могу попробовать,мне терять уже нечего,ключ привода стёр и теперь сижу кукую

Только что сделать надо???? :pleasantry:

[RichY 0]

Ключ стер? Если бокс выпуска до июля 2009 с дашем 7371, то можно восстановить :)

 

Кстати, есть одна заманчивая идея.

У кого есть возможность экспериментировать с записью флеш на боксе с потерянным ключом, пишите в аську