CFF Flash Files

[outlaw-50]

Really a powerful project and thanks for the hard time and effort that you've put in the development of this tool.

I am willing to help and contribute in any testing involved but will be testing on my own vehicle so we could take this project to the next level.

I have some concerns:

• After modifying the CFF file with my own code and exporting it does the tool calculate the CFF checksum? or do I need to do it prior extracting the CFF ?
• Do you have any plans to add an option to flash the CFF's from your tool?

[Feezex]

cff has its own chksum.
Data from cff data container has its own chksum.
So if you want to modify cff - then tool will fix its cs.
If you want to modify "flash data" from cff data container - you must check it work fine on real unit.
Example cr4_nfz ecu have MPC(processor) and flash on its board.
Any of known cff's for cr4_nfz have ~80% of real data. Some sectors of flash is secured and cannot be flashed with original cffs.
Why - Sector of flash that contain locked to ecu data (it is used as virtual eeprom) -e.g. immo, vin.
For securing this data its not been used in cffs. No need to modify FBS3, vin - to change ecu SW.
Notice - i havent told that you cannot flash it with having modified cff.
So once you have full backup of virgin ecu - you may be able to create cff that "probably" can virgin another same ecu.
It's all a theory, and you have a tool to prove it or disprove it. Especially if you have good hardware for experiments - so you dont afraid to kill your ecu, and\or can restore the ecu backup in a seconds.

[outlaw-50]

I suppose I need to clarify what I'm trying to achieve. I'm a car tuner and most of my work involves MB platforms so I tried the tool and exported the CFF File segments to binary form and when I checked the exported file it had maps as I expected, now lets say I modified a map then use the tool to inherit the modified bin to the segment using "Export Spliced File CFF". To make things easier I'll name the new exported CFF as "foo.cff" . Is this foo.cff is already checksum calculated and is it ready to be flashed or do I have to calculate the checksum once I modified the map before inheriting and exporting foo.cff

CFF I'm testing is for the ECU (MED177)

[jglim]

Thanks for checking this project out and appreciate your enthusiasm!

Sergey (@Feezex) answers are correct -- the flash splicer will automatically regenerate a new CFF checksum so that the new file can be used in official tools e.g. Vediamo.

CaesarSuite/Caesar/Diogenes/Forms/FlashSplicer.cs

Line 300 in c9ec0d2

uint checksum = CaesarReader.ComputeFileChecksumLazy(result);

However, you will still need to manage any other protections that are specific to your ECU. Depending on the ECU type, it may be checksum(s) embedded in the flash content, or it may be something else such as a post-flash signature verification / SWIL (that are not related to the CFF format).

On firmware flashing, regrettably there isn't a universal implementation that is within my capabilities. Each ECU has its own variations when it comes to authentication, flashing, and verification (including generating seed-keys). The official tools call on a compiled flash script that is embedded in the CFF file to handle these nuances. (These posts are related to scripting: #44 (comment) , jglim/UnlockECU#13 (comment) )

[Feezex]

once you modified "original" flash, lets say with winols it must correct cks so all you need to match adresses of segment area to be exported for cff.

[outlaw-50]

So I am going to calculate checksums using winols then I'll use the tool to export flash.

I'll use vediamo to flash the software and I'll be back with feedback if It was a success or not

Thanks for your replies.

[Feezex]

get a cff vith same sw you have in your ecu. Export flash segments, identify this segments with your real dump. In much cases last segment may be a part of MPC.
CFF wiki Maybe this can help you more

[outlaw-50]

Sorry for the delay, did first test on flashing MED177 after modifing the extracted segment without making checksum correction for the binary, inherited it into the CFF (tool did CFF checksum), flashed it and got "Signature Failed". I thought I could fool it and pass the Signature check without making checksum correction for the binary.

Next test is going to be checksum for both of them, hopefully we could mod other modules with the help of this amazing tool.

[outlaw-50]

So I modified the bin file and did the checksum then I inherited into the CFF file and the tool did the checksum for CFF, I tried to flash it using Vediamo and once it completed it showed a message "Signature Failed".

I tried to flash the binary file with another tool and it was OK so I think maybe their is another check which checks the integrity of the file.

Any suggestions?

[jglim]

That is probably a checksum/signature check that is present on your ECU. After uploading firmware blocks, ECUs with this mechanism will require a checksum that is paired with a signature. The signature ensures the checksum was issued from the vendor, and the checksum ensures that the uploaded firmware is not tampered.

Since Vediamo has allowed the upload to progress till the signature verification stage, it indicates that the CFF file is working correctly. If the CFF checksum was invalid, I believe the flash process will not be allowed to start.

[outlaw-50]

Do you have an idea to bypass this check?

[outlaw-50]

Do you have an idea to bypass this check?

[Feezex]

upload a modified flash you wish to be exported to cff. Ill fix software checksum. So you can compare what is your wrong step

[outlaw-50]

