Tune Analysis — EDC16U34
Prepared by indigo-nx · 2026-06-05
A methodology walk-through for analysing a stock vs modified calibration pair on a Bosch EDC16U34 ECU (a typical mid-2000s 1.9 TDI platform). Both files are 2 MB exact (0x200000) — identical container, different content.
File-level shape
Both files are partial reads — ~90% of each file is 0xFF, with the actual content concentrated in the upper memory:
| Region | Range | Coverage | Role |
|---|---|---|---|
| A | 0x180000 – 0x18FFFF | ~60 KB sparse | Shadow / EEPROM-image |
| B | 0x1C0000 – 0x1EAFFF | ~168 KB dense | Main calibration block |
Everything below 0x180000 is solid 0xFF. Consistent with an OBD-pulled calibration read on the EDC16U34 — code region not included.
Endianness: 16-bit big-endian throughout. Decoded values across map regions are plausible engine quantities under big-endian, random under little-endian. Consistent with Freescale MPC convention.
Header markers in Region B
ASCII strings near the start of each region identify the software variant and hardware PN. The fact that the same software-ID string appears at the head of both Region A and Region B confirms A as a shadow of B. A short engine-descriptor string (R4 1,9L EDC — 4-cyl 1.9 L EDC platform) appears further into the calibration block.
Diff summary
1928 bytes differ between the two files. Changes cluster into discrete regions inside Region B (calibration block), with mirror changes in shadow Region A. Representative regions and their observed edit patterns:
| File offset | Size | Pattern |
|---|---|---|
| 0x1C6F16 – 0x1C6F31 | 28 B | Axis preserved, data values zeroed |
| 0x1C6F64 – 0x1C6F8B | 40 B | 20 cells of 0x2710 (10000) zeroed |
| 0x1C7008 – 0x1C702F | 40 B | RPM-style axis ramp preserved (3500/3750/4000/4200), data values zeroed |
| 0x1CB924 – 0x1CD2F7 | sparse | Scattered single-byte / few-byte edits |
| 0x1D1730 – 0x1D17C7 | 128 B | Contiguous map edit |
| 0x1D3106 – 0x1D364B | many 4-byte deltas | Selective cells changed to flat 0x1F40 (8000) — per-cell ceiling edit |
| 0x1DF23D – 0x1DF8E7 | many 4-byte deltas | Selective cells edited at consistent strides |
| 0x1E3796 – 0x1E38F3 | 350 B | Constant block: 0x2328 (9000) → 0x1FC7 (8135) throughout |
| 0x1E3974 – 0x1E3AD1 | 350 B | Second 350-byte constant edit, same shape |
| 0x1E4A2A – 0x1E4B05 | 187 B | Contiguous block edit |
Worked example — 0x1C7000 region (limiter neutering)
Stock: 0D AC 0E A6 0F 96 10 68 | FF FF FF FF 08 98 08 98 08 98 0C 1C 0C 1C 0C 1C ...
Tune: 0D AC 0E A6 0F 96 10 68 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...
First 8 bytes (axis: 3500 / 3750 / 4000 / 4200 — a monotonic RPM-style ramp) unchanged. Data values following the axis zeroed end-to-end. Classic axis-preserved limiter neutering: the lookup still works, but every operating point returns zero.
Worked example — 0x1E3796 region (constant edit)
Stock: 23 28 23 28 23 28 23 28 ... (350 bytes of 0x2328 = 9000)
Tune: 1F C7 1F C7 1F C7 1F C7 ... (350 bytes of 0x1FC7 = 8135)
Constant scalar / flat-table changed from 9000 to 8135 across the entire block.
DTC suppression manifest
An address-style sequence in the modified file's label (0400-040f 0460-406f 0480-049f 0299 1951 0234 3103) is not a list of file offsets — they're OBD-II diagnostic trouble codes the tune has been configured to mute:
| Code | Standard meaning | |---|---| | P0400 | EGR Flow Malfunction | | P0460 | Fuel Level Sensor "A" Circuit | | P0480 | Cooling Fan 1 Control Circuit | | P0299 | Turbocharger "A" Underboost | | P0234 | Turbocharger "A" Overboost | | P1951 | VAG manufacturer-specific | | P3103 | VAG manufacturer-specific |
The pattern is consistent with a DPF / EGR / boost-modification delete tune. Emissions and boost-related codes muted so the dash stays clean after the corresponding calibration changes — which is exactly what the map diff shows:
- EGR-shaped table neutered at
0x1C7000→ pairs with P0400 mute - Boost-related limit altered at
0x1E3796(9000 → 8135) → pairs with P0234 / P0299 mutes - Selective ceiling edits at
0x1D3100→ plausibly the boost target curve or fuelling cap
A nochk flag in the label indicates the checksum routine has been patched to bypass validation. None of the diff regions show checksum-style patches, supporting this interpretation. A flex flag likely indicates Alientech FlexECU programming format.
Open questions
- DAMOS / A2L availability for the software variant — would convert the diff regions from shapes into named maps (boost target, injection quantity, smoke limiter, etc.) and unlock semantic interpretation rather than pattern reading.
- Map identity confirmations — given the patterns observed at
0x1C7000(EGR-style limiter neutered),0x1D3100(selective ceiling raises), and0x1E3796(9000 → 8135 constant), can these be identified by name?
Method
- Step 0 — file format detection. Entropy, byte distribution, ASCII visibility,
0xFFprevalence to distinguish raw flash from tool-wrapped/encrypted reads before any analysis. - Step 1 — layout. Non-
0xFFdensity mapping in 4 KB blocks to locate data regions; cal-block base located by the offset of meaningful ASCII header markers. - Step 2 — diff. Byte-level comparison with contiguous-region clustering (gap tolerance 16 bytes); side-by-side hex dumps of each change region; interpretation of edit patterns against expected map shapes (axis + data, constant tables, selective cells).
- Endianness calls confirmed by reading multi-byte sequences for plausibility as engine quantities (RPM ramps, limit sentinels, throttle/load axes) under both byte orders.
indigo-nx.com