ビット操作技術を特定するのに役立つ必要があります

Question

私は以下の技術を特定するのに役立つ必要があります。長い読書ですので、従ってみてください。私の質問は、これが既知の標準であるかどうかです。名前を持っていますか？何が利益です。また、これは忘れてしまった長いオンラインのPS2ゲームでキャプチャされたパケットに関連しています。私はそれを元に戻そうとしているチームの一員です。

これはipプロトコルで記述されているサイズではなく、実際のペイロードを使用したサイズです。この値はクライアントとサーバーの消費量を表します。 以下の説明は、メッセージのサイズの表現方法を説明しています。 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

実際のパケット長は94バイトです。 これらは、すべてのipプロトコルの後のペイロードデータ上のバイト5-6 [CF E0]です。 また、これらの2バイトをリトルエンディアン形式であると解釈する必要があります。したがって、これらの2つのバイトは、最初のバイトの最初のニブル（4ビット）を取ることによって決定されます。

[E0 CF] これらの2バイトからパケットクラスを決定します。この特定のケースでは、これはちょうど0xEです。次に、このパケットを0xEのパケットクラスとして識別する。これは、セッション開始者パケットクラスとして識別されました。

ここで、残りのニブルと2番目のバイトからパケット長を決定します。最初に2番目のバイトを10進数に変換すると0xCF = 207となります。この値と実際の長さの差は207-94 = 113バイトです。もともと私はこのバイトがパケットの長さに比例することを知っていましたが、ちょうどオフセットがありました。私はこのオフセットがどこから来たのか分からなかった。さらに、このオフセットはパケットごとに異なるように見えました。より多くの研究が必要でした。

結局、各パケットクラスに異なるオフセットがあることがわかりました。そこで私は同じパケットクラスのパケットだけを調べて、そのパケットクラスのオフセットを調べる必要がありました。これを行うにあたり、報告されたすべての長さ（バイト5）のテーブルを作成し、それを実際のパケット長と比較しました。私が発見したのは、バイト5の報告されたパケットの長さのほとんどすべてが0x80 = 128よりも大きいことです。

他のバイトの第2のニブルは、パケット長の乗算器のタイプとして作用し、各パケットクラスは、関連する最小パケット長および最大パケット長を表すことができた。調べている0xCパケットクラスでは、最小パケットサイズは18バイトで、最大パケットサイズは約10 * 128 + 17 = 1297バイトでした。 これは、第5および第6バイトのパケットヘッダからパケット長を抽出するために以下のアプローチを導いた。最初にパケットクラスを0xEと決定し、このパケットクラスに関連する最小パケットサイズは15バイトであることに注意してください。ここでは、最初のバイト[0xE0] = 0の2番目のニブルを取り出し、128バイト0 * 128 = 0バイトで乗算します。これを今度は2番目のバイト[0xCF] = 207に追加して128を引きます。したがって0 + 207 - 128 = 79です。このパケットクラスの最小パケットサイズを追加する必要があります。0xE = 15バイト最小パケットサイズ。したがって（0 * 128）+（207-128）-15 = 94。これは報告された真のパケットサイズです。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

この数式は、20,000個の後続パケットでテストされ、動作します。しかし、なぜそのメッセージに続くメッセージのサイズを示すのに苦労するのでしょうか？私はそれが暗号の一種だと思ったが、メッセージの残りの部分はまったく暗号化されていない。数式は理解されていますが、私は利益を見ません。私はおそらく、1バイトだけを使用して255より大きい数値を渡すことによってパケットのサイズを最適化する方法だと思っていますが、別のバイトを投げると65,535のMax値が得られます。バイトストリームに変換します。 1つの余分なバイトがネットワークに大きな影響を及ぼさないので、何が目的になるかは確信しています。他の誰かが、文書化された標準、プロトコル、パターン、テクニック、またはどこかに文書化されている何らかのものに欠けているものや接続されているものを見るかもしれないと私は考えました。

また、別のチームメンバーが行った上記の計算式の計算には、私は信用できません。

Answer 1

受信者は、LEB128のような可変長のbase128エンコーディングを使用していると思います。

しかし、この場合、実際の最大サイズが11ビットに収まることを知っている送信者は、エンコーディングに2バイトを使用させ、 "class"のハイニブルをオーバーロードします。これにより、ヘッダサイズと構築時間が一定になります。受信側はクラスをマスクして標準のデコーダで実行するだけです。

送信：

len -= minlen[class] 
byte[5]=(len&0x7F)|0x80; 
byte[6]=(len>>7)|(class<<4); 

が受信：

class = byte[6]>>4; 
byte[6]&=0xF; 
len = decode(&byte[5]) + minlen[class]; 

：

int decode(byte* data) { 
    int v=*data&0x7F; 
    while (*data & 0x80) { 
    data++; 
    v+=*data&0x7F; 
    } 
    return v; 
} 

もう一つの可能​​性は、[5]署名され、そして長さが
によって再構築されたバイトであります(int8_t)byte[5] + 128*((byte[6]&0xF)+1) + minlen[byte[6]>>4];
しかし、私はこのように構築する理由は考えられません。