Home page logo
/

wireshark logo Wireshark mailing list archives

Re: Fileshark (AKA Dissecting Files with Wireshark)
From: Gilbert Ramirez <gram () alumni rice edu>
Date: Thu, 20 Jun 2013 16:28:09 -0700

Hmm, I don't know what I'm thinking of "file dissectors" as being analogous
to wiretap modules.  I should have thought of them as dissectors instead.
My fault.

As long as we have plugins with a good API, then that's good. In fact, we
should have a better plugin API than what we have now. I am thinking
specifically of custom file formats that I would want to write "file
dissectors" for (for some proprietary file formats at my job).

Thanks,

Gilbert



On Thu, Jun 20, 2013 at 3:57 PM, Evan Huus <eapache () gmail com> wrote:

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

___________________________________________________________________________
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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault