A tiny byte.
A different war.

01 / The specimen

A whole world in 215½ KiB.

WINRISK is a three-player territory-conquest game for 16-bit Windows. Its executable contains the rules, computer opponents, dialogs, map artwork and the invisible geometry that decides where you clicked.

The About dialog identifies Freeware Version 2.11, Steve Stancliff, December 1992. A second label in the executable says Windows Risk 2.01. Both are original evidence, not a discrepancy to conceal: the repair leaves both untouched. We describe the exact supplied file by its SHA-256 fingerprint, rather than assume that every download bearing the same title contains these bugs. [Audit: identification]

The brief was unusually constrained: find real bugs, fix the executable and preserve the game. There was no original C project to rebuild. The investigation therefore worked in three layers: map the file’s structures, follow the machine instructions, and construct small experiments that force a suspected error to become observable.

Not every surprising behaviour warranted a patch. The 42-node adjacency graph had valid reciprocal edges and no self-neighbours. The AI was examined but not rewritten: a weak strategic choice is not automatically a correctness defect. Unexplained pre-existing NOP runs were preserved rather than “cleaned up” on intuition.

02 / Inside the machine

An executable is a small city.

The file is a Windows New Executable (NE), not a modern PE image. Code, shared data, imported services and resources have distinct addresses and jobs.

The DOS header points to the NE header at 0x0250. Its segment table describes nine code segments and one data segment. Calls into USER, GDI, KERNEL and WIN87EM are resolved through imports and relocations. The audit counted 530 relocation records and 59 resources. Those are part of the loader’s contract, so a repair cannot treat apparently unused bytes as free space without checking what follows them.

The shared data is the real board

Most game operations do not act on pictures. They index small records in the data segment. The following names describe roles recovered during the audit; they are not recovered source-code identifiers.

These are data-segment offsets, not positions in the EXE. For example, code segment 5 starts at file offset 0x5600; instruction offset 0x0D5F therefore maps to file offset 0x635F. Its operand begins one byte later.

The same click has different meanings in different states. Clicking the sea during territory selection should not select an imaginary country. Clicking the sea after a battle may legitimately dismiss the result. A blanket “reject every background click” patch would stop the corruption but break the interface.

03 / A borrowed die

The dice were fair.
The comparison wasn’t.

The defender’s insertion-sort code reads from the wrong array. When a higher defender roll arrives, it preserves the attacker’s maximum instead of the defender’s previous maximum.

With attacker rolls 6, 5, 1 and defender rolls 2, then 3, the correct comparisons are 6 against 3 and 5 against 2. Both go to the attacker. The original instead stores 3 and 6 for the defender, so its second comparison costs the attacker an army. Roll order matters: reverse the defender’s rolls and that particular error disappears.

; segment 5 : 0D5F
A1 F0 0B   mov ax, [0BF0h]
; highest ATTACKER die

; segment 5 : 0D5F
A1 F6 0B   mov ax, [0BF6h]
; previous DEFENDER maximum

This is a one-byte repair: F0 → F6 at 0x6360. The following instruction still writes AX to the defender’s second slot at 0x0BF8. We change the source, not the rules, number of dice or random generator. [Patch manifest]

The binary audit goes further than this browser demonstration: it executes the decoded combat instructions, supplies deterministic random results, and checks army counts and return-state codes. It finds 2,317 disagreements in the original and none in the repair across the same 10,836 configurations. That fraction is not an estimate of the percentage of real battles affected: different dice configurations do not occur equally often in a played game. [Recorded regressions]

04 / Between the turns

The bugs in the gaps.

A battle can be calculated correctly and still lead to the wrong game. Messages, cancelled dialogs, card cursors and continuation paths all have their own contracts.

One physical click, two queued actions

After a combat result, the old mouse handler posts a dismissal message but carries on through normal hit testing. It posts another action from the same click. By the time that second action is handled, the first may already have advanced the state. The repair returns after the first post; ordinary input continues through the normal path.

Off-map is a sentinel, not a country

A failed hit test returns -1. Without a range check, the dispatcher calculates territories + (-1 × 22), which lands in the preceding player storage. In a crafted test state, two preceding words change from (3, 5) to (0, 6). This proves an out-of-range write; it does not say that every sea click corrupts an ordinary game.

An elimination that misses its handover

Conquering a player’s final territory sets a pending-elimination flag. The optional troop-movement continuation processes it and transfers the defeated player’s cards. But when compulsory movement leaves only one army behind, execution follows the ordinary result-dismissal path instead. That path used to return directly to attack selection, bypassing the transfer.

