Subj : sexyz: ZMODEM ESC8 (Escape8thBit) is advertised but implemented in nei
To   : GitLab note in main/sbbs
From : Rob Swindell
Date : Sun Aug 30 2026 01:48:30

https://gitlab.synchro.net/main/sbbs/-/issues/1229#note_10227

**DSZ's ESC8 encoding, recovered.** It is not ZDLE escaping at all.

**`0x0E` (SO) prefix, followed by the byte with bit 7 cleared.** Ordinary ZDLE escaping of control characters continues alongside it, unchanged.

Evidence, from a capture of DSZ.EXE 1997 sending a 4096-byte random file to a receiver advertising ESC8:

- `0x0E` occurs 4,991 times and is followed by a byte below 0x80 in **100 %** of them; it is never doubled; the successor byte spans 0x01–0x7E.
- The stream contains **zero** bytes with bit 7 set (4 in 16,679, all before ESC8 engages), against 49.8 % in the same transfer without ESC8.
- Decoding on that rule alone recovers **92 contiguous bytes of the known plaintext** at file offset 2176, and restores the stream from 0.0 % high-bit to **45.6 %** (random data is about 50 %). The runs are subpacket-length rather than whole-file because framing and CRCs interrupt them.

This is precisely what DSZ.DOC claims — *"8th bit quoting similar to Kermit"* — and Kermit is where the prefix idea comes from.

**So the two ESC8 implementations use unrelated mechanisms:**

| | Encoding of a high-bit byte `c` |
|---|---|
| **DSZ** (Omen, 1997) | `0x0E`, then `c & 0x7F` — a Kermit-style prefix |
| **zmtx/zmrx 2.04** (2026) | `ZDLE`, then `c ^ 0x40` — ZMODEM's own escape |

Neither is wrong, because the specification never said. That is the whole problem: two implementers 29 years apart read the same one-line mention of ESC8 in ZMODEM.DOC and built different things, and a receiver that requests the mode gets whichever its peer happens to implement.

**This makes option 1 concretely worse than it looked when I wrote it.** "Implement ESC8" is not a matter of writing a decoder — it is choosing which of two mutually incompatible encodings to support, where picking either guarantees failure against the other, and one of them additionally needs an undocumented frame type. Option 2 stands: stop advertising `ZF0_ESC8`, retire `Escape8thBit`, and the failure mode disappears.

**Method note, in case anyone revisits this.** Disassembly was the obvious route and the wrong first one. DSZ.EXE is a plain unpacked MZ image (5 relocations, entropy 7.05, no packer signature), so it disassembles fine — but the escape table is not in the file. DSZ builds it at runtime into BSS, exactly as Forsberg's free `zsendline_init()` does, so a scan for a 256-byte class table finds nothing. Running the binary against a deliberately permissive receiver, with a known-plaintext file, gave the answer in three runs. Disassembly is still the only way to settle what the undocumented frame type `0x31` (`'1'`) means, and whether an RLE layer sits under the quoting.

— *Authored by Claude (Claude Code), on behalf of @rswindell*
--- SBBSecho 3.37-Linux
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

.