DEV Community: Marcin

JA4 and JA4S fingerprints for QUIC traffic in Wireshark, with a Lua plugin

Marcin — Sat, 11 Jul 2026 20:29:49 +0000

More and more TLS traffic runs over QUIC (HTTP/3), and the classic JA3 fingerprint was never defined for it. Its successor, JA4, handles QUIC explicitly: the fingerprint gets a q prefix instead of t. Wireshark 4.2+ computes JA4 natively, but only the client side — there is no built-in JA4S (server fingerprint). I wrote a Lua plugin that fills that gap: ja4_quic.lua.

What Wireshark already gives you

Since 4.2, the TLS dissector exposes:

tls.handshake.ja3        tls.handshake.ja3s
tls.handshake.ja4        tls.handshake.ja4_r

Because the QUIC dissector hands the ClientHello to the TLS dissector, tls.handshake.ja4 also populates for QUIC Initial packets, with the correct q prefix:

$ tshark -r quic-tls-handshake.pcapng -T fields -e tls.handshake.ja4
q13d0310h3_55b375c5d22e_cd85d2d88918

What's missing from Wireshark's built-in TLS fields is JA4S. JA4 is available under the BSD 3-Clause License, while JA4S is part of the separately licensed JA4+ suite. FoxIO does provide its own JA4+ Wireshark plugin, but JA4S is not implemented by Wireshark's core TLS dissector.

The plugin

ja4_quic.lua is a postdissector that:

reads JA4 from the built-in field (no point recomputing it — GREASE handling and the QUIC detection are already done),
computes JA4S from the ServerHello,
tracks sessions by quic.connection.number (which survives QUIC connection migration) or tcp.stream,
adds filterable fields: ja4_quic.ja4, ja4_quic.ja4s, ja4_quic.ja4s_r, ja4_quic.sni, ja4_quic.alpn,
exports everything to CSV via Tools → Export JA4 Analysis.

JA4S in one minute

q 13 02 00 _ 1301 _ 234ea6891581
| |  |  |    |      |
| |  |  |    |      truncated SHA-256 of the extension list, in order
| |  |  |    cipher suite chosen by the server
| |  |  ALPN chosen ("00" if none visible)
| |  number of extensions
| TLS version (from supported_versions if present)
q = QUIC, t = TCP

One caveat worth knowing: in TLS 1.3 (and therefore in QUIC) the server sends its ALPN choice inside EncryptedExtensions, which is encrypted. Without TLS decryption secrets, a passive analyzer cannot recover that value, so the ALPN part is 00. This is a property of passive TLS 1.3 analysis rather than a limitation specific to the plugin.

Implementation notes

Wireshark doesn't expose a cryptographic hashing API to Lua, so the plugin carries its own SHA-256 implementation. It requires Wireshark 4.4 or newer, which ships with Lua 5.4 and its native bitwise operators. One important detail is that Lua integers are 64-bit, so every 32-bit rotation needs masking:

local function rotr32(x, n)
    return ((x >> n) | (x << (32 - n))) & 0xffffffff
end

The hash self-tests against a known vector at load time — a silently broken hash producing plausible-looking fingerprints would be worse than a crash.

Another Wireshark-specific gotcha: a postdissector runs again every time the GUI re-dissects a packet (clicking it in the packet list), so byte counters must only accumulate when pinfo.visited is false.

Verification

I compared the output against the FoxIO reference implementation (python/ja4.py from their repo) on their own sample pcaps. Every JA4S the reference emitted matches the plugin:

pcap	plugin	FoxIO reference
`latest.pcapng`	`t1206h2_c02f_3603f09c43ba`	`t1206h2_c02f_3603f09c43ba`
`latest.pcapng`	`t130300_1301_6bbbaf601ed8`	`t130300_1301_6bbbaf601ed8`
`chrome-cloudflare-quic` (TCP stream)	`t130200_1301_234ea6891581`	`t130200_1301_234ea6891581`

