So the problem is that i have a corrupt pcap file. You can find a the pcap file [here][1]. First i did the file command on it : the.pcap: tcpdump capture file (little-endian) - version 2.4, capture length 24)So i thought Wireshark could open it easily and then i might be able to find any key/flag by analyzing the packets.But opening it with wireshark just gave me an error network type 216 unknown or unsupported. So first, i did some research on the different layers types for a pcap.Here is the link to the different value of layer header. As expected the type with the value 216 has no reference so i need to change the 216 value to the right one? But how ? how can i know which one is appropriate ? After googling a little bit i've seen that we can change the type's value manually.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 Below you can see the first bytes of the pcap file and the byte D8 is the type's value which here is equal to 216. Should i try to edit a program which modify the original pcap file with all the existing type value and see which one works ? or is there any way to directly to know which value is the right one ? If someone has some hint, it would be great. Thanks again and bye.
Find the right layer header for a corrupt pcap
digital forensics;networking;wireshark
But opening it with wireshark just gave me an error network type 216 unknown or unsupportedThat's because nobody's contributed support for DLT_LINUX_EVDEV to Wireshark.There does not appear to be anything at all corrupt about that file; if it were corrupt, Wireshark would have indicated that.  network type XXX unknown or unsupported doesn't mean the file is corrupt, it just means that Wireshark doesn't happen to handle that particular link-layer header type value.Let's look at the header:D4 C3 B2 A1: That's a little-endian pcap magic number.  So far, so good.02 00: That's a little-endian major version number of 2.04 00: That's a little-endian minor version number of 4.  2.4 is the current pcap file format version number; so far, so good.00 00 00 00: That's the time zone offset, which is usually 0.00 00 00 00: That's the time stamp accuracy, which is usually 0.18 00 00 00: That's a little-endian snapshot length of 0x18 or 24.D8 00 00 00: That's a little-endian link-layer header type of 0xD8, or 216, or DLT_LINUX_EVDEV.What follows are records for packets:8E 6E 6E 52: That's a little-endian seconds-since-January 1, 1970 00:00:00 UTC value of 0x526E6E8E, or 1382968974, or Mon Oct 28 07:02:54 2013 Pacific Standard Time - i.e., a bit more than a year and a half ago.A9 CB 00 00: That's a little-endian microseconds-since-that-second value of 0xCBA9, or 52137.18 00 00 00: That's a little-endian count of bytes captured, with a value of 0x18, or 24.18 00 00 00: That's a little-endian count of bytes that were actually in the message (the capture process can truncate data past a certain point; that's what the snapshot length in the file indicates), with a value of 0x18, or 24.And the 24 bytes of packet data are:8E 6E 6E 5200 00 00 00A9 CB 00 0000 00 00 0004 00 04 001C 00 00 00EVDEV refers to the evdev driver in Linux, which allows various providers of user input (keyboards, mice, tablets, trackpads, joysticks, etc.) to plug into it, and it merges the streams of input events into a single stream that can be read by programs such as the X server or the Weston server for Wayland.Its events are described in the Linux input.h header asstruct input_event {    struct timeval time;    __u16 type;    __u16 code;    __s32 value;};so that's a 64-bit(?) seconds-since-January 1, 1970, 00:00:00 UTC, a 64-bit microseconds since that second, a 16-bit type, a 16-bit code, and a 32-bit value.All, unfortunately, in host byte order, according to the discussion on the tcpdump-workers mailing list.  This host is, apparently, little-endian.And the time stamp duplicates the one in the pcap record header.So we have:8E 6E 6E 52 00 00 00 00 - 0x526E6E8E, or the same time stamp as in the packet record header;A9 CB 00 00 00 00 00 00 - 0xCBA9, or the same microseconds-since-that-second as in the packet record header;04 00 - 0x0004, or a type of 4, or EV_MSC according to the Linux header, and which is Used to describe miscellaneous input data that do not fit into other types according to the Linux event codes documentation;04 00 - 0x0004, or a code of 4, or MSC_SCAN for EV_MSC messages according to the Linux header;1C 00 00 00 - 0x1C, or a value of 30.And then we have the next packet:8E 6E 6E 52 - same secondA9 CB 00 00 - same microsecond18 00 00 00 - same length, not surprising as all evdev messages are 24 bytes long18 00 00 00 - again, same length8E 6E 6E 52 00 00 00 00 - same (duplicate) secondA9 CB 00 00 00 00 00 00 - same (duplicate) microsecond01 00 - 0x0001, or type EV_KEY, Used to describe state changes of keyboards, buttons, or other key-like devices1C 00 - 0x001C, or 28, which is KEY_ENTER, the meaning of which should be obvious (although the one on the laptop on which I'm typing this says return in larger letters below and only says enter in smaller letters above :-))00 00 00 00 - value of 0and so on.So I'm absolutely 100% certain that it is a pcap file, and isn't even a corrupted one; it just happens to contain messages that Wireshark doesn't understand.The link type, in the sense of link-layer header type, appears only once, in the file's header, so there's no reason to expect anything else to be a link type in the file - pcap simply doesn't support different link types in one single capture file, unless a hack like DLT_PPI is used.  So that part of the argument against it being a pcap file is invalid.As for addresses, there's no guarantee that a given DLT_ type has any addresses, and evdev events don't, so that doesn't apply, either.In any case, if you want to open it in Wireshark, you'll need to find or write a dissector for it.