Author Topic: ECU Reverse Engineering  (Read 7280 times)

0 Members and 1 Guest are viewing this topic.

Offline gnifTopic starter

  • Administrator
  • *****
  • Posts: 1672
  • Country: au
ECU Reverse Engineering
« on: November 16, 2015, 06:01:55 am »
Hi All,

Just thought I would throw up here what I have been working on. I have one of those dreaded Diesel's with a DPF... what a joke. Anyway, It has gone into fault and limp mode due to the state of the filter. So this begun my journey.

1) Removed the DPF from the vehicle, inspected and flushed it out with high pressure water, seems the Europeans are doing this also.
2) Wired a STM32F103 up to to the can bus and wrote a ton of code to interrogate the thing (Its a 2010 Subaru Outback  2.0Tdi btw).
3) Hacked about until I managed to figure out how to clear the fault codes... this had no effect.
4) Hacked about until I figured out how to tell the Subaru ECU to reset... this got it out of limp mode! But still complaining of a failed DPF and refuses to regen.

So this has left me at the final stage, tear open the ECU and see if I can dump its firmware out, but how? Well this thing has a MCU that has what is called an AUD port, Advanced User Debug, but finding the header and pinout involved some work in the gimp, using some of the techniques that Dave showcased in one of his videos (I have attached the result).

1) Find the MCU data sheet and get the BGA pinout drawing, and highlight the pins of interest.
2) Take a photo of the top of the PCB, scale/stretch and align it until the MCU aligns with the BGA drawing.
3) Take a photo of the bottom of the PCB, set some guidelines on various through holes, then stretch and scale it to align with the other two layers.
4) Follow the lines :)... A few educated guesses on the route of them, but as the page is filled in it becomes obvious as to where the errors are.

I am at the point of interfacing the STM32 to the AUD port, I have soldered a breakout connector onto the ECU's header and should have a firmware dump soon :). Update pending.

Update

Subaru agreed to update the ancient firmware on my ECU, I only had about 8 hours notice that they would before I had to take it there, so I did what any self-respecting hacker would do, built a can bus data logger and surreptitiously attached it to the can bus. I used a 72MHz STM32C8T, a MCP2551 transciever and a 8GB SD card. I configured the STM32 to run in silent mode, preventing it from even ackking frames on the bus and set it to work sniffing when I arrived at the dealership.

Unfortunately I did not have much time to tune and tweak the firmware and as such I was not able to capture every single packet on the bus, the write to the SD card caused the odd dropped packets, but they are pretty far and between so I still captured a ton of useful data, including this tidbit.

Code: [Select]
08,00,00,000007e0,000007e0,02,27,01,00,00,00,00,00 - Security Access Request
08,00,00,000007e8,000007e8,06,67,01,09,9a,33,29,00 - Challenge = 09,9a,33,29
08,00,00,000007e0,000007e0,06,27,02,c9,a7,2d,ed,00 - Answer    = c9,a7,2d,ed
08,00,00,000007e8,000007e8,02,67,02,00,00,00,00,00 - Success

I also requested information on the details of the firmware update and the log from the SSM-III scan tool, they refused to provide the log but they did give me a print out of the firmware details, which also contained some extra information I did not expect:

Code: [Select]
Decryption Keyword: 419A5B97

So now just to figure out the algo that is used to generate the answer to the challenge in the security request, any ideas?

Update 2
Managed to obtain a copyof the firmware image from another ECU running the same version and decompiled it in IDA Pro, and found this.

Code: [Select]
mov.w   word_D34, r1 ; h'FFFFBFAD
mov.b   r3, @r1
mov.w   word_D36, r0 ; h'3C04
mov.w   word_D38, r3

0xFFFFBFAD = SYSCR2
0x3C = allow write
0x04 = Clock supply to AUD stopped  |O |O |O
« Last Edit: November 19, 2015, 07:46:11 am by gnif »
 

Offline Srbel

  • Frequent Contributor
  • **
  • Posts: 360
  • Country: cs
  • Electronics engineer
Re: ECU Reverse Engineering
« Reply #1 on: November 16, 2015, 08:13:42 am »
You can try taking the car on the highway, and driving it a high RPM for 10km or so. It should clean the DPF a bit (and maybe remove the error). Or does it only work for catalytic converters?
 

Offline gnifTopic starter

  • Administrator
  • *****
  • Posts: 1672
  • Country: au
Re: ECU Reverse Engineering
« Reply #2 on: November 16, 2015, 09:09:43 am »
You can try taking the car on the highway, and driving it a high RPM for 10km or so. It should clean the DPF a bit (and maybe remove the error). Or does it only work for catalytic converters?
Unfortunatly it is beyond this, there are two stages of DPF fault.

1) Light steady on = Warning, high soot, burn needed
2) Light flashing = DPF Clogged, Service Required.

Mine is flashing...
 

Offline discomike

  • Contributor
  • Posts: 17
  • Country: se
Re: ECU Reverse Engineering
« Reply #3 on: November 16, 2015, 09:53:47 am »
Personally I'm not a fan of people defeating environmental protection features of their cars so they can pollute (and no you can not clean the filter sufficiently yourself), but hacking cars is fun =)

Have you made contact through the AUD port yet? It seems it can be disabled by software by setting MSTOP3 bit in SYSCR2 but maybe they have not done this (also there might be a attack window during startup since it defaults to enabled).

Another approach is to find some exploit through CAN using OBD-II. Since this is a fairly old car there should be some clone of the official service software available, use that as a base to find suitable commands to fuzz.
 

Offline 0xdeadbeef

  • Super Contributor
  • ***
  • Posts: 1570
  • Country: de
Re: ECU Reverse Engineering
« Reply #4 on: November 16, 2015, 11:17:49 am »
For a car from 2010 you might be lucky, but usually all ECUs designed in the last years will have security system to lock the debug port for production ECUs.
There is most probably still a way to get into some kind of boot loader with certain pin and/or can communications during the boot sequence, but it will be pretty hard to find out without debug access or inside knowledge.
Trying is the first step towards failure - Homer J. Simpson
 

Offline gnifTopic starter

  • Administrator
  • *****
  • Posts: 1672
  • Country: au
Re: ECU Reverse Engineering
« Reply #5 on: November 18, 2015, 09:14:48 am »
Quote
Personally I'm not a fan of people defeating environmental protection features of their cars

I am not looking to defeat them, just clear the fault code so that it will perform it's normal regeneration cycles.

Quote
Have you made contact through the AUD port yet

Yes, but I had to stop working on this vector as I managed to get Subaru to agree to update the ancient firmware in my ECU, I will update the main post with details :)
...

Edit The comms I was seeing must have been noise on the line, as discovered in the dissasembly the port is disabled. Doh!
« Last Edit: November 19, 2015, 07:49:08 am by gnif »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf