Joins the emission side (lanes AI1-AI3) to the counting side (A2, W2). Three results. The cost of applying a command is a property of its list, and the boundary is sharp: lists 1-16 each advance ModCount once per element, lists 17-27 never do. Four of the six prologue gates bump, one is free, and the sixth has no applier anywhere in the application path -- its cost is unknown, not zero. The batch applies the twenty-seven lists in a fixed order that is neither list nor offset order, with the six gates split across three separate per-player loops at three different points, and four of the sixteen bumps inlined into the batch rather than living in a handler, which is why a call-graph sweep under-counts them. Lane W2's four unnamed handler EIPs are named, and so are its two inlined ones, and the ten measured command bumps then decompose with zero residual. Four of the ten are the research-rate gate, one per submitted block, and one of those four is the human's. Two are list 14, on a turn that moved exactly one fleet -- which confirms lane AI2's P1 (an AI fleet order deposits two fleet-task elements where the interface deposits one) from the counter side, at no VM cost. The reference game is not what the record says. ref-turn2.sav IS turn2-state.sav; there are THREE AI players, not one, and the two dormant ones do run -- all three set a research rate and picked a research target on turn 1; and the four monster-faction players submit no command block at all, which is the first direct evidence that they have no client rather than an empty task list. Prediction committed for turn1-state: the same 12, out of a different set of commands -- 4 rate gates, 3 research targets, and three orders from the one AI with an empire, which are predicted to be a new design, a build order and a system-rates command, with NO fleet order on turn 1. The trap multiset it predicts contains two EIPs W2 has never seen and omits three it did, so it is cheap to falsify: one save swap on W2's unchanged watchpoint module. Also: phase 2 of the AI's turn is Hiver-only (a fifth cross-check on the species reading, and the reason one prologue gate has never been observed set), phases 29-33 are dead because the submit latches the client before it builds the send buffer, and cl_SetResearchTarget is AI-only surface with exactly one caller. 14 addresses in ghidra/addresses.d/lane-ai4.json; validated to a scratch path, 1,138 -> 1,152, no duplicate names. |
||
|---|---|---|
| campaign | ||
| findings | ||
| ghidra | ||
| guides | ||
| notes | ||
| objects | ||
| scripts | ||
| tools | ||
| verify | ||
| .gitignore | ||
| README.md | ||
sots-re
Reverse-engineering worklog for Sword of the Stars (2006, SOTS1) — the 32-bit DX9 original + expansions. The nitty-gritty: static/dynamic analysis notes, Ghidra & ReVa scripts, function/struct maps, D3D9 call traces, decomp progress, findings.
Where this runs
Analysis lab on spicy (PVE, 192.168.3.201):
- CT111
sots-re— Linux workspace: Ghidra + headless ReVa server, radare2/rizin/cutter, binwalk. Hosts the Samba share and this repo's working tree at/srv/re-lab/notes. - VM140
sots-re-win10— Win10 runtime + dynamic analysis (x64dbg, Cheat Engine, RenderDoc/apitrace, DXVK→CPU-Vulkan for GPU-less rendering).
Infra (guests, storage, network, share, ReVa endpoint) is documented from the
system-maintainer POV in trikilli → services/re-lab.md. This repo is everything else.
Layout
findings/— the running findings log (append-only), one file per subsystem.ghidra/— exported scripts, data-type archives, struct definitions.traces/— D3D9 / Win32 API call captures + analysis.scripts/— helper tooling (loaders, extractors, parsers).notes/— session notes, scratch, hypotheses.
Ownership / legality
Game binaries come from the owner's own GOG/Steam copy. RE is for personal
interoperability, bug-fixing, and preservation. Binaries themselves are not committed
here (see .gitignore) — they live on the lab's Samba share /srv/re-lab/samples.
Campaign (how this repo is run)
A 4-agent crew (defined in ~/.claude/agents/re-*.md) runs the exploration:
re-quartermaster (backlog + board) → re-analyst (maps via ReVa) →
re-verifier (proves vs real data; old-vs-new differential once reimpl starts) →
re-scribe (files the note, links it, commits).
campaign/board.md— live status board (start here).- Live tracking = Forgejo issues on
alex/sots-re(labelsstatus/*are the kanban columns;type/*,conf/*).campaign/board.mdis the editable mirror — publish withscripts/forgejo_campaign.py bootstrap(needsFORGEJO_TOKEN). campaign/backlog.md— prioritized target queue.campaign/open-questions.md— unresolved threads.findings/_template.md— the record format every finding follows.findings/{objects,control-flow,subsystems}/— the growing engine map.verify/{parsers,traces,harness,results}/— validation: struct parsers now, golden-trace replay + shim compare-mode for reimplementation.ghidra/— exported scripts + datatype archives.
Approach & north star: findings/00-strategy.md. Binary facts: findings/01-fingerprint.md.
Sibling repo
alex/sots-engine — the from-scratch engine source (clean-room, public-capable). This repo keeps the
evidence + planning for both; binary facts cross over only via ghidra/addresses.json → tools/gen_addresses.py.
guides/re-windows-2000s-howto.md— annotated bibliography + how-to for RE of mid-2000s MSVC/DX9 Windows games, with our-experience call-outs.