How it works
A plain text file becomes a verified result
A solution describes an attack, step by step. The runtime reads the file, talks to the target, and reports whether the attack worked.
The file
Header, then steps
Header lines at the top name the attack. Each block after that is one step: it starts with an identity and a name, then key: value lines, and ends with an assert, the pass or fail test.
The identity is the protocol the step speaks. The session persists across steps, so a solution can stage a handshake and then fire its payload.
id: openssl/heartbleed-mem-leak
summary: CVE-2014-0160 Heartbleed
ref: CVE-2014-0160
tls clienthello-heartbeat
send: 1603030125010001210303...
recv_until: 0e000000
recv: 65536
assert: contains "0e000000"
tls malformed-heartbeat
send: 1803030003014000
recv: 70000
assert: regex "18030[123]40"$ exploitmatic heartbleed-mem-leak.txt 127.0.0.1:8443
clienthello-heartbeat PASS contains "0e000000"
malformed-heartbeat PASS regex "18030[123]40"
result: verified (2/2)The run
What a run reports
The runtime prints what was sent, what came back, and the test that ran on each step. One line per step, then a result line. There is no artifact file; the console output is the result.
The result comes from the 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.
Identities
The protocol is the identity
A step's identity is the protocol it speaks, from the open IANA/STIX vocabulary. The runtime implements eighteen protocols today, from HTTP and TLS to DNS, SMB, and host steps. The full identity list and per-protocol fields live in the documentation.
See the grammar in full
The whole format, on one page, written so a human can read it and an LLM can write it.