Взлом протокола обмена, определение алгоритма подсчета CRC Опции

[Baser]

У меня вот такой

Судя по всему это Rev.N
У него бутлодер v1.10 - дырка там есть, и эти ревизии производят до сих пор.

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

[k155la3]

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

I D A отлично разбирается с кодом MSP430. Достаточно будет добраться до нижнего уровня формирования пакета. Пара дней максимум.
Далее взять тотже процессор и "рестартовать" клона уже на HW.

[ARV]

К сожалению, семейство MSP430 для меня абсолютно неизвестное, никаких средств для работы с ним нет И даже по поводу ревизии я не понял - как её определить? Что за баг в бутлодыре, какие указания? Боюсь, что в разумное время я ответы на все эти вопросы не найду.

[k155la3]

К сожалению, семейство MSP430 для меня абсолютно неизвестное, никаких средств для работы с ним нет И даже по поводу ревизии я не понял - как её определить? Что за баг в бутлодыре, какие указания? Боюсь, что в разумное время я ответы на все эти вопросы не найду.

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

[ARV]

Способы выделения полей в пакете в общих чертах мне известны, и какой-то успех в этом направлении есть. Но задача у меня стоит прежняя: научиться подсовывать свои данные в пакет. То поле, которое надо менять - поле адреса, - я уже вычленил на 100% в пакете. Остается совсем "пустяк" - подсунуть новый адрес в пакет так, чтобы приемник не заподозрил подвоха. И тут, к несчастью, знание остальных полей пакета очень мало поможет...

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

[k155la3]

. . . И тут, к несчастью, знание остальных полей пакета очень мало поможет...

Тут чем больше известной информации, тем лучше.
Ну, самый примитив - попробуйте поменять байты в последниих парах байт, может big-little endian - "счастливый случай"
и прогоните по стандартным CRC.
Поскольку здесь отмечали, что при изменении данных КС меняется "не очень", то возможно
в поледних 4 байтах сидит нечто CRC16, а в "лишних" 16 битах случайное число или шифр-код (это те биты, которые не меняются).
Для этого надо смотреть на бинарное представление этих 4 байт в выборке пакетов, смотреть "столбиком".
Возможно увидите "замерзшие" колонки нуля или единицы.
Это может быть ключ кодирования, общий для приемника и передатчиков.

[halfdoom]

Остается совсем "пустяк" - подсунуть новый адрес в пакет так, чтобы приемник не заподозрил подвоха.

А вы пробовали просто менять адрес и передавать остаток пакета как есть? Мне попадался счетчик, который при работе по IRDA протоколу анализировал поле адреса, в котором последним байтом шла КС адреса, а затем отдельно считал КС для оставшихся данных.

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

[ARV]

При помощи reveng я пробовал перебор (т.е. брутфорс) 8, 16, 24 и 32-битные варианты CRC для:
- полного пакета
- полного пакета с инверсией
- пакета без адреса
- пакета без адреса и без 1-2 байт в начале
- пакета без адреса и без 1,2,3 и 4 байт в конце
- пакет с адресом и без 1,2,3 и 4 байт в конце
- пакет без байта, находящегося перед предполагаемой КС и всегда имеющим значение 12
- пакет с адресом и без, у которого из 4 последних байт удалены четные или нечетные байты
все предыдущие варианты показали, что ВСЕ полиномы с начальным обнулением "регистра" и с заполнением, а так же с XOR в конце и без него, не подходят...

[Сергей Борщ]

При помощи reveng я пробовал перебор (т.е. брутфорс) 8, 16, 24 и 32-битные варианты CRC

Уже много раз писали, что это не CRC. У CRC при изменении пары битов в сообщении никогда не будет изменения пары же битов в контрольной сумме - их будет значительно больше. Так что пробуйте что-то более простое - исключающее "ИЛИ", сумму, сумму с исключающим "ИЛИ", сумму с дополнением до нуля или другого числа и т.п.

[ARV]

Так там и нет изменения пары битов, там все 4 байта меняются.

734F33656A 2000 6C 7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C000012 0199381C
734F33656A 4000 6C 7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C000012 03D0387E

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

Есть странная закономерность, но не могу понять, к чему она может привести: в последних 4 байтах всех пакетов одного и того же транспондера четные и нечетные байты слева направо связаны друг с другом.
Поясняю примером ABCD - 4 последних байта. Так вот, любому значению байта А всегда будет соответствовать одно и то же значение байта C, а для В соответственно D. Но обратной связи нет, т.е. к одному и тому же байту С могут "приводить" разные байты А.

[k155la3]

. . . . Может, я просто не знаю, как надо и пытаюсь изобрести велосипед?

Мы все тут "не знаем как надо", поскольку этот процесс называется криптоаналитика, крутая весч основанная на математике, алгоритмах кодирования-декодирования, разделы мат. статистики и вероятностях и тд. Ну и мощных компах. А кто знает - помалкивает
---
Я Вам предлагал поискать описание системы и сертификат на ее безопасность-защищенность. Если ОН подразумевает шифрование (даже не пакета а только контрольного кода), то на мой взгляд разобраться не получится.
Можно было бы "погрузить" приемник бутфорсом пакетами с нулевыми байтами данных и "подбираемой" КС из 4 байт.
При таймауте "отзыва" приемника 1с на это уйдет сотня лет Через 100 лет мы имеем статистический массив "правильных" пакетов всего лишь для одного (!) набора данных
---
Для начала все-же проверьте все поля пакета на "замерзшие" на одних позициях биты.
ps - и их "взаимозависимость" / корреляцию между собой (это по поводу ABCD)

