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]

S1872210.zip
here is full bdm of current ecu

[Feezex]

17:14:52 Request:
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
17:14:54 CR4_NFZ:
71 E1 00 01 FF FF

signature failed.txt

[Feezex]

this time i mod flash including 1st CS block.
Error: Service execution failed. Reason: CAESAR:ProgBlock: 20084: FLASH - Signature Check Failed: CAESAR:ProgBlock: 20084: FLASH - Signature Check Failed

[Feezex]

So
71 E1 00 00 FF FF - Pass
71 E1 00 01 FF FF - Fail

[Feezex]

another step i can trace can while flashing with external programmer.
Most interest part is verification in the end

[jglim]

From your trace, this is what I observe

CR4_NFZ
Flash block: 6469025800_095000

Security [0]
 - Method : 434343
 - Signature : 94FDFE9300E274A3E456B19CCDCC696D715895A0976812D6E61C86690D756A05C521B0459A99ECD5265480B4A5E98AA561B1E2FE6EB2D0B89BEA524B7938B45AF175E3783B4FC25822208F29F677DCE7C9B7167A88B4E9690A84C233A2DA01DDD00E1AE693C69A9DF536E5059D08B01948D109807CF6D8C16BF070BF3A86D7AA
 - ECU : 4130303634343639343430
----------------------------------
// host: exit transfer
37

// ecu: exit transfer ack
77

// host: verify checksum

128 bytes CCC signature for checksum verification
signature is usually matched with a checksum, but i have no idea where the cs value is for cr4_nfz
CFF securities table has no checksum

31 E1    04 00 00 00   (size 0x80 bytes?) 80    
(payload) 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: checksum okay
71 E1 00 00 FF FF 

// host: reset
11 01 

For comparison, a snippet from flashing the IC204:

IC_204
Flash block: A2049022702_W212_047000_rel_E_TESTER_P0

Security [0]
 - Method : 434343
 - Signature : 30EF0D46C8C34B0D16CA11B5D83941FC7453748D0B862ED51E4CC7848001269E1F61729423FD332C99640E0D7B36DC0C6F4DAE2ABFD9C128995F0A0BB83512BAD2369BC5FBC50B05979B20014D9EB61F7042B0F1FF1839A08B4AEE63CACFDFDF3AA8710581F8CEE5E3EFB3E85FF7AA4D5FA6CCD2694855D47A6D6C6B89D6B972
 - ECU : 4132313239303133313030

Security [1]
 - Checksum : 2E701235
----------------------------------
// host: exit transfer
37

// ecu: exit transfer ack
77

// host: verify checksum
31 01 ff 01     2e 70 12 35     30 ef 0d 46 c8 c3 4b 0d 16 ca 11 b5 d8 39 41 fc 74 53 74 8d 0b 86 2e d5 1e 4c c7 84 80 01 26 9e 1f 61 72 94 23 fd 33 2c 99 64 0e 0d 7b 36 dc 0c 6f 4d ae 2a bf d9 c1 28 99 5f 0a 0b b8 35 12 ba d2 36 9b c5 fb c5 0b 05 97 9b 20 01 4d 9e b6 1f 70 42 b0 f1 ff 18 39 a0 8b 4a ee 63 ca cf df df 3a a8 71 05 81 f8 ce e5 e3 ef b3 e8 5f f7 aa 4d 5f a6 cc d2 69 48 55 d4 7a 6d 6c 6b 89 d6 b9 72

// ecu: please wait (ignore)
7f 31 78

// ecu: checksum okay
71 01 ff 01 00

// host: reset
11 01

One difference is that the IC204 has checksum+signature, while CR4NFZ only has signature.

IC204 signature verification:

31 01 ff 01     	// RT_Check_Routine_Start_Signature_Check	
2e 70 12 35     // Checksum (see security[1])
30 ef 0d 46 c8 c3 4b 0d 16 ca 11 b5 d8 39 41 fc 74 53 74 8d 0b 86 2e d5 1e 4c c7 84 80 01 26 9e 1f 61 72 94 23 fd 33 2c 99 64 0e 0d 7b 36 dc 0c 6f 4d ae 2a bf d9 c1 28 99 5f 0a 0b b8 35 12 ba d2 36 9b c5 fb c5 0b 05 97 9b 20 01 4d 9e b6 1f 70 42 b0 f1 ff 18 39 a0 8b 4a ee 63 ca cf df df 3a a8 71 05 81 f8 ce e5 e3 ef b3 e8 5f f7 aa 4d 5f a6 cc d2 69 48 55 d4 7a 6d 6c 6b 89 d6 b9 72  
// Signature (see security[0])

CR4NFZ signature verification:

31 E1    // RT/FN, no known name
04 00 00 00   // ?? no idea
80    // Signature size 0x80 bytes?
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 
// Signature (see security[0])

In any case, normal flash modification via flash splicer will not work for the CR4NFZ because it uses signature verification. If there is some tool that is capable of flashing modded CR4NFZ flashdata through the CAN bus, we can at least try to guess how it is done from traces.

[Feezex]

i can post both original CS Blocks for this signature if this my be useful
Previously i posted full bdm.
Ext flash :
CS1 : 17FF70-17FFFF
CS2: 1FCF70-1FCFFF (this one is separate part of cff)

[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.