Wireshark · Wireshark-dev: Re: [Wireshark-dev] [GSoC] Packet Editor and Viewer

[Edwin Abraham <edwin.abraham12@xxxxxxxxx>]

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@xxxxxxxxx> wrote:

Sorry for the mess in the previous mail. Here is the link to the GUI jpeg

 packet-editor-UI.jpg

On Tue, Apr 16, 2013 at 2:27 AM, Edwin Abraham <edwin.abraham12@xxxxxxxxx> 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@xxxxxxxxxxxx> wrote:

On Apr 14, 2013, at 12:45 AM, Edwin Abraham <edwin.abraham12@xxxxxxxxx> 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@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

--

Edwin Abraham,
BITS Pilani Goa Campus

--

Edwin Abraham,
BITS Pilani Goa Campus

--

Edwin Abraham,
BITS Pilani Goa Campus