Como eu podia adivinhar um algoritmo de soma de verificação?

Question

Vamos supor que eu tenho alguns pacotes com um checksum de 16 bits no final. Gostaria de adivinhar qual checksum algoritmo é utilizado.

Para começar, a partir de dados de despejo eu posso ver que uma mudança byte na carga útil do pacote muda totalmente a soma de verificação, para que eu possa supor que não é algum tipo de XOR simples ou soma.

Então eu tentei diversas variações de CRC16 , mas sem muita sorte.

Esta questão pode ser mais inclinado para criptografia, mas eu estou realmente interessado em qualquer fácil de entender ferramentas estatísticas para descobrir quais CRC seria essa. Eu poderia até virar para desenho diferentes algoritmos CRC se tudo mais falhar.

Backgroud história: Eu tenho protocolo RFID série com algum tipo de soma de verificação. Posso reproduzir mensagens sem problema, e interpretar resultados (sem verificação checksum), mas não pode enviar pacotes modificados por causa do dispositivo desce-los no chão.

Usando o software existente, eu posso mudar carga de chip RFID. No entanto, o número de série único é imutável, então eu não tenho capacidade de verificar todas as combinações possíveis. Allthough eu poderia gerar despejos de valores incrementado por um, mas não o suficiente para fazer pesquisa exaustiva aplicável a este problema.

arquivos de despejo com dados estão disponíveis se a própria pergunta não é suficiente: -)

Precisa de documentação de referência? A PAINLESS GUIA PARA CRC ERRO Algoritmos de Detecção é grande referência que eu encontrei depois de pedir pergunta aqui.

No final, dica depois de muito útil na resposta aceita do que do CCITT, I usou este CRC calculadora e XORed soma de verificação gerada com soma de verificação conhecidos para obter 0xffff que me levou a conclusão de que xor final é instread 0xffff de CCITT de 0x0000.

Answer 1

Há uma série de variáveis ??a considerar para a CRC:

Polynomial
No of bits (16 or 32)
Normal (LSB first) or Reverse (MSB first)
Initial value
How the final value is manipulated (e.g. subtracted from 0xffff), or is a constant value

CRCs típicas:

LRC:    Polynomial=0x81; 8 bits; Normal; Initial=0; Final=as calculated
CRC16:  Polynomial=0xa001; 16 bits; Normal; Initial=0; Final=as calculated
CCITT:  Polynomial=0x1021; 16 bits; reverse; Initial=0xffff; Final=0x1d0f
Xmodem: Polynomial=0x1021; 16 bits; reverse; Initial=0; Final=0x1d0f
CRC32:  Polynomial=0xebd88320; 32 bits; Normal; Initial=0xffffffff; Final=inverted value
ZIP32:  Polynomial=0x04c11db7; 32 bits; Normal; Initial=0xffffffff; Final=as calculated

A primeira coisa a fazer é obter algumas amostras, alterando dizem que o último byte. Isso irá ajudá-lo a descobrir o número de bytes no CRC.

É este um algoritmo de "caseiro". Neste caso, ele pode levar algum tempo. Caso contrário, tente os algoritmos padrão.

Tente alterar tanto o MSB ou LSB do último byte, e ver como isso muda o CRC. Isto lhe dará uma indicação da direção.

Para torná-lo mais difícil, existem implementações que manipulam o CRC de modo que não afetará o meio de comunicação (protocolo).

Desde o seu comentário sobre RFID, isso implica que o CRC é comunicações relacionadas. Normalmente CRC16 é usado para comunicações, embora CCITT também é usado em alguns sistemas.

Por outro lado, se este é UHF etiquetagem RFID, então existem alguns esquemas CRC - a 5 bit um e alguns mais de 16 bits. Elas estão documentadas nas normas ISO e as folhas de dados IPX.

IPX:  Polynomial=0x8005; 16 bits; Reverse; Initial=0xffff; Final=as calculated
ISO 18000-6B: Polynomial=0x1021; 16 bits; Reverse; Initial=0xffff; Final=as calculated
ISO 18000-6C: Polynomial=0x1021; 16 bits; Reverse; Initial=0xffff; Final=as calculated
    Data must be padded with zeroes to make a multiple of 8 bits
ISO CRC5: Polynomial=custom; 5 bits; Reverse; Initial=0x9; Final=shifted left by 3 bits
    Data must be padded with zeroes to make a multiple of 8 bits
EPC class 1: Polynomial=custom 0x1021; 16 bits; Reverse; Initial=0xffff; Final=post processing of 16 zero bits

Aqui está a sua resposta !!!!

Tendo trabalhado através de seus registros, o CRC é o CCITT. O primeiro byte 0xd6 é excluído do CRC.

Answer 2

Você teria que tentar cada checksum algoritmo possível e ver qual gera o mesmo resultado. No entanto, não há garantia de que o conteúdo que foi incluído na soma de verificação. Por exemplo, alguns algoritmos ignorar espaços em branco, que levam a resultados diferentes.

Eu realmente não vejo por que alguém iria querer saber que embora.

Answer 3

Não pode ser um CRC, pode ser um código de correção de erros como Reed-Solomon.

códigos ECC são muitas vezes uma fração substancial do tamanho dos dados originais que protegem, dependendo da taxa de erro que deseja manipular. Se o tamanho das mensagens é mais do que cerca de 16 bytes, 2 bytes de ECC não seria suficiente para ser útil. Então, se a mensagem for grande, você é mais provável correto que sua algum tipo de CRC.

Answer 4

Eu estou tentando quebrar um problema semelhante aqui e eu encontrei um site bastante elegante que terá seus checksums de arquivo e rodar nele com 47 algoritmos diferentes e mostrar os resultados. Se o algoritmo usado para calcular o checksum é qualquer um desses algoritmos, você poderia simplesmente encontrá-lo na lista de checksums produzidas com uma pesquisa de texto simples.

O site é https://defuse.ca/checksums.htm