PSPx форум

PSPx форум (https://www.pspx.ru/forum/index.php)
-   PSP хакинг и девелопмент (https://www.pspx.ru/forum/forumdisplay.php?f=195)
-   -   Обсуждение взлома батарейки Пандоры PSP-3000... (https://www.pspx.ru/forum/showthread.php?t=87238)

Alezhek 21.12.2010 20:58

а что в них ищем? кстати, а где на них доки? выложи , пожалуйста

Boryan 21.12.2010 21:38

забирай http://zalil.ru/30194382..ну а искать чего? ...дырку :) Способ вытащить прошивку..верефикацией..написанием своего кода для вытаскивания прошивки.. и записью его в контроллер..короче искать уязвимость :)

hax0r 21.12.2010 23:28

Boryan, Я тут доку почитал... Есть инфа о том, какие биты защиты установлены в тех 9202,которые в наличии есть?

Boryan 22.12.2010 00:46

hax0r, пока такой инфы нет..сложно зацепить 9202...он рассчитан на работу со штатным программатором в отличии от 501...потому пока думаем как его зацепить...а что там нарыл по поводу битов защиты?

lazard 22.12.2010 01:52

Boryan, а разве 9202 есть в батарее на зызе с платой 93?

Alezhek 22.12.2010 08:53

в 9202 все гораздо хуже - "чексум" даже по документации идет блоками по 256 байт. А программатор придется переделывать под него
по мне - так овчинка выделки не стоит... разве что памяти там всего 4К.. проще разбираться, если все-таки удастся сдампить

hax0r 22.12.2010 11:36

Boryan, 9202 еще жесче чем 501... в нем биты защиты даже команду verify не пропустят... еще есть защита на определенную область памяти... регистр защиты от помех... ну и стандартные от стирания чипа, стирания блока и записи... самопрограммирование в нем есть, но оно недоступным становится, если биты защиты установлены... точнее, если оно предусмотрено в той прошивке, которая в нем сейчас и биты защиты установлены, то можно воспользоваться, если его в прошивке нету-то уже ничего не записать...
В общем, 9202 - не вариант, если защита на нем стоит..

hax0r добавил 22.12.2010 в 10:56
lazard,не важно на какой батарее он стоит. Главное что там есть ключи и алгоритм работы. Новые ключи по такой инфе не сложно вычислить.

hax0r добавил 22.12.2010 в 11:36
Boryan,единственное но... там написано, что биты защиты в 9202 можно переустановить, использую команду защиты чипа от записи (стирания чипа в 102).. только пока не понятно что из этого выйдет.. щас читаю доки на 102..

Boryan 22.12.2010 12:12

hax0r, давай давай ..напрягай мозги..а то у меня уже все мысли кончились :) ..жесть с этим NECом ..Ни кто с ним походу во всё мире не колупался как авэрками и пиками...вообще инфы ноль. Непонятно как китайцы нарыли алгоритм...ведь суко клепают баты левые на каждом углу...и прошивка есть почти у каждого китайца....а ни как у них её не выпросить...пробовал все варианты ..и за бабки и в обмен на карточку...тупят суки..типа не понимают что я хочу от них...Да и чел который обещал вытащить с 501 прошиву обломался..короче вся надежда на нас..только самим найти уязвимость в чипе и вытащить оттуда прошиву...других вариантов почти нет...

hax0r 22.12.2010 13:49

Boryan,китайцы скорей всего тупо декап сделали и все..) и не парились особо..) китайцы, сцуко, такие китайцы..)) они, сцуко, хитрые...
Изучу доки на 102 в ближайшее время, мож наколупаю чего...

ANDPSP 22.12.2010 14:08

Цитата:

Сообщение от Alezhek (Сообщение 924549)
может все-таки еще раз проверить и команду 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
лог по командам

