spliffedr

Take a look at https://github.com/concurrencykit/ck and https://github.com/microsoft/mimalloc, it will fit well for a zero-copy and mem aligned reverse proxy. Also, if you want to add a DDoS protection and more advanced L4 stuff check out https://docs.ebpf.io/ebpf-library/libxdp/libxdp/

I kinda built(vibe-coded) the same thing[1] but decided to go full C instead of rust.

[1] https://github.com/NoFear0411/spliff

CodecProbe asks your device what it can play — then checks if that's true.

Browsers expose three separate APIs for codec support, and they return different answers for the same codec on the same device. One says yes, another says no, a third says yes but not efficiently. Media servers like Jellyfin, Plex, and Emby pick one of these APIs to decide whether to direct-play or transcode — and often pick wrong.

CodecProbe tests 77 codecs (HEVC, AV1, Dolby Vision, VP9) against all three APIs and shows the results side-by-side. When the badges disagree, you've found the gap between what your device reports and what it can actually do.

Each codec card includes education content explaining what a string like hvc1.2.4.L153.B0 actually means, field by field, with spec references.

Zero runtime dependencies, entirely client-side, works offline as a PWA.

The test matrix is validated by codec-resolve [1], a companion Python tool that resolves, decodes, and cross-validates codec strings for 6 video codec families (HEVC, AV1, VP9, AVC/H.264, VP8, Dolby Vision). 180 tests, zero dependencies.

Both projects are AGPL-3.0. Looking for contributors — especially for VVC/H.266, audio codecs (AAC, Opus, DTS, Dolby), and platform-specific quirks on webOS, Tizen, or Roku.

[1] https://github.com/NoFear0411/codec-resolve

Source: https://github.com/NoFear0411/codecprobe

It is nice to see people thinking and working on low level networking stuff that everyone will benefit. I think even single node clusters/container hosts will benefit a lot from XDP loophole. I'll keep an eye on it.