https://mega.nz/file/QyRigYwK#trNvymXcy7Z2FaBrOf_ol3yPDPBuka9HvEk8F9w2-M8

Here is a modified flash

[Feezex]

it is BOSCH MED17.7.1 1037540338
pobably MERCEDES CLS W218 CLS63 AMG 5.5L V8 BITURBO 386KW 525PS
https://mega.nz/file/JNRFRa5A#2oH7pdXA-caVlONloKfQkIbg_jIT812pnX6HLQoUrkE
here is fixed cs for flash.
now fix cs block 0x3FDF70 to 0x3FDFFF in exported from cff part.
update cff, and youre done

it is 1579033700 cff
FlashDataBlock: 1579033700_134500
Segment: 0x80380000 mapped to 0x80380000 with size 0x75400
Segment: 0x803FDF00 mapped to 0x803FDF00 with size 0x100

1579033700_134500_803FDF00 is CS block segment you havent fixed

[outlaw-50]

Sorry for the delay had too much work to do, Feezex thanks for the help and I tried your checksum but didn't work

here is a pic

[Feezex]

post cff you tried to flash and mod file you trying to export

[Feezex]

I got a same mod.cff as yours. Next thing is to check cff CS been set correctly.
Mod file cs ok, Exported data and CS sectors.
Im afraid tool made wrong CS

[outlaw-50]

thats what I had in mind maybe with the tool

[Feezex]

Last 4 bytes in cff is crc, it is updated but vediamo doesnt accept it

[outlaw-50]

yeah I know about the last 4 bytes but if the checksum is correct it should accept it, maybe the checksum function in the code needs to be revised

[jglim]

I don't know much about tuning and firmware modification, specifically the process of how a modified flash file is written back onto an ECU, and would be glad to understand more about it.

With the currently available information, my guess is that the flash was uploaded and fails during a verification command. For example on the IC204, the command is 31 01 FF 01. Does the ols checksum patch also handles this verification on the MED1771? What is the typical process for flashing a modified MED1771 firmware onto the ECU? Uploading the traces of the flash process might be helpful.

[Feezex]

since the feature was added by my request ive tried it with cr4_nfz with no success long time ago. At that spot i thought i made something wrong (Flash sector names orso). Now we see that it wasnt. Ill try to make trace while flashing.
Small hints :
*modified CFF withought editing CS will be blocked by vediamo during adding it in flashdata admin.
*MOD CFF file will pass flashdata admin with CS fixed
*Veiamo will start flashing process with MOD CFF but interrupt flashing at 100%
Seems @jglim right about CRC/Signature check in the end of flash process, in this case CFF still store Original "KEY" somwhere in Trafo arguments/Security table

[Feezex]

Dear @jglim i would like to hear from you :

1. Is there any bits left after all data been read by Caesar? Eg Name, Author, untill Flash Payload.
2. In hex tables with - $ ($2D $33 $AF $15 $86 $F2 $E7 $5E $92) stands for?
3. FINGERPRINT in header (eg 86.44.141.87) used for?

[jglim]

1. Yes there are unread fields. For example, in CFF:

   CaesarSuite/Caesar/Caesar/Flash/FlashHeader.cs

   Line 73 in fb66526

   UnkTableCount = CaesarReader.ReadBitflagInt32(ref bitFlags, reader);

   There's possibly a security table in one of them, containing SWIL related information (e.g. for checksum) but I am not sure because the data can also be stored in the CBF as a flash script variable. If so, being able to parse this field might allow for easier un-modded flashing but it will not bypass the flash verification as-is.
2. For the field +ss "$75 $C2 $1E $CA $96 $A6 $6A $C4 $2E $4A $50 $3F $2D $33 $AF ..
   
   As far as I know, the flash author exports a odx-f file into smr-f and cff via some tool (TrafoCoApp?) and those are the generation parameters. I also do not know what the +ss parameter is used for, however the content is 128 bytes so it's possibly a 1024-bit RSA public key that is used for SWIL / firmware verification.
3. As far as I know, the data in the CFF fingerprint isn't used when interacting with the vehicle. My guess? Probably to identify the author of the CFF file. Similar to how the fingerprint in variant coding is not essential, and is used to identify the exact sdconnect hardware which is linked to the buyer

[outlaw-50]

What I recall that for example MED177 has 2 checksums blocks sometimes when I use WinOLS to make the checksums it does change the last block and approx 4 bytes before the starting of the maps. Does that have something to do with it?

I saw some other tuners use a private tool which is not public that can flash TCU or CPC directly without using Vvediamo. Only J2534 + the private software. Maybe if you could think of a solution that would flash directly without Vediamo we could bypass that last check?

That private tool flashes BIN file not CFF.

[Feezex]

this isnt our goal for current project

[outlaw-50]

yeah but thought of maybe in light you in a way to figure out the flashing problem

[jglim]

I am not sure of how checksums work in the MED177.