The fix checks the pending flag during result dismissal, routes through elimination processing when necessary, then clears the flag. A second continuation must not award the same cards twice; the audit checked that too.

The missing forty-fourth card

The shuffle creates 44 entries, numbered 0–43. The old draw routine reshuffles when the cursor is greater than 42, before slot 43 can be used. Changing the comparison constant from 0x2A to 0x2B makes the check agree with the deck’s actual length.

Cancel must mean cancel

The Setup dialog originally edited live player records. Cancel closed the window but did not undo a changed name or human/computer flag. The wrapper also accepted any nonzero return value, inadvertently treating dialog-creation failure (-1) as success.

05 / Invisible borders

The map you click is not the map you see.

The artwork and the hit regions are separate resources. Eight malformed coordinates distort seven countries’ clickable outlines while the printed borders look perfectly normal.

Eastern Australia contains an x-coordinate of 346 instead of 546. Indonesia contains a y-coordinate of 476 instead of 276. Other slips affect Middle East, Taymyr, Buryat, China and India. These corrections were inferred from neighbouring vertices, shared borders and the original map bitmap; no artwork was altered. [Audit: polygon repairs]

A marker mistaken for a vertex

Each point list ends with (−100, −100). That is a terminator, not a distant corner of the world. Both polygon consumers passed it to CreatePolygonRgn: the hit-test path in segment 4 and the bounds path in segment 3. Both loops needed repair.

Switch off “Include original sentinel” above to separate that error from the malformed coordinates. With a correctly closed polygon, the extra trip out to the sentinel and back can enclose zero area. So it would be wrong to claim that this bug visibly corrupts every territory. Buryat’s malformed closing point is a particularly revealing combination: the bad endpoint and the sentinel can create an unintended filled wedge.

The audit exercised all 42 resources through both actual polygon-construction routines: 84 repaired API-boundary counts, with no terminator included. The geometric witness points demonstrate changed classifications; they are not screenshots of a native Windows session.

06 / Binary surgery

Make room without moving the world.

Some repairs fit in one operand. Others need new control flow. The challenge is to add that logic without invalidating the executable’s layout.

The card threshold and combat operand are in-place changes. The input guard, elimination continuation and transactional Setup wrapper need more instructions. The repair adds 94 bytes to segment 5 and 58 bytes to segment 9, using existing file padding. Near jumps divert the old paths into these helpers, which then return to the existing code.

Padding is not automatically safe to overwrite. Each affected segment’s relocation table originally followed its code. The patch moves that unchanged table forward within available padding and updates the segment’s length and minimum allocation. Other code and resource offsets remain fixed. The whole file still occupies 220,672 bytes.

A hash-locked patcher accepts only the exact original fingerprint and reproduces the repaired fingerprint. That prevents a plausible-looking patch from being applied to a different revision where the same file offsets could mean something else. The original was kept for rollback.

07 / The repair ledger

Nine defects.
One bounded repair set.

The source audit groups these findings into eight sections, with the two Setup defects together. They are separated here so each contract failure can be inspected on its own. Open an entry for the location, witness and repair.

Exact byte operations are in the patch manifest; the full audit retains the original finding groups and qualifications.

08 / Proof & limits

Evidence, not a victory lap.

The strongest part of a repair is not how convincing the explanation sounds. It is whether the bad case fails before the patch, passes after it, and leaves the surrounding contracts intact.

The Python harness deliberately fails on unsupported instructions rather than pretending to execute them. Linear disassembly can mistake embedded jump-table data for instructions, so decoding is restarted at function boundaries. Imported API and calling-convention identification was cross-checked against Wine’s Win16 specification files. These precautions reduce specific sources of error; they do not turn a purpose-built harness into a complete Windows machine. [Audit: method and confidence]

Which executable does this describe?

Original SHA-256

b829f76340d6848a697b7a4b499c60c27bb109921a00b96fd771eb5bff894ae3

Repaired SHA-256

9fcdf5e021d089c135eb6b39f609f495b955e71a4d7798fbe41844c1284fcc76

What remains to be tested

Play a complete graphical game in the intended Windows or emulator environment. Exercise Setup Cancel and OK; click the corrected territories and the sea; dismiss multiple combat results; eliminate a player and check the card handover. Observe actual GDI regions, resource loading and message behaviour. General low-resource failures, every possible re-entrant message sequence and exhaustive AI validation remain outside the repair set.

The absence of another justified patch is not proof that no other bug exists. Likewise, preserving the binary’s structure is necessary but not sufficient for compatibility. This is a bounded, tested repair with a remaining integration check—not a certification that WINRISK is bug-free.