"Unsigned flash" related discussion

[Feezex]

Sorry for starting it here , but original one is in Public archive state. Im about to retrofit my monochrome ic204 to color one. So it can be a good spot to learn more about it, edit some menu, icons etc. Since @jglim done it before and @VladLupashevskyi made interesting things with IC. My question is:

1. I need to get mcu dump to get the const verification value or it can possibly be read by can?
2. @jglim can you explain icons decrypt, i need a hint because i cant find any in files you been using due experiment.
3. I want to make my own localization due this small project, so to get full menu tree or localization indexes - internal slash may be needed.
4. i tried this d70f3421 with vvdi prog, got identification only, mcu is locked. So i need here another programmer such as orange5 with v850 licence. Which one you been using?

[jglim]

Take note that the mcu that I worked on was µPD70F3426 (note the last digit, yours is 1), there might be subtle differences:

For (1) and (4), if your objective is to modify the firmware, I believe there's an easier way that does not care about the verification checkpoints. If you can unlock the device through seed key to enable uds memory reads, you should also be able to dump the entire firmware. This dump only needs to be done once, after which you can then freely modify it and write it back using your programmer. The mcu is locked by default, but you can erase and write the dumped firmware back, and leave the protection off this time.

It might be worth noting that there is a risk of bricking the mcu if there are extra config/parameters (e.g. fuses, clock source) that were not properly migrated. I ignored this while using an orange5, which was risky, but was lucky that the reflash was successful.

As far as I remember, there are no checksums that prevent a modified firmware from booting, as long as the verification constants are present.

Also, since you have taken off the protection after writing back the dump, you now have the capability to read back the flash. You should then be able to compare the dumps of a working flash, and a bad flash to identify the addresses and values of the verification checkpoints. In my case, I found those using ghidra, but I believe that comparing 2 flash dumps will be a lot faster.

(3) I don't quite understand the question.

(2) is fairly straightforward for monochrome devices. The images are uncompressed binary bitmaps, so each byte contains 8 pixels, either on or off. The images should be visible when you fiddle with the length and alignment:

---

Back then, I also experimented with replacing the amg logo with bmw m-sport logo, but I never got to see it in action as I could not find out how to send the steering wheel button messages to the cluster. Would have been fun to see that in action

[VladLupashevskyi]

Oh, images are done the same way as on ki211.

There is also must be a structure with width in bits and height in bytes for each image.

[VladLupashevskyi]

What helped me to find them is to open dump in hex editor and enable binary view, then by changing width of window you can notice them rather easy

[Feezex]

2049022702/2049022802 the files you been using, im trying to locate any image here. Can you show any in hex so i can have start point, of what to search. if i understand correctly it must be like :

[jglim]

$ md5sum 2049022802_001.cff
1eb6c9a9e8114a58696224adbb1cbab3  2049022802_001.cff

0x5A1DB:

00 00 00 00 00 00 80 E0 F0 F0 F0 F0 F0 F0 F0 F0 70 10 80 E0 F0 F0 F0 70 10 80 E0 F0 F0 70 10 80 E0 F0 70 10 80 E0 70 10 80 E0 F0 F0 70 30 30 30 30 30 30 30 30 30 70 F0 F0 E0 80 00 00 00 00 00 F0 F0 F0 F0 F0 E0 C0 C0 80 00 00 00 00 00 80 C0 C0 E0 F0 F0 F0 F0 F0 00 00 F0 F0 F0 F0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 00 00 00 
00 00 00 20 38 3E 3F 3F 3F 3F 3F 3F 3F 1F 07 21 38 3E 3F 3F 1F 07 21 38 3E 3F 1F 07 21 38 3E 1F 07 21 38 1E 07 21 38 3E 3F 1F 0F 0F 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0F 0F 1F 3F 3E 38 20 00 00 3F 3F 3F 3F 00 01 01 03 03 07 07 06 07 07 03 03 01 00 00 3F 3F 3F 3F 00 00 3F 3F 3F 3F 30 30 30 30 33 33 33 33 33 33 33 33 33 3F 3F 3F 3F 00 00 00

