Vida CEM swapping

[dikidera]

I think I have finally cracked these CAN IDs and how they are stored.

It appears that in the Volvo CAN signal configuration, the CAN id is stored as a serialized packet of the raw message buffer for that particular architecture

In the ETM, one of the IDs is stored as 09 18 00 22. The CAN message buffer for MC68376 is as follows



As such if we use this bit extractor I cobbled up

Code: Select all

id = (a << 21) | ((((b & 0xE0) << 18))) | ((b & 0x7) << 16) | (((c) & 0xFF) << 8) | d & 0xFE

we get 0x01200022, however somewhere in the setting up process, the CAN ID can be mutated perhaps to signal a multiframe CAN sequence or signal if it's a receiver(ECM->ETM) or sender(ETM->ECM). In my car with a running engine, the ID 01200021 is from the ECM in response to fetching Dynamic Records. You can see that 0x01200022(decoded from ETM's signal configuration) and 0x1200021 are similar but differ with one byte.

I dumped all such CAN IDs from the ETM, and none match 1:1 specifically the IDs I have on the bench and on a running car there are small differences. But I am positive this is how they are stored. I cannot say if the encoding scheme is the same(based on CAN msg buffer) for M32C, Denso's SH2 or other processors..

[rkam]

I get 0x1200011

Something like this:
id = (a << 21) | ((((b & 0xE0) << 18))) | ((b & 0x7) << 15) | (((c) & 0xFF) << 7) | ((d & 0xFE) >>1)

Code: Select all

00001001 00011000 00000000 00100010
-------- ---xx--- -------- -------x
87654321 098..765 43210987 6543210
00001001 000  000 00000000 0010001

00001001000000000000000010001

22&FE=22  0010001.  >>1 : ........ ........ ........ >0010001
00&FF=00  00000000  <<7 : ........ ........ .0000000 0<<<<<<<
18&07=00  .....000  <<15: ........ ......00 0<<<<<<< <<<<<<<<
18&E0=00  000.....  <<18: ........ ...000<< <<<<<<<< <<<<<<<<
09        00001001  <<21: ...00001 001<<<<< <<<<<<<< <<<<<<<<

-----------------------------00001 00100000 00000000 00010001

[dikidera]

I think you are correct. That does look more probable. I have forgotten the last rtr bit and as I was modifying the code I forgot to update the bit positions to be 15 not 16

Thanks to you, I also found another bug which slipped through the cracks

id = (a << 21) | ((((b & 0xE0) << 18))) | ((b & 0x7) << 15) | (((c) & 0xFF) << 7) | (d & 0xFE) >> 1

With this the decoded CAN ids now match with the CAN dump. Which means there may be no mutation afterall.

Now the reverse is required. Given a CAN id, convert it to several architecture dependent MSG buffers aka encoded CAN ids.

With this, I have finally solved the mystery of the CAN ids and how they are formed. It only took me 2 years and 3 months or so.

In the ETM the general structure of a CAN signal is this

ROM:0000601E dword_601E: dc.l $25000001 <-- will reverse later on ; DATA XREF: sub_9334+4E↓o
ROM:00006022 dc.l unk_4006B <--either receive or send
ROM:00006026 dc.w $4000 <-- unknown but may be position of bits/byte in the CAN data buffer
ROM:00006028 dc.l unk_40069 <--either receive or send
ROM:0000602C dc.l unk_40000 <- not known actually, this is RAM end
ROM:00006030 dc.l dword_641A <-- most important. A pointer which describes the CAN id.

dword_641A: dc.l $5080100 <-- will reverse later on ; DATA XREF: ROM:00006030↑o
ROM:0000641A ; ROM:00006046↑o ...
ROM:0000641E dc.l unk_40028
ROM:00006422 dc.l unk_40068
ROM:00006426 dc.w 0
ROM:00006428 dc.l 5 <--- I think this was mailbox buffer
ROM:0000642C dc.b 0
ROM:0000642D dc.b 0
ROM:0000642E dc.l $84980040 <---- can ID corresponds to 12802011 but never seen in dumps?
ROM:00006432 dc.b $FF <-- |
ROM:00006433 dc.b $BE | unknown modifiers for now
ROM:00006434 dc.b $F <-- |
ROM:00006435 dc.b $FF
ROM:00006436 dc.b $FF
ROM:00006437 dc.b $FF
ROM:00006438 dc.b $FF
ROM:00006439 dc.b $FF

