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.
Gast
#5386233
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.
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.
Gast
#5386479
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
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
Gast
#5404192
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.
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...
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.