Wolfenstein Modloader Buy me a coffeeKaffee spendieren

Wiki / Latest research roundsNeueste Forschungsrunden

The SWF-Based UI: Format, Menu Entries, and HUD Restyling

Partly solvedTeilweise gelöst Original page in the GitHub wikiOriginalseite im GitHub-Wiki

In plain wordsIn einfachen Worten

This report studied the menu and HUD system of Wolfenstein II: The New Colossus, which is built on id Software's own Flash-like binary format (idSWF). It redid an earlier pass that had looked at the wrong game's files by mistake, and found that 17 of the 18 UI files are compressed. Plain HUD icon textures can be swapped with the already-proven texture route, but the artwork packed inside the UI files themselves cannot be edited yet; all of this is static analysis, and whether a new menu entry appears needs an in-game test.

  • TNC has 18 .bswf UI files (format version 31); reading them without decompressing gives convincing-looking garbage.
  • Chapter and DLC menu content is ordinary, patchable decl data; the UI files only provide named containers.
  • About 1,700 HUD/GUI images are normal textures; none of 1,430 sampled uses virtual texturing.
  • The art atlas embedded in each UI file is blocked: there is no reader or writer for its format.
  • The dev menu file debugmenu.txt does not exist in any of the 24 TNC archives.

Dieser Bericht untersucht das Menü- und HUD-System von Wolfenstein II: The New Colossus, das auf id Softwares eigenem Flash-ähnlichen Binärformat (idSWF) beruht. Er wiederholt einen früheren Durchlauf, der versehentlich die Dateien des falschen Spiels untersucht hatte, und stellt fest, dass 17 der 18 UI-Dateien komprimiert sind. Einfache HUD-Icon-Texturen lassen sich über den bereits bewiesenen Texturweg tauschen, die in den UI-Dateien selbst verpackten Grafiken aber noch nicht; alles ist statische Analyse, und ob ein neuer Menüeintrag erscheint, braucht einen Test im Spiel.

  • TNC hat 18 .bswf-UI-Dateien (Formatversion 31); liest man sie ohne Entpacken, erhält man überzeugend aussehenden Datenmüll.
  • Kapitel- und DLC-Menüinhalte sind normale, patchbare Decl-Daten; die UI-Dateien liefern nur benannte Container.
  • Etwa 1.700 HUD/GUI-Bilder sind normale Texturen; keines von 1.430 geprüften nutzt Virtual Texturing.
  • Der in jede UI-Datei eingebettete Grafik-Atlas ist blockiert: Für sein Format gibt es weder Leser noch Schreiber.
  • Die Dev-Menü-Datei debugmenu.txt existiert in keinem der 24 TNC-Archive.

Technical detailsTechnische Details

Der technische Teil ist auf Englisch – so, wie er im Wiki steht. Unterstrichene Begriffe haben eine Erklärung auf Deutsch.

This track investigates TNC's menu/HUD system, which is built on id Software's own closed Flash-like binary format (idSWF), asking whether a custom-map menu entry or HUD restyling is possible without an SWF bytecode writer. An earlier pass accidentally analyzed the wrong game's files entirely (a tooling default silently falls back to The New Order when both games are installed), and this pass redid the whole investigation against the real TNC archives, catching and documenting that mistake plus a second one — TNC's UI files are compressed and silently produce plausible-looking garbage if read without decompressing first. Everything here is static format/corpus analysis — the actual, still-open question of whether a new menu entry shows up on screen needs a real in-game test, already queued by a related report and unaffected by this pass's corrections.

Format

TNC has 18 distinct .bswf UI files (idSWF version 31 — a real, later format than the version 20 reported for the other game by the earlier mis-scoped pass). 17 of the 18 are Kraken-compressed; reading them without decompressing first produces data that looks plausible but is complete garbage (wrong magic, nonsense dimensions) — worth flagging as an easy trap for any future tooling touching these files. Unlike the other game, TNC embeds its bitmap/dictionary atlas data directly inside each (larger) .bswf file rather than in a separate sibling file — there is no separate atlas file to re-encode. The header's stage-size field (two big-endian floats) and a following frame-rate field hold corpus-wide once correctly decompressed: 14 files at 1920×1080, 4 at 1280×960, frame value 60 in 17/18 files (one file is a build-specific outlier at 61).

Chapter and DLC content is still plain, patchable decl data (chapter/chaptervariation) resolved through the normal patch-layer mechanism — the SWF layer only supplies named UI containers that compiled game code fills in. The real shell/main-menu file lists 29 named sprite containers (including a _absLeft_devMenu one) and contains zero console-variable-shaped strings in its text pool — the one coincidental substring match was proven by byte-context inspection to sit inside unrelated binary shape data, not a real reference. Per-screen, the number of individually-named "item" slots ranges from 4 to 46 across different screens, which looks more like each screen's own authored instance count than one shared list-length cap — but this is inference from file structure, not a read of the actual bytecode (no disassembler for this format exists in the project).

HUD restyling — two channels, very different outlook

  • Standalone icon/texture assets (the low-risk, already-proven channel): TNC's real GUI/HUD texture convention is textures/guis/.../textures/effects/hud/..., under which roughly 1,700+ image and similarly many material entries exist. A large sample (1,430 of them) was checked and none use virtual texturing — they're ordinary BC-compressed textures, the same pipeline already proven in-game for a weapon skin.
  • The embedded per-screen atlas inside each .bswf — this is where restyling actually touches the menu/HUD chrome itself, and it remains blocked: there is no reader or writer for the idSWF dictionary/bitmap-tag structure the atlas data lives in. The archive write mechanics themselves (compressing and writing back into the slot) are not the obstacle — the project's existing archive-writer code already round-trips this kind of compressed entry — only a format-level serializer for the embedded bitmap content is missing, and that is a substantially larger reverse-engineering project than re-encoding a sibling file would have been.

Dev menu — a dead end for TNC specifically

The file the project's existing dev-menu-unlock tooling injects into (debugmenu.txt) is absent from all 24 real TNC archives — the entire "dev menu exists, but the renderer isn't connected" finding documented for the other game simply doesn't apply here; TNC doesn't even ship the target file to test.

Open / needs a live test

  • Whether an appended chaptervariation entry actually appears as a selectable item in the chapter-select screen — the decisive, already-queued in-game test from the related DLC-ownership report, unaffected by anything in this pass.
  • Whether TNC's localization text tables (a different, encrypted container type than the plain text files the HUD-text-rewrite technique was proven against) support the same byte-length-exact rewrite trick — not attempted this pass.