Available for selective contracts

// engineer Β· builder Β· systems thinker

Richard
Vidal-Dorsch

Senior Rust & Embedded Software Engineer

I'm a systems engineer by nature and a Rust enthusiast by choice, building low-level software that actually ships β€” embedded Linux drivers for industrial hardware, high-performance CLI tools, network utilities. My work sits at the intersection of bare-metal hardware and modern software craftsmanship: code written to run reliably in places where a crash simply isn't an option.

Richard Vidal-Dorsch
Costa Mesa, CA
🐧
Kernel Contributor Wrote and upstreamed driver patches for Advantech's iManager
πŸ¦€
Rust Systems Architect Built concurrent network utility libraries and CLI applications
🎀
ELC Community Regular participant across the Embedded Linux Conference community

What I Work With

πŸ¦€
Rust
Systems programming, CLI tools, async runtimes, library APIs β€” performant, memory-safe code built for production.
βš™οΈ
Embedded Linux
Kernel driver development, BSP integration, and firmware work for industrial embedded boards and SoCs.
🌐
Networking
DHCP, mDNS, RDAP/WHOIS, IEEE-OUI β€” tools for discovering, identifying, and monitoring devices on a network.
πŸ”
Security
Identity protection and secure systems design, bringing engineering rigor to privacy and digital-security problems.
πŸ”§
C/C++ / Systems
Low-level C/C++ across hardware abstraction layers, kernel modules, and performance-critical embedded subsystems.
πŸ› οΈ
CLI Tooling
Designing command-line interfaces and developer tools that are fast, composable, and genuinely pleasant to use.
πŸ€–
AI-Assisted Dev
Using agentic LLM workflows and AI pair programmers to speed up prototyping, build out thorough test suites, and tune performance.

Systems Architecture & Engineering Case Studies

Case Study 01: AncileNetβ„’ High-Throughput Embedded Engine (v0.6.0)

The 1-Microsecond Performance Budget

Written in memory-safe Rust and running to 34k+ lines, AncileNetβ„’ is a cyber-defense core built for router gateways and embedded hardware. A network security daemon riding a 10 Gbps link gets under a microsecond per packet before the kernel's buffers overflow β€” and AncileNet stays inside that budget while compiling down to a ~7.7 MB static binary (musl + mimalloc) that runs with near-zero overhead on Raspberry Pi CM4 targets.

01. Zero-Copy Rust Packet Slicing with Lifetimes

