vt1200/EXPLOIT_NOTES.md

VT1200 code-execution audit notes

Objective: run self-compiled TMS34010 code on the VT1200, loaded over the network, without modifying the ROMs (user requirement). So: find a remotely-triggerable control-flow hijack in the stock firmware.

Hardware: v2.2 unit (SHOW reports Firmware Revision V2.2; power-up self-test passes), on the LAN. ROM/RAM map: see MEMORY_MAP.md. reference/dis34-a-v22.txt.gz is the analyzed disassembly used below (byte offset = displayed address, see tools/).

Safety: the terminal stores configuration in NVRAM. INIT, menu diagnostics and any crash risk that config — capture the current setup (SHOW / setup screen) before sending malformed data.

Attack surfaces, ranked by attacker control

Surface	Who initiates	Control	Evidence
PCF / SNF font parsing	terminal (font server or TFTP font path)	we serve the font bytes	pcfReadBitmaps, Invalid SNF font file format.
TFTP font file fetch	terminal	we are the TFTP server	dwt_tftp.c, Setting TFTP Font Path, .DECW$FONT
BOOTP reply	terminal (broadcast)	we are the BOOTP server	bootp_proto, do_bootp
MOP remote console	host → terminal	command args only	DWT>>>, INIT/TEST/SHOW/HELP
X11 requests	client → terminal	full protocol	X server (port 6000)
LAT / TCP	mixed	large	x_tcp_interface, ni_rcbtom

What is already guarded

• Network receive path (ni_rcbtom, 0x08006E–0x080170): explicit size checks — cmpi 0x5EE (MAXSIZE_RCVPKT = 1518) and cmpi 0x226 (SIZE_OF_RCV_BUFS = 550), each followed by an error + abort.
• TFTP data path (tftp_read, 0x07DD78–0x07DE40): validates payload length against buffer capacity (0x7DDAA cmp a11,a9 / jrle), then the bufsize (%d) too small for %d bytes error; standard 512-byte block logic (cmpi 0x200 → last-block flag at 0x1CB940).

So the packet layers are not the low-hanging fruit.

The promising target: the X11-derived font parser

The server is MIT X11 sample-server derived — the strings are its internals: pcfReadBitmaps, mfbValidateGC, mfbFaultGlyph, AM_FaultGlyph, mfbFreeGlyphCacheSpace. It parses PCF, SNF and a DEC font format.

Locations (v2.2 byte offsets):

Code	Site	String
PCF bitmap reader	0x0F09F2, 0x0F0A2C	bad count in pcfReadBitmaps (expected %d, got %d), allocation failure in pcfReadBitmaps (offsets,%d)
PCF font reader	0x0F177E	Failed to read PCF format bitmaps
SNF reader	0x0ED830	Invalid SNF font file format.
metrics validation	0x0EB288, 0x0EB32E	bad packed/unpacked metrics, glyph=…
glyph data	0x0ED426	Failed to read glyph data (%d at %d) for %s.
font-file open	0x0ED014, 0x0ED27A, 0x0ED37A, 0x0EDA1A	Could not open font file '%s'. etc.

