DEV Community: Zayd Mulani

I built a local-first coverage-guided fuzzer in Rust with LLM seed bootstrap

Zayd Mulani — Tue, 14 Jul 2026 13:27:34 +0000

I built a local-first coverage-guided fuzzer in Rust with LLM seed bootstrap

rust #opensource #security #fuzzing

The problem that kept bothering me: I wanted to fuzz a custom binary protocol parser. Not something with a public corpus of real traffic. Just a service my team built that speaks a length-prefixed binary format over TCP.

AFL++ requires a C harness. cargo-fuzz wraps libFuzzer but you still need to write the harness and you're starting from random bytes. Neither tool helps you when the first thing the parser does is check a 4-byte magic header and exit if it doesn't match. You spend hours getting past that check before you find anything real.

So I built Phaedra.

The LLM seeding idea

The core insight is that you don't need random bytes to start. You need bytes that look plausible. If you describe what your target parses in plain English, a language model can generate a structured initial corpus.

phaedra fuzz \
  --target ./my_parser \
  --description "TLV binary protocol with PHDR magic header, u8 type, u16be length, payload bytes"

Phaedra sends that description to a local Ollama instance and gets back hex-encoded seed inputs. No API key, no data leaving your machine. OpenAI and Anthropic work as drop-in backends if you want them.

The seed generation prompt asks for variety: valid inputs, boundary values, truncated records, inputs where the length field exceeds the payload. The parser gets past the magic check immediately because the seeds include valid magic bytes. Campaign starts finding new coverage on the first execution instead of the hundredth.

Coverage via SanCov edge bitmaps

Once you have seeds, you need coverage feedback. I chose SanCov edge bitmaps over shared memory rather than LLVM .profraw files for one reason: speed. Reading a profraw file after each execution means a file write, a file read, and a parse. Shared memory is a single shmat call and a memcpy.

The setup: Phaedra allocates a 65536-slot edge bitmap in POSIX shared memory, passes the segment ID to the target via __PHAEDRA_SHM_ID, and the target's SanCov runtime shim writes edge hit counts directly into that segment on every execution. After the process exits, Phaedra reads the bitmap, XORs against the global "seen" bitmap, and if new edges fired, the input goes into the corpus.

The shim is a small C file that gets compiled into the target:

void __sanitizer_cov_trace_pc_guard(uint32_t *guard) {
    if (!*guard || !phaedra_map) return;
    phaedra_map[(*guard - 1) % PHAEDRA_MAP_SIZE]++;
}

Schema-aware mutation

Random byte mutation gets past the magic check once you have good seeds. But it still struggles with structured fields. If your protocol has a u16be length prefix followed by exactly that many payload bytes, random mutation almost never produces a valid record because it corrupts the length without adjusting the payload.

The schema DSL solves this. You describe your protocol in TOML:

name = "my_protocol"

[[fields]]
name = "magic"
type = "magic"
length = 4
value = "50484452"
mutable = false

[[fields]]
name = "length"
type = "u16_be"

[[fields]]
name = "payload"
type = "lp_bytes16_be"

30% of mutations operate at the field level: corrupting the length prefix specifically, setting it to 0, to max value, or to a value larger than the actual payload. The other 70% are still raw byte mutations. The split keeps the campaign from getting stuck in schema-valid inputs only.

If you have a corpus but no schema, phaedra infer analyzes the samples with six heuristics and writes a starting schema:

phaedra infer --corpus-db ./phaedra-corpus/corpus.db --name my_proto

Crash triage

When Phaedra finds a crash it deduplicates by signal number and input fingerprint. SIGSEGV and SIGABRT are CRITICAL. SIGILL and SIGFPE are HIGH. No-signal crashes are LOW. Each unique signature gets one entry in SQLite with a hit counter so if the same bug triggers 500 times you see one entry with hit_count=500, not 500 files in your crash directory.

phaedra crashes

ID  SEVERITY   HITS  SIGNATURE     STATUS
1   LOW        47    crash_3f2a1b  Crash { signal: None }
2   LOW        12    crash_7e4d2c  Crash { signal: None }

phaedra minimize runs delta minimization to reduce a crashing input to the smallest bytes that still trigger it. Found a 200-byte crash? It will usually get it down to under 10.

Try it

cargo install phaedra
phaedra fuzz --demo tlv

The TLV demo target has a real bounds-check bug. Phaedra finds it within the first few seconds.

GitHub: https://github.com/zaydmulani09/phaedra

I built a local token cost tracker for Claude Code in Rust

Zayd Mulani — Mon, 13 Jul 2026 21:58:53 +0000

After one too many surprise Claude Code bills, I built agentwatch.
It's a local HTTP proxy written in Rust. Point your agent at localhost:7878, and it intercepts every request, parses the token usage, and shows a live Ratatui TUI dashboard of what you're spending — in real time.
Everything stays local. SQLite database, zero signup, single binary via cargo install agentwatch.
Supports Claude Code, Codex, and Gemini CLI.
github.com/zaydmulani09/agentwatch

I built a self-hosted reverse proxy for MCP servers in Rust

Zayd Mulani — Thu, 02 Jul 2026 18:52:40 +0000

The problem

Every AI tool that talks to MCP servers (Claude, Cursor, etc.)
connects directly — no auth, no rate limiting, no observability.
You have no idea what's hitting your servers or how often.

What I built

MCP Gateway sits in front of all your MCP servers and handles:

