Unexamined Files

Status: ✅ Historical — every file on the disc has now been examined at least once. eeu.tmc (partially cracked — see TMC Traffic-Data File) and zone.cfg (identified — see Disc-Root Subsystems) were the last two. This page is kept as a historical record of how each file got there, and for its still-useful "how to start" methodology below.

(eeu.abc, eeu.aff, eeu.cal, eeu.cat, and eeu.cny, previously listed here, are now cracked — see Alphabet/Languages, Affix Table, Country Names, Country Bounding Boxes, and County Catalog — .cal's, .cat's, and .cny's derived record-size candidates below all turned out exactly right. Investigating eeu.aff's header led to cracking 3 more fields shared by every NOT_COMPRESSED file's header — see Header Trailer Fields — used below to derive real record-size candidates for the remaining still-unexamined files. eeu.mod, also previously listed here, turned out not to be a data file at all — it's the disc's own schema dictionary, and cracking it is now the single biggest lead for every file remaining on this page — see Database Schema and the per-file notes below. eeu.pcl, the one file eeu.mod couldn't identify at all, is also now cracked — not through eeu.mod, but through the disc's own files.cfg — see Phoneme Cluster List. eeu.pmc/ eeu.pmm, previously listed here as "not clean at k=0..4", are now cracked too — the real wraparound multiple was just larger (k=62) than the small search range originally tried — see Postal-Code Merge Tables. eeu.pmp, eeu.pol, and eeu.pot, previously listed here as confirmed-empty with no further write-up, now have a full page reconstructing their intended design from eeu.mod's schema — see Postal-Code Files (Empty). eeu.si, whose 8-byte derived record size below was already exact, is also now fully cracked (all 20 real leaf fields positioned in exact schema order) — see Segment Classification Table, which also corrects this page's own "strong lead for eeu.rd's bytes[1:5]" claim below — that cross-reference doesn't hold up. eeu.stt, previously the top "worth investigating first" candidate below, is now fully cracked — see State/Region Catalog, which also closes the loop on eeu.cny's own state_id field. eeu.ti, then the last remaining "worth investigating first" candidate, is now fully cracked (a later pass assigned byte positions for all 14 remaining named fields, though a couple of fields' exact semantics — e.g. the precise DST transition hour — aren't independently confirmed) — see Time-Info / DST Rule Table, which closes the loop on eeu.cny's own timeinfo_id field. eeu.tmc, then the last "still genuinely unexplained" file below, is also now partially cracked — see TMC Traffic-Data File, using ground truth found via config/create_cd. zone.cfg has also since been opened and identified — see Disc-Root Subsystems.)

They all share the same known container

Every one of these started with the identical 94-byte SIEMENS/ (C) SIEMENS AG NOT_COMPRESSED header already cracked for eeu.rd/.il/ .iof/.typ/ .ctr/.cty — so the outer container was a known quantity for all of them, including 3 more fields in the header's own tail (full write-up). eeu.tmc was file_type 16, record_count_lo16 0 (correctly consistent with the variable-length directory it turned out to have — see TMC Traffic-Data File), and eeu.mod's own schema had already named its real table "tmc file" (74 fields) before it was opened.

Every file's real table name and full field count was known from eeu.mod — none of these are actually unidentified anymore, only un-opened. research/mod_reader.py's extract_blocks() prints each table's ordered field-name list directly and is the fastest way to start any of the entries below (know what you're looking for before guessing at byte offsets).

Files whose original speculation was superseded by eeu.mod

