RomRaider

I was able to successfully dump the ROM and EEPROM from the RKE TPMS module from ALPS, 88035XA04A

Attaching here in case someone wants to help reverse engineer it.

MCU is MC9S08AW32
EEPROM is 93C66

Here are the BDM test points from the bottom of the board, in case someone wants to dump the rom themselves.

A few updates:

EEPROM is connected to the Serial Pins (on the 48-Pin HCS08 its pins 13-16) but the serial controller isn't used. I was really confused when all of the serial hardware was turned off in the RESET code but the lines on the board were clearly going to the serial ports. After further snooping it turns out reading and writing to the EEPROM is bit-banged, which is insane. The read portions of this are at 0x885C. Will take some more digging to figure out which reads relate to what part of the EEPROM and how all the data get put in/out of the stack and wrangled.

Looks like there is a weird checksum at 808F which does some manipulation on all the bits except for FFB0-FFC0.

Also some interested code at 9x811F that loads a binary blob of data from 0xFD81 onward into 0x100-0x190 in RAM

K-Line appears to be connected to Pins 47 and 48, which are part of SCI2. Haven't explored this yet due to the rabbit-hole the EEPROM created.

Edit, location of all sub-functions related to EEPROM:
0x885C EEPROM Read
0x88C5 EEPROM Write
0x8927 EEPROM Write Enable
0x896F EEPROM Write Disable

Edit: I am going to update this post with responses as I sort them out and add the names from Rimwall's post

Found all the SSM Commands from the tool to the RKE, but don't know what they do yet. I will list them out here (incomplete) and update this post when I can make sense of them. You have to send the 'startComms' command shortly before the next command, otherwise the module will not respond.

You can read/write these with a VAG cable, OpenPort is not necessary. Protocol is IS09141: 10400 Baud 8N1 No Parity.
SSM order is: Start,Dest,Source,Cmd,[cmd,...],checksum (CheckSum8 Modulo 256). The module doesn't hardcode the checksums so the ones that I have worked out I will put in brackets, otherwise I will leave them 0x00

startComms
0x81, 0x38, 0xF0, 0x81,[0x2A]

response: 0x83,0xF0,0x38,0xC1,0xE9,0x8F,[0xE4]

endComms
0x81, 0x38, 0xF0, 0x82,[0x2B]

response: 0x81,0xF0,0x38,0xC2,0x00,...

testerPresent
0x81, 0x38, 0xF0, 0x3E,[0xE7]

response: 0x081,0xF0,0x38,0x7E,0x00,...

readRKEIdentification:
<Unknown>
0x82, 0x38, 0xF0, 0x1A, 0x9A, [0x5E]

response: 0x086,0xF0,0x38,0x5A,0x9A,[4 data bytes],0x00 note: data bytes are variables at addr: 0x02B8,0x02B9,0x02B6,0x02B7

sample_1: 0x086,0xF0,0x38,0x5A,0x9A,0x10,0xAA,0x04,0x00,[0x60]

sample_2: 0x086,0xF0,0x38,0x5A,0x9A,0x10,0xAA,0x04,0x00,[0x60]

note: looks like they are the same

<Unknown>
0x82, 0x38, 0xF0, 0x1A, 0x91, [0x55]

response: 0x085,0xF0,0x38,0x5A,0x91,0xCC,0x02,0x00,[0x66] note: this is not variable, it is hardcoded

writeDataByLocalIdentification
<Erase all TPMS IDs in EEPROM>
0x82, 0x38, 0xF0, 0x3B, 0x12, [0xF7]

response: 0x82,0xF0,0x38,0x7B,0x12,[0x37]

<Write new TPMS IDs in EEPROM>
0x8E, 0x38, 0xF0, 0x3B, 0x10, [12 bytes], 0x00
sample_A:0x8E, 0x38, 0xF0, 0x3B, 0x10,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,0x0C,[0x4F]

Responses: (not sure what causes different responses):

Sample_A: 0x83,0xF0,0x38,0x7F,0x3B,0x21,[0x86] note: this wrote data to EEPROM

0x83,0xF0,0x38,0x7F,0x3B,0x10,... (fail?)

0x83,0xF0,0x38,0x7F,0x10,0x00,...

<Unknown>
0x87, 0x38, 0xF0, 0x3B, 0x11, [5 bytes?], 0x00
sample_A: 0x87, 0x38, 0xF0, 0x3B, 0x11, 0xFB, 0xF6, 0xEC, 0xD8, 0xB0, [0x60] note, this didn't write to eeprom (fail)

