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)

Boryan 19.12.2010 01:15

hax0r, большой с 30 ногами это и есть 501 ..просто сейчас маркировку лепят любую на чип..а мелкий в красном кружке еепром

Boryan добавил 19.12.2010 в 01:15
hax0r, в мелкой Е**РОМ не 16 к а 256 байт всего

hax0r 19.12.2010 01:22

Boryan,да... тогда в ней действительно ничего полезного нет..

Boryan 19.12.2010 17:51

Цитата:

Сообщение от hax0r (Сообщение 923888)
Boryan,да... тогда в ней действительно ничего полезного нет..

Неужели ты думаешь что еепром я первым делом не поковырял? Есно там ловить не чего....а ловить нужно только в прошивке контроллера..

Yoti 20.12.2010 00:57

Цитата:

Сообщение от hax0r (Сообщение 923434)
Методы для обычных программ с железками обычно не работают по одной простой причине...
<...>
Поэтому дырявая программа вполне может перекинуть вас в раздел оперативки, где хранится она сама, а не только переменные.

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

Wesbam 20.12.2010 01:22

Хорошо, убедил этот способ возможно не проканает.
Но я бы все равно его проверил.
Я всего лишь хочу опять сказать что не стоит зацикливаться
на одних только батарейках и на том как растворить свою psp в кислоте, а искать другие способы взлома.
Конкретное я озвучивал еще раньше, выяснить каким образом сам сикон
переводит проц в режим загрузки с карты памяти.

Boryan 20.12.2010 01:32

Wesbam, очень просто ...командами по шине...только доступа туда нет...это как в биосе РС ты выбираешь сам откуда будешь грузиться...так и здесь..доступ только с команд батарейки..А потом это бредовая идея для реализации ...в смысле что бы перешить или сделать даун тебе нужно будет всю консоль разобрать

Boryan добавил 20.12.2010 в 01:32
а потом ты думаешь что мы тупые и за полгода не пересмотрели все возможные варианты взлома? Аппаратный вариант со сменой сискона уже описывался много страниц назад..

Wesbam 20.12.2010 02:29

Okey, я допускаю что мог что то пропустить и совершить ошибку
в своих умозаключениях. С самого начало правильней было бы
самому заняться взломом и проверкой своих идей.
Что касается варианта взлома через прошивку батарейки, то
я по прежнему считаю его не самым лучшим.

Желаю удачи и успехов во взломе.

Boryan 20.12.2010 03:52

Wesbam, так попытайся сам сискон поломать...мож у тебя получится...Ты наверное так до конца и не понял всей сути перевода ПСП в сервисный режим:(.....только взлом батарейки и ни чего более

hax0r 20.12.2010 12:47

Цитата:

Сообщение от Yoti (Сообщение 924045)
На это я и намекал, когда спрашивал про наличие практических идей. А туманные ответы - не модно.

Что-то я не очень понял.. Если это мне адресовано, то я всего лишь пытался человеку объяснить, что он предложил априори провальный путь...
А насчет практических идей - то, мне кажется, варианта всего 3 на данный момент:
1.декап
2.вариант с двумя чипами
3.вычисление ключей и алгоритма по ответам, но это наиболее нереально.. только если ООООчень сильно повезет... хотя, если у вас есть знакомые криптографы с мировым имене-можно попробовать..)

ANDPSP 20.12.2010 18:01

Цитата:

Сообщение от Alezhek (Сообщение 923824)
Ладно, следующая идея: имеем команды работающие с 4-мя байтами.
Командой Cheksum - проверяем их - получаем число - побайтное вычитание
этих 4х ячеек из 0000h. Таким образом значительно сокращается количество вариантов перебора значений для команды Verify. Нам нужно проверять только те a,b,c,d, разность которых равна этому числу

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

Теперь про алгоритм чексума - побайтного вычитания там нет и в помине, что там за алгоритм - хз. можно конечно попробовать просчитать алгом выложенным в доках на 9202 - но там блок 256 байт а у нас 1024...

Если кому интересно то блок из 1024 FF имеет чексум 0400h, причем полностью затертый чип так же имеет этот же чексум, как и любой блок.

Первый блок с данными "8000FFFF....FF" имеет чексум 057Eh, остальные пустые блоки имеют тот же чексум 0400h, а чексум всего чипа равен 417Eh

Мне пока не удалось найти алгоритм расчета чексуммы, попытайтесь - может кому повезет, но всеравно сомневаюсь что будет толк - поскольку мы узнаем лишь чексум всего блока - т.е. 1024 байт, а никак не 4-х байт которых достаточно для верификации...

