Flash (CFF) Tools - jglim/CaesarSuite GitHub Wiki

  1. Explain limitations first (current naive implementation, no compression or encryption)
  2. Export CFF into individual memory-mapped data segments
  3. Reassemble modified CFF files
  4. Technical note: 4.1. Reassembly capability 4.2. Reassembly limitations
  • Basic control unit structure. Should make things clear.

The ECU uses closed-loop control, a control scheme that monitors outputs of a system to control the inputs to a system.

Gathering data from dozens of different sensors, the ECU performs millions of calculations each second (this why many people call it Calculator), including looking up values in tables, calculating the results of long equations to decide on the best spark timing or determining how long the fuel injector is open.

Generally, we are interested in software part, so we will focus on it.

Simplified hardware structure for any onboard unit should have CPU+FLASH+EEPROM in all their variations.

By Hardware it may be:

  • MCU + Flash memory + eeprom = 3 separate controllers group
  • MCU with internal (emulated) Flash + eeprom = 2 separate controllers group
  • MCU + Flash with internal (emulated) eeprom = 2 separate controllers group
  • standalone MCU.
  • Software

Group of controllers contain microcode that we call "software".

Software (SW) = MCU SW (Part1) + Flash SW (Part2) + Eeprom (Part3).

I call it group because in most ecus P1+P2+P3 form an integral part of Software.

Lets say we take dump from MCU(as is) that represent ECU N1 with SW version "1" to ECU N2 with SW version "2". It wont work.

If we manipulate same way only with Flash(as is) - 50\50 % - ecu may be able to communicate via CAN - but wont start engine.

From EDC16 generation immobilizer data may be stored in flash - as emulated EEprom.

Part3 Eeprom store long term data - VIN , injector codes , variant codings, etc.

Different ecu types have its own structure (i wish we can arrange this data one day).

For Example try to find VIN in Flash of CRD2, its encrypted, and only one way to find it out -change it using embedded functions and compare files.

  • SW and CS sectors

Flash SW = Bootloader + firmware + calibrations + Checksum (CS).

Dependent on ECU type CS blocks may exist more than one

In the process of running the firmware, the software applies for the necessary values in the area of calibrations and applies them depending on the instructions.

In case of calibrations been modified to improve engine performance without correction of CS - it would loop bootloader, or may be unpredictable.

Often, CRD2\CRD3 units enter bootloader loop after sw update - yes because of incorrect CS \ or wrong CFF been flashed.

  • CFF....

CAESAR Flash File - binary format with flash data. Can contain multiple areas / FlashKeys.

CFF = flashware files. CFF is good solution for updating units SW, like we does with our iPhone or Droid.

Daimler thought ahead and understood that SW written by people and they can do mistakes as well, CFF is a panacea to change software without changing hardware.

СFF doesn't include ALL data like ECU does. Bootloader keeps ECU alive during changing or updating SW with CFF.

  • Limitations

Fixing CS in modified Engine ECU flash is part of another tools.

Fixing CS in modified flash of instrument cluster or EZS looks impossible due lack of tool that able to do that (for today, there must be a way!).

All this aren't CaesarSuite limitations, its just not his part of job.

  • Advantages

If you're doing chip tuning, egr, dpf, swirl flaps, NOx, SCR or so, you might have bunch of tools to flash different ecu's by BDM pads or direct OBD, or one expensive.

But what if your client on another side of Earth, having only J2534 or C3\C4 multiplexer - no way to help(can flash factory CFF only).

For today editing CFF gave us the ability to modify Engine units SW in way we want, then upload it to ECU without having special flash tools.

All we need for it is original or china MB multiplexer or tested J2534 tool.

  • Practical usage overview using CFF Tools
  • code examples & comparisons

As example ill take CR4_NFZ, and one of most popular sw CFF.

Slice cff.

Then compare original flash to sliced parts from cff.

Block1.

Block4.

Block4 2d view.

EOF = 1FFFFF

HEXtoDEC 1FFFFF = 2 097 151 bytes = 2 Kb

Block5. MCU Flash block

Pay attention that 0x404000 is mapped for MCU 0x004000 address. So we can make conclusion that MCU flash beginning mapped internally to ECU by 0x400000 address.

  • etc. that might be not last one