Pandora (unbricker/downgrader) для PSP-200X TA-088v3
Сервисный комплект для PSP-200X
(включая TA-088v3)
{ НИЧЕГО НЕ ПРОДАЁМ / NO SALES HERE }
После удачного взлома и последующей длительной заморозки в скрытом разделе темы: "Размышления о возможностях взлома ТА88v3"
было решено, что настало время её разморозить и отдать "в народ".
Дабы не нарушать хронологию "размышлений по взлому", инструкция выложена в шапке отдельной темой.
Первое видео от Yoti
Новое видео подтверждение работы сервисной карты JigKick на PSP-2006 TA-088v3!
Скачиваем "MSID Dumper", вставляем карту памяти в PSP и запускаем программу. Видим на экране номер "Серийный номер" и MSProID вашей карточки и записываем, хотя дамп области MSID всё равно сохранится в корне карты памяти и вы можете его потом посмотреть хекс-редактором. Это вам может пригодиться, когда вы будете искать данные MSID в дампе микросхемы.
Тонким скальпелем располовиниваем корпус карты памяти пополам. Не поностью, а только заднюю часть и чуть больше половины по краям.
Затем пинцетом достаём из корпуса плату, она не приклеена, а просто лежит в пазах.
Из платы выпаиваем микросхему памяти (nand), которая самая большая и имеет 48 ножек. Рядом находится небольшой квадратный контроллёр памяти, его не трогаем.
Нужно учитывать, что с виду карты одинаковые, но внутри могут быть разные нанды, например Hynix или Samsung. Поэтому под вашу микросхему уже потом ищется программатор. Смотрим список поддерживаемых микросхем: http://www.soft-center.ru/reader/NAND_List.php.
Hynix, насколько я знаю, практически все имеют одинаковый стандарт выводов по даташиту среди TSOP-48, поэтому если буквы или цифры немного отличаются от списка поддерживаемых моделей, то это вряд ли имеет значение.
Микросхема вставляется в панельку программатора очень просто. Панелька имеет конструкцию прищепки, нажимаем сверху, контакты отходят, ставится микросхема и отпускаем, контакты прижимаются к ножкам микросхемы.
Далее, программатор подключается к компьютеру, с заранее установленной программой и драйверами, поставляемыми с программатором. В программе указывается диапазон страниц, которые нужно сдампить и дампится часть памяти.
Сразу дампить 2 Гб всей памяти очень долго, да и не нужно. Сразу скажу, что нужная нам служебная область, где прописан MSID карты находится либо в самом начале, либо в самом конце микросхемы, обычно в 1-ом банке и не далее 3-4 блоков. Рекомендую сдампить сразу 4 блока - это 256 страниц или 0x100 в шестнадцатеричном виде, что и нужно указывать в диапазоне.
Открываем файл дампа в хекс-редакторе. Вводим в поиск, что нужно искать, а именно кусок хекс-кода MSID: 4D535053, что в буквенном выражении означает первые четыре аббревиатуры MSPS(NY0/DK0/XX0), то есть, это часть 16-значного ключа MSID, которая у всех карт памяти MS PRO DUO одинаковая.
Скриншот MSID
Это логическая область с MSID, снятая программой MSID Dumper, сохраняющаяся в корне карты памяти в файл. По структуре она не имеет ничего общего с настоящей областью MSID, которая находится в физическом чипе памяти.
Требуется только для определения номера MSID для поиска в сыром RAW-дампе ципа карты памяти.
Не путать с оригинальным RAW-дампом(снятым программатором)!
Так выглядет оригинальная сервисная область MSID, сдампленная программатором.
Обратите внимание, что она выглядет совсем иначе, нежели на первом рисунке, снятом программой для PSP - "MSID Dumper".
В стартовом секторе содержится серийный номер и MSID.
Далее идут 3 пустых сектора, полностью заполненных FFFFFFFF.
Затем идёт сектор, где указывается фрмат и размер карты памяти.
Yokel, ты рассматриваешь код в 16-ричном редакторе в 16 столбиков или в 17?
Может у тебя просто контроллёр другой или память.
Я рассматриваю тот, что в шапке с контроллёром UD1F.
Хотя во многих дампах видел тоже самое, но может быть и по другому, смотря какая геометрия.
Кстати, мы с gregorio ночью всё-таки провели эксперимент по заливке данных через USB.
Сейчас только вот получили данные и рассматриваем. Результат потом огласим.
Но сдаётся мне, уже при беглом просмотре, что в ECC не участвуют первые 6 байт.
Yokel, ты рассматриваешь код в 16-ричном редакторе в 16 столбиков или в 17?
Может у тебя просто контроллёр другой или память.
Я рассматриваю тот, что в шапке с контроллёром UD1F.
Хотя во многих дампах видел тоже самое, но может быть и по другому, смотря какая геометрия.
Кстати, мы с gregorio ночью всё-таки провели эксперимент по заливке данных через USB.
Сейчас только вот получили данные и рассматриваем. Результат потом огласим.
Но сдаётся мне, уже при беглом просмотре, что в ECC не участвуют первые 6 байт.
Контроллер у меня такой же как у тебя! Вот тебе служебка: 00 07 00 FD FF FF 62 38 0F 4B 50 04 3B F4 83 5E
Контроллер у меня такой же как у тебя! Вот тебе служебка:
00 07 00 FD FF FF 62 38 0F 4B 50 04 3B F4 83 5E
О_о у меня в дампе такого нет. У меня встречаются или 00 или FF.
Хотя может я напутал, может 5-ый байт отвечает.
Просто вчера рылся по документациям и в нескольких местах встречал раскладку по байтам, как оно должно быть.
У меня в основном в таком виде все сектора помечены:
Простите, что вмешиваюсь.
Вот еще занятная штука, хотя может уже видели. http://www.elnec.com/sw/an_elnec_nand_flash.pdf http://www.elnec.com/sw/samsung_ecc_...m_for_512b.pdf
В последнем документе расписывается структура 16-байтного ECC для 512-байт блоков.
1,2,3 байты - номер блока
4, 5 - зарезервировано
6 - метка бэд-блока
7,8,9 - ECC code for Main area data, алгоритм вычисления тоже описан
10, 11 - ECC code for LSN data (ECC для номера блока) - заметьте, вычисляется отдельно и независимо от основных данных. Здесь уже предлагалось записать на карточку блок с нужными данными и подсмотреть его ECC, не прокатило - но что если здесь так же, то есть надо заменять не весь ECC а часть отвечающую за именно данные в блоке?
12-16 - зарезервировано.
с другой стороны, это только пример, и то от самсунга. Еще там написано что это для 64м-1гб нандов, для 2гб алгоритм может быть другим.
Другие консоли: XBOX 360, PlayStation®3 500Gb 3.55
Регистрация: 30.01.2007
Адрес: Москва
Возраст: 32
Сообщений: 626
Вы сказали Спасибо: 208
Поблагодарили 162 раз(а) в 119 сообщениях
Сила репутации: 1
Репутация: 172 (весьма и весьма положительная личность)
но в итоге ECC пересчитался по новому) карта работает, есть косяки из-за ее происхождения(это всё-же китайское Г), надо попробовать на оригинале. буду переделывать проггер под BGA нанды, на днях опробую технологию на оригиналах. и надеюсь во второй раз всё получится
но в итоге ECC пересчитался по новому) карта работает, есть косяки из-за ее происхождения(это всё-же китайское Г), надо попробовать на оригинале. буду переделывать проггер под BGA нанды, на днях опробую технологию на оригиналах. и надеюсь во второй раз всё получится
Но сдаётся мне, уже при беглом просмотре, что в ECC не участвуют первые 6 байт.
Нет, всё не так. Видать всю ночь сидели с gregorio и уже галюники пошли.
Сегодня выспался и заново рассмотрел, что мы там нахимичили.
В общем структура данных сервисной области такая:
Сначала идёт сектор с самим MSID
Следом идут 3 сектора, полностью забитых FFFFFFFF
Затем идёт сектор с PID|VID+Размер(4Гб)+Формат_FAT(32)
То есть, структура идёт по формуле 1+3 - один сектор первичный, затем 3 вторичных сектора, потом опять первичный и 3 вторичных. И так вся карта.
Как мы знаем, 4 сектора - это одна страница. Вот и получается постраничная организация.
У Гриши попалась такая хитрая карта на 4 Гб, что в области MSID избыточные данные не имеют нумерации блоков. Там первые 4 байта просто FF FF FF FF, затем 2 байта FF FF и далее идёт 10 байтов ECC.
В общем, процесс происходил в следующем порядке:
Отпаяли микросхему памяти.
Сняли программатором дамп первого Банка(их там 4 Банка по 1 Гб).
Физический размер дампа вышел 1,03 ГБ (1 107 296 256 байт), что оказалось как бы больше размера, заявленного производителем. Но, если взяться за арифметику, то выясняется, что эта разница как раз составляет эти 16 байт избыточного кода, приклеиваемого к каждому сектору. А логический размер, без избыточного кода, вплоть до байтика равен ровно 1 Гб (1 073 741 824 байт).
Сохранили эти 5 служебных секторов с MSID/3хFFFFFFFF/PID|VID... отдельно
Удалили у каждого сектора служебку с ECC - по 16 байт. Правда 3 сектора по FFFFFFFF не имеют контрольной суммы, но избыточный код всё равно присутствует, просто все 16 байт тоже забиты FF-ками, поэтому конечно же тоже избавляемся от него. Собственно нас интересует только один сектор, где предположительно требуется смена MSID, но, для полноты эксперимента, забираем все 4 сектора + 5ый сектор, содержащий PID|VID|Format|Size
В итоге получилось 5 чистых логических секторов ровно по 512 байт.
Затем, имея в виду, что один блок содержит 256 секторов по 512 байт каждый - подсчитываем размер блока = 131072 байт.
Ложим эти 5 секторов в начало блока и забиваем оставшиеся 251 секторов блока символом "X" (58 в хексе) для наглядности. Таким образом у нас получился один цельный логический блок, размером 131072 байт (без ECC конечно)
Теперь копируем и размножаем этот шаблон блока до размера первоначально снятого дампа - 1,03 ГБ (1 107 296 256 байт). С размером умышленно переборьщили, рассчитывая на то, чтобы полностью переписался первый банк и чтобы не мешал оставшийся мусор, учытывая, что контроллёр сам подсчитает к каждому сектору свои 16 байт избыточного кода.
Таким образом, начало каждого блока у нас начинается с этих 5 секторов с MSID и далее забит просто "X-ами". Это делалось специально для того, чтобы проверить, действительно ли ECC меняется в каждом блоке.
Припаяли микросхему обратно на карту памяти, ничего не меняя в ней.
Подключаем по USB и заливаем этот файл Blank.bin, весом более 1 Гб в корень карты, с надеждой на то, что весь 1-ый Банк заполнится и останется без лишнего мусора.
Потом опять отпаиваем микросхему и снимаем дамп.
Проверяем и видим, что действительно в каждом блоке ECC меняется в виду того, что первые 4 байта имет нумерацию этого блока. С другой стороны, нумерация блока проставляется только в каждом первом секторе, каждой страницы. НО!!! В остальных 3-ёх секторах страницы нумерация в первых 4-ёх байтах отсутствует, но отлична от FF FF FF FF, там выставлено EF FF FF FF (а это печально, потому что мы могли бы подсчитывать ECC к MSID сектору). И таким образом, ECC у младших 3-ёх секторов по всему дампу одинакова, не зависимо от номера блока.
Вот этот заново снятый дамп, после заливки по USB поблочного файла. (Осторожно! после разархивации 1 Гб)
Можете сами посмотреть структуру и как сменяется ECC в зависимости от нумерации блока.
Итог:первые 4 байта избыточного кода - участвуют в формировании контрольной суммы ECC.
Потом я снял дамп со своей карты памяти с микрухой HY27UY08AG5M и контроллёром 0805-0
Но у меня первые 4 байта в системной области всё-таки пронумерованы.
Зато ECC не содержит нигде!
Скриншот
Последний раз редактировалось ErikPshat; 28.11.2011 в 20:27.
Другие консоли: XBOX 360, PlayStation®3 500Gb 3.55
Регистрация: 30.01.2007
Адрес: Москва
Возраст: 32
Сообщений: 626
Вы сказали Спасибо: 208
Поблагодарили 162 раз(а) в 119 сообщениях
Сила репутации: 1
Репутация: 172 (весьма и весьма положительная личность)
Yokel, а тебе оно надо? эти карты уже не найдёшь, я об этом позаботился) я-же когда их пытался делать, скупал сотнями.. и не только по Москве, по всей России и Украине собирал) так что практически не вариант..
ну а если вдруг всё-же захочешь, всю инфу дам через асю/скайп
Кстати, контроль ECC как-то можно отключать. Читал на той неделе на сайте Тошибы, там прилагается какой-то файл патча, который отключает генерацию и проверку ECC.
Думаю на картах других производителей имеется свой метод.
06.07.2011, 04:21
(31)
Линейный вид
![C чего начать? ⇒ ⇒ ⇒ [ЧАВО] - ответы на ЧАсто задаваемые ВОпросы](../forum/images/panel_start.png "C чего начать? ⇒ ⇒ ⇒ [ЧАВО] - ответы на ЧАсто задаваемые ВОпросы")