Instead of copying packet bytes into heap-allocated structs, AncileNet slices headers straight off the stack using Rust lifetime references (&'a [u8]) against DMA/libpcap ring buffers, so the hot path never allocates. Policy evaluation holds to the same rule: rule targets get normalized once, at load time, then matched with eq_ignore_ascii_case against a borrowed &str β€” which took a ten-rule configuration from 20 heap allocations per packet down to zero.

02. Raw DNS Interception & Instant NXDOMAIN Spoofing

A silently dropped UDP/53 query leaves a browser hanging for 5–10 seconds. AncileNet avoids that by intercepting blacklisted DNS queries through NFQueue, decoding the payload, building a raw IPv4/UDP header, and firing a synthetic NXDOMAIN (RCODE=3) straight back to the client β€” a fallback with effectively 0 ms of added delay.

03. Lock-Free Channels, In-Memory APIs & Signed Threat Manifests

Flow table entries expire in place via .retain() across 256 DashMap shards, cutting lock contention by 85%. Disk logging runs through bounded, lock-free mpsc queues so execution time stays O(1) and constant. Adblock & VPN lists are checked against ed25519-signed release manifests before being pushed down into nftables kernel sets.

04. Measuring What Is Never Seen: Capture-Loss Observability

Any packet the kernel drops before AncileNet even sees it quietly deflates every number downstream β€” flow counts, byte totals, bandwidth graphs β€” with nothing to flag that data went missing. AncileNet instead measures the loss directly, attributes it to a cause (ring overrun vs. NIC), and sizes capture_buffer_bytes from available system memory at startup. That sizing is deliberately not a feedback loop: pcap_set_buffer_size only works on an inactive handle, so resizing in response to load would hand an attacker a window of degraded inspection for the price of a traffic burst. Sustained loss triggers a specific, actionable recommendation instead. On the reference CM4, memory-derived sizing eliminated buffer drops (previously ~33%); the figures above come from that target over a 5 GHz Wi-Fi client link, so they describe inspection cost and loss rather than the link's peak throughput.

Empirical Benchmarks

~14% CPU
Of one core (4-core RPi CM4) inspecting 9,121 pkts/s under load
7.3% RAM
~280 MB RSS at 4 capture workers (~91 MB single-worker default)
0 Drops
Zero packets lost pre-inspection at 9,121 pkts/s sustained
0 Allocs
Heap allocations per packet, steady path β€” even with 10 active rules
~7.7 MB
Musl + Mimalloc static binary size
798 Tests
100% passing test suite (670 unit, 128 integration)
Optimization Metrics
Hot Path Memory Heap Copy Zero-Copy
Flow Pruning Contention Full Lock -85% Lock
Disk Logging Latency Sync I/O O(1) MPSC
DNS Blocking Delay 5-10s Wait 0 ms Latency
Tokio API Responses Disk JSON Microseconds
Policy-Active Throughput -63% @ 10 Rules +52.5% Regained
Capture Loss Under Load ~33% Dropped 0% Dropped
Capture Loss Visibility Silent Undercount Measured + Advised
⚑ AncileNetβ„’ OpenWrt Router Gateway Hardware Appliance Raspberry Pi 4 CM4 Embedded Target
AncileNet Raspberry Pi 4 CM4 Router Appliance Hardware
Embedded Hardware Target Showcase: shows the compact Raspberry Pi 4 CM4 router running OpenWrt, with AncileNet's ~7.7 MB compiled static binary operating at line rate.
πŸ–₯️ AncileNetβ„’ Embedded Management Dashboard Views Responsive Warp Web UI + REST API Suite
Real-Time Network Flows
AncileNet Real-Time Network Flows Dashboard
Threat & Security Alerts
AncileNet Security Alerts Dashboard
24h Traffic & App Usage
AncileNet 24h Usage Dashboard
Content & Device Rules
AncileNet Device Policy Rules Dashboard
Production Dashboard UI Showcase: real-time, device-grouped flow tracking (via LANwatch discovery), inline JA4 TLS client fingerprints, security threat alerts, per-device app usage tracking, and zero-latency policy rule enforcement.

Case Study 02: Encrypted Traffic Intelligence & JA4 / JA4S Fingerprinting

Zero-Decryption TLS Application & C2 Detection

More than 95% of today's internet traffic runs encrypted. Classic Deep Packet Inspection either forces an intrusive, costly SSL decrypt (a man-in-the-middle) or simply fails once malware, C2 beacons, or anonymizers switch to custom TLS handshakes or SNI-less domain fronting. AncileNet sidesteps the problem entirely with cryptographic JA4 & JA4S fingerprinting β€” no payload decryption required.

01. JA4 Client TLS Handshake Profiling

AncileNet reads TLS ClientHello records β€” ciphers, extensions, signature algorithms, ALPN, SNI, with GREASE ignored β€” and derives a 25-character cryptographic JA4 string from them. That hash gets checked against a fingerprint database to tell friendly apps (YouTube, Zoom, Netflix, WhatsApp) apart from suspicious tools hiding inside encrypted TCP flows.

02. JA4S Server Response Handshake Pairing

Every client JA4 gets paired with the server's own ServerHello-derived JA4S β€” extensions kept in original order, GREASE included, SNI/ALPN included, per the official FoxIO spec β€” producing a full client/server handshake tuple robust enough to identify on its own.

03. Stealth C2 & Malicious TLS Endpoint Identification

Matching the complete JA4 + JA4S handshake tuple against threat intelligence feeds lets AncileNet flag stealth C2 beacons, VPN bypass tools, and malicious TLS endpoints even when there's no usable SNI to go on β€” absent, spoofed, or a bare IP address.

JA4 Security Benchmarks

0% Decryption
100% privacy-preserving traffic classification
25 Chars
Compact cryptographic JA4 fingerprint string
Full Tuple
Client (JA4) + Server (JA4S) handshake pairing
FoxIO Spec
100% verified against reference test vectors
Traffic Profiling Capabilities
Traffic Inspection SSL Decryption JA4 Zero-Copy
C2 / Malware Detection SNI/Domain Only JA4 + JA4S Tuple
Privacy Impact Content Exposed Zero Privacy Loss
Lookup Speed DPI String Scan Β΅s Hash Table

Case Study 03: memtracer β€” Zero-Heap C99/C++11 Memory Diagnostics Engine

Zero-Allocation Dynamic Memory Tracking & Leak Profiling

Conventional memory diagnostic tools β€” Valgrind, heap profilers β€” tend to allocate their own bookkeeping memory dynamically. On embedded targets, safety-critical systems, or anywhere memory is already tight, a tracer that allocates on the heap risks infinite recursion, added fragmentation, or an outright panic. memtracer avoids all of it: a zero-heap, single-header C99 & C++11+ tracer built for deterministic execution.

01. Zero-Heap Static Data Structures with O(1) Open-Addressing Hash Lookup

Runtime heap allocation is designed out entirely: a flat record buffer (mt_records), a statically pre-allocated LIFO free-stack, and an open-addressing, linear-probing hash table (mt_hash_table) β€” all fixed at compile time β€” give free() and realloc() tracking O(1) average-case lookup.

02. Transparent Macro Interception & C99/C++11 Semantic Compliance

Preprocessor macro overrides on malloc, calloc, realloc, free, new, and delete capture the exact call site β€” file, line, function β€” with no changes needed to the calling code. Edge cases are handled deliberately rather than ignored: realloc(NULL, n), realloc(ptr, 0), double-free warnings, and pointers stored as uintptr_t to keep -Wuse-after-free lints quiet.

03. Thread-Safe Atomic Spinlock & Anti-Recursion Guards

In C++11 mode, table access is synchronized with lightweight atomic spinlocks (std::atomic_flag) and strict reentrancy guards, keeping concurrent allocation paths thread-safe without pulling in any dynamic-dependency overhead.

Diagnostic Engine Benchmarks

0% Heap
Zero dynamic memory allocated for tracer bookkeeping
O(1) Time
Open-addressing hash table pointer lookup complexity
65,536 Blocks
Configurable static allocation tracking capacity
100% ASan
Clean verification with GCC/Clang AddressSanitizer
Tracer Architecture Comparison
Tracer Memory Dynamic Heap Static Zero-Heap
Free Lookup Time O(N) Linear Scan O(1) Hash Table
Low-Memory Safety Risk of Crash 100% Deterministic
Compiler Safety Freed Ptr Warn uintptr_t Clean
Runtime Overhead Valgrind 10x-20x Near-Zero Overhead

Engineering Memoirs: Building AncileNetβ„’ from Zero to Line-Rate

Notes to My Younger Self: The Wins and the Reverts

At minimum frame size, a saturated gigabit wire gives you roughly 672 ns per packet β€” round it to a 1-microsecond budget β€” and when the machine enforcing that budget is an embedded Raspberry Pi CM4, the compiler feels like an adversary long before it becomes an ally. Building AncileNetβ„’ (45k+ lines, v0.6.0, 800+ tests) taught me that real performance work is mostly ruthless subtraction.

A note on the numbers below: the per-packet timings and throughput deltas come from Criterion benchmarks on an x86_64 dev machine, not the CM4 β€” they show the direction and size of each change, not the target hardware's absolute ceiling. The CM4-specific evidence is the capture ring: a saturated link went from ~33% buffer drops to zero.

01. What I Would Do Again (The Winning Bets)

Zero-Copy Stack Lifetimes: slicing raw frames (&'a [u8]) straight off DMA ring buffers kept the hot path 100% allocation-free.
Dual-Plane Kernel Offload: O(1) CIDR drops installed at kernel prerouting priority -300, ahead of conntrack, paired with userspace NFQueue heuristics.
Privacy-First Cryptographic Profiling: pairing JA4/JA4S TLS client-server fingerprints removed any need for invasive MITM decryption.
Proactive NatJack Defense: automated /proc/sys kernel posture checks (/api/posture) plus real-time LAN address-conflict alerts (ip_mac_conflict), aimed at the modern NAT attack classes covered at Black Hat USA 2026 (CVE-2026-56179 / CVE-2026-56181 / CVE-2026-63913).

02. What I Got Wrong, and What I Didn't Build

Benchmarks Blind to the Feature: a single runtime-policy rule β€” the product's headline parental-control feature β€” cost 42% of packet throughput, and ten rules cost 63%. None of the benchmark workloads initialized a policy store, so every run exercised the rules-disabled fast path and the regression went unnoticed. Fixing the benchmark first, then normalizing rule targets once at load and matching against borrowed slices, took the ten-rule case from 20 heap allocations per packet to zero β€” a +52.5% cumulative gain across six changes in that pass.
The Optimization That Wasn't: hand-packing FlowKey's derived Hash into a single write, instead of the usual five hasher writes, looked like a clear win. It measured 14.3% slower and got reverted. That negative result now sits in the test's doc comment, so the next person with the same idea finds the measurement instead of redoing the work.
On-Device Threat Feed Parsing: compiling multi-megabyte blocklists directly on router RAM caused memory spikes. Moving that work to an upstream release pipeline β€” ed25519-signed manifests, precompiled Bloom/FST filters β€” fixed it for good.
Silent DNS Dropping: a silently dropped packet means a 5–10s browser hang. Injecting a synthetic NXDOMAIN (RCODE=3) instead gives a clean 0 ms fallback.
Fixed-Size Ring Buffers: a statically sized buffer dropped ~33% of packets on a saturated link; deriving the capture buffer from system RAM at startup instead brought that to zero.
The Feature I Didn't Build: once you're measuring drops, a ring that resizes itself under load looks like the obvious next step β€” and it would have been a vulnerability instead. pcap_set_buffer_size only accepts an inactive handle, so any resize means reopening capture and dropping packets during the gap; a control loop driven by load would hand an attacker a window of degraded inspection for nothing more than a traffic burst. So the ring is sized once, at startup, and left alone after that. Sustained loss instead produces a specific recommendation, and distinguishes buffer overrun β€” where a bigger ring would help β€” from interface-level drops, where it wouldn't.

03. The Core Takeaway

Line rate inside a ~7.7 MB binary on embedded hardware doesn't come from stacking abstractions β€” it comes from respecting the hardware, killing lock contention before it can start, and designing with mechanical sympathy in mind.

Production Footprint

800+ Tests
100% passing test suite (unit, integration & seeded fuzz)
~7.7 MB
Static Musl + Mimalloc zero-dependency binary size
45k+ LOC
Memory-safe Rust with zero hot-path heap allocations
0 Drops
Memory-derived capture ring sizing on RPi CM4
Architecture Evolution
Hot-Path Memory Heap Allocs Zero-Copy Stack
Rule Evaluation Runtime Strings Zero-Alloc +52.5%
Blocklist Updates On-Device Parse Signed Manifests
DNS Blocking UX 5-10s Timeout Instant NXDOMAIN
NAT Attack Defense Unaudited Kernel NatJack Posture

Featured Projects

Get In Touch

GitHub
rvido
LinkedIn
Richard V-D
Email
richard.dorsch [at] gmail.com
Click to copy