Metodi per inchiodare l'algoritmo CRC/checksum a 16 bit utilizzato dall'eseguibile di Windows CE?

Question

Ho bisogno di invertire l'algoritmo CRC/Checksum implementato dall'eseguibile di Windows CE. Essendo un protocollo proproriale, non dice nulla sull'algoritmo CRC/checksum. Tuttavia, v'è l'interfaccia della console che riporta corretto checksum/calcolato e posso costruisco i miei messaggi con bit casuali se il protocollo messaggio è corretto:

ho osservato che,

• Modifica singolo bit nel messaggio cambia byte di checksum completamente.

• Algoritmo sembra essere dipendente dalla posizione in quanto ho alimentato alcuni singoli messaggi a 1 bit in varie posizioni di dati del messaggio con il resto dei bit zero e tutte le console di tempo riportavano checksum differente. Se fosse semplice somma di controllo additiva, il checksum sarebbe stato identico.

ho applicato XOR comune, LRC, additivi algoritmi di checksum, comuni polinomi CRC (Standerd, CCITT, X-modem) e attraversato [CRC Reverse saggio di ingegneria] [2], ma purtroppo non posso andare oltre dedurre la polinomiale perché il tipo di messaggio è fisso, quindi non è possibile creare un singolo messaggio a 1 bit.

Le mie domande:

1. Ci sono le proprietà/checksum algoritmo CRC che posso testare contro i messaggi per determinare se algoritmo è checksum o polinomiale basato CRC?

2. Esiste un modo per collegare un messaggio di errore visualizzato nello smontaggio del programma con istruzioni di montaggio corrosivo?

3. Quali sono i modi per eseguire il debug/pinpoint del codice di disassemblaggio nel momento in cui viene segnalato il checksum corretto sulla console? Discarica della memoria o qualcosa del genere?

Answer 1

Prova CRC RevEng. Alcuni rapidi tentativi con i tuoi dati sono stati infruttuosi, ma non ci ho provato molto. Prova a provare non solo tutti e dieci i byte dei messaggi, ma anche gli ultimi otto e gli ultimi sei.

Inoltre è possibile trovare nello stesso sito lo most comprehensive list of known CRCs di cui sono a conoscenza.

Aggiornamento:

E 'molto probabile che questo è un CRC di qualche tipo, o almeno un funzionamento lineare su GF (2). Ha questa proprietà che i CRC hanno: se due sequenze hanno la stessa esclusiva o, allora i loro CRC hanno anche gli stessi esclusivi. Ad esempio, dai dati (lasciando cadere il prefisso comune, anche se nota che compreso il prefisso o una parte di esso non cambia il risultato):

00000000000122b5^0000000000022421 = 0000000000030694 
0447080a300130A1^0447080a30023635 = 0000000000030694 

e

0447080a300130A1^0447080a30043A36 = 0000000000050a97 
00000000000122b5^0000000000042822 = 0000000000050a97 

Dato questo fatto, ci è un modo per costruire una routine per calcolare il valore di controllo senza determinare se si tratta di un CRC o di quali sono i parametri CRC.

Generare il valore di controllo a 16 bit per tutti i messaggi a bit singolo, ad es.un singolo bit impostato nei sei byte dei dati del messaggio, con il resto dei bit di dati del messaggio zero. Questi messaggi sono un set completo di vettori di base per questo campo lineare. Ce ne sono 48. Genera anche i valori di controllo per un messaggio tutto zero. Hai già un inizio con tutti gli zeri che danno 2020, l'ultimo bit impostato con 22b5, ecc. Esclusivo o il valore di controllo per tutti gli zeri (2020) con ciascuno degli altri. Ora avete 49 valori di cui 48 per i vettori di base e uno è la correzione per il vettore zero (che è probabilmente diverso da zero a causa del condizionamento pre e post di un CRC e dei prefissi). Ad esempio, il valore per il vettore base con l'ultimo bit impostato è 0295.

Ora è possibile utilizzare questi 49 valori per calcolare il valore di controllo per qualsiasi messaggio a sei byte. Esclusivo o insieme i valori per tutti i bit corrispondenti impostati su uno in quel messaggio. Esclusivo o con il valore di controllo per zero. Il risultato sarà il valore di controllo per quel messaggio.