データ+ CRCからCRCアルゴリズムを決定-組み込みアプリケーション。
https://stackoverflow.com/questions/401231
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
修正が必要な16ビットチェックサムで保護された一連のデータがあります。チェックサムの場所は既知であり、それらが計算される正確な領域とそれらを計算するために使用される正確なアルゴリズムは不明です。 16ビット、LSBファースト。何らかの16ビットCRCであると思われますが、実際にチェックサムを計算しているコードを見つけることができませんでした。
例：
00 4E00FFFF26EC14091E00A01830393630
10 30313131313030393030363030313030
20 30303131313030393030363030313030
30 30303131313030393030363030313030
40 3030FFFF225E363436304D313037**0CE0**
50 64000000000000008080808080800000
60 00000000**BE6E**FC01E001EB0013010500
チェックサムは4Eと64に保存されます。各データセクションの先頭の最初の単語のオフセットから計算されるか、それ以降から計算されるか、または範囲全体で計算されるかはわかりません。私は運のない多くの一般的なCRCアルゴリズムと多項式を試しました。このアプリケーションに利用可能な参照または仕様はありません。
比較のために、CRCが異なる別のデータセクションがあります。
00 4E00FFFF26C014091600A01030393132
10 30313131313030393030313230313030
20 30303131313030393030313230313030
30 30303131313030393030313230313030
40 3030FFFF225E343231324F313044**8348**
50 64000000000000008080808080800000
60 00000000**72F8**E001EB00130105000E01
私の質問は、誰でもアルゴリズムを特定できるのですか？データとCRCからCRC多項式と他の要因を計算する方法はありますか？
ありがとう！
編集：
一般的なCRC16多項式0xA001の逆アセンブリを検索すると、次の機能が明らかになりました。
34F86 ; =============== S U B R O U T I N E =======================================
34F86
34F86
34F86 Possible_Checksum: ; CODE XREF: MEM_EXT_4:00034FEEP
34F86 ; MEM_EXT_4:0003503AP ...
34F86 mov [-r0], r9 ; Move Word
34F88 mov r4, r12 ; Move Word
34F8A mov r5, r13 ; Move Word
34F8C shr r4, #14 ; Shift Right
34F8E shl r5, #2 ; Shift Left
34F90 or r5, r4 ; Logical OR
34F92 mov r4, r12 ; Move Word
34F94 mov DPP0, r5 ; Move Word
34F98 and r4, #3FFFh ; Logical AND
34F9C movb rl3, [r4] ; Move Byte
34F9E mov DPP0, #4 ; Move Word
34FA2 movbz r9, rl3 ; Move Byte Zero Extend
34FA4 mov r15, #0 ; Move Word
34FA6
34FA6 loc_34FA6: ; CODE XREF: MEM_EXT_4:00034FC8j
34FA6 mov r4, [r14] ; Move Word
34FA8 xor r4, r9 ; Logical Exclusive OR
34FAA and r4, #1 ; Logical AND
34FAC jmpr cc_Z, loc_34FBA ; Relative Conditional Jump
34FAE mov r4, [r14] ; Move Word
34FB0 shr r4, #1 ; Shift Right
34FB2 xor r4, #0A001h ; Logical Exclusive OR
34FB6 mov [r14], r4 ; Move Word
34FB8 jmpr cc_UC, loc_34FC0 ; Relative Conditional Jump
34FBA ; ---------------------------------------------------------------------------
34FBA
34FBA loc_34FBA: ; CODE XREF: MEM_EXT_4:00034FACj
34FBA mov r4, [r14] ; Move Word
34FBC shr r4, #1 ; Shift Right
34FBE mov [r14], r4 ; Move Word
34FC0
34FC0 loc_34FC0:
解決
loc_34FA6から投稿したコードは基本的に次のとおりです。
unsigned short
crc16_update(unsigned short crc, unsigned char nextByte)
{
crc ^= nextByte;
for (int i = 0; i < 8; ++i) {
if (crc & 1)
crc = (crc >> 1) ^ 0xA001;
else
crc = (crc >> 1);
}
return crc;
}
これは、0xA001多項式を持つCRC-16です。 CRC-16が適用されるデータの範囲を見つけたら、CRCを0xFFFFに初期化し、シーケンスの各バイトに対してこの関数を呼び出します。戻り値を保存し、次回にそれを返します。最後に返される値は最終的なCRCです。
プロローグが何をしているかわからない...
他のヒント
より一般的には、CRCの概念の一部は、データファイルのCRCを計算し、最後にCRCを追加すると、CRCの長さがファイルの長さに依存する値になるということです。ファイルですが、内容ではありません。 （一部のCRCアルゴリズムでは、ファイルの長さにも依存しません。）
したがって、リバースエンジニアリングしようとしているアプリがCRC16などを使用していると思われ、CRC16を計算するプログラムがあり、同じ長さの複数のサンプルがある場合は、それらのデータファイルのCRC16を計算するだけです（チェックサムを含む）。毎回同じチェックサムデータが返される場合（同じ長さのファイルの場合）、同じ幅と多項式を使用したCRCチェックサムを含める必要があります。
たとえば、2つの定数を変更してCRC32アルゴリズムを変更することで、開発者が賢いと思ったファイルをリバースエンジニアリングする必要がありました。チェックサムを検証したオブジェクトコードを見つけて、それを逆アセンブルしてから、難しい方法を見つけ出す必要はありませんでした。この簡単なテストでそれが決まりました。
