Re: [GSoC] Packet Editor and Viewer

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

I want to start working on the LUA interpreter to achieve minimum to no
reboot required to execute LUA scripts added while Wireshark is running. I
have started to make a list of areas the LUA interpreter is being blocked.
I wanted to know if there is anything specific I should look for while
digging into the LUA interpreter. I also want to develop a better
understanding of how the wslua machine is loaded while wireshark is booted.

As for the Packet Editor I will start working on the Edit toolbar
functionalities that need to be added to the Packet Editor. I will start by
enlisting the editcap funtions and translating them to GUI based approach
and start working on the UI with edit functions.

This is the proposed UI design for the Packet Editor. Please let me know
your thoughts
https://docs.google.com/file/d/0BzQfAxVhGpq9S2RKWGxudExnQjQ/edit?usp=sharing


On Tue, Apr 16, 2013 at 2:30 AM, Edwin Abraham <edwin.abraham12 () gmail com>wrote:

> Sorry for the mess in the previous mail. Here is the link to the GUI jpeg
>  packet-editor-UI.jpg<https://docs.google.com/file/d/0BzQfAxVhGpq9S2RKWGxudExnQjQ/edit?ups=drive_web>
>
>
>
> On Tue, Apr 16, 2013 at 2:27 AM, Edwin Abraham <edwin.abraham12 () gmail com>wrote:
>
> > 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
>
>
>
> --
> Edwin Abraham,
> BITS Pilani Goa Campus



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