SWL Disc Boot Chain and Build System

SWL Disc: Boot Chain and Factory Build System

This page is about the separate factory "Software Loading" (SWL) disc (VwSwIndex 5238, extracted at 5238_ALL) that flashes the RNS510 — not the map disc this wiki otherwise documents, and not FHDD6.FLI's own internal code (see Firmware Reversing for that). This page covers everything AROUND FHDD6.FLI: how the unit actually gets flashed, step by step, from cold bootloader to the finished install, and the disc's own build-system metadata. Reader/analysis code: research/swl_5238_reader.py.

Status: ✅ Disc identity, ECU tree, and every script/container format in the boot chain cracked (plain text or a fully understood binary container throughout — no proprietary encoding survives at this level).

Disc identity

VERSION.TXT: CdTreeBuilder version 3.06, build P 0 0 5 . 6 7 0 . 3 0 6, dated 2012-10-19, #Project: VWRNS, #VwSwIndex:5238. Lists 18 real VW part numbers sharing this build. #Steckbrief: C_EU_13.236_t3 C3/C4A/C5C/C6/C10/C12 — these are internal Continental hardware- revision codes for the head unit's own PCB (confirmed via INFO/CDSTRUCT.CFG's own #ifdef HARDWARE_C3/etc. blocks), not vehicle platform codes. #CommentStart: This is an unofficial SWL CD by josi. — this specific disc image is a community repack, a disclosed provenance detail (CRC.16 files throughout the tree would make any tampering detectable).

The full boot chain, traced end to end

bootloader (hardware ROM)
  -> reads BLSCRIPT.CFG (disc root)
  -> flashes + boots SWL.FLI (small bootstrap loader app)
       -> SWL.FLI reads DLSCRIPT.TXT (per project-variant)
            -> INSTALL_FRAGMENT installs A_HDD.FRG (a container/wrapper)
            -> LOAD_FIB writes FHDD6.FLI (the real navigation firmware)

BLSCRIPT.CFG — the bootloader's own config, one stage before everything else

Sits at the disc ROOT (one per disc, not per project variant). Its own header comment states its role directly: "The BlScript will be parsed by the bootloader only... It describes the process how to load the right SWL application."

