17

最後に 16 ビットのチェックサムを持ついくつかのパケットがあると仮定しましょう。どのチェックサム アルゴリズムが使用されているかを推測したいと思います。

まず、ダンプ データから、パケットのペイロードの 1 バイトの変更によってチェックサムが完全に変更されることがわかります。そのため、単純な XOR または合計ではないと推測できます。

次に、 CRC16 のいくつかのバリエーションを試しましたが、うまくいきませんでした。

この質問は暗号化に偏っている可能性がありますが、これがどの CRC であるかを調べるためのわかりやすい統計ツールに本当に興味があります。他のすべてが失敗した場合は、別の CRC アルゴリズムを描画することさえあります。

背景の話: 私はある種のチェックサムを持つシリアル RFID プロトコルを持っています。問題なくメッセージを再生し、結果を解釈することはできますが (チェックサム チェックなし)、変更されたパケットを送信できません。

既存のソフトウェアを使用して、RFID チップのペイロードを変更できます。ただし、一意のシリアル番号は不変であるため、考えられるすべての組み合わせを確認することはできません。1 ずつ増加する値のダンプを生成できましたが、この問題に徹底的な検索を適用するには十分ではありませんでした。

質問自体が十分でない場合は、データを含むダンプファイルを利用できます:-)

参照ドキュメントが必要ですか? A PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMSは、ここで質問した後に見つけた素晴らしいリファレンスです。

最後に、CCITT よりも受け入れられた回答で非常に役立つヒントが得られた後、 この CRC 計算機を使用し、生成されたチェックサムを既知のチェックサムで xor して 0xffff を取得し、最終的な xor が CCITT の 0x0000 の 0xffff インストレッドであるという結論に至りました。

4

4 に答える 4

21

CRC について考慮すべき多くの変数があります。

Polynomial
No of bits (16 or 32)
Normal (LSB first) or Reverse (MSB first)
Initial value
How the final value is manipulated (e.g. subtracted from 0xffff), or is a constant value

典型的な CRC:

LRC:    Polynomial=0x81; 8 bits; Normal; Initial=0; Final=as calculated
CRC16:  Polynomial=0xa001; 16 bits; Normal; Initial=0; Final=as calculated
CCITT:  Polynomial=0x1021; 16 bits; reverse; Initial=0xffff; Final=0x1d0f
Xmodem: Polynomial=0x1021; 16 bits; reverse; Initial=0; Final=0x1d0f
CRC32:  Polynomial=0xebd88320; 32 bits; Normal; Initial=0xffffffff; Final=inverted value
ZIP32:  Polynomial=0x04c11db7; 32 bits; Normal; Initial=0xffffffff; Final=as calculated

最初に行うことは、たとえば最後のバイトを変更して、いくつかのサンプルを取得することです。これは、CRC のバイト数を把握するのに役立ちます。

これは「自家製」のアルゴリズムですか？この場合、時間がかかる場合があります。それ以外の場合は、標準アルゴリズムを試してください。

最後のバイトの msb または lsb を変更してみて、CRC がどのように変化するかを確認してください。これにより、方向が示されます。

さらに困難にするために、通信媒体 (プロトコル) に影響を与えないように CRC を操作する実装があります。

RFIDに関するあなたのコメントから、CRCが通信関連であることを暗示しています。一部のシステムでは CCITT も使用されますが、通常は CRC16 が通信に使用されます。

一方、これが UHF RFID タグ付けである場合、CRC 方式はいくつかあります - 5 ビットのものと 16 ビットのものです。これらは、ISO 規格および IPX データ シートに記載されています。

IPX:  Polynomial=0x8005; 16 bits; Reverse; Initial=0xffff; Final=as calculated
ISO 18000-6B: Polynomial=0x1021; 16 bits; Reverse; Initial=0xffff; Final=as calculated
ISO 18000-6C: Polynomial=0x1021; 16 bits; Reverse; Initial=0xffff; Final=as calculated
    Data must be padded with zeroes to make a multiple of 8 bits
ISO CRC5: Polynomial=custom; 5 bits; Reverse; Initial=0x9; Final=shifted left by 3 bits
    Data must be padded with zeroes to make a multiple of 8 bits
EPC class 1: Polynomial=custom 0x1021; 16 bits; Reverse; Initial=0xffff; Final=post processing of 16 zero bits

これがあなたの答えです!!!!

ログを調べた結果、CRC は CCITT のものです。最初のバイト 0xd6 は CRC から除外されます。

于 2008-10-01T17:14:13.697 に答える
2

ここで同様の問題を解決しようとしていますが、ファイルを取得して 47 の異なるアルゴリズムでチェックサムを実行し、結果を表示する非常に優れた Web サイトを見つけました。チェックサムの計算に使用されるアルゴリズムがこれらのアルゴリズムのいずれかである場合、単純なテキスト検索で生成されたチェックサムのリストの中から見つけることができます。

ウェブサイトはhttps://defuse.ca/checksums.htmです。

于 2015-06-09T14:11:16.723 に答える
2

これは CRC ではなく、Reed-Solomon のようなエラー修正コードである可能性があります。

ECC コードは、処理するエラー率にもよりますが、保護する元のデータのサイズのかなりの部分を占めることがよくあります。メッセージのサイズが約 16 バイトを超える場合、2 バイトの ECC では十分ではありません。したがって、メッセージが大きい場合は、CRC の一種である可能性が高いでしょう。

于 2008-09-29T17:15:42.913 に答える
0

考えられるすべてのチェックサム アルゴリズムを試して、どれが同じ結果を生成するかを確認する必要があります。ただし、チェックサムにどのような内容が含まれていたかは保証されません。たとえば、一部のアルゴリズムは空白をスキップするため、結果が異なります。

なぜ誰かがそれを知りたいのか、私には本当にわかりません。

于 2008-09-29T17:03:06.203 に答える