Методы определения 16-битного алгоритма CRC / Checksum, используемого исполняемым файлом Windows CE?
Мне нужно перепроектировать алгоритм CRC / Checksum, реализованный исполняемым файлом Windows CE. Будучи пропротокольным протоколом, он ничего не говорит об алгоритме CRC / контрольной суммы. Однако есть консольный интерфейс, который сообщает правильную / вычисленную контрольную сумму, и я могу создавать свои собственные сообщения со случайными битами, если протокол сообщений правильный:
Я заметил это,
Изменение одного бита в сообщении полностью меняет байты контрольной суммы.
Алгоритм, похоже, зависит от позиции, так как я подавал несколько однобитовых сообщений в различных позициях данных сообщений, остальные биты равны нулю, и консоль все время сообщала разные контрольные суммы. Если бы это была простая аддитивная контрольная сумма, контрольная сумма была бы идентична.
Я применил общие алгоритмы XOR, LRC, Аддитивные контрольные суммы, общие полиномы CRC (Standerd, CCITT, X-модем) и прошел [эссе обратного инжиниринга CRC] [2], но, к сожалению, я не могу пройти мимо вывода полинома, потому что тип сообщения фиксирован, поэтому не может создать одно 1-битное сообщение.
Мои вопросы:
Существуют ли какие-либо свойства алгоритма CRC / контрольной суммы, которые я могу проверить по сообщениям, чтобы определить, является ли алгоритм CRC контрольной суммы или полиномиальной?
Есть ли способ связать сообщение об ошибке в разборке программы с соответствующей инструкцией по сборке?
Как можно отлаживать / точно определять код разборки в тот момент, когда он сообщает правильную контрольную сумму на консоли? Дамп памяти что ли?