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

Немного описания:
полный цыкл передачи - 200 бит (25 байт)
первые 16 бит(два байта) синхронизация 00000011 01000010 (С042h)
дальше 176 бит (22 байта) - данные
последние 8бит (1 байт)проверка

вид самого потока:

Увеличить

а это поток:
sam_potok.zip

Проверял CRC8, разными полиномами, не подобрал, простое сумирование по модулю 2 или 256 тоже не подходит....

Буду благодарен любой конструктивной помощи!

у crc может не быть порождающего полинома, если есть возможность произвольно менять биты в потоке попробуйте составить порождающую матрицу.

Это поток который выдает "железка", поменять к сожелению ничего в нем не возможно.
Пробовал эмулировать этот поток: пока передаються пакеты записаные ранение (например, тот который, здесь представлен) - программа обработки реагирует так как надо; как только меняеш хотя б один бит програма говорит что устройство не опознано и отказывается обрабатывать пакеты.
Судя по тому что находиться в железке (интеловская однокристалка) - алгоритм проверки данных должен быть не очень сложным и громоздким.Все простые способы были проверены от простого сложения по модулю до CRC с 8-мю разрядами. Не один вариант не совпадает с значением предпологаемого проверочного поля. При расчете CRC были проверены все распостраненные полинимы, изменялась длинна расчета (включался/исключался заголовок) все равно не получаеться совпадений....

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

Увеличить
как видно изменения одного бита данных на разных позициях приводит к совершенно разному изменению проверочного поля....
Ни чего толкового в голову не приходит

mandgusta
приводит к совершенно разному изменению проверочного поля....
Может использована ХЭШ-функция?

crc8:
ваша посылка:
10001001000100001...
матрица:(по количеству бит посылки)
24, 45, 63, 124, ...
начальное значение crc = 55
если первый бит посылки равн 1 ксорите значение из таблички с crc, если = 0 пропускаете и переходите к сл.

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

cryptomaster Может использована ХЭШ-функция? думаю, наврят ли.... там чего-то простое должно быть. Попробую вычислить по тому рецепту который XOR предоставил...Только проблемка будет заставить железку изменить все биты по очереди...

скорее всего так и будет, с перехода 95 -> 96 меняется много бит сразу, тогда надо делать несколько начальных значений crc, допустим для пакетов с D1 одно для 14 другое.

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

Кроме начального значения нам надо еще и знать образующий полином.... как его определить? Кроме того я не уверен что здесь вообще применяеться алгоритм CRC....

я перебрал полиномы

0x07 / 0xE0 / 0x83
0x31 / 0x8C / 0x98
0xD5 / 0xAB / 0xEA
0x1D / 0xB8 / 0x8E

но не один не подходит, для всех менял начальное значение от 0х00 до 0хFF. Полином 0х31 дает результат 0х02 при начальном 0хFF для пакетов у которых в проверке и стоит 0х02, но больше никаких совпадений нет....

Может, имеет смысл дизасмнуть/залезть дебаггером в саму проверяющую программу? :)

берем два пакета отличающиеся одним битом
C042150000000064230000071500009897000000010100F0 BA
C042150000000064230000071500009897000000010100F1 E4

ксорите BA с E4 получаете 5Е, это значение для мл бита в последнем байте
аналогично поступаете с другими парами, в вашей записи их 6

F1 5E
95 43
15 68
21 8C
22 01
24 02

потом берете посылку
C042150000000064230000071500009897000000010100F0 BA
в ней установлены биты значения которых 01 8С 68 43

ксорите BA со значениями установленных бит и получаете начальное
значение crc для посылки со сброшенными битами
C042150000000064200000071400009896000000010100F0 1С

теперь устанавливая в этой посылке биты будете ксорить 1C теми значениями бит которые хотите установить.
аналогично для посылки 15 D1.

XOR, таким образом, у меня набереться некий набор значений для всех изменяющихся бит?
Проблема в том, то фрагмент записи который я предоставил записан при работе железки в неактивном режиме. В активном режиме у нее изменяються 9-10 байт независимо друг от друга со значениями от 0х00 до 0xFF. прийдеться строить на все варианты значений. Причем изменеия могут быть как последовательными так и скачкообразными.

да, у вас должна получиться матрица

unsigned char matrix [] ={
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x01, 0x8С,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x68,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x43,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x5E};


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

Полином 0x31, начальное заполнение 0x7B, переворот битов в байте (байт обрабатывается, начиная с младшего бита), переворот битов в остатке (остаток записывается, начиная с мл. бита).

Остаток после вычисления CRC = 0x00.

zhabazhab перебором нашли?

zhabazhab, насколько вас понял, байты переворачиваються, младшими разрядами вперед?
ПРОБУЮ!

До 16 битов быстрее всего работает перебор. Есть софт самописный для этого.

При подборе CRC необходимо учитывать степени свободы (из личного опыта): произвольное начальное заполнение регистра, переворот битов в байте (abcd efgh -> hgfe dcba), переворот четвёрок битов (abcd efgh -> efgh abcd), XOR выходного значения с константой и т.п.

Для нахождения полинома после устранения степеней свободы можно сделать так:

CRC формируется как остаток r(x) от деления полинома x^n×m(x) на порождающий полином g(x), где m(x) - полином исходного сообщения, g(x) - порождающий полином циклического кода, n - степень порождающего полинома g(x).

Сумма x^n×m(x)+r(x) делиться на g(x) без остатка.

По алгоритму Евклида найдём НОД между двумя полиномами (двумя блоками данных с CRC): полином представляется в виде списка степеней, при сложении одинаковые степени вычёркиваются. Степени нумеруются от 0 (единица) до n.

Этот НОД и будет искомым полиномом CRC.

ПОЛУЧИЛОСЬ!
Большое спасибо всем кто помогал! Железка не различает, где софт фирменный а где самописный. Мы так же делали перебор полиномов и начальных установок СRC, но переворачивание разрядов почему-то ни мне ни моим коллегам в голову не пришло. Как только переделали по рецепту zhabazhab, все сразу стало на свои места!
Задача решена, тему можно закрывать!
Еще раз спасибо всем кто помог!

zhabazhab
Приятно читать разумного человека.

реверсивный полином 31 8с, начальное значение для него de, и не потребуется переворачивать биты в остатке.

XOR, можно и так. Хотя лишний переворот для РС-шки сути не поменяет.
Для контролера, можно было б и извращаться с оптимизацией и укорочением кода, но для РС,
думаю не стоит... Всеравно спасибо за совет.
Тем более что "железка"приняла нашу программку как родную и стала
послушной и ласковой :-D. Заказчик доволен, мы, естественно - тоже....

zhabazhab
получилось)) переворот четвёрок битов (abcd efgh -> efgh abcd), спасибо за подсказку))

XOR

Так это вы Uniden ковыряете?

Rulez Reloaded
нет, беспроводной датчик от метеостанции