1

Google Chrome同期に接続しようとしています（Chrome設定と現在開いているタブを同期します）。今のところ、私はタブの同期に集中しています。Googleトークサーバーに接続しましたが、Chromeで新しいウェブページに移動するたびにタンゴボットからメッセージを受信して​​います。

しかし、これらのメッセージはGoogleのprotobuf形式でエンコードされているため、デコードするのが困難です。ChromeSync専用のさまざまなprotobufクラスがたくさんあり、バイナリprotobufメッセージのタイプを把握する方法がないと思いますか？

典型的なメッセージは次のようになります（base64でエンコードされ、XXXXは私のメールアドレスを出力しません）：

CAAilQEKQAoGCgQIAxACEiUKBgoECAMQARISCZwF6dZYmkeFEXZLABNN3/yMGgcIhSwQAxgBINP80ri/JyoIMTgxOTgxMjYaUQpPCgwI7AcSB1NFU1NJT04QARiw64/I0se0AiIyVzpDaGZDeU9JWUZXdXFuUmRXaGtJWk94VkRSM1lmTGU1M0FoRGVxT2EwOHVQUHcyOD0wASoGCgQIAxACMAI4AUIrCG8SJxAEGAIiFGRlbHXXXXXXXXdAZ21haWwuY29tQgl0YW5nb19yYXdIAQ==

いくつかのprotobufクラス（Java用にコンパイルしたもの）を使用してデコードしようとしましたが、どれも有用なデータを取得できませんでした。

誰かがこのトピックに関する詳細情報を持っていますか？特定のバイナリメッセージをデコードするための適切なprotobufクラスを見つける方法についての洞察は素晴らしいでしょう。上記の例として示した正確なメッセージをデコードできるようになると、ある程度は役に立ちます。公開ドキュメントはほとんどなく、C ++を使用していない場合、Chromiumのソースコードを確認するのは非常に困難です…（重要な場合は、Javaで開発しています）

4

1 に答える 1

1

はい、それは広く可能です。ただし、投稿したデータは、メールアドレスを削除しようとして取り返しのつかないほど破損しているため、実行できません。Protobufはそれに非常に敏感です。6文字の電子メールアドレスのXXXXXXXXをbase-64に置き換えようとしましたが、その直前のバイトは199であり、199は有効ではありません（文字列の内容の直前のデータは、としてエンコードされた文字列の長さです。 varint、およびvarintは、MSBが継続フラグであるため、最後のバイトセットの最上位ビットで終了することはできません）。

生のprotobufバイナリがある場合は、それを実行してみてprotoc --decode_raw、それが何を言っているかを確認できます。これで、レイアウトの再構築を開始するのに十分な場合があります。または、好みの実装の「リーダー」API（ある場合）を使用して手動で解析してみることができます。たとえば、protobuf-netとを使用して、つなぎ合わせるProtoReaderことができました（括弧内の数字は、各フィールドヘッダーを読み取った後のオフセットです）。

{
    (1) field 1: varint, value 0 if int
    (3) field 4: string, looks like sub-message
    // everything after this point is really really suspect
        (6) field 1, string, looks like sub-message
            (8) field 1, string, looks like sub-message
            (16) field 2, string, looks like sub-message
            (55) field 4, varint, 1357060030035 assuming int64
            (62) field 5, string; "18198126"
        (72) field 3, string, looks like sub-message
            (64) field 1, string, looks like some encoded session data
    (155) field 5: string, looks like sub-message
        (157) field 1: string, looks like sub-message
    (163) field 6: varint, value 2 if int
    (165) field 7: varint, value 1 if int
    (167) field 8: string, looks like sub-message
        (169) field 1: varint, value 111 if int
        (171) field 2: string, looks like sub-message
}

問題は、（交換のために）破損しているため、そのフィールド4をはるかに超えて言うことは不可能であるということです。その時点で、長さがずれているため、すべてが完全にぎこちないものになる可能性があります。ですから、それ以降はほとんど自信がありません。上記の主なポイントは、単に説明することです。はい、スキーマを事前に知らなくてもprotobufデータを解析して、スキーマをリバースエンジニアリングすることができますが、次のことが必要です。

  • 各フィールドを解釈するための忍耐と少しの当て推量（各ワイヤタイプは複数のことを意味する可能性があります）
    • それぞれがフィールドにどのようにマップされるかを必ずしも知らなくても、格納されている値がわかっている場合は、有利なスタートを切ることができます。たとえば、値が22、1325、 "hello world"、および123.45Fの何かが送信されていることがわかっている場合。そうすれば、マッピングを簡単に理解できるはずです。
  • 完全なデータ（この場合は悲しいことに欠落しています）
于 2013-01-02T08:44:26.150 に答える