Subaru Euro5 Reverse Engineering! Found new authentication!

gnif · **Joined:** Thu Nov 19, 2015 12:23 am **Posts:** 30

Hi All,

Edit: This thread has become about documenting my progress and what I have discovered so far

Edit2: I would like to ensure that the help rendered by the Subaru Diesel Crew does not go unnoticed, it was they who got me started and pointed me in the right direction, and their documentation that has helped enormously with understanding how to talk to a Subaru ECU at all.

Once again I am plagued with DPF issues and I am in need of the commands to force the vehicle to perform a regeneration. I have spent the last week reversing the ROM in an attempt to identify the commands to issue, and implemented the challenge/response algo to auth with the ECU, but alas, I can't figure out much more at this point.

The vehicle is an Australian 2010 Outback 2.0D with the rom JE5F231A.

I am using some custom hardware (stm32ce8t micro) to talk to the vehicle and I have implemented enough to query mode 22 data from the ECU, so at this point all I am looking for is the raw commands to send to the ECU.

gnif · **Joined:** Thu Nov 19, 2015 12:23 am **Posts:** 30

Since I posted this I have discovered a ton of information while waiting for my ability to post be approved

.

Here is a quick rundown of discoveries so far:

1) I am working with a 7059 based ECU running a JE5F231A ROM.
2) The ROM is running Hitachi OS Version 1.0.00.000 (Ho7058)
3) There is a datasheet for this OS that gives a good overview of the HCAN bus Here.
4) Using a home brew CAN bus data logger, I acquired a ton of data from the official SSM3 scan tool while the car was having it's firmware updated, and a forced regeneration performed.
5) I believe I have identified the commands to trigger a DPF forced regeneration, but it requires Mode 3 which requires authentication using an unknown algo at this point, I believe it is the same algo but with a different seed, I am yet to identify it.
6) There are 3 vector tables I have discovered so far, the primary residing at the end of the ROM at address 0x17FC50, all other vector tables are only stubs for initial initialization, and one for a shutdown mode at 0x306C which does nothing but shutdown the AUD clock.
7) AUD is NOT disabled as far as I can ascertain so far.

Both HCAN0 and HCAN1 buses are serviced by the same routine, as far as I can tell it doesn't matter which one the messages arrive on.
9) The Mode 09 handler routines have been identified starting at 0x18A24, 0x18B94 and 0x58164
10) The VIN is loaded into RAM at address 0xFFFF65F4
11) The CVN is loaded into RAM at address 0xFFFF1FC0

I have also managed to get the Renesas simulator setup for this ECU and wrote a register I/O file for it, this has been very handy in confirming the program flow and how the various devices are configured.

gnif · **Joined:** Thu Nov 19, 2015 12:23 am **Posts:** 30

A second seed key has been identified at 0x94368!!!

Code:

const uint16_t seedKey2[16] =
{
  0x24b9, 0x9d91, 0xff0c, 0xb8d5, 0x15bb,
  0xf998, 0x8723, 0x9e05, 0x7092, 0xd683,
  0xba03, 0x59e1, 0x6136, 0x9b9a, 0x9cfb,
  0x9ddb
};

It is using the same nybbleTable

gnif · **Joined:** Thu Nov 19, 2015 12:23 am **Posts:** 30

Well, I have made a TON of progress over the last few days... here is what I know now.

1) That additional seed is NOT just in Euro5 ECU's, I have also found it in a ROM for a Impreza 2.0D (JZ2F401A) which is Euro 4. Would be cool to find out what it is for, but I believe it wont help things with my current goals.

2) I have managed to confirm 100% positive that the algo for the normal seed, which is used for mode 27 auth has not changed, the existing algo is correct.

3) The logic to enter mode 27 has changed substantially, which is why it won't work anymore.

4) I have identified the mode handler jump table!!! This has been the hardest thing to find! For this ROM is the complete list of modes supported:

1, 2, 3, 4, 7, 9, 10, 19, 22, 23, 27, 28, 2A, 2C, 2E, 2F, 31, 34, 35, 37, 3D, 85, A8, AA, B6, B7, B8, BA

Some of these are already known, I have only just discovered this, my focus will be on mode 0x27 so that we can authenticate to the ECU, but I am very keen to see what other features lie in these modes.

For those that are interested, the jump table can be located a little way after the SSM base, it looks like this. Note thought that (at least in my case) IDA had just jumbled this into a mess of an array or two, and because it was misaligned it was not at all obvious as to what it was.

Code:

