Re: [GSoC] Packet Editor and Viewer

[Edwin Abraham <edwin.abraham12 () gmail com>]

I agree on the confusion. The initial thought when I saw the project
details on the Wireshark GSoC page was that a platform to design dissectors
based on existing data. Then I extrapolated from that Idea to the Packet
Editor.

About the LUA code to run without restarting. We need to call init.lua
again to re-load the scripts. But that may interfere with the existing lua
based wireshark components. If we kill all captures and freeze the gui into
a refresh, during the re-loading of the scripts, that should help. I am not
quite sure of this. It may be better to reload the wslua machine itself.

My thought about the Packet Editor environment was to have a UI that can be
used for multiple functions. Packet editing, Creating Filter/Dissectors,
Tools making listener. The main function would be to extend the editcap
capabilities to the GUI.

After filtering out and selecting the required packets, they are opened in
the Packet Editor UI. The packets can be a capture file or a capturing
device but the filter has to narrow down the packet editing.
The UI will have three sets of toolbar and options
(editcap,dissector,listener) to manipulate the packet.

There will also exist a viewing tools to change how the selection of
packets are percieved. Like data can be represented as HEX/BIN/ASCII with
help of toggle switches. Then an edit tracker that highlights the edits to
the packet can be enabled with a full range of customizable colours for
each type of edit. The view will also have single packet view and multiple
view. Each of the single packet will have ability to switch the selected
data between HEX/BIN/ASCII/DEC. Whereas the Multiple Packet View will have
a default data representation of HEX so that the view is compact.

The Packet Editor part of the UI can have UI buttons for each of the
editcap functionalities like changing the timestamp, simple shifts to the
data, etc. Once the settings is applied for one packet it can be applied to
all the remaining packets in the packet editor UI. With simple highlighting
each of the changes can be seen so that when an edit is applied for the
entire selection of packets the progress can be seen. When saving if we
give option to store extra info about how the edit history looks like.

While using Packet Editor the Dissector/Listener toolbar should be disabled
when using the editcap based toolkit. This will avoid unnecessary bugs. The
Dissector/Listener will use the LUA interpreter to create custom dissectors
and listeners. The GUI will give more accessible methods to select and
create the protocol-fields and specify the details of each of them. As the
success of the simple Dissectors are tested we can even give the filters
access to use the UI to make the filters and save them. Listener
functionalities I will need to look a little more into them.

Below is a rough idea of how the UI can look like.



The difference between single view and multi-view is that it will have the
grid-structure with collapsible protocol headers in a column view. Each
data element can be given a option to be viewed as a different data type
than the rest in a pop-up and then resize the grid to accommodate the
change.

Since the custom dissectors will take time to implement the dissector. It
will be better to include a temp mode where the dissector can be applied to
the packet in the gui not in the packet before actually creating the
dissector.

Though I am saying editcap when referring to the editor. I mean to use the
functionalities. And then link the editcap to the gui later on.




On Sun, Apr 14, 2013 at 10:15 PM, Guy Harris <guy () alum mit edu> wrote:

> On Apr 14, 2013, at 12:45 AM, Edwin Abraham <edwin.abraham12 () gmail com>
> wrote:
>
> > Last Summer as a part of an internship at DRDO (Defense Research and
> Development Organisation) I was asked to go through their custom networking
> protocol. So that they could improve the protocol handling and how the
> application handled. Since they needed a quick fix and I used LUA scripts
> to write a custom dissector for them. They were happy with the result. But
> the in the end I realized they wanted to open the packet edit the data
> within wireshark, compare it with other protocols they were using.
> > I agree with the fact there is a Packet Viewer but it’s not editable.
> But if there is a UI where the packets can be manipulated by applying data
> changes or designing a dissector with the existing packets.
>
> Unless I *completely* misunderstand what you're proposing, "a UI where the
> packets can be manipulated by applying data changes" is a completely
> separate item from "[a UI for] designing a dissector with the existing
> packets".
>
> How do you envision the latter item working?  And would it be more useful
> if you had a UI to design a dissector *regardless* of whether you have a
> capture file open with packets for that protocol, even if it has some
> additional features that let you use existing packets for the protocol?
>
> > LUA is powerful and if the UI is setup to create the dissector without
> using an IDE or  at least eventually. If the reboot is given from within
> the UI we can resume the Packet Editor session when wireshark restarts.
>
> And if there's no need to *have* a reboot to use a new piece of Lua code,
> that would be even better - you wouldn't *need* to resume the session.
>
> > I was thinking the Packet Editor should be able to display the packet
> data to the user in the mode he desires. Like if the user wants to see the
> packet in hex, then a specific part in decimal. Or to have the headers
> applied and not applied on the packet. In the following is a rough idea of
> what I mean.
>
>         ...
>
> > Initially when a packet is opened it is already filtered by the headers
> IP,UDP,etc. This editor can display the data in a way comfortable to add
> custom headers (using dissectors) and temporarily apply and see the
> payload. Once the packet is modified to user requirement, the user can
> apply listeners to send the required data to the applications to analyse
> the data.
> > When I mentioned that the editor can exist on its own I meant the UI can
> be used wherever in wireshark to view packets like when designing
> dissectors, applying filter, or any kind of packet manipulation.
>
> You seem to be talking about changing the way packets are *displayed*.
>  That's not really an "editor" function, that's a "viewer" function; the
> Packet Editor (GUI) item in the Wireshark GSoC page says "It would be
> useful to be able to edit packet contents and to save edited packets back
> to disk."
>
> What you're describing could be interesting (although you need to describe
> it more clearly, for example by giving some examples of what the UI might
> look like and what operations it supports), but it doesn't sound as if it's
> a "packet editor", it sounds more like a "dissector editor".  I.e., it
> sounds as if you're describing something that lets you change the way
> packet data is displayed, not something that lets you actually change the
> data *in* the packet.
>
> ___________________________________________________________________________
> 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



-- 
Edwin Abraham,
BITS Pilani Goa Campus

___________________________________________________________________________
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