Give it a test and let me know if you encounter any issues. Except the chrome/chromium with static binaries, that have BoringSSL shipped inside. The entire SSL/TLS code flow is a motherfucking spaghetti to provide acceleration and fast page loads. They even offload to system OpenSSL lib for some TLS parts and even with debug symbols (not you google that doesn't include them in repo) it is a headache to trace it

That is a rabbit hole that I don't wanna go down to again.

I think (not 100% sure) Cillium [0][1] kinda already does this. This loophole is good for packet processing/routing and even introducing XDP based ACL to bypass any ip/nf tables and get that almost wire speed benefit. I use Cilium with these features for custom made k8s clusters with Talos OS without any kube-proxy.

[0]https://docs.cilium.io/en/stable/operations/performance/tuni...

[1]https://isovalent.com/blog/post/cilium-netkit-a-new-containe...

I've updated the Architecture diagrams to include everything: https://github.com/NoFear0411/spliff/blob/main/README.md#arc...

Thanks for the format tip.

Here are answers to both your questions:

The code has the infrastructure for XDP hardware offload:

- XDP_MODE_OFFLOAD enum exists in bpf_loader.h:61

- XDP_FLAGS_HW_MODE flag mapping in bpf_loader.c:789

But it's not usable in practice because:

1. No CLI option – There's no way to enable offload mode; it defaults to native with SKB fallback

2. BPF program isn't offload-compatible – The XDP program uses:

- Complex BPF maps (LRU hash, ring buffers)

- Helper functions not supported by most SmartNIC JITs

- The flow_cookie_map shared with sock_ops (can't be offloaded)

3. SmartNIC limitations

– Hardware offload typically only supports simple packet filtering/forwarding, not the stateful flow tracking spliff does

What would be needed for SmartNIC support:

- Split XDP program into offloadable (simple classification) and non-offloadable (stateful) parts

- Use SmartNIC-specific toolchains (Memory-1, Netronome SDK, etc.)

- Me having a device with SmartNIC and full driver support to play with. I've done all my testing on Fedora 43 on my device

For now this could be a future roadmap item, but the current "Golden Thread" correlation architecture fundamentally requires userspace + kernel cooperation that can't be fully offloaded.

Here is a sample debug output when you run spliff -d and it tries to detect all your NICs:

--- [DEBUG] Loaded BPF program from build-release/spliff.bpf.o [XDP] Found program: xdp_flow_tracker [XDP] Found required maps: flow_states, session_registry, xdp_events [XDP] Found optional map: cookie_to_ssl [XDP] Found map: flow_cookie_map (for cookie caching) [XDP] Found optional map: xdp_stats_map [XDP] Initialization complete [XDP] Discovered interface: enp0s20f0u2u4u2 (idx=2, mtu=1500, UP, physical) [XDP] Discovered interface: wlp0s20f3 (idx=4, mtu=1500, UP, physical) [XDP] Discovered interface: enp0s31f6 (idx=3, mtu=1500, UP, physical) libbpf: Kernel error message: Underlying driver does not support XDP in native mode [XDP] native mode failed on enp0s20f0u2u4u2, falling back to SKB mode [XDP] Attached to enp0s20f0u2u4u2 (idx=2) in skb mode libbpf: Kernel error message: Underlying driver does not support XDP in native mode [XDP] native mode failed on wlp0s20f3, falling back to SKB mode [XDP] Attached to wlp0s20f3 (idx=4) in skb mode libbpf: Kernel error message: Underlying driver does not support XDP in native mode [XDP] native mode failed on enp0s31f6, falling back to SKB mode [XDP] Attached to enp0s31f6 (idx=3) in skb mode [XDP] Attached to 3 of 3 discovered interfaces XDP attached to 3 interfaces [SOCKOPS] Using cgroup: /sys/fs/cgroup [SOCKOPS] Attached socket cookie caching program sock_ops attached for cookie caching [XDP] Warm-up: Seeded 5 existing TCP connections [DEBUG] Warmed up 5 existing connections ---

edit: formating is hard on my phone

Hi HN,

I *built Spliff, a high-performance L7 sniffing and correlation engine in pure C23. The goal is to build a fully working, Linux-native EDR that isn't a resource-hogging black box.

The core innovation – "Golden Thread" correlation:

Most eBPF sniffers capture SSL data OR packets. Spliff correlates both:

  XDP (NIC) → sock_ops (socket cookies) → Uprobes (SSL buffers)
      ↓              ↓                         ↓
   packets      TCP 5-tuple              decrypted data
                     ↘         ↓         ↙
                      unified per-flow view

This maps raw decrypted TLS data back to the exact TCP flow, PID, and process—something commercial EDRs struggle with.

Technical highlights:

• XDP + sock_ops + Uprobes – Three BPF program types working together via shared maps

• Lock-free threading – Dispatcher/Worker model with Concurrency Kit SPSC queues

• Full HTTP/2 – HPACK decompression, stream multiplexing, request-response correlation

• No MITM – Hooks OpenSSL, GnuTLS, NSS, WolfSSL, BoringSSL directly via uprobes

• Static binary fingerprinting – Build ID matching for stripped binaries (Chrome)

• BPF-level filtering – AF_UNIX IPC filtered in kernel, not userspace

Current status: Working L7 visibility engine. Captures and correlates HTTPS traffic in real-time.

What's next: Process behavior tracking, file/network anomaly detection, event streaming (NATS/Kafka), threat intel integration.

Linux-only – Requires kernel 5.x+ with BTF, XDP, libbpf.

---

The project is GPL-3.0 and we're inviting anyone interested to contribute—whether it's code, architecture feedback, security research, or ideas for EDR features that actually matter (not compliance theater).

GitHub: https://github.com/NoFear0411/spliff

*Note: The codebase was written with Claude Opus. I provide the research, architecture decisions, and review every line.