The workbench.

Suijin is a dual-mode autonomous security platform. The Red Team chains reconnaissance → vulnerability discovery → exploitation → escalation → flag capture → reporting over a LangGraph state machine, while the Blue Team monitors live HTTP traffic, detects attacks, and responds with deception, blocking, and source patching. Both modes share one toolkit, one knowledge base, and one knowledge graph. Intended for authorized security testing, education, and research only.

The Red Team

A LangGraph-driven pipeline runs recon, vuln discovery, exploit, escalation, flag capture, and report generation autonomously. It spawns parallel subagents (up to 3 concurrent) for multi-vector attacks, coordinated by a zero-cost LLM supervisor that watches for loops, missed flags, and stalled progress every 5 iterations — no API cost. A persistent knowledge graph is shared across all agents, and every engagement produces Markdown reports with Mermaid attack-chain diagrams. A live command box during runs supports /state, /note, /kb, /cost, /approvals, /scope, /audit, /sessions, /report, /pause, and /panic.

The Blue Team SOC

Live traffic flows through 18 regex-based attack pattern detectors — SQLi, XSS, SSRF, CMDi, XXE, JWT, SSTI, deserialization, LDAP, NoSQL, scanner user-agents, mass assignment, auth bypass, brute force, file inclusion, and GraphQL. Per-endpoint AI subagents analyze handler code in real time. When an attack is detected, the decision engine deploys layered responses: tarpit (real, measurable delays — 0.018s normal to 8.0s at threat score 10), network blocking via pfctl/iptables, source code patching directly on the filesystem, and honeypots (decoy admin users, canary API keys, phantom debug tokens). The first 25 requests build baseline profiles before the AI activates.

Built-in labs

Eight deliberately vulnerable Flask apps ship in the box, so nobody learns on real targets:

• cloud_iam_lab (:5900) — AWS IAM misconfigurations
• api_only_lab (:5901) — REST + GraphQL, BOLA, mass assignment
• oauth_lab (:5902) — OAuth 2.0 / OIDC misconfigurations
• log4shell_lab (:5903) — Log4j RCE
• wordpress_lab (:5904) — WordPress + vulnerable plugins
• ad_lab (:5905) — simulated AD DC, Kerberos, LDAP, SMB
• blue_target (:5906) — 25 endpoints, 15+ vuln classes
• devops_dashboard (:5700) — hard RCE, multi-step chain required

A modular security OS

Suijin is rebuilt as a modular operating system for security automation: a kernel of 12 stdlib-only subsystems (contracts, context, events, registry, controller, jobs, vfs, security, config, health, journal, errors), a Core tier that cannot be disabled, a Recommended tier of disableable modules, and an Installed tier of community modules discovered on every boot. Modules are one folder — plugin.json plus register(ctx), start(ctx), stop(ctx) — managed through a Textual TUI.

Extensibility in four rungs

• Skill — drop a markdown file, it boots into the agent's prompt. 30 seconds.
• Addon — plain functions, auto-registered as agent tools. 2 minutes.
• Pack — scaffolded tools + skill doc + kernel unit. 5 minutes.
• Module — full lifecycle with dependencies, versioning, overrides.

The offline knowledge base

suijin pull kb downloads and indexes HackTricks, GTFOBins, PayloadsAllTheThings, LOLBAS, OWASP Cheat Sheets, and SecLists (~300 MB) into a local sqlite3 store with FTS5 and BM25-ranked search. KB-powered tools — suggest_exploit, find_wordlist, extract_payloads, kb_stats, mine_failures, anonymize_report — all work offline, with no API key.

Governance & ops

A policy engine blocks dangerous patterns before the agent hits enter, scope controls enforce Burp-style target boundaries, and HITL approvals gate destructive actions. Credentials live in a PBKDF2-HMAC-SHA256 encrypted vault, provider failover rolls to the next LLM provider on hard failure, and cost guardrails enforce alert, budget, and hard-cap limits in USD.

BreachBench is a production-grade benchmark for evaluating LLM offensive security capabilities. Unlike existing benchmarks such as CyberSecEval, WMDP, and PurpleLlama — which test rote memorization of CVEs and port numbers — BreachBench measures whether a model can actually execute attacks. It is the only benchmark that tests the full kill chain, with real tools, against real targets.

Four-stage pipeline

• CONTROL (50 questions) — baseline competency: does the model understand security concepts?
• RECALL (50 questions) — breadth of knowledge: does it know obscure CVEs and edge cases?
• REASONING (50 questions) — multi-step attack chain reasoning: can it chain steps in order?
• LAB (100 questions) — the critical test: live exploitation against five deliberately vulnerable applications with full professional UIs.

Five live labs

The five labs — VaultStack (secrets management, 18 vulns), NetPulse (network monitoring, 16 vulns), MedChain (healthcare EHR, 16 vulns), DevOpsForge (CI/CD platform, 17 vulns), and FinClear (financial clearing, 17 vulns) — each contain a flag.txt file accessible via exploitation. The model must read the app, identify a vulnerability, craft an exploit, execute it, and capture the flag. No amount of memorization helps when facing a live GraphQL injection on CloudBoard at port 5800.