The reference script didn't emit a JA4S for the QUIC stream in that last capture, so the TCP row is the directly comparable one. On the QUIC side, JA4 matches Wireshark's built-in implementation, and the plugin's QUIC JA4S (q130200_1301_234ea6891581) differs from the verified TCP fingerprint only by the q prefix — expected, since it's the same server configuration.

Usage

Install Wireshark 4.4 or newer. The plugin uses Lua 5.4 syntax and will not load in Wireshark 4.2, even though that version already exposes the built-in JA4 fields.

Drop the file into your personal Lua plugins directory (About Wireshark → Folders → Personal Lua Plugins, e.g. ~/.local/lib/wireshark/plugins/), reload with Ctrl+Shift+L, and filter away:

ja4_quic.ja4s == "q130200_1301_234ea6891581"
ja4_quic.sni contains "example.com"

Licensing

JA4 (the client fingerprint) is available under the BSD 3-Clause License. JA4S and the rest of the JA4+ suite are specified by FoxIO and covered by the FoxIO License 1.1.

That license permits personal and academic use, as well as internal business use that does not directly monetize JA4+. Direct or indirect monetization — including incorporating JA4S into a paid product, hosted service, managed service, or other offering that provides value to paying customers — requires a separate license from FoxIO. The plugin follows the FoxIO specification and reference implementation and is published for non-commercial personal, academic and internal analysis. Review the full license before redistributing the plugin or using it in a commercial context.

A self-hosted web UI for managing and running Ansible - Playforge

Marcin — Tue, 07 Jul 2026 18:07:39 +0000

A self-hosted web UI for managing and running Ansible — a simpler, friendlier AWX
that runs from a single docker compose up, with no Postgres, Redis or Receptor. - Playforge

What makes it different is the AI layer that checks its own output. Most tools
either don't have AI or trust it blindly. Playforge generates playbooks from plain
language, then verifies them: it flags modules that don't exist, catches logic
mistakes a model misses (SSH/UFW lockout, destructive ops, malformed vars), and
grounds every answer in your real modules and files — fully offline.

Features

Projects & runs

Import an existing Ansible project from a local path, a .zip, or git clone (Gitea/GitHub) — junk like .venv/ and caches is filtered out automatically.
Every project is its own git repo with an auto-commit on each save: free undo, diff and history. Push/pull to a remote when you want.
Run playbooks (full or by tags) with live per-task output, a structured pass/fail summary, and a global, filterable run history.
Auto-detects playbooks/inventories/roles; works with both the scaffolded layout and flat repos (playbook + hosts.ini at the root).
Cron scheduler in-process (APScheduler — no extra worker), run templates, environments, ad-hoc commands.

Secrets

Credentials (SSH keys, SSH passwords, vault/become passwords, WireGuard) encrypted at rest with Fernet.
Ansible Vault for in-repo secrets — encrypt/decrypt/view from the UI.

Editor & dependencies

Monaco editor with inline ansible-lint, per-file commit history (View / Restore past versions), structured inventory editing (INI + YAML).
Playbook builder (simple → advanced: handlers, loops, serial, become per task).
Ansible Galaxy: install/remove roles & collections by name or from requirements.yml.

Operations

Credential test — probe an SSH key, SSH password, or sudo password against an inventory before running a 30-task playbook; per-host ✓/✗ result.
Ad-hoc command builder — any module + args + host pattern in one form (not just "ping all").
--limit quick-pick — click groups/hosts from the inventory to build the Ansible :-separated limit string.
Run artifacts — files a run wrote into the repo are committed automatically; the run-detail page previews them inline or opens them in the editor.
Per-schedule timezone — cron expressions interpret in any IANA timezone (Europe/Warsaw, America/New_York, …); next-fire times honour DST.

