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

сам обмен идет всегда в одну сторону, передатчик сообщает свой адрес и некий набор данных. протокол я проснифил, но по внешнему виду в каждом пакете есть контрольная сумма в конце. я пришел к такому выводу по тому, что когда в пакете меняется буквально 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 успеха не принесла...

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

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

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

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

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.

Подробнее>>

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

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

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

CRC32 ?

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

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

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

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

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