Vida CEM swapping

[Treur]

Next small step with my V70 BiFuel 2006.
Readout of CEM-L with M30855FW cpu using a SBL.
Only read implemented so far.
Decrypt of eeprom data is implemented but not verified that data is correct. It looks good, much more 0 values now and not just random. Parts that was FF (unused) now looks like random, but it is as expected.
Sharing both c cource for the sbl and a python script using it. I'm running on a old raspberry pi using socketcan. There is a long delay between every message sent over can as otherwise I get overflow in socketcan in the raspberry end. Maybe I should upgrade my old v3 raspberry to something faster and newer.
I have only tested it on bench, not in car.

What about CEM-L with M30835? I have some encoded SBL, but just Dikidera can make it work

[oscilloscope]

Does anyone know anything about the seed key in SID206? I asked the module for seed, but it gives me some strange data -

7E8 05 67 01 00 01 E0 55 55
7E8 05 67 01 00 17 15 55 55
7E8 05 67 01 00 5E F8 55 55
7E8 05 67 01 00 53 68 55 55
7E8 05 67 01 00 11 7C 55 55
7E8 05 67 01 00 14 0A 55 55
7E8 05 67 01 00 45 B1 55 55
7E8 05 67 01 00 1D 91 55 55

Обычный ответ по протоколу UDS
7E8 = 7E0 + 8
5 - длина ответа в байтах
67 01 - ответ на от сервиса 27 (+ 40) 01
00 01 E0 собственно само семя. Последние 2 байта, это добивание пакета до 8 байт. Алгоритм генерации ключа по семени широко используемый. У меня есть реализация такого алгоритма на C https://github.com/prometey1982/VolvoTo ... ps.cpp#L28

interesting git repo

[dikidera]

Next small step with my V70 BiFuel 2006.
Readout of CEM-L with M30855FW cpu using a SBL.
Only read implemented so far.
Decrypt of eeprom data is implemented but not verified that data is correct. It looks good, much more 0 values now and not just random. Parts that was FF (unused) now looks like random, but it is as expected.
Sharing both c cource for the sbl and a python script using it. I'm running on a old raspberry pi using socketcan. There is a long delay between every message sent over can as otherwise I get overflow in socketcan in the raspberry end. Maybe I should upgrade my old v3 raspberry to something faster and newer.
I have only tested it on bench, not in car.

Code: Select all

~/cem/tools/sbl $ python3 sblflasher.py
Bus sleep....Bus idle
Check SBL running..NO
Sending SBL....Done
Checking loaded SBL OK
Starting SBL Done
Check SBL running..YES
Read memory 0xfb0000 -- 0xffffff.
  0xfb0000................
  0xfc0000................
  0xfd0000................
  0xfe0000................
  0xff0000................
  Checking CRC..OK
Read memory 0x0 -- 0x7ff.
  0x000000
  Checking CRC..OK
Read memory 0xffff00 -- 0xffff3c.
  0xffff00
  Checking CRC..OK
Exiting, Restart bus.Done

Please try sudo ifconfig can0 txqueuelen 1000/sudo ifconfig can1 txqueuelen 1000 this helped me when writing SBL. There were also issues in some kernels with the drivers that I had to downgrade to an earlier kernel.

[porcupine7655]

Next small step with my V70 BiFuel 2006.
Readout of CEM-L with M30855FW cpu using a SBL.
Only read implemented so far.
Decrypt of eeprom data is implemented but not verified that data is correct. It looks good, much more 0 values now and not just random. Parts that was FF (unused) now looks like random, but it is as expected.
Sharing both c cource for the sbl and a python script using it. I'm running on a old raspberry pi using socketcan. There is a long delay between every message sent over can as otherwise I get overflow in socketcan in the raspberry end. Maybe I should upgrade my old v3 raspberry to something faster and newer.
I have only tested it on bench, not in car.

Looked somewhat more on the decrypted eeprom data. It is correct decrypted as all data is in two records.
Yellow is first instance of data, green backup.
(Red is unused area, FF in unencrypted)

cem-eeprom-backup-pages.png (231 KiB) Viewed 456 times

[porcupine7655]

Please try sudo ifconfig can0 txqueuelen 1000/sudo ifconfig can1 txqueuelen 1000 this helped me when writing SBL. There were also issues in some kernels with the drivers that I had to downgrade to an earlier kernel.

Thanks for the hint. Unfortunately I have already tested it and did improve it somewhat.
In this state of the work I'm not focused in speed, I'm more concerned in verifying data is correct.

[dikidera]

I have used Python and RPI for the last 2 years+, no data issues with ZERO verification.

[Yariy]

I have a problem loading sbl into the CEMB block. SBL cannot be loaded if the block is not new (pin code is not FF FF FF FF FF FF). Also, the Pin code cannot be changed to FF FF FF FF FF FF respectively. Any ideas? How is this done in more modern CEM blocks?

[Yariy]

So far, I have only one thought - to replace the main program, which PBL switches to during the download process, with another code, but this is a long time. That is, you need to read the area where the main program starts and save it, then erase and write the replacement code, respectively, after successful execution, return everything back.

[Yariy]

Does anyone know what this command does - 40 B2 11 - "E2 EPROM force write"?

[Yariy]

I replaced the flash area from where the main program (OS) starts with SBL. SBL has started successfully and reads the entire flash. The difficulty in this approach for running SBL is to write even one byte of information in the flash area, it must be completely erased. Then record the SBL and, after successful operation, rewrite the entire area again. But, for example, the EEPROM area is flashed, rewritten byte by byte, how is this done?