The flash splicer was designed to allow for CFF modifications (dumping/modifying/splicing) and will automatically repair the checksum. Its goal is to generate a valid CFF file that is accepted and usable by Vediamo/flashdata admin.

This is a generic approach that should work well enough for older ECUs without firmware verification protection. However it will not handle any newer protections that are specific to the ECU, such as firmware signing.

Without having any traces, and only using your screenshot to make a guess, the firmware was accepted by Vediamo and completed about 37 seconds of uploading. When the upload completes, the flash script calls on the firmware verification routine that is required for your ECU to boot normally. The ECU will verify its own flash memory independently, and if it fails, it will return an error back to Vediamo, which shows up as the CRC failed error.

There isn't a quick and easy way to find a 'bypass' to flash unsigned firmware. Here's a good writeup that explains the work that went into developing a process to write unsigned firmware on some VW ECUs with a similar kind of protection. It's very specific and unfortunately beyond the scope of this current project. That being said, discussion is always welcome and I would encourage you to continue investigating.

About the tool that you mentioned, it is good to know that a working method exists. Flashing directly without Vediamo is not the issue; the tool is likely doing something else. However, without CAN logs/traces, there is not a lot of information to work with (even if only for discussion).

[Feezex]

maps write can trace.zip
here is maps file and its writing log.
Used FLEX tool to write

[Feezex]

and a sector mapping, maybe each byte from CCC stands for CRC for a specific sector
mb_bosch_edc16cp31_bench.txt

[Feezex]

As example of ic204 CCC block may store base adress and some byte to check ?

[jglim]

Original 2049022702_001.cff (sha1: d95485d5737888a765fb6098229e63308b234c18)

To get the checksum of 2E701235, export all the segments, order the segments by their addresses, then combine them (e.g. in a hex editor) directly. Do not add padding for the empty space. The file should be 794,568 bytes and have the same checksum. The checksum is regular CRC32, standard polynomial.

Bad news: I tried fixing the CRC so that a modified firmware also has the same 2E701235 checksum. First attempt was by extending the firmware by 4 bytes to add a CRC fix. Second attempt was by overwriting the last 4 bytes with the CRC fix.

Both attempts were rejected by the ECU which implies that there are more protections apart from this checksum (..or my technique is incorrect). There may also be more information that is wrapped within the 128-byte signature, but I do not know what it contains. This might also explain why the CR4NFZ does not even include a CRC when sending the signature verification request.

Regrettably, manipulating the CRC (which would have been a nice generic method) does not seem to work and I do not know of a way forward with regard to mitigating the flash verification.

[Feezex]

you used some script to flash ic204 with UnsignedFlash. Maybe such method will work for others?

[jglim]

The technique is specific to the exact firmware version of that ECU. I have written in detail on the entire process so that anyone can try to replicate it. I do not know if it will work for other ECUs; this remains for others to investigate as I do not have the time (or ECUs) to do so.

If the signature verification is similar to IC204, the ECU (not Vediamo) also writes special additional data into the flash memory only if it is successful. Bypassing the error message in Vediamo (e.g. emulating a successful message) will not work since Vediamo has no control over this special data. If this data is not written, the ECU will not boot normally after reset.

[Feezex]

Notes on the cff algo.
Once you need to update your ECU with new cff - you get cff and flash ECU. Theres no tips and tricks. By that cff update we get anoter rule. ECU data has nothing to match with new cff data but it works.
Doesnt matter which SW is current in ECU - so CFF data sectors are *protected by CCC maps 3 times in single CFF + CRC in the end of file.
*Protected - is a failsafe protection, protection of data loss during transfer. After transfering data to ecu - theres no need to read it all again to make sure its been written fine but theres a checkpoints to do that. Possible CCC models:

1. CFFoffset1+checkdata, CFFoffset2+checkdata, CFFoffset3+checkdata.....
2. CFFoffset+CS, CFFoffset+CS
3. sectorN1+CRC, sectorN2+CRC,sectorN3+CRC, sectorN4+CRC (if we have 4 data sectors)
4. and many more..
   All may be encrypted to compress data.
   One more experiment to do- breakpoint on 31 E1 04 00 00 00 80 (dont allow this packet reach ECU)+ emulated 71 E1 00 00 FF FF answer to vediamo - If it will pass and write modified file- then we have deal with trafo protection against unsigned cff's

[Feezex]

