Vida CEM swapping

[Arty]

Thanks for the logs!.

In other news, a while back someone posted an SBL for the DIM for P1. I confirm it also works for P2, though I did ask my AI assistant to support a few more masks and build a more specialized but nearly autonomous tool, this is so I can dump the UEM module, which is the next goal.

I gave it 4 PDF documents which it referenced to modify the SBL source code to support MC912DG128 and MC912S and to follow the requirements more closely plus any masks(aka changes to the mcu in later revisions) + linker files to move the code into other ram regions should the original offsets overwrite running PBL stuff.

In other more exciting news, with the release of GPT 6 Astra, though I am sure Fable can also do it no problem, the models are now able to recreate software from binary code. For people with cash this means full reimplementation of TCM or ECM code but with user controlled source code.

If you need it, I can provide the SBL for the 5 DIM processor masks. Just please share something interesting with me in return)))

[dikidera]

I would be careful on what is good to be posted out in the open, just saying.

I can share how to steal a P2/P3 car also in less than a minute if it's ok for everything to be out in the open

No, it is not so easy. Yes you can crack KeeLoq from air frames. But it is not so easy that you need one frame and then you can calculate the key from it. The latest I read was that you have 65000 frames and can do the calculations within a week.

What I show here is that if you have a dump of the uem eeprom you can make a key that matches that information.
But if some evil person can take a eeprom dump of the uem, they can also write to the eeprom in the uem. If they can write they can modify it to match a key they already have. It is much easier.
What I have shown is that you can learn a key to a car and not what already is out, learn a car to a key.
So from security point of view there is nothing new here. It doesn't weaken it. It is in same level.

Do you have other information? An new novel attack on KeeLoq that is not published?

Are you serious? Is it really that hard? I wrote a generator for the 412 in a single evening. It programs via PicKit, Arduino and via my own programmer, which I cobbled together from an ST-Link dongle.

photo_2025-12-10_17-04-10.jpg

While we are on the subject of key fobs, anyone know why my fob now requires 4-5 clicks to unlock and lock the car?My first guess is car battery, the fob battery was replaced.

As for the DIM SBL I personally did my work with the available SBLs, but thank you for the kind offer.

[vtl]

While we are on the subject of key fobs, anyone know why my fob now requires 4-5 clicks to unlock and lock the car?My first guess is car battery, the fob battery was replaced.

Clean the pads on PCB?

[Treur]

No, it is not so easy. Yes you can crack KeeLoq from air frames. But it is not so easy that you need one frame and then you can calculate the key from it. The latest I read was that you have 65000 frames and can do the calculations within a week.

What I show here is that if you have a dump of the uem eeprom you can make a key that matches that information.
But if some evil person can take a eeprom dump of the uem, they can also write to the eeprom in the uem. If they can write they can modify it to match a key they already have. It is much easier.
What I have shown is that you can learn a key to a car and not what already is out, learn a car to a key.
So from security point of view there is nothing new here. It doesn't weaken it. It is in same level.

Do you have other information? An new novel attack on KeeLoq that is not published?

Are you serious? Is it really that hard? I wrote a generator for the 412 in a single evening. It programs via PicKit, Arduino and via my own programmer, which I cobbled together from an ST-Link dongle.

photo_2025-12-10_17-04-10.jpg

While we are on the subject of key fobs, anyone know why my fob now requires 4-5 clicks to unlock and lock the car?My first guess is car battery, the fob battery was replaced.

As for the DIM SBL I personally did my work with the available SBLs, but thank you for the kind offer.

Maybe the buttons themselves have worn out? Have you thought about replacing them?)))

[Yariy]

I am sure any USB sniff logs would help, as long as DiCE was used, and hopefully with VIDA for its parallel communication(usually best if done on a live car since both buses are active).

You got lots of people already setup to do CAN sniffing. You just need to answer their question: What capture format, USBPcap .pcapng files ... ect?

The attached file Volvo DiCE USB Protocol Guide is a draft. It is bound to have errors and short comings. It might give you some useful insights. It might not. I do have a basic, stripped down, no frills Linux-DiCE API written in Python. I could let you peek at.

I'll add it, it may be useful: https://github.com/wjkennedy/PyDiCE.git

[dikidera]

Are you serious? Is it really that hard? I wrote a generator for the 412 in a single evening. It programs via PicKit, Arduino and via my own programmer, which I cobbled together from an ST-Link dongle.

photo_2025-12-10_17-04-10.jpg

While we are on the subject of key fobs, anyone know why my fob now requires 4-5 clicks to unlock and lock the car?My first guess is car battery, the fob battery was replaced.

As for the DIM SBL I personally did my work with the available SBLs, but thank you for the kind offer.

Maybe the buttons themselves have worn out? Have you thought about replacing them?)))

It fixed itself somehow. I did not do anything else. I am puzzled. Now it works on first try every time.

[RickHaleParker]

I'll add it, it may be useful: https://github.com/wjkennedy/PyDiCE.git