Measurement that matters

BreachBench tracks token cost (per-provider pricing tables with real-time USD estimation), latency percentiles (p50/p95/p99 per stage), and MITRE ATT&CK framework alignment (80+ tactic mappings). It generates confusion matrices per topic, identifying exactly where a model excels and where it struggles. The persistent leaderboard tracks model improvement over time and compares providers side-by-side on cost-efficiency — because a model scoring 85% at $0.03 per run is often more valuable than one scoring 88% at $3.00.

Reproducibility by design

With 836 hand-crafted questions across 29 topics and 8 difficulty tiers, 11 providers supported natively (plus any OpenAI-compatible API via the custom provider), Docker support for isolated lab execution, and a professional web dashboard at :5100, BreachBench targets security researchers, red teams, AI safety teams, model providers, and DevSecOps teams integrating it into CI/CD pipelines. Dry-run mode validates the full pipeline without API calls, while fixed seeds, deterministic sampling, checkpoint/resume, and multi-format exports (JSON + CSV + HTML) ensure reproducibility for academic publication and regression testing.

dd-rs is a Rust+C reimplementation of the Unix dd command — the standard tool for copying and converting data that has been destroying databases and SSDs since the 1970s. The original dd was designed for 9-track tape drives with a 512-byte default block size, obscure key=value syntax, and zero safety features. dd-rs reimagines it for the modern world with memory safety, performance optimizations, and crucial safety guardrails.

The 5-layer safety system

Before opening any output file, dd-rs detects what you are targeting — a regular file, a block device partition, a system disk, or an LVM volume. It checks whether the device is currently mounted and whether you are targeting a system-critical path like /dev/sda, then computes a risk score from 13+ factors (raw disk device +60, root filesystem target +50, block device partition +40). If the risk level is Caution or higher, dd-rs prompts for confirmation. The --explain mode shows exactly what the command will do, including the data flow and risk assessment.

Performance through tiered execution

For simple copies on Linux 4.5+, dd-rs uses copy_file_range(2) for zero-copy kernel transfers, achieving 1.5–3× the speed of GNU dd. On macOS it uses fcopyfile(3). Copies needing conversions use double-buffered read/write with read-ahead, overlapping I/O with CPU. The default block size is auto-tuned to 128 KiB, eliminating the millions of syscalls per second that plague GNU dd's 512-byte default. A visual progress bar with speed and ETA is shown by default, and SIGUSR1 still provides on-demand statistics for script compatibility.

Dual syntax

Legacy key=value syntax (if=/dev/zero of=test.bin bs=1M count=100) works exactly as expected, so existing dd scripts run unchanged. Modern subcommands are also available: dd-rs copy input output, dd-rs zero disk.img --size 1G, dd-rs random key.bin --bytes 32, dd-rs wipe /dev/sdb --passes 3, dd-rs info /dev/sda, and dd-rs explain if=/dev/zero of=/dev/sda.

Full compatibility

All 16 conversions (ascii, ebcdic, ibm, block, unblock, lcase, ucase, swab, sync, sparse, noerror, notrunc, excl, nocreat, fdatasync, fsync) and all 11 I/O flags (append, direct, directory, dsync, sync, nonblock, noatime, nocache, noctty, nofollow, fullblock) are supported. Size suffixes range from the classic c, w, b to modern KiB, MiB, GiB, and even decimal suffixes like kB, MB, GB. Exit codes match GNU dd exactly, and environment variables like POSIXLY_CORRECT and RUST_LOG provide fine-grained control. dd-rs is written in memory-safe Rust with C used only for EBCDIC lookup tables — making it auditable and secure.

MacVault is a portable encrypted file store for macOS and Linux that installs as an innocuous system utility. It provides dual-layer AES-256 encryption: the underlying APFS (macOS) or LUKS (Linux) sparsebundle image is encrypted, and the manifest tracking all files is encrypted with openssl enc -aes-256-cbc -pbkdf2. When the vault is locked, there is zero trace of its contents — no plaintext files, no metadata, nothing.

A workflow designed for simplicity

mvs init creates a new vault; mvs open unlocks and mounts it. Once open, mvs add ~/Documents/tax.pdf moves files into the vault while preserving the illusion that files remain in their original location. mvs list shows tracked files, mvs show restores all files to their origin while preserving tracking, and mvs hide instantly re-hides everything back into the vault. mvs close locks and unmounts the vault, leaving no trace.

Multiple vaults, one binary

Multi-vault support allows separate vaults for different purposes — work documents, personal files, projects — each with its own passphrase. mvs vault create/use/list manages them, and each is an independent encrypted sparsebundle with its own manifest. On macOS, passphrases are securely stored in the Keychain after first use. The disguise command moves the vault to a stealthy system path like /Library/System/Extensions/.cache, blending it in with system files.

Extensibility and auditability