Responses:

0x83,0xF0,0x38,0x7F,0x3B,0x10,[0x75] response from Sample_A (fail?)

0x83,0xF0,0x38,0x7F,0x11,0x00,...

<Unknown>
0x86, 0x38, 0xF0, 0x3B, 0xE1, [4 bytes?], 0x00
Sample_A: 0x86, 0x38, 0xF0, 0x3B, 0xE1, 0x01,0x02,0x03,0x04, [0xD4]

Responses:

Sample_A: 0x83,0xF0,0x38,0x7F,0x3B,0x10,[0x75] (fail?) Doesn't appear to change EEPROM

<Unknown>
0x82, 0x38, 0xF0, 0x3B, 0xE2, [0xC7] Note: Loads 0x01 into address 0x01D4

Response: 0x83, 0xF0, 0x38, 0x7F, 0x3B, 0x10, [0x75] (fail?)

startRoutineByLocalIdentifier
0x83, 0x38, 0xF0, 0x31, 0x01?, 0x01?, ... looks like last two bytes need to be 0x01

Response: 0x84,0xF0,0x38,0x71,0x01,0xXX,0xXX,0xXX,...

stopRoutineByLocalIdentifier
0x83, 0x38, 0xF0, 0x32, 0x02?, 0xXX, ... looks like the last two bytes must be 0x02 followed by a value > 0x01

Two responses depending on value of 0x01AE:

0x83,0xF0,0x38,0x72,0x01,0x00,0x00,...

0x83,0xF0,0x38,0x7F,0x32,0x21,...

readDataByLocalIdentifier
<Unknown>
0x82, 0x38, 0xF0, 0x21, 0x10, [0xDB]

response: 0x8C,0xF0,0x38,0x61,0x10,[10 data bytes],0x00

sample_1: 0x8C,0xF0,0x38,0x61,0x10,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x88,0x97,0xA0,[0xE4]

sample_2: 0x8C,0xF0,0x38,0x61,0x10,0x07,0x00,0xA0,0x00,0x00,0x00,0x00,0x88,0x97,0x20,[0x0B]

<Unknown>
0x82, 0x38, 0xF0, 0x21, 0x99, [0x64]

response: 0x8A,0xF0,0x38,0x61,0x99,[8 data bytes],0x00

sample_1: 0x8A,0xF0,0x38,0x61,0x99,0x78,0x80,0x1C,0xAF,0xAA,0xA8,0xAD,0x78,[0xE6]

sample_2: 0x8A,0xF0,0x38,0x61,0x99,0x78,0x80,0x1C,0x9E,0x9E,0xA3,0xA6,0x78,[0xBD]

<Get TPMS IDs from EEPROM>
0x82, 0x38, 0xF0, 0x21, 0x11, [0xDC]

response: 0x9A,0xF0,0x38,0x61,0x11,[24 data bytes],0x00 note: data bytes are variable

sample_1: 0x9A,0xF0,0x38,0x61,0x11,0x0C,0x2E,0xC6,0x0C,0x2F,0xC6,0x0C,0x2E,0xC2,0x0C,0x2E,0xC4,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,[0x2F]

sample_2: 0x9A,0xF0,0x38,0x61,0x11,0xA8,0x28,0x59,0xA7,0xFC,0xAC,0xA7,0xFC,0xCF,0xA8,0x2C,0xB1,0xA8,0x28,0x59,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,[0xCC]

readStatusofDTCs
0x82, 0x38, 0xF0, 0x17, 0xFE, [0xBF]

response: 0x9A?,0xF0,0x38,0x57,0xXX,0xXX looks like first data byte is length, followed by list of DTCs, the DTCs are listed in a later post

no_DTCS: 0x82,0xF0,0x38,0x57,0x00,[0x01]

sample_1: 0x87,0xF0,0x38,0x57,0x05,0x11,0x12,0x13,0x32,0x34,[0xA7] 5 DTCs: 11/12/13/32/34

sample_2: 0x88,0xF0,0x38,0x57,0x06,0x11,0x12,0x13,0x14,0x24,0x61,[0xDC] 6 DTCs: 11/12/13/14/24/61

clearDiagnosticInformation(DTCs)
0x82, 0x38, 0xF0, 0x14, 0xFE, [0xBC]

looks like multiple responses, this list may not be complete:

