Pages: [1]
Author Topic: How to disassemble ECU firmware  (Read 3201 times)
dzsec
Newbie
*

Karma: +0/-0
Offline Offline

Posts: 5


« on: May 14, 2022, 12:56:33 PM »

Hi all, I'm a noob firmware reverse engineer, i have experience reverse engineering compiled executable formats but im not sure how to properly disassemble firmware.

Biggest questions are: how do you tell the difference between code and data, there's gotta be libraries and imports in the firmware, how do you rebuild those references in something like IDA or GHIDRA?

My first thought was, since i have an ECU to work on was; why not get JTAG and see if gdb via openocd can show that to me during runtime but getting JTAG has been kind of a rabbit hole and im not sure if maybe there's an easier way that i missed.

I did find that with IDA you can kind of highlight sections you think could be code and have it just disassemble those sections but it seems maybe less than trustworthy and also isn't giving me cross references. Plus, in the firmware dump i got; i have an eeprom file and an irom file, the irom is the one i think has code since the entropy graph from binwalk says most of it is at 0.8 and the eeprom is around 0.6 and lower, eeprom is probably maps and such, right? There must be some way to build references to eeprom, since I'm sure the firmware code touches that right?

The architecture i am dealing with is TriCore 1762 and I know there's some dev tools for the architecture.. could those be of use to me? I don't really even know how to compile firmware.

Thanks for helping out a noob in advance!
Logged
d3irb
Full Member
***

Karma: +131/-1
Offline Offline

Posts: 185


« Reply #1 on: May 14, 2022, 04:21:10 PM »

Read the Tricore documentation and understand the memory map.

Once you know the entry point you can disassemble code and from that xrefs to data will fall out.

There are no imports in a full firmware file since it is all of the code running on the ECU (besides the boot ROM) - there is no dynamic linker and nothing to import!

Find an A2L and you have a map of all RAM variables for application software. For the bootloaders you pretty much just have to disassemble and look around and start naming things.

Generally calibration is a fixed area within Flash on newer ECUs. EEPROM is volatile data like adaptations, immo, fault information, etc. The A2L will sometimes also tell you which Flash block area is called what which can be helpful.

A lot of Bosch RE people here also play on easy mode with leaked ELFs with symbols which can be cross correlated.
Logged
dzsec
Newbie
*

Karma: +0/-0
Offline Offline

Posts: 5


« Reply #2 on: May 16, 2022, 02:35:35 PM »

Hey thank you so much for the reply! that makes a lot of sense.

I managed to find the entry point address by following your instructions and studying the TriCore docs i found!

Would you be down to point me in the direction of anyone talking about the leaked ELFs you mentioned? My ECU is Bosch and I'm interested in that. I've asked and looked around a bit and I don't think I'm going to find an A2L.

The ECU I'm looking at is Bosch ME17.8.5 for SeaDoo Spark. I know k0mpressed posted .kp files but my understanding is that those won't help much with what I'm doing.
« Last Edit: May 16, 2022, 02:42:41 PM by dzsec » Logged
prj
Hero Member
*****

Karma: +903/-420
Offline Offline

Posts: 5789


« Reply #3 on: May 17, 2022, 04:42:48 PM »

IDK if it helps you, but my logger will ram log and live tune this thing.
But not sure what you want to do.
Logged

PM's will not be answered, so don't even try.
Log your car properly.
crackerx
Jr. Member
**

Karma: +1/-8
Offline Offline

Posts: 43


« Reply #4 on: May 18, 2022, 01:21:48 AM »

interesting
« Last Edit: May 18, 2022, 01:23:27 AM by crackerx » Logged
dzsec
Newbie
*

Karma: +0/-0
Offline Offline

Posts: 5


« Reply #5 on: May 19, 2022, 12:44:29 PM »

IDK if it helps you, but my logger will ram log and live tune this thing.
But not sure what you want to do.

yeah, to be quite honest im not sure if that would help me either; but i'd be interested to look into that more and see if it would! When you say that it will live tune my ECU, is that over CAN? I'm basically interested in reverse engineering the firmware update over CAN. At this point I have the Seed2Key algorithm to unlock the ECU for firmware update over CAN, and I'm just trying to learn about a few more of the details, i.e. encoding/encrypting the firmware, CRC formatting/algorithm and so on. Thanks to d3irb & k0mpressed I have a solid and trustworthy disassembly of the firmware now, and I'm trying to get through it while learning the TriCore assembly haha! I am not sure how to fit in the eeprom dump that k0mpressed posted but I know that's part of the picture.

