GSoC2020

Google Summer of Code 2020

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

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. The mentor organization application has been completed.

Important dates (from Timeline):

Links

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

Ideas

As discussed at https://www.wireshark.org/lists/wireshark-dev/201302/msg00199.html please use the following template for proposed topics.

Please provide as much information as possible.

Students who are considering one of these ideas, please read https://google.github.io/gsocguides/student/writing-a-proposal.

USB Audio/Video stream export

Summary. Wireshark features RTP stream analysis and filtering. It would be nice to have similar functionality for USB Audio and/or USB Video class devices. USB Audio devices describe the supported audio formats in class-specific descriptors. Information from descriptors alongside with control requests can be used to determine the format used in isochronous transfers (e.g. 16-bit PCM).

Expected Result. Ability to playback captured USB Audio streams.

Mentor(s). Tomasz Moń

Prerequisites. C, C++, Qt

Area(s) of Wireshark. libwireshark (dissector), UI

USB HID Report Descriptor parser

Summary. Wireshark currently has basic USB HID class dissector. While it is capable of dissecting the HID Report Descriptor itself, it only annotates the bytes within the descriptor. The USB HID dissector does not parse the HID Report Descriptor and does not build any report format representation based on it. The goal is that instead of showing "Leftover Capture Data" for the interrupt transfers (HID Reports) it would show what individual bytes mean (e.g. buttons state).

Expected Result. USB HID Reports would be dissected based on the HID Report Descriptor present in the capture.

Mentor(s). Tomasz Moń

Prerequisites. C, Compiler Theory, USB HID

Area(s) of Wireshark. libwireshark (dissector)

USB 2.0 Link Layer reassembly

Summary. Wireshark 3.2.0 includes basic USB Link Layer dissector. It currently only works at the USB packet level. The goal is to extend the dissector in a way that it would reassemble the transfers (including SPLIT transactions) and pass reassembled data to USB dissector ("URB dissector").

Expected Result. Existing USB class dissectors (e.g. Audio) dissecting USB transfers reassembled from the USB packets captured by hardware USB sniffer (e.g. OpenVizsla).

Mentor(s). Tomasz Moń

Prerequisites. C, USB 2.0

Area(s) of Wireshark. libwireshark (dissector)

Extcap interface improvements

Summary. Wireshark extcap interface allows easy integration of various capture sources. While the extcap interface is generally working fine, there are some outstanding bugs that limit its usefulness. The project idea is to fix multiple extcap related bugs/feature requests, e.g. properly indicate capture source, bookmark extcap options as new "interface", reduce number of configuration calls to extcap binary, implement grouping in selector options.

Expected Result. Improved extcap interface support, lower amount of open extcap bugs.

Mentor(s). Tomasz Moń

Prerequisites. C, C++, Qt

Area(s) of Wireshark. extcap, UI

SSH decryption support

Summary. Wireshark supports dissection of the initial plaintext SSH protocol messages, but support is missing for decryption of encrypted protocol messages (authentication messages, shell commands and output, file transfers (SFTP), forwarded ports, etc.). To enable dissection of the latter protocol messages, decryption has to be implemented in Wireshark based on externally supplied secrets. These external secrets can be obtained from an existing SSH client or server using a debugger or other means (to be implemented).

