serversdown/seismo-relay
1
0
Fork 0
Code Issues 6 Pull Requests Actions Packages Projects Releases 1 Wiki Activity

docs(series4): overwrite is protocol-identical to create -- no handshake

Browse Source 
The firmware carries `Overwrite File`, `MFS FILE EXISTS` and `Cannot be
Overwritten`, which suggested the wire path might negotiate an overwrite.  It
does not.  Those strings belong to the on-device Save screen (CSaveSetupFile),
not the protocol.

A second Thor push to TEST1.mmb -- a name that now existed, and which SUB 0x41
confirmed was the ACTIVE setup -- produced an identical sequence:

  * same 12 SUBs in the same order, same offset fields
  * 0xDA / 0x68 / 0x82 data byte-identical
  * 0x71 differs in exactly 18 bytes = the one edited note string
  * all seven write acks identical and still all-zero
  * no dialog on Thor

Verified on the unit: the edited General Notes string is present in the setup on
the device.  The write applied silently and in place, and being the active setup
bought it no protection.

Two consequences recorded:

  * A writer needs no exists-check and no overwrite negotiation.
  * We have never seen this protocol report a FAILED write -- acks are all-zero
    across create and overwrite alike.  Do not treat a zero ack as proof a write
    applied; read back with 0x41 + 0x1A and compare.  And a remote push to a
    monitoring unit's active setup changes what it is recording with, unprompted
    -- gating that belongs in SFM, because the device will not do it.

Still untested: overwriting a non-active setup, and factory.MMB.  Neither
blocks a writer.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL
This commit is contained in:
serversdown
2026-09-24 18:56:20 -04:00
co-authored by Claude Opus 5
parent d33e2d85be
commit b5e34ce8ae
1 changed files with 48 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/micromate_protocol_reference.md
+48
View File
@@ -865,6 +865,54 @@ homebrew client needs no file-transfer primitive and no pre-existing target:
That closes the last open question about whether Series IV setup management is
reachable from outside Thor. It is.
### ✅ Overwriting is protocol-identical to creating (2026-09-24)
The firmware carries strings that suggest an overwrite handshake:
```
Overwrite File MFS FILE EXISTS
Cannot be Overwritten Can Not Delete Active Setup File
```
**There is no such handshake on the wire.** A second push to `TEST1.mmb` — a
name that now existed, and which `SUB 0x41` confirmed was the *active* setup —
produced a byte-for-byte identical command sequence:
| | create | overwrite |
|---|---|---|
| SUBs, and their order | `5B 41 08 2E 1A DA 68 73 82 83 71 72` | **identical** |
| every `offset` field | — | **identical** |
| `0xDA` / `0x68` / `0x82` data | — | **0 bytes differ** |
| `0x71` data | — | 18 bytes differ = the one edited note |
| all seven write acks | 11 zero bytes | **identical, still all-zero** |
No extra command, no confirm step, no error status, and **no dialog on Thor**.
Those firmware strings belong to the on-device Save screen (the
`CSaveSetupFile` UI class), not to the protocol.
**The overwrite was verified on the unit itself** — the edited `General Notes`
string is present in the setup on the device, so the write applied, silently and
in place.
This is the case that mattered most, and it landed the right way round: the
target was the **active** setup, which is what a real remote config push would
hit. Being active bought it **no protection** — it was overwritten directly.
A writer therefore needs no exists-check and no overwrite negotiation.
⚠ That cuts both ways. A remote push to the active setup of a **monitoring**
unit changes the config it is recording with, with no prompt, no warning and no
distinguishable ack. Whatever SFM eventually exposes should gate this on the
operator, not on the protocol — the device will not stop anyone.
⚠ Two overwrite cases remain untested: a **non-active** setup file, and
`factory.MMB`, which `Cannot be Overwritten` probably guards. Neither blocks a
writer — the active setup is the one worth pushing to.
⚠ Note also that the write acks are **all-zero in every case observed**, across
a create and an overwrite. We have never seen this protocol report a *failed*
write, so **do not treat a zero ack as proof a write was applied.** Read the
config back and compare; `SUB 0x41` plus `SUB 0x1A` make that cheap.
## Static analysis of the firmware (2026-09-23, solo session)
### Architecture