DATA:00092BE8 00 94                                       .data.b 0, h'94
DATA:00092BEA FF FF FF FF                 dword_92BEA:    .data.l h'FFFFFFFF      ; DATA XREF: ROM:off_18DE8o
DATA:00092BEE FF FF FF FF                 dword_92BEE:    .data.l h'FFFFFFFF      ; DATA XREF: ROM:00018DF8o
DATA:00092BF2 FF FF FF FF                 dword_92BF2:    .data.l h'FFFFFFFF      ; DATA XREF: ROM:00018E40o
DATA:00092BF6 FF FF FF FF                 dword_92BF6:    .data.l h'FFFFFFFF      ; DATA XREF: ROM:00018E30o
DATA:00092BFA FF FF FF FF                 dword_92BFA:    .data.l h'FFFFFFFF      ; DATA XREF: ROM:00018E20o
DATA:00092BFE FF FF                       word_92BFE:     .data.w h'FFFF          ; DATA XREF: ROM:00018E10o
DATA:00092C00 FF FF 00 00                                 .data.l h'FFFF0000
DATA:00092C04 01 00 00 00                 modeJumpTable:  .data.l h'1000000    <- This is the start of the table, and the mode ID, 0x01 in this case.
DATA:00092C08 00 01 7D 60                                 .data.l mode01       <- The function offset
DATA:00092C0C 00 00 00 01                                 .data.l 1            <- Used to signal the end of the array, last record is 0
DATA:00092C10 02 00 00 00                                 .data.l h'2000000    <- The next record. mode 0x02
DATA:00092C14 00 01 82 34                                 .data.l mode02
DATA:00092C18 00 00 00 01                                 .data.l 1
DATA:00092C1C 03 00 00 00                                 .data.l h'3000000
DATA:00092C20 00 01 86 48                                 .data.l mode03

gnif · **Joined:** Thu Nov 19, 2015 12:23 am **Posts:** 30

Just thought I would throw in the stark contrast in complexity of the mode 27 handler.

CORRECTION: I am tired, that should read 0x27 on the image, not 0x22.

gnif · **Joined:** Thu Nov 19, 2015 12:23 am **Posts:** 30

Wow, they do not make this easy...

There is quite a few commands you need to send to get the internal state ready to even respond to a challenge, at the moment it seems to start with a few mode 0x10 calls, from what I can tell you need to perform a set of commands in a very and I mean VERY specific order to set bits in a variable. Just to get the variable initialized there is a ton of protection around it.

This explains why in my logs I can see the official SSM3 tool performing requests that are returning errors, the errors are just to keep you blind as to the state of the internal machine.

See attached image of the mode 0x10 mess.

Any chance anyone has some SSM3 CAN logs from the official tool they are willing to share? It would make this go much easier.

gnif · **Joined:** Thu Nov 19, 2015 12:23 am **Posts:** 30

Some more findings... Once mode 10 is figured out, we will be able to authenticate!!!!!

1) entering service mode 0x01 (0x27 0x01) we already know and I can confirm the method is identical to euro 4.

Test from known good auth from sniffed dump

Code:

Challenge Known    Calculated
099a3329  c9a72ded c9a72ded

2) entering service mode 0x03 (0x27 0x03) uses the same algorithm as Euro4, but with some byte swapping.

Code:

// 0xAABBCCDD -> 0xBBCCAADD
challenge = ((challenge >> 8) & 0x00FFFF00) | ((challenge & 0x0000FF00) << 16) | (challenge & 0xFF);

answer = calcAnswer(challenge);

// 0xAABBCCDD -> 0xDDBBCCAA
answer = ((answer & 0xFF000000) >> 24) | (answer & 0x00FFFF00) | ((answer & 0xFF) << 24);

Test from known good auth from sniffed dump

Code:

Challenge Known    Calculated
11573862  360263d0 360263d0

3) entering service mode 0x05 (0x27 0x05) again uses the same algorithm, but different byte swapping again, I have not bothered figuring this out yet as I have no dumps of this authentication to verify my findings with.

Note, none of these are useful until authentication is unlocked via mode 0x10.

Just realized I have been calling int mode 10 all this time, when there is a mode 10, it is mode 0x10, or mode 16.

gnif · **Joined:** Thu Nov 19, 2015 12:23 am **Posts:** 30

Some more obvservations...

It is documented that the Euro6 cars do not have pin3 in the OBD-II connector, and that they do not use it... well it seems that the Australian 2010 Outback 2.0D has it, and grounding it makes the vehicle behave just like you plugged in the green connector, fans, pumps, etc...

Also there is a secondary connector in the right foot well, I believe this is called the self diagnostics connector. If this is plugged in, the internal light in the car starts flashing on and off once a second. If the engine is started, with just the pin grounded on the ODB connector, the check engine light flashes rapidly, if the connector is plugged in also the lamp flashes slowly.

On the ROM side of things, I have discovered that the mode 0x10 is reading values from bit arrays, which some are confirmed to be physical things like cruise control, brake switch, etc. If this is all done right, calling mode 0x10 with a pid of 0x02 should enable mode 0x27. The euro4 ROM I am comparing to also has a very similar set of checks in mode 0x10... I wonder if anyone knows the secret sauce for the older ECU?

The assembler also shows it should be possible with the PIDs 0x43, but it also is check on an unknown value at this time, this might be the better option though as it seems to only be looking at one of the variables that I believe holds switch data (Cruise Control, Brake, etc).

If anyone has any idea what the following set of numbers might represent we might have a solution here:

0.056249999
10.0
14.0
100.0
5.0

Whatever it is checking, it is looking things that are larger then these numbers, and it is correct that they have the .0 on them, they are all confirmed to be floating point numbers.