Vediamo CAN verification log for sucess flashing
57,912 7E0 8 10 87 31 E1 04 00 00 00
57,912 7E8 8 30 08 00 00 00 00 00 00
57,912 7E0 8 21 80 94 FD FE 93 00 E2
57,914 7E0 8 22 74 A3 E4 56 B1 9C CD
57,915 7E0 8 23 CC 69 6D 71 58 95 A0
57,916 7E0 8 24 97 68 12 D6 E6 1C 86
57,917 7E0 8 25 69 0D 75 6A 05 C5 21
57,919 7E0 8 26 B0 45 9A 99 EC D5 26
57,920 7E0 8 27 54 80 B4 A5 E9 8A A5
57,921 7E0 8 28 61 B1 E2 FE 6E B2 D0
57,921 7E8 8 30 08 00 00 00 00 00 00
57,922 7E0 8 29 B8 9B EA 52 4B 79 38
57,923 7E0 8 2A B4 5A F1 75 E3 78 3B
57,924 7E0 8 2B 4F C2 58 22 20 8F 29
57,926 7E0 8 2C F6 77 DC E7 C9 B7 16
57,927 7E0 8 2D 7A 88 B4 E9 69 0A 84
57,928 7E0 8 2E C2 33 A2 DA 01 DD D0
57,930 7E0 8 2F 0E 1A E6 93 C6 9A 9D
57,931 7E0 8 20 F5 36 E5 05 9D 08 B0
57,931 7E8 8 30 08 00 00 00 00 00 00
57,932 7E0 8 21 19 48 D1 09 80 7C F6
57,933 7E0 8 22 D8 C1 6B F0 70 BF 3A
57,934 7E0 8 23 86 D7 AA 00 00 00 00
57,935 7E8 8 03 7F 31 78 00 00 00 00
01,181 7E8 8 06 71 E1 00 00 FF FF 00
01,216 7E0 8 02 11 01 00 00 00 00 00
01,217 7E8 8 01 51 00 00 00 00 00 00

[jglim]

Tidying this up as an isotp representation for readability:

host:	31 E1 04 00 00 00 80 94 FD FE 93 00 E2 74 A3 E4 56 B1 9C CD CC 69 6D 71 58 95 A0 97 68 12 D6 E6 1C 86 69 0D 75 6A 05 C5 21 B0 45 9A 99 EC D5 26 54 80 B4 A5 E9 8A A5 61 B1 E2 FE 6E B2 D0 B8 9B EA 52 4B 79 38 B4 5A F1 75 E3 78 3B 4F C2 58 22 20 8F 29 F6 77 DC E7 C9 B7 16 7A 88 B4 E9 69 0A 84 C2 33 A2 DA 01 DD D0 0E 1A E6 93 C6 9A 9D F5 36 E5 05 9D 08 B0 19 48 D1 09 80 7C F6 D8 C1 6B F0 70 BF 3A 86 D7 AA

ecu:	7F 31 78 

ecu:	71 E1 00 00 FF FF

host:	11 01 

ecu:	51

Edit: looks pretty much the same as the trace here : #47 (reply in thread)

[Feezex]

Got another hint from cxf.
| | |---** Number of securities: 1
| | ---Security Table 0
| | |---Method: STRING: CCC
| | |---FW Signature: DUMP: 0x94 DUMP: 0xfd DUMP: 0xfe DUMP: 0x93 DUMP: 0x00 DUMP: 0xe2 DUMP: 0x74 DUMP: 0xa3 DUMP: 0xe4 DUMP: 0x56 DUMP: 0xb1 DUMP: 0x9c DUMP: 0xcd DUMP: 0xcc DUMP: 0x69 DUMP: 0x6d DUMP: 0x71 DUMP: 0x58 DUMP: 0x95 DUMP: 0xa0 ...
| | |---Check Sum: Not available
| | ---ECU Key: DUMP: 0x41 DUMP: 0x30 DUMP: 0x30 DUMP: 0x36 DUMP: 0x34 DUMP: 0x34 DUMP: 0x36 DUMP: 0x39 DUMP: 0x34 DUMP: 0x34 DUMP: 0x30
| |--- Number of expected idents: 0
| ---* Number of securities: 0
|---** Number of flash classes: 1
*---Flash Class 0
|---Identifier: CR4NFZ.6469025800_001.095000
|---Qualifier: 095000
|---Long-Name: 095000
|---Description: Not available
*---Unique Object ID: Not available

[Feezex]

DS: FN_Start_Check_Checksum_Routine Checksun Routine starten
Longname: Checksun Routine starten
Qualifier: FN_Start_Check_Checksum_Routine Klasse:Function
Accesslevel:1
Securityaccesslevel:0
Is executable: TRUE
Minlength:10
Maxlength:10
** Number of Preparations: 10
PREP-0 [Not available]
Type:CONSTANT
--- Name: SID
--- Data type: BYTE
--- Byte position: 0
--- Byte length: 1 PREP-1 [Not available]
Type:CONSTANT
--- Name: Lid
--- Data type: BYTE
--- Byte position: 1
--- Byte length: 1 PREP-2 [Not available]
Type:CONSTANT
--- Name: memoryId (highNibble) + startAdress (lowNibble of highByte)
--- Data type: BYTE
--- Byte position: 2
--- Byte length: 1 PREP-3 [Not available]
Type:CONSTANT
--- Name: startAdress (middleByte)
--- Data type: BYTE
--- Byte position: 3
--- Byte length: 1 PREP-4 [Not available]
Type:CONSTANT
--- Name: startAdress (lowByte)
--- Data type: BYTE
--- Byte position: 4
--- Byte length: 1 PREP-5 [Not available]
Type:CONSTANT
--- Name: memoryId (highNibble) + endAdress (lowNibble of highByte)
--- Data type: BYTE
--- Byte position: 5
--- Byte length: 1 PREP-6 [Not available]
Type:CONSTANT
--- Name: endAdress (middleByte)
--- Data type: BYTE
--- Byte position: 6
--- Byte length: 1 PREP-7 [Not available]
Type:CONSTANT
--- Name: endAdress (lowByte)
--- Data type: BYTE
--- Byte position: 7
--- Byte length: 1 PREP-8 [Not available]
Type:CONSTANT
--- Name: CRC lowByte)
--- Data type: BYTE
--- Byte position: 8
--- Byte length: 1 PREP-9 [Not available]
Type:CONSTANT
--- Name: CRC (highByte)
--- Data type: BYTE
--- Byte position: 9
--- Byte length: 1
CS: 31 01 00 00 00 00 00 00 00 00

