RomRaider

I've been spending countless hours in Ghidra attempting to understand most functions and variables from the E2WG200G ROM. It started as an investigation into how knock control works (there is no IAM in this ROM), and it just went on from there. I'm about two thirds the way through.

Anyway, I have come across some HCAN RX/TX functions. The TX ones seem to transmit key parameters (things like Engine Speed, and switch states). Quite a few of these are different to the parameters accessed by the SSM_Get Function calls. The RX functions seem to receive key user defined variables like Idle Speed Targets, which I assume must be done via some other SSM functionality.

So, if there was some documentation (SSM or otherwise) that listed the order of these TX/RX parameters, more parameters could be defined as easily as the SSM_Get parameters. I have looked through the FSM and the SSMIII User Guide, but I can't see a list that resembles the data in the HCAN RX/TX Functions. Maybe someone else will recognise them?

A way to find one of the HCAN TX functions is:
- Find the SSM_Get function that provides the Power Steering Switch S8 (along with other switches)
- The SSM_Get function calls another function which returns the S8 switch state (assume this is called Func_Return_Pwr_Steering_S8)
- Find all the references to Func_Return_Pwr_Steering_S8. The first call (in ROM address order) should be one of the HCAN TX Functions

The HCAN TX Functions prepare 8 bytes of data in a RAM location, and then these 8 bytes are transmitted via HCAN Registers. The function mentioned above prepares in RAM the following parameters, in order:
Byte 0: Cranking Fuel IPW Compensation (combination of a number of Compensations)
Byte 1: Not sure - relates to Manifold Relative Pressure
Byte 2: Not sure - a Factor used in Timing Calculations
Byte 3: Not sure - related to Timing
Byte 4: Accelerator Pedal Angle
Byte 5: Engine Speed byte 1 of 2
Byte 6: Engine Speed byte 2 of 2
Byte 7, bit7: Main AF Learning System ON/OFF
Byte 7, bit6: Idle Switch S5
Byte 7, bit5: Not sure - relates to a comparison between ECT parameters
Byte 7, bit4: Set when ECT is out of range on the lowside
Byte 7, bit3: Power Steering Switch S8
Byte 7, bit2: AC Status ON/OFF
Byte 7, bit1: Not sure
Byte 7, bit0: Torque Permission Signal S56

At the end of the TX Function, there is a call to the function that actually does the transmitting. This function is passed an argument that is the base address in ROM containing details of how this particular TX/RX function should operate. The structure of this information is:

Bytes 0-1: 0x00 00
Bytes 2-3: CAN-ID for the message - for example 0x0410
Byte 4: 0x00 for TX or 0x01 for RX
Byte 5: Number of the particular TX/RX Function - ranges from 0x01 to 0x0D - the one above is number 0x04. Also an offset to determine exactly which HCAN Register to use
Byte 6: Number of Bytes to TX/RX - 0x08
Byte 7: 0x00
Bytes 8-11: RAM address where the data to be TX/RX comes from/goes to - eg: 0xFF FF 52 A8
Bytes 12-15: 0x01 00 00 00

There are 13 HCAN TX/RX Functions in this ROM, so if the order of these parameters was known and standardised, this could accelerate the ROM definition process. Or if someone out there has a fully defined ROM, they would be able to work out what each of the bytes represent in each of the 13 HCAN TX/RX functions. I have checked one other ROM (E2VG222B) and found the same functions using the method above, so it seems possible it is standardised.

So, I'm hoping this list of parameters/switches above is recognisable to someone? Or perhaps someone with a well defined ROM can find these HCAN TX/RX functions and share the list of parameters they access?

(Apologies if this ground has been covered previously, I couldn't find it in the forums)
(edit: fixed up the format of the data in ROM)

I'm not aware of many posts on this forum regarding the CAN messaging. The folks working on the diesel ROMs did post their findings here:
http://web.archive.org/web/201512200022 ... -messages/
There may be a few similarities.

Thanks for the info dschultz. It looks like the messages probably are standardised, but there are still many bytes/bits that aren't understood. I guess the content of the specific CAN messages *must* be documented somewhere, but nowhere I can locate.

Oh well, seems like a dead-end for now.

The way forward.. Not a dead end.. A2l

Did you look into this further?

I did define as much of the CAN messages as I could. There is another post on this called ‘Decoding CAN messages’.

That should help with defining an ECU because it provides more variables to ‘propagate’ the reverse engineering process.

Can you explain a bit more how A2L could be used? It seems like OEMs use CCP and A2L files during ECU development. But I don’t think the associated CCP commands survive into the ‘published’ ECU ROMs that folks pull from their cars. The A2L files look like they require (as inputs) the ECU RAM addresses for the various ECU parameters. So creating an A2L file from the ROM would first require reverse engineering the ROM (ie) the same process that currently occurs. If the OEMs A2L file was available that would be different, but I’m guessing they aren’t generally available?

Dont try and explain what you do not understand fully..... so here is a link to explain for me...
Im sure this will make a lot more sense to you.. But the way i read it, its all there just need to piece it together... (mind ive read it a few times now..its a good read)

https://www.csselectronics.com/pages/cc ... n-protocol

Ive also seen this within another program HUD Ecu Hacker.. I read a ECU DelphiMT05.2 of which it knew the structure and segments but the OS on the rom it did not.
It then defined the rom and wrote a definition file for it.. But i think this was done by reading the calibrtion file in the rom that was downloaded..

Yes, I read that before writing my prior post. Here are a few key extracts:

“CCP/XCP is designed specifically for pre-launch measurement and calibration by the OEMs. Typically, the CCP/XCP access to ECUs is disabled once vehicles are ready for launch.”

“A2L - ECU Description Files
In the prior sections, we've occasionally referred to "ECU description files". An ECU description file contains everything a master tool needs to know to communicate with an ECU.”

Note that the A2L snippet shows the A2L file contains the address of each ECU parameter.

“In some cases all it takes to communicate with an ECU is the A2L file and a suitable CAN tool. As evident, one can also simply extract a subset of the A2L file to configure a device e.g. for measurement of specific signals. However, without the A2L file, it's practically impossible to perform communication and hence many OEMs do not require any additional security measures beyond keeping the A2L file under lock.”

So, without the OEM’s A2L file nothing can be done except the current process of manual reverse engineering.