Replies: 14 comments 11 replies
-
|
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
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
2049022702/2049022802 the files you been using, im trying to locate any image here. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
recommend an editor plz |
Beta Was this translation helpful? Give feedback.
-
|
Seed level 0D doesnt allow to read those sectors, so i was able to read memory 0x0 to 0x10B18 , 66,7kb only. |
Beta Was this translation helpful? Give feedback.
-
|
this looks very similar to @jglim case but not the same. |
Beta Was this translation helpful? Give feedback.
-
|
This is the base image for the mcu, I have removed the firmware content by filling the firmware segments defined by the CFF with You will need to obtain the CFF for 2049022702 and 2049022802 as those files belong to MB and I can't upload them here. template_2049022702_2049022802.zip |
Beta Was this translation helpful? Give feedback.
-
|
so if the color cluster have 5 cff's, i need to merge all data by offsets to single file - thus how i can get comlete dump |
Beta Was this translation helpful? Give feedback.
-
My earlier post is specific to my mono 204 mcu only, those files are used to assemble the dump for the UPD70F3426GJ mcu. I don't know about color 204 clusters. I assume there is still a NEC mcu as usual, as well as a second coprocessor to drive the color screen (toshiba capricorn?). Might explain why there are 5 CFFs, but I do not know how they are delivered, maybe both mcus sit on the same bus? |
Beta Was this translation helpful? Give feedback.
-
|
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 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 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. |
Beta Was this translation helpful? Give feedback.
-
|
Got a ori o5, and it cannot bypass mcu protection. |
Beta Was this translation helpful? Give feedback.
-
|
If I recall correctly, I used both level 9 and 13. Level 13 seems to be used for write access so you can try with 9 first. My device was also initially protected and had to be erased to remove the lock. Since the full firmware was already dumped earlier over UDS, I could then flash it back onto the device via the o5. |
Beta Was this translation helpful? Give feedback.
-
|
Ok i sorted this things out. My mistake was to read len 0x10000, as i saw that there was no data, but hasnt pay attention that there was no refuse message. So all 256kb done by obd. |
Beta Was this translation helpful? Give feedback.
-
|
uPD70F3421 Security flag information: BOOT SEC: OFF |
Beta Was this translation helpful? Give feedback.
-
|
Interesting thing that 3426 is a 2Mb len, so 0 to 0x1FFFFF. Both of cff files are written to mcu and fits with offsetts. |
Beta Was this translation helpful? Give feedback.
-
|
*256kb mcu took 1 hour to read by obd. |
Beta Was this translation helpful? Give feedback.
-
|
For mono 204: Programming session allows limited write for mcu internal flash. I believe a minimal firmware is running from the RAM (required for self reprogramming) during this state. and there is no support for the external eeprom. Extended session, 0D allows read+write to the external eeprom, and read only for the internal flash. The firmware is running off the internal flash, so it cannot be written to. External programmer can always read+write to external eeprom. For the main mcu, once the protections are off, you can also read+write. I believe the checkpoints can be found by dumping and diffing the firmware; for the first flash, use a clean unmodified CFF, and for the second, skip the signature check. From my experience, as long as the Which hardware and CFF files are you using? Since you have a full dump now you can try using https://binvis.io/ to look for patterns in the memory |
Beta Was this translation helpful? Give feedback.
-
|
@jglim for monochrome - i have same 5a.. keys, if i want modify flash - each time i must write changes with O5 withought changing keys? Seems there no way to write changes directly after seed, even with mcu protection off. For color one. Heres my build: Seems to be - distronic symbol: tried to cut out cup, i find each line starts and ends with alot of garbage which makes image to slip in lines, and thus why hard to identify methods used here. All known here variants in 7yuv cant stabilize any image. Heres is sample image |
Beta Was this translation helpful? Give feedback.
-
|
Yeah the easiest way would be to make changes to your working, bootable dump, then write it back directly with O5. When UDS write memory by address is available, the cluster is booting from internal flash. The internal flash cannot be modified when it is also concurrently in use by the firmware. I believe that the firmware only executes from RAM in bootmode (allowing self-reprogramming), but the UDS write is not implemented in that mode. Protection off only lets you dump the flash anytime, this allows you to compare a good, signed flash, as well as a bad flash to identify where the I looked very briefly at Ressource2_BC000000 but I could not recognize or identify any known color modes. I found it interesting that the bytes at the tail end were consistently increasing in value. Those values appear to be aligned in 4 bytes, and there is always an FF (alpha? assuming full alpha, ARGB or RGBA? The color values did not make sense to me)
|
Beta Was this translation helpful? Give feedback.
-
|
play with with width, as long as you resize dump - different images appears |
Beta Was this translation helpful? Give feedback.
-
|
what going to happen if i fill with FF all 7 5A keys? |
Beta Was this translation helpful? Give feedback.
-
|
The default erased flash state should be Depending on what you remove, there will be different side effects. For example on the mono 204, if the data block does not have a proper signature, it will show the "Reprogramming not correct!" screen. If the application block isn't signed, the screen will be uninitialized, and the device will start in bootmode, and will be accessible on the canbus. |
Beta Was this translation helpful? Give feedback.
-
|
Color cluster in my case include 1276 pictograms. Small investigation on tx mcu usage:
|
Beta Was this translation helpful? Give feedback.
-
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:
Beta Was this translation helpful? Give feedback.
All reactions