RomRaider

I've gone through the SSM Functions in my ROM and a more modern MY19 one (both SH7058) to get a better understanding of what the SSM Functions can do.

I thought I'd share a few things I didn't realise, given that perhaps others may find them useful. Caveat: this is based on examining the logic in the ROM, I haven't actually tried these on a car. So, I'm happy to be corrected if I got it wrong.

0xB0 Block Write
The logic allows writing to the ROM area from 0xC0000 up to 0xFFB80 (which has almost all the maps and variables that are used for tuning). But, in practice it tries to write, nothing changes, and it echoes back the unchanged value. This functionality might be left over from factory testing on ECUs that are pure RAM, who knows.

0xB8 Address Write
It's less of an 'Address Write' function and more of a 'SSM_Set' function. I had thought the Address field of [AA_1] [AA_2] [AA_3] meant you could write to an address 0xFF[AA_1][AA_2][AA_3]. However, it looks like an SSM_Set function is called with the offset being ([AA_2][AA_3] * 4) and the data being [DD]. The offsets match those of the SSM_Get functions. For example, the Global User Timing Adjustment (P239) is at an offset of 0x1BC from the SSM_Get Base. Dividing by 4 gives 0x6F. So in a Address Write command, setting [AA_1] [AA_2] [AA_3] to [0x00] [0x00] [0x6F] and [DD] to [0x01] would set the Global User Timing Adjustment to 0x01

0xA0 Block Read
operates as you would expect, although it won't read these sections of ROM / RAM:
- 0x00000000 to 0x00002000 - the basic IO and bootloaders
- 0x000FFB80 to 0xFFFF2000 - Checksums, VBR and Interrupt Management parts of RAM
- 0xFFFF3FE4 to 0xFFFFFFFF - Peripherals, some RAM variables and Chip Registers

0xA8 Address Read
in most cases, this works as expected. But for low address values, this is the ‘SSM_Get’ function. If [A1_1] != 0xFF and the Address chosen is less than 0×0350, then it calls the SSM_Get function with the offset being ([A1_2][A1_3] * 4).

0xBF ECU Init
0x9F ECU Init
As well as 0xBF, there seems to be another ECU Init command (0x9F) that gets the ECU ID from a RAM Address. Not sure why... maybe this is a remnant from factory testing of some kind...?

Other functions
There are other functions which don't seem to be documented much, especially 0x27 which initiates the ECU Challenge/Response process. Happy to share more info on that if folks are interested.

Edit: fixed up some inaccuracies

Maybe update the wiki with your new found info if not already present.
https://www.romraider.com/index.php/Rom ... smProtocol

Thanks dschultz. Wiki updated.

As well as the SSM functions, I've now been through the bootloader and on-chip kernel.

A few things of interest:
- as mentioned above, the 0xB0 Block write function looks like it can write to ROM in the range 0xC0000 to 0xFFB80. There appears to be no special flashing process. The only thing that happens is that the UBC is disabled first. The UBC looks like it is set to trigger an interrupt upon writing to the ROM area. So this is disabled, and then the ROM is written to. It is re-enabled after ROM writing is finished.
- the commands 0x81, 0x83, 0x27 (Challenge/Response) and 0x10 give access to the bootloader
- the bootloader (at approx addresses from 0x1000 to 0x2000) then has commands 0x34 (validate RAM address to load kernel), 0x36 (de-encrypt kernel and write it into RAM) and 0x31 (jump into the kernel)
- the on-board kernel (at addresses 0x4C to 0xAA4) has various commands including ones to load an address into the stack pointer, copy data to that address (presumably a flash function), and jump to an address in the stack pointer (perhaps a way to exit the kernel). Command 0x31 requires the kernel to have a total checksum of 0x5AA5. Interestingly, the on-board kernel does not seem to have that checksum - so maybe the on-board kernel isn't intended to be loaded into RAM. Maybe only custom kernels were intended to be loaded into RAM...?
- there seems to be a way to enter the kernel itself (at its ROM location), either during initial startup or at any stage via a special HCAN message of 0xFF 0x86 0x00 0x00 0x00 0x00 0x00 0x00. So, maybe you can use the on-board kernel for flashing from its ROM location?

The bootloader entry process, and the bootloader commands were described here and there many years ago. I haven't seen any commentary on the on-board kernel before.

Has anyone used the onboard kernel? Has anyone entered it via the HCAN message? Has anyone used it for flashing?

Appreciate your digging... I suspect one of the few "public" people who would have insight onto this is Colby @ Tactrix. I wouldn't be surprised if this is closely related to the "subarucan" flash method used by ECUFlash.

Thanks solidxsnake.

I have looked a bit closer and thinking about it further, I think what I was calling a kernel is actually also a bootloader.

