Как определить алгоритм преобразования 8 байт ?

с помощью этой программы можно полностью разобрать прошивку 6.20 и редактировать!
1.Скачайте архив

2.Находим в архиве папку new_psar_dumper_mod_620 и кладём её в /PSP/GAME/

3.Создаем папку FW с прошивкой 6.20 кладём в корень карты памяти

4.Запускаем программу

5.Все файлы прошивки распакуются в папку FW

6.Если вы программист, то начинайте колдовать с полученными файлами

http://upwap.ru/929847

 

выложите кто нить прошивку пжл!(декампилированую 6.20 )

 

выложите просто прошивку, а там видно будет

 

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

 

Вот нашел инфу по нековским чипам и работе с ними программатором http://eldigi.ru/site/nec/index.php нужный чип uPD78F0102H есть в списке поддерживаемых микроконтроллеров...
Архитектура Фон неймана однозначно подтверждает XTEA или нет ?
И все же правильно ли я понял что этот программатор и софт поможет лишь стереть прошивку или записать свою но никак не даcт возможности считать имеющуюся ? Чтобы считать нужно стравливать или стачивать корпус и добираться до флеш-памяти ?

 

еще такой документик http://www.eltech.spb.ru/pdf/nec/78K0_User_Manual.pdf выглядит интересно но как это все к чипу прикрутить ума не приложу....

 

Поднимаю тему - очень актуально....
Может кто то подскажет сайты где криптографов можно зацепиь ?

 

reng.ru, попробуй на defectoscopy написать.

 

Спасибо за совет, но что то с лету не нашел там подобной тематики...

А еще вопрос по поводу криптоалгоритма - нашли микруху uPD78F09202 - в ней тоже зашит нужный алгоритм, но памяти то в ней всего 4 килобайта, понятно уже что таблица ключей в ней усеченная, поскольку ограничено количество возвращаемых ответов на запросы, но и даже так какой алгоритм может уместиться в 4 кбайта ? ведь прошивке еще нужно отвечать на обычные запросы (возвращать серийник и уровень заряда батарейки). Может какие то алги можно сразу отсечь...
И еще нашли интересный документ - патент сони на батарейки http://www.google.com/patents?id=RP...urce=gbs_overview_r&cad=0#v=onepage&q&f=false там точно описан алгоритм взаимодействия железяки и батарейки, может кто то догадается для какой криптовки это типично ?

 

Androand

Ну вот тот, который мы обсуждали выше - TEA? - с простейшей сетью Файстеля - я напишу на ассемблере 8086 с гарантией в 500 байт. Если это какой-то простейший 8-ми битный CPU - раза в полтора больше. Реально конечно будет сучественно ниже.

Если там внутри даже не асм а что-то вроде скрипта и форт-машины то код может быть даже МЕНЬШЕ.

 

именно такой чип и есть ...

Просто я подумал что если там еще хранится таблица ключей (дельт) 256 вариантов по 8 байт то это уже по объему будет 2 килобайта - ровно половина и потом впритык ведь наверное не пишут... Нашел в доках упоминание про FlexiHash - погуглив понял что это аппаратная реализация идентификации в чипах Интерслил (или как там ее), но тут реально алгоритм сложнее, но сони могли отталкиваться от этой технологии...

 

Поднимаю тему - есть определенные сдвиги в обсуждаемом вопросе - удалось вытащить прошивку - Ида дизасмит ее вроде не плохо - даже удалось быстро найти кусок ответа серийника на запрос

5A 02 0C 97 - это запрос серийника
A5 06 06 863D008A 01- это ответ серийника из прошивки, его то удалось легко найти
5A 0B 80 0A6A1239AF4AEE4E6E B8 - это запрос (0B - длина команды+данные, 80 0A - команда, 8 байт данных, B8 - чексум )
A5 12 06 D326E4AFF5590271A04C905070626F6E 7A - это ответ (12 - длина, 06- положительный статус ответа, 16 байт данных, 7A - чексум)
5A 0A 81 0C15A897DB18AF12 06
A5 0A 06 8528A34EFD88A926 58

по серийнику IDA вроде не плохо разобрала дамп - логика прослеживается:

ROM_:0AB4 loc_AB4: ; CODE XREF: sub_9FB+AD j
ROM_:0AB4 movw AX,#3D86h
ROM_:0AB7 call !sub_9E9
ROM_:0ABA movw AX,#8A00h
ROM_:0ABD call !sub_9E9
ROM_:0AC0 br !loc_C03

но вот понять математику и алгоритм преобразования восьми байт очень тяжело, может кто сможет помочь ? Если кто то готов взяться за это на платной основе, то называйте цену за полный реверсинг прошивки или только за реверсинг алгоритма преобразования...

 

Что то тут совсем затишье, неужели никто помочь не может ?

Задача предельно упростилась, удалось переписать алгоритм с асма на VB, прога получилась полностью рабочая, ответ на запрос просчитывается без ошибок, стандартный вариант AES-128 не сработал, но он определенно присутствует в алгоритме.

Код (Text):