Routing — /mcp/server-name/* proxies to the right backend
Auth — per-server API keys encrypted AES-256-GCM in memory
Rate limiting — token bucket per client, 429 + Retry-After
Logging — SQLite log of every request with latency + status
Usage tracking — token counts from Anthropic/OpenAI responses
CLI — mcpgw server add/list/remove, mcpgw logs show, mcpgw stats

Quickstart

MCPGW_MASTER_SECRET=your-secret docker compose up --build

Stack

Rust, Axum, SQLite (rusqlite), DashMap, AES-GCM

GitHub: https://github.com/zaydmulani09/mcp-gateway

I built a local-first AI memory layer for LLMs in Rust (no cloud, no API keys)

Zayd Mulani — Wed, 03 Jun 2026 20:33:22 +0000

Every LLM app has the same problem — the model forgets everything between
conversations. Cloud solutions like Mem0 exist but they send your data
to their servers. I built mnemo to solve this locally.

What it does

mnemo runs as a sidecar process next to your app. You POST text to it,
it extracts named entities and relationships using a local LLM (Ollama),
builds a persistent knowledge graph, and injects relevant context back
into your prompts automatically.

The stack

Rust — core engine, 4 crates (mnemo-core, mnemo-api, mnemo-cli, mnemo-bench)
SQLite + WAL mode — persistent storage, survives restarts
petgraph — in-memory knowledge graph with BFS traversal
Axum — REST API sidecar any app can call
Ollama — fully local LLM, zero API costs

Fully free by default

docker compose up -d
docker exec mnemo-ollama ollama pull llama3
curl http://localhost:8080/health

Works with OpenAI or Anthropic too if you bring your own key.

Python SDK

from mnemo import MnemoClient

client = MnemoClient()
client.ingest("I'm building a Rust vector database called vecdb")
print(client.get_context("what am I working on?"))

Numbers

122 Rust tests, 21 Python SDK tests
Sub-millisecond entity lookup
~4ms full retrieval pipeline (debug build)

Links

GitHub: https://github.com/zaydmulani09/mnemo

Would love feedback, especially on the retrieval scoring and graph
traversal approach.

I built an open-source dependency intelligence platform in TypeScript — here's how it works

Zayd Mulani — Fri, 29 May 2026 12:13:27 +0000

Most teams find out their dependencies are risky after something breaks. A maintainer disappears, a vulnerability sits unpatched for months, or a single package with one contributor becomes a hidden outage waiting to happen. I wanted a tool that told you this stuff before it became a problem.
So I built depgraph — an open-source dependency intelligence platform that crawls npm, PyPI, and Cargo registries, builds a live risk-scored dependency graph, and tells you exactly which packages in your supply chain are about to cause you pain.
What it does
Risk scoring across 6 dimensions
Every package gets scored on security (open advisories, CVSS scores), maintenance (commit recency, release cadence), compatibility (semver violation rate), concentration (bus factor, single-maintainer risk), blast radius (how many downstream packages break if this one changes), and operational health (issue response latency, PR merge time).
These combine into a single composite score with full explanations — not just a number, but "35% because maintainer activity fell 80% in 120 days."
Interactive dependency graph
Built with Cytoscape.js. Click any package to see its full transitive dependency tree, blast radius stats, and which packages it would take down if it disappeared. Chokepoint detection highlights the packages that are structurally too central to ignore.
Policy engine with CI gate
Define rules like "block packages with one maintainer and no release in 180 days" or "require approval for anything with 500+ downstream dependents." A GitHub Action runs the policy check on every PR and fails the build on violations — with a formatted comment showing exactly what triggered and how to fix it.
Abandonment detection
Time-series signals track commit frequency trends, maintainer count decay, and bus factor over time. A weighted model produces an abandonment probability score per package so you can see which ones are quietly dying before they become your problem.
Historical snapshot diffs
Every scan creates a full risk snapshot. Compare any two snapshots to see which packages degraded, which improved, what new vulnerability chains appeared, and how your overall supply chain health changed over time.
Tech stack
TypeScript monorepo with pnpm workspaces. Hono API, React + Vite frontend, PostgreSQL + Drizzle ORM, BullMQ workers, MinIO for raw storage. Fully self-hostable — one docker compose up and you're running. Zero paid services required.
Supports npm, PyPI, and Cargo with a shared normalization layer that maps all three ecosystems to a canonical data model.
Running it locally
bashgit clone https://github.com/zaydmulani09/depgraph
cd depgraph
pnpm install --ignore-scripts
cp .env.example .env
docker compose up -d
pnpm db:migrate
pnpm --filter @depgraph/api dev &
pnpm --filter @depgraph/crawler dev &
pnpm --filter @depgraph/ui dev
Open localhost:5173. The crawler seeds 10 packages immediately and starts processing — within a few minutes you'll see risk scores, graphs, and explanations populating in the UI.
What I learned building this
The hardest part wasn't the risk scoring or the UI — it was maintaining a living graph. Getting data once is easy. Keeping it fresh, detecting drift, diffing snapshots, and making all of that fast enough to be useful is where the real complexity lives.
The second hardest part was normalization. npm, PyPI, and Cargo all have wildly different versioning semantics, dependency specifier formats, and registry API shapes. Building a canonical model that works cleanly across all three took longer than any other single component.

Check it out, open issues, and PRs are welcome.
GitHub: https://github.com/zaydmulani09/depgraph

I built a local-first hybrid vector database in Rust from scratch

Zayd Mulani — Tue, 19 May 2026 01:29:22 +0000

A few months ago I started building vecdb — a vector database that
runs entirely on your own machine. No cloud, no API keys, no subscription.

The problem

Most vector databases make you choose — semantic search OR keyword search.
Semantic search finds meaning but misses exact keywords. Keyword search
finds exact matches but misses meaning.

vecdb combines both in a two-stage pipeline:

HNSW dense index retrieves candidates by meaning
BM25 sparse index re-scores by keyword relevance
A fusion function combines both scores

What it can do

Hybrid HNSW + BM25 retrieval
SQL-like query language with VECTOR_SIM predicate
Python and TypeScript SDKs
Single binary, Docker support
187 tests
MIT license

Example query

SELECT * FROM documents
WHERE VECTOR_SIM(vec, [0.1, 0.2, 0.3]) > 0.75
AND payload->>'region' = 'US'
LIMIT 10;

Try it

GitHub: https://github.com/zaydmulani09/vecdb

Would love feedback from the community — especially on the
architecture and what to tackle in v0.2.0.