[ARV]

Я умом понимаю сложность задачи... но надеюсь еще пока на успех.
Не знаете какой-то софт, который бы позволял как-то автоматизировать хотя бы то, что вы посоветовали (а своих идей у меня тоже не мало)? Ну, например, быстро переводить HEX-строку в бинарный вид, инвертировать, XOR-ить и т.п. манипуляции делать? Основное время уходит именно на ручное преобразование и расписывание карандашиком...

Для логического анализатора софт вроде как весьма помог, но почему разработчики этого софта не додумались делать "стек" захваченных сигналов, чтобы можно было визуально сравнивать "этот" и "тот" или "пред-предыдущий"? И экспорт тоже та еще беда: для одной программы надо строку в том виде, как я тут привожу, т.е. без префиксов 0x, а лог.анализатор пишет с префиксами, да еще в CSV-таблице... пока вручную переформатируешь...

Я, конечно, что-то пописываю сам себе в помощь, но ведь на каждый случай утилитку писать тоже не самый оптимальный вариант по усилиям и срокам. Неужели ничего готового нет?

Если ОН подразумевает шифрование (даже не пакета а только контрольного кода), то на мой взгляд разобраться не получится.

Это, будучи в отрыве от реальности, безусловно верно. Но логическое размышление не находит причин, по которым идентификатор коровы должен передавать инфу о том, активно она жует или нет, в зашифрованном виде... Да и тот факт, что адрес передается полностью в "сыром" виде (правда, старшими байтами вперед), как-то с шифрованием уже не вяжется...

[_pv]

последние два байта - тупо xor от первых 18ти 16ти битных слов

Код

734F33656A 2000 6C 7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C00001201 99 381C
hex($734F xor $3365 xor $6A20 xor $006C xor $7B7B xor $7B7B xor $7B7B xor $7B7B xor $7B7B xor $7B00 xor $0C0C xor $0C0C xor $0C0C xor $0C0C xor $0C0C xor $0C0C xor $0000 xor $1201)
 $381C 

734F33656A 600C 6C 7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C00001283 02 34DE
hex($734F xor $3365 xor $6A60 xor $0C6C xor $7B7B xor $7B7B xor $7B7B xor $7B7B xor $7B7B xor $7B00 xor $0C0C xor $0C0C xor $0C0C xor $0C0C xor $0C0C xor $0C0C xor $0000 xor $1283)
 $34DE 

724F1BBA9C 4162 10 0000000000000001000002000081840000000000000000005C3C12FD 79 5FE5
hex($724F xor $1BBA xor $9C41 xor $6210 xor $0000 xor $0000 xor $0000 xor $0001 xor $0000 xor $0200 xor $0081 xor $8400 xor $0000 xor $0000 xor $0000 xor $0000 xor $5C3C xor $12FD)
 $5FE5 

[ARV]

последние два байта - тупо xor от первых 18ти 16ти битных слов

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

я-то тупил на байте 12 перед 4-я последними - он всегда и во всех пакетах на одном и том же месте...

[k155la3]

Я умом понимаю сложность задачи... но надеюсь еще пока на успех.
. . .
Неужели ничего готового нет?

"Готовое" есть, но в "очень специальных местах", где сидят "специальные" люди и чтут УК.
Можете посмотреть на github.com - искать "cryptoanalyze".
----
Вы тут помянули "идеи". Еще одна Возможно в контрольном коде используется какой либо корректирующий-исправляющий код
вроде Хемминга. Ну, а если "идеи" не требуются - то удачи

ps вот КС в бинарном виде. Переводил вручную, возможны ошибки.

Код

0000 0001 0011 0000 1110 0111 1111 0110        01 30 E7 F6
1101 0000 0001 0011 1000 0101 0000 0101        D0 13 85 05
0000 0001 0001 0010 1110 0111 1100 1010        01 12 E7 CA
0000 1011 1010 1010 1110 1100 1000 0000        0B AA EC 80
0100 0111 0000 0110 0110 0010 0100 1100        47 06 62 4C
0001 1001 0010 0000 0000 0110 0111 0000        19 20 06 70
0000 0001 0110 1010 0110 0110 0100 1110        01 6A 66 4E
0111 1000 0000 1100 0100 1110 0100 0101        78 0C 4E 45
0111 0001 0110 1101 0110 0010 1000 0111        71 6D 62 87
0011 1011 1000 0000 0000 0111 1010 1001         3B 80 07 A9
0000 0001 0110 1101 0110 0111 1011 1101        01 6D 67 BD
0111 0001 0010 0000 0110 0010 1000 1000        71 20 62 88
0000 0001 1001 1001 0011 1000 0001 1100        0199381C
0000 0011 1101 0000 0011 1000 0111 1110         03D0387E

psps
функция С для преобразования int или long из бинарного вида в символьный
itoa(src,ascptr,2) ltoa(src,ascptr,2)