Возникла необходимость взломать некий протокол обмена данными. Никакого криминала, просто протокол закрытый, передача инфракрасным лучом, нужно научиться передавать собственные данные, чтобы фирменный приемник не замечал подвоха.
сам обмен идет всегда в одну сторону, передатчик сообщает свой адрес и некий набор данных. протокол я проснифил, но по внешнему виду в каждом пакете есть контрольная сумма в конце. я пришел к такому выводу по тому, что когда в пакете меняется буквально 1 бит, в конце пакета меняется сразу 4 байта.
теперь вопрос знатокам: как определить алгоритм подсчета этой контрольной суммы, чтобы иметь возможность формировать свои пакеты со своими данными? существуют ли какие-то специальные утилиты для этого? может, есть какой-то метод? после 8-часового ломания головы я пока что в тупике.
вот имеющиеся на сегодня данные с трех "передатчиков":
алгоритм кодрования адреса оказался очень простым, что вызывает у меня подозрения, что и с крутым алгоритмом контрольной суммы тоже производитель не заморочился... однако, попытки пробрутфорсить CRC8, CRC16 и CRC32 при помощи утилиты reveng успеха не принесла...
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Млин... подзабыл уже... смысл в получении многобайтовой "цифровой подписи" индивидуальной для любого потока данных... вроде вот этого: https://studfiles.net/preview/4354160/page:15/ алгоритм весьма похож на CRC... http://mirznanii.com/a/208865/proektiro ... nalizatora Когда-то модным было, сам хотел такую штуку в качестве диагностического тестера логических автоматов соорудить... Да так и не дошло до реализации... Даавнееенько то былоо... еще во времена логики-рассыпухи...
Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.
Повбивал немного значения в калькулятор, заметил вот что: XOR первых 5 байт всегда равен 0. Возможно, тут несколько контрольных сумм для разных частей пакета.
_________________ Этот пост оказался полезен? Не поленись, нажми слева!
Куплю индикаторы ИТС-1А, ИТС-1Б, ИГВ1-8х5Л, ИГПС1-222/7, ИГПС1-111/7 и подобные.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Возможно, тут несколько контрольных сумм для разных частей пакета.
Все-таки ум хорошо, а два - лучше! Спасибо! Подумаю в этом направлении... Там просматривается еще структурированность... Но, блин, 4 последних байта меняются одновременно
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
На CRC32 это не похоже. Вижу 2 области у чексуммы. С относительно линейными (при малых изменениях 1 байта) свойствами. Они взаимо увязанны, при изменении даже 1 байта меняются обе части.
Чексумм не для разных частей пакета: даже при изменении 1 байта меняются обе половинки, так что эта версия выглядит неправдоподобно.
Это наводит на мысль что так может себя вести например нечто типа Adler32, или каких-нибудь флетчеровских сумм. У адлера как раз в процессе счета есть две 16-битных половинки. Но они более сложно увязаны, чтобы не обладать недостатками тривиальных чексум, которые бы плохо работали на таком наборе данных. Так что тут вероятно что-то такое. Было бы логично: не сильно уступает CRC32 по обнаружению ошибок, а считать адлера куда проще, быстрее и/или компактнее по коду.
самые последние 2 байта - это обычный XOR первых 18 двухбайтных слов (ну или это 2 байта XOR етных и нечетных байтов). а вот остальные 2 байта в конце - это уже нечто загадочное...
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 25
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения