Pages: [1]
Author Topic: ZF 8HP (AL551/AL552) FRF Decryption + LZZ Decompression  (Read 784 times)
dspl1236
Jr. Member
**

Karma: +5/-1
Offline Offline

Posts: 35


« on: June 08, 2026, 09:16:50 AM »

Building on the work shared in the AL551 threads here and chrisgotboost's compression research, I've put together an open-source toolkit for extracting ZF 8HP TCU firmware from VAG flashdaten FRFs.

Key findings:
The ZF 8HP ODX method 0x22 encryption is a 19-byte repeating XOR:
Key: CyA2008ZFVAGtcuxsam
Hex: 437941323030385a465641477463757873616d

The XOR key itself reads as ASCII: CyA 2008 ZF VAG tcu xsam — looks like an internal project label. If anyone recognizes the CyA/xsam naming convention from ZF tooling, the method 0x01 AES key might follow a related pattern.

The compression (also method 0x22) is an LZSS variant with a 2047-byte window instead of the standard 1023. Inverted flag bits (0=literal, 1=reference), 5-bit count + 11-bit displacement. Verified with a 1,310,208 byte perfect match against a known-good decrypted block.

Confirmed working on 4G0927158 (A6/A7 C7) and 4H1927158 (A8 D4) families. The 8K0 (A4/A5 B8) uses method 0x01 which is actual AES — that key is still unknown.

The repo also covers DQ381 BL301 extraction (same SH72549 MCU) and documents where the AES key/IV is stored in the bootloader (BOOT offset 0x344/0x354) for anyone chasing the BL401 key.

All keys, decompression algorithms, and platform research in one place:

https://github.com/dspl1236/vag-tcu-tools

Credits to chrisgotboost for identifying the encryption type and compression format (topic: ZF8 AL551 Compression http://nefariousmotorsports.com/forum/index.php?topic=22625.0), projectLSaudiA4 for the AL551 memory map and Ghidra work(http://nefariousmotorsports.com/forum/index.php?topic=22488.0title=), and bri3d/VW_Flash for the FRF pipeline that made this possible.

If anyone has the method 0x01 AES key (8K0 family) or a BL401 DQ381 bench read, the repo has a contributing section. Happy to add support for other TCU platforms (DQ500, DL501, DL382) if people share what they know... if its already out there then I need todo more reading.
Logged
dspl1236
Jr. Member
**

Karma: +5/-1
Offline Offline

Posts: 35


« Reply #1 on: June 08, 2026, 10:20:54 AM »

Update: Differential analysis of 3 FRFs from the 8K0 family (A4/A5 B8, method 0x01) confirms it's NOT AES either — mid-block transitions in the XOR of two ciphertexts rule out any block cipher. It's byte-level processing but not a short repeating XOR like method 0x22. Different and more complex. Still need a raw flash dump from any 8K0 TCU to crack it. Updated the repo.
Logged
gremlin
Hero Member
*****

Karma: +217/-13
Offline Offline

Posts: 767


« Reply #2 on: June 13, 2026, 06:37:15 AM »

Update: Differential analysis of 3 FRFs from the 8K0 family (A4/A5 B8, method 0x01)
...
It's byte-level processing but not a short repeating XOR like method 0x22. Different and more complex.
DL381 ( 0AW) и DL501 (0B5) tcus (with 01 compress/crypt mark) use 256-byte long table of values from 0 to 255 in swapped order.
It is some add/shift algo not XOR-ing.
The tables is different for both TCUs.

The same crypt method is used in TCUs with 11 compress/crypt marking of types DQ200/DQ250/DQ400/DL501/D382
but with additional compressing.
Interesting that DL800 tcu with fake AA-mark use the same method not AES.
« Last Edit: June 13, 2026, 07:31:39 AM by gremlin » Logged
dspl1236
Jr. Member
**

Karma: +5/-1
Offline Offline

Posts: 35


« Reply #3 on: Today at 08:10:28 AM »

This is exactly what my differential analysis was pointing at — I called it "byte-level, not XOR" but couldn't characterize it further without the table structure. 256-byte permutation + add/shift makes perfect sense given what I was seeing.

A couple of follow-up questions if you're willing:

Is the permutation table static per TCU family (same across all firmware versions of DL381, for example), or does it vary per SW version? If it's static I should be able to recover it from a bench dump via known-plaintext.

For method 0x11 — you mentioned "same algorithm + additional compression". Is the compression layer something standard (LZ77, LZSS) or another proprietary scheme like the LZZ I found in the ZF method 0x22 blocks?

On the DL800 fake 0xAA — I've been looking at 4M0927158 (Q7/Q8 ALX520) and 8W0927158 (B9 S4/S5 AL552) which both report 0xAA. Block alignment analysis suggests those are real AES (all blocks 16-byte aligned), so I think the fake 0xAA warning doesn't apply there. Can you confirm which DL800 part numbers show the fake mark so I can make sure I'm not mixing things up?

Updated the documentation at github.com/dspl1236/vag-tcu-tools with your findings — credited to community RE on NefMoto. Let me know if you'd prefer different attribution.
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 1.785 seconds with 17 queries. (Pretty URLs adds 0.00099999999999989s, 0q)