Tip: Reverse-Engineering von CRCs

[Georg A. (georga)]

Falls andere auch ab und an das Problem haben, beim Reverse-Engineering 
fremder Protokolle rauszufinden, mit welcher CRC-Methode das geschützt 
ist: Habe gestern "CRC RevEng: arbitrary-precision CRC calculator and 
algorithm finder" auf http://reveng.sourceforge.net/ entdeckt.

Da muss man fast nicht mehr nachdenken, das Programm findet alles raus. 
Wenn man ahnt, dass es zB. eine CRC32 ist, man aber keine Ahnung hat, 
welches Polynom, welcher Initwert, ob/wie das Ergebnis invertiert wird 
und in welche Richtung die Ein/Ausgabe geschoben wird, alles kein 
Problem...

Konkretes Beispiel: Das WeatherHub-Protokoll, an dem ich gerade sitze. 
Die letzten vier Bytes der Nachricht sind offensichtlich eine Prüfsumme, 
nur welche...

Es braucht nur drei (unterschiedliche) Nachrichten im Hexformat mit der 
CRC am Ende:

msg1=250833c27080f1400000000000c0000000000000000000000000000000000000007 
100549f
msg2=250833c27080f1400000040000c0000000000000000000000000000000000000006 
830f3df
msg3=250833c27080f1400000080000c0000000000000000000000000000000000000004 
3611a1f

Dann einfach

./reveng -w 32 -s $msg1 $msg2 $msg3

und schwupps schon nach <20s:

width=32  poly=0x04c11db7  init=0x29f0f49b  refin=false  refout=false 
xorout=0x00000000  check=0xb901303d  residue=0x00000000  name=(none)

Das Polynom ist Standard, nur der komische Init-Wert nicht... Die 
gesamte Suche über alle CRC32-Möglichkeiten würde single-threaded so 
15-20min dauern.

[Eduard (Gast)]

Der INIT Wert ist nicht "komisch" sondern willkürlich gewählt. Der ist 
oft Null, muss aber nicht.

Ansonsten bleibt festzustellen, dass das Verfahren evident ist, weil CRC 
ja nichts anderes ist, als umgerechnete Information, die observierbar 
ist. Der Trick ist ja nur, die Infor auf mehre Bits zu verteilen, um 
einen Einzelbitfehler auszumerzen.

CRC ist keine Verschlüsselungsmethode.

Man könnte auch einen Scrambler nehmen.

[Georg A. (georga)]

Eduard schrieb:
> Der INIT Wert ist nicht "komisch" sondern willkürlich gewählt. Der ist
> oft Null, muss aber nicht.

Normal ist halt ffffffff oder 0. Dann hätte ich es auch so gefunden. 
Jeder andere Wert klingt stark nach absichtlicher Obfuskation ;)

> CRC ist keine Verschlüsselungsmethode.

Weiss ich... Aber es hilft ungemein, wenn man sie checken kann...

> Man könnte auch einen Scrambler nehmen.

Gibts da auch, der ist mit G3RUH aber Standard, weil das der 
RF-Sendechip selbst macht.

[~Mercedes~ (Gast)]

Danke, Georg!
hey, ein schönes Progamm!

Da sieht man , das CRC "nur" ein cyclic redunance check
ist und keine Hashfunktion, die könnte man dann nicht
rückrechnen.
Trotzdem gibts ja auch bei einer Hashfunktion
Möglichkeiten, da tobt halt ein K(r)ampf. ;-)

mfg

[Christian B. (casandro)]

Für Leute die mehr über die Hintergründe erfahren wollen. Hier gibts 
einen Vortrag vom Easterhegg 2016
https://media.ccc.de/v/eh16-27-how_to_reverese_crcs

[A. S. (Gast)]

Georg A. schrieb:
> Jeder andere Wert klingt stark nach absichtlicher Obfuskation ;)

Oder nach einem anderen Start. Z.b. die ersten 2 Byte nicht, oder schon 
3 Byte (impliziten) Header vorher.

[Georg A. (georga)]

Achim S. schrieb:
> Georg A. schrieb:
>> Jeder andere Wert klingt stark nach absichtlicher Obfuskation ;)
>
> Oder nach einem anderen Start. Z.b. die ersten 2 Byte nicht, oder schon
> 3 Byte (impliziten) Header vorher.

Die 4 Bytes vorher sind immer dieselben (Sync-Word). Aber der 
CRC-Startwert ist offensichtlich abhängig vom Typ des Sensors (2tes Byte 
der Message), also kanns das nicht sein. Die Länge (erstes Byte) hängt 
auch vom Typ ab. Ich habe aber die einfachen Möglichkeiten (mit ohne 
erstes/zweitem Byte) schon probiert, damit wird der Startwert leider 
nicht allgemeingültig. Muss wohl noch etwas rumspielen...