MOI3 MCF file reverse engineering — part 2 (Language file editing)

Previous post about the MCF file was fun: laugh about what went wrong.

So let's talk about other ways the MCF file is used: i18ndata.mcf .

i18ndata.mcf — Languages
The MIB infotainment devices are used across many countries. This means the device needs to support many languages. i18ndata.mcf is arguably the least glamorous and most useful to understand: it's the translation string table that backs every piece of UI text in the car's operating system, in every supported language. i18n is the industry-standard abbreviation for internationalization. It is a numeronym where "18" represents the number of letters between the first letter ("i") and the last letter.

The MCF format
MCF ("MOI/MIB Container Format") is a generic binary envelope: a 20-byte file header, a table of contents (TOC), and a series of tagged, zlib-compressed, CRC32-checked chunks. What differs between MCF variants is purely the mix of TOC tags and what's inside each chunk's decompressed body. i18ndata.mcf uses the same envelope as everything else, but every single TOC entry is tagged OBJA — Java "Object Array" — because, unlike the 3D scene or image-atlas variants, this file is never handed to the native Kanzi rendering engine. It's read entirely by MOI3's Java application layer, through a class called I18nDataReaderImpl, and exists solely to answer one question at runtime: given a UI label and the active language, what string do I display?

the i18ndata.mcf file
The i18ndata.mcf doesn't look like language data at first sight:

But… looks can be deceiving! What you see is in fact ZLIB data, which can be recognized by the "78 DA" hex data. Zlib is a lossless compression method. This means you can compress and extract files and the resulting extracted file will be identical to the original file. The same happens with ZIP and RAR. Zlib can be found in many firmware distributions.
So it makes sense that we can't make sense of the hex data when you first look at it… but you can inflate the data, and then it suddenly makes sense.

The file follows a "directory + data chunks" pattern.

Chunk 0 is always a directory. It maps every other chunk id to a key string shaped like "{entryKey}:{languageTag}" — e.g. callhandling:de_DE. In the sample file there are 92 distinct entry keys (UI feature areas like callhandling, carsetup, controlcenter) and 34 languages.

Chunks 1.N are data chunks, one per entry/language pair, each stamped with a magic value 0x6E383149 — the ASCII bytes "I18n" read as a little-endian u32.

Each data chunk holds four things in sequence:

— Header (6 integers): metadata like objlen=7 and the magic marker 0x6E383149 ("I18n")
— String pool (texts[]): all UI strings deduplicated and stored once (UTF-16LE, length-prefixed)
— Lookup table (scalars[]): maps label IDs to string indices, for instance scalars[3] → index 5 → texts[5]
— Extra arrays (optional): additional lookup tables for plural/variant forms

To display a label, the UI does a two-hop lookup: ask scalars[] for the index, then fetch the string from texts[]. For example, label ID 3 in the callhandling:de_DE chunk resolves through scalars[3] to texts[] entry for "Anruf beenden" (German: "hang up call").

Why separate chunks per language instead of one chunk with parallel columns? Each language chunk can load/unload independently. Switching UI language only reloads the small directory (chunk 0), not the entire file.

So let's look at this data after it's deflated:

This looks much more like text!

We can edit the languages… which is useful because sometimes your language isn't yet supported by the infotainment system. So now you can translate things!

Check out the new MFC tool on mqbtools.nl:
mqbtools.nl/mcf_universal/