Есть два девайса при коннекте между собой делают проверку свой-чужой по хитрому алгоритму. Ведуший девайс посылает 8 байт криптованный ключик ведомому..ведомый должен его декриптить и отправить правильный ответ..
сокращённо лог общения выглядит так
5A 0B 8004 B7A80076B00587EC 19
A5 12 06 8E759E521D19EEB0 47B29FE2342209F9 A9
где : 8004 команда запроса и далее ключ 8 байт на конце КС
1206 успешный ответ и далее 8 байт ответа плюс 8 байт криптованный ключ уже для проверки на свой-чужой ведущего девайса.
Ведомый девайс собран на МК NEC....удалось взломать этот контроллер и вытащить с него дамп прошивки весом 4 к.
Начал поторшить дамп в IDA на предмет взлома алгоритма...и застрял в сложности его..алго нечто отдалённо напоминающее SAFER
Что на данный момент поятно..Принятый ключик разбивается побайтно и мешается попарно с ключом шифрования 8 байт ..на выходе 16 байт вперемешку. Далее эти 16 байт опускаются в кучу "мусора" представляющуюю тупо набор разных значений байт объёмом около 430 байт и там начинают перемешиваться с использованием различных логических операций посредством приблизительно около 247 проходов по этой куче...на выходе получаем ключ 16 байт из него выбрасываем 8 байт и оставшиеся 8 байт есть ответ. В чём стоит задача? Ведомый девайс старой ревизии и понимает только запросы в диапазоне от 8000 до 8005, а новые работают в диапазоне от 8008 до 800D...вот и нужно старый научить работать по новому диапазону.
Тепрь про саму команду запроса 80хх ..второй байт в этой команде указывает каким ключом дешифровать посланный ключ и помимо этого указывает на точку входа в "мусор" Реально этот "мусор" весит около 2 кило! И соответсвенно имеет разные точки входа/выхода для 16 байт ключа...Вопрос реально ли в этой всей каше просчитать новые ключи шифрования и точки входа/выхода для нового диапазона команд. Если кому интересно помочь мне то могу предоставить все доки и дамп по этой задаче..Так же возможна оплата труда в разумных пределах.

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

r_e пишет:
Это ИДА косячит.

Будь добр подскажи - это ведь очередной косяк ?

ROM_:07AE sub_7AE: ; CODE XREF: sub_9FB:loc_AE7p
ROM_:07AE and word_FE9A+1,#07h ; AND Logical Product of Byte Data
ROM_:07B1 set1 byte_FEF5.0 ; Set Single Bit (Carry Flag) 1 Bit Data Set
ROM_:07B4 ret ; Return from Subroutine


строчка "and word_FE9A+1,#07h" в хексе выглядит так "61 9B 07"

61 - это оператор AND saddr,#byte, с байтом все ясно, но почему адрес 9B(FE9B) ида отдизасмила как FE9A+1 ?

правомерна ли такая замена
ROM_:07AE and 0FE9Bh,#07h ; AND Logical Product of Byte Data

| Сообщение посчитали полезным:

и еще в догонку

ROM_:07F2 set1 MK0.SRMK00 ; Interrupt mask flag register 0

в хексе 0A 46 E4

0a - set1
46 в бине 1000110 (100 - это 4, 0110 - говорит что это SFR)
E4 - это FFE4 - в нашем случае ядра 78k0S регистр SFR - MK0

в итоге получаем "set1 MK0.4"

все правильно ???

| Сообщение посчитали полезным:

И еще вопрос знатокам - вроде причесал весь код - при компиляции, а конкретно на этапе обработки main.rel идет ругань на процедуры которые вызываются оператором CALLT, попробовал заменить их на локальные с вызовом CALL - можно ли делать такую замену или это неправильно ? И что это за этап компиляции ?

и еще после подобной замены на CALL стала вылазить одна ошибка, ранее не вылазившая - вот в этой процедуре:

sub_FA4:
movw BC,#0008h ; Move Word Data Transfer / Word Data Transfer with Stack Pointer

loc_FA7: ; Push
push DE
movw HL,#0FEECh ; Move Word Data Transfer / Word Data Transfer with Stack Pointer
mov A,[HL] ; Move Byte Data Transfer
xch A,X ; Exchange Byte Data Exchange
mov A,[HL+01h] ; Move Byte Data Transfer
movw DE,AX ; Move Word Data Transfer / Word Data Transfer with Stack Pointer
movw HL,#0FEDAh ; Move Word Data Transfer / Word Data Transfer with Stack Pointer

