Решил я развеять слухи о том что зыза 3000 преходит в сервисный режим с порта USB. Во первых, что бы активировался порт USB должен стартануть ЦП..., а он ну ни как не может это сделать на брикнутой консоли Далее я просто зацепил крутой осциллограф к среднему выводу батарейки пандора и воткнул её в 3000 брик и записал их разговор. Известно, что со старой батарейкой 3000 не стартует....но ....смотрите сами http://www.youtube.com/watch?v=T4mQofU37sg, что записал осциллограф. Короче зыза общается с батарейкой упорно на предмет получения ключика для перехода в сервисмод. Делаем выводы....нужен ключик для перевода 3000 в сервис мод, но, он не FFFFFFFF.....а какой? какие будут предложения по подбору ключика? Кто силён в написании прог под винду. Нуно сварганить прогу что бы она по USB через микруху МАХ232 эмулировала флешку батарейки ....со всеми вытекающими последствиями. А точнее сгенерила ключик и дала команду электронному ключу на вкл батарейки....посмотрели... нет сервисмод у 3000....отключаем батарейку...генерим новый ключик ...и так далее до победного конца. Кто готов написать такую прогу? Электронную начинку я беру на себя .
Boryan добавил 20-04-2010 в 11:33
народ давай подтягивайтесь в тему. неужели не интересно мозгами поработать? Мои мысли по поводу батарейки для 3000....что могли в ней изменить Сони? Применить другой ключик...слишком просто...перебрать 4 байта учитывая что код только может быть типа 0хAA AA AA AA или 0хАВ АВ АВ АВ, это не сложно. Это не в правилах Сони...уж если рубить концы, то конкретно. Я думаю что они тупо увеличили код до 8 байт, и он так и остался 0хFF FF FF FF FF FF FF FF. Что это даёт? Во первых, процессор стандартной батарейки не может дать зызе код длиннее 4 байт, а вот их специальная батарейка может выдать код длинной 8 байт. В итоге... и волки сыты и овцы целы... Мужики, подумал я тут и понял эмулировать флешку батарейки пока рано. Нужно написать прогу снифер под винду, ну типа писать протокол обмена с батарейкой. Записать один протокол с 2000 а второй с 3000, и сравнить команды запроса на серийник, если они одинаковые то возможно ключик так и остался 4 байта, и тогда перебор нам поможет. А вот если разные...то нужно думать как заставить батарейку выдать 8 байт.....или тупо заставить прогу снифер поработать за батарейку и отвечать за неё ...ведь если будет записан протокол, то что нам составит труда выплюнуть его обратно с нужным нам ключиком?
Код Описание Данные Ответ от батареи Примечание
0x01 запрос оставшегося заряда нет energyleft_mAh:u16
0x02 запрос температуры нет temperature:u8 cercius degree, min/max value unknown
0x03 запрос напряжения нет voltage_mV:u16
0x04 запрос тока нет current_mA:short positive if charging battery
0x07 запрос ёмкости нет capacity_mAh:u16
0x09 запрос оставшегося времени нет timeleft_min:u16 XMB showing not this value
0x0c запрос серийного номера нет serialno:u32 suspected
0x80 запрос аутентификации? 9byte 16byte encrypted data/reply
0x81 запрос аутентификации? 8byte 8byte encrypted data/reply
0x05 ответ от батареи нет NAK, BCC error and so on??
0x06 ответ от батареи да ACK, with reply data
забирай http://zalil.ru/30194382..ну а искать чего? ...дырку Способ вытащить прошивку..верефикацией..написанием своего кода для вытаскивания прошивки.. и записью его в контроллер..короче искать уязвимость
hax0r, пока такой инфы нет..сложно зацепить 9202...он рассчитан на работу со штатным программатором в отличии от 501...потому пока думаем как его зацепить...а что там нарыл по поводу битов защиты?
в 9202 все гораздо хуже - "чексум" даже по документации идет блоками по 256 байт. А программатор придется переделывать под него
по мне - так овчинка выделки не стоит... разве что памяти там всего 4К.. проще разбираться, если все-таки удастся сдампить
Boryan, 9202 еще жесче чем 501... в нем биты защиты даже команду verify не пропустят... еще есть защита на определенную область памяти... регистр защиты от помех... ну и стандартные от стирания чипа, стирания блока и записи... самопрограммирование в нем есть, но оно недоступным становится, если биты защиты установлены... точнее, если оно предусмотрено в той прошивке, которая в нем сейчас и биты защиты установлены, то можно воспользоваться, если его в прошивке нету-то уже ничего не записать...
В общем, 9202 - не вариант, если защита на нем стоит..
hax0r добавил 22.12.2010 в 10:56 lazard,не важно на какой батарее он стоит. Главное что там есть ключи и алгоритм работы. Новые ключи по такой инфе не сложно вычислить.
hax0r добавил 22.12.2010 в 11:36 Boryan,единственное но... там написано, что биты защиты в 9202 можно переустановить, использую команду защиты чипа от записи (стирания чипа в 102).. только пока не понятно что из этого выйдет.. щас читаю доки на 102..
Последний раз редактировалось hax0r; 22.12.2010 в 11:36.
Причина: добавил, подумав
hax0r, давай давай ..напрягай мозги..а то у меня уже все мысли кончились ..жесть с этим NECом ..Ни кто с ним походу во всё мире не колупался как авэрками и пиками...вообще инфы ноль. Непонятно как китайцы нарыли алгоритм...ведь суко клепают баты левые на каждом углу...и прошивка есть почти у каждого китайца....а ни как у них её не выпросить...пробовал все варианты ..и за бабки и в обмен на карточку...тупят суки..типа не понимают что я хочу от них...Да и чел который обещал вытащить с 501 прошиву обломался..короче вся надежда на нас..только самим найти уязвимость в чипе и вытащить оттуда прошиву...других вариантов почти нет...
Boryan,китайцы скорей всего тупо декап сделали и все..) и не парились особо..) китайцы, сцуко, такие китайцы..)) они, сцуко, хитрые...
Изучу доки на 102 в ближайшее время, мож наколупаю чего...
может все-таки еще раз проверить и команду Verify?
[IMG][/IMG]
ведь судя по доку.. проверять можно от 1 байта?
Что же ты примечание (Note) в вышеприведенный фрагмент не включил ? Сразу бы все понятно стало.... короче вот тебе фрагмент переписки с разработчиком FlashProg, а он побольше всех нас в неках шарит...
про верификацию
Привет,
было бы здорово если бы этот способ сработал, поскольку с нашей
верификацией чипа UPD78F0501 что то не получается, тоже была мысль
что реализована лишь поблочная верификация по 256 байт, но тогда не
понятно для чего реализована передача данных произвольной длины - от
1 байта до 256 и не понятен байт окончания пакета - 03H или 17H -
какой из них оканчивает передачу данных и дает понять чипу что можно выдавать результат верификации.
Верификация только блочная... посылать инфу можно хоть по
байтику и отвечать он будет всегда положительным подтверждением (ACK
= 0х06) на каждый посланный байт...но конечный результат верификации
предоставляется только после передачи последнего 256 байта!
Про это черным по белому написано в каменте на Verify result:
Even if a verify error occurs in the specified address range, ACK is always returned
as the verify result. The status of all verify errors are reflected in the verify result for
the last data. Therefore, the occurrence of verify errors can be checked only when
all the verify processing for the specified address range is completed.
Почему такую возможность сделали...возможно просто алгоритмы
скопировали...То же программирование имеет подобную схему.
А так хрен их знает....зачем они так сделали.
я конечно принял эту инфу к сведению но все же решил сам проверить, так вот методом научного тыка и нашлись эти 4 байта достаточные для верификации...
свежий лог
22.12.2010 13:42:13 49333,39 send: 010120DF03
22.12.2010 13:42:13 49333,56 read status command: 020106F903
22.12.2010 13:42:13 49333,56 Chip erase successful...
22.12.2010 13:42:29 49349,19 Read from file 8 byte...
22.12.2010 13:42:51 49371 send command to write: 010740000000003FFF7B03
22.12.2010 13:42:51 49371,02 read status command: 020106F903
22.12.2010 13:42:51 49371,02 send data frame: 0208019B5E011620FE10B903
22.12.2010 13:42:51 49371,05 get status data frame: 02020606F203
22.12.2010 13:42:51 49371,05 data frame write successful...
22.12.2010 13:42:51 49371,25 get status all data frame: 020106F903
22.12.2010 13:42:51 49371,27 All data write successful...
22.12.2010 13:42:58 49378,05 Read from file 1 byte...
22.12.2010 13:42:58 49378,05 send command to verify: 010713000000003FFFA803
22.12.2010 13:42:58 49378,08 read status command: 020106F903
22.12.2010 13:42:58 49378,08 send data frame: 020101FE03 SentBytes = 5
22.12.2010 13:42:58 49378,16 get status data frame: 0202060FE903
22.12.2010 13:42:58 49378,16 data frame verify error...
22.12.2010 13:43:01 49381,36 Read from file 2 byte...
22.12.2010 13:43:01 49381,36 send command to verify: 010713000000003FFFA803
22.12.2010 13:43:01 49381,38 read status command: 020106F903
22.12.2010 13:43:01 49381,38 send data frame: 0202019B6203 SentBytes = 6
22.12.2010 13:43:01 49381,47 get status data frame: 0202060FE903
22.12.2010 13:43:01 49381,47 data frame verify error...
22.12.2010 13:43:07 49387,52 Read from file 3 byte...
22.12.2010 13:43:07 49387,53 send command to verify: 010713000000003FFFA803
22.12.2010 13:43:07 49387,55 read status command: 020106F903
22.12.2010 13:43:07 49387,55 send data frame: 0203019B5E0303 SentBytes = 7
22.12.2010 13:43:07 49387,63 get status data frame: 0202060FE903
22.12.2010 13:43:07 49387,63 data frame verify error...
22.12.2010 13:43:10 49390,27 Read from file 4 byte...
22.12.2010 13:43:10 49390,27 send command to verify: 010713000000003FFFA803
22.12.2010 13:43:10 49390,3 read status command: 020106F903
22.12.2010 13:43:10 49390,3 send data frame: 0204019B5E010103 SentBytes = 8
22.12.2010 13:43:10 49390,31 get status data frame: 02020606F203
22.12.2010 13:43:10 49390,31 data frame verify successful...
22.12.2010 13:43:13 49393,25 Read from file 5 byte...
22.12.2010 13:43:13 49393,25 send command to verify: 010713000000003FFFA803
22.12.2010 13:43:13 49393,27 read status command: 020106F903
22.12.2010 13:43:13 49393,27 send data frame: 0205019B5E0116EA03 SentBytes = 9
22.12.2010 13:43:13 49393,36 get status data frame: 0202060FE903
22.12.2010 13:43:13 49393,36 data frame verify error...
22.12.2010 13:43:15 49395,95 Read from file 6 byte...
22.12.2010 13:43:15 49395,95 send command to verify: 010713000000003FFFA803
22.12.2010 13:43:15 49395,97 read status command: 020106F903
22.12.2010 13:43:15 49395,97 send data frame: 0206019B5E011620C903 SentBytes = 10
22.12.2010 13:43:16 49396,06 get status data frame: 0202060FE903
22.12.2010 13:43:16 49396,06 data frame verify error...
22.12.2010 13:43:19 49399,33 Read from file 8 byte...
22.12.2010 13:43:19 49399,33 send command to verify: 010713000000003FFFA803
22.12.2010 13:43:19 49399,34 read status command: 020106F903
22.12.2010 13:43:19 49399,34 send data frame: 0208019B5E011620FE10B903 SentBytes = 12
22.12.2010 13:43:19 49399,38 get status data frame: 02020606F203
22.12.2010 13:43:19 49399,38 data frame verify successful...
22.12.2010 13:43:30 49410,86 Read from file 4 byte...
22.12.2010 13:43:32 49412,86 send command to write: 010740000400003FFF7703
22.12.2010 13:43:32 49412,88 read status command: 020106F903
22.12.2010 13:43:32 49412,89 send data frame: 02048000FFFF7E03
22.12.2010 13:43:32 49412,91 get status data frame: 02020606F203
22.12.2010 13:43:32 49412,91 data frame write successful...
22.12.2010 13:43:33 49413,05 get status all data frame: 020106F903
22.12.2010 13:43:33 49413,05 All data write successful...
22.12.2010 13:43:37 49417,63 Read from file 4 byte...
22.12.2010 13:43:37 49417,63 send command to verify: 0107130004000007FFDC03
22.12.2010 13:43:37 49417,64 read status command: 020106F903
22.12.2010 13:43:37 49417,64 send data frame: 02048000FFFF7E03 SentBytes = 8
22.12.2010 13:43:37 49417,67 get status data frame: 02020606F203
22.12.2010 13:43:37 49417,67 data frame verify successful...
22.12.2010 13:43:42 49422,38 Read from file 4 byte...
22.12.2010 13:43:42 49422,39 send command to verify: 0107130004000007FFDC03
22.12.2010 13:43:42 49422,41 read status command: 020106F903
22.12.2010 13:43:42 49422,41 send data frame: 0204019B5E010103 SentBytes = 8
22.12.2010 13:43:42 49422,44 get status data frame: 0202060FE903
22.12.2010 13:43:42 49422,44 data frame verify error...
22.12.2010 13:43:49 49429,22 Read from file 4 byte...
22.12.2010 13:43:49 49429,22 send command to verify: 0107130004000007FFDC03
22.12.2010 13:43:49 49429,25 read status command: 020106F903
22.12.2010 13:43:49 49429,25 send data frame: 02048000FFFF7E03 SentBytes = 8
22.12.2010 13:43:49 49429,27 get status data frame: 02020606F203
22.12.2010 13:43:49 49429,28 data frame verify successful...
22.12.2010 13:43:51 49431,69 send command to verify: 0107130004000007FFDC03
22.12.2010 13:43:51 49431,72 read status command: 020106F903
22.12.2010 13:43:51 49431,72 send data frame: 02048000FFFF7E03 SentBytes = 8
22.12.2010 13:43:51 49431,73 get status data frame: 02020606F203
22.12.2010 13:43:51 49431,73 data frame verify successful...
22.12.2010 13:43:51 49431,73 send command to verify: 0107130004000007FFDC03
22.12.2010 13:43:51 49431,77 read status command: 020106F903
22.12.2010 13:43:51 49431,77 send data frame: 0201807F17 SentBytes = 5
22.12.2010 13:43:51 49431,78 get status data frame: 02020606F203
22.12.2010 13:43:51 49431,78 send data frame: 020100FF17 SentBytes = 5
22.12.2010 13:43:51 49431,81 get status data frame: 02020606F203
22.12.2010 13:43:51 49431,81 send data frame: 0201FF0017 SentBytes = 5
22.12.2010 13:43:51 49431,84 get status data frame: 02020606F203
22.12.2010 13:43:51 49431,84 send data frame: 0201FF0003 SentBytes = 5
22.12.2010 13:43:51 49431,86 get status data frame: 0202060FE903
22.12.2010 13:43:51 49431,86 data frame verify error...
Лень писать комменты в логе, тот кто разбирается прекрасно все поймет - чип вначале полностью стирается, потом во всю память пишется 8 тестовых байт (они пишутся в первый блок), дальше идут попытки верификации заведомо правильными байтами: 1 байт, 2 байта, 3, 4, 5, 6, 8 - где 4 и 8 там успех, потом во второй блок пишутся других 4 байта и так же верифицируются правильными и неправильными значениями ну и напоследок прототип брута - вот тут очень интересный результат - если сразу верифицировать 4 байта - то все нормально , а если посылать побайтно правильные байты то в результате будет провал...
Ну и еще интересное - вспомнил как гонял батарейку по однобайтовым командам и решил так же пробить чип на недокументированные команды, в итоге нашлась пара таких команд A4h и 9Eh
ответ 020104FB03 говорит о том что команда не поддерживается (стр. 17 доки), а вот ответ 020105FA03 (для A4 и B0) говорит про ошибку передачи параметров, но признает что команда есть...
С английским не на ТЫ, но тут чуть ли не ренген чипа. Кстати, о ренгенах: может лучше взять лампу из низкого диапазона, приобрести необходимую оптику и просветить чип. С электрикой тоже не на ТЫ, но такой способ применял при поиске дефекта внутри деталей. Реально ли?