[outlaw-50]

Good luck guys on the hard work hope you get to a solution

[Feezex]

have you think about removing CCC blocks? Im thinking of compare similar cffs to determine all 3 blocks. 1 and 3 is easy, but second string have pre bytes, which must be removed to set Number of securities to 0 (as far as i think- it is).
At that moment i understand that data blocks has not much influence to CCC. CS blocks seems the key for CCC

[jglim]

Welcome back, and no, I still do not know how the what the actual block structure looks like, as well as the actual block boundaries. My prior exploit only wrote the "block verified" indicator manually, which was accidentally left unprotected. Nothing else regarding the block headers were modified.

I am not sure of what to expect if the block headers are removed but if I had to guess from earlier behavior, that the device will most likely be stuck in bootmode.

[Feezex]

One more thought.
Sorted my cff database by file size. Smallest cffs with CCC is for HUD177(Head Up Display) with low amount of data (Almost all is "00").
But i do have ARCADE221 and its cff is only 7kb, and its partial eeprom data.
Vedi trace looks different but i cant understand data blocks are transfered
Airbag 0285001996.zip

[jglim]

I added some notes to your trace: Flash_trace_2214470842_001_jg.txt

The key takeaway that might be a source of confusion, is that some parts of transferred flash block is embedded and "hidden" in the CBF, which may explain why the trace looks different.

The flash data written to 0x100600, size 0x1028 can be found in chunks inside ARCADE221.CBF. As an example in my CBF, ctrl+f for:

09 00 01 47 00 10 06 14 00 10 06 28 00 10 06 3C 00 10 06 50 E9 2D 40 08 E5 8D 00 00 E5 9D 00 00 EB 00 03 76 E8 BD 80 08 E9 2D 40 08 E5 8D 00 00 E5 9D 00 00 EB 00 03 6B E8 BD 80 08 E9 2D 40 08 E5 8D 00 00 E5 9D 00 00 EB 00 03 5B E8 BD 80 08 E9 2D 40 08 E5 8D 00 00 E5 9D 00 00 EB 00 03 50 E8 BD 80 08 B0 81 90 00 21 00 98 00 80 81 98 00 78 80 28

After this unknown block is written, the CFF data from 2214470842_001 is written to 0x400028 and verified. I assume that these transfers are automatically hidden in the traces, but will be visible on the raw can bus.

[N0cynym]

31E0 = Flash Erase Routine

[Feezex]

To make comparison i took same smr-d file that have correct name for thing we call CCC.
<FLASHDATA-HANDLING>
<FLASHKEYS>
<FLASHKEY FLASHKEY="2214470842_001" NEW_FLASHKEY="2214470842_001">
<DATABLOCK-PROPERTIES>
<DATABLOCK-PROPERTY DATABLOCK-SHORTNAME="A2214470842_PARAMETERDATEN_AIRBAG_ECE_0643_00" CREATE-NEW-SECURITY-ELEMENT="false">
<SECURITY-CLASS>CCC</SECURITY-CLASS>
<SECURITY-KEY>A2218704887</SECURITY-KEY>
<SIGNATURE>
4AD3F5E64F12552B582850B1B0BEAFC9E2D09848B13CF62F77C3D4D1A206D5F03C5BDB89462F9926A5E0E7A4FD915998CFE37370F85B946B6717VGf6WqoM7Wa59f3ak8hoAZ8yr7d2VbTb02BCB3LcKWitA5ezLi78Q6BRPPxfURxT41jS8HF0309C018DC0D87D7A40CA0AA4F45C467894E4E8C3M98ULQdLu49eSYwHhshCH56q9DkcjajCG04BA4AE5E2BCB0412
</SIGNATURE>
</DATABLOCK-POPERTY>
</DATABLOCK-PROPERTIES>
</FLASHKEY>
</FLASHKEYS>
</FLASHDATA-HANDLING>
</TRANSFORMATION-DIRECTIVE>
</TRANSFORMATION-JOB>

