protobuf inspector
1.0.0
付随する定義を知らなくても、Google Protobuf でエンコードされた BLOB (バージョン 2 または 3) を解析できる単純なプログラム。内容を色付きで美しく印刷します。例：
ご覧のとおり、フィールド名は明らかに失われており、次のような高レベルの詳細も失われています。
しかし、protobuf-inspector は、ほとんどの場合、メッセージ構造を正しく推測できます。フィールドに埋め込まれたバイナリ データが見つかると、まずそれをメッセージとして解析しようとします。それが失敗した場合は、データが文字列または 16 進ダンプとして表示されます。特に小さな塊の場合、間違いを犯す可能性があります。
ワイヤー内でエンコードされた順序でフィールドが表示されるため、リバース エンジニアリングに加えて、ワイヤー フォーマットやパーサー開発者に詳しくなりたい人にとっても役立ちます。
pip でインストールできます。
pip install protobuf-inspector
これにより、 protobuf_inspectorコマンドがインストールされます。標準入力に protobuf blob を供給して実行します。
protobuf_inspector < my-protobuf-blob
BLOB の最初の (ブラインド) 分析を読んだ後、通常は、完全な protobuf 定義が完成し、パーサーがそれを行う必要がなくなる点に到達するまで、protobuf-inspector が BLOB をより適切に解析できるように、いくつかのフィールドの定義を開始します。何でも推測してください。
フィールドの定義については、こちらをお読みください。
解析エラーが見つかった場合、解析はそのフィールド内で停止しますが、階層の外側では影響を受けずに続行されます。スタック トレースはフィールドの内容が出力される場所に出力され、該当する場合はそのチャンク内のどこで解析が停止したかを示す 16 進ダンプも出力されます。
したがって、 uint32指定し、より大きなバリアントが見つかった場合は、次のような結果が得られます。
一部のフィールドに埋め込みメッセージが含まれるように指定したが、そこで無効なデータが見つかった場合、次の結果が得られます。
1 つ以上の解析エラーが発生した場合、 main.pyゼロ以外のステータスで終了することに注意してください。
blob に近づくときに時間を節約するために使用できるトリックがいくつかあります。
varint がジグザグ エンコーディングを使用していないことは確かだが、符号付きかどうかまだわからない場合は、 varintのままにしておきます。ジグザグ エンコーディングを使用する場合は、64 ビットではなく 32 ビットであることが確実でない限り、 sint64使用してください。
チャンクが誤ってpacked chunkまたは埋め込みメッセージとして認識されている場合、または解析されたメッセージに何か奇妙な点があり、生のバイトを確認したい場合は、 bytesのタイプを指定します。逆に、何らかの理由で埋め込みメッセージとして検出されず、検出されるはずの場合は、メッセージを強制的にmessageして理由を確認します。
チャンクの生データをファイルに抽出してより適切に分析したい場合は、 dumpの種類を指定すると、 protobuf-inspector は一致する BLOB が見つかるたびにdump.0 、 dump.1などを作成します。
protobuf-inspector は blob をroot型のメッセージとして解析しますが、これは単なるデフォルトです。多数のメッセージ タイプが定義されている場合は、オプションの引数としてタイプ名を渡すことができ、 protobuf-inspector はrootの代わりにそれを使用します。
protobuf_inspector request < my-protobuf-blob
簡単な例:
from protobuf_inspector . types import StandardParser
parser = StandardParser ()
with open ( 'my-blob' , 'rb' ) as fh :
output = parser . parse_message ( fh , "message" )
print ( output )ただし、このプロジェクトは当初ライブラリとして使用するように設計されていないため、API は変更される可能性があります。より複雑な例については、 protobuf_inspector/__main__.pyを参照してください。