loc_FB3: ; Move Byte Data Transfer
mov A,C
cmp A,B ; Compare Byte Data Comparison
mov A,[DE] ; Move Byte Data Transfer
xor A,[HL] ; Exclusive Or Exclusive Logical Sum of Byte Data
xch A,X ; Exchange Byte Data Exchange
incw DE ; Increment Word Data Increment
mov A,[DE] ; Move Byte Data Transfer
incw DE ; Increment Word Data Increment
xor A,[HL+01h] ; Exclusive Or Exclusive Logical Sum of Byte Data
bc $loc_FC2 ; Branch if Carry Conditional Branch with Carry Flag (CY = 1)
xch A,X ; Exchange Byte Data Exchange

loc_FC2:
mov [HL],A
xch A,X ; Exchange Byte Data Exchange
mov [HL+01h],A ; Move Byte Data Transfer
incw HL ; Increment Word Data Increment
incw HL ; Increment Word Data Increment
dbnz C,$loc_FB3 ; Decrement and Branch if Not Zero Conditional Loop (R1 != 0)
movw AX,DE ; Move Word Data Transfer / Word Data Transfer with Stack Pointer
movw HL,#0FEECh ; Move Word Data Transfer / Word Data Transfer with Stack Pointer
mov [HL+01h],A ; Move Byte Data Transfer
xch A,X ; Exchange Byte Data Exchange
mov [HL],A ; Move Byte Data Transfer
pop DE ; Pop
ret ; Return from Subroutine
; End of function sub_FA4

конкретная строчка - bc $loc_FC2

я так понимаю компиляция идет последовательно и утыкаясь на метку ранее не встречавшуюся (переход вперед) начинает ругаться ? Как побороть эту ситуацию ?

И вообще возможно ли повторно откомпилить в рабочую прошивку исходник полученный после дизасма ИДА ? А то может это вообще нереально, очень непонятно начало исходника:

; Segment type: Pure data
off_0: dw RESET ; RESET
db 0FFh
db 0FFh
INTWDT_: dw 0FFFFh ; INTWDT
INTP0_: dw 0FFFFh ; INTP0
INTP1_: dw 0FFFFh ; INTP1
dw INTP2_ ; INTP2
INTSR_INTCSI0: dw 0FFFFh ; INTSR_INTCSI0
INTST_: dw 0FFFFh ; INTST
dw INTTM0_ ; INTTM0
db 0FFh
db 0FFh
INTTM2_: dw 0FFFFh ; INTTM2
db 0FFh
db 0FFh


что означает оператор "dw" - например в первой строчке "dw RESET" - пока ее не закомментил - шла ругань при компиляции...

Извиняюсь за большое количество вопросов, но решил уж тут спросить не создавая новую тему...

| Сообщение посчитали полезным:

Начни уже пользоваться кнопкой Правка, хватит их лепить подряд.

| Сообщение посчитали полезным:

Androand
Честно говоря, RTFM.
Как ты вообще пытаешься разобрать прошивку, если не читал документацию?

Про поводу косяков иды - я не специалист. Надо брать документацию и сравнивать байты.
Касательно смещений - они могут быть относительные и абсолютные. Возможно, ида и правильно дасмит этот блок.
Блок из dw вначале - это блок "векторов прерываний". В оригинале SDK содержит описание как назначить ту либо иную функцию вектору.

А что касается ассемблирования дампа иды, да и вообще анализа асма - это адское занятие для извращенцев. Я бы перевел это все хотя бы в Си и затем уже оптимизировал и анализировал.

-----
старый пень

| Сообщение посчитали полезным:

Archer пишет:
Начни уже пользоваться кнопкой Правка, хватит их лепить подряд.

извиняюсь, просто думал что повторное сообщение добавится автоматически к предыдущему, если никто не ответил вперед - на многих форумах так и реализовано... впредь буду добавлять сообщения через правку.

r_e пишет:
Как ты вообще пытаешься разобрать прошивку, если не читал документацию?

Что значит не читал ? я каждую спорную команду вручную по байтам по мануалу разбирал... просто хотел удостоверится что правильно все понял.

r_e пишет:
А что касается ассемблирования дампа иды, да и вообще анализа асма - это адское занятие для извращенцев. Я бы перевел это все хотя бы в Си и затем уже оптимизировал и анализировал.