Real, fully self-documented grammar: a [FORMAT] section defines HW_INFO = <AREA ID>.<GIID> and LOAD = <CUSTOMER_PRODUCT_ID>.<HW_MODULE_ID>.<HW_VERSION BEGIN>.<HW_VERSION END>; a [HW_INFO] block names 3 real hardware registers (HW_MODULE_ID = 01.08, HW_VERSION = 01.01, CUSTOMER_PRODUCT_ID = 01.07); then wildcard-matched sections ([0x000201XX.0x00010002.0x00000000.0xFFFFFFFF], 4 total on this disc) select a script body by detected hardware. Each body draws a progress screen (BAR/TEXT/PROGRESS_BAR, pulling live version text straight out of VERSION.TXT's own #CD:/#DATE: fields), then LOAD_FLASH_IMAGE //cddos/SWL/SILVER_1/RNSMIDEC/SWL/SWL.FLI, SET_BOOT_MODE 0x12 (twice), REBOOT. All 4 sections on this disc run an identical body — they only differ in which hardware IDs select them.

DLSCRIPT.TXT — the real flash-programming script language

Each project variant's own CONFIG/DLSCRIPT.TXT (plain text) is what SWL.FLI interprets step by step once booted. Confirmed real commands:

BOOTMODE_SWL
SHOW_SCREEN <flag> <id> <screen-name>
EXPECTED_TIME <seconds>
RUN_SHELL_SCRIPT <flag> <byte-size> <path.WSH>
INSTALL_FRAGMENT <flag> <byte-size> <path.FRG>
LOAD_FIB <flag> <byte-size> <path.FLI>
LOAD_LIBRARY <flag> <byte-size> <path.OUT>
UPDATE_SYS_CONFIG
COMPARE_REG_ID <reg> <mask> <value> <goto-label-if-match> <default>
GOTO <label>
<label>                    -- a bare identifier line is a jump target
VALIDATE_TFFS
FILE_UPDATE <flash-path> <byte-size> <disc-path>
LOAD_ECU_BLOCK <ecu-address> <byte-size> <flash-path>
FINISHED_ECU

FILE_UPDATE itself is not new — it's already used elsewhere on this disc for a plain file copy, no ECU flash involved: HDD/HDD_20GB/RNSMIDEC/CONFIG/DLSCRIPT.TXT (the HDD ECU target has no .FLI/.FRG payload of its own, just 2 variant DLSCRIPT.TXTs — NO_HDD's is a no-op) runs a MULTI_VERIFY_HDD 3 3 50 2 25 3 25 0 0 integrity check (numeric parameters not decoded), then 22 plain FILE_UPDATE <dest> <size> <src> commands copying every SPEECH/ *.ZIP voice pack onto the unit's own internal hard disk, e.g. FILE_UPDATE /hdb2/speech/parts/uvo_csCZ_01.zip 16746861 /cddos/ SPEECH/UVO_CZ.ZIP — confirming a real on-unit filesystem mount point, /hdb2/speech/..., and the real locale-code-to-disc-filename mapping for all 14 UVO_*.ZIP packs. What IS new is LOAD_ECU_BLOCK, and specifically the FILE_UPDATE+LOAD_ECU_BLOCK PAIRING — a 2nd, distinct real use of the already-known FILE_UPDATE command, staging a file into the unit's own local flash filesystem (the same real /tffs0/ root the WA/*.WSH scripts reference — see HOST BSP and Vehicle Coding) and then writing it straight to a peripheral ECU's own flash at a real, fixed numeric address — confirmed identical across every variant checked: LOAD_ECU_BLOCK 131242 884736 .../GATEWAY.FLI and LOAD_ECU_BLOCK 65706 8192 .../PQTABLE.FLI (the gateway/VUCI ECU — see HOST BSP and Vehicle Coding for what PQTABLE.FLI turned out to be), and — a real, concrete structural fact — the MPEG ECU's own addresses are each exactly ONE MORE: LOAD_ECU_BLOCK 131243 .../MPEGAPPS.FLI, LOAD_ECU_BLOCK 65707 .../MPEGSWL.FLI, consistent with a shared flash-address numbering convention across ECUs on this platform (not decoded further — no claim about why they're adjacent).

The real official flashing sequence for the gateway ECU flashes GATEWAY.FLI+PQTABLE.FLI TWICE — once before GWBOOTL.FLI (the gateway's own bootloader), once again after — while at least one real community repack does each only once. Real EXPECTED_TIME values recovered per step: GATEWAY.FLI 150s, PQTABLE.FLI 30s, GWBOOTL. FLI 90s — a genuine ~3-minute difference in total flash time between the two real sequences seen. Plausibly a real official reliability measure (re-flashing gateway+table after its own bootloader changes, to guard against an inconsistent state) that a repack strips to save time — not verified against real hardware.

Every <byte-size> argument matches the real on-disc file's exact byte size (cross-checked: LOAD_FIB 20 85658916 .../FHDD6.FLI against the real file's 85,658,916-byte size, exact). One representative file (APPS/SILVER_1/ET5PQDB/CONFIG/DLSCRIPT.TXT) shows the whole sequence concretely: boot into SWL mode, clear old language data (DEL_LANG.WSH), INSTALL_FRAGMENT A_HDD.frg (85,254,064 bytes), LOAD_FIB FHDD6.FLI (85,658,916 bytes), UPDATE_SYS_CONFIG, load a diagnostic test library (CTEST.OUT — see HOST BSP and Vehicle Coding), run FIXCOD.WSH, then a COMPARE_REG_ID 0x091C 0x09 <lang> <label> de branch chain — a real per-language decision tree that installs exactly ONE of 14 LANG_XX.FRG+RECOG_XX.FRG fragment pairs (German, English x2, Spanish, French, Portuguese, Italian, Czech, Dutch, Swedish, Turkish, Polish, Norwegian, Russian, Arabic) based on a real detected hardware/config register value — confirming 0x091C is (part of) the real on-unit language-selection register.

.FRG — CRACKED: the fixed 64-byte ZZZZ container, and its embedded sub-script

Every .FRG file (A_HDD.FRG for APPS, every HOST\...\H_*.FRG variant) opens with the SAME fixed 64-byte header, validated exact across 5 independent files spanning 2 ECU targets and a 94x size range, as 16 big-endian uint32 words:

Word	Offset	Value	Meaning
0	0	0x5a5a5a5a	"ZZZZ" magic
1	4	0x7d020100	constant, format/version tag
2	8	36	this header's own byte length
3	12	CRC-CCITT (XModem)	of the payload
4	16	1	constant
5	20	filesize - 36	real payload size
6	24	99 (HOST) / 160 (APPS)	per-ECU-target constant, not size-derived
7	28	1	constant, = word4
8	32	= word5	exact duplicate
9	36	0x69696969	"iiii" marker
10	40	33554432	constant
11	44	1	constant
15	60	16	constant

word5/word8 = filesize - 36, validated exactly across A_HDD.FRG (85,254,064), H_PQEE.FRG (1,286,592), H_SB_HDD.FRG (1,855,592), H_AK.FRG (1,286,592, note: same size as H_PQEE.FRG but a genuinely different file), H_SE_DAB.FRG (994,140) — zero exceptions. The CRC field was identified by noticing it never exceeds 16 bits despite a 32-bit field — a real CRC32 wouldn't do that by chance across 5 independent files.

Right after the 64-byte header, every .FRG embeds its own short, real, plain-text script — a genuinely separate command vocabulary from DLSCRIPT.TXT's own:

INSTALL_IMAGE 15
INSTALL_IMAGE 23
INSTALL_ALL_LOG_DB
SET_LOG_DB_STATUS 2 2
STORE_FRAGMENT
FINISHED_FRAGMENT

INSTALL_IMAGE 15/23 write two separate flash images (a bootstrap + main pair, or dual-bank redundancy); INSTALL_ALL_LOG_DB/ SET_LOG_DB_STATUS 2 2 install and initialize the unit's persistent diagnostic/fault-log database — real, HOST-owned platform responsibilities, not application logic. Immediately following this script: a real VxWorks 5.5.1 build banner ("Sep 25 2012, 11:33:51", "Copyright 1984-2001 Wind River Systems, Inc.") confirming the separate HOST processor runs its own VxWorks image (same RTOS version as APPS), with zlib linked in — see HOST BSP and Vehicle Coding for what that zlib turned out to hide.

Disc structure — a real ECU-by-ECU flashing tree

ECUORDER.TXT lists the real flashing order: APPS/HOST/HDD/ RADIO/MPEG/SPEECH/DAB/VUCI, matching the top-level folder names exactly:

Folder	Role
APPS	main head-unit application processor (navicore/Java/VxWorks)
HOST	a separate "host" platform-layer processor (boot, drivers, PCI/flash/video-mux, fault-log — see HOST BSP and Vehicle Coding)
HDD/RADIO/MPEG/DAB/VUCI	peripheral ECUs (hard disk controller, radio tuner, MPEG/video decoder, DAB tuner, MOST-bus/CAN gateway)
SPEECH	TTS/speech-recognition fragments, per-language
WA	shared shell scripts + one diagnostic ELF tool — see HOST BSP and Vehicle Coding
INFO/config	build metadata (below)

Every leaf project folder (e.g. APPS/SILVER_1/EURPQEE/) holds only a CONFIG/DLSCRIPT.TXT + CRC.16 — flashable payloads live in a SHARED location (APPS/SILVER_1/RNSMIDEC/PROG/), referenced by path, not duplicated per variant.

HWIDMAP.TXT (<12-digit hex ID> <hardware name>) maps a detected hardware ID to SILVER_1/SILVER_6. PRJCTMAP.TXT (<8-digit ID> <variant folder name>) maps a per-vehicle configuration ID to one of ~15 project-variant folders — EE/WE = East/West Europe, SK = Skoda, SB = Skoda Superb (independently confirmed twice below), T5/TO/PQ/AK/DAB = real VW platform/hardware-option codes. Every CRC.16 file (119 occurrences disc-wide) is a real per-directory integrity checksum.

A first pass over the other, previously-untouched peripheral ECU images found one genuinely new architectural discovery: DAB\1\RNSMIDEC\PROG\DAB.FLI's own real, clean startup banner ("DSPLink Version: dsplink_sla_1_62_02", "PSP DRx40x: Version 1.1.4.3", "EDMA3 driver used: Version 1.05", "Starting J2VIS. Build Date: %s, Time: %s", dated "Mar 2 2012, 13:55:04") confirms the DAB digital-radio tuner runs on a Texas Instruments DSP — DSPLink/EDMA3/PSP are real TI DSP/BIOS ecosystem terms — a 3rd distinct processor architecture in this whole system, alongside PowerPC/VxWorks (APPS/HOST) and the ST10F276E/TMS470 satellite MCUs (see Theft Protection and the CAN Gateway). VUCI's GATEWAY.FLI shows real "NO_BOOT"/"ipcRP_uart" strings (an inter-processor-communication-over-UART mechanism); RADIO.FLI references a 3rd-party osAbsLayer.c framework distinct from the navicore codebase; MPEGAPPS.FLI showed no clear identifying strings in this first pass. None of these 4 show any .cpp/.h debug-string paths at all, unlike FHDD6.FLI/CTEST.OUT — consistent with different (non-Siemens/Continental) codebases or debug-stripped builds. Not investigated further; real, open, low-priority leads for a future session.

The first 2 real North-America-market discs (opening up several subsystems only ever known by reference until then, including a complete Sirius TravelLink database/channel-art crack and a real IBOC/HD-Radio negative result) are covered on their own page: Sirius TravelLink and North America Discs.

INFO/ — the real factory build-configuration system

INFO/CDSTRUCT.CFG (25,955 lines) is the top-level build/flash ORCHESTRATION script — #ifdef/#else/#endif-guarded, choosing which ECU targets to flash per build configuration.

INFO/USER.CFG (184 lines) is the REAL, filled-in build- configuration input for THIS SPECIFIC disc:

• Its own header names real contacts: "If changes are needed please contact David Yates or Torsten Hildebrand." This disc's own <AUTHOR>: RoNe.
• <VERSION_FILE_HEAD>: "Software Loading CD for CP2 based units / (c) CONTINENTAL Wetzlar" — Continental's Wetzlar, Germany site (the former Siemens VDO Automotive location) confirmed as the real build facility.
• <LOGISTIC_DATA>: #Integrationphase: Delivery cw45/12 C10/C12/C6-samples — this disc was a calendar-week-45-2012 delivery of hardware SAMPLE units for the C6/C10/C12 revisions specifically.
• A large <PREDEFINITIONS> block is the real, filled-in #ifdef flag set driving CDSTRUCT.CFG. Confirms EUROPA=1/NORTHAMERICA=0/ JAPAN=0/CHINA=0 (Europe-only build) and a complete per-vehicle- platform flag list (PQ, SK, SE, SB, PH, T5, BY, BM, PHGO, AK, NAR-only TH/GN/CH184, China-only NMS/ECAR). Real per-feature flags: 40GB_HDD=1 (this variant's real HDD capacity), TRAVELLINK=0 (a real traffic/content service, present as a build option), IBOC=0/MPEG=0 (both real options, disabled on this disc), a VUCI section (VUCBL, VUC_HEAL).

INFO/INOUT.TXT (236 lines) is the build tool's own master file manifest — maps every internal build-tree source path to the short on-disc filename this project works with elsewhere. Surfaces several subsystems never otherwise mentioned:

• BL_VW.FLI <- SSW\SF_INTEGRA\cp2\bin\flash\ppc\fli\bootloader.fli — SF_INTEGRA is the real internal platform codename.
• Per-vehicle-platform CAN gateway routing tables (PQTABLE.FLI/ TOTABLE.FLI/SKTABLE.FLI/PHTABLE.FLI/T5PQTBL.FLI/ T5TOTBL.FLI, each really named GWTABLE.FLI in its own platform-specific source folder).
• Regional radio tuner firmware: RADIO.FLI (Europe), NARRADIO.FLI (North America), JAPRADIO.FLI (Japan).
• IBOC.FLI — In-Band On-Channel, the North American HD Radio standard. Never examined.
• A parallel DVD-based nav-firmware line (FDVD.FLI, FSE_DVD.FLI) alongside the already-studied HDD line (FHDD6.FLI/ FSE_HDD.FLI/FSE_HDD6.FLI), plus an older generation, FHDD4.FLI. Checked directly, a later session (motivated by the multi-session FHDD6.FLI 9MB+ disassembly wall — see Firmware Reversing — hoping an alternate build might be less stripped): NEITHER exists on any of the 3 real firmware discs this project has (5238_MOD_C3_C4, 5274_MOD_C6_C12, 6276_MOD_C14 — the same 3 builds already cross-checked on the Firmware Reversing page). Every one of them ships only FHDD6.FLI + A_HDD.FRG in PROG/, consistent with USER.CFG's own PROJMAP_EU_PQ_DVD=0/ONE_FIB=1 flags (above) selecting the HDD-only line for these specific builds. FDVD.FLI/FHDD4.FLI are real entries in the build system's own master manifest, but a genuinely different, DVD-based or older-generation SWL disc would be needed to actually open one — not something a future session can route around with files already on hand. Update, a later session, a large new firmware-build trove added under BASE/: the OLDEST disc in the whole collection (900, VwSwIndex 0900, 2008-05-29) ships FHDD.FLI — no "4", a genuinely different filename from FHDD4.FLI above, and NOT the same file being found — but a real, confirmed direct ancestor of FHDD6.FLI (73,877,728 bytes, smaller than every FHDD6.FLI checked; the real 800×480/VxWorks/tShell strings are already present). The FHDD.FLI → FHDD6.FLI rename happened sometime between 900 and build 1100 (2008-11-26) — not narrowed further, and FHDD4.FLI/FDVD.FLI themselves remain genuinely absent from every disc this project has, even after this much larger BASE/ trove.
• CCC_NAVP.FRG/CCC_NAVP_BY.FRG <- JNAV\CCC_navp.frg — a separate Java-navigation-specific fragment, distinct from FHDD6.FLI. Never examined.
• SIRIUS.DB3 <- SIRIUS\NA_SIRIUS.DB3, plus MDSIRIUS/DELSIR management scripts — a SiriusXM satellite radio database, North-America-specific. Never examined.
• RVCLOW.WSH — a rear-view-camera-related script; ties directly to the cpdrVideoInSetSource ... RVC video-input source found in the HOST BSP (see HOST BSP and Vehicle Coding).

INFO/CDSTRUCTTMP.CFG (4,853 lines) is an earlier draft of the final CDSTRUCT.CFG, with a longer, more detailed leading changelog: a real, dated (2006-2008), named-engineer log (AKls/m./y./MaRu/ AKr) giving actual context for bug IDs otherwise only known as bare numbers — TlaWtz#46435: "an additional Restart_System is entered in front of RADIO"; TlaWtz#47169: caused a COD_BAP workaround to be REMOVED. "080213-MaRu: adapted for EUR SB (Skoda Superb) with GW Tbl from SK" — independent confirmation SB = Skoda Superb. A real //ECUORDER parameter comment: 0 1 = user input required (OK/ CANCEL), 1 1 = no user input.

INFO/HISTORY.TXT: confirmed genuinely empty, 0 bytes.

A 3rd, independent TlaWtz# instance found in the oldest disc's own WA/FIXCOD.WSH (see the FIXCOD.WSH section below) — the same real internal bug-tracker convention as TlaWtz#46435/#47169 above, naming a real Continental engineer directly: #PR: 070720: wieder rausgenommen, wegen: TlaWtz#42671 und Mail von Ingo Georg Felzer ("taken back out again, because of: TlaWtz#42671 and an email from Ingo Georg Felzer"). Not decoded further (ticket content, register 0x25 it's attached to) — recorded as a 2nd real source confirming TlaWtz# and named-engineer references are a genuine, recurring internal process artifact on these discs, not a one-off.

The real "unlock" pattern — confirmed 9 times across the whole BASE/ trove, including inside mainstream tooling

A large later addition to this project (BASE/, reorganized firmware/ tools) let this page's own tree-diffing technique be applied directly to real community "unlock" discs, instead of only inferred from .WSH script content in isolation. Diffed every same-VwSwIndex-and- date official-vs-unofficial pair findable in the collection (4120, 5270, 5269, 5274×2, 5238, 3810/3810a, plus a 6276 pair caught by a corpus-wide sweep below) — every single one shows the exact same pattern, zero exceptions:

- # Testmode: NOT active
- SetRegDataHex(0x21,"00",0x0,0x1,0x1)
+ # Testmode: Active
+ SetRegDataHex(0x21,"01",0x0,0x1,0x1)
+
+ # Speed limit DVD/TV: 300km/h
+ SetRegDataHex(0x0B3A,"012C",0x0,0x2,0x89)

— the exact 2 registers already documented on HOST BSP and Vehicle Coding (0x21 testmode, 0x0B3A speed lockout). Consistently accompanied by: the "unlocked" disc declaring a BROADER real hardware scope in its own VERSION.TXT (C3/C4A/C5C/C6/C10/C12 vs. the narrower official C10/C12), the official disc shipping RADIO/1/RNSMIDEC/PROG/ RADIO.FLI genuinely ZEROED (0 bytes), and HWIDMAP.TXT/PRJCTMAP.TXT sizes tracking that narrower scope directly.

VIM = Video In Motion, confirmed directly: BASE/Other/ VIM_Berto89 is a tiny, complete, standalone SWL disc (5 files + one WA/VIM.WSH script) whose ENTIRE payload is this exact 2-line patch — the file is literally named VIM.WSH. Confirms VIM throughout this whole family of community releases (including a disc actually named 5270_VIM_testmode) is the well-known aftermarket term for bypassing the "no video while driving" lockout, not a vehicle-identifier acronym.

#CommentStart is proven unreliable as a signal in BOTH directions. 5270_original (named "original") carries the "unofficial SWL CD by josi" disclaimer and is the EARLIER, broader- scope build; 5270_VIM_testmode (named "testmode") carries the official "VW delivery" text and is the LATER, narrower, more official-looking build — folder names and the comment string both point the wrong way here. Going the other direction: a cheap corpus-wide grep sweep (grep -rl "Testmode: Active" */WA/, no pairwise diffing needed) across every remaining un-paired build found 2 discs whose VERSION.TXT claims "VW delivery" but which actually carry the full unlock pattern — 6276_MOD_C14 (a real, later official-looking revision of 6276_original_update, same hardware scope, only 19 of 1,303,600 real firmware-image bytes differ between the pair — almost certainly a build stamp, not code) and 5218 (a completely plain-named folder, no _MOD_/_josi hint at all). One tempting explanation — that -samples-suffixed #Integrationphase strings might mark legitimate testmode-enabled internal builds — was tested directly against 6 confirmed testmode-INACTIVE discs and found to be universal boilerplate, unrelated to testmode status; ruled out, not just unconfirmed. 5218 carries a 2nd, independent anomaly: its MPEG/1/RNSMIDEC/CONFIG/DLSCRIPT.TXT is missing the CYCFLAG1.TXT/CYCFLAG0.TXT (dlpSetCyclicFlag 1/0) bracket every other build sets around its MPEG flash step — a real, likely dirty- flash/power-loss-recovery mechanism 5218 skips entirely. The real explanation for either "official-labeled but modified" disc (relabeled repack vs. a genuinely leaked/internal factory build) remains open — neither is provable from disc content alone.