PyDiCE compared with my Linux DiCE API

Linux DiCE API is substantially further along on the native DiCE API, based on PyDiCE commit d45ae94.

• Native USB: PyDiCE has a placeholder; Linux DiCE API works.
• Device information: PyDiCE provides detection/probing; Linux DiCE API has hardware-verified reads.
• Raw CAN: PyDiCE’s native path is unfinished; Linux DiCE API has verified LS reception, transmission and matching ECU responses.
• Reliability: Linux DiCE API implements and tests cleanup, reconnect, concurrency and queue limits.
• Native ISO15765: PyDiCE has command-table research; Linux DiCE API has an experimental implementation, but its data path remains unqualified.
• HS-CAN: Neither project has demonstrated qualification.

PyDiCE has more application/UI scaffolding, including a terminal interface and DTC helpers using other CAN backends.

Linux DiCE API has working, hardware-backed API functionality. Linux DiCE API remaining qualification gaps are still open.

***********************************************************
Linux DiCE API: implemented and missing functionality

I have a working Python Linux DiCE API for device information and raw CAN, plus an experimental native ISO15765 implementation. It is not a complete J2534 driver ... yet.

Implemented

• USB discovery, open and close: Hardware verified.
• Device information: RFC, hardware/firmware versions, supply voltage and warranty date; hardware verified.
• Raw CAN: LS at 125 kbit/s and HS at 500 kbit/s implemented. LS verified; HS reception remains unqualified.
• Standard and extended identifiers: Implemented. Extended LS reception verified; standard-ID reception remains unqualified.
• Receive: Single frames and bounded batches.
• Filtering: Software CAN-ID filters with runtime addition/removal.
• Transmission: Explicit opt-in, bounded DiCE confirmation and request/response collection. Matching LS ECU responses verified.
• Session management: Multiple sessions, concurrent callers, bounded queues, cleanup, disconnect detection and explicit reconnect.
• Python J2534-shaped raw-CAN interface: Implemented.
• Native ISO15765: Experimental setup, filtering, encoding/reassembly and transmission plumbing. Control operations verified; data path unqualified.

Missing or unfinished

• HS functional qualification: Successful reception/transmission through the API with an eligible stimulus. Controller startup alone is insufficient.
• Standard-ID reception qualification: A demonstrated 11-bit receive path.
• Native ISO15765 end-to-end verification: Reception, transmission and multi-frame flow control with a suitable ECU or peer.
• Full J2534 functionality: No C-compatible shared library, complete IOCTL/configuration interface, periodic-message API or full filter-type support.
• Other transports: K-line/ISO9141 and J1850 are not implemented.
• Broader qualification: Evidence remains limited to the tested bench CEM and hosts.

Programming, security operations and vehicle-specific diagnostics are outside the generic API’s present scope.

Versions and validation

Released 1.0.0 remains frozen. Development source contains the recent fixes and experimental additions. The built 1.1.0rc1 does not contain those recent fixes.

Last source results: 211 API/tool tests and 25 resource tests passing. These do not close the hardware qualification gaps.

[Yariy]

Tell me please. I’m trying to write a shim (a native DLL) between J2534.dll and TSDiCE32.dll. I can’t open 2 channels simultaneously. In the log file, opening the second channel ends with an error: “Device::OpenChannel() This protocol or pin is already in use.” Does Dice not support opening two channels simultaneously?

Log generated by: C:\Program Files (x86)\DiCE\Tools\TSDiCE32.dll
DLL version: 6, 1, 0, 0
Operating system version: 6.2 buildno: 9200
Date: 2026-09-14
LogValue: 4
********************************************************************************

01:35:05,446 0103 000000 PassThruOpen() enter
01:35:05,446 0100 000000 PassThruOpen() In parameter pName = NULL
01:35:05,446 0000 000000 HardwareHelper::CreateHardwareConnection() No device name given.
01:35:05,454 0000 000000 ReceiveThread() ReceiveThread() started
01:35:05,455 0100 000000 PassThruOpen() Out parameter pDeviceID = 0
01:35:05,455 0104 000000 PassThruOpen() exit
01:35:05,456 0103 000000 PassThruReadVersion() enter
01:35:05,457 0100 000000 PassThruReadVersion() Out parameter pFirmwareVersion = 5.6.2-Aug 22 2011 09:03:43
01:35:05,457 0100 000000 PassThruReadVersion() Out parameter pDllVersion = 6, 1, 0, 0
01:35:05,457 0100 000000 PassThruReadVersion() Out parameter pApiVersion = 04.04
01:35:05,457 0104 000000 PassThruReadVersion() exit
01:35:05,464 0103 000000 PassThruConnect() enter
01:35:05,464 0100 000000 PassThruConnect() In parameter DeviceID = 0
01:35:05,464 0100 000000 PassThruConnect() In parameter ProtocolID = CAN
01:35:05,464 0100 000000 PassThruConnect() In parameter Flags = 0
01:35:05,464 0100 000000 PassThruConnect() In parameter BaudRate = 500000
01:35:05,469 0100 000000 PassThruConnect() Out parameter pChannelID = 1
01:35:05,469 0104 000000 PassThruConnect() exit
01:35:05,471 0103 000000 PassThruStartMsgFilter() enter
01:35:05,471 0100 000001 PassThruStartMsgFilter() In parameter ChannelID = 1
01:35:05,471 0100 000001 PassThruStartMsgFilter() In parameter FilterType = PASS_FILTER
01:35:05,471 0100 000001 PassThruStartMsgFilter() Mask:
01:35:05,471 0100 000001 PassThruStartMsgFilter() msg[0].ProtocolID = CAN
01:35:05,471 0100 000001 PassThruStartMsgFilter() msg[0].RxStatus = 4096
01:35:05,471 0100 000001 PassThruStartMsgFilter() msg[0].TxFlags = 0
01:35:05,471 0100 000001 PassThruStartMsgFilter() msg[0].Timestamp = 15185753
01:35:05,471 0100 000001 PassThruStartMsgFilter() msg[0].ExtraDataIndex = 15185793
01:35:05,471 0100 000001 PassThruStartMsgFilter() msg[0].DataSize = 4
01:35:05,471 0100 000001 PassThruStartMsgFilter() msg[0].Data = [0x00, 0x00, 0x07, 0xff]
01:35:05,471 0100 000001 PassThruStartMsgFilter() Pattern:
01:35:05,471 0100 000001 PassThruStartMsgFilter() msg[0].ProtocolID = CAN
01:35:05,471 0100 000001 PassThruStartMsgFilter() msg[0].RxStatus = 4096
01:35:05,471 0100 000001 PassThruStartMsgFilter() msg[0].TxFlags = 0
01:35:05,471 0100 000001 PassThruStartMsgFilter() msg[0].Timestamp = 15185753
01:35:05,471 0100 000001 PassThruStartMsgFilter() msg[0].ExtraDataIndex = 15185793
01:35:05,471 0100 000001 PassThruStartMsgFilter() msg[0].DataSize = 4
01:35:05,471 0100 000001 PassThruStartMsgFilter() msg[0].Data = [0x00, 0x00, 0x07, 0xc9]
01:35:05,471 0100 000001 PassThruStartMsgFilter() Flow: NULL
01:35:05,472 0100 000001 PassThruStartMsgFilter() Out parameter pFilterID = 0
01:35:05,472 0104 000001 PassThruStartMsgFilter() exit
01:35:05,473 0103 000000 PassThruConnect() enter
01:35:05,473 0100 000000 PassThruConnect() In parameter DeviceID = 0
01:35:05,473 0100 000000 PassThruConnect() In parameter ProtocolID = CAN_XON_XOFF
01:35:05,473 0100 000000 PassThruConnect() In parameter Flags = 0
01:35:05,473 0100 000000 PassThruConnect() In parameter BaudRate = 125000
01:35:05,473 0300 000000 Device::OpenChannel() This protocol or pin is already in use.
01:35:05,473 0300 000000 PassThruConnect() Could not open channel
01:35:05,473 0104 000000 PassThruConnect() exit result: ERR_CHANNEL_IN_USE.....

[RickHaleParker]

Tell me please. I’m trying to write a shim (a native DLL) between J2534.dll and TSDiCE32.dll. I can’t open 2 channels simultaneously. In the log file, opening the second channel ends with an error: “Device::OpenChannel() This protocol or pin is already in use.” Does Dice not support opening two channels simultaneously?

I don't have the answer for that .... but .. It looks like a conflict over a resource.

01:35:05,469 PassThruConnect() Out parameter pChannelID = 1
.
.
01:35:05,473 PassThruConnect() In parameter ProtocolID = CAN_XON_XOFF
01:35:05,473 Device::OpenChannel() This protocol or pin is already in use.
01:35:05,473 PassThruConnect() exit result: ERR_CHANNEL_IN_USE

[Yariy]

Tell me please. I’m trying to write a shim (a native DLL) between J2534.dll and TSDiCE32.dll. I can’t open 2 channels simultaneously. In the log file, opening the second channel ends with an error: “Device::OpenChannel() This protocol or pin is already in use.” Does Dice not support opening two channels simultaneously?

I don't have the answer for that .... but .. It looks like a conflict over a resource.

01:35:05,473 PassThruConnect() In parameter ProtocolID = CAN_XON_XOFF
01:35:05,473 Device::OpenChannel() This protocol or pin is already in use.
01:35:05,473 PassThruConnect() exit result: ERR_CHANNEL_IN_USE

I also thought the problem was with “PassThruConnect() In the parameter ProtocolID = CAN_XON_XOFF”. I’ll keep going. I found the solution for writing the layer between the libraries to be interesting. I wonder how much slower the data exchange will be on the CAN bus.Thanks