Edit:
10.0 and 14.0 are a range, something has to be between those values. (x > 10.0f && x < 14.0f)
5.0 and 100.0 is a range, something has to be between those values. (x > 5.0f && x < 100.0f)
0.056249999 is used to scale a word value, which must be less then 5.0 ((x * 0.056249999) < 5.0), so looking for a word value no higher then 88.

gnif · **Joined:** Thu Nov 19, 2015 12:23 am **Posts:** 30

Still progressing and just made a huge find, the extended mode table!

Starts at 0x00092EA8, has 248 elements in it, each in the following format:

Code:

struct ExtModeRecord
{
  uint16_t extModeID;
  uint16_t unknown1;
  uint32_t unknown2;
  void (*handler)();
  void (*unknownHandler)();
};

Now I have a complete list of all the possible extended mode PIDs!!!!

Edit:
ANOTHER DISCOVERY! I am getting so excited now!

A new mode 22 PID, not sure what it returns yet, but I do know it returns one of the values that are needed for mode 10 auth!

PID: 0xf186
Size: 1 byte
Formula: ((float)value) * 0.056249999f

Edit2:

Another PID discovered, this one is a switch/button, etc, no idea what yet

PID: 0x1022
Size: 1 byte
Formula: (bool)value

Sasha_A80 · **Posted:** Sat Aug 20, 2016 3:34 pm

The most activitity related to Subaru Extended PIDs is here
https://subdiesel.wordpress.com/generic ... ed-obd-ii/

Values 10.0 and 14.0 are most probably BatteryVoltage (V) limits.
Values 5.0 and 100.0 are probably Atmo or Manifold pressure limits.
Those values may be traced from OBD mode 1 or mode 22 PIDs.

Edit: Values 5.0 and 100.0 are most probably CoolantTemperature limits.
I have faced an Erase\Write problem with overheated ecu's.

gnif · **Joined:** Thu Nov 19, 2015 12:23 am **Posts:** 30

Thanks, nice to finally see someone is reading this.

Quote:

I would like to ensure that the help rendered by the Subaru Diesel Crew

I am well aware,

... this is beyond what SDC has on their website.

gnif · **Joined:** Thu Nov 19, 2015 12:23 am **Posts:** 30

There are TONS, of new PIDs here, and their scaling factors! Will have to produce a list of them later so people can figure out what they are for.

Figured out some of the numbers:

> 10.0 and < 14.0 applies to engine RPM (multiply by 256), when converted to actual RPM, this is 2560 to 3584 RPM. - Edit: This is wrong!, CPU pipelined instructions confused me, it is indeed battery voltage. Confirmed, the value can be obtained by reading SSM2 address 0x222, the scaling factor is 0.099999994 (or just divide by 10, but the figure here is what the ECU uses and will be slightly more accurate).

The value from 0x22 0xF186 I logged, and it never seems to go above 0, which meets the criteria, so nothing to do here.

Sasha_A80 · **Posted:** Sun Aug 21, 2016 1:50 am

The main problem is to understand and verify what parameters are reported by Subaru Extended OBD PIDs.
Those PID locations and scalings are evident in ROMs. What they mean is the greatest question.
Subaru SSM3 software have this information inside the software code for K-line based SSM2 protocol ( and SSM over CAN ).
This is not the case for SSM4 software. PID meaning is inside scrabmled\encoded XMLs.

gnif · **Joined:** Thu Nov 19, 2015 12:23 am **Posts:** 30

While that is true, it doesn't mean that some new ones can't be identified given time, I am slowly making sense of the values it is checking to enable mode 0x27 on Euro5 cars.
I just found that there are two mode tables, one before and one after access is enabled.

Initial set of available modes are:
0x01, 0x02, 0x03, 0x04, 0x07, 0x09, 0x10, 0x19, 0x22, 0x28, 0x34, 0x35, 0x37, 0x3E, 0x85, 0xA8, 0xB6, 0xB7, 0xB8, 0xBA

Once unlocked the following modes are also available:
0x23, 0x27, 0x2A, 0x2C, 0x2E, 0x2F, 0x31, 0x3D,

Also all the numbers have been figured out that were of interest in the mode 0x10 handler, the criteria for entering service mode 0x2 are:

Battery Voltage between 10V and 14V, this means that while the battery is charging (car running, alternator) it is impossible to enter this mode.
Engine RPM is less then 100, again, engine off
Vehicle Speed is less then 5kph

There is still a bit to turn on though to enable this set of features, the mode27 handler seems to set the bit, so authentication for mode27 seems to lie in the above mode set selection.

Edit: Confirmed! to begin anything mode 0x10 pid 0x01 needs to be executed first with the correct conditions met.

Extended Mode 0x22 0xF186 needs to be set to 1
And another switch array referenced with other switches (brake, clutch, etc..) needs to be set, still to identify which this is also.

Edit2:

Mode 85 is used to set the switch value in question, but it seems to check on the value of 0x22 0xF186 before proceeding

Sasha_A80 · **Posted:** Mon Aug 22, 2016 2:40 am

I would recommend to verify if the bootloader itself ( just started ) has less strict authentification procedure.

RomRaider

Subaru Euro5 Reverse Engineering! Found new authentication!

Who is online