and a string drom CFF

[Feezex]

Also found some hint.
..... Manual/Daimler/BaseSystem.pdf
6.1.8.3 Change of flash properties
Transformation can be configured to update several flash elements from database:

1. FLASHKEY elements update
   The existing value of ”FLASHKEY” (PARTNUMBER in ODX) shall be replaced by a
   new value from ”NEW FLASHKEY”.

2. SECURITY elements update Following scenarios are covered: • insert a SECURITY element at the first position (in front of all existing);
• replace all existing SECURITY elements with that found in the config file;

Trafo will check the attribute CREATE-NEW-SECURITY-ELEMENT and :
• when is TRUE, a new SECURITY element will be created containing the specified values for properties SECURITY-CLASS, SECURITY-KEY, SIGNATURE and CHECKSUM;
• when is FALSE, only the indicated properties will be updated and only for the first SECURITY element;

[Feezex]

Since Caesar does signature check i decided to check c32s.dll from vediamo package.
And yes it have that function.
uint DIGetSecurityFWSignature(size_t *param_1,short *param_2,void **param_3,size_t *param_4)

[Feezex]

How about using unsecured cff as a sketch - modify flashkey, meaning, qualifier, priority etc.
Like- export cff specs to template, add flash section and then fix only checksum.
Tried some modifications with unCCC'ed cff, and they pass all checks.
Still having problems with some parts of cff - dont want to accept changes, e.g
00 06 00 43 52 33 55 50 00 2D 69 = ���CR3UP�-i
00 06 00 43 52 34 4E 46 5A 00 00 2D 69 = ���CR4NFZ��-i
where is 06 00 is a pointer to "name start" and next 00 \ 00 00 is end.

[jglim]

I am unable to see a way to make major changes to a new CFF without inadvertently breaking the file.

Take the flash splicer as an example -- it works by rebuilding only the flash payload section (whose layout is fully understood, and is not affected by other sections since it is at the end of the file), then patching the offsets in the existing flash table. The flash table size and number of entries remains unchanged.

Making changes such as adding/removing content is difficult as the file is made up of a collection of internal file offsets. Any changes that affect the file size will most likely misalign all subsequent offsets, making the file unreadable.

For now, I think the easiest way is (still) your technique of using a hex editor and fix the checksum afterwards.

It might also be worth noting that patching an existing CFF for a different ECU may lead to unexpected behavior from the embedded flash script. For example, it may use a different unlock algo, or after entering programming mode, the flash script might compare the variant ID with a different hard-coded value.

---

If I could suggest a different technique, it should be easier to send the firmware manually as CAN/UDS frames manually by writing a custom flasher. This will give you full control of the flash process.

[Feezex]

variant id is stored in flash offsets section and can be easily modified, but we knew nonthing about hardcoded part..
If we do have success in rebuild single CR3_UP unCCC'ed cff - we woudnt have universal solution for all other ecus.
Even having good and best in stock flasher this becomes a huge challenge for me.
I just dont want to give up.

[mbsmartdiag]

hello together
many thanks for the great software

I have read your discussion with enthusiasm
and hope that you are still in the process of finding a solution
what software do you use to edit bin.?
greetings from germany

[Feezex]

im using WinOls

[N0cynym]

If you want to edit binary files you can use multiple tools.

For example:

• Hexed
• ImHex
• Rusty Hex Edit

[N0cynym]

im using WinOls

It's the best tool to work on maps.

[diegohmarciano]

Hi pals,
Just trying to collaborate here on improvement, be it either knowledge or troubleshooting.
I've been messing around for a long time with CFF files, with either WinOls pluging, CaesarSuite, or Samik's CFF2BIN (And AVDI dump tool to try fixing CRC).

I was always successful at exporting data from CFF files to I can use that for different purposes, like tuning, DTC, etc and later on writting with either Autotuner, Flex, or AVDI. However, each time I tried to modify a CFF file and flash that to the ECU I was a complete failure, either the ECU would vediamo would fail on the post verification, or vediamo would say that the CFF is missing flash data.

So far as per everything I have read here, in other places, and tried myself I understand I do have some missconception somewhere but can understand where so if anyone has any hint or can help me understand a few things would be awesome:

• That I'm able to read the data from a CFF file doesn't mean that it is unencrypted and that I can patch it to flash whatever I want right?
• In case the problem is the encryption itself, would it be a valid test to find some old unencrypted CFF file and use that for patching?
• My understanding after reading the discussion here is that even if I can extract the flash data area because the structure is known, there are still unknown security areas in the CFF and that it will be the main source of issues when the post flash verification executes in the ECU and fails, correct?

It is just that, at this point I tried so many things that I'm looking mostly for a "you cannot do that so will never work" or a "yes it is possible but you are doing it wrong".

Thanks everyone!

[jglim]

Hey and welcome back,

