5

与えられたコード+CRC文字列が与えられた場合、どうすればCRCアルゴリズムを理解できますか？

コードと一致するCRCで構成される文字列がいくつかありますが、より多くのコード文字列を生成できるように、問題のCRCを計算する方法がわかりません。次にいくつかのサンプル（16ビットコード+ 4ビットCRC）を示します。

0010101000011101 + 0000
0010101000011111 + 0001
1000110011101101 + 0001
0000000000000100 + 0010
0011100011001110 + 0011
1000110011101110 + 0100
0001011110101100 + 0100
0010101000011110 + 0101
0011100011001101 + 0110
0001011110101111 + 0111
0011100011001100 + 1001
0011100011001111 + 1010
0001011110101101 + 1011
0000000000001000 + 1011
0000111100001101 + 1100
0000000000001100 + 1100
1111111111111111 + 1101
1000110011101111 + 1101
1000110011101100 + 1110
0001011110101110 + 1110
1111111100001101 + 1110
0010101000011100 + 1111

これらのコードは、X10製品のようなRF（433MHz）送信機から送信されます。

これがCRCなのか、それとも何なのかはわかりませんが、少なくともこれらのコード文字列から何らかの形で計算されています。

更新

RE：仕様を見つけることも最善の解決策だと思いますが、これはオプションではないため、なんとかしてチェックサム計算を総当たり攻撃する必要があります。

これが問題です。仕様がなく、どこにも入手できません。結果なしでいくつかの異なるチェックサム計算方法を試しましたが、入力文字列を比較して共通点を見つけ、この方法でアルゴリズムを取得する方法はありませんか？

4

9 に答える 9

5

それがCRCだと思う理由は何ですか？通常、CRC はこのような小さなデータには使用されません。

私には、これはある種のパリティ、ECC (実際にはFEC )、またはリードソロモンコードのように見えます。Hamming Codeである可能性があります- ハミングは、通信業界で広く使用されています。

于 2008-11-18T13:18:54.577 に答える
3

推測は非常に正しい言葉です。このRFデバイスが独自仕様でない場合は、仕様を読んでみてください。これが最も簡単な方法です。

考えられるすべてのCRC（またはハッシュアルゴリズム）を推測することは、楽観的すぎるようには見えません。こちらをご覧ください。

3番目の可能性は、チェックサムの生成に使用しているコードをリバースエンジニアリングすることです。

幸運を ：）

于 2008-11-18T12:29:51.697 に答える
2 
['0010101000011101', '0000', '0'] ['0010101000011110', '0101', '5'] [1, 3]
['1000110011101101', '0001', '1'] ['1000110011101110', '0100', '4'] [1, 3]
['0000000000000100', '0010', '2'] ['0000000000001000', '1011', 'b'] [0, 3]
['0011100011001110', '0011', '3'] ['0011100011001101', '0110', '6'] [1, 3]
['0001011110101100', '0100', '4'] ['0001011110101111', '0111', '7'] [2, 3]
['0011100011001100', '1001', '9'] ['0011100011001111', '1010', 'a'] [2, 3]
['0001011110101101', '1011', 'b'] ['0001011110101110', '1110', 'e'] [1, 3]
['1000110011101111', '1101', 'd'] ['1000110011101100', '1110', 'e'] [2, 3]

差分「分析」の結果、これはcrcのようには見えません。参照： http： //www.cosc.canterbury.ac.nz/greg.ewing/essays/CRC-Reverse-Engineering.html

4パリティビットは16ではなく11データビットしか許可しないため、ハミングコードでもないかと思います。

于 2011-04-18T20:12:48.083 に答える
2

@meckiは正しいかもしれませんが、知るのは難しいです。X-10 ワイヤレス ユニットのデータ フォーマットおよびX-10 FAQを試すことができます。

于 2008-11-18T20:07:52.613 に答える
0

効果的に推測するには、CRCアルゴリズムの可能性が多すぎます。デバイスの仕様を見つけるという簡単なアプローチを取ることができます。または、可能な入力ごとにCRCを計算し、同じ結果を生成するアルゴリズムを作成するブルートフォース方式を採用することもできます。

于 2008-11-18T12:40:55.090 に答える
0

優れたチェックサム アルゴリズムの要点は、入力テキストと共通点がないことです。入力内の 1 文字を変更できます。チェックサム出力全体が変更されます。したがって、他の方法に進む唯一の方法は、はい、推測することです。入力文字列と出力文字列がわかっている場合は、いくつかの一般的なチェックサム アルゴリズムを試して、正しい出力が得られるかどうかを確認できます。それ以外は、いや、無理です。

あるいは、他の人が示唆しているように、それはチェックサムではなく、ある種のエラー修正/冗長コードである可能性があり、それを理解する方が簡単かもしれません。

于 2008-11-18T13:27:38.507 に答える
0

文字列の長さとチェックサムの長さから判断すると、これは単純な 1 エラー訂正チェックサムであると言えます。おそらく、ハミング距離を使用した単純なものの1つです。それがどのように機能したかをすぐに思い出せません。また、情報理論/線形代数の教科書も持っていません。

于 2008-11-18T20:21:19.653 に答える
0

いくつかの一般的な CRC メソッドを試して、幸運を祈ることもできますが、Mana の回答 (仕様を探している) が最良の選択です。

于 2008-11-18T12:50:35.850 に答える
0

おそらくCRCではありませんが、それでもエラー訂正/冗長アルゴリズムを見つけることができません.

于 2008-11-18T13:41:32.893 に答える