Boryan, Если честно, то мысль в теме плавно перешла от невозможности запустить пандора образ из СЦ на других картах, к другой мысли, о том, как подделать msid на карте памяти.
Кстати, я запутался. В какое время мы все пришли к выводу, что образ пандоры не работает из-за неправильного msid?

может мой пост не в тему будет, т.к. в хаке не силен. Но точно знаю, что хак по смене Volume ID карты на нужный есть (100% работает для SD карт и обычных USB-flash). Сам менял с помощью одного батника, который где-то откопал. Шел в комплекте с одной из версия The Bat Voyager v.4 (там именно привязка регистрации по ID флешки шла). Возможно он и для MS покатит.


PS. похоже ошибся - сейчас посмотрел - меняет 8-значный номер, а это по ходу не ID, a SN

Boryan, ну знаешь-ли... Ты разве можешь видеть, что творится в консоли во время загрузки с такой карты? Разве можешь видеть, чего не хватает и что считывается? Нет. Все, что было сказано выше - эмпирика и логические выводы. А я хочу, чтобы у тебя был инструмент, которым ты можешь непосредственно отследить ход загрузки, процесс проверки IPL и все прочее. Если тебе не надо - ну, кому-то другому пригодится.
P.S. - Мы здесь не буки. Знал-бы я ответы на твои вопросы - ответил бы уже давно...

Evolret, Он же объяснил, что нельзя подобраться к нанду из-за того, что он сопряжен с процессором, и следовательно нельзя отследить ход проверки ipl.

chel12, елки-палки, да я ничего не утверждаю. Работы, чтобы сделать такой хвост - пол-часа от силы. А пользы может быть очень много. Никого не заставляю, никому не навязываю. Надо будет - сделают и посмотрят.
chel12, ты сам понял вообще, про что я речь веду?

Да я помню тоже было такое. Когда на первых порах ломали прошивки, этим способом пользовались. Так что этот вариант тоже откидывать не стоит.

Через порт гарнитуры есть довольно секретные функции. Взять даже тот-же датчик наклона.

Боря, в дампе флехи сдвиг на MSID... По идее инфа о размере должна быть после MSID. Нехорошо это как то. При записи попасть будет сложнее. Нельзя ли полностью её перешить? и это случайность что ссылка на дамп оканчивается на 8888?

Alex14435, что-то я не понял, что куда сдвинуто? В дампе вроде все корректно.
Boryan, Сейчас пытаюсь разобраться с докой - писать нужно сразу всю страницу, т.е. 2К + 64 байт, Но мне пока не понятно как там на сектора все это дело делится. Кстати удавалось ли хоть что-то с помощью программатора записать или только читал?
У тебя точно Самсунговский чип?

В смысле начинается не с начала строки... И расположение не такое как в дампе MSID прогой. Могут быть проблемы с подменой

Alex14435, а чего она должна быть выровнена? Там записана какая-то структура служебных данных в том числе и msid. Перед msid в этой структуре были какие-то данные меньше 16 байт, вот она и не выровнена. Структура наверняка кратна 16 и пишется целиком, вот и все. Прогу я не смотрел еще, но там данные насколько я понимаю получаются через контроллер и необязательно структура служебных данных вычитывается "как есть".

Klerikus, С докой на микруху я уже разобрался ....работать с ней можно только блоками в коих 64 страницы. Программатор именно так и работает, блоками пишет и блоками читает. В нём и в настройках адресов начала и конца записи/чтения я могу минимум выставить только размер блока. Так что тут всё нормально. Переписать MSID уже не вопрос....вопрос в том, что по даташиту на эту микруху в странице 4 блока по 512 байт+16 байт служебной инфы и контрольная сумма этой страницы. Выглядит это так: 512+512+512+512+16+16+16+16 то есть в начале 4 блока по 512 а далее 4 блока по 16 байт....но это всё по даташиту....а в реале мы имеем структуру отличную от рекомендуемой 512+16+512+16+512+16+512+16....странно что многие 16 байт блоки похожи как близнецы.....и ещё после нескольких страниц может быть блок большого размера, вообще без опознавательных признаков и этих 16 байт в конце....Что это за блоки? Они все заполнены кодом FF....это что резервные блоки? Получается что вообще в этой флехе мешанина какая то....Мало того при смене редактировании MSID во флехе нужно заново подсчитать новую контрольную сумму и вписать её ...но вопрос куда в какие 16 байт....те что выше или ниже.....так как нарушена структура я не пойму какие 16 байт несут инфу о тех 512 байт блоке ...который под ними или над ними? И опять же где в этих 16 байтах сидит инфа о контрольной сумме?