That I'm able to read the data from a CFF file doesn't mean that it is unencrypted and that I can patch it to flash whatever I want right?

I haven't touched any encrypted MB firmware till date so I'd generalize that most MB firmware embedded in CFF is unencrypted. You can patch them and fix the CFF container's checksum, and Vediamo should load the CFF without complaints. Things get trickier if you resize the segments by adding or removing bytes in the flash as it'll break some file offsets but this isn't a protection scheme, it's a file format issue.

In case the problem is the encryption itself, would it be a valid test to find some old unencrypted CFF file and use that for patching?

I can at least confirm that these are unencrypted, though in general it's safe to assume that most CFF are unencrypted.

sha1
D95485D5737888A765FB6098229E63308B234C18 2049022702_001.cff
5DDD6263A5399CAE6FE6F715C5914CB13F7BE0D1 2049022802_001.cff

My understanding after reading the discussion here is that even if I can extract the flash data area because the structure is known, there are still unknown security areas in the CFF and that it will be the main source of issues when the post flash verification executes in the ECU and fails, correct?

At least on the IC204, I can confirm that the firmware is signed and modifying the firmware breaks the signature. If the signature is broken, the ECU will not mark the flash as valid, and it will always remain in bootmode until it receives a valid firmware image. I was only able to deliver a modified payload as I found a vulnerability in their signature check.

Bear in mind that flashing via CAN is effectively going through the "front door" where checks are present. I still do not know how tuners or WinOLS users are able to write their changes back onto the ECU. My assumption is that they use "back door" techniques like writing through physical means such as JTAG/BDM but I could be wrong.

Tagging @Feezex on this as he's an actual workshop expert, maybe he can offer some advice if he's available.

It is just that, at this point I tried so many things that I'm looking mostly for a "you cannot do that so will never work" or a "yes it is possible but you are doing it wrong".

yes it is possible but (for most parts) you cannot simply deliver a modified payload

[diegohmarciano]

Hi pals, Thanks for your answers!! Awesome, I'm workshop too, I do programming/coding and tuning. Mostly on MB as I work closely with a few MB workshops. Will retry once more today on an ME9.7, I have a few around, and I think I also had a SIM266 but that is older. On ME9.7 I was able to get to the point where I it flashed but failed verification. SIM271 CFFs for some reason once modified Vediamo stopped recognizing FLASH_DATA (Complaining that the CFF was missing it) What I finally did because I had that ecu here for coding and tuning, I matched the CFF at the locations I needed and wrote it back with another interface. Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: JinGen Lim ***@***.***> Sent: Thursday, February 20, 2025 2:12:37 AM To: jglim/CaesarSuite ***@***.***> Cc: Diego Hernan Marciano ***@***.***>; Comment ***@***.***> Subject: Re: [jglim/CaesarSuite] CFF Flash Files (Discussion #47) Hey and welcome back, That I'm able to read the data from a CFF file doesn't mean that it is unencrypted and that I can patch it to flash whatever I want right? I haven't touched any encrypted MB firmware till date so I'd generalize that most MB firmware embedded in CFF is unencrypted. You can patch them and fix the CFF container's checksum<https://github.com/jglim/CaesarSuite/blob/580f846bf1e9797e04f77492195de9cd0f4be4c7/Caesar/Caesar/CaesarContainer.cs#L70>, and Vediamo should load the CFF without complaints. Things get trickier if you resize the segments by adding or removing bytes in the flash as it'll break some file offsets but this isn't a protection scheme, it's a file format issue. In case the problem is the encryption itself, would it be a valid test to find some old unencrypted CFF file and use that for patching? I can at least confirm that these are unencrypted, though in general it's safe to assume that most CFF are unencrypted. sha1 D95485D5737888A765FB6098229E63308B234C18 2049022702_001.cff 5DDD6263A5399CAE6FE6F715C5914CB13F7BE0D1 2049022802_001.cff My understanding after reading the discussion here is that even if I can extract the flash data area because the structure is known, there are still unknown security areas in the CFF and that it will be the main source of issues when the post flash verification executes in the ECU and fails, correct? At least on the IC204, I can confirm that the firmware is signed and modifying the firmware breaks the signature. If the signature is broken, the ECU will not mark the flash as valid, and it will always remain in bootmode until it receives a valid firmware image. I was only able to deliver a modified payload as I found a vulnerability<https://github.com/jglim/UnsignedFlash/> in their signature check. Bear in mind that flashing via CAN is effectively going through the "front door" where checks are present. I still do not know how tuners or WinOLS users are able to write their changes back onto the ECU. My assumption is that they use "back door" techniques like writing through physical means such as JTAG/BDM but I could be wrong. Tagging @Feezex<https://github.com/Feezex> on this as he's an actual workshop expert, maybe he can offer some advice if he's available. It is just that, at this point I tried so many things that I'm looking mostly for a "you cannot do that so will never work" or a "yes it is possible but you are doing it wrong". yes it is possible but (for most parts) you cannot simply deliver a modified payload — Reply to this email directly, view it on GitHub<#47 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACM5ILLILHZFWHGHBBCH6RL2QVP4LAVCNFSM6AAAAABXPWYQPOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMRVHAZDCOA>. You are receiving this because you commented.Message ID: ***@***.***>

