Add the maps-tool.exe finding: the unlock pattern ships in mainstream tooling
A 9th confirmed instance of the testmode/0x0B3A unlock pattern, and by
far the most consequential: decompiling maps-tool-2.0.2.exe (the
single most mainstream SD-card map tool for this platform) found a
bundled minimal SWL disc template, tied by byte-identical VERSION.TXT
metadata to the already-documented 4120_testmode_tvfree build, whose
sole DLSCRIPT.TXT step runs a VIM.WSH copied in unconditionally by
the app's own code for every user -- no UI toggle, no opt-in. Every
prior instance required deliberately seeking out an unlock disc; this
one is silently part of using the tool for an ordinary map update.
Migrate the theft-protection/C166 and Sirius/NAR research threads to the wiki
A consistency audit found 2 major real research threads that existed
in research/swl_5238_reader.py (and, for one part, README.md) but had
NEVER been migrated to the wiki at all, across the project's whole
history -- not just this session. Moving them in fully rather than
just linking out, per direction to consolidate documentation in the
wiki.
New page: Theft-Protection-and-the-CAN-Gateway.md
- GATEWAY.FLI's complete TheftProtection_* state machine (string
level): status dump fields, diagnostic override interface, ITD_*
function family, a separate CodingShadow_*/CONFIG_FKTID_* coding-
sync protocol.
- A real ST10/C166 disassembler (hn/c166-dis) found and validated --
no capstone support for this chip exists.
- A real string-to-code cross-reference: found the actual diagnostic
override dispatcher, a disassembly-confirmed 50-retry limit, and the
real 0x5A55/0xA5AA EEPROM signature scheme -- all at the instruction
level, not inferred from strings.
- 7 real techniques tried to find the dispatcher's own caller, all
negative, including one caught-and-refuted false positive (a linear
sweep desyncing into a data table) -- a real, general lesson about
this architecture recorded so it isn't hit again.
- TpPvVerifyPin's real location in FHDD6.FLI (~82.6MB, the VxWorks/BSP
region) and the real ClusterID vehicle-pairing security design --
correcting an error in this session's own earlier wiki edit, which
wrongly said TpPvVerifyPin was "not in FHDD6.FLI" when the research
file clearly places it there by file offset.
- Consolidated (moved, not duplicated) the serial-console confirmation
and wiring diagram already added to HOST-BSP-and-Vehicle-Coding.md
last turn -- that page now points here instead of repeating it.
New page: Sirius-TravelLink-and-North-America-Discs.md
- The first 2 real North-America SWL discs: real part-number
prefixes, a SetCoding byte-7 refinement (a real enum, not a bool),
and the first confirmed case of the testmode register explicitly
OFF.
- SIRIUS.DB3, a real Sirius TravelLink SQLite database -- the map
disc's own POI.DB3 coordinate decoder applies completely unchanged.
- CHANNELARTSCACHE/*.DDB, a complete real image format crack (2-plane
BGR555+mask, visually confirmed against 3 real Sirius channel
logos), with the filename-to-database key cross-checked 3 for 3.
- A clean IBOC/HD-Radio negative result across all 5 discs on hand,
and a 4th independent cross-build confirmation the 9MB+ FHDD6.FLI
disassembly wall is structural, not EU-specific.
Also: added the "other ECU images" first-pass findings (DAB.FLI's
real TI DSP identity) to the boot-chain page, and flagged (without
attempting a full migration) that Map-Viewer-Tool.md's own changelog
is stale relative to README's -- a separate, large body of app
changelog content, different in kind from these RE findings.
Consistency fix: FILE_UPDATE wasn't new, and document the missing HDD_20GB use
Cross-checking against README.md found 2 real problems with the
FILE_UPDATE/LOAD_ECU_BLOCK section just added:
1. The framing implied FILE_UPDATE itself was newly found this
session. It wasn't -- README.md's own §2.6 already documented
FILE_UPDATE from an earlier session, in a different real context
(HDD_20GB's DLSCRIPT.TXT copying SPEECH/*.ZIP voice packs onto the
unit's own /hdb2/ hard disk, no ECU flash involved). Only
LOAD_ECU_BLOCK, and specifically the FILE_UPDATE+LOAD_ECU_BLOCK
pairing for direct-to-ECU flashing, is actually new.
2. That HDD_20GB finding itself was never added to this wiki page at
all, despite being real and already in README -- added it now, so
a reader sees the already-known plain-file-copy use before the new
ECU-flash use.
Document the BASE/ firmware trove: unlock pattern, SetConfig, BAP, K2L GmbH
Adds this session's findings from the large BASE/ firmware/tools
reorganization to the 2 pages that already cover this territory:
HOST-BSP-and-Vehicle-Coding.md:
- Resolves this page's own open question ("real PIN validation...
more plausibly... handled entirely by an external tester") --
TpPvVerifyPin is confirmed as a real, live VxWorks shell command,
found by decompiling a community .NET brute-force tool back to its
original C# source. Real wiring diagram recovered and embedded
(26-pin connector P/N N91-10930 -> DB9 serial).
- SetConfig-for-rns510.pdf (a real commercial coding tool's manual)
externally corroborates Theft protection/PIN verification/BAP as
real named coding options, plus a 3rd independent 800x480
confirmation and a literal "# by SetConfig" signature caught in one
disc's own DLSCRIPT.TXT.
- The real BAP wire protocol, recovered from working community C
source: frame framing, real CAN IDs per emulated MOST device, 2
function-ID catalogs, and a worked destination-injection payload
(with its fake placeholder coordinates proven fake, not decoded).
- PQTABLE.FLI/SKTABLE.FLI's real header format cracked: vendor
identified (K2L GmbH), version field decoded, exact 3-stage revision
history recovered for both tables.
SWL-Disc-Boot-Chain-and-Build-System.md:
- Adds the FILE_UPDATE/LOAD_ECU_BLOCK command family (real fixed ECU
flash addresses, a real double-flash official sequence) alongside
the already-documented INSTALL_FRAGMENT/LOAD_FIB.
- The testmode/speed-lockout unlock pattern, confirmed 8 times across
independent build pairs with zero exceptions; VIM confirmed as
Video In Motion; #CommentStart proven unreliable in both directions
including 2 "official"-labeled discs that actually carry the
pattern, found via a corpus-wide outlier sweep.
- FHDD.FLI, the confirmed real ancestor of FHDD6.FLI, found in the
oldest disc in the collection -- extends the existing FHDD4.FLI/
FDVD.FLI paragraph without contradicting it.
- WA/FIXCOD.WSH: a real, one-off leaked internal engineering artifact
(a 72-register table plus a dated bug-tracker comment naming a real
engineer) present only in the 3 earliest discs -- a 3rd independent
instance of the same TlaWtz# convention already documented from
CDSTRUCTTMP.CFG.
Record FHDD4.FLI/FDVD.FLI as confirmed unreachable with current discs
Checked all 3 real firmware discs directly: none ship these alternate
nav-firmware builds, only FHDD6.FLI. A different DVD-based or
older-generation SWL disc would be needed -- not routeable around with
files already on hand, so recorded to avoid re-chasing this lead.
Document SWL disc boot chain, HOST BSP, and vehicle coding
Adds 2 new pages covering everything reverse-engineered around
FHDD6.FLI this session: the real boot chain (bootloader -> BLSCRIPT.CFG
-> SWL.FLI -> DLSCRIPT.TXT -> A_HDD.FRG -> FHDD6.FLI), the .FRG ZZZZ
container format, the factory build-configuration system (USER.CFG,
INOUT.TXT, CDSTRUCTTMP.CFG), the HOST processor's own decompressed
VxWorks BSP (SSW_VW-RNS, Siemens VDO Automotive AG 2005), the real
/tffs0/lib/ filesystem tree (confirming Arriba/navcore.out/dbal.out),
and the full disassembly of the real UDS-based vehicle-coding protocol
(SetCoding/SetRegData/SetRegDataHex). Also adds a Firmware-Reversing
section on the 25-30MB service-dispatcher investigation.