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.
UpdateSubaru 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.
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:
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 2Managed to obtain a copyof the firmware image from another ECU running the same version and decompiled it in IDA Pro, and found this.
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