Ну перевод в Си это второй шаг - вначале очень хочется хотя бы на асме получить рабочий вариант - когда заведомо известные байты запроса алгоритмом этой прошивки переведутся в известные байты ответа - вот тогда можно будет говорить что точно известен кусок отвечающий за шифрование и преобразование, просто нет спецов по асму серьезных в команде - вот и получается этот ликбез - я вообще первый раз и ИДА работаю, а азы ассемблера были в институте 15 лет назад Думал что тут народ серьезный и натасканный на ИДА и асм и подскажет что к чему...

| Сообщение посчитали полезным:

Тут народ натасканый по x86 асму, а у тебя несколько иной проц, поэтому так вяло помогают.

-----
Yann Tiersen best and do not fuck

| Сообщение посчитали полезным:

ВСЕ, полностью вылизал отдизасмленный исходник прошивки - теперь после повторной компиляции получается прошивка один-в-один с оригинальной.

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

Просто раз тут нет спецов по МК, то может имеет смысл создать отдельную тему в софте - поскольку теперь вопросов к железяке нет никаких - есть следующее:

1. код на асме
2. есть пары запросов-ответов, которые без проблем обрабатываются этим кодом и таблицей байт
3. есть пары запросов-ответов, которые не получаются при использовании этого кода и таблицы байт

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

| Сообщение посчитали полезным:

Пакуйте исходник и аттачьте здесь.
Не помогают не потому что спецов нет, а потому что вопросы из разряда RTFM.

В идеале исходник перевести в язык высокого уровня. Получится компактней, а значит и легче анализировать.

-----
старый пень

| Сообщение посчитали полезным:

Androand
Попробуй написать прогу на С++, оптимизмровать КОД и проверить, возвожность развернуть АЛГО ! Там Видно буит возможно или нет Просчитать новую таблицу !

| Сообщение посчитали полезным:

r_e пишет:
Пакуйте исходник и аттачьте здесь.

Запаковал в принципе всю сборку - может у кого то есть PM+ и SM+ для ядра 78k0S, тогда можно в симуляторе пошагово наблюдать процесс преобразования, хотя достать эти инструмены не проблема...

если смотреть только исходник, то он внутри - main.asm, основную его часть занимает таблица, реализована имитация получения запроса от консоли и размещение байт запроса в RAM
Запрос 0B 8000 C1EF1FBD294886BA
После отработки теста получается правильный ответ 1206 ABD08FBE6858FCC6

Теперь немного умозаключений, пока игрался в симуляторе и гонял тест понял следующее:

в процессе участвуют:

1. 8 байт ключа которые генерит консоль (в случае теста C1EF1FBD294886BA)
2. область 00EC-015B для хранения 14 ключей по 8 байт (в тесте используется первый - адрес 00EC)
3. область 015С-062D для хранения байтов участвующих в XOR с байтами ключа - 7 областей размером 176 байт каждая (11 шагов по 16 байт), каждая область соответствует строго одному ключу, который определяется вторым байтом 80XX - в нашем случае это 8000 и область 015С-020B
3. область 062С-072B - 256 байт, самая важная область - отсюда берутся байты для основного преобразования функцией sub_EE3 (сдвиги, XOR четырех байтов ключа)

Теперь по алгоритму:

call !sub_78D
addw AX,#00ECh ; 'ü'

тут в зависимости от второго байта команда 80XX определяется адрес ключа, для 8000 это 00EC, для 8004 - это 010С ну и т.д.

call !sub_F81
mov B,#02h
movw AX,#0FEBCh
call !sub_F81

это формирование 16 байт из 8 байт сгенеренных консолью и 8 байт ключа вытащенных из таблицы, причем формируется попарно 1-5, X ,2-6, X ,3-7, X ,4-8, потом вместо X также попарно вставляется ключ от консоли - вот и получилась первая мешанина из двух ключей по 8 байт - итого 16 байт рабочего ключа расположенного в RAM FEDA-FEE9 - именно тут будут формироваться байты ответа

call !sub_C36
вот это основной вход в алгоритм преобразования, внутри модификация байтов рабочего ключа и байтов из таблицы посредством XOR, потом идет ротация байтов в полученном ключе по схеме 6-8, 9-12, 10-11, 13-15, дальше идет сложение каждого полученного байта со смещением 062Ch и получением адреса таблицы из которой выдергивается байт замены, потом все это в четыре прохода обрабатывается путем сдвига и XOR по 4 байта (в первый проход используются 1,5,9,13 байты) - ну и все это повторяется в общей сложности 11 раз

mov B,#00h
movw AX,#0FEBBh
call !sub_F90

ну эти последние три строчки можно и не рассматривать - тут просто байты ответа складываются в правильный вид и переносятся в RAM FEBB-FEC2 , т.е. из 16 байт рабочего ключа формируются 8 байт ответа по схеме:
1-5,9-13,2-6,10-14
и на этом все...

43ca_01.03.2011_CRACKLAB.rU.tgz - minitest.rar

З.Ы. Забыл добавить в этом примере ключ для команды 8004 заменен на FF, может кто то с ходу его воспроизведет из таблицы байт или проанализировав пары запросов-ответов - в исходнике есть парочка...

| Сообщение посчитали полезным:

Ну, осталось совсем немного и можешь статью писать
Переводи теперь это все в си или любой другой ЯВУ.


Дальше будет еще легше.

-----
старый пень

| Сообщение посчитали полезным:

товарищи почему тут никто еще про слово из трех буквы "DES" не вспомнил?
очень похоже на него, на вид выглядит как мусор, легкий и удобный в использовании+ немного в памяти занимает, в 6х6мм точно влезает, да и китайцы его любят.


upd/ AES ru.wikipedia.org/wiki/Rijndael


e9c2_01.03.2011_CRACKLAB.rU.tgz - 78K0S.png

| Сообщение посчитали полезным:

DES сделать можно.
Для AESа ключ маловат, да и таблиц тоже маловато.

-----
старый пень

| Сообщение посчитали полезным:

rr222 пишет:
товарищи почему тут никто еще про слово из трех буквы "DES" не вспомнил?

Так вроде для DES размер ключа 56 бит и 16 циклов, а тут только размер входного блока совпадает - 64 бита, а размер ключа получается 128 бит, поскольку собирается из байт входного блока и ключа из таблицы, хотя может это уже элемент преобразования, но циклов точно не 16

r_e пишет:
Переводи теперь это все в си или любой другой ЯВУ

Ну да осталось теперь до кучи СИ и яву выучить Ты явно для примера выбрал самую простую процедуру - обычный своп переменных - на VB я тоже так могу с полпинка написать, а вот как быть с кусками посложнее, да еще с таблицей этой и эмуляцией RAM - в массивы что ли все загонять ?

И по поводу таблицы, ведь должна какая то зависимость быть между 8 байтами ключа и 11 вариантами по 16 байт участвующими в XOR

ключ - D2072253A4F27468

варианты для цикла
01 - 5CF389EC5282D816D9AC81291CA4787B
02 - 1AE9608CF775ADBBF854D5FCD2760E75
03 - F21B7BF747329F246531E418B6C0CEBB
04 - C0DBA057EAD847638FBE5A42DE1ED06B
05 - 33E8481FC61E593AF04E1456859B4B20
06 - A34B031C7769300A47091D4B45DE95B5
07 - E4AFACB0C4AD9D97929B86CDD9079227
08 - 2C832F9F79D449DE5EC5438E3E39AB8C
09 - B1321D8260B4FD233AFFBC32E5DC77FB
10 - 8CBEA32143F70A2935CA7644F62A5DA6
11 - 1FA1022358AFA58C11DBADE90B217CDA

ведь если это будут любые произвольные байты то результата может не получится или я не прав ?

| Сообщение посчитали полезным:

ключ там фиксированый , при TXEncrypt получается строка D2072253A4F27468

каждый шаг зависит от предыдущего, так как внутри в des ключ ксорится, но вам об этом заморачиватся не нужно как оно там и что делает, вам нужно скорее всего :

initkey (xxxx.. 8 байт) не B7A80076B00587EC а какой-то другой стандартный, в начале всего процесса
вот после инита
zzz= Encript(yyyy) должно дать B7A80076B00587EC

далее уже вы делаете Tx(5A 0B 8004 zzz crc)

0B тут кстати длина пакета, как в ответе "a5 12 06..." 12 это длина

des разные бывают варианты по длине ключа/пакета и тп, скачайте тут и посмотрите хелпы
--> http://www.cityinthesky.co.uk/_media/opensource/dcpcrypt2.zip <-- мне оно очень в свое время помогло... провозившись месяц подобно вашему, вышел всетаки на это..

| Сообщение посчитали полезным: Androand

rr222 пишет:
ключ там фиксированый , при TXEncrypt получается строка D2072253A4F27468

Там - это где ? и строка D2072253A4F27468 никак не получается - она жестко прописана в таблице, как и 11 вариантов по 16 байт - вот я и спрашивал по какой зависимости они формируются из 8 байт или это с потолка набрали байты...