[diegohmarciano]

I wasn't able to get to a similar function, to be honest I need to take a second look, you know how ghidra psecudo can sometimes be a pain to follow.

Regarding the logs, I have prepared a dedicated bench to work uniquely with the ECU (ME9.7 in this case) and be able to compare both, last night I logged a flash with Vediamo and the C4 as a test and it looks good, had to filter a few IDs that I think are sent by the ME9.7 and that flood the logging, so I ended up with like 4 or 5 IDs that were about hte communication itself.

So will record that, and a broken flash (One with a modified CFF that fails). And then will record a read and a write session, first of the same content, and then with the same modificaitons of the broken CFF, so we can compare apples with apples.

[diegohmarciano]

I feel like crap coming here like a year after but I just started dedicating time to this again now.
So I did quite a bit of analysis already by disassembling ME9.7 completely, found a way to patch it for unsigned code flashing (did it on boot mode though first, and then I can flash unsigned code over and over). Still trying to find a way to do it without having to get to boot.
Replying to my past myself, modified CFF flashing with vediamo is not possible, at least on this ecu it won't be, unless you patch it like I did which is non sense anyways because still requires another tool work in boot mode. RSA signature will get validated always (by vediamo trigerring the verification) after the ecu gets flashed, and only turn to true the values for CRC32 and signature verification to "ok". However, MB was a bit weird on that it left kind of a bypass value for the CRC32 verification, they worry about the signature, and still found no way other than patching the KBB code to skip it. I'm trying a few more things these days.

[jglim]

Small note on Vediamo triggering validation, specifically it's the embedded script for the flash routine that sends that request. It's likely possible that you can patch a CFF enough to skip that (if you have a strong tolerance or liking for pain, and a sense of adventure)

V2 branch has very basic interpreter support: https://github.com/jglim/CaesarSuite/blob/v2/Caesar/Interpreter/Interpreter.cs

[diegohmarciano]

I have a battery of python scripts so far where I'm doing it all manually, to have a bit more direct view and easy manipulation of what is going on.
I tried already everything, manipulating the checksum (they use a magic value, but is not enough alone, RSA blocks it next), corrupting RSA, corrupting KBB area in purpose (I'm not afraid of this ecu, I saved them multiple times, can go boot mode if necessary, but I'm twisting it as much as I can do them without going boot mode). Cal area you leave the magic chk bypass value (as they use in their own CFFs for cal area), and then dummy RSA and it will work anyways, no issues, code area however I found no way yet to do it completely over can. However there is one section I can override at 403000 which disables the RSA completely, the problem is I have to do it at boot mode, which I do not like or I am trying to avoid. so still playing with it a bit. If anyone wants to play it I have a full CPP export of hte ecu for these segments:

Code Segments

BOOT_SEGMENTS = [
{"name": "Boot", "start": 0x000000, "end": 0x01FFFF}, # Size: 0x20000
]

CODE_SEGMENTS = [
{"name": "KBB", "start": 0x020000, "end": 0x03FFFF}, # Size: 0x20000
{"name": "Prog0", "start": 0x040000, "end": 0x0EFFFF}, # Size: 0xB0000
{"name": "Prog1", "start": 0x0F0000, "end": 0x1BFFFF}, # Size: 0xD0000
{"name": "Prog2", "start": 0x404000, "end": 0x47FFFF}, # Size: 0x7C000
]

Calibration Segments (use A2L sizes, will FF-pad to match OEM format)

CALIBRATION_SEGMENTS = [
{"name": "Cal1", "start": 0x1C2000, "end": 0x1DFFFF}, # Size: 0x1E000
{"name": "Cal2", "start": 0x1E0000, "end": 0x1FFFFF}, # Size: 0x20000
]

RAM Segments (current + mirrors + ETK)

RAM_SEGMENTS = [
{"name": "Cal1_Mirror", "start": 0x5C2000, "end": 0x5DFFFF}, # Cal1 RAM Overlay
{"name": "Cal2_Mirror", "start": 0x5E0000, "end": 0x5FFFFF}, # Cal2 RAM Overlay
{"name": "RAM1", "start": 0x7F8000, "end": 0x7FFFFF}, # Internal RAM
{"name": "RAM2", "start": 0x800000, "end": 0x803FFF}, # Extended RAM
{"name": "RAM3", "start": 0x804000, "end": 0x83FFFF}, # Extended RAM
{"name": "RAM_ETK", "start": 0x900000, "end": 0x901FFF}, # ETK Trigger/Var
]

[diegohmarciano]

I'm though still missing the EEPROM mirror as I haven't found it on what I exported