>
> Stephen Fisher wrote:
> > On Mon, Jan 29, 2007 at 10:22:15AM -0000, Douglas Pratley wrote:
> >
> >> Are there any other encodings / decodings it would be worth having
> >> available (uuencode? zip?). This might be better done as a full
> >> "Select bytes and decode / encode" feature rather than
> something in a
> >> copy menu.
> >>
> > Good point. For viewing encoded e-mail contents, uudecode
> support may
> > be useful, though it's not very popular these days as far
> as I can tell.
> > We could go the whole way and even add viewers for images contained
> > within capture files. I'm not sure how useful this would be?
> >
>
> Every program attempts to expand until it can read mail ;-)))
...and browse the web, these days. Wouldn't take much to integrate an
HTML display engine into Wireshark, surely ;-)
>
> Ok, serious again, this is more of a question about a
> general way to copy/export/display "generic objects". Why not
> be able to copy/export/display a picture from a HTTP capture,
> or a HTML page, or ...
>
> Other analyzers will provide you with a list of files,
> derived from the captured HTTP packets, with an option to
> display/export it.
>
> That reminds me of the media dissector which already gets in
> that direction - we are getting more and more into the
> application layer - and I like it :-)
Given time, I'd tackle it like this, in three layers.
1) Provide the user with ways to select bytes of interest:
a) User can select exactly the bytes they want [New feature]
b) User can select the bytes represented by a line in the packet details
pane; dissectors can be "helpful" here, by breaking packets down
appropriately [Existing feature]
c) Specialist analysis for content-rich formats (mail, HTTP); I don't
know what is already in Wireshark. These could provide lists of embedded
data.
2) Ability to apply decodings / encodings to bytes of interest; I think
this should _not_ be built into the dissectors, as you then have to
repeat the code, or find you can't actually apply it to the exact set of
bytes that you want. A "reflective" architecture where encodings are
registered would make sense - easy to generate lists.
3) Ability to move encoded bytes (encoding may have been a NOOP) to
file, clipboard, viewers (again, registered viewers).
Each layer should be available, and hence re-usable, from within the
whole UI codebase, so defining decent interfaces would be important.
If this makes sense (some might think it over-engineered), I'll put
together a wish-list entry, and also put it forward as a suggestion in
our internal process. Unfortunately, I'm not free to tackle something
this large off my own bat in work time (and I'm organising my upcoming
wedding in my free time, so am not my own boss there either!). It's
possible that I'll get a chance to work on it later, or someone else
might like the idea enough to pick it up and run with it.
Cheers
Doug
This message should be regarded as confidential. If you have received this email in error please notify the sender and destroy it immediately.
Statements of intent shall only become binding when confirmed in hard copy by an authorised signatory. The contents of this email may relate to dealings with other companies within the Detica Group plc group of companies.
Detica Limited is registered in England under No: 1337451.
Registered offices: Surrey Research Park, Guildford, Surrey, GU2 7YP, England.