(See also https://wiki.wireshark.org/OpenSourceSoftwareEngineeringFall2019)

NOTE: this idea is very popular among students. To increase your chances of success, write a very good proposal or consider alternative ideas on this page. You can also propose other topics that you find interesting, feel free to reach out to me -- PeterWu.

Expected Result. Ability to (1) decrypt SSHv2 packet captures with modern ciphers based on (2) externally provided shared Diffie-Hellman secrets, and (3) dissect the resulting plaintext protocol messages.

Mentor(s). Peter Wu

Prerequisites. C, basic cryptography preferred (familiarity with Diffie-Hellman, ChaCha20-Poly1305, AES-GCM/CBC).

Area(s) of Wireshark. libwireshark (dissector)

User interface accessibility improvements

Summary. The Wireshark user interface is written using the Qt framework which has some accessibility features. Right now there are known accessibility issues which could make Wireshark harder to use for sight-impaired users with a screen reader for example. To be done: identify accessibility issues and propose solutions.

For some known issues, see https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9284

Expected Result. A written overview with the results of the investigation of accessibility problems, and patches to address these.

Mentor(s). Peter Wu

Prerequisites. Qt and some C++ knowledge preferred. Empathy.

Area(s) of Wireshark. Qt UI

Unify HTTP and HTTP/2 features

Summary. The HTTP dissector supports the classic HTTP (0.9, 1.0, 1.1) protocol while a separate HTTP/2 dissector exists for the newer HTTP/2 protocol. A HTTP/3 dissector is in development. Unfortunately, separate dissectors result in different field names (http.content_length, http2.headers.content_length) for an item with the same semantics. It would be great if these can be unified under a single field name.

Another HTTP dissector-specific feature is "Export Objects", saving the body of a message. This should be extended to support HTTP/2, under the same user interface. https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16126

Expected Result. A better experience for HTTP analysts with working Export Objects for HTTP/2, and a single way to filter for HTTP and HTTP/2 headers.

Mentor(s). Peter Wu

Prerequisites. C. Basic HTTP and HTTP/2 knowledge. Some Qt skills would be useful, but not required.

Area(s) of Wireshark. libwireshark (dissectors), Qt UI

Make process information available

Summary. Wireshark currently captures packets from a single network interface where a capture filter can be applied to remove uninteresting packets. These captures can subsequently be filtered using a display filter based on properties such as IP address and port number, but there is no way to express something such as "filter all packets from Firefox". To make this possible, a mechanism is necessary to link packets to processes. This is very operating system dependent, and it might not even possible to link a packets to a process (for example, for ingress traffic).

On Linux for example, one can use eBPF or the tracing subsystem to retrieve socket information in a reliable manner. On most platforms (Linux, macOS, Windows, ...) one can use the netstat command to retrieve socket information, but this is not fully reliable. These are privileged operations, and since captures may be done remotely, the capture process is most likely a good candidate for these kind of modifications.

Related bugs for two use cases: * Bug 1184 - *Shark should support associating TCP and UDP packets with processes * Bug 16194 - Allow us to filter traffic by sending or receiving process

Difficulty. very hard

Expected Result. A mechanism through which process information is made available for at least one platform and linkable to packets. Ideally a mechanism to limit a capture to one or more processes and potentially their children.

Mentor(s). Peter Wu

Prerequisites. C. Strong systems knowledge.

Area(s) of Wireshark. libwireshark (dissectors), wiretap (capture file reading library), dumpcap/libpcap (capture processes), Qt UI

Put Wireshark on a diet

Summary. Wireshark has about 1500 C files for protocols that are part of libwireshark, the dissectors library. There are dependencies between them, and other components such as the Qt GUI may require exported symbols from libwireshark. In order to make Wireshark smaller in order to fit on smaller devices, it might be desirable to strip the number of dissectors to a subset of protocols (HTTP) plus their potential dependencies (TCP, IP, TLS, X.509, Ethernet, 802.11, ...).

Another use case is during development: if one is testing the GUI only, or performing a Git bisect process to isolate a bug in one dissector, it can save some time if a lot of esoteric protocols can be excluded from the build.

Expected Result. A build mode in CMake where the number of dissectors can be stripped down to generate a smaller binary with fewer source files. An updated test suite to account for the possibility that protocols may not be available.

Mentor(s). Peter Wu

Prerequisites. C. Familiarity with the CMake build system is preferred.

Area(s) of Wireshark. libwireshark (dissectors), the CMake build system, test suite in Python/pytest.

Fully asynchronous Qt UI

Summary. In the past there have been few issues related to Qt UI code calling QCoreApplication::processEvents() and/or QDialog::exec(). The Qt documentation mentions "Note: Avoid using this function; instead, use open(). Unlike exec(), open() is asynchronous, and does not spin an additional event loop. This prevents a series of dangerous bugs from happening (e.g. deleting the dialog's parent while the dialog is open via exec()). When using open() you can connect to the finished() signal of QDialog to be notified when the dialog is closed.". The goal is eliminate all uses of exec() in Wireshark UI code and to limit QCoreApplication::processEvents() usage to absolute minimum.

Expected Result. Single Qt event loop regardless what actions user takes.

Mentor(s). Tomasz Moń

Prerequisites. C, C++, Qt

Area(s) of Wireshark. UI

WebRTC: DTLS-SRTP decryption and Opus playback support

Summary. Wireshark has basic support for playing and saving RTP media streams. WebRTC however supports encrypted media streams using DTLS as basic cryptographic handshake protocol, resulting in DTLS-SRTP. This is not yet supported by Wireshark. Additionally, the Opus codec is not yet supported, but required for WebRTC.

See also https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13193

Expected Result. Ability to play decrypted DTLS-SRTP media streams in Wireshark using a secret from the TLS key log. Ability to playback audio streams using the Opus codec, integrating with the existing Opus codec library.

Mentor(s). Peter Wu

Prerequisites. C, basic cryptography preferred (familiarity with (D)TLS, AES-CTR). Knowledge about media codecs are also a plus.

Area(s) of Wireshark. libwireshark (dissector), libcodecs.

Others

The above list of projects are suggested examples. Feel free to propose your own idea on the wireshark-dev mailing list.

For a full list of open issues and feature requests, see https://bugs.wireshark.org/bugzilla/buglist.cgi?limit=0&order=bug_id%20DESC&resolution=---. Users might also ask questions on https://ask.wireshark.org/, but are typically requested to open a bug entry if they have feature requests or bug reports.

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