00jciv00 / zing

A small Zig tool & library to craft and interact with basic network datagrams based on IETF specifications.

zing

A small Zig tool for crafting datagrams and interacting with networks, based on IETF specifications.

Overview

This project is an experiment to learn more about the basics of how network datagrams (Frames, Packets, and Segments/UDP Datagrams) work by coding parts of the IETF spec in Zig. This is a continuation of packt-lib, a similar project written in Kotlin. I've moved to Zig to help myself understand the lower level intricasies of networking and bit/byte manipulation. Optimally, the tool will allow users to manipulate network directly through the library, a DSL (.json, .toml?, and .zon?), or an interactive shell.

Goals

• Replicate Basic Networking Headers:
  • IP
  • ICMP
  • UDP
  • TCP
  • Ethernet
• Replicate Basic Networking Addresses:
  • IPv4
  • IPv6
  • MAC
• Add data to Networking Headers to create Datagrams
• Craft & Send Datagrams on an interface:

Datagram	Layer	Craft	Send
Ethernet	2	Y	Y
WiFi	2	Y	N
Bluetooth	2	N	N
IP	3	Y	Y
ICMP	3	Y	Y
ARP	3	Y	Y
UDP	4	Y	Y
TCP	4	Y	Y

• Implement Sending a Stream of Datagrams

• Implement Receiving Datagrams

• Implement Basic Connection Protocol Handling

  • ICMP
  • ARP
  • TCP

• Network Scanning tools

• File Transfer tools

Resources

• IP
• ARP
• ICMP
• UDP
• TCP

zing's Issues

WiFi Frame Handling

• Add parity between WiFi Frames and Ethernet Frames.
• Support Data, Management, and Control Frames.

Iptables

I hear you're having trouble with your packets getting marked invalid by iptables. Have you thought about rewriting it in rust? Not sure, but I'm guessing it'll fix the issue.

Add IPv6 Addresses

Support them to the same level as IPv4 and MAC Addresses.

BPF Filtering on Interfaces

• Filters should be based on user input for the Zing tool.
• Simple abstractions should be available in the Zing library.
• This filtering should be applied in either connect.zig or receive.zig.

Solution for Variable Length Headers

Several Datagram Headers can be of a variable length. Typically, this just means that there's an associated length field in the fixed part of the header, then a number of "options" (or similar) that may or may not be at the end.

Datagrams.zig should include "Layer Options" that will be kept in slices between each layer. During the checksum/CRC calculations, these slices will be narrowed down to the required bytes which are then passed on to the required functions.

Interaction Context Expressions for Datagram Crafting

When crafting a Datagram, there needs to be a way to add small expressions that can be handled during Interactions. These expressions would allow for simple tasks like incrementing/decrementing a field or setting specific value based on the context of the Interaction.

One possible solution for this is using a StringHashMap that holds Datagram fields in dot notation as the keys and simple expressions as the values.

PCAP Encoding

• Add PCAP Encoding to craft.zig and record.zig.
• Choose between PCAP or PCAP-NG. (Probably the latter).
• Figure out the simplest way to both ingest and append GPS data.

Optional `libc`

The library should be able to optionally use libc if it's linked at build time. While Zing is intended to be "pure" Zig, there are a few areas that could benefit from having that available. Namely, getting Linux constants from the target OS's C header files, which could overwrite the defaults in constants.zig.

Scan Tool

The Scan Tool should be able to make basic scans across Layer 2 (ARP), Layer 3 (ICMP), Layer 4 (TCP).