解释 DBus 消息

Posted

技术标签:

【中文标题】解释 DBus 消息【英文标题】:Interpret DBus Messages 【发布时间】:2022-01-06 03:51:52 【问题描述】:

我试图解释 https://dbus.freedesktop.org/doc/dbus-specification.html 中指定的 DBus 消息中的字节。这是在使用 Frida 工具时从 pcap 中获取的。

字节数是

0000   6c 01 00 01 08 00 00 00 01 00 00 00 70 00 00 00
0010   01 01 6f 00 15 00 00 00 2f 72 65 2f 66 72 69 64
0020   61 2f 48 6f 73 74 53 65 73 73 69 6f 6e 00 00 00
0030   02 01 73 00 16 00 00 00 72 65 2e 66 72 69 64 61
0040   2e 48 6f 73 74 53 65 73 73 69 6f 6e 31 35 00 00
0050   08 01 67 00 05 61 7b 73 76 7d 00 00 00 00 00 00
0060   03 01 73 00 17 00 00 00 47 65 74 46 72 6f 6e 74
0070   6d 6f 73 74 41 70 70 6c 69 63 61 74 69 6f 6e 00
0080   00 00 00 00 00 00 00 00

有些字段我不确定它们的含义。感谢是否有人可以提供一些指导。

0x6C:指小端序 0x01:消息类型(方法调用) 0x00:按位或标志 0x01:主要协议版本 0x08000000:消息体长度(小端序),从报头末尾开始。 这应该是指最后的八个空字节吧? 0x01000000:此消息的序列号(小端序) 0x70000000:(Little Endian)不确定这代表什么?此值确实对应于结构数组的长度,不包括尾随空字节,从 0x0010 开始,到 0x007F 结束。 0x01:对象路径的十进制代码 0x01:不确定这代表什么? 0x6F:对象路径的 DBus 类型“o” 0x15:对象路径字符串的长度

【问题讨论】:

【参考方案1】:

您想查看说明message format is 是什么的规范部分。

但要回答你的问题:

0x08000000:消息体的长度(Little Endian),从 Header 的末尾开始。这应该是指最后的八个空字节吧?

正确。

0x70000000:(Little Endian)不确定这代表什么?这个值确实对应于结构数组的长度,不包括尾随的空字节,从 0x0010 开始,到 0x007F 结束。

这是标题中数组的长度。 DBus 标头的大小可变 - 在前几个字节之后,它是一个结构(字节,变体)数组。根据文档,如果您要将其表示为 DBus 类型签名,则看起来像 a(yv)

0x01:对象路径的十进制代码 0x01:不确定这代表什么?

这就是解析变得有趣的地方:在我们的结构中,签名是yv,所以第一个0x01 告诉我们这个结构条目是对象路径的头字段,如您所见。但是,我们现在需要解析变体内部包含的内容。要编组一个变体,首先要编组一个签名,在本例中为 1 个字节长:01 6f 00。请注意,签名的最大长度为 255 个字节,因此与其他字符串不同,它们在前面只有 1 个字节的长度。作为一个字符串,即o,它告诉我们这个变体内部包含一个对象路径。由于对象路径是字符串,因此我们将接下来的字节解码为字符串(注意前 4 个字节是字符串长度):15 00 00 00 2f 72 65 2f 66 72 69 64 61 2f 48 6f 73 74 53 65 73 73 69 6f 6e 00

如果我正确地完成了转换,那就是/re/frida/HostSession

【讨论】:

嗨@rm5248 感谢您的明确解释。 嗨@rm5248 我再次阅读了规范,但仍然没有看到在哪里提到包含结构数组的长度(在本例中为 0x70000000)。在串行的第二个 Uint32 之后,后面是结构数组,但我没有看到它提到数组的长度是串行后面的下一个 Uint32。规格中有提到吗? "但我没有看到它提到数组的长度是序列之后的下一个 Uint32。"紧随其后的是“零个或多个标题字段的数组”。在“编组容器”下,它说“数组被编组为UINT32n,以字节为单位给出数组数据的长度,然后是数组元素类型的对齐边界的对齐填充,然后是数组的 n 个字节元素按顺序编组。”因此,数组以 Uint32 开头,给出它的长度,并且由于数组跟在序列后面,所以数组长度是第一件事。 感谢@user16139739 的澄清。【参考方案2】:

这是从 pcap 中获取的

如果它是标准 pcap(或 pcapng)D-Bus 捕获文件,使用 LINKTYPE_DBUS 链路层类型,那么 Wireshark 应该能够读取它,并且至少在某种程度上能够解释消息(即,它具有理解消息格式的代码,由the specification to which @rm5248 referred(以及the list of link-layer header types 中的LINKTYPE_DBUS 条目所指)定义,因此您可能不必自己解释所有字节。

【讨论】:

谢谢@user16139739 我会看看你分享的那个链接。 哪个链接?第一个链接是另一个答案提到的相同文档,因此您不会从中学到任何新东西 - 您已经阅读过它。第二个链接只是表明LINKTYPE_DBUS 是该规范中描述的内容。你应该做的是看看用 Wireshark 读取 pcap 文件 谢谢@user16139739 是的,我查看了 Wireshark 中的 pcap 文件。它能够理解 DBus 消息是一个 WebSocket 有效负载,但它没有根据 DBus 规范进一步分解有效负载。我想我需要检查一下是否需要为此配置任何选项。

以上是关于解释 DBus 消息的主要内容,如果未能解决你的问题,请参考以下文章

linux 进程间通信 dbus-glib实例详解二(上) 消息和消息总线(附代码)

通过python监控dbus消息

dbus 信号中收到的消息与发送的数据不匹配

来自 Chrome 扩展的 X11 / DBUS 消息传递?

linux 进程间通信 dbus-glib实例详解二(下) 消息和消息总线(ListActivatableNames和服务器的自动启动)(附代码)

获取由消息发送者的“dbus_request_name”设置的总线名称