111
edits
Changes
Jump to navigation
Jump to search
→Unlocking the ECU
That makes it really slow and I think this slowness is deliberate. I believe that when you are trying to write data to a flash substrate that hasn’t been freshly erased, it can take time for the bytes to ‘soak’ into the flash. It’s not freshly erased and just sitting there waiting. Instead it’s already got some contents and now you’re writing to it again. Maybe it takes longer to sink in and for the binary state to change… So that is your thirty to forty-five minutes waiting around time when the crack first happens.
Those checks I mentioned that set the green OKAY bytes in the pictures I drew. Those checks only happen when you ‘step through the front door’. They don’t happen again. Just a once-off when the file is first pushed onto the ECU through the OBD front door. After it’s written to the flash, no point in checking it again, it already passed once and caused the OKAY bytes to be written. Simply the presence of the OKAY bytes suffices to say it was checked. That’s why if you can somehow change the code and leave the OKAY bytes intact, the code will not be checked again and your changes will go undetected!
Now you’ve reached the point, after a lot of effort, that you can write modified stuff down to the ecu. Great. But what if this is the second or third or nth time you want to flash. Clearly you don’t need to patch the ecu every single time, just the first time. No one want to sit around for 45 minutes unnecessarily. So wouldn’t it be nice to somehow check if the ECU has already been patched and we can just skip straight to sending modified files. Or discover if it was never patched and we have to start from scratch. Maybe a friend brings their ecu along and you don’t know the history. You need a way to talk to the ECU…
So now I must digress back to UDS again.
You’ve see services $2C, $22 and $23 for logging. There’s another service $3E TesterPresent. It is simply a heartbeat sent from any OBD tool to the ECU periodically every few 100ms and reminds the ECU that the tool is still there. Just a little tap on the shoulder. Useful for things like elevated security levels – if the tool had requested an elevated privilege level (Service $27 SeedKey) and the ECU then went into that privilege mode, but then the tool disappeared for some reason (flat battery/disconnected cable) then the ECU would notice the missing heartbeat, tear down the elevated privilege session and go back to a basic diagnostic mode waiting for the next connect.
A regular ISO/SAE UDS hearbeat is really simple. The format is always the same as well:
0x02 0x3E 0x00:
2 – it’s 2 bytes in length. Mandated by the UDS standards. Anything other than 2 in this field returns an error
3E – the first byte, it’s service $3E
00 – the second byte, it’s allowed to be 00 or 80 (acknowledgement required/not required)
So many third party tools re-task the UDS heartbeat message for their own purposes. What they’ve done is to slightly ‘corrupt’ the heartbeat request/reply, to use it beyond the original intention:
0x03 0x3E 0x00 0x01
3 - it’s 3 bytes in length.
3E - the first byte, it’s service $3E
00 - the second byte, it’s allowed to be 00 or 80 (acknowledgement required/not required)
01 – an extra byte, tacked upon the end. This could represent Command #1
So now you send this modified heartbeat. Firstly, the length is different now, 3 bytes instead of 2 bytes. So an unpatched stock ECU would reply with an Error 13 – incorrectMessageLengthOrInvalidFor
mat because the ISO/SAE standard is just 2 bytes always . But a patched ECU (with suitable patching in the UDS stack) would accept this and reply with a positive response instead. And there you have it, the tool can learn whether the ECU is previously patched or stock by simply send a little heartbeat message and seeing if the reply is positive or negative.
In addition, you can use that extra byte at the end to trigger something inside the ECU as well (as long as there is corresponding patching to accept it). In the example above, the extra byte being a value of 0x01 could mean invoke activity #1. A value of 0x02 might mean invoke activity #2. All driven by the tool. The clever bit here is that it’s a combination of external tool and ecu patches. It’s not enough just to have the patches inside the ECU, you also need the external tool to trigger those patches inside the ECU otherwise they just sit there waiting.
Next chapter of the story
So now the ECU is wide open. After several steps (and going around the houses via ASW), finally a couple of bytes (yes, it really is just two) have been changed in CBOOT_actual which bypass the RSA signature checks. The ECU will now accept any modified file (i.e. signature not matching contents) that you throw at it, moreover you can just use the factory flash sequence of UDS commands to send the modified files. You don’t need a fancy tool costing £££ thousands either, anything that can send the UDS commands will do the job.
So the pendulum has swung too far if you are a tool vendor! And now they dial it back a bit and make sure that it’s their tool in control again and you have to use their tool.
So whilst the ECU is wide open with RSA signature checks bypassed, the flash tools send down a CBOOT with a number of changes:
A patched heartbeat
Remember UDS command $31 02 02 checkMemory, described much earlier? The one that does a bunch of checks and write the green OKAY bytes? Well, there’s a patch that does the same thing but it doesn’t do any checks beforehand, it just blindly writes the OKAY bytes
And the RSA signature checking is re-activated (the two bytes are reverted)
The ECU reboots, comes up running this modified CBOOT (and although it’s modified it runs quite happily because no checks are done after the fact. The checks are only done once when it passes through the front door on the way in via OBD).
The active RSA signature checks prevent you from sending down any more modified files. Err - but then how do you send a modified CAL?
Remember again that modified UDS heartbeat $3E? Tacking a byte onto the end? And using that byte to represent some command?
Well, you send over the modified CAL using the same UDS flash sequence commands Erase, then Write, all legitimately ($34, $36 etc). The CAL ends up on the flash inside the ECU and the final step is to get the OKAY bytes. At this point, instead of running the OEM $31 02 02 checkMemory which will fail because the file is modified and not write the OKAY bytes, the tools send a modified heartbeat. A patch inside the ECU recognises the modified heartbeat and blindly writes the OKAY bytes for CAL. Then as far as the ECU is concerned, all is fine, the OKAY bytes are there and everything is perfect.
And the tool vendor is happy because you’ve had to use their tool to do this and their modified heartbeat comms channel and whatever command byte sequence they put in :blush:
== Adding features ==
