eeu.pmc / eeu.pmm — Postal-Code Merge Tables

Status: ✅ Cracked · 16.3 MB each · NOT_COMPRESSED

Two files, one finding: both are fixed 4-byte-record arrays whose entire content on this disc is a pure identity function — confirming the whole postal-code subsystem is unpopulated, not that either file has an unusual format.

Record format — cracked, validated at full scale (4,084,104 records)

94-byte header, then fixed 4-byte records:

uint32 LE  value   -- on this disc: value == record's own 0-based index,
                       for every record, no exceptions

The real record count is 4,084,104 — not obviously derivable from the shared header's own record_count_lo16 field (see Header Trailer Fields) using small wraparound multiples: this file was originally flagged in Unexamined Files as "not clean at k=0..4" because only record_count_lo16 + 65536×k for k=0..4 was tried. The real multiple needed k=62: 20,872 + 65,536×62 = 4,084,104, and 4,084,104 × 4 = 16,336,416 bytes — an exact match to the real body size, zero leftover. The convention held after all; the earlier search just wasn't wide enough.

The content — a perfect identity function

Checked exhaustively across all 4,084,104 records, zero exceptions: record i's value is exactly i — 0, 1, 2, 3, ..., 4084103. A real "merge" table, even a mostly-trivial one, would be expected to have at least some entries pointing elsewhere; a perfect identity sequence across 4 million+ records is the strongest possible signal of an auto-generated placeholder array, not populated data.

eeu.pmc and eeu.pmm are byte-identical in body content

eeu.mod's own schema names eeu.pmc postalcodeListMergeCity (13 fields) and eeu.pmm postalcodeListSeparate (15 fields); the disc's own files.cfg calls them "postalcode merge city file" and "postalcode merge separator file" respectively. Despite the different declared schemas, direct comparison shows the two files' bodies are byte-identical — the same 4,084,104-entry identity array. Only the 94-byte header's file_type byte (63 for .pmm vs. 64 for .pmc) differs between the two files.

This confirms the whole postal-code subsystem is unpopulated

Combined with the confirmed-empty eeu.pmp, eeu.pol, and eeu.pot — all bare 94-byte headers with zero body, same family as eeu.pcl — the entire postal-code subsystem (.pol/.pot/.pmm/.pmc/.pmp) is unpopulated on this specific EU East V17 disc. Plausibly this East-Europe dataset's country set didn't have licensed/available postal code data at build time, or the feature wasn't enabled for this particular release — not independently confirmed (no other region/market disc was available this session to compare against a populated postal-code subsystem).

Resolved: why a 4-byte record when eeu.mod's schema declares 13/15 fields?

Solved in a later session, while investigating eeu.pmp/.pol/.pot. The "13"/"15" counts include 11 shared boilerplate strings every eeu.mod table block carries (the table name, its ...Header struct name, and the stamp/copyright/db_release/db_version/comp_version/dbID/ fileID/rec_cnt/byte_cnt header-struct fields) plus 1 more struct-name wrapper — not 13/15 independent per-record data fields. Pulling each block's real field list directly (research/mod_reader.py's extract_blocks()) shows the actual per-record payload is:

• eeu.pmc (postalcodeListMergeCity): mergedListIndex (1 field)
• eeu.pmm (postalcodeListSeparate): type, listIndex (2 fields, under wrapper struct name type_and_listIndex — strongly suggesting they're bit-packed into one physical word, not stored separately)

Both resolve cleanly to the single 4-byte field found by direct inspection above. eeu.pmp (postalcodeListMergePostalcode) — the third sibling in this file family — independently confirms the pattern: its own real payload is a lone mergedListIndex field too, same shape as eeu.pmc exactly.

type_and_listIndex's packed-bitfield naming also cleanly explains why eeu.pmm's placeholder content is still a pure identity sequence despite nominally carrying 2 logical fields: a type field packed into unused high bits reads as 0 for every value in a 0..4,084,103 range (needs only 22 of 32 bits), consistent with type defaulting to an unset/zero sentinel while listIndex fills the low bits with the placeholder sequence.

Also superseded: the original POI speculation

eeu.pmc/.pmm were originally guessed (in Unexamined Files) 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 corrected this to "real postal-code list variants" before either file's actual bytes were opened; this page's content analysis confirms that correction and adds the further finding that the data itself is a placeholder.

Reader code

research/pmc_reader.py — read_pmc(), is_identity_placeholder() (works identically against eeu.pmm).