# Command line reference

> The Exploitmatic command: what it takes, what the flags mean, and how to read the result.

Exploitmatic is GUI-first: running the binary with no arguments opens the desktop workbench. The command line is selected with `--cli` or a subcommand (`run`, `lint`, `check`, `mcp`); `run` is the default command. Scripts and CI use this page. The program runs from a command line:

```
exploitmatic <solution.txt> <target> [flags]
```

The two required arguments are the solution file and the target. Flags are optional and can appear before or after the arguments.

## The arguments

| argument | what it is |
| --- | --- |
| `solution.txt` | the path to a solution file, the attack to replay |
| `target` | the target address, shaped by the solution's protocols |

The target shape depends on the protocol in the solution. A `tcp` or `tls` solution takes a `host:port`. An `http` or `websocket` solution takes a base URL. Host-scope solutions (`process`, `file`) ignore the target.

## The lint subcommand

A second command form checks a solution without running it. It is a rule-based checker (not a language model) that reports the grammar mistakes that most often trip up an author, each with a suggested English fix:

```
exploitmatic lint <solution.txt> [...]
```

It flags the removed `name: value` step fields (`encoding:`, `payload:`, `assert:`, `send:`, and the rest), an HTTP method used in the wrong place or the wrong case, a method directive on a non-http step, an unindented directive, and an unknown identity. It reports every finding instead of stopping at the first, and it never rejects the file.

```text
$ exploitmatic lint solution.txt
solution.txt:
  line 7: "encoding" was removed; step fields read as English directives
  suggestion: get <path> / post <path> as <shape>
  line 12: "GET" is an HTTP method; write it lowercase
  suggestion: get /x
```

It exits `0` when every file is clean and `1` when any file has a finding.

## The flags

| flag | default | what it does |
| --- | --- | --- |
| `-flag-path` | `flag.txt` | where `{flag_path}` points |
| `-param` | empty | override the input parameter name |
| `-oob-host` | empty | override the out-of-band listener host; use a routable address when the target is in a container |
| `-oob-port` | `0` | override the out-of-band listener port (`0` picks a free one) |
| `-timeout` | `10s` | per-request timeout |
| `-version` | - | print the version and exit |

## The result

The runtime prints one line per step and a result:

```text
probe  PASS  contains "49"
rce    PASS  contains "REPL_RCE_MARKER"
read   PASS  flag
3/3 verified
```

Then it exits with one of three codes:

| exit code | what it means |
| --- | --- |
| `0` | verified: every step's test passed |
| `1` | error: bad arguments, invalid solution, or replay failure |
| `2` | not verified: at least one step failed its test |

The result comes from the step tests. It is never stored anywhere, so it always comes from the run itself.

## Examples

Heartbleed against a target:

```sh
exploitmatic solutions/openssl-heartbleed-mem-leak.txt example.com:8443
```

An HTTP solution against a target:

```sh
exploitmatic solutions/tpl-jinja2-ssti-rce.txt http://example.com/render \
    --param template --flag-path flag.txt
```

Host-scope steps:

```sh
exploitmatic examples/host-exec.txt example.com
```

Override the input parameter without editing the solution:

```sh
exploitmatic solutions/tpl-jinja2-ssti-rce.txt http://example.com/render \
    --param payload
```