-----------------------------------------------------------------------------------------------------------------
1                                                                                                                 
2                                                                                                                 
3                                                                                                                 
4                                                                                                                 
5        ██████████  █████  ████  ███  ██  ███████████████       █████             █████  █████████████████████   
6       ██████████  █████  ████  ███  ██  █████████████████      ██████           ██████  █████████████████████   
7       ██████████  █████  ████  ███  ██  ████         ████      ████████       ████████  ████                    
8      ██████████  █████  ████  ███  ██  ████           ████     █████████     █████████  ████                    
-----------------------------------------------------------------------------------------------------------------
1      ██████████  █████  ████  ███  ██  ████           ████     ████ ██████ █████  ████  ████    █████████████   
2     ██████████  █████  ████  ███  ██  █████████████████████    ████   █████████   ████  ████    █████████████   
3     ██████████  █████  ████  ███  ██  █████████████████████    ████     █████     ████  ████             ████   
4    ██████████  █████  ████  ███  ██  ███████████████████████   ████               ████  ████             ████   
5    ██████████  █████  ████  ███  ██  ████               ████   ████               ████  █████████████████████   
6   ██████████  █████  ████  ███  ██  ████                 ████  ████               ████  █████████████████████   
7                                                                                                                 
8                                                                                                                 
-----------------------------------------------------------------------------------------------------------------

[Feezex]

recommend an editor plz @jglim you havent mentioned image flipped 90^ clockwise, pff it almost blow my mind, but that can help in future. Wonder how color ones are made, as rgb? there must be 3 color layers?

[Feezex]

Seed level 0D doesnt allow to read those sectors, so i was able to read memory 0x0 to 0x10B18 , 66,7kb only. Question about verification checkpoints. Are they stored in cff's? I guess flash routine (cbf,cff or conrol unit side )decode checkpoint values from cff's CCC block, compares whem with data written. So thats another task from another thread., Basically to modify cff , CCC block must be fixed with new checksums + main cff Cks. Seems only cff knews exact way to extract those values. We can try move to some smr-d , since it can be decoded, and flash process can be revealed. For ODX only control units CFF's are also avaliable, so here we can get the pack of data : CCC decode sequence & data to verify it works properly. Such function will make huge advantage to UnlockECU, so anyone will be able to modify cff and write it withought external programmer. Here i will mention that actions like that requires full understanding of risk, its unsafe and can destroy control unit, but that must be written with red in header of new UnlockECU tab =) @jglim you used script to write back verification keys after flash and before 31 01 ff 01 (RT_Check_Routine_Start_Signature_Check), but you got them from mcu full read, unfortunately i can't read mcu for now. Playing with color cffs doesnt gave any result yet, cant detect bitmaps and dont understand how they are implemented.

[Feezex]

this looks very similar to @jglim case but not the same. @jglim can you share your mcu dump so i can learn more about it.

[jglim]

I don't think there's an editor for monochrome bitmaps for this use case. It should be easier to diy by converting the bytes into pixels and dumping them into a file where you can resize the window to find patterns.

No idea about rgb, depends on display type and image modes. Typical embedded displays tends to be rgb565 or argb4444, better screens use rgb888/argb8888. Like the monochrome, you'll need to find the patterns and work from there.

Checkpoints are not stored in CFF. The flash is transferred without any changes, and the checkpoints are written when the signature check 31 01 FF 01 is called. I've written about the 204 flash messages here earlier: https://github.com/jglim/UnlockECU/issues/25#issuecomment-1867169191

The flash routine is fairly straightforward and doesn't handle any of the security aspects. It is designed to be untrusted with the assumption that the end users (e.g. us) are capable of emulating or tampering with the messages. The actual check is done on the ECU.

MB holds a private key which is never shared, and the corresponding public key is embedded in the ECU. When MB pushes out a firmware, the private key is used to create a signature of the firmware, and is sent to the ECU with 31 01 FF 01. The ECU then hashes the received firmware, then verifies that (1) the signature can be decrypted by the public key, and (2) the signature output is identical to the previously calculated hash.

The v2 branch has preliminary and very dodgy flash support that works for my 204. It doesn't use a separate flash script, instead it uses the original script that was embedded in the CBF. If you want to figure out how the flashing logic works, you might want to look around there.