Métodos para descobrir algoritmo CRC / Checksum de 16 bits usado pelo executável do Windows CE?

Eu preciso fazer engenharia reversa do algoritmo CRC / Checksum implementado pelo executável do Windows CE. Sendo protocolo propritory, ele não diz nada sobre o algoritmo CRC / checksum. No entanto, existe uma interface de console que informa a soma de verificação correta / calculada e posso construir minhas próprias mensagens com bits aleatórios se o protocolo de mensagem estiver correto:

Eu observei isso,

A alteração do bit único na mensagem altera completamente os bytes da soma de verificação.

O algoritmo parece ser dependente da posição, já que eu alimentei algumas mensagens únicas de 1 bit em várias posições de dados de mensagens com o resto dos bits zero e todo o console do tempo relatou soma de verificação diferente. Se fosse uma soma de verificação aditiva simples, a soma de verificação teria sido idêntica.

Eu apliquei XOR, LRC, algoritmos de soma de verificação aditiva, polinômios comuns de CRC (Standerd, CCITT, X-modem) e passei por [CRC Reverse engineering essay] [2] mas infelizmente não posso passar de deduzir o polinômio porque o tipo de mensagem é fixo não é possível criar uma única mensagem de 1 bit.

Minhas perguntas:

Existe alguma propriedade de algoritmo CRC / soma de verificação que eu possa testar em relação a mensagens para determinar se o algoritmo é de checksum ou CRC baseado em polinômios?

Existe alguma maneira de relacionar a mensagem de erro vista na desmontagem do programa com instruções de montagem de corrosão?

Quais são as maneiras de depurar / identificar o código de desmontagem no momento em que ele relata a soma de verificação correta no console? Despejo de memória ou algo assim?

questionAnswers(1)

yourAnswerToTheQuestion