Addendum it needs more work. There are a few CAN ids it isnt decoding correctly.

The correct version is now

id = (a << 21) | ((((b & 0xE0) << 13))) | ((b & 0x7) << 15) | (((c) & 0xFF) << 7) | (d & 0xFE) >> 1

[prometey1982]

Is it possible for any of you programmers in this thread to help me out?
I promise at the end of my project there will be a sweet surprise for end users but I need help or some pointers on the following:

Using Visual Studio 2022 C++, I want to use dice J2534 commands, can anyone point me in the direction of how to do this?
What do I need to import etc?
I know SDA has a sample project but it doesn't explain much.
If I do a driver function extraction on known apps that work with dice I don't see the dice drivers getting loaded.

I know some of you have made apps for dice reading and flashing, you don't have to give me a step by step but some good pointers would do the trick.

Thank you all

You can use my project as reference
https://github.com/prometey1982/VolvoTools

[scaro]

Is it 2020 ETM? Havent take any of them apart. Have a couple old MMs but havnt taken them apart yet. I was just thinking that the chips you talked about is "old". Is these inside really?

I now that i should have files for "upgraded" ETM (Magnetti Marelli) for the Brick P2 somewhere. Upgraded them with SDA long time ago.
Not that it will help you in this case.

Do you have SDA files for Marelli? I need SBL. Want to try for reflash.

I should have for the one for like 99-04 ETM. Have updated Turbo ETMs with it long time ago. Afaik Turbo and N/A use same hardware and only diff in soft and maybee year, but could be wrong. Lost the PC I used at the time but have old one with VCT2000 (havnt used this myself not even checked whats on disk could be alot of fun things). I should even have a bit more stuff laying. Could be a USB stick somewhere from the lost PC.

What i can recall it was 3 softs used when update. SBL,config,flash or something

[scaro]

Have fixed a CEM 2001 these days (Key & ECU gone) had to sync a ECU (SH7055) to it and made keys. Starts and works good now.

Used BDM for Arduino 2560. Know T5Luke have one for Nano on forum but i didnt have nano and didnt get it working on Uno3.
Ecu, desoldered 93C56 and read in programmer. It would be good to read these on bench without soldering as i can with "newer" SH7058...

Tested to add both a new transponder and a used key to it, both starts car. It wasnt the same approach as the L-shaped CEM i had to "add transponder" in DHA to make it "fit" car even that i have written transponder code in cem and key. Seems like when using "add transponder" it writes new crypt to key because now i cant compare my known transpondercode with the ones in the keys. That was possible in the L-shaped one? Anyway it works but good to know.

[scaro]

One more thing. Read some of my UEMs and checked remote ID and code. Made some maps with Winols. Seems like there is som part that could be "logincode" will check it out more. If there is then i can look in DHA for IDs and more. It only helps when having known remotes but it could be possible to add new ones maybee.

Will the code thats visible in UEM MCU be the one showing when "radiosniffing" or is it "only" remote ID?
I could have a radio usb stick somewhere when i thought about it...

Seems like remotes should be possible to read as it have pads for it. Havnt checked it more yet.

[Dudde]

One more thing. Read some of my UEMs and checked remote ID and code. Made some maps with Winols. Seems like there is som part that could be "logincode" will check it out more. If there is then i can look in DHA for IDs and more. It only helps when having known remotes but it could be possible to add new ones maybee.

You need uem pincode? If so i can check the adress of where it is located

[scaro]

One part is 3byte and the other 6byte. Could be login and sync with cem or nothing?? just thougts.
I shall try the bytes in DHA and see what is happening when getting time.

[alfons38]

Hello

I have build volvo cem cracker teensy work good on p1 p2 but not on p3

I use p3 script


Thanks Have nice day