Document DBAL.OUT full decompilation, research/dbal.py, and the definitive external-reader confirmation
Crack all remaining eeu.rd header bytes via eeu.mod's own binary field descriptors + DBAL.OUT disassembly
Disassembled db_road.cpp's read_current_record_from_database in DBAL.OUT
to get the real field read order and names (countryID, cityID, prefix,
suffix, rdtype, roadinfo), confirming delta_long/delta_lat get converted
to a max-corner on read. The real unlock was eeu.mod itself: its binary
bytes (not just the field-name strings already extracted) carry a real
per-field width/bit-offset descriptor, cracked this session and
validated byte-exact against eeu.ctr's own known layout.
Applied to eeu.rd's schema block and validated against real file data:
cityID (bytes[1:4], 24-bit) shows 50.3% same-value match among
geographically nearby records vs ~0.025% expected by chance; typeID
(bytes[5:7]) ranges 0-2571, matching eeu.typ's 2,574 real entries almost
exactly; roadInfo bit0 (highway) correlates with route-like names at
89.95% vs 0.10%; suffixID/prefixID (byte[0]'s two nibbles) are
independent and both span the full 0-15 range. All 8 previously
unresolved header bytes are now accounted for, with zero bits wasted in
the roadInfo byte's 6 packed sub-fields.
Crack eeuz.fea's relative point-geometry format via real DBAL.OUT disassembly
Disassembled db_feature.cpp's real handler chain (db_fea_read_parcels_V005
-> parseExtractedParcel -> FeaCoordReceiverInternal::getCoordinates())
using capstone plus a hand-rolled ELF relocation-table parser to resolve
every global reference to its real linker symbol name. Fully cracked the
per-point delta format: 4-byte records (int16 BE dx, int16 BE dy),
cumulative 16-bit accumulators, each point scaled by a per-layer factor
from a FeaLayerPropertiesInternal struct.
Also found strong, disassembly-proven evidence that the absolute anchor
is NOT part of this decode path at all: init()'s own code zeroes the
accumulators and stores its 2 float params into fields getCoordinates()
never reads (traced to an accuracy/unit-conversion ratio, not a
coordinate). Combined with the type's own name (LocalPoint, not
GeoPoint) and this project's already-exhaustive refutation of any
absolute coordinate embedded in entry bytes, the most consistent
reading is that an external caller (likely rendering code, using a tile/
viewport position it already has) supplies the real anchor -- meaning
further progress may require tracing into FHDD6.FLI, which has its own
known disassembly wall.
Crack eeu.iof's type field via real DBAL.OUT disassembly
Disassembled 5 real functions (unpack_intersection_offset_rec,
db_get_minor_road_list_type/_offset/_count, db_get_crossstreet_offset)
directly from dbal/V010_015/DBAL.OUT using capstone -- this small
unlinked ET_REL object has full .text content in-file, unlike FHDD6.FLI's
disassembly wall. Confirms the real struct IOF_Record and the real
in-memory field mapping, and cracks type's actual role: a validity gate
(type must be 0 for offset to be valid) plus a tri-state cache-resolution
flag (type==1 means the stored count is provisional and gets recomputed
from a live IntersectionList cache). Also refutes the natural "type
selects minor-road vs cross-street list" guess -- cross-street lookups
go through a completely separate in-memory hash cache.
Crack eeu.rd's delta_long/delta_lat: a real segment bounding-box extent
eeu.mod's own schema names this table's real fields in order:
...min_long, min_lat, delta_long, delta_lat, name... -- min_long/
min_lat sit exactly where the already-verified longitude/latitude
fields are, putting delta_long/delta_lat exactly at the 2 fields
previously listed as "unresolved, small values" (bytes[16:20]/[20:24]).
Validated at real scale (20,000-record random sample across the whole
8.8M-record file): zero negative values for either field, implied
segment diagonal median 350m / mean 1.1km, 96.8% under 5km, 99.9% under
50km -- exactly the real-world range of named road-segment lengths.
Also checked the firmware side directly (user asked specifically):
dbal confirms real db_road.cpp/db_road_list.cpp/db_road_cache.cpp/
db_road_sel_char.cpp source files and one accessor
(db_road_NameListDataByIndex_V004), but unlike eeu.si's rich db_seg_*
catalog, no further per-field road-classification accessors were found
-- the firmware confirms the handler exists but doesn't hand over a
field-by-field breakdown. The remaining 14 eeu.mod field names
(cityAndCountryID through interchange) packing into 8 still-unresolved
bytes remains open; highway as a single bit of byte[0] tested and
refuted (zero correlation with route-like names across all 8 bits).
New page: RNS510 Serial Console command reference
The actual request: a consolidated reference of every real command
the RNS510 head unit itself understands over its own serial debug
console (the VxWorks tShell documented on the Theft Protection page),
not a 3rd-party device's protocol.
Pulls together commands already scattered across 3 narrative pages
into one scannable reference, organized by real source:
- The SetCoding/SetRegData*/ReadRegData/DeleteRegData/SaveRegData
family (CTEST.OUT, fully disassembled) plus every real
register/coding-array value confirmed this project-wide (testmode,
speed-lockout, manufacturer, HDD/tuner/DAB/SDARS/MPEG flags).
- TpPvVerifyPin (confirmed live).
- Real VxWorks shell built-ins (ld, sp, rmdir, mkdir, cd, copy,
IL_Flush, dlpSetCyclicFlag) with a real example line pulled from an
actual flashed script for each, plus the real confirmed mount points
they operate on (/tffs0, /hdb2, /sda).
- version/help, and one real, honestly-unresolved command ("x68")
rather than a guessed-at explanation.
Explicitly scopes out what this page is NOT about (DLSCRIPT.TXT/
BLSCRIPT.CFG's own command sets, the gateway's register-override
mechanism, BAP) so it doesn't get confused with those real but
different command vocabularies documented elsewhere.
Remove the rns510_dtv-master protocol page -- out of scope
Misread the request: the ask was to document the commands the RNS510
head unit itself understands, not a 3rd-party retrofit box's own
separate protocol. Removed the dedicated page and its cross-links;
condensed the HOST-BSP mention back to a brief correction note
without re-detailing a protocol this wiki isn't meant to cover.
New page: the rns510_dtv-master serial protocol, fully documented
Dedicated page for the real custom RS232 protocol found in the DVB-T
retrofit box's own source (not BAP, despite the class names).
Went back through the whole application (not just QMostInterface.cpp)
to find every real command actually in use: the 3 outbound commands
already found (device status, send service-list entry, set channel
position), plus the full real inbound command set recovered from all
3 separate onCanRecieve() handlers (QMostTvList.cpp, QTvList.cpp,
QMostMediaPlayer.cpp) -- 0x80-0x8b, including a context-dependent
multiplexing scheme where the same leading byte means a different
real action depending on which UI screen is active, and a complete
remote-control relay (UP/DOWN/OK/EXIT/MENU) under command 0x89.
Condensed the existing inline protocol description on
HOST-BSP-and-Vehicle-Coding.md into a pointer here, to avoid
duplicating the same material across 2 pages.
Add the Road Editor page, fix a stale status, and fill the geo-index gap
New page: Road-Editor-Tool.md -- rns510_gui.py (the actual editing
tool that writes real changes back to a real ISO) had zero dedicated
wiki documentation; only ever mentioned in passing on other pages.
Migrated README's own #6/#7: features, how to run it, and the
"what's solid vs. experimental" table (critical reading before
trusting any real edit).
Fixed a real stale/wrong status label: MAP_COMPRESSED-Container-
Format.md said the geo-index prefix was "not cracked" at all -- long
out of date. It's actually architecture-identified (a real R-tree,
confirmed via firmware disassembly: MDCacheTIRTree/findNode/
enlargeMBR/etc.) and ~42-46% byte-decoded via scan_native_geo_hints(),
validated against build_bbox_index()'s own bounds on 2 independent
files. Migrated the full story: the (tile_id, tile_id+1) finding, 4
refuted structural hypotheses, the confirmed max-corner-only
semantics, and the wire-in-then-honest-revert into the live viewer
(cross-linked to Map-Viewer-Tool.md's own changelog entry for that
part). Also documented build_bbox_index()/find_tile_for_coord_bbox()
(98% real-point resolution accuracy) as a 2nd practical workaround,
previously unmentioned anywhere in the wiki.
Enriched ISO-Container-Handling.md's SD-card section with the real
region-code gate and the actual button-combo procedure (previously
just pointed to README for these).
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.
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.
Add Firmware Reversing wiki page
New page documenting FHDD6.FLI reverse-engineering: the recovered load
base (VA = file_offset + 0xf688dcf4), the prologue finder, the real
symbol/EH-descriptor table, and 3 fully disassembled and understood
functions (getId__C26CfcMsgStreamedServicePoint, the unnamed mg4
seg_list-shaped record reader, and getNodeVidArmMP0). All disassembly
listings verified directly against script output to guarantee exact
branch targets. Linked from the sidebar and Home page.
eeu.tmc: crack the complete per-location byte-offset index (100% scale)
Mirrors the main repo's research/tmc_reader.py update. Every one of the
44 location tables' own location_offset_table_p/_n arrays (eeu.mod's
schema names) are now cracked: (no_of_locations + 1)-entry uint32
prefix-sum arrays of absolute file offsets, validated with zero
exceptions across all 44 tables. The whole file is self-consistent end
to end -- the last table's own table_n array independently computes to
end at the exact same byte (8,584,500) as the first table's own
table_p[0], and the last table's final offset equals the file's exact
EOF, both to the byte.
This maps 100% of the file's own addressing structure -- only the
deepest leaf chain records' own content (what's actually inside each
now-exactly-known byte range) remains undecoded.
eeuz.fea: find directory tables T3 and T4, resolve Turku/Trondheim/Oslo
Mirrors the main repo's research/feature_reader.py update. A whole-file
stride-12 self-similarity scan located 2 new directory-table regions
(T3, T4) in a few seconds -- T3 specifically indexes the 3 cities
(Turku, Trondheim, Oslo) previously confirmed absent from both known
tables, with an exact declen/complen match against real decompression,
3/3. Closes the prior session's own load-bearing negative finding
completely. A weaker 5th candidate region at EOF was found but doesn't
verify cleanly -- documented as unconfirmed, not claimed as a table.
eeu.iof: narrow anchor selection (route-numbered roads 7.5x enriched)
Mirrors the main repo's research/iof_reader.py update. Anchor names
(the 31,318 records with a "nearby street names" pointer) match a
route-code-like pattern (B215/SP246/L1-shaped) 44.80% of the time vs.
5.86% for non-anchors at full file scale -- a real 7.5x enrichment, but
not a clean 1:1 rule (only 2.66% of all route-like-named records are
anchors), consistent with anchors being a deduplicated subset rather
than one per road segment.
Also documents a 3rd count-field correlation hypothesis tested and
refuted: eeuz.rl's own per-eeu.rd reference count correlates slightly
NEGATIVELY with the common-case count (r ~ -0.08), the wrong sign,
despite covering 95% of eeu.rd vs. eeu.il's 8.4%.
eeu.si fully cracked: last 11 single-bit flags assigned by schema order
Mirrors the main repo's research/si_reader.py update: all 20 real
seginfo leaf fields are now positioned across the record's 5 real
bytes, in exact eeu.mod schema order throughout. The final 11
single-bit flags (toll_vignette, toll_road, hwy_complex_bit, landmark,
dbldig, detailedcity, urban, bifurcation_left, bifurcation_right, rnc,
truck_digitized) use the same in-order-packing technique already
validated for byte 0 and byte 4, corroborated for 2 of them by a clean
joint-exclusivity signature (rnc/truck_digitized never both set) and
for another 2 by a near-exclusivity signature (toll_vignette/toll_road,
0.15% co-occurrence). Explicitly tested and refuted a hypothesis that
dbldig tightly tracks the divided flag.
Status bumped 🟡 -> ✅ on eeu-si-Segment-Classification-Table.md and in
Home.md's status table and intro narrative; Unexamined-Files.md's
historical eeu.si entry updated to match and its stale "~5 distinct
patterns" eeu.rd claim corrected to the actual 6,174 distinct values.
Add eeu.tmc TMC Traffic-Data page; close out final wiki stale references
New page eeu-tmc-TMC-Traffic-Data.md documents the file header + 44-table
directory crack (code, offset_p/offset_n into the bulk payload), found
using ground truth from telemat/tmc2/TMCCONFIG.ini and dbal/'s own
embedded source-file list (db_tmc.cpp), mirroring README S3.25.
Home.md: added eeu.tmc as a proper Road network status-table row (was
sitting in the "Never examined" table); folded zone.cfg's resolution
into the intro text (it never belonged in that table — plain-text
config, not a files.cfg data file); renamed the section "Formerly
'never examined' -- now all resolved" now that every file on the disc
has been examined at least once.
Unexamined-Files.md: added the "Formerly 'still genuinely unexplained'"
section resolving both eeu.tmc and zone.cfg, with the closing statement
that all 1,535 files across db/ and the 5 disc-root subsystems have now
been examined.
eeu-mod-Database-Schema.md: fixed 4 stale table rows that still said
"still unexamined"/plain filename with no link (eeu.tmc, eeu.pmc,
eeu.pmm, eeu.pol, eeu.pot, eeu.pmp) -- all now link to their real
write-ups.
_Sidebar.md: added the missing eeu.tmc link under Road network.
Examine and document every remaining file on CD_8555
All 1,535 files on the disc now examined at some level:
- cdrom.toc/DBINFO.TXT: real manifests confirming every subsystem's
version stamp (TPD/SVD/TMC/DBAL dates all cross-confirmed)
- telemat/tmc2: TMCCONFIG.ini fully cracked; .et files confirmed real
TMC phrase text; .lt binary tables identified, not byte-cracked
- speech/: confirms the real TTS vendor (SVOX) and the actual embedded
RTOS (VxWorks) -- the first OS identification in this project. Real
dated Siemens VDO/SVOX license string (2005).
- dbal/: confirmed PowerPC ELF relocatable objects; ~330 real internal
source file names extracted, mapping almost 1:1 onto this project's
own already-cracked eeu.* files; independently confirms eeuz.fea's
hash-table directory from the source's own runtime log strings; real
dated bug-fix branch history
- tpd/ (1,443 files): confirmed a real embedded HTML destination-search
UI (CGI-style forms to a local web server), category hierarchy, icon
set, compressed search-index tables (header decoded, body not)
- EDB/POI/POI.DB3: PredefinedStatement embeds real SQL, confirming the
precompiled-statement architecture already inferred from firmware
Rewrites Disc-Root-Build-Script.md comprehensively, updates Home.md and
Unexamined-Files.md.
Document config/create_cd: the disc's own build script, plus EDB/POI.DB3 (4.7M real POIs)
config/create_cd is the disc's own mastering/build script, revealing:
- the literal origin of the EEU50530910.84 version string
- ZIP_3kb as the source tree's own real name for block_size=3072
- 5 never-examined disc-root subsystems: config, tpd, EDB, telemat,
speech, dbal
Opens and confirms EDB/POI/POI.DB3, a real standard SQLite database
with 4,733,183 real POIs, full addresses, and real brand-specific
category sets (main vw/seat/skoda/bentley) -- confirming this POI
database is shared across the whole VW Group. Independently confirms
eeu.mod's own 'Arriba' self-identification via the database's own
ClearCase build metadata (arriba2/arriba2_VW).
Also finds telemat/tmc2/TMCCONFIG.ini: real, standard ALERT-C TMC
location-table config for 14 countries, giving eeu.tmc (still
unexamined) a strong new lead -- a quick scan already finds a plausible
sequence of real ALERT-C Location Code numbers in its body.
Adds Disc-Root-Build-Script.md, updates Home.md, _Sidebar.md,
eeu-mod-Database-Schema.md, Unexamined-Files.md.
Fully crack eeuz.prd: minNumber/maxNumber is a real house-number address range
eeu.mod names the table phRoad with real fields graphem/phonem/roadID/
minNumber/maxNumber, immediately explaining why the two originally-tried
hypotheses (nearby-road index, same-name count) both failed.
Validated exhaustively: minNumber <= maxNumber holds on all 11,960,527
records, zero exceptions. 26.5% have both fields zero (no house-number
data), matching the earlier observed f2==0 rate exactly. Real examples:
VIA LIDO AZZURRO -> 47-49, VIA DEPOSITI -> 1-95. Also explains why the
pair is identical across a road's own multiple .prd entries (a real
property of the road segment, not a per-entry variant).
Notes a genuine cross-file curiosity: eeuz.rl's own minNumber/maxNumber
is always zero on this disc while eeuz.prd's is populated -- two
different tables sharing the naming convention, populated
inconsistently.
Upgrades eeuz.prd to fully Cracked status.
Advance eeu.iof: eeu.mod schema names, il-reference-count correlation, correct eeu.rd bytes[1:5]
eeu.mod names the table intersectionOffsetFile with real fields offset/
type/count, confirming and renaming zero4/vb/c80. type's value shape
(0x80 default vs {0,1} for real anchors) now reads as a clean bit-7
discriminator.
New lead for the long-unresolved common-case count field: correlates
moderately (r~0.21) with how many eeu.il entries reference the same
eeu.rd record -- a real signal, not an exact formula. Two other
hypotheses (eeu.rd's own bytes[1:5]; local road density as a literal
intersection-count proxy) were tested and refuted.
Major correction found along the way: eeu.rd's bytes[1:5] has 6,174
distinct values at full file scale, not '~5 distinct patterns' as
previously reported from a small sample. Also refutes the direct-embed
hypothesis against eeu.si's own bit layout. Fixed across
eeu-rd-Road-Routing-Graph.md, eeu-si-Segment-Classification-Table.md,
eeu-mod-Database-Schema.md, eeu-iof-Parallel-Road-Array.md, Home.md.
Further crack eeu.si: driveable_lower/drivable_upper, tollbooth_direction, restclass
driveable_lower/drivable_upper (byte1 bits0-1): never both clear across
all 24,353 records -- matches real 'drivable in at least one direction'
semantics for a road segment.
tollbooth_direction (byte1 bits4-5): mutually exclusive, both rare
(~1.3% each) -- matches a real 'which direction is tolled' state.
restclass (byte2 bits3-6): fully saturated 4-bit range (16/16 values
used), the cleanest possible enum-field signal.
11 more single-bit flags (toll_vignette, toll_road, hwy_complex_bit,
landmark, dbldig, detailedcity, urban, bifurcation_left/right, rnc,
truck_digitized) occupy the remaining 11 bits exactly by count, but
no confident 1:1 name assignment was found for them.
Crack eeu.ti's timezone field and full purpose via real-world geography
Major finding: utc_offset_hours = timezone_field/100 - 12, validated
exhaustively against Russia's own real 11 federal district time zones
(Kaliningrad UTC+2 through Kamchatka UTC+12), all exactly right.
Joining eeu.cny -> eeu.stt -> eeu.ctr for every county reveals the
whole file's purpose: timeinfo_id=1 is the disc's Central European
Time DST zone (72% of counties), timeinfo_id=3 is Eastern European
Time (17%), and every other id is one of Russia's 11 real time zones
plus Belarus/Turkey -- none of which observe DST (Russia abolished it
2014, Belarus never has, Turkey abolished it 2016, consistent with
this 2019-dated disc). The 2 DST zones are exactly the 2 ids with a
real 2-rule spring-forward/fall-back sub-schedule; every non-DST id
has just a simple default record.
Byte positions assigned for all 14 remaining named fields (1 byte
each, matching eeu.mod's schema order); a few fields' exact hour/day
semantics remain unconfirmed.
Upgrades eeu.ti to Cracked status.
Partially crack eeuz.pca: record framing at full scale, 2 of 4 trailer fields
188 country/continent phoneme records parsed with zero leftover bytes.
clusterOffset/clusterCount confirmed always-zero (cross-validates
eeu.pcl's empty status). cityOffset/cityCount is a real per-country
constant but its target file wasn't identified -- tested against
eeu.cty (both direct and reversed field order) and eeuz.pct, neither
matched. Also found eeu.cty's own country tag is NOT one contiguous
block per country as previously summarized (441,325 tag transitions
across 939,351 records).
Adds eeuz-pca-Country-Phoneme-Catalog.md, updates Home.md, _Sidebar.md,
eeu-mod-Database-Schema.md.
Partially crack eeu.ti, confirm eeu.cny's timeinfo_id FK by exact id-frequency match
Fixed 23-byte records, 17 total, small enough to fully hand-inspect.
timeinfo_id/seqnr and the one-to-many grouping structure cracked and
validated. The 2 timeinfo_id values with rich 3-sub-record groups (1
and 3) are exactly eeu.cny's own 2 most common timeinfo_id values
(72% and 17% of all counties) -- an exact, non-coincidental
correspondence that closes the loop eeu.cny's own page left open.
14 more named fields (the actual DST-rule transition-date/duration
data, per the schema's own field names) live in an 18-byte tail but
weren't decomposed into individual fields this session -- documented as
2 clean record 'shapes' (real entry vs. terminator) instead.
Adds eeu-ti-Time-Info-DST-Table.md, updates eeu-cny-County-Catalog.md
and eeu-mod-Database-Schema.md with the confirmation, and Home.md/
Unexamined-Files.md/_Sidebar.md.
Crack eeu.stt, confirm eeu.cny's state_id FK by full set equality
Fixed 114-byte records, validated at full file scale (691 records).
name and country_id both cracked and validated: name is a real
sub-national region/canton name; country_id is an exact FK into
eeu.ctr's own row order (not eeu.cal's alphabetical numbering) --
checked against all 691 records with zero anomalies -- a 3rd distinct
country-numbering scheme found on this disc.
Closes the loop eeu.cny's own state_id field left open: eeu.cny's 691
distinct state_id values are the exact same set as eeu.stt's own 691
state_id values, and 3 spot-checks (CHANIA/IMPERIA/SION) all resolve
exactly right against eeu.stt's real content.
Adds eeu-stt-State-Region-Catalog.md, updates eeu-cny-County-Catalog.md
and eeu-mod-Database-Schema.md with the confirmation, and Home.md/
Unexamined-Files.md/_Sidebar.md.
Partially crack eeu.si, correct the eeu.rd bytes[1:5] cross-reference lead
Fixed 8-byte records, validated at full file scale (24,353 records).
Cracked byte 0 (rank/class/divided) and byte 4's low nibble
(route_num_type/paved), in exact eeu.mod schema order, with plausible
bounded value ranges and realistic real-world rates (paved ~95%,
divided ~16%). 15 more named fields in bytes 1-3 not yet assigned.
Also corrects a previous session's lead: eeu.mod's write-up flagged
eeu.si as a strong candidate for eeu.rd's unresolved bytes[1:5]. Checked
directly -- eeu.rd's ~5 distinct patterns there are far too few to index
eeu.si's 20,381 distinct records, so that specific cross-reference
doesn't hold up. Corrected on eeu-mod-Database-Schema.md and
eeu-rd-Road-Routing-Graph.md.
Adds eeu-si-Segment-Classification-Table.md, updates Home.md,
Unexamined-Files.md, and _Sidebar.md.
Identify eeu.pmp/eeu.pol/eeu.pot via eeu.mod's schema, resolve eeu.pmc/.pmm's open question
All 3 are genuinely empty (94-byte header, zero body) on this disc, same
family as eeu.pcl. eeu.mod's schema reconstructs each one's intended
design: eeu.pot uses the identical character-trie field template as
eeuz.rt/.ct (roadTree/cityTree); eeu.pol is a postalcode+lat/lon+list-
index lookup record; eeu.pmp is the third 'merge' sibling of eeu.pmc/
.pmm, sharing the same lone mergedListIndex field.
That cross-reference resolves eeu.pmc/.pmm's own previously-open question
(why a 4-byte physical record when the schema counts 13/15 strings per
block): those counts are mostly shared header-struct boilerplate, and
the real per-record payload is just mergedListIndex (pmc) or a
bit-packed type+listIndex pair (pmm) -- both exactly 4 bytes.
Adds eeu-pol-pot-pmp-Postal-Code-Empty-Files.md, updates the pmc/pmm page
with the resolution, Home.md, Unexamined-Files.md, and _Sidebar.md.
Crack eeu.pmc/eeu.pmm: fixed 4-byte records, provable identity placeholder
The 'not clean at k=0..4' flag on these two files was a search-range
limitation, not a real dead end: the true record-count wraparound
multiple is k=62 (20,872 + 65,536*62 = 4,084,104), giving an exact
4-byte record with zero leftover bytes.
Checked exhaustively across all 4,084,104 records: every value equals
its own index, for both files, which are byte-identical in body content
(only the header's file_type byte differs). Combined with the already-
confirmed-empty eeu.pmp/.pol/.pot, this confirms the entire postal-code
subsystem is unpopulated on this EU East V17 disc.
Adds eeu-pmc-Postal-Code-Merge-Tables.md, updates Home.md and
Unexamined-Files.md (removes pmc/pmm, corrects the superseded-speculation
note), and _Sidebar.md.
Identify eeu.pcl via the disc's own files.cfg, not eeu.mod
eeu.mod's schema dictionary has no table block for eeu.pcl at all (the
only 'pcl' occurrences in that file are an unrelated field-name prefix
in the MAP_COMPRESSED tile schema, 'parcel'). The real answer was in
files.cfg, a plain-text disc-root file this project had only partially
read before: fileId 27, extension pcl, 'phoneme cluster list' -- part
of the same phonetic/TTS family as pca/pct/prd. The file is genuinely
empty (94-byte header, zero body) on this disc.
Also surfaces a side discovery: 3 files.cfg-declared file types (ptp,
pdx, pti) that don't exist on this disc at all, not even as empty
placeholders.
Adds eeu-pcl-Phoneme-Cluster-List.md, updates Home.md, Unexamined-Files.md,
_Sidebar.md, and eeu-mod-Database-Schema.md's stale 'still unexplained'
note.