Методы определения 16-битного алгоритма CRC / Checksum, используемого исполняемым файлом Windows CE?

Мне нужно перепроектировать алгоритм CRC / Checksum, реализованный исполняемым файлом Windows CE. Будучи пропротокольным протоколом, он ничего не говорит об алгоритме CRC / контрольной суммы. Однако есть консольный интерфейс, который сообщает правильную / вычисленную контрольную сумму, и я могу создавать свои собственные сообщения со случайными битами, если протокол сообщений правильный:

Я заметил это,

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

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

Я применил общие алгоритмы XOR, LRC, Аддитивные контрольные суммы, общие полиномы CRC (Standerd, CCITT, X-модем) и прошел [эссе обратного инжиниринга CRC] [2], но, к сожалению, я не могу пройти мимо вывода полинома, потому что тип сообщения фиксирован, поэтому не может создать одно 1-битное сообщение.

Мои вопросы:

Существуют ли какие-либо свойства алгоритма CRC / контрольной суммы, которые я могу проверить по сообщениям, чтобы определить, является ли алгоритм CRC контрольной суммы или полиномиальной?

Есть ли способ связать сообщение об ошибке в разборке программы с соответствующей инструкцией по сборке?

Как можно отлаживать / точно определять код разборки в тот момент, когда он сообщает правильную контрольную сумму на консоли? Дамп памяти что ли?

Ответы на вопрос(1)

Ваш ответ на вопрос