Skip to content

README.md

Latest commit

 

History

History
88 lines (67 loc) · 3.69 KB

README.md

File metadata and controls

88 lines (67 loc) · 3.69 KB
Raw

OP-COM OBD Data File Decoder

A reproducible decoder for the OPCOMECF2d container files shipped inside the legacy OP-COM (Opel diagnostic) tool. Point it at your own OP-COM installation and it writes out the decrypted plaintext catalogs — the ECU address maps, measuring blocks, error codes, output tests, and coding tables.

This repository ships an algorithm, not data and not a key. No OP-COM executable, no vendor data (encrypted or decoded), and no key constant is included. You supply the files you already legally possess.

What it does

your OP-COM folder ──▶ derive the cipher key from your own datafiles
                   ──▶ decrypt every OPCOMECF2d file
                   ──▶ write plaintext to ./output/  (git-ignored)

The OPCOMECF2d payload is a stream-ciphered, zlib-compressed, nibble-swapped blob. Decoding needs two 32-bit cipher constants (K0, G).

The key is derived, not extracted or shipped

You might expect the tool to pull the key out of OP-COM.exe. It does not — and it can't, easily: those two constants are zeroed at rest in the binary and are written only by protector-wrapped startup code that never runs in a cold call (see docs/history/ for the full reverse-engineering account and the experimental emulation harness).

Instead the key is re-derived by cryptanalysis of your own encrypted files: the payloads are standard zlib streams, and "stored"-type deflate blocks provide exact known plaintext that, with the constant encrypted zlib header, pins K0 and G uniquely. This uses only your datafiles plus the public zlib/deflate spec — the executable is not needed at all. It runs in about half a second, once. Because the constants are derived from your ciphertext and a public spec (nothing copyrightable from the binary) and are never written to disk, this repository distributes no key.

Usage

Requirements: Python 3 (standard library only for the main pipeline).

python3 python/decrypt.py --opcom "/path/to/your/OP-COM 08-2010 EN" --output ./output
  • --opcom — your OP-COM install folder (must contain LangData/EN/).
  • --output — where to write decrypted plaintext (default ./output, git-ignored).

Individual pieces, if you want them:

# just derive and print the key from your files
python3 python/recover_key.py "/path/to/OP-COM 08-2010 EN/LangData/EN"

# decode specific files (deriving the key first)
python3 python/decode_opcomecf2d.py --langdata "/path/.../LangData/EN" FILE...

# run the self-contained tests (no vendor data needed)
python3 python/test_decoder.py

Repository layout

python/
  decrypt.py             # entry point: folder -> derive key -> decrypt -> output/
  recover_key.py         # derive (K0, G) from your encrypted files
  decode_opcomecf2d.py   # the cipher + decoder (key passed in, never hardcoded)
  test_decoder.py        # synthetic round-trip tests (ship no vendor data)
  experimental/          # historical exe-emulation RE track (never produced a key
                         #   end-to-end); requires user-supplied binaries
docs/
  FORMAT.md              # the OPCOMECF2d container + cipher, in detail
  history/               # the original reverse-engineering handover notes

A Rust rewrite may follow for ease of distribution; the Python here is the working implementation.

Legal / scope

This is interoperability reverse engineering for reading files you legally possess, to recover open diagnostic facts (CAN addresses, DIDs) about your own vehicle. Do not redistribute the decoded vendor data — the decrypted output is git-ignored for that reason. The tool is read-only: it decodes files and does nothing to any vehicle or ECU.