Why Exploitmatic?

Exploit knowledge is fragmented. The same attack is written as Python, C, Ruby, shell, notebooks, framework modules, and AI output, each in its own shape. Exploitmatic is a common representation for that knowledge: one plain text solution that records where it came from, what it targets, and what must hold for it to be verified.

A solution is data, not code. It chains steps, captures values, and evaluates an assert on each response. The runtime validates the file, replays it against one target, and prints verified or not verified. Exploitation is expressed in the file; verification is what proves it worked.

The format is plain text on purpose: a human can read it, an LLM can write it. Replay a documented attack against one target, from a TLS handshake to a flag read on your own host. Each step gets a result line, and the result says whether the attack worked.

What you can do

These are the outcomes a finished solution produces. Each one is a real example to read.

• Replay the Heartbleed memory leak against a TLS server and get a clear verified or not-verified result
• Probe a web application for a reflection point by sending a marker and checking it comes back
• Read the flag file a lab writes, the finish line of a capture-the-flag exercise
• Catch an out-of-band callback, the pattern behind Log4Shell

See the solutions for the full list and what each one proves.

One attack, one target

Exploitmatic is not a scanner. It does not crawl a network or sweep a fleet. You point it at one target with one documented attack, and the result tells you whether the attack worked. To run the same attack across many hosts, loop it in a shell.

What a run reports

Every run prints what was sent, what came back, and the test that ran on each step. The result comes from those tests, never from the file, so it always comes from the run itself. When every test passes the run is verified; when one fails, the report names the step and the test that failed.

A format a human can read and an LLM can write

Solutions are plain text on purpose. Every protocol speaks the same grammar: one step block, one capture form, one assert line with five test types. The identity vocabulary is open, taken from the protocol registry, and the runtime implements eighteen protocols today, the ones found most often in real exploits (see the format reference and the Identity list). A human reads a solution like a checklist, with # comments that say why each step runs. An LLM writes one from the same rules, because the runtime is deterministic: a file an LLM writes is exactly what runs, and the result lines give it a clean signal to fix and retry. Describe the attack in your own words, let an LLM draft the .txt, review it, then run it.

Steps that touch your machine

process and file steps run commands and read or write files on your machine. They run like any other step; you started the tool, so it runs where you tell it to. This is the reach a sandboxed scanner does not have.

Learn more

• Installation: get the program on your machine
• Usage: the command, its flags, and how to read the result
• The solution format: what a solution file is, in plain language, with a worked example
• Format reference: the whole grammar on one page
• Authoring guide: build a solution from scratch, stage by stage
• Solutions: what ships with the program and what each one proves
• Scope and ethics: when and how to use an attack replay responsibly