Форум РадиоКот

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

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

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

вот имеющиеся на сегодня данные с трех "передатчиков":

Спойлер

73 07 61 = BA AF 20 05 1C 00 00 00 00 00 00 00 00 00 00 09 0A 00 00 00 00 00 00 80 00 00 00 41 41 00 3C 12 = 71 6D 62 87
73 07 61 = BA AF 40 60 18 00 00 00 00 00 00 00 00 00 00 09 0A 00 00 00 00 00 00 80 00 00 00 41 41 00 3C 12 = 3B 80 07 A9
73 07 61 = BA AF 60 00 16 00 00 00 00 00 00 00 00 00 00 09 0A 00 00 00 00 00 00 80 00 00 00 41 41 00 3C 12 = 01 6D 67 BD
73 07 61 = BA AF 20 05 12 00 00 00 00 00 00 00 00 00 00 09 0A 00 00 00 00 00 00 80 00 00 00 41 41 00 3C 12 = 71 20 62 88

72 4F 1B = BA 9C 60 00 62 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 = 01 30 E7 F6
72 4F 1B = BA 9C 40 62 60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 = D0 13 85 05
72 4F 1B = BA 9C 60 00 5E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 = 01 12 E7 CA
72 4F 1B = BA 9C 20 0B 5E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 = 0B AA EC 80

73 10 07 = 25 41 20 04 1E 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 12 = 47 06 62 4C
73 10 07 = 25 41 40 60 1C 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 12 = 19 20 06 70
73 10 07 = 25 41 60 00 1A 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 12 = 01 6A 66 4E
73 10 07 = 25 41 20 04 18 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 12 = 78 0C 4E 45
знаками равенства я отделил в начале область адреса (я уверен, что это так) и в конце - область контрольной суммы (100% уверенности в назначении этих байтов нет)

будут ли какие-то мысли у уважаемого сообщества?

алгоритм кодрования адреса оказался очень простым, что вызывает у меня подозрения, что и с крутым алгоритмом контрольной суммы тоже производитель не заморочился... однако, попытки пробрутфорсить CRC8, CRC16 и CRC32 при помощи утилиты reveng успеха не принесла...

Обычная КС в пределах одного байта...
Может вариант сигнатуры фрагмента данных (типа того, что описывали для сигнатурных анализаторов)?...

BOB51 писал(а):Может вариант сигнатуры фрагмента данных (типа того, что описывали для сигнатурных анализаторов)

пока это мне ни о чем не говорит...

Млин... подзабыл уже... смысл в получении многобайтовой "цифровой подписи" индивидуальной для любого потока данных...
вроде вот этого:
https://studfiles.net/preview/4354160/page:15/
алгоритм весьма похож на CRC...
http://mirznanii.com/a/208865/proektiro ... nalizatora
Когда-то модным было, сам хотел такую штуку в качестве диагностического тестера логических автоматов соорудить...
Да так и не дошло до реализации...
Даавнееенько то былоо... еще во времена логики-рассыпухи...

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

*Trigger* писал(а):Возможно, тут несколько контрольных сумм для разных частей пакета.

Все-таки ум хорошо, а два - лучше! Спасибо! Подумаю в этом направлении... Там просматривается еще структурированность... Но, блин, 4 последних байта меняются одновременно

CRC32 ?

проги есть всякие Sigrok, Cain & Abel и др. анализаторы протоколов софтверные

На CRC32 это не похоже. Вижу 2 области у чексуммы. С относительно линейными (при малых изменениях 1 байта) свойствами. Они взаимо увязанны, при изменении даже 1 байта меняются обе части.

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

Это наводит на мысль что так может себя вести например нечто типа Adler32, или каких-нибудь флетчеровских сумм. У адлера как раз в процессе счета есть две 16-битных половинки. Но они более сложно увязаны, чтобы не обладать недостатками тривиальных чексум, которые бы плохо работали на таком наборе данных. Так что тут вероятно что-то такое. Было бы логично: не сильно уступает CRC32 по обнаружению ошибок, а считать адлера куда проще, быстрее и/или компактнее по коду.

самые последние 2 байта - это обычный XOR первых 18 двухбайтных слов (ну или это 2 байта XOR етных и нечетных байтов). а вот остальные 2 байта в конце - это уже нечто загадочное...