Support the newer OP-COM data-file format (2012–2014 era, non-OPCOMECF2d)

[jwderoos]

Summary

A newer OP-COM data-file format (internal version markers 141105 / 120320,
i.e. 2012–2014 era) is not decodable by the current pipeline, which targets
the OPCOMECF2d container. We should reverse-engineer this second format and add
support for it.

No vendor files, keys, or the OP-COM executable are attached to this issue or
belong in the repo. They are held separately by the maintainer for local analysis.

What we know so far

Findings from running the current tool against a newer install's LangData/EN:

• No OPCOMECF2d magic anywhere in the tree — this is a different container.
• .hdr files are plain, unencrypted zlib (78 da), and decompress directly
  to readable catalog text with no nibble-swap. Only 2 such files exist
  (opeldata.hdr, eculist.hdr).
• The body files (opeldata, eculist, *.MBF, *.SCR, *.code, *.scs,
  *.var, *.can, ProgrammingData/**, …) — ~5000 files — are encrypted with an
  unknown cipher that is not the project's dword stream cipher.

Why it isn't the current cipher

The project's cipher fixes K0/S at the stream start, so the encrypted
zlib-header bytes are identical across every file. In this format, the body
files share no common prefix at all (opeldata, eculist, and the .MBF
files all differ in their leading bytes). That rules out "same cipher, different
K0/G" — it's a different algorithm, or per-file keying (e.g. an IV derived
from filename/length/header).

Running the project's own cryptanalytic key-recovery adapted to this layout
(whole file as payload, no 12-byte magic header) found no corpus-wide key: a
candidate matched exactly one 20-byte file by coincidence and failed on all
others.

Suggested next steps

• Determine the body-file cipher (candidate hypotheses: per-file IV from
  filename/length; a different stream cipher; header-carried key material).
• Check whether the plain-zlib .hdr files carry an index/offset table or key
  hint for their companion bodies.
• Inspect the OP-COM executable's loader for this version (separate, local —
  not in repo) to identify the key-setup path.
• Once the cipher is known, add a format-detecting decoder path alongside the
  existing OPCOMECF2d one, and extend decrypt.py to dispatch by format.

Scope note

The current OPCOMECF2d format is fully working and unaffected — this is purely
additive support for the newer format.