1

1 バイトのカウンターとおそらくチェックサムと共に 6 バイトのメッセージを送信するセンシング デバイスがあります。

データは次のようになります。 

------DATA----------- -Counter- --Checksum?--

55 FF 00 00 EC FF ---- 60---------- 1F

カウンタの最後の 4 ビットは常に 0 に設定されます。つまり、これらのビットはおそらく使用されません。最後のバイトは、非常に特殊な性質を持つため、チェックサムと見なされます。データが変更されると、ランダムに変更される傾向があります。

ここで必要なのは、--DATA-- に基づいてこのチェックサムを計算するアルゴリズムを見つけることです。私が試したのは、すべての可能なCRC-8多項式です。各多項式について、データを反映させたり、切り替えたり、ゼロ以外で開始したりしました。通常のcrcを扱っていないという結論に達しました。アルゴリズム。また、成功せずにフレザーとアドラーの方法をいくつか試しましたが、xor を行ったり来たりしましたが、チェックサムを生成する方法はまだわかりません。

私の最大の懸念は、カウンターがどのように使用されるか??? 同じデータでカウンター値が異なると、異なるチェックサムが生成されます。計算にカウンターを含めようとしましたが、うまくいきませんでした。

他のデータサンプルは次のとおりです。

55 FF 00 00 F0 FF A0 38  
66 0B EA FF BF FF C0 CA  
5E 18 EA FF B7 FF 60 BD  
F6 30 16 00 FC FE 10 81

言及する価値があるかもしれないもう 1 つのことは、データの最後のバイトが値 FF または FE のみを取ることです。

ここに投稿しようとするヒントやコツがあれば、本当に必死です。

ありがとう

4

1 に答える 1

0

いくつかのランダムなアイデア:

  1. ビット順序: 現在、データをオクテットとして表現していますが、これは CRC アルゴリズムがそれを認識する方法ではありません。CRC は、オクテットの配列ではなく、ビットの配列として表される多項式で動作します。このため、デバイスは、使用しているビット順序付けスキームとは異なるビット順序付けスキームを使用して CRC を実行する可能性があります。
  2. デバイスによっては、カウンターが CRC 計算に含まれている可能性が高いと言えます。
  3. これが組み込みデバイスの場合は、BCH などの他のコードを使用している可能性があります。

問題のデバイスについて他に提供できる情報はありますか?

これにより、強力なコーディングがどの程度使用されているかがわかります。例として、特定の CRC-12 (0x8F8) は、53 ビットのデータ ワード長まで 5 のハミング距離を提供します (データでは、CRC サイズが 12 ビットであると仮定すると、データ ワードは 52 ビットになる可能性があります)。

編集:チェックサムアルゴリズムを推測するにはどうすればよいですか? の回答を参照してください。いくつかの追加のアイデアについて。

于 2010-05-24T13:20:15.923 に答える