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.....тут и так думаю ясно ...