0x83,0xF0,0x38,0x7F,0x14,0x21,[0x5F] note: success response

0x83,0xF0,0x38,0x7F,0x14,0x10,0x00,...

0x83,0xF0,0x38,0xXX,0xFE,0x00... Where 0xXX is value at addr 0x04E0

Unknown command response, where 0xXX is Command from Diag Tool:

0x83, 0xF0,0x38,0x7F,0xXX,0x10,0x00?,...

Great progress!

I've added some notes based on the BIU commands which are probably the same. Hopefully this helps accelerate the reverse engineering.

0x81, 0x38, 0xF0, 0x81,... startComms
0x81, 0x38, 0xF0, 0x82,... endComms
0x81, 0x38, 0xF0, 0x3E,... testerPresent (periodic keepalive)
0x82, 0x38, 0xF0, 0x1A, 0x9A, ... readECUIdentification - bytes indicating something (eg) car model etc
0x82, 0x38, 0xF0, 0x1A, 0x91, ... readECUIdentification - bytes indicating module options
0x82, 0x38, 0xF0, 0x3B, 0x12, ... writeDataByLocalIdentifier - to set various options
0x8E, 0x38, 0xF0, 0x3B, 0x10, ... writeDataByLocalIdentifier - to set various options
0x87, 0x38, 0xF0, 0x3B, 0x11, ... writeDataByLocalIdentifier - to set various options
0x86, 0x38, 0xF0, 0x3B, 0xE1, ... writeDataByLocalIdentifier - to set various options
0x82, 0x38, 0xF0, 0x3B, 0xE2, ... writeDataByLocalIdentifier - to set various options
0x83, 0x38, 0xF0, 0x31, ... startRoutineByLocalIdentifier - more significant settings (eg) handshake with new car
0x83, 0x38, 0xF0, 0x32, ... unknown
0x82, 0x38, 0xF0, 0x21, 0x10, ... readDataByLocalIdentifier - to read various data / settings
0x82, 0x38, 0xF0, 0x21, 0x99, ... readDataByLocalIdentifier - to read various data / settings
0x82, 0x38, 0xF0, 0x21, 0x11, ... readDataByLocalIdentifier - to read various data / settings
0x82, 0x38, 0xF0, 0x17, 0xFE, ... unknown
0x82, 0x38, 0xF0, 0x14, 0xFE, ... clearDiagnosticInformation - clear DTCs and update part of EEPROM that stores DTCs

This helps a lot. I am going to start with the readEcu (readRKE? ) commands and see if I can make heads or tails of the data they produce.

Edit: I am going to update my second post with responses as I go though the commands. one other command looks like a default response if the RX command is not found:
0x83, 0xF0,0x38,0x7F,(variable?),0x10,(variable?),...

Not sure if you’ve seen it, but the SSM protocol page under ‘articles’ may help.

When the module doesn’t recognise the command, it will reply with 0x7f and then echo the unrecognised command.

When the module recognises the command, it replies with command + 0x40.

Just checked some iso 14230 docs. The two remaining ‘unknowns’ should be:
Command 0x17 - readStatusOfDTCs
Command 0x32 - stopRoutineByLocalIdentifier

Thanks, updated post #3.

I want to use FastECU to test some of these commands and see how the responses reflect the TPMS sensor info in the car. I am completely out of space on my laptops HDD (thanks Qt!). Once I embiggen the HDD I can start writing some code.

When reverse-engineering a module, many clues can also come from reviewing that module's diagnostic section from the FSM.

So, the 0x21 0x10/0x11/0x99 commands probably return data that includes 4 x "Function Code" per tire, 4 x Tire Pressure, Vehicle Speed, Pressure Warning Threshold, Pressure ok threshold (per the FSM table). Usually the 0x21 commands also provide a lot of hidden data that isn't documented anywhere so you have to figure out which is which.

This snip from the SSMIII manual also implies one of the commands will return 3 bytes per item x 8 items for a total of 24 bytes. Maybe the 0x21 0x11 command? But what seems odd about this snip is that, as far as I know, TPMS IDs are 4 bytes long (8 hex digits), not 3.

You can also use the readDTC command to locate the logic that sets each DTCs, and combine this with the FSM descriptions of each DTC to hopefully figure out which variables represent pressure, Function Code, Speed etc.

Plus, one of the 0x31 routines might be the process by which a new transmitter id is registered.