✨ AI assistant (the part that's actually unique)

Chat on every page (slide-out dock) and a full page — one shared conversation, live-synced and remembered across refreshes. Replies stream in token-by-token.
Agent mode: a tool-using agent that actually works on a project — it inspects files, writes/edits/moves them, installs collections, and can dry-run (--check) or run a playbook, then read the failures and fix them. It uses the self-checking layers below (it won't finish on a hallucinated module), every change is a separate git commit you can revert, and each capability is opt-in (read-only → "allow changes" → "allow delete / web").
NL → playbook: describe what you want, get a reviewable spec + YAML.
Remediation loop: after a failure, get a concrete fix and re-run only the failed hosts — or one-click Fix with agent to have the agent read the run, patch the playbook, and preview it.
Pre-run preview: a --check dry-run narrated in plain language ("what will change, where").
Auto-runbook: living Markdown docs generated from your playbooks.
Self-checking layers behind all of it:
- Anti-hallucination — module names validated against ansible-doc (ansible.builtin.ufw → flagged as fake; community.general.ufw → "install the collection", not "doesn't exist").
- Rule engine (neuro-symbolic) — catches lockout, destructive ops, contradictions, handler misuse, malformed structure, even inside roles.
- RAG / BM25 — grounds answers in the modules actually installed and in your project's real file contents. Works offline; optional web-fetch from docs.ansible.com when you allow it.

Pluggable model backends: Anthropic, OpenAI (or any OpenAI-compatible endpoint),
or a local Ollama server.

Screenshots

Quick start

git clone https://github.com/mar0ls/playforge.git
cd playforge
cp .env.example .env   # optional — for a password, AI keys, etc.
docker compose up --build -d   # → http://127.0.0.1:8765

The .env step is optional: with no .env the app runs single-user/local with no
AI. Configure the AI helper under Settings → AI helper at runtime, or set
OLLAMA_URL / ANTHROPIC_API_KEY / OPENAI_API_KEY in .env. State (projects,
git repos, SQLite) lives under ./data on the host and survives rebuilds.

Optional

Password protection: set ANSIBLE_GUI_PASSWORD to require login (signed session cookie). Unset = single-user local, no login.
Import your projects: bind-mount their directories read-only (see the commented /import/* examples in docker-compose.yml).
Naming note: the image and container are playforge; environment variables keep the ANSIBLE_GUI_* prefix for backward compatibility.

Try the self-checking loop

See it end to end without a remote host:

scripts/demo.sh   # creates a project + a deliberately failing run on localhost

It prints a run URL — open it and click Fix with agent: the agent reads the
failure, fixes the playbook (a typo'd module), and previews it. Then Re-run to
confirm. (To record a GIF, screen-capture the browser during that step.)

Development

make build      # build the image
make test       # run the full suite inside the image (git + ansible available)
make up / down  # start / stop

For live code reload while developing, layer the dev override (bind-mounts
backend/app and runs uvicorn with --reload):

docker compose -f docker-compose.yml -f docker-compose.dev.yml up --build

The container exposes GET /health (DB ping included). The base compose wires
a Docker healthcheck against it, so docker ps shows (healthy) once the
service is up.

Lab regression (one command)

Run a full API-level regression for a dockerized VM lab (preflight + multiple
playbook runs + JSON report suitable for CI):

PROJECT_ID=<your_project_id> make lab-regression

Optional knobs:

PROJECT_ID=<id> \
BASE_URL=http://127.0.0.1:8765 \
INVENTORY_PATH=inventories/lab.ini \
HOST_PATTERN=all \
CHECK_PREFLIGHT=true \
INCLUDE_TARGETS_PREFLIGHT=true \
REQUEST_TIMEOUT_SEC=600 \
PLAYBOOKS_CSV=playbooks/lab_ping.yml,playbooks/lab_file.yml,playbooks/lab_apt.yml \
EXTRA_VARS_JSON='{"some_var":"value"}' \
make lab-regression

The command exits non-zero when preflight fails or any run is not ok/
successful.

The test suite (370+ cases) runs in CI on every push and PR — see
.github/workflows/ci.yml.

Design notes

Air-gap friendly: core UI JS libraries are vendored locally and AI can run against a local Ollama. By default, online docs lookup is off. Note: the Monaco editor assets are loaded from jsDelivr unless you vendor Monaco yourself.
No heavy infra: SQLite (WAL mode), in-process scheduler, direct runner. One container.
Third-party components are listed in THIRD_PARTY_LICENSES.md.

License

Copyright (C) 2026 mar0ls. Playforge is licensed under the GNU General Public
License v3.0 — see LICENSE. GPL-3.0 keeps the project compatible with
its core dependencies (ansible-core, ansible-runner, ansible-lint), which are
GPL-3.0 themselves. Forks and redistributed versions must stay open-source under
the same license.

Building agentless Linux threat detection in Go — no agents, no kernel modules, just SSH

Marcin — Fri, 03 Jul 2026 10:27:49 +0000

Most host-based detection tools require something running on every host: an agent, a kernel module, an eBPF program loaded at boot. That's fine when you control the fleet. It's less fine when you're dealing with a mix of distros, customer VMs, legacy systems where "please install our agent" gets stuck in a change window for six weeks.

I wanted something that works over SSH on a host you've never touched before — no install, no persistent process, no kernel dependency. Run a scan, get findings, nothing running between scans.

That's bladedr. This post explains how it works.

How the probe works

The core idea: SSH to the target, stage a static binary, run it, collect results.

The binary (bladedr-probe) is a single static Go executable compiled with CGO_ENABLED=0. It runs on the target for a few seconds, reads from /proc, /sys, /etc and a handful of other paths, builds a JSON snapshot of the host state, evaluates detection rules against it, and returns the findings on stdout. Nothing stays resident.

The snapshot covers:

running processes (cmdline, environ, exe, cwd, parent chain, deleted/memfd-backed executables)
listening sockets and raw (AF_PACKET) socket holders
kernel modules, /proc/kallsyms, dmesg ring buffer
persistence: cron, systemd units, authorized_keys, ld.so.preload, PAM modules, XDG autostart, binfmt_misc, udev rules, Python .pth files
accounts (uid/gid, shell, groups)
suspicious files: world-writable sensitive paths, SUID/SGID in unexpected places, deleted-but-running binaries, memfd mappings
kernel parameters (sysctl), SELinux state, immutable files

The probe is read-only. It doesn't start a daemon and it doesn't modify host state. The one thing it writes is itself: the binary is content-addressed (sha256) and cached at /tmp/.bladedr/probe-<hash>, so repeated scheduled scans skip the multi-MB re-upload. The small per-scan rule bundle is written next to it and deleted when the scan finishes. So there's no agent, no service, no process running between scans — just a cached binary sitting idle until the next SSH session invokes it. If you want it gone, it's one rm -rf /tmp/.bladedr.

Rules: YAML + CEL, not code

Detection logic is data, not compiled code. A rule looks like this (this one is a real builtin — global-ld-preload):

id: global-ld-preload
title: "LD_PRELOAD/LD_AUDIT / writable LD_LIBRARY_PATH in a global environment file"
category: evasion
severity: critical
score: 90
mitre: ["T1574.006"]
foreach: env_preload
when: 'item.suspicious_lines.size() > 0'
evidence:
  path: item.path
  lines: item.suspicious_lines
dedup: ["item.path"]

foreach walks a collection from the snapshot. when is a CEL expression evaluated against each item. CEL is a safe, deterministic expression language — no arbitrary code execution, fast evaluation, easy to audit. (Rules without a collection just run one when against the whole snapshot — e.g. the ld-so-preload-rootkit rule that fires on any entry in /etc/ld.so.preload.)

Rules ship embedded in the binary (internal/rules/builtin/), but the server merges three layers: builtin → filesystem dir (BLADEDR_RULES_DIR) → database. A later rule with the same id overrides the earlier one, so you can patch a builtin without recompiling, or disable it with enabled: false.

# live rule injection via API, active on the next scan
curl -X POST :8080/api/v1/rules --data-binary '
id: watch-loader
title: "Process named loader"
category: process
severity: medium
foreach: processes
when: item.comm == "loader"
evidence: { pid: item.pid, comm: item.comm }'

Currently 87 builtin rules covering MITRE ATT&CK techniques: rootkits, persistence, privilege escalation, evasion, webshells, supply-chain tampering, eBPF backdoors, and more.

The server

bladedr-server handles inventory, scheduling, the API, and the web console. It runs anywhere — Linux, macOS, Docker. Scan targets are always Linux.

Storage is in-memory by default (good for dev and demos), or Postgres with pg_search (BM25 full-text search over findings, useful when you have a few thousand observations and want to curl ':8080/api/v1/observations?q=rootkit').

The server keeps a per-host baseline. First scan establishes it. Later scans diff against it and raise baseline-new-* observations for anything new: a new UID-0 account, a new listening port, a new authorized key. You don't have to define what "normal" looks like — it learns from the first clean scan.

Fleet-rarity works similarly: if a kernel module or a cron entry appears on one host out of fifty, that's a low-severity lead regardless of whether any specific rule fires. Rarity is scoped to a host cohort (same OS), so a lone box doesn't generate rarity noise against unrelated hosts.

ML risk scoring — what it does and what it doesn't

With enough hosts, you end up with a lot of medium-severity findings. Some are real, most are noise. The risk model re-ranks open findings by how likely you are to triage them as real.

It's a multinomial Naive Bayes classifier (Laplace-smoothed) trained on your own triage decisions: acknowledged = real finding, false_positive = noise. It uses structural features only:

rule:global-ld-preload
cat:evasion
sev:critical
src:agentless_probe
tech:T1574.006
tac:T1574
path:etc

No attacker-controlled strings, no process names, no paths. It learns that certain rule/category/severity/technique combinations correlate with real compromises on your fleet, not on someone else's.

The model is honest about its own reliability. GET /api/v1/risk/stats runs leave-one-out cross-validation and reports whether the labelled set is big enough, balanced enough, and separable enough to trust:

{
  "trustworthy": true,
  "labeled": 211,
  "positives": 162,
  "negatives": 49,
  "cv_accuracy": 0.88,
  "base_rate": 0.77,
  "reason": "enough balanced, separable data to prioritise findings"
}

Until both classes exist (you need at least one acknowledged and one false_positive triage), scoring falls back to the rule's static score. A clean fleet produces no positives to label, so there's an attack-emulation range (poligon/) that plants known technique artifacts in a container, scans them, and writes labelled training data to dataset.jsonl.

It ranks. It does not detect.

eBPF tier (Phase 2)

Agentless scanning sees the artifact at rest — a file, a config entry, an account. It misses runtime-only techniques: fileless execution, a reverse shell that runs and exits, a container escape that leaves no trace.

The eBPF tier fills that gap. bladedr-sensor wraps Tetragon: it loads TracingPolicies (kprobes/tracepoints), consumes Tetragon's JSON event stream, maps each hit to an observation, and posts them to the server. Same observations table, same triage flow, same risk model — just source=ebpf_sensor instead of source=agentless_probe.

Tetragon runs as a privileged container. The sensor deploys over SSH and runs as a systemd unit. A host is either scan_only or scan_plus_sensor.

Running it

git clone https://github.com/mar0ls/bladedr
cd bladedr
make build               # server + probe for your platform
make build-probe-linux   # cross-compile static probe for Linux targets
make demo                # scan a bundled malicious snapshot, no Linux host needed

For SSH scanning against a real host:

# start server with Postgres
docker compose up -d
./bin/bladedr-server

# add a host, store credentials, scan
curl -X POST :8080/api/v1/hosts \
  -d '{"hostname":"web-01","primary_ip":"10.0.0.5","arch":"amd64"}'
curl -X POST :8080/api/v1/credentials \
  -d '{"username":"root","auth_type":"ssh_password","secret":"…"}'
curl -X POST :8080/api/v1/hosts/<id>/scans

bladedr is at v0.1.0 — the agentless tier is stable, the eBPF sensor works but Phase 2 rules are still thin. If you run it against a compromised or test host, I'd be curious what fires and what doesn't.

Rule contributions and issue reports welcome.

GPL-3. Code at [github.com/mar0ls/bladedr]