チェックサム アルゴリズムを推測するにはどうすればよいでしょうか?

Question

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

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

それから私は試してみました CRC16 のいくつかのバリエーション, 、しかし、あまり幸運ではありませんでした。

この質問は暗号化に偏っているかもしれませんが、これがどの CRC であるかを調べるためのわかりやすい統計ツールに本当に興味があります。私も目を向けるかもしれません さまざまな CRC アルゴリズムを描画する 他のすべてが失敗した場合。

バックグラウンドストーリー:ある種のチェックサムを備えたシリアル RFID プロトコルを使用しています。メッセージは問題なく再生でき、結果を解釈できます (チェックサム チェックなし)。しかし、デバイスが床にパケットを落とすため、変更されたパケットを送信できません。

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

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

参考資料が必要ですか? CRC エラー検出アルゴリズムの簡単なガイド ここで質問した後に見つけた素晴らしい参考資料です。

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

Answer 1

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 が通信に関連していることがわかります。通常、通信には CRC16 が使用されますが、一部のシステムでは CCITT も使用されます。

一方、これが UHF RFID タグ付けの場合は、5 ビットのものと 16 ビットのものなど、いくつかの CRC スキームがあります。これらは 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 から除外されます。

Answer 2

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

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

Answer 3

CRC ではなく、リードソロモンのようなエラー訂正コードである可能性があります。

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

Answer 4

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

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