A 9th, significantly more consequential instance: this pattern ships inside maps-tool, the single most mainstream, currently-recommended SD-card map-loading tool for this whole platform (see ISO Container Handling for the tool's own real, unrelated region-check/DVD-deployment behavior) — found by decompiling maps-tool-2.0.2.exe (a real self-executing JAR, Apache- 2.0; CFR + a winget-installed JDK, since this project never had a JVM before). A bundled resource, sd_to_hdd_fw.zip, is a complete, real, minimal SWL disc — its own VERSION.TXT is byte-identical (VwSwIndex 4120, same #CD:P/date/author) to 4120_testmode_tvfree above, except its #CommentStart reads the innocuous "Copy map from SD card to HDD." — a 3rd real instance of #CommentStart being unreliable, and the most consequential one so far. A real NameMapper class in the tool's own decompiled code confirms exactly ONE file gets copied into the disc's WA/ folder for every user, unconditionally, with no UI toggle anywhere in the app: VIM.WSH — the same 0x21/0x0B3A pattern, fused into the same script as the real SD-to-HDD copy shell procedure (sp xcopy("/sda/mapsdvd","/hdb2/dvd") — /sda, a real, newly- confirmed VxWorks mount point for the SD card itself). The disc's own DLSCRIPT.TXT runs nothing else — RUN_SHELL_SCRIPT 0 845 /cddos/WA/VIM.WSH is its entire payload. Every prior instance of this pattern required a user to deliberately seek out an "unlock"-branded disc; this one is silently part of using this tool for a completely ordinary map update. No claim made about the tool author's intent — only about the real, decompiled behavior. Full writeup, including the real CD_8048/CD_8049 special-casing this same decompile confirmed at the code level: research/swl_5238_reader.py, search for "maps-tool-2.0.2.exe".

WA/FIXCOD.WSH — a real, one-off leaked engineering artifact in the oldest disc

Present, same filename, in literally every firmware build this project has examined (31 builds spanning 2007-2014) — but 7,050 bytes in 900/1020_1022/1024 (the 3 EARLIEST discs — 1020_1022/1024 both dated 2007-12-20, actually predating 900's 2008-05-29 despite a numerically smaller-looking index; VwSwIndex order is not chronological, worth remembering generally) vs. exactly 253 bytes in literally every other build checked, 1100 (2008-11-26) onward through 6276_original_update (2014-03-20) — permanently stripped within about 11 months of the collection's earliest disc, and never restored.

The 253-byte version every later disc ships keeps only the 2 real cleanup lines already covered above (/tffs0/lib/ — Arriba/dbal.out and /tffs0/data/fwdir/bundles/4). The REMOVED content is a real, large, structured table: SetRegDataHex calls for every register from 0x0AC4 through 0x0B0B (72 consecutive registers, 30 bytes each), in repeating ~12-register blocks whose content is near- identical except one trailing counter byte that increments once per block — consistent with (not confirmed as) an enumerated per-item lookup table. Not decoded at the field level. Immediately preceding it, the real TlaWtz#42671/Ingo Georg Felzer comment quoted above survives verbatim — the single most direct piece of real internal Continental engineering process evidence found on any disc this project has examined, attached to a SetRegData(0x25,...) call that's itself commented out even in 900.

Reproducing this work

All plain text — no tooling needed beyond a text editor. research/ swl_5238_reader.py's own module docstring has the full narrative and every validation number: search for "BLSCRIPT.CFG", "INOUT.TXT", "USER.CFG", "CDSTRUCTTMP.CFG", ".FRG"'s own container section, "4120_original vs 4120_testmode_tvfree", "5270_original vs 5270_VIM_testmode", "VIM_Berto89", and "FIXCOD.WSH is a REAL, UNIQUE, one-off artifact". outlier_sweep.py/outlier_sweep_hash.py (referenced in that same docstring, saved to the session scratchpad, not committed to this repo) implement the corpus-wide minority-outlier sweep used to find the 5218/6276_MOD_C14 anomalies above — a reusable technique: group every recurring file path across all builds, flag paths where all but 1-3 builds agree.