1. Public Sub EncryptNec(buff() As Byte, r_key() As Variant)
2.     Dim i       As Byte
3.     Dim j       As Byte
4.     Dim r       As Byte
5.     Dim x       As Byte
6.     Dim a(15)   As Byte
7.     Dim y(15)   As Byte
8.    
9.    
10.     Debug.Print "вход: " & Arr2Hex(buff)
11.     Debug.Print "key0: " & Arr2Hex(r_key(0))
12.    
13.     ' 1 раунд - XOR с первым раундовым ключем
14.    
15. For r = 0 To 9
16.    
17.     'реализация процедуры sub_F9F и sub_F4E в одном флаконе
18.    
19.     a(0) = buff(0) Xor r_key(r)(0)
20.     a(1) = buff(1) Xor r_key(r)(1)
21.     a(2) = buff(2) Xor r_key(r)(2)
22.     a(3) = buff(3) Xor r_key(r)(3)
23.    
24.     a(4) = buff(5) Xor r_key(r)(5)
25.     a(5) = buff(6) Xor r_key(r)(6) ' rotate 5-7
26.     a(6) = buff(7) Xor r_key(r)(7)
27.     a(7) = buff(4) Xor r_key(r)(4) ' rotate 5-7
28.    
29.     a(8) = buff(10) Xor r_key(r)(10)   ' rotate 8-11
30.     a(9) = buff(11) Xor r_key(r)(11)   ' rotate 9-10
31.     a(10) = buff(8) Xor r_key(r)(8)    ' rotate 9-10
32.     a(11) = buff(9) Xor r_key(r)(9)    ' rotate 8-11
33.    
34.     a(12) = buff(15) Xor r_key(r)(15)  ' rotate 12-14
35.     a(13) = buff(12) Xor r_key(r)(12)
36.     a(14) = buff(13) Xor r_key(r)(13)  ' rotate 12-14
37.     a(15) = buff(14) Xor r_key(r)(14)
38.    
39.     'реализация процедуры sub_FD4 - подстановка байт
40.     For i = 0 To 15
41.         a(i) = m_fbsub(a(i))
42.     Next i
43.    
44. '    Debug.Print "шаг1: " & Arr2Hex(a)
45.    
46.     If r < 9 Then
47.         'реализация процедуры sub_EE3
48.         For j = 0 To 3
49.             x = a(j) Xor a(j + 12) Xor a(j + 4) Xor a(j + 8) ' то что кладем в регистр X
50.             y(j) = a(j) Xor x Xor LShiftByteNec(a(j), 1) Xor LShiftByteNec(a(j + 4), 1)
51.             y(j + 4) = a(j + 4) Xor x Xor LShiftByteNec(a(j + 4), 1) Xor LShiftByteNec(a(j + 8), 1)
52.             y(j + 8) = a(j + 8) Xor x Xor LShiftByteNec(a(j + 8), 1) Xor LShiftByteNec(a(j + 12), 1)
53.             y(j + 12) = a(j + 12) Xor x Xor LShiftByteNec(a(j + 12), 1) Xor LShiftByteNec(a(j), 1)
54.         Next
55.         'Переносим результат после очередного шага
56.         For i = 0 To 15
57.             buff(i) = y(i)
58.         Next i
59.    
60.     Else
61.        
62.         'Переносим результат после очередного шага
63.         For i = 0 To 15
64.             buff(i) = a(i)
65.         Next i
66.    
67.     End If
68.    
69.     'Debug.Print "_EE3-" & r & ": " & Arr2Hex(buff)
70.    
71. Next r
72.  
73.     'последний раунд XOR
74.     For i = 0 To 15
75.         buff(i) = buff(i) Xor r_key(10)(i)
76.     Next i
77.  
78. '    Debug.Print "_EE3-" & r & ": " & Arr2Hex(a)
79.  
80. End Sub
81.  
82.  
83. 'Процедура сдвига влево с учетов переполнения и коррекции
84. Private Function LShiftByteNec(ByVal bytValue As Integer, _
85.                             ByVal bytShiftBits As Byte) As Byte
86.    
87. bytValue = LShift(bytValue, bytShiftBits)
88.    
89. If bytValue > &HFF Then
90.     LShiftByteNec = (bytValue - &HFF) Xor &H1A
91. Else
92.     LShiftByteNec = bytValue
93. End If
94.  
95. End Function

Кто то может опознать что за реализация AES тут или это что то другое ? Ведь в стандартном AES нет такого хитрого сдвига влево и механизм генерации раундовых ключей не подходит - пока так и не удалось определить зависимость:

Код (Text):

1. раундовые ключи
2. 01 - 5CF389EC 5282D816 D9AC8129 1CA4787B
3. 02 - 1AE9608C F775ADBB F854D5FC D2760E75
4. 03 - F21B7BF7 47329F24 6531E418 B6C0CEBB
5. 04 - C0DBA057 EAD84763 8FBE5A42 DE1ED06B
6. 05 - 33E8481F C61E593A F04E1456 859B4B20
7. 06 - A34B031C 7769300A 47091D4B 45DE95B5
8. 07 - E4AFACB0 C4AD9D97 929B86CD D9079227
9. 08 - 2C832F9F 79D449DE 5EC5438E 3E39AB8C
10. 09 - B1321D82 60B4FD23 3AFFBC32 E5DC77FB
11. 10 - 8CBEA321 43F70A29 35CA7644 F62A5DA6
12. 11 - 1FA10223 58AFA58C 11DBADE9 0B217CDA

И есть ли вообще возможность обратного просчета раундовых ключей из пары запрос-ответ?

 

Ну хоть кто нибудь может ответить ? Или нужно было новую тему начинать ? Модераторы отпишитесь хоть вы - стоит тут ждать ответа или можно закрывать тему и создавать новую - конкретно по алгоритму ?