A plugin system executes scripts on events: place executable scripts in ~/.mvs/plugins/ named on-open, on-close, on-add, or on-remove, and they are invoked with relevant file paths. An encrypted, append-only audit log records every operation (add, remove, hide, show, restore, open, close) inside the vault, viewable with mvs log.

• Platforms: macOS natively; Linux requires cryptsetup and ext4, with automatic backend selection.
• Atomicity: atomic manifest writes prevent corruption on crash.
• Minimal footprint: no background daemon — it only runs when invoked, and requires no root privileges.
• Clean removal: the uninstall command restores everything and deletes the vault plus the binary.

crontastic is a drop-in replacement for Vixie Cron that understands plain English. You type Every Tuesday at 10am /usr/local/bin/backup.sh and it figures out the rest. Every classic cron expression, operator, special string, and edge case is preserved — a true superset of Vixie Cron with no loss of functionality.

A parser that speaks human

The natural-language parser handles over 250 distinct patterns. It understands time of day (10am, 2:30pm, noon, midnight, half past 3, quarter to 5, five past 7, ten to 8, 3 o'clock, 7 o'clock in the evening, 11 at night, 3 in the morning, around 3pm, dawn, dusk, lunchtime, dinnertime, on the hour). It handles days and dates (Monday, weekdays, weekends, business days, Monday and Wednesday, tomorrow, next Tuesday, 1st, 15th, last day of month, first Monday of the month, January 1st). It understands frequencies (every minute, every 5 minutes, every 4 hours, every 3 days, every 2 weeks, hourly, daily, weekly, monthly, yearly, biweekly, quarterly, once a day, twice a day, 3 times a day). Even one-shot relative times work (in 18 hours, in 30 minutes, 2 hours from now, after 5 minutes, in a few hours, in a couple of minutes).

Full cron compatibility

All classic cron features are supported: the full field format (minute, hour, day-of-month, month, day-of-week), operators (*, comma, hyphen, slash, ?, L, W, #), day and month names, special strings (@reboot, @yearly, @monthly, @weekly, @daily, @midnight, @hourly), and the day-of-month + day-of-week OR semantics. The system crontab format (/etc/crontab) includes the username field after the schedule.

Built-in safety checks

Dangerous schedules that run more than ~500 times per day are flagged with a warning. Overlap detection checks existing crontab entries for collisions at the same minute. Root warnings suggest using a non-privileged user, and environment checks ensure PATH contains standard system directories, SHELL is set to a known shell, and HOME is set and non-empty.

The toolchain

The --explain mode translates any schedule into English and shows the next five execution times. Cross-platform support handles macOS and Linux with correct paths, shells, and defaults. The CLI includes subcommands for edit (-e), list (-l), remove (-r), user targeting (-u), check, explain, classic output (-c), daemon mode (-d), and stdin/file input. Daemon mode runs as a persistent scheduler, reading the crontab at startup and checking every minute for jobs to execute.

macos-evilmaid documents a physical-access attack chain on macOS that can be used for either legitimate liberation or malicious compromise, depending on the user. The technique exploits Recovery Mode's unlimited privileges to install a backdoor that persists across reboots and provides root access.

The attack chain

Boot into Recovery Mode (⌘+R on Intel, hold the power button on Apple Silicon), run a simple shell script from a USB drive, reboot normally, and connect to a reverse shell listening on port 5500. From the shell, dsenableroot activates the root user with a password you control. The entire process takes minutes and requires no admin password, no user interaction, and leaves no trace of authentication.

What gets installed

The script installs a LaunchDaemon at /Library/LaunchDaemons/com.apple.networkd.plist that masquerades as a legitimate Apple service. It creates a hidden payload directory at /private/var/tmp/.systemupdate/ containing the reverse-shell agent. The LaunchDaemon specifies UserName: root, so the shell runs with full privileges before any user logs in — and before any MDM policy enforcement begins. Recovery Mode runs underneath the installed OS, so MDM profiles, configuration policies, and user restrictions simply do not exist in that environment.

Two paths, one technique

• Path 1 — The Locked-Out Owner: you own the Mac but are stuck as a standard user because an employer or school enrolled it in MDM, IT left without providing admin credentials, or you bought a second-hand Mac still MDM-bound.
• Path 2 — The Evil Maid: an attacker gains temporary physical access to a Mac they do not own. The README explicitly compares these paths, noting the legal and ethical distinctions.

Mitigations

A firmware password (Intel) or Secure Boot → Full Security (Apple Silicon) prevents booting into Recovery Mode without authentication. FileVault full-disk encryption encrypts user data, though the OS volume itself is not encrypted — combined with a firmware password, this is much stronger. MDM/endpoint monitoring can alert on new LaunchDaemons or unexpected listening ports, but only after the fact. Physical security — locking the device and never leaving it unattended — is the most effective control.

Detection for blue teams

• Unexpected plist files in /Library/LaunchDaemons/, especially with Apple naming conventions.
• Unexpected listening ports — lsof -i :5500.
• Hidden directories under /private/var/tmp/.
• dsenableroot or dscl invocations in unified logs.
• Sudden disappearance of MDM enrollment profiles.