Boryan добавил 14-04-2010 в 20:21
AVP-720, Кинь ссылку на прогу ...штука нужная...пригодиться.

Boryan добавил 14-04-2010 в 20:25
Вчера попробовал тупо изменил MSID и SN и залил обратно в нанд...прилепил его в стик ...ну и есно что и следовало ожидать...контроллер стика заметил не соответствие контрольной суммы той страницы где я ковырялся....и есно закрыл доступ к нанду. Короче флеха компом видется ..буква ей присваивается...но сделать с ней ни чего нельзя....Зыза её вообще не видит...Буду дальше ковырять...:)Нужно контрольную сумму менять на правильную...

Boryan добавил 14-04-2010 в 20:32
Evolret, да суть не в том что можно.....все хотят халявы....вкладываться в это дело ни кто не хочет....и уж тем более ковырять свою зызу ....Ты посмотри, кто тут реально занимается и пошёл на трату денег? Так пару человек рискнули....ну про себя я промолчу....сколько бабок уже влетело только в одни стики....не одна новая зыза...

ну это же очевидно, после блока служебная инфа и чексумма. как она считается сейчас попробую понять

чексумма 2 байта или больше?

ну раз служебной инфы там 16 байт, то явно больше 2х байт сумма. там может быть хитрая сумма.

а как узнать это? Мужики кто в поиске даташитов силиён....нужны даташиты на нанды Hynix HY27UV08AG5M и её аналог фирмы VDATA VD102P3PC53-L5.....блин не могу найти ....нанд Самсунговский сдох ..осталось дофига стиков именно с вышеназванными нандами

ну фиг знает как, сидеть, смотреть и думать надо.. я пробую..
а вот что сдох - плохо. (а чего сдох?) эт мы так если будем сначала искать алгоритм вычисления суммы, а потом они будут дохнуть, и заново искать для других - нехорошо..

сдох потому что я лох :) при прошивке нанда прогер попросил стереть микруху, есно не всю, а тот блок с которым я работал....ну я разрешил...он и затёр FF...и теперь некоторые ячейки память так и остались FF, он туда записать ни чего не может....так мало того, я не понимаю.. пишу в нанд, а затем считываю с него то что записал....сраниваю с исходником....всё смещено на 4 байта....ХЗ почему....то ли прогер чудит..толи сама микруха уже умирает....И она такая одна единственная....а вот других дофига....и непонятка с их распиновкой....сравниваю стик на котором нанд самсунга сидел с остальными, у остальных разводка дорожек под нанд одинаковая....а у самсунга своя....и она стандартаная для нандов в таком корпусе....а вот остальные видать кривые...

Чексумму контроллер должен считать, и скорее всего одинаково для любых нандов.
Чтобы определить "где в этих 16 байтах сидит инфа о контрольной сумме" нужен дамп со случайными данными(не только 00 или FF).

Всегда считал что ид нанда не меняется, типа на заводе
втуливают ид для работы в системах с контроллером автоматически
выставляющим режимы. Тупо перелить мсид с гигового нанда в
двух-гиговый, например, однозначно приведет к неработоспосбности.
Для примера, возмите, планку оперативной памяти с пс, там есть
еепромка которая и определяет всё. Если в сервисстике и есть хитрая
инфа, то не более одного байта, а может и нескольких битов. Надо
сравнивать стикиды с нескольких стиков (по объему и архитектуре
совпадоющим с сервисным).

так я дамп выкладывал где и MSID и SN прописан и другая инфа про стик

Boryan добавил 14-04-2010 в 23:14
lport3, Как видишь, ты ошибался как и многие.....я тож ранее так думал....и многие твердили, что серийник записан в контроллере намертво в одноразовую флеху....оказалось не так :) нас жестоко обманывали...

Boryan добавил 14-04-2010 в 23:18
prx закриптованны с использованием MSID....когда мэтьюху дали MSID от сервисного, он декриптил с помощью него сервисные prx.....тут и так думаю ясно ...

