Re: Fileshark (AKA Dissecting Files with Wireshark)

[Gilbert Ramirez <gram () alumni rice edu>]

I've written some tools to read various file formats, and what I have
learned from this is that it's really most useful to create:

1. a generic library for reading a file format.
2. an application dissector (i.e, a FileShark dissector) for using the
generic library, and providing the API that the application (FileShark)
wnats.
3. And on top of that, FileShark itself.

This is good so that other programs besides FileShark can make use of the
generic libraries.

This is different from how we did wiretap, in which the logic for
dissecting a packet capture is embedded directly in the wiretap module. If
another application wanted to decode packet captures, it would have to link
against wiretap, and use its APIs.

This would mean we might spawn some new projects that read the file
formats, and those would be separate from FileShark itself. But, that's
more generally useful.

Taking this a step further, maybe it's time to "harden" the APIs of the
various modules of Wireshark, and also break apart Wireshark. wiretap could
be removed entirely out of the Wireshark source base, and put into its own
SCM repo and released independently.

Gilbert





On Thu, Jun 20, 2013 at 2:15 PM, Guy Harris <guy () alum mit edu> wrote:

> On Jun 20, 2013, at 11:54 AM, Evan Huus <eapache () gmail com> wrote:
>
> > 3. Create a separate application called Fileshark that doesn't use
> > wiretap and links only against libfiledissectors. When dissecting
> > files directly, wiretap simply gets in the way. Additionally, people
> > have pointed out several possible UI changes that make sense for files
> > but not for packets. While hopefully Fileshark and Wireshark will be
> > able to share much of their code, there are still places where they
> > will diverge and we want to be able to do that cleanly.
>
> Yes.  For example, in Fileshark, you either:
>
>         1) might want to show, in a summary pane, multiple items for
> multiple sections/records/etc. of a file
>
> or
>
>         2) show only one pane, a detail pane, so that with everything
> closed up, you have a list of sections/records/etc..
>
> > Some of the consequences of this:
> > - Wireshark proper will not open non-capture files directly. It will
> > parse files it sees over transport protocols, but to parse an on-disk
> > file directly will require opening it in Fileshark.
>
> Note, BTW, that you might well want to have file dissectors for various
> forms of capture files that Wireshark can read; if you open those files in
> Wireshark, they'd show you the packets (and perhaps other records), but if
> you open them in Fileshark, they'd show you the file header (if there is
> one) and the file records (including the raw contents of record headers,
> etc.) - that might be a useful tool for Wireshark developers
> reverse-engineering features of not-publicly-documented file formats.
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org
> ?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe