为损坏的 pcap 找到正确的层头

逆向工程 数字取证 联网 线鲨
2021-07-01 08:11:32

所以问题是我有一个损坏的 pcap 文件。您可以在 [此处][1] 中找到 pcap 文件。首先我对它做了文件命令:the.pcap: tcpdump capture file (little-endian) - version 2.4, capture length 24)

所以我认为 Wireshark 可以轻松打开它,然后我可以通过分析数据包找到任何键/标志。但是用wireshark打开它只是给了我一个错误“网络类型216未知或不受支持”。所以首先,我对 pcap 的不同层类型做了一些研究。这是层头不同值链接正如预期的那样,值为 216 的类型没有引用,所以我需要将 216 值更改为正确的值?但是怎么样?我怎么知道哪一个合适?

在谷歌上搜索了一下之后,我发现我们可以手动更改类型的值。

00000000  D4 C3 B2 A1  02 00 04 00   00 00 00 00  00 00 00 00   ................
00000010  18 00 00 00  D8 00 00 00   8E 6E 6E 52  A9 CB 00 00 

下面你可以看到 pcap 文件的第一个字节,字节 D8 是类型的值,这里等于 216。我应该尝试编辑一个程序,用所有现有的类型值修改原始 pcap 文件,看看哪个有效? 或者有什么方法可以直接知道哪个值是正确的?

如果有人有一些提示,那就太好了。再次感谢,再见。

2个回答

但是用wireshark打开它只是给了我一个错误“网络类型216未知或不受支持”

那是因为没有人为 Wireshark 提供对 DLT_LINUX_EVDEV 的支持。

该文件似乎没有任何损坏;如果它已损坏,Wireshark 会指出这一点。“网络类型 XXX 未知或不受支持”并不意味着文件已损坏,只是意味着 Wireshark 没有处理该特定链路层标头类型值。

让我们看一下标题:

D4 C3 B2 A1:这是一个小端 pcap 幻数。到现在为止还挺好。

02 00:这是 2 的小端主要版本号。

04 00:这是4的little-endian次要版本号。2.4是当前的pcap文件格式版本号;到目前为止,一切都很好。

00 00 00 00:这是时区偏移量,通常为 0。

00 00 00 00:这是时间戳精度,通常为0。

18 00 00 00:这是 0x18 或 24 的小端快照长度。

D8 00 00 00:这是 0xD8 或 216 或 DLT_LINUX_EVDEV 的小端链路层报头类型。

以下是数据包的记录:

8E 6E 6E 52:这是自 1970 年 1 月 1 日 00:00:00 UTC 值 0x526E6E8E 或 1382968974 以来的小端秒数,或 1382968974,或 10 月 28 日星期一 07:02:54,太平洋标准时间更多位一年半以前。

A9 CB 00 00:那是 0xCBA9 或 52137 的小端微秒值。

18 00 00 00:这是捕获的字节的小端计数,值为 0x18 或 24。

18 00 00 00:这是消息中实际存在的字节的小端计数(捕获过程可以截断超过某个点的数据;这就是文件中的快照长度所指示的),值为 0x18 或 24 .

24字节的数据包数据为:8E 6E 6E 52 00 00 00 00 A9 CB 00 00 00 00 00 00 04 00 04 00 1C 00 00 00

“EVDEV”指的是Linux 中evdev驱动程序,它允许各种用户输入提供者(键盘、鼠标、平板电脑、触控板、操纵杆等)插入其中,并将输入事件流合并为单个流可以被诸如 X 服务器或 Wayland 的 Weston 服务器之类的程序读取。

它的事件在 Linux “input.h” 头文件中被描述为

struct input_event {
    struct timeval time;
    __u16 type;
    __u16 code;
    __s32 value;
};

所以这是自 1970 年 1 月 1 日 00:00:00 UTC 以来的 64 位(?)秒,自那一秒以来的 64 位微秒,16 位类型,16 位代码和 32-位值。

不幸的是,根据 tcpdump-workers 邮件列表上的讨论,所有这些都按主机字节顺序排列。这个主机显然是小端的。

并且时间戳复制了 pcap 记录头中的时间戳。

所以我们有:

8E 6E 6E 52 00 00 00 00 - 0x526E6E8E,或与包记录头中的时间戳相同;

A9 CB 00 00 00 00 00 00 - 0xCBA9,或与数据包记录头中相同的微秒数;

04 00 - 0x0004,或4的类型,或根据Linux标头的“EV_MSC”,根据Linux事件代码文档“用于描述不适合其他类型的杂项输入数据”

04 00 - 0x0004,或4的代码,或根据Linux头的EV_MSC消息的“MSC_SCAN”;

1C 00 00 00 - 0x1C,或值为 30。

然后我们有下一个数据包:

8E 6E 6E 52 - 同一秒