So I tested out some commands today and success! Added sample data to the 3rd post. for command 0x21/0x11 it does look like the data is grouped into 3 bytes. Maybe they ignore the upper address byte and hope that there isn't a collision?

I will need to dump that actual eeprom in the car and look at the addresses on the TPMS sensors in a few tires to finish this up.



Going to put the DTCs here for future reference:
11,12,13,14: Tire pressure 1/2/3/4 is reduced
21,22,23,24: Data cannot be received from transmitter 1/2/3/4
31,32,33,34: Transmitter 1/2/3/4 pressure data abnormal
41,42,43,44: Transmitter 1/2/3/4 function code abnormal
51,52,53,54: Transmitter 1/2/3/4 battery voltage decrease
61 : Vehicle Speed is Abnormal (no speed signal when > 3.7 mph)

Good progress! The 24 bytes match very well. The 5th group of 3 bytes (‘last reception id’ ?) is a repeat of one of the first 4 groups of 3 bytes. So, that seems to line up nicely.

Thanks! I modified the spare board I had (picture in the 1st post) so I can send K-Line commands from my bench and added legs to the EEPROM so I can dump it without having to take it out of the circuit now.

The result is successful writes to EEPROM for TPMS IDs via K-Line sending SSM commands!

the 'local identifiers' for the writeData commands (0x3B) are: 0x12 to reset/clear all the TPMS IDs, and 0x10 to write new sensor IDs to EEPROM

not much success with the remaining three write commands. I get generic responses that look like failures and no new data in the EEPROMs

Nice!

Based on your thread title, does this module also perform keyless functions? I thought that was all done by the BIU.

The SSM-III manual only describes 2 TPMS processes - one is the reporting of the 8 items (already found), and the other is a process whereby it determines the 4 TPMS IDs from what is currently installed in the car. It's possible the remaining 0x3B commands relate to stages of this process.

What platform are you using for the reverse engineering? IDA Pro? Or Ghidra? What processor / language? Freescale HCS08?

Yes, this module does both TPMS and Keyless. Subaru refers to it as the RKE (remote keyless entry) module. Makes a lot of sense to do it this way from an engineering standpoint since both radios for the kays and the TPMS are sub-gig frequency.


I have a few hypotheses: 1) some other activity for TPMS such as loading additional offsets for temperature or pressure. 2) activities around the remote keyless -> adding/removing remote key IDs. 3) Setting some diagnostic or debug info. 4) sub-gig radio settings: different regions may use different frequencies for TPMS and/or have different standards on how strong the radio broadcast can be (i.e., FCC vs CE broadcast strength in the sub-gig are different)


IDA. MCU is HCS08 (MC9S08AW32). I set the RAM area from 0x0000 - 0x1860 to capture all the registers as well as RAM. Flash is 0x8000 - 0xFFFF

The SSM subroutines for data write are at 0xDEA1:
0x3B, 0x11 -> subroutine starts 0xE108

the 5 bytes in in the command look to be loaded in 0x319 to 0x31D. At ROM 0xE110 these bytes get compared to either: each other, 0x81 or zero. I tried quite a few different different data set inputs to see if I could get a different response, but no love so far.

0x3B, 0xE1 -> subroutine starts 0xE1E9

The 4 input bytes are loaded in memory at 0x319 to 0x31C. Haven't gone further on this one

0x3B, 0xE2 -> subroutine starts 0xE211

No input data via SSM other than the command. This command loads 0x01 into 0x01D4, not sure the effect.

The SSM-III manual seems to describes 3 processes for the Keyless module, which (with a bit of luck) will line up with the 3 remaining 0x3B commands.

Here's my guesses:
0x3B 0xE1 is the 4byte entry of the Keyless ID itself - because the SSM-III manual shows this is 8 digits long. From what I've seen from BIU reverse engineering, I'm guessing the Keyless module sends the ID to the BIU where it is stored?

0x3B 0xE2 is the exit for the Keyless ID Registration process - my guess is setting that RAM value to 1 indicates a recently entered ID should now be saved??

0x3B 0x11 is the 5byte entry of Customizable settings - because the SSM-III manual shows 5 options. From what I've seen from BIU reverse engineering, these options are stored in the BIU, so perhaps the RKE sends them to the BIU? Maybe this command will work if you only use 0x00 or 0x01 as values?

By the way, the first byte of every message represents the length, so it is equal to 0x80 + n where n is the length of the command or response (excluding header & checksum)