On Mon, Feb 7, 2011 at 11:36 AM, Gregory Seidman
<gsslist+wireshark@xxxxxxxxxxxxxxxxxx> wrote:
> Ah, interesting. Thanks for the info on netdude. I clearly disagree with
> you in that I think Wireshark (the project, though not necessarily the
> existing GUI) is the best possible place for packet editing.
Modifying packets would involve significantly more work on the part of
the dissector developers, and it can be very difficult to even know
what it means to "modify" a packets.
I've wrestled with this a bunch, including the poverty of good packet
construction toolkits. I'm currently maintaining libnet (NOT the
author), and also work for a company (Wurldtech) that generates bad
protocol traffic to test implementations. Here's some stuff to think
about.
Right now, wireshark has C code that decodes packets, building an
in-memory tree for the UI (or tshark) that describes the packet.
Going the other way, since the tree knows what bytes are associated
with values, might not seem such a big deal, but editing a packet has
several possible, but very different, outcomes.
One is the packet is still somewhat valid. This involves recursing
back down the packet tree, correcting encapsulating lengths and
checksums as you go. Also, perhaps correcting other linking
elements (you change a function ID in a packet, but the function ID is
also present in an encapsulating layer, should it be changed in both
places?).
The other is the packet is being "fuzzed", the result is intended to
be invalid. This is simpler, you just change one thing. But, its
rarely so simple, even when generating test data. Many protocol
processors will discard any data with bad checksums, so you don't end
up actually getting your test data processed unless checksums are
recalculated. So some kind of semi-validity is still required.
libnet's API allows rewriting a layer of a protocol in-place, but
isn't good at it, can easily result in (unintentionally) invalid
packets, and also was subtle enough that doing so could often cause
libnet to segfault. Tough going.
The effect of all this is there is very little choice or discretion
involved in packet decoding, what wireshark does. Somebody else made
the packet, you are just displaying it (though you might run into some
difficulties if the packet is invalid, and wireshark does have the
occaisonal puke-up on bad packets).
Going the other way, encoding packets, there are HUGE amounts of
discretion and choice involved, and once you get into the realm of
modifying packets, possibly involving generating non-compliant
packets, the choice explodes to the point that I can's see how a
general purpuse GUI would ever do a good job of it.
Cheers,
Sam