5

WindowsCE実行可能ファイルによって実装されたCRC/チェックサムアルゴリズムをリバースエンジニアリングする必要があります。独自のプロトコルであるため、CRC/チェックサムアルゴリズムについては何も述べていません。ただし、正しい/計算されたチェックサムを報告するコンソールインターフェイスがあり、メッセージプロトコルが正しい場合は、ランダムビットを使用して独自のメッセージを作成できます。

私はそれを観察しました、

  • メッセージの1ビットを変更すると、チェックサムバイトが完全に変更されます。

  • アルゴリズムは、さまざまなメッセージデータ位置にいくつかの単一の1ビットメッセージを送り、残りのビットはゼロであり、コンソールが異なるチェックサムを報告したため、位置に依存しているようです。単純な加法チェックサムの場合、チェックサムは同じになります。

一般的なXOR、LRC、加法チェックサムアルゴリズム、一般的なCRC多項式（Standerd、CCITT、X-modem）を適用し、[CRCリバースエンジニアリングエッセイ] [2]を実行しましたが、メッセージタイプが固定されているため、残念ながら多項式の推定を通過できません。単一の1ビットメッセージを作成できません。

私の質問：

  1. アルゴリズムがチェックサムであるか多項式ベースのCRCであるかを判断するために、メッセージに対してテストできるCRC /チェックサムアルゴリズムのプロパティはありますか？

  2. プログラムの逆アセンブルで見られるエラーメッセージを対応するアセンブリ命令と関連付ける方法はありますか？

  3. コンソールに正しいチェックサムが報告された瞬間に、逆アセンブリコードをデバッグ/特定する方法は何ですか？メモリダンプか何か？

4

1 に答える 1

4

CRCRevEngを試してください。あなたのデータを使ったいくつかの簡単な試みは無益でしたが、私はそれほど一生懸命に努力しませんでした。10メッセージバイトすべてだけでなく、最後の8バイトと最後の6バイトも試してみることを検討してください。

さらに、同じサイトで、私が知っている既知のCRCの最も包括的なリストを見つけることができます。

アップデート：

これは、ある種のCRCであるか、少なくともGF（2）に対する線形演算である可能性が高いです。これには、CRCが持つこの特性があります。2つのシーケンスが同じ排他的論理和を持っている場合、それらのCRCも同じ排他的論理和を持ちます。たとえば、データから（共通のプレフィックスを削除しますが、プレフィックスまたはその一部を含めても結果は変更されないことに注意してください）：

00000000000122b5 ^ 0000000000022421 = 0000000000030694
0447080a300130A1 ^ 0447080a30023635 = 0000000000030694

と

0447080a300130A1 ^ 0447080a30043A36 = 0000000000050a97
00000000000122b5 ^ 0000000000042822 = 0000000000050a97

この事実を考えると、それがCRCであるか、CRCパラメータが何であるかを判断せずに、チェック値を計算するルーチンを構築する方法があります。

すべてのシングルビットメッセージの16ビットチェック値を生成します。つまり、6バイトのメッセージデータに1ビットを設定し、残りのメッセージデータビットをゼロにします。これらのメッセージは、この線形フィールドの基底ベクトルの完全なセットです。それらの48があります。また、すべてゼロのメッセージのチェック値を生成します。すでに、すべてゼロが与えられ2020、最後のビットセットが与えられる22b5などの開始があります。排他的論理和、または他のすべてのゼロ（）のチェック値2020。これで49個の値が得られました。そのうち48個は基底ベクトル用で、1個はゼロベクトルの補正です（CRCとプレフィックスバイトの前後の調整が原因でゼロ以外になる可能性があります）。たとえば、最後のビットが設定された基底ベクトルの値はです0295。

これで、これらの49個の値を使用して、6バイトのメッセージのチェック値を計算できます。排他的論理和-または、そのメッセージで1に設定されている対応するすべてのビットの値をまとめます。排他的論理和、またはチェック値がゼロの場合。結果は、そのメッセージのチェック値になります。

于 2012-09-15T18:02:36.423 に答える