CODEWITHSUNDEEP
pcap
Christian
Christian

Reputation: 123

How to get byte alignment of a pcap file?

I'm trying to read a PCAP file created by differnt tools.

One tool does no byte alignment, the other one always aligns to the next double word. How can I figure out which alignment is being used?

As mentioned here: https://wiki.wireshark.org/Development/LibpcapFileFormat

Each captured packet starts with (any byte alignment possible)[...]

I don't want to use libpcap, because my files are sometimes broken and I then need to work with the bits and bytes of the underlying file.

Upvotes: 1

Views: 1841

Answers (1)

user862787
user862787

Reputation:

The official man page for the pcap file format specifies that the file begins with a 24-byte file header, followed immediately (with no padding) by a sequence of packet records.

Each packet begins with a 16-byte header, followed by the packet data; there is NO padding after the packet data - there are exactly as many bytes of packet data as are specified by the "Length of captured packet data" field in the header.

So, yes, any byte alignment is possible.

If some tool is putting padding between packets, that tool has a bug. There is no provision in pcap files to record whether there's any such padding, as there's not supposed to be such padding.

So any repair to malformed pcap files with padding requires heuristics to guess whether there's padding or not. You might want to look at the pcapfix tool to see if it can repair any of the bad files being produced by the second tool. (And please tell whoever wrote that tool NOT to pad packet records to guarantee that the next record is on a double word boundary!)

If the tool writes out records with the captured length field not including the length of the padding - for example, if a 63-byte packet, all of which was captured, has a captured length of 63 and one extra byte of padding - then you could write your own fixer program. It would:

  • read the file header and write it out;
  • read each packet, calculate the rounded-up-to-a-doubleword-size value of the captured length, write out the packet header and the non-rounded-up number of bytes of captured data, and skip the next ({rounded-up captured length} - {captured length in the header}) bytes (the padding) to get to the beginning of the next packet;

and do that until it runs out of packets.

Upvotes: 3

Related Questions