Тем кто будет играться с моей прогой напоминаю что прошивка для заливки должна быть в виде бинарника а не стандартного хекса, т.е. вид типа ":10016600B7891CD6874197B0B160F204FAF3B1B0F3" не прокатит...
Для перевода нужно загрузить хекс в проге FlashProg и скопировать в бинарник или же заливать в самом FlashProg, но она льет с самого начала, а в моей проге можете записать данные в любой блок и стереть так же любой блок...

ANDPSP добавил 20.12.2010 в 18:01
Цитата:

Сообщение от hax0r (Сообщение 924087)
Что-то я не очень понял.. Если это мне адресовано, то я всего лишь пытался человеку объяснить, что он предложил априори провальный путь...
А насчет практических идей - то, мне кажется, варианта всего 3 на данный момент:
1.декап
2.вариант с двумя чипами
3.вычисление ключей и алгоритма по ответам, но это наиболее нереально.. только если ООООчень сильно повезет... хотя, если у вас есть знакомые криптографы с мировым имене-можно попробовать..)

1. У тебя реально есть навыки декапа и соответствующее оборудование ?
2. Тут Боря немного сам запутался и вас всех запутал, в реале наиболее открытые 501-е чипы с батареек, имеющие возможность перезаписи бута, закрыты от программирования - а это отключает возможность стереть определенный блок и записать в него програмку внутреннего чтения. теоретически есть конечно надежда найти в батарейке полностью открытый чип, но это скорее из области фантастики, как и надежда найти работающий бутлоадер в этих чипах - хотя этот момент так и не проверили...
3. Это не реально, я на 90 % теперь уверен что там реализован XTEA который в асме занимает всего 20-30 строк кода - можете в википедии посмотреть...

hax0r 20.12.2010 18:13

ANDPSP, действительно, очень похоже на XTEA.. но не забывайте, что у сони есть свой алгоритм, который так же не требователен к ресурсам и памяти. Название не приведу, но я о нем писал ранее... Или возможно, что сони модифицировали XTEA и стали его применять, т.к. XTEA не был запатентован по инфе из википедии..
Да и в семействе XTEA довольно много разновидностей.. например, XXTEA или RTEA..
RTEA вообще на СИ одну строчку занимает..

Alezhek 20.12.2010 19:36

Цитата:

Сообщение от ANDPSP (Сообщение 924174)
Теперь про алгоритм чексума - побайтного вычитания там нет и в помине, что там за алгоритм - хз.

вот что в доке
http://i040.radikal.ru/1012/b0/adc053365e30.jpg

ANDPSP 21.12.2010 13:13

Цитата:

Сообщение от Alezhek (Сообщение 924205)

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

hax0r 21.12.2010 14:15

Цитата:

Сообщение от ANDPSP (Сообщение 924429)
Все правильно в доке, это я ошибся при пересчете чексума - все значения перепроверил и все сходится тютя в тютю, там реально побайтное вычитание из нуля, но что это нам дает ?

Это дает уменьшение возможных вариантов при бруте прошивки с помощью поблочной/побайтной верификации.

lazard 21.12.2010 14:41

hax0r, Еси так, хватит ли времени раскурочить прошивку брутом?

hax0r 21.12.2010 14:45

lazard, время бесконечно))) его не может не хватить))
Другой вопрос-на сколько сократится время на вытаскивание брутом...

lazard 21.12.2010 15:19

hax0r, ты тоже вечен? или Борян? а сама консоль? Я как раз о чем, на что нам хватит времени. Без обид, но о вечности времени это сомсем другая тема.

З.Ы.реально ли рассчитать, сколько времени нужно для этого?

hax0r 21.12.2010 15:27

lazard,рассчитать можно все что хочешь.
А насчет обид... какие вопросы задаешь-такие ответы и получаешь.
Хватит или не хватит времени будет зависеть от тех временных рамок в которые ты хочешь уложиться.

Alezhek 21.12.2010 20:10

Цитата:

Сообщение от ANDPSP (Сообщение 924429)
Все правильно в доке

может все-таки еще раз проверить и команду Verify?
[IMG][/IMG]
ведь судя по доку.. проверять можно от 1 байта?

Boryan 21.12.2010 20:23

Alezhek, по докам , да....а на деле 4 байта..Я же и прогу и доки и схемы всё выложил..можете сами попробовать...Мы тоже губы раскатали на эти доки ...но NEC быстро закатал :)

Boryan добавил 21.12.2010 в 20:23
Alezhek, А уже если у тебя есть желание помочь ..то поизучай доки на 9202 ..мож там дырку можно найти...или на 102 чип посмотри своим свежим взглядом :)

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, тогда будем бить китайцев...


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

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