Боря, ты не понял, переписать стикид не фокус,
главное знать где в нем нанд-ресы а где продуктор-ид,
который возможно и отличает сервисный стик.

стик ид не маленький, каким куском декриптили..))
кодов запуска от першингов там никто не наковырял?..))

lport3, Фома неверующий :) вот тебе данные стика SN: 0024732B
ID: 204D53505344B30001CD387000000000.....этого достаточно? :)
каким куском декриптили ..это вопрос к мэтьюху...

Boryan добавил 14-04-2010 в 23:46
вот ещё несколько для анализа :)
204D5350534E59300079A800056F0000
204D5350534E5930006000EF95D70000
204D5350534E593000788884C6AA0000
204D5350534E59300078490000000001
204D53505344B30001CD387000000000

Boryan, Так, хорошо, теперь я верю в то, что msid нужен.
Стоп, так получается он раскриптовал prx с использованием msid! Почему же просто не закриптовать с помощью другого msid? Емае зачем такие сложности с подменой msid? когда можно проще простого взять и закрптовать с помощью оригинального msid другой MS PRO DUO?

chel12, Друг ты далёк от истины :) для того что бы закриптовать нужно знать алгоритм....а его ни кто не знает.....задай поиском на этом форуме "кирк" и поймёшь что это такое :) вот с помощью кирка делают декрипт....кирк -это чёрный ящик...модуль для декриптовки...что в нём и во какому алгоритму он работает ...ни кто не знает....

Boryan, Вопрос, а не быстрее ли раскрыть алгоритм кирка, чем ломать голову над подменой msid? :o

ну вот можно на ней пока экспериментировать научиться туда писать правильно (в другие блоки).. я уж думал она совсем физически сдохла..

pronvit добавил 15-04-2010 в 00:19
ну так вперед) все только за будут, потому что это решит ВСЕ проблемы.

pronvit добавил 15-04-2010 в 00:22
для нандов для всех одинаково, а вот контроллеры разные могут по-разному. а так как если в другой флешке будет другой нанд, то и контроллер скорее всего тоже, то...

не так просто. там были блоки с одинаковыми данными, но разными этими 16 байтами. единственное объяснение, которое я могу придумать, это что первые байты это инфо о блоке типа адреса или что-то такое, а сумма считается от самого блока и этих данных тоже. но с другой стороны там есть блоки, в которых и данные и эти 16 байт одинаковые, значит, там не адрес...

Скиньте пару prx encr.,decr. и msid желательно,
попробую пробрутить парой криптов. Если размер не
изменяется, не должно быть сложно. Файлы желательно
маленькие jigkick_bridge например.
В программе edecript что за крипт применяется
известно?

да ничего не получится. это все через kirk идет, а чего он внутри делает - никада не пробрутишь и не догадаешься..

В принципе ИМХО правильное предположение.
Пример расчета этих 16 байт есть здесь. У нас LSN тоже имеет место быть, но структура иная и RESERVED области тоже юзаются.

Этот момент тоже не понятен, хотя на 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. Возможно считываются данные посекторно?

Например один логический сектор(LSN термин опять же отсюда) и одинаковые данные - результат одинаковые контрольные суммы.

Неиспользуемые страницы. В них ничего не писали - соответственно и служебные 16 байт тоже "чистые". Возможно и резервные, т.к. насколько я понял в NANDе допускаются "бэды", и для сохранения объема должен быть какой-то резерв. С завода чип скорее всего идет весь FF-ками заполненый, только в каком-то блоке какая-то служебная инфа записана (msid и др.).


По поводу Hynix:
Вот даташит на микруху HY27UH08AG5M.
Отличия от твоей: HY27UH08AG5M - SLC, HY27UF08AG5M - MLC. Не думаю, что для конечного пользователя есть какие-то отличия в использовании (кроме цены). Тут даже кое-что на русском по NANDу.

Тааак, Вас уже не туда понесло.
Тему закрываем ввиду безперспективности, по словам самого автора, работ в данном направлении.
Если у Вас появятся свежие идеи, сообщайте в ЛС - откроем)

Размышления о возможностях взлома ТА88v3
 

Хронология данной темы сохранена и немного почищена от флуда.
Закрыто.