• eeu.pmc/.pmm were originally guessed to be a POI ("point of interest") file family based on the shared pm prefix and the firmware's own EDB/POI/*.db3 convention. eeu.mod's schema already showed this was wrong — real postal-code list variants (postalcodeListMergeCity/postalcodeListSeparate) — and both files are now fully cracked: fixed 4-byte records (the real wraparound multiple needed k=62, not the small k=0..4 range tried here), and the content is a provable placeholder identity array, confirming these are siblings of the three confirmed-empty .pmp/.pol/.pot files — see Postal-Code Merge Tables.
• eeu.pmp/.pol/.pot were confirmed empty early on but never given a full write-up; eeu.mod's schema reconstructs each one's intended design (.pot uses the identical character-trie field template as eeuz.rt/.ct; .pol is a postalcode+lat/lon+list-index lookup record; .pmp is the third "merge" sibling of .pmc/.pmm, which is also what resolved .pmc/.pmm's own open question about their field count) — see Postal-Code Files (Empty).
• eeu.mod itself was originally just another unexamined file in this table, guessed to be "variable-length" from its zero record_count_lo16 alone (correctly, as it turned out) — now fully cracked, see Database Schema.
• eeu.pcl was flagged here as having "no block at all" in eeu.mod's schema, purpose completely open. eeu.mod genuinely couldn't identify it (confirmed: only appears as a prefix inside unrelated MAP_COMPRESSED tile field names, pcl_cnt/pcl_dir/etc.) — but the disc's own files.cfg names it directly (fileId 27, "phoneme cluster list") and is now cracked — see Phoneme Cluster List. A reminder that eeu.mod's schema, while comprehensive, isn't the only source of ground truth on this disc.
• eeu.si was flagged here as "a strong lead for eeu.rd's own long-unresolved bytes[1:5]". Opened and fully cracked — all 20 real leaf fields positioned in exact schema order (rank/class/divided, route_num_type/paved, and 15 more including the last 11 single-bit flags assigned by position in a later pass) — but the eeu.rd cross-reference itself doesn't hold up: even at full-file scale (eeu.rd's bytes[1:5] actually has 6,174 distinct values, a since- corrected earlier session's claim of "~5 distinct patterns"), decoding eeu.rd's own bytes with eeu.si's bit layout produces values outside eeu.si's own bounded ranges. See Segment Classification Table for the corrected lead (the real seginfoID FK more likely lives on the MAP_COMPRESSED tile format's own segment records instead).
• eeu.stt was the top "worth investigating first" candidate here, on the strength of its 114-byte exact record-size match to eeu.cny's own 691 distinct state_id values. Opened and fully cracked: country_id is a real FK into eeu.ctr's own row order (not eeu.cal's numbering — a 3rd distinct country-numbering scheme on this disc), and eeu.cny's state_id is now confirmed a genuine FK into this table by full set equality, not just plausibility — see State/Region Catalog.
• eeu.ti was the last "worth investigating first" candidate here (17 records, 23-byte exact candidate, small enough to fully hand-inspect). Opened and fully cracked: timeinfo_id/seqnr/ grouping confirmed, eeu.cny's own timeinfo_id field is confirmed a genuine FK into this table by an exact id-frequency correspondence (not just schema-consistency), timezone is cracked by an exact formula validated against all 11 real Russian UTC offsets, and (a still later pass) byte positions are assigned for all 14 remaining named fields (the transition-date/duration DST-rule data), though a couple of fields' exact semantics (e.g. starthour showing the same value 3 for both CET and EET, where real-world DST rules should make them differ by 1 real hour) aren't independently confirmed — see Time-Info / DST Rule Table.

Formerly "still genuinely unexplained" — both since resolved

• eeu.tmc (25.8 MB) was flagged here as still fully unexamined, with only a speculative "TMC/ALERT-C" guess and a real 74-field schema name to go on. config/create_cd (the disc's own build script, Disc-Root Subsystems) revealed telemat/tmc2/, whose real, self-documenting TMCCONFIG.ini gave this investigation concrete ALERT-C ground truth to test against — now partially cracked (the file's own header + 44-table directory, fully validated) — see TMC Traffic-Data File.
• zone.cfg (81 bytes, plain text) — was flagged here as "quick to just read directly" but never actually was, until now: one line, eeu = 10.1/DB 01234 18408555 4444444444444443444111144444444421411 4442222444444 — the 18408555 token ends in 8555, this disc's own volume number. See Disc-Root Subsystems for the full picture.

With these two, every file on the whole disc — db/ and all 5 disc-root subsystems — has now been examined at least once.

Files declared by the format but not on this disc at all

Reading files.cfg in full (while tracking down eeu.pcl) surfaced 3 more logical file types the format defines that this disc doesn't even create — not even as an empty 94-byte placeholder like eeu.pcl/ .pmp/.pol/.pot: 7 = ptp ("point types"), 15 = pdx ("poi index file"), 16 = pti ("point types international"). None of eeu.ptp/eeu.pdx/eeu.pti (or their eeuz. compressed forms) exist under db/ on this reference disc. Not pursued further — noted here in case a different region/market disc does populate them.

How to start

research/*.py all follow the same pattern: read the 94-byte header (now including the 3 trailer fields, see Header Trailer Fields), then try dividing (filesize - 94) by the derived record size above (or small candidate sizes if record_count_lo16 was 0 or didn't divide cleanly), or look for embedded plausible-range coordinate int32s (/100000, same convention used everywhere else on this disc) if a fixed record size doesn't pan out. Cross-check candidate field boundaries against eeu.mod's own ordered field-name list for that table (research/mod_reader.py's extract_blocks()) before guessing blind.