ErikPshat, дык, давай просчитать попробуем. Дай ка мне секторок с родным msid и его хешик. Всё отдельно, секторок без избыточного кода и только его! и хешик тоже отдельно в первоначальном виде.
|
Цитата:
Каждый сектор в RAW идёт по формуле 512+16. Когда мы подключаем карту по USB, то контроллёр эти 16 байт ECC не выдаёт, а даёт файл по порядку 512+512+512+... . А в сыром дампе мы видим не только 512 байт сектора, но и котрольную сумму у каждого сектора. То есть, мы считываем сырой RAW-дамп программатором напрямую с микросхемы памяти, минуя контроллёр. Если в дампе присутствуют FFFFFFFF и через каждые 512 байт отсутствует контрольная сумма, значит это место просто пустое, а на пустое место ECC не рассчитывается. Короче, скачай вот этот мой дамп: https://www.pspx.ru/forum/showpost.ph...&postcount=244 Вложи его во вложение, потому что я сам не могу его скачать оттуда, постоянно крутится индикатор загрузки и всё тут. А я тебе выложу скрин, чтобы наглядно показать строение дампа. |
Вложений: 1
...
|
Ну вот, думаю посмотрев на картинку ты всё-таки сумеешь в хексе отсчитать 512 байт и увидеть 16 байт ECC в конце каждого сектора :D
0x200 + 0x10 Нужно вычислить/найти алгоритм подсчёта этой контрольной суммы на сектор. Собственно там первые 4 байта указывают на порядковый номер блока, к которому относятся сектора. Все сектора одного блока имеют этот номер одинаковый. Блок не может быть разделимым, т.е. не может полблока находиться в одном месте, а другая часть в другом. Он всегда пишется непрерывно. После 4-ёх байт, ещё идут 2 байта FFFF Остальные 10 байт и есть контролка. Скриншот Можно поступить по другому:
Если файл не помещается целиком в свободное место, то контроллёр пропускает это место и пишет в следующее свободное место. Занятые места посреди карты образуются, если мы заполняем карту памяти до середины или до конца, к примеру, а затем удаляем файлы, записанные ранее. Таким образом, в начале освобождается место, а файлы, записанные позднее, остаются в конце или середине карты памяти. |
ErikPshat, постой, не развивай тему... кажись получилось... я там с одним челом сижу, щас он занят, потом ещё попробуем. Мало того, нашёлся способ программно это делать на SD'шках, надеюсь на MS'ках также выйдет. Перелазь в девелоперскую.
|
|
Yokel, и все побежали покупать Flash Extractor =)
|
Цитата:
Что по сути такое [ЕСС]? Код ЕСС - код коррекции ошибок. Иными словами это СRC с ограниченной возможностью коррекции содержания по которому он высчитан. Сектор представляет из себя [данные] + [служебка]. Точнее сказать, [данные] + [служебка контроллера] + [код ЕСС]. Код [ЕСС] защищает не только [пользовательские данные], но и [служебку контроллера]. В частности, [служебка контроллера] - хранит номер блока в банке, ротацию блока и еще бог знает какие служебные биты-флаги. Поэтому выше предложенный способ не сработает. Сектор, имеющий одно и то же содержание пользовательских данных, будучи записанным в разные места через стандартный интерфейс, имеет разную [служебку контроллера] и следовательно разный [код ЕСС] (высчитанный из [пользовательских данных] + [служебки контроллера]). Не зря же пишут: ECC Code: 512 / 7 / SM325QF AC Sector: 519/9 или ECC Code: 514 / 13 / Memory Stick 7 Sector: 527/1 Замете, размер сектора везде 528 (512+16), а вот код ЕСС защищает разное количество байт на странице. ================================================================================ =============== Цитата:
|
Цитата:
Это же ECC - просто проверка целостности данных, но это не относится к шифрованию. Представляешь, записав только один единственный файл, во сколько секторов он ляжет? А если это куча файлов или один большой файл? Если рассуждать по твоему, то получается, чтобы произвести чтение карты памяти или запись, то на вычисление ECC к каждому сектору уйдёт масса времени, от которого зависят характеристики карт памяти на скорость чтения/записи, которыми хвалится каждый производитель и соревнуются между собой. На этом основании покупатели и делают вывод, какого производителя купить карту памяти. Здесь всё обстоит намного проще. Каждый сектор просто-напросто проверяется операцией XOR и всё! На основании заранее заданоого сида, с помощью XOR вычисляется код этого сектора 512 байт. Если на основании СИДА, с помощью операции XOR, получается другое значение, отличное от имеющегося, значит сектор считается фейковым. Цитата:
Я уже разбирался с этим вопросом и вычислил, что 16 байт избыточного кода содержит:
Код:
ECC Code: 512/10/ Memory Stick Hynix HY27UH08AG5M 2Гб; Контроллёр UD1FКстати, это уже вопрос к нашим программистам Yoti и Frostegater: здесь я нашёл код вычисления ECC
Цитата:
|
Цитата:
ErikPshat, где слова про шифрование? XOR я вообще как тему трогаю, т.к. в MS Pro он пока что не встречается. Тут линейный циклический код. Либо "Код Хемминга", либо "Рида — Соломона" http://ru.wikipedia.org/wiki/%D0%9E%...B1%D0%BE%D0%BA http://ru.wikipedia.org/wiki/%D0%9A%...BD%D0%B3%D0%B0 |
Вложений: 1
Ну чтобы было более понятно, о чём я говорю и что есть на самом деле, то предлагаю, в качестве подсказки, небольшую элементарную задачку:
Вот вам задачка... Кто решит, тому +1 ))) Прилагаю отксоренный файл во вложении. Предлагаю его попробовать посмотреть в блокноте, в Hex Workshop и убедиться, что там ничего читабельного нет. Ваша задача: на основе SEED'a, записанного по формуле 512/10 восстановить данные в 512 байтах сектора.
Результат можете выложить здесь в спойлер в теге CODE. Воспользуйтесь функцией вывода - "File => Export => Text (*.txt)" Текстовой редактор советую использовать EmEditor, т.к. Блокнот показывает результат не форматированным. P.S. Надеюсь, с помощью этой задачки вы поймёте, что записано в секторе MSID в шапке, вместо вопросиков ??????????? Задача №2: что написано в секторе оригинального MSID вместо вопросиков в шапке? Шапка |
Цитата:
Цитата:
Понял. Понял. Извиняюсь. Схожу за попкорном и Колой. Устраиваюсь поудобнее за своими двумя мониторами :) |
Скажу больше, в XOR-е принимают участие только первые 2 байта ECC. Остальные 8 байт несут ещё какие-то функции.
|
Цитата:
Изначально, маска не может осуществлять функцию коррекции битовых ошибок. Она лишь может выполнять функцию контроля целостности данных. XOR применяется во флешках для уменьшения взаимовлияния винтелей памяти при большей их плотности. Особенно этим заморачивается Тошиба и СанДиск. То что Вы увидели пустые сектора без маркера, но имеющие какой-то [код ЕСС], объясняется тем, что контроллер во время операций записи не желает тратить время на стирание сектора. Он подготавливает очередь заранее, очищая сектора. Так же он знает, что [код ЕСС] ему писать в сектор по любому. Зачем тогда его очищать? Правильно не нужно. Нужно подготовить сектора так, чтобы туда по-быстрому все записать, а именно забить его [FFFFFFFF] или [яяяяяяяя] и затем записать только измененые байты. Для ускорения этого процесса в SSD придумали команду /trim . |
Задача 1.
Код:
00000000 53 74 69 6C 6C 20 64 6F 6E 27 74 20 47 69 76 65 20 41 20 46 75 63 6B 0D 0A 28 45 6D 69 6E 65 6D Still don't Give A Fuck..(Eminem |
Цитата:
Можно проследить, что он у всех секторов с такими данными одинаковый. В некоторых местах отсутствует контрольная сумма, это потому, что сектор совсем не используется. Но если у пустого сектора есть контрольная сумма, значит, пусть даже он и пустой, но он используется и воспринимается, как часть реальных данных. Это всё можно так же проследить в nand-dump-ах, где например IPL в конце заполнен пустыми блоками FFFF, но с контрольными суммами. И IPL дампится и пишется именно со всеми этими блоками. Однако, где данные идут без ECC, эта часть отрезается. Ну я так понял задачки вы не решили ))) Yokel, отлично! Всё верно, у тебя первого получилось из непонятного кода извлечь читабельный код из песни Эминема :D 2 ответ тоже верный - там вначале сектора MSID закодирован алфавит. И это подтверждает, что данные верны, т.к. мы получили строго закономерную и читабельную последовательность, значит первые 2 байта из 10-значного ECC отвечают за операцию XOR. Если даже просмотреть XOR в u8 или u32, то мы увидим тоже вроде читабельный код, но там сразу понятно по хаотичности данных, что это не верный код. Верный код мы видим именно в u16. |
Можно пересобрать "MSID Dumper 3.XX" чтобы выводил на экран “Serial number” и MSProID а не только писал в файл ?
|
AndyI, можно переписать.. перепиши.. да и переписать легко.
Собсно вот! https://www.pspx.ru/forum/showpost.ph...&postcount=126 |
СПС за дампер.
думаю реверсить все алго ЕСС лишено смысла да это и понятно нужно выбрать 1 кролика и под него сделать пересчет ECC кому надо найдет кролика по описанию P.S. как раз начал смотреть где взять и какой тулчейн надо юзать под сборку дампера. |
AndyI, просьба воздержаться от "пустых" сообщений впредь.
|
есть прога http://www.ice-graphics.com/ICEECC/IndexR.html ICE ECC, ее автор (по мылу) утверждает что она может с этой задачей справиться, у меня пока не получилось, может еще кто потыкает!?
|
Есть брикнутая PSP-3008 c TA-93, возможно ли восстановление описанным выше методом? Стоит ли попробовать?
|
Arsenikum,
НУ СПЕЦИАЛЬНО НАПИСАНО В ТЕМЕ ДЛЯ :girl_crazy: И :to_become_senile:: Цитата:
|
Цитата:
|
Yoti, согласен, что конечно там никакой защиты нет.
Но это служебный сектор и по моему единственный, поэтому там содержится всё - и VendorID и PendorID и MSID и серийный номер, а соответственно, как обычно бывает во всех независимых областях, Алфавит с циферками. В данном случае, думаю это не случайный мусор, а вполне закономерные данные. Вот эта область в реале: [IMG]http://img526.**************/img526/6395/18112011185430.png[/IMG] И она после ксора (первые 2 байта ECC - D1BF): [IMG]http://img7.**************/img7/6981/18112011185404.png[/IMG] Это не сказать бы, что случайность. Вдруг всплыл алфавит, а за ним символы скобок, наклонной черты, знака ксора, знака подчёркивания... И причём такое появляется именно с этими двумя байтами D1BF. Но если в этих байтах поменять хоть одну циферку, то мы уже увидим действительно неупорядоченный мусор. Поэтому считаю, что это преобразование над первыми 64 байтами происходит не случайно. Думаю это матрица, которая может используется для восстановления данных. Это аналогично тому, что такие матрицы есть, например в BMP. Там все цвета лежат отдельно в матрице, и на её основе строится изображение. Такая же матрица существет во многих других форматах, например в GIF, JPEG, RAR, ZIP. На основе некой таблицы производится сжатие и восстановление информации. |
Цитата:
Цитата:
Я вполне мог опустить или упустить моменты, но самая база мне более-менее известна. |
Цитата:
|
А если контрольную сумму забить FFFFFFFF, может тогда контроллёр не будет сверять этот сектор/блок?
А ключ MSID может будет считываться. |
ErikPshat, очень в этом не уверен. хотя чисто ради прикола попробую, во вторник вечерком отпишусь
|
У кого есть карта памяти Lexar и шитая PSP - напишите в личку.
|
Цитата:
Yokel добавил 21.11.2011 в 06:40 Цитата:
|
Цитата:
|
Цитата:
|
Цитата:
|
Цитата:
Если сменить в секторе MSID, то ECC уже не будет соответствовать этому сектору, то есть, ECC уже будет не тот. А если сменть ECC на не тот, то сектор не будет соответствовать ECC. Таким образом, оригинальный ECC восстановит сектор к его прежнему значению. Изменённый ECC восстановит сектор к тому значению, по мнению которого должна быть такая ECC. |
в любом случае, до проггера доберусь и проверю, всё-равно время есть. да и еще пара идей на эту-же тему
|
Цитата:
|
Yokel, есть идея круче) подходящие карты используют тупые контроллеры. есть другие карты, которые используют точно такой-же алгоритм расчёта контрольной суммы, но намного умнее. вот как-раз на них и можно попробовать всё провернуть.
в любом случае в мск я вернулся только что, доберусь до проггера и буду пробовать |
Цитата:
|
Цитата:
|
| Текущее время: 06:48. Часовой пояс GMT +3. |
Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2025, vBulletin Solutions, Inc. Перевод: zCarot
PSPx Forum - Сообщество фанатов игровых консолей.