21.12.2010 16:42:31 60151,97 send command: 0101A25D03
21.12.2010 16:42:32 60152,02 read status command: 020104FB03
21.12.2010 16:42:32 60152,02 send command: 0101A35C03
21.12.2010 16:42:32 60152,06 read status command: 020104FB03
21.12.2010 16:42:32 60152,06 send command: 0101A45B03
21.12.2010 16:42:32 60152,11 read status command: 020105FA03
21.12.2010 16:42:32 60152,11 send command: 0101A55A03
21.12.2010 16:42:32 60152,16 read status command: 020104FB03
21.12.2010 16:42:32 60152,16 send command: 0101A65903
21.12.2010 16:42:32 60152,2 read status command: 020104FB03
21.12.2010 16:42:32 60152,2 send command: 0101A75803
21.12.2010 16:42:32 60152,25 read status command: 020104FB03
21.12.2010 16:42:32 60152,25 send command: 0101A85703
21.12.2010 16:42:32 60152,3 read status command: 020104FB03
21.12.2010 16:42:32 60152,3 send command: 0101A95603
21.12.2010 16:42:32 60152,34 read status command: 020104FB03
21.12.2010 16:42:32 60152,34 send command: 0101AA5503
21.12.2010 16:42:32 60152,39 read status command: 020104FB03
21.12.2010 16:42:32 60152,39 send command: 0101AB5403
21.12.2010 16:42:32 60152,44 read status command: 020104FB03
21.12.2010 16:42:32 60152,44 send command: 0101AC5303
21.12.2010 16:42:32 60152,48 read status command: 020104FB03
21.12.2010 16:42:32 60152,48 send command: 0101AD5203
21.12.2010 16:42:32 60152,53 read status command: 020104FB03
21.12.2010 16:42:32 60152,53 send command: 0101AE5103
21.12.2010 16:42:32 60152,58 read status command: 020104FB03
21.12.2010 16:42:32 60152,58 send command: 0101AF5003
21.12.2010 16:42:32 60152,63 read status command: 020104FB03
21.12.2010 16:42:32 60152,63 send command: 0101B04F03
21.12.2010 16:42:32 60152,67 read status command: 020105FA03
21.12.2010 16:42:32 60152,67 send command: 0101B14E03
21.12.2010 16:42:32 60152,72 read status command: 020104FB03
21.12.2010 16:42:32 60152,72 send command: 0101B24D03
21.12.2010 16:42:32 60152,77 read status command: 020104FB03


ответ 020104FB03 говорит о том что команда не поддерживается (стр. 17 доки), а вот ответ 020105FA03 (для A4 и B0) говорит про ошибку передачи параметров, но признает что команда есть...

А в случае с 9E вообще положительный статус

21.12.2010 16:16:51 58611,52 send command: 0101996603
21.12.2010 16:16:51 58611,55 read status command: 020104FB03
21.12.2010 16:16:51 58611,55 send command: 01019A6503
21.12.2010 16:16:51 58611,58 read status command: 020104FB03
21.12.2010 16:16:51 58611,59 send command: 01019B6403
21.12.2010 16:16:51 58611,61 read status command: 020104FB03
21.12.2010 16:16:51 58611,63 send command: 01019C6303
21.12.2010 16:16:51 58611,64 read status command: 020104FB03
21.12.2010 16:16:51 58611,66 send command: 01019D6203
21.12.2010 16:16:51 58611,69 read status command: 020104FB03
21.12.2010 16:16:51 58611,69 send command: 01019E6103
21.12.2010 16:16:51 58611,72 read status command: 020106F903
21.12.2010 16:16:51 58611,73 send command: 01019F6003
21.12.2010 16:16:53 58613,34 read status command:


но после этой команды чип клинит - дальше не хочет отвечать на посылы команд, скорее всего ждет передачи каких то данных...

Вот такие пироги :-(

hax0r 22.12.2010 14:15

ANDPSP, да... интересно было бы выяснить с какого чипа NECовцами система команд сдута была...

Boryan 22.12.2010 15:19

hax0r, а толку от этого? Нужно самим ковырять и искать дырку..не верю я в то что в NEC не существует дыры...просто её реально ни кто ещё не искал...

hax0r 22.12.2010 17:03

Кому-нибудь из присутствующих случайно не попадались книги по аппаратному взлому..?) Глупость, конечно, спросил, но все же вдруг..)

DARK-MAN-X 22.12.2010 17:22

Сергей Скоробогатов
Книга по аппаратному взлому
Semi-invasive attacks – A new approach to hardware security analysis

(на английском языке)

144 стр., University of Cambridge, 2005

Книга представляет собой подробный разбор методов взлома микропроцессоров и смарт-карт. Отлично иллюстрирована.

Выложена автором в формате pdf (11.6 MB), распространяется свободно


just google it

может и бесполезна однако это первач-вторая ссылка в гугле

hax0r 22.12.2010 17:53

DARK-MAN-X, спасибо, эту книгу тут уже выкладывали) Я думал может еще какие есть.. В Гугле ничего не нашел пока... Изучаю страницу Скоробогатова...

Yokel 22.12.2010 19:21

если уж говорить о доках от Скоробогатова, то про NEC в этой описано!
http://www.cl.cam.ac.uk/~sps32/ches2010-bumping.pdf

Boryan 22.12.2010 19:32

ну ковырять чип методом Скоробогатова ... дешевле будет поймать китайца ..набить ему морду ..дать денег и сказать что бы притащил прошивку :)

lazard 22.12.2010 20:02

С английским не на ТЫ, но тут чуть ли не ренген чипа. Кстати, о ренгенах: может лучше взять лампу из низкого диапазона, приобрести необходимую оптику и просветить чип. С электрикой тоже не на ТЫ, но такой способ применял при поиске дефекта внутри деталей. Реально ли?

Boryan 22.12.2010 20:13

lazard, бред :)

lazard 22.12.2010 20:16

Boryan, тогда будем бить китайцев...


Текущее время: 02:10. Часовой пояс GMT +3.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2025, vBulletin Solutions, Inc. Перевод: zCarot
PSPx Forum - Сообщество фанатов игровых консолей.