Eighteen protocols, one grammar

.....::::::::::::::....................::::::::::........               ....:::::----------------:::
:::------::::::....              ......::::::::::::::.....                 ....::::----=========----
---------::::...               ....:::----=========----::::......         .......:::::----=========-
====----:::....           .....::::---====+++++++++====----:::::::::::::::::::::::::::::::------===-
==----:::::...........::::::::::::-----======++=====----:::::::::------====------:::::::::::::::----
----:::::::::::::-----------::::::...:::::---------:::...   ....::--====++++++===---:::..........:::
::::::::::::---===========--::...       ..:::------::.         ..::--===++++++++===--::....       ..
........:::--===+++++++===--:::..       ..:-==++++==-::.......::::-------=========---:::..          
.   ....:::--=====+======-------:::::::::--=+*####**+=----===++====--::::::::::::---::::...         
      ...:::----------::::::---==++****++====+*#%%#+===+**#####*+=--:..       ...:::::::::...       
       ...:::::::::....    ..::-=++*##%%%#*+=::-+*=::-+####**++=--::..        ..:::-------:::....   
      ...:::::::::...        ..::--======--===+- = -=:..::-==+++++===--:::::::::---=======---:::....
    ...:::--------:::......::--==+***#####***+- .= =. .-=+*##%%%%##**+==-------====++++++===--::::::
.....:::---=========---------==+***###**+=---=+*+-.:=*#*+==========----::::::---===+++++===---::::::
...::::---===++++++====----::::---------==+*#%%#*+=-=+#%%%#**+=-::..       ..::---=======---::::...:
::::::::---===+++++===--::...      ..::-=+*####*+==--=++*****+=--:..       ...:::------::::.........
:::::::::::----=====---:::..        ..:--==++==--::...::---===---::::......:::::::::::....        ..
::::.........:::::::-:::::::.......::::------::..       ...::-------------------:::....           ..
-:::....       .....::::::---------======----::...      ..:::--===+++++++====---::...            ...
-::::...            ....:::---====++++++++===---::::::::::---====+++++++===---:::...         ......:
::::::....             ...:::---====++++++====-----:::::::------======-----:::::.............:::::::
::::::::.......        .....:::::-------------::::::........::::::::::::::::::::::::::::::::---:::::
.....::::::::::::...........::::::::::::::.......               ........:::::::----------------::::.
    ....:::::::------------::::::::::::......                    ....:::::-----==========-----:::...

Most exploit code is written in the dialect of whichever socket library the author happened to use. That is fine for a one-off, but it means every protocol is a different programming shape. Exploitmatic takes the opposite route: one grammar, and the protocol is just the identity of a step.

Identity comes from the registry

A step’s identity is the protocol it speaks, from the open IANA/STIX protocol vocabulary. The runtime implements the eighteen found most often in real exploits:

http  https  websocket  tls  tcp  ssh  ftp  smtp  dns
ldap  redis  mysql  postgresql  smb  telnet  snmp  process  file

The vocabulary is open and standard, so a solution does not invent names. An http step is an HTTP exchange. A tls step is raw bytes over a TLS session. A process step is a command on your host.

One shape for every protocol

Every step has the same shape:

<identity> <name>
  key: value
  ...
  assert: <type> "<expect>"

Byte-session protocols add send and recv. HTTP adds method, path, and encoding. The grammar stays one thing; the identity decides which keys are legal.

That uniformity is what makes the format learnable and LLM-writable. A model that has seen one TLS solution has seen the shape of all of them.

Hex in, hex out

For the byte protocols, the payload is hex. That sounds unfriendly until you notice the payoff: a solution is exact bytes, no encoding surprises, no line endings mangled by an editor. When you need to read or write it, hex "text" exists, with the usual escapes plus \xHH for one arbitrary byte.

A capture runs a regex over the received hex and stores group 1 decoded under a var. Later steps reference {var} in their send payload. That is how a solution follows a server-assigned value without a scripting language.

Asserts are the payoff

Each step ends with an assert. Five kinds cover the space:

• contains: a substring in the response
• regex: an RE2 pattern
• flag: a flag-shaped string, for labs
• oob: a callback hit the out-of-band listener
• empty: the response body is empty, for crash verification

A crash is data too. For a denial-of-service solution the assert is empty: the target stopped answering, which is the point.

Why close the grammar

A closed grammar means the runtime is deterministic. There is no embedded interpreter to surprise you, no template engine to evaluate, no supply chain that can hide a payload. A file is validated at load, and the validator and the runtime agree because they share the same grammar.

Eighteen protocols, one grammar, one portable binary. That is the whole design.