Dynamic analysis of the firmware would help tons, but I'm conflicted to go at it from a hardware/JTAG perspective which I've already kinda started trying to figure out, or try to use qemu like d3irb has done with the Simos18, I've gotten as far as compiling qemu with d3irb's additions but i don't have any Simos18 firmware to test that out, and I may just go ahead and try to make a similar but different addition for ME17.8.5. Not sure if I know enough, since I'm not entirely certain where the eeprom would get mapped into memory.

Thanks again for all your replies d3irb & prj!

EDIT: i've tried to read TriCore docs to figure out where the EEPROM dump from k0mpressed would be mapped but I'm coming up short. Using Qemu would be useless if I can't figure out where this data would be mapped and provide it to Qemu somehow, even if I can get it to work with the firmware somehow, so at this point it seems like my best plan would be to keep hammering away at getting JTAG to work and then use that to at least just cross reference that with what I'm seeing in the EEPROM and find the correct mapping for that data. My best guess is that the EEPROM dump is some concatination of several data segments. I'll repost the files that I got from k0mpressed's dump here just for reference in case anyone wants to look.
« Last Edit: May 19, 2022, 01:51:10 PM by dzsec » Logged
prj
Hero Member
*****

Karma: +903/-420
Offline Offline

Posts: 5789


« Reply #6 on: May 19, 2022, 03:22:01 PM »

OK, if you're reversing the flashing then all you care about is the CBOOT anyway. ASW is not super interesting beyond the initial security access.
It is possible to hack the CBOOT on Bosch to pull real time data. It mostly uses the same UDS stack as the ASW, and you can do some abuse to the SID table.

This would allow you to vector to your own routine and read out any RAM while the CBOOT is running... It's not exactly debugger breakpoint stuff, but it's possible to insert jumps into code caves that will write the stuff to RAM that you need.
I'd dare say if you are handy, you might be able to hijack my logger to read the memory...
Logged

PM's will not be answered, so don't even try.
Log your car properly.
dzsec
Newbie
*

Karma: +0/-0
Offline Offline

Posts: 5


« Reply #7 on: May 20, 2022, 11:06:00 AM »

OK, if you're reversing the flashing then all you care about is the CBOOT anyway. ASW is not super interesting beyond the initial security access.
It is possible to hack the CBOOT on Bosch to pull real time data. It mostly uses the same UDS stack as the ASW, and you can do some abuse to the SID table.

This would allow you to vector to your own routine and read out any RAM while the CBOOT is running... It's not exactly debugger breakpoint stuff, but it's possible to insert jumps into code caves that will write the stuff to RAM that you need.
I'd dare say if you are handy, you might be able to hijack my logger to read the memory...

Oh cool thats great to know thank you, yeah, I'm interested in checking out your logger - do you have it up somewhere or would you be down to send it to me? How does it log RAM? Also what is CBOOT? I'm assuming ASW is just application software, so you're talking about the main firmware logic that I've disassembled and is what I'm looking at.

When you talk about abusing the SID table, that would basically require me to patch the firmware and insert my own code that would write to RAM like you said, so I would flash some patched firmware and then inspect it with your logger? All this would require for me to find the SID table too.. Thats been one of the main targets I've been trying to find with the firmware RE I've been doing, I've spent some time reading through the KWP2000 documents and cross referencing with the SIDs I've seen BitBox use to flash firmware over CAN and there are several manufacturer specific SIDs, and I think they probably have to do with encryption and/or CRC. Maybe the SID table lives in the EEPROM though.

Thanks again prj, this is super helpful and I really appreciate it!
« Last Edit: May 20, 2022, 11:15:06 AM by dzsec » Logged
prj
Hero Member
*****

Karma: +903/-420
Offline Offline

Posts: 5789


« Reply #8 on: May 20, 2022, 03:23:08 PM »

Don't think logger is too useful for you at this stage.

The encryption/compression algorithm is in the CBOOT...
As is the signature checking (I don't know if this ECU has it enabled or not).

If signature checking is enabled, you will have to find an exploit to bypass it.

I'd recommend starting with UDS specification, finding the SID tables and reversing the routines.
Logged

PM's will not be answered, so don't even try.
Log your car properly.
dzsec
Newbie
*

Karma: +0/-0
Offline Offline

Posts: 5


« Reply #9 on: July 08, 2022, 02:34:44 PM »

Don't think logger is too useful for you at this stage.

The encryption/compression algorithm is in the CBOOT...
As is the signature checking (I don't know if this ECU has it enabled or not).

If signature checking is enabled, you will have to find an exploit to bypass it.

I'd recommend starting with UDS specification, finding the SID tables and reversing the routines.

Can I ask what is a CBOOT? At first I thought you meant Cold Boot and someone is telling me it means Customer Boot? What is this?
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.023 seconds with 18 queries. (Pretty URLs adds 0.001s, 0q)