Side tracked looking at T87 and T87a TCM controllers.
The T87a is a 5byte seed/key ecu, and also uses signed calibrations hence needs to be 'unlocked' which is basically editing the boot block area I believe to allow using unsigned cals.
Whats interesting is a kernel can be loaded into ram on the T87, but when trying to execute in ram on a T87A.. it will send back a "7EA 03 7F 36 12 AA AA AA AA ".
Basically its the controller saying "Get fucked, Im not doing it".
This is actually controller by the controller itself to whether it will run the code. Probably going through the OS and searching for the 34 routine would indicate the if statement to whether a execution (0x80) is accepted.
Now, looking at the datasheet (
https://www.st.com/resource/en/referenc ... ronics.pdf)
The SRAM area is 0x4000_8000 to 0x4002_FFFF (160KB). There is also a 32KB standby powered SRAM at 0x4000_0000 to 0x4000_7FFF.
So theres to possibilities I can think of:
1) There is a specific main SRAM area which accepts the code upload and will execute (Im thinking this is least likely)
2) The standby SRAM might be unprotected, or from what I understand of the standby sram information..is an application can be loaded into standby sram, then put the ecu into standby, boot backup and hope it runs?
3) Put ecu into as recovery state (interrupt flash of cals or OS) and try upload to those locations. The 'recovery' state technically is run by the bootcode.. so this might be the exploit point.
Bit of food for thought