rr222 пишет:
каждый шаг зависит от предыдущего, так как внутри в des ключ ксорится, но вам об этом заморачиватся не нужно как оно там и что делает, вам нужно скорее всего :
initkey (xxxx.. 8 байт) не B7A80076B00587EC а какой-то другой стандартный, в начале всего процесса

initkey конечно не B7A80076B00587EC а именно D2072253A4F27468, поскольку B7A80076B00587EC - это ключ который генерит консоль - это вторая составляющая рабочего ключа в 16 байт, она каждый раз разная а вот initkey стационарный и не меняемый....

rr222 пишет:
zzz= Encript(yyyy) должно дать B7A80076B00587EC

далее уже вы делаете Tx(5A 0B 8004 zzz crc)

0B тут кстати длина пакета, как в ответе "a5 12 06..." 12 это длина


Бред какой то, к чему этот ликбез про длину пакетов ?
И zzz= Encript(B7A80076B00587EC) должно дать 6C8487344210CF9A

Если не понятно то
;5A0B 8004 B7A80076B00587EC 19 - это ЗАПРОС
;A51206 6C8487344210CF9A FAF4513AA460B39F 0D - это ОТВЕТ и нужны в нем первые 8 байт

но в приаттаченном выше примере работает только эта пара:
;5A0B 8000 C1EF1FBD294886BA DD
;A51206 ABD08FBE6858FCC6 2743DFD5C44A8BA3 9E ;

поскольку начальный ключ (initkey в вашей терминологии) для команды 8004 затерт на FF

rr222 пишет:
des разные бывают варианты по длине ключа/пакета и тп, скачайте тут и посмотрите хелпы
--> http://www.cityinthesky.co.uk/_media/opensource/dcpcrypt2.zip <-- мне оно очень в свое время помогло... провозившись месяц подобно вашему, вышел всетаки на это..

А вот за это СПАСИБО!!!

нашел в файле DCPrijndael.inc некую таблицу

T4: array[0..255,0..3] of byte= (
($63,$63,$a5,$c6), ($7c,$7c,$84,$f8), ($77,$77,$99,$ee), ($7b,$7b,$8d,$f6),
($f2,$f2,$0d,$ff), ($6b,$6b,$bd,$d6), ($6f,$6f,$b1,$de), ($c5,$c5,$54,$91),
($30,$30,$50,$60), ($01,$01,$03,$02), ($67,$67,$a9,$ce), ($2b,$2b,$7d,$56),
($fe,$fe,$19,$e7), ($d7,$d7,$62,$b5), ($ab,$ab,$e6,$4d), ($76,$76,$9a,$ec),

так вот ее значения (первые элементы массивов) очень похожи на область 062С-072B
"637C777BF26B6FC53001672BFED7AB76...." - откуда берутся байты для подстановки и дальнейшей модификации - вряд ли это совпадение....

значит это AES-128 ?

| Сообщение посчитали полезным:

Androand да, скорее всего это AES-128



PS Вот остальные таблицы AES'а:




-----
Yann Tiersen best and do not fuck

| Сообщение посчитали полезным: rr222

Ну в общем перелопатил я алгоритм и сбацал программку которая просчитывает ответ для запроса, пытался идти от классического AES-128, но в отладке понял что принцип в батарейке немного другой, ощущение что от AES взяли только таблицу подстановок, 11 раундов и как то механизм изменения байт с хитрым сдвигом и XOR, ну и еще размер - 16 байт входных данных и 16 байт раундового ключа...


в общем весь алг оказался не таким и сложным, но однозначно не понятным


Теперь вопрос знатокам - что же это за AES такой и реально ли просчитать раундовые ключи ? Минус еще в том что оказался неизвестен еще один параметр - 8-ми байтный довесок - при помощи его формируются рабочие 16 байт входных данных - получается что известны только 8 байт из 16 входных и на выходе точно есть правильных 8 байт.

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


8d43_18.03.2011_CRACKLAB.rU.tgz - pspkeygen.vbp

| Сообщение посчитали полезным:

Блин в предыдущем посте прикрепился не тот файл не знаю как вложение отредактировать тут...

251a_18.03.2011_CRACKLAB.rU.tgz - PSPKeyGen.exe

| Сообщение посчитали полезным:

Не кто не знает удалось ли боряну сделать свою чудо батарейку?

| Сообщение посчитали полезным: