我尝试连接到Google Chrome同步（用于同步Chrome设置和当前打开的标签）。 现在我专注于标签同步。我连接到Google Talk服务器，每当我导航到Chrome中的新网页时，我都会收到来自 tango bot 的消息。
但是我在解码这些消息时遇到了困难，因为它们采用Google的protobuf格式编码 - 因为有大量不同的protobuf类专用于Chrome Sync，我认为没有办法弄清楚这种类型二进制protobuf消息？
典型的消息看起来像这样（base64编码，XXXX＆＃39;输出我的邮件地址）：
CAAilQEKQAoGCgQIAxACEiUKBgoECAMQARISCZwF6dZYmkeFEXZLABNN3/yMGgcIhSwQAxgBINP80ri/JyoIMTgxOTgxMjYaUQpPCgwI7AcSB1NFU1NJT04QARiw64/I0se0AiIyVzpDaGZDeU9JWUZXdXFuUmRXaGtJWk94VkRSM1lmTGU1M0FoRGVxT2EwOHVQUHcyOD0wASoGCgQIAxACMAI4AUIrCG8SJxAEGAIiFGRlbHXXXXXXXXdAZ21haWwuY29tQgl0YW5nb19yYXdIAQ==
我尝试用一些protobuf类（我为Java编译）解码它，但是没有一个我得到任何有用的数据。
有没有人有关于此主题的更多信息？有关如何找到正确的protobuf类来解码某个二进制消息的一些见解会很棒。它甚至可以帮助我能够解码我给出的确切消息作为上面的例子。 如果你不是一个C ++家伙，那么public documentation很少{Chromium源码很难看出来...... （我在Java中开发，如果重要的话）
答案 0 :(得分：1)
是的，这是广泛的可能;但是，由于您在尝试删除电子邮件地址时无可挽回地损坏了数据，因此无法使用您发布的数据。 Protobuf对此非常敏感;我尝试用base-64替换XXXXXXXX用于6个字母的电子邮件地址，但是之前的字节是199，并且199在那里不合法（字符串内容之前的数据是编码为字符串的字符串的长度） varint和varint永远不会以最后一个字节集的最高有效位结束，因为MSB是一个连续标志。）
如果你有原始protobuf二进制文件，你可以尝试通过protoc --decode_raw运行它，看看它说的是什么;这可能会让你足够开始重建布局。或者，您可以尝试使用首选实现的“reader”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数据，对模式进行反向工程 - 但它需要：