3DPacketViewer: Native Wireshark Extensions for Field Location and OT Transaction Analysis

I have released 3DPacketViewer: two native Wireshark extensions, open source under GPL-2.0-or-later. Wireshark decodes the fields. These extensions show where each field is encoded, and how decoded operations relate across packets in OT and smart-grid traffic.

60-second demonstration (R-GOOSE)

Silent, captioned. Opens Routable_GOOSE.pcap, rotates and explodes the 3D protocol stack, locates goose.stNum in the byte & bit map, examines publisher observations in the semantic analyzer, shows one reviewed AI response, navigates to evidence frame 12, then disables AI. Provider waiting time is cut.

What it is

Module	Question it answers	Capabilities
3DPacketViewer 0.2.0	Where is this decoded field encoded?	Byte & bit map, source-relative offsets, raw hex/binary values, field inspector, interactive 3D protocol stack
Stateful Semantic Protocol Analyzer 0.1.0	How do decoded operations and observations relate over time?	Transaction correlation, publisher state, configured policy checks, temporal differences, evidence-linked findings

Both are Qt UI plugins integrated into the Wireshark source build and opened as modeless Wireshark-owned windows from the Tools menu. They are independent modules in one repository.

Why

Field location is implicit in Wireshark. The Packet Details tree gives the value; the byte pane gives a highlight. Bit-level position, container length, data source and provenance are not shown together. The viewer makes them explicit and adds a 3D view of the layer stack.
OT analysis is stateful. Whether a GOOSE stNum jump, an IEC 104 sequence gap or a Modbus write matters depends on what came before. Wireshark dissects one packet at a time. The analyzer correlates transactions and publisher state across the capture and links every finding to the frames that produced it.

Protocol coverage

Implemented profiles: IEC 60870-5-104, GOOSE / R-GOOSE, Sampled Values, MMS, Modbus/TCP, DNP3. Coverage differs by protocol; MMS confirmed-service envelopes and basic DNP3 application correlation are narrower than full conformance. The exact rule set is documented in PROTOCOLS.md.

Design constraints

Deterministic first. All statistics and findings are computed locally, offline.
AI is optional and gated. It receives only a reviewed, allowlisted JSON context that you see before pressing Send. Its output is labelled separately and cannot overwrite deterministic findings. See PRIVACY.md.
No network client in the visualizer.
No invented data. Geometry follows represented bit ranges; unmapped bits are not labelled payload; a state change or policy violation is not by itself an attack.

Build

Validated against Wireshark 4.7.4 development (pinned upstream commit) on Ubuntu 24.04, x86-64, with Qt 6.4.2, GCC 13.3, CMake 3.28, Ninja 1.11. Windows and macOS are not tested. The build script checks the revision and links the repository into the upstream build; it does not vendor or patch Wireshark.

git clone https://github.com/MamdouhEgy/3DPacketViewer.git
cd 3DPacketViewer
python3 tools/build.py --wireshark ../wireshark-pinned --build ../ws-build --jobs 4
../ws-build/run/wireshark

Then: Tools → 3DPacketViewer → Open 3D packet viewer, or Tools → Stateful Semantic Protocol Analyzer → Protocol Transactions. Platform dependencies are listed in BUILD.md.

Limits

Validation uses bounded fixtures and documented GUI runs, not standards certification or field deployment. Reverse selection from the plugin into Wireshark’s native Packet Details is not exposed by the plugin API. Remaining scope is tracked in LIMITATIONS.md and semantic/LIMITATIONS.md.