Why this matters: this is X11R3/R4-era font code, a class with a long public history of memory-safety bugs, well studied in libXfont (Ilja van Sprundel's 2014–2015 audit: integer overflows in PCF/SNF/BDF table size arithmetic leading to undersized allocations and heap overflows, plus missing bounds checks in pcfReadFont). The firmware predates all of those fixes, and the presence of some checks (bad count in pcfReadBitmaps) just means it is a version that has a few — not necessarily all.

Suspect constructs already spotted in the font loader: sub a5,a3 / sll 0x6,a3 (0x0ED396) and sll 0x3,a12 (0x0ED29E) — table indexing by a value derived from file data, with no visible bound check at the use site.

CONFIRMED CANDIDATE: pcfReadBitmaps num_chars integer overflow (heap)

Era source: reference/x11/r4/contrib/server/pcf/fonts/lib/pcf/pcfrbitmaps.c (X11R4, Dec 1989 — the firmware's error strings match this file exactly, e.g. allocation failure in pcfReadBitmaps (offsets,%d); R5's monolithic pcfread.c does not contain that string).

n = pcfReadInt32(file);                     /* attacker-controlled */
if (pCS->nChars==0) pCS->nChars = n;        /* only cross-check is nChars, not a max */
else if (n != pCS->nChars) { error; return; }
offsets = (CARD32 *)fosAlloc(n*sizeof(CARD32));   /* n*4 — 32-bit, can wrap */
if (!offsets) { "allocation failure ... (offsets,%d)"; return; }
for (i=0;i<n;i++) offsets[i] = pcfReadInt32(file); /* writes n entries */

Firmware (v2.2), pcfReadBitmaps at 0x0F09CE–0x0F0A5E:

0x0F09CE  move *a9(0x270),a11,1        ; a11 = pCS->nChars
0x0F09D2  jrne ...                     ; nonzero -> only compare against n
0x0F09D4  move *a13(0x20),*a9(0x270),1 ; nChars==0 -> nChars = n (file value)
...
0x0F0A06  move *a13(0x20),a11,1        ; a11 = n
0x0F0A0A  sll 0x2,a11                  ; a11 = n*4   <-- NO overflow/range check
0x0F0A12  calla 0x3f703d90             ; fosAlloc(n*4, 1)
0x0F0A18  move a8,*a13(0x40),1         ; pBitOffsets = result
0x0F0A1E  jrne ...                     ; alloc ok?
0x0F0A20  "allocation failure in pcfReadBitmaps (offsets,%d)"
0x0F0A42  sub a10,a10                  ; i = 0
0x0F0A44  move *a13(0x20),a11,1        ; n
0x0F0A48  cmp a11,a10 / jrge           ; loop while i < n
0x0F0A52  move a10,a7; sll 0x5,a7      ; i*32 bits = i*4 bytes
0x0F0A5A  add a11,a7                   ; offsets[i]
...                                    ; writes n entries (n*4 bytes)

There is no range check on n between the read and the multiply, exactly as in the R4 source. So n >= 0x40000000 makes n*4 wrap: e.g. n = 0x40000001 → alloc(4) → the loop then writes ~4 GiB of file-derived data starting 0 bytes in → heap overflow with attacker-influenced content (the first writes come from our file; ultimately EOF-filled 0xFFFFFFFF).

Ruled out (fixed in this firmware)

• The R4 stack bug in pcfrfont.c (TableDesc toc[NUM_FONT_TABLES=8] with loop bound MAX_FONT_TABLES=32) is not present: the firmware's loop is bounded at 8 (0x0F0A…: cmpi 0x8,a9; jrlt loop), and its message says nTables>NUM_FONT_TABLES.

Secondary candidates (not yet audited in the firmware)

• pcfReadBitmaps repad path: padTmp = alloc(padSize) where padSize comes from one table while the glyph offsets/metrics come from another — a mismatched-size write if the two disagree.
• pcfReadProperties (allocation failure ... (tmpbuf,%d), (isstring,%d)) — property-table parsing.
• pcfReadMetrics (bad char count (%d, expected %d), (pCI,%d,0x%x)).

Harness — tools/fontgen.py (+ test_fontgen.py, 10 tests)

• PCF: pcf_tables(), get_num_chars() / set_num_chars() (byte-order aware — PCF table bodies are MSBFirst when format & FMT_MS_BYTE (bit 2) is set; this bit us once, the 10x20 font reads 223 only big-endian).
• Baseline: minimal_bdf() → bdftopcf → a valid PCF the terminal should accept, so we can distinguish "parse error" from "never delivered".
• TFTP (TFTPServer): RFC 1350 octet read server; short-block termination, error opcode for missing files, never dies on an idle socket (bug fixed).
• CLI:

  python3 tools/fontgen.py baseline out.pcf
  python3 tools/fontgen.py mutate base.pcf evil.pcf --num-chars 0x40000001
  python3 tools/fontgen.py info  some.pcf
  python3 tools/fontgen.py serve evil.pcf --host 0.0.0.0 --port 69 --name font.DECW$FONT
  

Artifacts in reference/fonts/: baseline.pcf, evil-numchars.pcf (num_chars = 0x40000001), fonts.dir, system-10x20.pcf (a real system font).

Primitive: num_chars = 0x40000001 → n*4 wraps to 4 → alloc(4) → the offsets loop then writes n entries → heap overflow.

Next: reachability

Still to determine before touching the live terminal: how the VT1200's TFTP font path names the file it requests, and whether it fetches fonts.dir first (strings: /fonts.dir, font name different: name in path file='%s'). serve logs every request, so the first run against the unit will tell us.

Font delivery: confirmed protocol (live, v2.2)

Learned by driving the real terminal:

• Setup has two fields — LAT Font Path and TFTP Font Path — with a radio selecting which is used.
• The TFTP Font Path is <host>:<fontdirectory>:
  • 100.103.255.254 bare → parsed as a port (atoi stops at the first .) → font path :100,ROM (host empty, no font source at all; xlsfonts then reports no fonts).
  • 100.103.255.254:69 → host 100.103.255.254, directory 69.
• The terminal then fetches <fontdirectory>/fonts.dir over TFTP and loads the font files named inside. Observed RRQs: "69", then "69/fonts.dir".
• Confirmed exchange once routing was fixed: RRQ "69" → <us> DATA block 1 → terminal ACK block 1 → <us> DATA block 2 → terminal ERROR ENOSPACE. (Serving a directory path as if it were a file makes the terminal abort with TFTP error 3.)

Two non-obvious gotchas

1. Routing: our replies were hijacked into the WireGuard interface (ip route get 100.103.100.103 → dev wg-k-space src 172.24.1.2), so nothing reached the terminal even though the server logged the requests. Fix: pin the terminal to the LAN interface (ip route add 100.103.100.103/32 dev enp197s0f3u1) or drop the tunnel.
2. The TFTP server must not block: the terminal can ACK then ERROR, so the server has to abort that transfer on a TFTP ERROR, or it stalls on retransmits and misses the following fonts.dir request.

Working delivery recipe (confirmed)

1. Setup → Font Path Selection → TFTP Font Path = <our-ip>:<fontdir> (e.g. 100.103.255.254:69) → Apply. Font path becomes 100.103.255.254:69,ROM.
2. The terminal TFTP-fetches <fontdir>/fonts.dir from us.
3. A client OpenFont/ListFontsWithInfo triggers the lazy fetch of the font file named in fonts.dir. Observed working: RRQ "baseline.pcf" → DATA 1 → ACK 1 → DATA 2 → ACK 2.
4. The server registers our font name (-misc-vt1200test-medium-r-normal--8-80-75-75-c-80-iso8859-1 shows in xlsfonts).

Open issues

• xlsfonts -l -o / ListFontsWithInfo still reports the font unmatched, so the delivered file is not becoming an openable font — the parser may be rejecting it (fonts.dir name vs the name inside the file, or a required table). Does not block the exploit (pcfReadBitmaps runs during the parse).
• xset fp rehash on the terminal returns "bad font path element … Directory missing fonts.dir" and issues no TFTP request, so re-applying via Setup is currently the only way to re-read a changed fonts.dir.
• The terminal sends a trailing ACK block 3 after a short final block.

Live results (patched payload)

• Small synthetic font (680 B = 2 TFTP blocks): transfers cleanly, name registered, but OpenFont/ListFontsWithInfo still reports it unmatched and xmessage can't convert it — so the delivered font is not accepted, and no message is printed.
• Large real font (25,860 B ≈ 51 blocks): the terminal ACKs block 1 and 2, then stops, and ~15 s later sends ERROR ENOSPACE. This happens for the unpatched font too, so it is a transfer/large-file limit, not our patch.
• num_chars = 0x40000001 therefore never produced corruption: the whole file never arrived, and the failure is a clean ENOSPACE.
• The terminal prints no font error, so we have no black-box oracle for where the parser bails.

What that implies

• We can reliably push ≤ ~1 KiB of font data into the parser today.
• Two blockers: (1) our synthetic small font is rejected somewhere before it becomes an openable font; (2) larger fonts cannot be transferred.
• To fire pcfReadBitmaps we need a font that (a) parses up to the BITMAPS table and (b) fits the transfer window — or fix the large-transfer path.

Candidate next moves

1. Fix/inspect the large-transfer path: try a fresh TID per transfer (spec behaviour), a smaller/spec block size, and probe with a ~2 KB valid font to find the real limit.
2. Make a small font the parser accepts (debug the rejection — likely a table or property the terminal requires).
3. Get visibility: a minimal MAME driver for the TMS34010 + ROM would let us watch the parse and choose values that corrupt rather than cleanly fail.

Update: transfer window and font acceptance

• Multi-block transfers work. A 2248-byte real font transferred fully over 5 blocks — but the terminal paused ~13 s mid-transfer (busy processing), so the server needs a generous ACK timeout (we now use 60 s). The earlier 25 KB failure at 2 blocks was our 15 s timeout expiring during such a pause.
• Even a real, valid font is not openable. decsess.pcf (a genuine DEC cursor font) fetched via TFTP shows up in xlsfonts as VT1200PROBE1 but OpenFont/ListFontsWithInfo still fails. So the rejection is not about our synthetic font — something about the TFTP font path itself.
• Hypothesis under test: the firmware's own template is DECW$FONTPATH:*.DECW$FONT; — the font files may need a .DECW$FONT name (and/or a DEC-specific container format). Test: index lists probe-uniq.DECW$FONT.

DEC's own font container (found in the firmware)

Font-file dispatch at 0x0ED764:

cmpi 0x70636601, a5      ; "pcf\1" -> PCF reader
jrne L76BC60             ; otherwise -> SNF path
...
cmpi 0x1DF5E76, a5       ; SNF magic (NOT the MIT/X11 version 4!)
cmpi 0x54, <field@0x20>
cmpi 0x54, <field@0xb0>
<a9(0xd0)> must be 1
<a9(0xe0)> must be 6
        else "Invalid SNF font file format."   (0x0ED82E)

• Our PCF files carry 0x70636601, so they take the PCF path and are rejected silently — even a genuine DEC cursor font (decsess.pcf).
• Our MIT-style SNF is rejected with the message above — the firmware wants a DEC container with magic 0x1DF5E76 and that field layout.
• We now have an oracle for the SNF path (the message names the failure) and a concrete target format to reverse from the code at 0x0ED760–0x0ED8C0.

Terminal crash (observed on real hardware)

The unit displayed a Level-0 fault screen:

LEVEL0 ERROR -> Illegal OPCODE Occurrence - 28
    007AA3F0   00200008   00000260   3F9B8EA0
    00785110   00785070   00000020

• The firmware's own string for this fault is ILLEGAL OPCODE, PC=%#08x, so one of those is the PC.
• Decoding the values as TMS34010 bit addresses (byte = v >> 3):

value	physical byte	where
007AA3F0	0x000F547E	RAM ~0.96 MiB
00200008	00040001	RAM 0.25 MiB
00000260	0x4C	RAM
3F9B8EA0	0x07F371D4	ROM off 0x0F71D4 (the only ROM value)
00785110	0x000F0A22	RAM ~0.94 MiB
00785070	0x000F0A0E	RAM ~0.94 MiB
00000020	0x4	RAM

• ROM code lives at bit 0x3F200000+; only one entry is in ROM. So the CPU was almost certainly executing out of RAM — it fetched a non-instruction and trapped. That is the signature of control flow redirected out of ROM into RAM, i.e. a hijack, reached via memory corruption.
• Circumstances: the terminal crashed while idle (a separate session was running the latd (LAT) setup; no command was in flight). An idle crash implies a latent corruption that surfaced on later execution, not a just-in-time fault.

Prime suspects (both control attacker-supplied bytes into the terminal):

1. LAT receive path — see lat/notes/lat-receive-audit.md: the demultiplexer at 0x16C44 walks nbr_slots (wire byte 1) with no length bound, so nbr_slots/byte_count up to 255 give ~66 KB of out-of-bounds slots that are acted on (Data_a delivered; Start/Stop/Reject mutate SCB state).
2. Font path — pcfReadBitmaps num_chars*4 overflow (see above), delivered over TFTP; the terminal retries the font path periodically.

Isolation plan: power-cycle, then (a) run only latd with the font path set to ROM, and (b) run only the TFTP font path with latd stopped — see which one reproduces the idle crash.

Plan

1. Baseline: obtain or generate a valid PCF/SNF font the terminal will accept, and confirm the terminal actually fetches it (proves reachability).
2. Delivery harness: a Python TFTP server (RFC 783 — trivial) serving .DECW$FONT files, with the terminal's Font Path pointed at us; or impersonate the font server.
3. Find the bug: compare the firmware's pcfReadFont/pcfReadBitmaps against the published libXfont fixes to find the missing check; or fuzz mutated PCFs and watch for a crash (terminal reset / hang / font error).
4. Payload: RAM is writable and executable and we know the map; place code in RAM and redirect the corrupted control datum (return address or a font/glyph structure field) to it.

The alternative (faster but needs physical work) is a ROM patch + bootloader — explicitly ruled out, ROMs to stay original.