--- Begin Message ---
On Sat, 11 Jun 2022 10:51:41 -0400
Michael Richardson <m...@sandelman.ca> wrote:
> Denis Ovsienko via tcpdump-workers
> <tcpdump-workers@lists.tcpdump.org> wrote:
> > Below is a draft of such a file format. It addresses the
> > following needs:
> > * There is a header with a signature string to avoid false
> > positive detection as some other file type that begins exactly
> > with particular bytecode (ran into this during disassembly
> > experiments).
>
> Looks good, but I suggest that rather than 'savefile', that it
> contain something about the program that wrote it, and then a CRC32
> on the first 12 bytes.
> That protects against a .txt file that starts with with cBPFsavefile
> :-)
Thank you for the feedback. The essential thing is to declare what the
file is, in that sense I agree a binary marker would work better. It
could be, for example, 0xa1, 0xb2, 0xc3, 0xcb (along the lines of
sf-pcap.c, but not yet taken). With that in place, the program that
generates the file can leave a "XYZ BPF compiler was 'ere" string in an
optional TLV, if it wants.
The CRC is an interesting point, but it would need to cover more data
to make a meaningful difference in the sense of data integrity. Thus it
would need to be as close to the end of file as possible in order not
to block/buffer subsequent output data (fseek() does not work on pipes).
This way, to be a part of the initial version, the CRC would need to be
very carefully defined.
> https://datatracker.ietf.org/doc/draft-ietf-cbor-file-magic/ is
> waiting on editing, and deals with these issues from a CBOR point of
> view. Instructions *could* just be a CBOR array or CBOR arrays
Maybe in a later version. Let's keep the initial encoding as simple as
possible, for both reading and writing.
> > TLV format:
>
> I'm really not keen for Yet-Another-TLV format.
> I don't think that the disk space is so constrained to use 24-bits
> rather than 32-bits for the TL header.
Fine, let it be 16+16 bits then.
--
Denis Ovsienko
--- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers