Google Summer of Code 2013

Each year Google brings students and open source projects together in the Google Summer of Code. This page tracks Wireshark's participation in GSoC 2013.

Google Summer of Code 2013
Guidelines
- Status
- Links
Ideas

Guidelines

The ideas below have been contributed by Wireshark's community of developers and users. Some of them are "what ifs". Some are based on very specific and immediate needs. Either way, if you are a student you should contact the submitter/mentor or the wireshark-dev mailing list for background information or clarification before submitting your proposal. More information about wireshark-dev and complete list archives can be found on the mailing lists page.

If you are adding an idea below, please be as clear and provide as much information as possible. Projects that can be completed in about 12 weeks are preferred.

Status

We're collecting proposals for projects. See "Ideas" below.

Links

The Nmap SoC page has some good guidelines for students including:

Ideas

As discussed at http://www.wireshark.org/lists/wireshark-dev/201302/msg00199.html please use the following template. Proposals should be sorted alphabetically by title.

Subject
Summary of the topic, what should be done
Summary of the expected result
Developer who could mentor
Prerequisites
Level of expertise in these languages (beg./adv./exp.)
Area of Wireshark it applies
Level of wireshark expertise needed
Amount of time estimated for a developer already familiar with the code

Please provide as much information as possible.

Arbitrary capture sources

Summary. Wireshark uses an external program called dumpcap to perform packet capture. Dumpcap only supports capture via libpcap/WinPcap or stdin. It would be amazingly useful to be able to capture from other sources, such as a remote instance of tcpdump or dumpcap data via SSH or a non-libpcap based capture source such as KisBee.

Expected Result. The user should be able to add custom capture sources to the interface list. The user should be able to configure them similar to local interfaces (e.g. set a snapshot length or a capture filter), and they should otherwise act like a normal interface.

Mentor(s). Gerald Combs

Prerequisites. Dumpcap is written in C, and modifying it requires intermediate level C. Capture sources should probably be written in one or more common scripting languages such as Bash, Python, or Ruby in order to provide working examples for the community.

Area(s) of Wireshark. Capture, UI

Capture Permissions

Summary. You shouldn't run Wireshark as root. Ever. Linux, OS X, and sometimes Windows want you to be root when you capture network traffic. We've made some progress in this area but we're not quite there yet. For this project the student should come up with a way to capture packets on Linux and OS X which requires minimal interaction from the user without sacrificing security.

Expected Result. When a normal user runs Wireshark they should see a list of interfaces and be able to apply capture filters and capture on those interfaces. They shouldn't have to run Wireshark as root, change device permissions, or make other modifications to their system.

Mentor(s). Gerald Combs

Prerequisites. Intermediate C, privilege separation concepts on Linux (Polkit) and OS X (Authorization Services).

Area(s) of Wireshark. Dumpcap, UI, privilege separation

File-backed tvbuffs

Summary. Tvbuffs (testy, virtual buffers) are one of Wireshark's primary data structures. Everything you see in the packet detail and packet bytes views are driven by tvbuffs. This is also why Wireshark consumes lots of memory. The contents of tvbuffs are normally copies of data that resides on disk, so it should be possible to reduce memory consumption by reading tvbuff data from the filesystem instead of copying data to memory, at least in some cases.

Expected Result. Wireshark should consume less memory with little to no loss in performance.

Mentor(s). Gerald Combs

Prerequisites. Intermediate C

Area(s) of Wireshark. Dissection core, memory management

Process Information

Summary. Most packets come from and go to users and processes. Who and what are they? Most major operating systems have event and/or polling-based mechanisms for gathering this information and tying it to packets but so far no one has added support for this to Wireshark.

Expected Result. The application and user associated with each packet should be shown in the packet detail. Process information should be available on Linux, OS X, and Windows. If you could associate a stack trace with a packet a limited subset of the world would sing your praises.

Mentor(s). Gerald Combs

Prerequisites. Intermediate C

Area(s) of Wireshark. Dumpcap

JSONshark

Summary. A dual project: a JSON message based interface to epan (Wireshark's dissection core), and a Javascript Browser App to control it.

Expected Result. A web based shark.

Mentor(s). LuisOntanon

Prerequisites. Intermediate C, JavaScript

Area(s) of Wireshark. EPAN, UI

New Export Objects

Summary. Wireshark can export objects embedded in HTTP, SMB, and DICOM streams but there are many other protocols that we don't support such as FTP and SMTP.

Expected Result. The user should be able to extract files from FTP, SMTP, and other protocol streams.

Mentor(s). Alexis La Goutte

Prerequisites. Intermediate C

Area(s) of Wireshark. EPAN, UI

QtShark

Summary. Wireshark currently uses the GTK toolkit. An initial port to Qt (aka QtShark) has begun but there is lots of work to do. There are also many opportunities to take Wireshark's user interface to the next level. If you have an idea for a better way to implement one of Wireshark's current features or for a great new feature this is the place to propose it.

Expected Result. A new UI for Wireshark.

Mentor(s). Alexis La Goutte

Prerequisites. Intermediate C/C++, Qt API, UX

Area(s) of Wireshark. UI

Wireshark for Android

Summary. Port Wireshark to Android. This includes translating the current deskop-based method of analyzing packets and to a touch-based workflow.

Expected Result. Packets. On a tablet.

Mentor(s). Gerald Combs

Prerequisites. Intermediate C/C++.

Area(s) of Wireshark. UI/UX, Qt

See also. JSONshark above, Android PCAP, Ubertooth for Android, Necessitas (Qt for Android)

Discussion.

My belief is that the best way to do "packets on a tablet" is through a web browser (see JSONshark). -- Luis
I think the uses cases are different and both are valid. JSONshark would separate the capture source from display, which is a radical shift from our current architecture. This would make it easier for a home user to see what's happening on his or her router for example. An Android port would let you run Wireshark on your phone or tablet, and thanks to Mike Kershaw you can now do local 802.11 capture with an RTL 8187 adapter. -- Gerald
JSONshark could also let you do statistics taps on the client, with only the dissection done on the server. However, it separates the capture source from display, but doesn't separate capture source from dissection; to separate them, you need some remote capture protocol such as rpcap. What do you see having to be installed on the router for the home user scenario? -- Guy
Java is also a pre-req for this, right? -- G94

Timing Information Graph

Summary. Chrome, Fiddler and other tools have popularized the use of timing information displays. This sort of analysis is missing in Wireshark but we could provide a much deeper view than other products. For example, Wireshark could show ARP along with HTTP and DNS transactions that other tools currently show. We could also show timing information for other protocols such as SMB.

Expected Result. The display should show a list of conversations with timing information rendered graphically.

Mentor(s). Gerald Combs

Prerequisites. Intermediate C/C++, Qt

Area(s) of Wireshark. UI/UX, data visualization

See also. The "Network" display in Chrome's Developer Tools.

Discussion. It might be possible to leverage the current conversation list code for this.

Improved Fuzzing

Summary. Spend a summer breaking Wireshark! Wireshark's automated build system runs fuzz tests all day, every day. It has helped us to find many serious bugs. However the testing environment is naive and inefficient, and doesn't reflect the current state of the art in fuzzing.

Expected Result. Fuzz tests should be more efficient and have more complete coverage.

Mentor(s). Gerald Combs

Prerequisites. Advanced C, scripting languages (Bash, possibly others), security

Area(s) of Wireshark. Dissection engine, file readers

Packet Editor (UI)

Summary. It would be useful to be able to edit packet contents and to save edited packets back to disk. There is preliminary support for this but there is plenty of work to do to fully implement this. Wireshark is unique in that it should be possible to go beyond simple hex editing and modify packets based on protocol fields.

Expected Result. Users should be able to easily and naturally edit packets interactively.

Mentor(s). Gerald Combs

Prerequisites. Intermediate C/C++, Qt or GTK APIs.

Area(s) of Wireshark. Dissection engine, file formats

Packet Editor (CLI)

Summary. Along with interactive editing above it would be useful if editcap's editing capabilities were enhanced so that users could arbitrarily insert, modify, and remove data in all the packets in a given capture file. For example, to rewrite sequence numbers or to anonymize packets by substituting addresses or removing or overwriting sensitive data.

Expected Result. Users should be able to modify packet contents on a massive scale.

Mentor(s). Gerald Combs

Prerequisites. Intermediate C/C++.

Area(s) of Wireshark. Dissection engine, file formats

itshark (CLI)

Summary. An interactive version of tshark

Expected Result. Users should be able to capture and open files, then to filter the packets and visualize summaries and the protocol tree of individual packets on request.

Mentor(s). LuisOntanon

Prerequisites. Intermediate C/C++.

Area(s) of Wireshark. Epan, console

Discussion. Are you thinking of a "command-line" program, in the sense that, for example, ed or ex are "command-line" editors, or a "full-screen" or "curses" program, in the sense that vi or emacs are "full-screen" editors (which would probably be more like "a curses version of Wireshark" than "an interactive version of tshark"), or both? --GuyHarris

I was thinking in something like ed to begin with, so it can later be daemonized. A curses adaptation, would be nice too, especially for embedding it into routers and similar devices. --LuisOntanon

Fileshark

Summary. Wireshark will open and let you explore MP3s, PNGs, and other non-network capture files but that's not its main purpose. A fork of Wireshark could be created that focuses on file formats instead of network traffic, letting users view the internal structures of images, executable objects, office documents, PDFs, and other files.

Expected Result. A sister executable or project for Wireshark that can be used for file exploration.

Mentor(s). Unknown

Prerequisites. Intermediate C/C++, Qt API.

Area(s) of Wireshark. UI, wiretap, epan.

Imported from https://wiki.wireshark.org/GSoC2013 on 2020-08-11 23:14:26 UTC