Re: Fileshark (AKA Dissecting Files with Wireshark)

[Evan Huus <eapache () gmail com>]

On Thu, Jun 20, 2013 at 2:39 PM, Gilbert Ramirez <gram () alumni rice edu> wrote:
> 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.

I think this is the wrong way to approach the problem. To draw a
parallel, there's a reason we don't just link a normal TCP stack into
Wireshark. The goal is to be able to display the raw structure of the
file/packets, which is sometimes quite different from the values that
an application reading the file/packets is going to care about.

> 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.

Wiretap is a library for reading packet file formats, which is
basically step 1 of your proposal. I'm not entirely clear on what in
your proposal is different, or why it makes sense to do this.

> 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.

If we're going to be decoding a file in Fileshark, there's almost
certainly already a library to read/write it for applications, as
otherwise there would be no files for us to decode.

> 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.

I would be very happy to make proper libraries out of wiretap,
dfilter, epan, etc (and I designed wmem with this in mind). I suspect
splitting them out into multiple repositories is just making work at
this point, but if there's interest once they're usable stand-alone
then it might make sense to reconsider.

Evan

> 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
___________________________________________________________________________
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