Steps

A solution is a list of steps, and each step is one action. Think of a step as one line in a checklist: do this, then look for that. The runtime works through the list in order and checks each response as it goes.

A step, annotated

http reflect
  encoding: query
  meaning: send a unique marker in the template param and confirm it comes back
  payload: REFLECTED_7x7
  assert: contains "REFLECTED_7x7"

What this step does:

• http is the protocol and reflect is the step name
• meaning: why the step exists, in plain words
• encoding: query with payload: send the value REFLECTED_7x7 in a GET parameter
• assert: contains "REFLECTED_7x7": pass only if the response contains the marker

The whole step is one idea: send a marker, confirm the target reflects it. This is the classic test for a reflection point.

How a step runs

When the runtime reaches a step, four things happen in order:

1. It fills in any values the file references (see Variables).
2. It talks to the target: sends what the step says to send, then reads the response.
3. If the step has a test, it checks the response against it.
4. It hands any new values from the step to the steps that follow.

One conversation or many

For tcp, tls, and websocket steps the connection stays open across steps. This matters for attacks that need a handshake first: stage the handshake in one step, send the exploit in the next, on the same connection. A close field ends the session when a step is done.

For http steps each step is its own request. Nothing carries over from the previous HTTP step.

On the byte-session identities (tcp, tls, and the rest) send is hex bytes, or the readable hex "text" form that the runtime hex-encodes for you. On websocket, send is plain text.

Pass, fail, and the result

A step without a test never fails. When every step with a test passes, the run is verified. When any step fails, the run is not verified.

The step fields

Every step has two required fields, the identity and the step name. The fields that follow depend on the protocol in identity; the full detail for each protocol is on its identity page. A step can also carry meaning, set, capture, and assert whatever the protocol.

identity field

Required on every step. The protocol this step speaks, and it decides which other fields apply. The runtime implements eighteen protocols today: http, https, websocket, tls, tcp, ssh, ftp, smtp, dns, snmp, ldap, redis, mysql, postgresql, smb, telnet, process, and file; the vocabulary is open and grows with the runtime. Each protocol has its own page with the full field detail (see Fields per identity below).

meaning field

Optional. Why the step runs, in plain words. The runtime prints it with the step result so a reader knows why the step mattered.

set field

Optional. Values to hand to later steps, in the same form as the solution-level vars. A later set on the same name wins. Reserved names are rejected. See Variables.

capture field

Optional on http, tcp, tls, and websocket steps. Pulls a value out of the response for later steps: on http steps from the full response text (status line, headers, and body), on tcp/tls/websocket steps from the received hex. See the capture form below.

assert field

Optional on any step. The pass or fail test on the response. A step without an assert never fails. See the assert form below and Asserts.

The assert form

assert: <type> "<expect>"
note: <what passing means>

The pass or fail test on the response.

assert type

Required. One of:

• contains: the response contains the exact text in expect
• regex: the response matches the pattern in expect
• flag: the response contains a flag-shaped string such as FLAG{...}
• oob: the target contacted the out-of-band listener

The contains, regex, and oob tests take an expect value. The flag test takes none.

note field

Optional. A plain-language explanation of what passing means, printed with the step result.

The capture form

capture <var>: <regex>

capture var

Required. The name later steps use as {var}.

capture regex

Required. The pattern that picks the value out of the response. The first capture group is the value that is stored.

Fields per identity

Which fields apply depends on the identity:

identity	fields
http	encoding (required), payload, path, headers, capture
websocket	send (required), recv, recv_until, timeout, close, capture
tls	send (required), recv, recv_until, timeout, close, capture
tcp	send (required), recv, recv_until, timeout, close, capture
process	command (required), cwd
file	op (required), path (required), data (required when write)

Each identity has its own page with the full detail: http, websocket, tls, tcp, process, and file.

Determinism

Keep steps deterministic: fixed bytes, fixed paths, no randomness. The same solution against the same target should give the same result, so a run can be repeated and compared any time.

See Variables for how values flow between steps and Asserts for the pass or fail tests.