A9 CB 00 00 - 相同的微秒

18 00 00 00 - 相同的长度,这并不奇怪,因为所有 evdev 消息都是 24 字节长

18 00 00 00 - 同样,同样的长度

8E 6E 6E 52 00 00 00 00 - 相同(重复)秒

A9 CB 00 00 00 00 00 00 - 相同(重复)微秒

01 00 - 0x0001,或键入“EV_KEY”,“用于描述键盘、按钮或其他类似按键的设备的状态变化”

1C 00 - 0x001C 或 28,即“KEY_ENTER”,其含义应该很明显(尽管我在笔记本电脑上打字的那个在下面用较大的字母表示“返回”,并且只说“输入”上面的小字母 :-))

00 00 00 00 - 0 的值

等等。

所以我绝对 100% 肯定它一个 pcap 文件,甚至不是一个损坏的文件;它恰好包含 Wireshark 不理解的消息。

链接类型,在“链接层头类型”的意义上,只出现一次,在文件的头中,所以没有理由期望文件中的任何其他链接类型 - pcap根本不支持不同的链接类型在一个单一的捕获文件中,除非使用了像 DLT_PPI 这样的 hack。因此,反对它是 pcap 文件的那部分论据是无效的。

至于地址,不能保证给定的 DLT_ 类型任何地址,evdev 事件也没有,所以这也不适用。

无论如何,如果您想在 Wireshark 中打开它,您需要为它找到或编写一个解剖器。

我很确定这根本不是 pcap 文件,不管文件怎么说,而且 D8 似乎根本不是网络类型。

首先,因为 D8 (216) 根据http://www.tcpdump.org/linktypes.html不是有效的链接类型

其次,因为十六进制转储更多的文件会产生这个:

00000000  d4 c3 b2 a1 02 00 04 00 00 00 00 00 00 00 00 00   ................
00000010  18 00 00 00 d8 00 00 00 8e 6e 6e 52 a9 cb 00 00   .........nnR....
00000020  18 00 00 00 18 00 00 00 8e 6e 6e 52 00 00 00 00   .........nnR....
00000030  a9 cb 00 00 00 00 00 00 04 00 04 00 1c 00 00 00   ................
00000040  8e 6e 6e 52 a9 cb 00 00 18 00 00 00 18 00 00 00   .nnR............
00000050  8e 6e 6e 52 00 00 00 00 a9 cb 00 00 00 00 00 00   .nnR............
00000060  01 00 1c 00 00 00 00 00 8e 6e 6e 52 a9 cb 00 00   .........nnR....
00000070  18 00 00 00 18 00 00 00 8e 6e 6e 52 00 00 00 00   .........nnR....
00000080  a9 cb 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

如果您稍微重构一下,重点关注 8e 6e 6e 52 (.nnR) 序列:

0000 d4 c3 b2 a1 02 00 04 00
0008 00 00 00 00 00 00 00 00
0010 18 00 00 00 d8 00 00 00 8e 6e 6e 52             a9 cb 00 00
0020 18 00 00 00 18 00 00 00 8e 6e 6e 52 00 00 00 00 a9 cb 00 00 
0034 00 00 00 00 
0038 04 00 04 00 1c 00 00 00 8e 6e 6e 52             a9 cb 00 00
0048 18 00 00 00 18 00 00 00 8e 6e 6e 52 00 00 00 00 a9 cb 00 00
005c 00 00 00 00
0060 01 00 1c 00 00 00 00 00 8e 6e 6e 52             a9 cb 00 00
0070 18 00 00 00 18 00 00 00 8e 6e 6e 52 00 00 00 00 a9 cb 00 00

您会看到 a) 文件显然有一个模式,并且 b) 如果第一个d8是链接类型,那么1c 并且也00 应该是链接类型。但是,将变化很大且内容相同的链接类型包含在一个捕获文件中是没有任何意义的。

此外,如果协议不是 tcp/ip,则没有任何东西类似于源和目标 ip 地址,或者至少是 mac 地址。

也许有人只是保存了 tcp 连接的有效负载,但在保存时不知何故犯了一个错误,给了它一个 tcpdump 标头。但我 99% 确定这不是损坏的 tcpdump 文件;这似乎是非常不同的事情。

现在如果你告诉我这个文件是 25 年前在运行 IPX 协议的 ARCNET 硬件上创建的,我可能会重新考虑,因为 arcnet 没有 mac 地址,只有 1-255 之间的网卡号,必须使用拨码开关进行配置,IPX 重用网卡号进行寻址。但是除非你有一个很好的解释文件是如何创建的,以及它应该包含哪种数据包和有效载荷,这可以解释结构,否则我会说这根本不是 tcpdump 或 pcap,并且修补一两个字节不会帮你在wireshark中打开它。