Боря, ты не понял, переписать стикид не фокус,
главное знать где в нем нанд-ресы а где продуктор-ид,
который возможно и отличает сервисный стик.
prx закриптованны с использованием MSID....когда мэтьюху дали MSID от сервисного, он декриптил с помощью него сервисные prx.....тут и так думаю ясно ...
стик ид не маленький, каким куском декриптили..))
кодов запуска от першингов там никто не наковырял?..))
Последний раз редактировалось lport3; 14.04.2010 в 23:27.
lport3, Фома неверующий вот тебе данные стика SN: 0024732B
ID: 204D53505344B30001CD387000000000.....этого достаточно?
каким куском декриптили ..это вопрос к мэтьюху...
Boryan добавил 14-04-2010 в 23:46
вот ещё несколько для анализа
204D5350534E59300079A800056F0000
204D5350534E5930006000EF95D70000
204D5350534E593000788884C6AA0000
204D5350534E59300078490000000001
204D53505344B30001CD387000000000
Последний раз редактировалось Boryan; 14.04.2010 в 23:47.
Причина: добавил, подумав
Boryan, Так, хорошо, теперь я верю в то, что msid нужен.
Стоп, так получается он раскриптовал prx с использованием msid! Почему же просто не закриптовать с помощью другого msid? Емае зачем такие сложности с подменой msid? когда можно проще простого взять и закрптовать с помощью оригинального msid другой MS PRO DUO?
Думайте перед тем, как говорить. Хотя если наоборот, то лучше вообще не думать.
chel12, Друг ты далёк от истины для того что бы закриптовать нужно знать алгоритм....а его ни кто не знает.....задай поиском на этом форуме "кирк" и поймёшь что это такое вот с помощью кирка делают декрипт....кирк -это чёрный ящик...модуль для декриптовки...что в нём и во какому алгоритму он работает ...ни кто не знает....
сдох потому что я лох при прошивке нанда прогер попросил стереть микруху, есно не всю, а тот блок с которым я работал....ну я разрешил...он и затёр FF...и теперь некоторые ячейки память так и остались FF, он туда записать ни чего не может....так мало того, я не понимаю.. пишу в нанд, а затем считываю с него то что записал....сраниваю с исходником....всё смещено на 4 байта....
ну вот можно на ней пока экспериментировать научиться туда писать правильно (в другие блоки).. я уж думал она совсем физически сдохла..
pronvit добавил 15-04-2010 в 00:19
Сообщение от chel12
Boryan, Вопрос, а не быстрее ли раскрыть алгоритм кирка, чем ломать голову над подменой msid?
ну так вперед) все только за будут, потому что это решит ВСЕ проблемы.
pronvit добавил 15-04-2010 в 00:22
Сообщение от GVr
Чексумму контроллер должен считать, и скорее всего одинаково для любых нандов.
для нандов для всех одинаково, а вот контроллеры разные могут по-разному. а так как если в другой флешке будет другой нанд, то и контроллер скорее всего тоже, то...
Сообщение от GVr
Чтобы определить "где в этих 16 байтах сидит инфа о контрольной сумме" нужен дамп со случайными данными(не только 00 или FF).
не так просто. там были блоки с одинаковыми данными, но разными этими 16 байтами. единственное объяснение, которое я могу придумать, это что первые байты это инфо о блоке типа адреса или что-то такое, а сумма считается от самого блока и этих данных тоже. но с другой стороны там есть блоки, в которых и данные и эти 16 байт одинаковые, значит, там не адрес...
Последний раз редактировалось pronvit; 15.04.2010 в 00:22.
Причина: добавил, подумав
Скиньте пару prx encr.,decr. и msid желательно,
попробую пробрутить парой криптов. Если размер не
изменяется, не должно быть сложно. Файлы желательно
маленькие jigkick_bridge например.
В программе edecript что за крипт применяется
известно?
Скиньте пару prx encr.,decr. и msid желательно,
попробую пробрутить парой криптов. Если размер не
изменяется, не должно быть сложно. Файлы желательно
маленькие jigkick_bridge например.
В программе edecript что за крипт применяется
известно?
да ничего не получится. это все через kirk идет, а чего он внутри делает - никада не пробрутишь и не догадаешься..
не так просто. там были блоки с одинаковыми данными, но разными этими 16 байтами. единственное объяснение, которое я могу придумать, это что первые байты это инфо о блоке типа адреса или что-то такое, а сумма считается от самого блока и этих данных тоже. но с другой стороны там есть блоки, в которых и данные и эти 16 байт одинаковые, значит, там не адрес...
В принципе ИМХО правильное предположение.
Пример расчета этих 16 байт есть здесь. У нас LSN тоже имеет место быть, но структура иная и RESERVED области тоже юзаются.
Сообщение от Boryan
вопрос в том, что по даташиту на эту микруху в странице 4 блока по 512 байт+16 байт служебной инфы и контрольная сумма этой страницы. Выглядит это так: 512+512+512+512+16+16+16+16 то есть в начале 4 блока по 512 а далее 4 блока по 16 байт....но это всё по даташиту....а в реале мы имеем структуру отличную от рекомендуемой 512+16+512+16+512+16+512+16
Этот момент тоже не понятен, хотя на 18 стр.: " To make EDC valid, the page program operation
should be performed on either whole page(2112byte) or sector(528byte)." ...
A 2,112-byte page is composed of 4 sectors of 528-byte and each 528-byte sector is composed of 512-byte main area and 16-byte
spare area.
и дальше:
Table 2. Definition of the 528-Byte Sector
Т.е. там есть понятие сектор 512 + 16. Возможно считываются данные посекторно?
Сообщение от Boryan
странно что многие 16 байт блоки похожи как близнецы.....
Например один логический сектор(LSN термин опять же отсюда) и одинаковые данные - результат одинаковые контрольные суммы.
Сообщение от Boryan
и ещё после нескольких страниц может быть блок большого размера, вообще без опознавательных признаков и этих 16 байт в конце....Что это за блоки? Они все заполнены кодом FF....это что резервные блоки?
Неиспользуемые страницы. В них ничего не писали - соответственно и служебные 16 байт тоже "чистые". Возможно и резервные, т.к. насколько я понял в NANDе допускаются "бэды", и для сохранения объема должен быть какой-то резерв. С завода чип скорее всего идет весь FF-ками заполненый, только в каком-то блоке какая-то служебная инфа записана (msid и др.).
По поводу Hynix: Вот даташит на микруху HY27UH08AG5M.
Отличия от твоей: HY27UH08AG5M - SLC, HY27UF08AG5M - MLC. Не думаю, что для конечного пользователя есть какие-то отличия в использовании (кроме цены). Тут даже кое-что на русском по NANDу.
Последний раз редактировалось Klerikus; 15.04.2010 в 13:01.
Причина: Добавлены ссылки
Тааак, Вас уже не туда понесло.
Тему закрываем ввиду безперспективности, по словам самого автора, работ в данном направлении.
Если у Вас появятся свежие идеи, сообщайте в ЛС - откроем)