Windows CEの実行可能プログラムで使用される16ビットCRC /チェックサムアルゴリズムをネイルダウンする方法はありますか？

Question

Windows CEの実行可能プログラムによって実装されたCRC /チェックサムアルゴリズムをリバースエンジニアリングする必要があります。 propritoryプロトコルであるため、CRC /チェックサムアルゴリズムについては何も言及していません。しかし、正しい/計算されたチェックサムを報告し、メッセージプロトコルが正しいかどうか、私はランダムなビットで自分のメッセージを作成することができますコンソールインタフェースがあり：

私は

• は、メッセージの変更に単一のビットを変更する、ことを観察しましたチェックサムバイト完全に。

• アルゴリズムは、ビットの残りの部分がゼロであり、すべての時間がコンソールが異なるチェックサムを報告して、いくつかの単一の1ビットメッセージをさまざまなメッセージデータ位置に供給したように見えます。シンプルな追加チェックサムの場合、チェックサムは同一であったはずです。

私は、LRC、添加物のチェックサムアルゴリズム、共通CRC多項式（VoIP音声、CCITT、X-モデム）を、共通のXORを適用し、[CRCリバース・エンジニアリング・エッセイ]を経て[2]が、残念ながら、私は推論を過ぎて行くことができません多項式はメッセージタイプが固定されているため単一の1ビットメッセージを作成できないためです。

私の質問：

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

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

3. コンソールで正しいチェックサムを報告すると、逆アセンブリコードをデバッグ/ピンポイントする方法はありますか？メモリダンプか何か？

Answer 1

お試しCRC RevEngあなたのデータを使ったいくつかの素早い試みは無駄でしたが、私はとても努力しませんでした。 10バイトのメッセージバイトだけでなく、最後の8バイトと最後の6バイトも試すことを検討してください。

さらに、同じサイトで私が知っているmost comprehensive list of known CRCsを見つけることができます。

更新：

ある種のCRCであり、又はGF（2）上の少なくとも線形動作可能性が高いです。 CRCの持つ性質は：2つのシーケンスが同じ排他的ORを持つ場合、CRCの排他的ORも同じです。そこに、

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

と考える

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

この事実：たとえば、あなたのデータから（接頭辞またはその一部を含むことは、結果を変更しないことに注意してくださいかかわらず、共通のプレフィックスを落とします）チェック値がCRCかどうか、またはCRCパラメータが何であるかを判断せずにチェック値を計算するルーチンを作成する方法です。

すべての単一ビットメッセージに対して16ビットのチェック値を生成します。6バイトのメッセージデータに1ビットセットされ、残りのメッセージデータビットはゼロである。これらのメッセージは、この線形フィールドの基底ベクトルの完全な集合です。それらの48があります。また、すべてゼロのメッセージのチェック値を生成します。すでにすべてのゼロが2020となっており、最後のビットが22b5などとなっています。Exclusive-またはすべてのゼロのチェック値（2020）。ここでは、49個の値があり、そのうちの48個が基底ベクトル用であり、1個はゼロベクトル（CRCのプレおよびポストコンディショニングおよびプレフィックスバイトのためゼロでない可能性が高い）に対する補正である。たとえば、最後のビットが設定された基底ベクトルの値は0295です。

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