Menu
pcap files to collect and record packet data from a network. PCAP comes in a range of formats including Libpcap, WinPcap, and PCAPng. These PCAP files can be used to view TCP/IP and UDP network packets. If you want to record network traffic then you need to create a .
The PCAP Next Generation Dump File Format (or pcapng for short) is an attempt to overcome the limitations of the currently widely used (but limited) libpcap format. The pcapng file format specification is still work in progress, see: The pcapng mailing list (and archives)
The pcap file format is a binary format, with support for nanosecond-precision timestamps.
I've got two PCAP files, A and B.
A has a 'magic number' in the header of d4 c3 b2 a1, B has a 'magic number' in the header of 4d 3c b2 a1. According to the wireshark documentation (http://wiki.wireshark.org/Development/LibpcapFileFormat), only 0xd4c3b2a1 and 0xa1b2c3d4 are valid magic numbers, which leads me to think that B is not a valid magic number.
Running file on linux backs this up, with the output of file A being:
tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 65535)
file B simply gives:
data
It looks like that whatever wrote B wrote it in a 'swapped' (little-endian) format, but wrote the forst twp bytes with the nibbles the wrong way round. Given that I'd expect a big-endian system to write the whole int32 the other way around and not the individual bytes, giving a magic number of 1a 2b 3c 4d.
Is B a valid file? If so, why? Can different systems write both 32-bit ints and the individual nibbles in a byte in an arbitrary order?
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With