The first address area (from 0x4C to 0xAA4) looks more like a CAN bootloader. The function that copies RX'd data into memory is restricted so you can only copy into addresses in the range 0xFFFF0000 to 0xFFFFBFFF (ie) RAM addresses. Access into this bootloader is only possible via CAN. Data comes in via CAN RX. And outgoing messages get TX'd via CAN.

The second address area (from approx 0x1000 to 0x2000) is all accessed via SCI2 (presumably K-Line). So this one looks like a SCI2 bootloader.

Seems odd that Denso/Subaru decided you needed keys/encryption to access the second bootloader, but not the first.

I'm guessing ECUFlash has modified one of these bootloaders to make it a kernel. The CAN one is simpler, so maybe that one. If you stick to using CAN, the modifications required would be to remove the address restrictions and maybe add in the UBC disabling (to allow copying to ROM).

Still interested if anyone has delved into this and used the CAN bootloader (or kernel)?

Looking at the code, I think this is how the address restrictions work in the SSM functions.

There are three flags set to either 1 or 0.
- Flag 1: indicates whether the area can be read by SSM
- Flag 2: indicates whether the area can be written to by SSM
- Flag 3: indicates whether the UBC needs to be disabled before writing by SSM

And they are applied as follows (the 3 flags are shown as 1s or 0s)...

*There is another special byte that is required to have its third bit set to off before the area from 0x2000 to 0xC0000 can be read. The default value for this byte is 0x4, so it needs to be set to anything that has the third bit off. This byte is set using the 'Address Write' function (which is really an SSM Set Function) using an offset of 0x0 and (eg) a value of 0x0. The full command would be 0x80 0x10 0xF0 0x04 0xB8 0x00 0x00 0x00 0x[Checksum]. This sets the special byte, and then this ROM region should be readable by SSM. So, it should be possible to read almost the entire ROM just using SSM.

The 0xFFFFF2DC4 and 0xFFFFBFE4 addresses change from ROM to ROM, but the other addresses appear static.

Caveat: not yet checked on a car, I need to find a way of issuing raw SSM commands to a car, hopefully I can do this with the 'Test App' in RR editor...?

I'm still curious if the 0xB0 command can be used for tuning of maps and parameters, and live tuning as well. Does anyone want to try it out? I don't have a spare ECU lying around... not sure if you would also need to write some extra data into a blank region of the ROM to make sure the checksum doesn't change. This could be automated in RR if the technique works.

Edit: I tried the 0xB0 command on the maps area. The SSM function thinks it works, but the ROM doesn't change and it echoes back the unchanged value. I'm guessing this is left over from factory testing. Kinda makes sense that you can't change ROM as if it was RAM.

As an update, I have now verified on my car the operation of the 'special byte' described below to enable SSM reading of the ROM from 0x2000 upwards. You can use the 'Test App' in RR - set it to 'Write', Address = 0x000000, 1 byte length, Data of 0x0. This will set the 'special byte' to 0x00 after which you can read the ROM from 0x2000 upwards.

Nice work, and thanks for posting it up. If you're a Python guy, I put together a J2534 library: https://github.com/Shamtam/PyJ2534

There's also a good chunk of code here that implements most of SSM that you can probably use to communicate via command-line/interactive Python session: https://github.com/Shamtam/PyRRhic

Thanks solidxsnake, I'll look into that code. I've been using the RR 'Test App' so far which is ok for the basic SSM functions. Whilst the 'Test App' is helpful to get the syntax correct, a RR development suggestion would be to also have a free text command line option. Especially if anyone wants to take on the kernel side of things.

I think I've found another little gem inside the various SSM Set functions that are triggered by the 0xB8 command. At offset 0x60 * 4 there is a function to clear all the DTCs and MIL if the data payload is set to 0x40. It uses the same function as a General Scan Tool in Mode 04. Unless I'm wrong, the only way to clear DTCs with RR is to reset the entire ECU which wipes out all the Learned Values. So, this could be a nice little extra function for RR to clear DTCs without resetting the ECU. Reset it back to 0xAA once finished.

The syntax should be: 0x80 0x10 0xF0 0x04 0xB8 0x00 0x00 0x60 0x40 0x[Checksum]. Using the RR Test App this would be 'Write', Address of 0x000060, Data of 0x40, untick 'Block'. And then reset it using: 0x80 0x10 0xF0 0x04 0xB8 0x00 0x00 0x60 0xAA 0x[Checksum]

I tested it on my car, but because I didn't have any DTCs or MIL active, nothing obvious changed. Happy for someone to give it a try and let me know.

Not sure if this is useful, but hopefully it is for someone.

There are some other SSM Set functions which I haven't figured out yet. Work in progress...