# dwt/gui — X window feasibility payload Investigation of the VT1200 GUI architecture and whether an rdebug payload can create its own window. Read `dwt/notes/GUI_APPS.md` first; this directory is the reproducible part. | file | what it is | |---|---| | `xhello.asm` | payload: ABI check (`strlen("0::0")==4`) then `XOpenDisplay`, root lookup, `XCreateSimpleWindow`, `XMapWindow`, `XSync` | | `build.sh` | TI SDK (GSPA/GSPLNK under DOSBox) wrapper; writes `build/`, scratch in `work/` | | `probe.lua` | frame snapshots + marker/PC telemetry (250-frame interval) | | `probe2.lua` | same, 25-frame interval, also reads the X server client watermark | | `probe3.lua` | breakpoint on the X server accept entry + telemetry | | `build/xhello.bin` | assembled payload, linked at bit `0x01840000` | | `run/mame.log` | last live run: `strlen=4`, `stage=2`, `display=0`, watermark `1` | | `run/gui_frame*.png` | post-injection frames (normal Terminal Manager, no new window) | ## Build ```sh ./dwt/gui/build.sh dwt/gui/xhello.asm 01840000 ``` ## Run The payload needs the OS, i.e. `VT1200_SKIP_LEVEL1=1` (documented divergence), a BOOTP/TFTP server and the LANCE attached. MAME's network device is enabled by the **cfg file**, not the command line — without `` in `vt1200.cfg` the taptun provider is never opened (the tap stays `NO-CARRIER`). ```sh RUN=$PWD/dwt/gui/run mkdir -p $RUN/cfg $RUN/nvram cp dwt/evidence/live-run2/cfg/vt1200.cfg $RUN/cfg/vt1200.cfg sudo python3 -u harness/serve.py 192.168.99.1 --bootp \ --bootp-iface tap-mess-1000-0 & VT1200_SKIP_LEVEL1=1 MSG_TRIGGER=$RUN/trigger MSG_DIR=$RUN \ /home/arti/code/k-space/mame0289/vt1200 vt1200 \ -rompath harness/mame/roms -sound none -skip_gameinfo \ -networkprovider taptun -video none -nothrottle \ -cfg_directory $RUN/cfg -nvram_directory $RUN/nvram \ -debug -debugger none -autoboot_script $PWD/dwt/gui/probe2.lua \ -autoboot_delay 0 # once port 771 answers: python3 dwt/visual/inject.py --host 192.168.99.2 \ --poke-file 0x01840000 --file dwt/gui/build/xhello.bin \ --jump 0x01840000 --jump-wait 20 ``` Markers are 32-bit cells at bit `0x01850100` (display), `0x01850110` (root), `0x01850120` (window), `0x01850130` (sync), `0x01850140` (stage), `0x01850160` (strlen). The observed result is a **hang at stage 2** (`display=0`): `XOpenDisplay` blocks in Xlib's select wrapper and the X server's client watermark never moves. See the note for the verdict and the decisive next experiment.