NOT_COMPRESSED Header Trailer Fields

Status: ✅ Cracked — a cross-cutting finding that applies to every NOT_COMPRESSED file on the disc, not just one. Found while investigating eeu.aff, then verified against all 22 NOT_COMPRESSED files present on the reference disc.

Background

Every NOT_COMPRESSED file (eeu.rd, .il, .iof, .typ, .ctr, .cty, .abc, .aff, ...) shares the same 94-byte SIEMENS/(C) SIEMENS AG header. Only the literal ASCII version strings near the front were previously decoded — this session found 3 more meaningful fields in the header's own tail.

The fields

Bytes	Type	Field	Status
[84:86]	uint16 LE	file_type	A small per-logical-file-type code, unique per file (e.g. eeu.rd=4, eeu.cty=3, eeu.typ=1)
[86:88]	uint16 LE	record_count_lo16	That file's own record count, truncated to 16 bits for files whose real count exceeds 65,536
[90:94]	uint32 LE	total_size	The file's total size in bytes — for most files

Validation

record_count_lo16 checked exactly against every already-known real record count on the disc:

• eeu.typ (2,574 records) — matches exactly.
• eeu.ctr (35 records) — matches exactly.
• eeu.rd (8,809,081 records, exceeds a uint16): 8,809,081 mod 65,536 = 27,257 — matches the header exactly.
• eeu.cty (939,351 records, exceeds a uint16): 939,351 mod 65,536 = 21,847 — matches the header exactly.

Practical use: for a not-yet-examined file, dividing (filesize - 94) by this field (trying field + 65536*k for small k if the plain field doesn't divide evenly) is a fast way to GUESS a real fixed record size before reverse-engineering the body at all.

total_size matches the real file size exactly on 18 of 22 NOT_COMPRESSED files checked. Known exceptions:

• eeu.iof and eeu.mod store the body size instead (off from the real total by exactly 94 — the header's own size).
• eeu.cal's value (24,778) matches neither convention against its real size (23,326) — unexplained.

Derived record-size candidates for 5 still-unexamined files

Using record_count_lo16 against each file's own real body size — not independently verified against real content, but an exact-integer division at k=0 for all 5 is a strong structural signal, not a guess:

File	Records	Record size	Body size
eeu.cal	484	48 bytes	23,232
eeu.cny	2,326	176 bytes	409,376
eeu.si	24,353	8 bytes	194,824
eeu.stt	691	114 bytes	78,774
eeu.ti	17	23 bytes	391

eeu.pmc/eeu.pmm (record_count_lo16 = 20,872 each) do not divide their own body sizes evenly at k=0..4 — either their real record size isn't fixed, the true count needs a larger wraparound multiple, or they don't use this convention at all. eeu.mod/eeu.tmc both show record_count_lo16 == 0 — consistent with either a genuinely variable-length body (like eeu.il, which also doesn't fit a clean fixed-record model) or a real count that happens to be an exact multiple of 65,536 (implausible for files this size).

See Unexamined Files for the full remaining list.

Reader code

research/aff_reader.py — decode_not_compressed_header() (works on any NOT_COMPRESSED file's header, not just eeu.aff).