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.
Затем идёт сектор, где указывается фрмат и размер карты памяти.
ErikPshat, дык, давай просчитать попробуем. Дай ка мне секторок с родным msid и его хешик. Всё отдельно, секторок без избыточного кода и только его! и хешик тоже отдельно в первоначальном виде.
Всё отдельно, секторок без избыточного кода и только его! и хешик тоже отдельно в первоначальном виде.
Ты не можешь отличить обычный Сектор от ECC (избыточного кода)?
Каждый сектор в RAW идёт по формуле 512+16.
Когда мы подключаем карту по USB, то контроллёр эти 16 байт ECC не выдаёт, а даёт файл по порядку 512+512+512+... .
А в сыром дампе мы видим не только 512 байт сектора, но и котрольную сумму у каждого сектора.
То есть, мы считываем сырой RAW-дамп программатором напрямую с микросхемы памяти, минуя контроллёр.
Если в дампе присутствуют FFFFFFFF и через каждые 512 байт отсутствует контрольная сумма, значит это место просто пустое, а на пустое место ECC не рассчитывается.
Ну вот, думаю посмотрев на картинку ты всё-таки сумеешь в хексе отсчитать 512 байт и увидеть 16 байт ECC в конце каждого сектора
0x200 + 0x10
Нужно вычислить/найти алгоритм подсчёта этой контрольной суммы на сектор.
Собственно там первые 4 байта указывают на порядковый номер блока, к которому относятся сектора.
Все сектора одного блока имеют этот номер одинаковый.
Блок не может быть разделимым, т.е. не может полблока находиться в одном месте, а другая часть в другом. Он всегда пишется непрерывно.
После 4-ёх байт, ещё идут 2 байта FFFF
Остальные 10 байт и есть контролка.
Сохранить сектор 512 байт с изменённым MSID, без контролки, в бинарный файл.
Припаять микросхему обратно.
Сделать соединение по USB.
Записать бинарный файл на карту памяти в корень.
Отпаять микросхему.
Снять дамп.
Найти этот файл.
Файл то 512 байт, он ровно ляжет в один сектор. Контроллёр сам подсчитает и запишет контрольную сумму на этот сектор. Там только первые 4 байта контролки будут иметь не тот порядковый номер блока.
Записать этот сектор в исходный дамп, с правильной контролкой и нужным MSID, оставив родные первые 4 байта оригинала.
Прошить микросхему и впаять на место.
Сектор с изменённым MSID должен стать легитимным.
Все файлы, программы, музыку, видео, картинки, которые мы копируем по USB на карту памяти логическим способом (обывательски), мгновенно контроллёр пишет в свободные места по порядку и на каждый сектор 512 байт тут же подсчитывает контрольную сумму сам с порядковым номером блока.
Если файл не помещается целиком в свободное место, то контроллёр пропускает это место и пишет в следующее свободное место.
Занятые места посреди карты образуются, если мы заполняем карту памяти до середины или до конца, к примеру, а затем удаляем файлы, записанные ранее. Таким образом, в начале освобождается место, а файлы, записанные позднее, остаются в конце или середине карты памяти.
Последний раз редактировалось ErikPshat; 30.10.2011 в 12:27.
ErikPshat, постой, не развивай тему... кажись получилось... я там с одним челом сижу, щас он занят, потом ещё попробуем. Мало того, нашёлся способ программно это делать на SD'шках, надеюсь на MS'ках также выйдет. Перелазь в девелоперскую.
Можно поступить по другому:
...
(13) Сектор с изменённым MSID должен стать легитимным.
ErikPshat, увы не станет.
Что по сути такое [ЕСС]?
Код ЕСС - код коррекции ошибок. Иными словами это СRC с ограниченной возможностью коррекции содержания по которому он высчитан.
Сектор представляет из себя [данные] + [служебка].
Точнее сказать, [данные] + [служебка контроллера] + [код ЕСС].
Код [ЕСС] защищает не только [пользовательские данные], но и [служебку контроллера]. В частности, [служебка контроллера] - хранит номер блока в банке, ротацию блока и еще бог знает какие служебные биты-флаги.
Поэтому выше предложенный способ не сработает.
Сектор, имеющий одно и то же содержание пользовательских данных, будучи записанным в разные места через стандартный интерфейс, имеет разную [служебку контроллера] и следовательно разный [код ЕСС] (высчитанный из [пользовательских данных] + [служебки контроллера]).
Не зря же пишут:
ECC Code: 512 / 7 / SM325QF AC
Sector: 519/9
или
ECC Code: 514 / 13 / Memory Stick 7
Sector: 527/1
Замете, размер сектора везде 528 (512+16), а вот код ЕСС защищает разное количество байт на странице.
(10) Файл то 512 байт, он ровно ляжет в один сектор. Контроллёр сам подсчитает и запишет контрольную сумму на этот сектор. Там только первые 4 байта контролки будут иметь не тот порядковый номер блока.
это очень зависит от контроллера, точнее от алгоритма по которому он хранит данные в доступном ему пространстве памяти.
Последний раз редактировалось Erema36; 31.10.2011 в 09:56.
Что по сути такое [ЕСС]?
Код ЕСС - код коррекции ошибок. Иными словами это СRC с ограниченной возможностью коррекции содержания по которому он высчитан.
Сектор представляет из себя [данные] + [служебка].
Точнее сказать, [данные] + [служебка контроллера] + [код ЕСС].
Код [ЕСС] защищает не только [пользовательские данные], но и [служебку контроллера]. В частности, [служебка контроллера] - хранит номер блока в банке, ротацию блока и еще бог знает какие служебные биты-флаги.
Поэтому выше предложенный способ не сработает.
Сектор, имеющий одно и то же содержание пользовательских данных, будучи записанным в разные места через стандартный интерфейс, имеет разную [служебку контроллера] и следовательно разный [код ЕСС] (высчитанный из [пользовательских данных] + [служебки контроллера]).
По моему ты слишком много читаешь детективов )))
Это же ECC - просто проверка целостности данных, но это не относится к шифрованию.
Представляешь, записав только один единственный файл, во сколько секторов он ляжет?
А если это куча файлов или один большой файл?
Если рассуждать по твоему, то получается, чтобы произвести чтение карты памяти или запись, то на вычисление ECC к каждому сектору уйдёт масса времени, от которого зависят характеристики карт памяти на скорость чтения/записи, которыми хвалится каждый производитель и соревнуются между собой.
На этом основании покупатели и делают вывод, какого производителя купить карту памяти.
Здесь всё обстоит намного проще.
Каждый сектор просто-напросто проверяется операцией XOR и всё!
На основании заранее заданоого сида, с помощью XOR вычисляется код этого сектора 512 байт.
Если на основании СИДА, с помощью операции XOR, получается другое значение, отличное от имеющегося, значит сектор считается фейковым.
Сообщение от Erema36
Не зря же пишут:
ECC Code: 512 / 7 / SM325QF AC
Sector: 519/9
Всё правильно. На Memory Stick, как правило ставятся контроллёры, которые форматируют карту на основании геометрии 512 + 16 = 528
Я уже разбирался с этим вопросом и вычислил, что 16 байт избыточного кода содержит:
Первые 4 байта - адресацию блока. Но цифра по моему перевёрнута, т.к. если эти байты превратить в децимальную цифру, то встречаются такие цифры, что столько блоков просто не может поместиться в память.
Следующие 2 байта - FFFF или 0000. То есть, я так думаю пустой резерв или разделение кода.
Остаётся 10 байт - это и есть контроль ECC - XOR u16 Bit Unsigned Short. То есть, эти 10 байт со здвигом переворачивают каждые 16 бит (2 байта) кода из этих 512 байт сектора.
Отсюда, в случае с рассматриваемым нами контроллёром, представленным в шапке, геометрия идёт так:
Если не понятно, то я чуть позже более подробнее объясню, как производится операция XOR на примере сектора MSID.
Кстати, это уже вопрос к нашим программистам Yoti и Frostegater: здесь я нашёл код вычисления ECC
У нас есть дампы памяти, где как раз есть области, полностью забитые одинаковым кодом FFFF FFFF FFFFF FFFF
И у такого сектора есть 10-значный код ECC.
То что код имеет структуру u16 Bit Unsigned Short - я уже 100% вычислил и полностью уверен в этом.
Так что можно найти SEED - код преобразования XOR.
P.S. За основу берём этот дамп: https://www.pspx.ru/forum/showpost.ph...&postcount=283
Там есть оригинальный дамп сектора MSID под названием "07FFC4 - MSID Page Original (1 Page = 4 Sectors).bin"
Это неизменённый натуральный дамп, с которым можно работать.
А файл "07FFC4 - MSID Page Changed (1 Page = 4 Sectors).bin" - это тот же самый, только я туда вписал сам MSID от сервисной карты. Ессно ECC осталось прежним. Вот туда нужно подсчитать новый легитимный ECC.
Последний раз редактировалось ErikPshat; 31.10.2011 в 11:09.
Ну чтобы было более понятно, о чём я говорю и что есть на самом деле, то предлагаю, в качестве подсказки, небольшую элементарную задачку:
Вот вам задачка... Кто решит, тому +1 )))
Прилагаю отксоренный файл во вложении.
Предлагаю его попробовать посмотреть в блокноте, в Hex Workshop и убедиться, что там ничего читабельного нет.
Ваша задача:на основе SEED'a, записанного по формуле 512/10 восстановить данные в 512 байтах сектора.
Результат можете выложить здесь в спойлер в теге CODE.
Воспользуйтесь функцией вывода - "File => Export => Text (*.txt)"
Текстовой редактор советую использовать EmEditor, т.к. Блокнот показывает результат не форматированным.
P.S. Надеюсь, с помощью этой задачки вы поймёте, что записано в секторе MSID в шапке, вместо вопросиков ???????????
Задача №2: что написано в секторе оригинального MSID вместо вопросиков в шапке?
Кстати, это уже вопрос к нашим программистам Yoti и Frostegater: здесь я нашёл код вычисления ECC
-Artix 20:45, 15 января 2011 (UTC)
Шифр XOR - очень плохой шифр, потому что если в исходной последовательности встречается длинная цепочка одинаковых символов - ключ шифрования вылетает в выходной поток в чистом или почти чистом виде. Поэтому ломается такой шифр за 1 минуту. Соответственно, программа, демонстрирующая суть метода, а также наглядно показывающая как в шифрованном потоке возникают повторения ключа, применима только в ознакомительных и учебных целях - и никогда в практических. В общем, не используйте XOR и деление по модулю в качестве шифров.
Написано на этой страничке прямым текстом.
Понял. Понял. Извиняюсь.
Схожу за попкорном и Колой. Устраиваюсь поудобнее за своими двумя мониторами
Скажу больше, в XOR-е принимают участие только первые 2 байта ECC. Остальные 8 байт несут ещё какие-то функции.
ErikPshat, XOR - это маска, накладываемая на блок целиком.
Изначально, маска не может осуществлять функцию коррекции битовых ошибок. Она лишь может выполнять функцию контроля целостности данных.
XOR применяется во флешках для уменьшения взаимовлияния винтелей памяти при большей их плотности. Особенно этим заморачивается Тошиба и СанДиск.
То что Вы увидели пустые сектора без маркера, но имеющие какой-то [код ЕСС], объясняется тем, что контроллер во время операций записи не желает тратить время на стирание сектора. Он подготавливает очередь заранее, очищая сектора.
Так же он знает, что [код ЕСС] ему писать в сектор по любому. Зачем тогда его очищать? Правильно не нужно. Нужно подготовить сектора так, чтобы туда по-быстрому все записать, а именно забить его [FFFFFFFF] или [яяяяяяяя] и затем записать только измененые байты.
Для ускорения этого процесса в SSD придумали команду /trim .
То что Вы увидели пустые сектора без маркера, но имеющие какой-то [код ЕСС]
Не какой-то код, а это именно сгенерированный код контрольной суммы для сектора полностью забитого этими FFFF FFFF FFFF FFFF.
Можно проследить, что он у всех секторов с такими данными одинаковый.
В некоторых местах отсутствует контрольная сумма, это потому, что сектор совсем не используется. Но если у пустого сектора есть контрольная сумма, значит, пусть даже он и пустой, но он используется и воспринимается, как часть реальных данных.
Это всё можно так же проследить в nand-dump-ах, где например IPL в конце заполнен пустыми блоками FFFF, но с контрольными суммами. И IPL дампится и пишется именно со всеми этими блоками. Однако, где данные идут без ECC, эта часть отрезается.
Ну я так понял задачки вы не решили )))
Yokel, отлично! Всё верно, у тебя первого получилось из непонятного кода извлечь читабельный код из песни Эминема
2 ответ тоже верный - там вначале сектора MSID закодирован алфавит.
И это подтверждает, что данные верны, т.к. мы получили строго закономерную и читабельную последовательность, значит первые 2 байта из 10-значного ECC отвечают за операцию XOR.
Если даже просмотреть XOR в u8 или u32, то мы увидим тоже вроде читабельный код, но там сразу понятно по хаотичности данных, что это не верный код. Верный код мы видим именно в u16.
думаю реверсить все алго ЕСС лишено смысла да это и понятно нужно выбрать 1 кролика и под него сделать пересчет ECC кому надо найдет кролика по описанию
P.S.
как раз начал смотреть где взять и какой тулчейн надо юзать под сборку дампера.
06.07.2011, 04:21
(31)
Линейный вид
![C чего начать? ⇒ ⇒ ⇒ [ЧАВО] - ответы на ЧАсто задаваемые ВОпросы](../forum/images/panel_start.png "C чего начать? ⇒ ⇒ ⇒ [ЧАВО] - ответы на ЧАсто задаваемые ВОпросы")
