Vida CEM swapping

[vtl]

That's a good catch. I must've changed that setting manually last year when I was messing with my 2002 CEM and never changed it back. Gonna try to start at third position and see if it's able to do it. Looks like first 3 are 79 92 and 97.

-2004 won't crack. I found the pin comparison code, it is "buggy": yields only a couple of CPU ticks of difference, which is not possible to detect over CAN.

You CEM-L has a "bad" code placement in flash memory. I speculated a few dozen pages back why some CEMs are harder to crack than others, that may be due to CPU executing code from flash, which has memory row/line access latency. On some CEMs the third byte compare routine does not yield extra latency, or enough extra latency to be detected over CAN.

You can always stock up enough beer and crack with CALC_BYTES 2, not 3. Within like 18 hours it will crack with brute-forcing the last 4 bytes.

[RickHaleParker]

You can always stock up enough beer and crack with CALC_BYTES 2, not 3. Within like 18 hours it will crack with brute-forcing the last 4 bytes.

Perhaps an additional routine that will execute only when the CEM fails to crack: Brute force using top candidate for B0 & B1 + cycle through a shortlist for B2. If B2 is making it into a shortlist it would take a lot less time then 18 hours.

Maximum time = B2 Shortlist range # * 10.72 minutes.

B2 Short range 3 : 3 * 10.72 minutes = 32.16 minutes.
B2 Short range 6 : 6 * 10.72 minutes = 64.32 minutes.
B2 Short range 12 : 12 * 10.72 minutes = 128.64 minutes.
.... ect.

Alternative: Use the shortlists to sort the long list of 100 B2 weights by probability. Maximum time would still be 18 hours but statistically the average time would be less then sequentially brute forcing the last four.

[Sh4rp]

I’ve been reading since the morning and just finished the last page. It is truly amazing what you guys, especially vtl and rick are doing here. I already ordered the hw to crack my v50.

I wish I could contribute but sadly im from a whole other department… (automotive design) I already thought of hitting up my colleagues at geely but they know as little about this stuff as I do and will never have access to the resources I guess…

I’ve noticed that it got quiet around T5Luke and his Configuration Writer since a few months. It seems he was really close. Hope he’s just very busy but Is there maybe anything in development by the others or anything we could do to push this forward?

Best regards from Germany

[RickHaleParker]

opps!

By default CEM_PN_AUTODETECT is turned off. Turn this back on by removing //. Unless you are cracking a CEM-L on the bench or a car with a CEM-L and a defective DIM.


/* tunable parameters */

#define CALC_BYTES 3 /* how many PIN bytes to calculate (1 to 4), the rest is brute-forced */
//#define CEM_PN_AUTODETECT /* comment out for P2 CEM-L on the bench w/o DIM */
//#define DUMP_BUCKETS /* dump all buckets for debugging */

/* end of tunable parameters */


Corrected:

Code: Select all

/* tunable parameters */

#define CALC_BYTES     3     /* how many PIN bytes to calculate (1 to 4), the rest is brute-forced */
#define CEM_PN_AUTODETECT    /* comment out for P2 CEM-L on the bench w/o DIM */
//#define  DUMP_BUCKETS                               /* dump all buckets for debugging */

/* end of tunable parameters */

[ZRimaZ]

Hi to all again!

Today I tried one more CEM-H from XC90 MY2007, HW_PN 30786890. 2x the same CEM. Unfortunately, no luck
What is strange:
- first and second have completely different PIN candidates
- no one has any of real PIN bytes.

My hardware pictures are:

Log files are here:

PIN 30786890 Try1.txt

(122.69 KiB) Downloaded 76 times

PIN 30786890 Try2.txt

(121.25 KiB) Downloaded 68 times

Sketch is the latest one from vtl repo with

Code: Select all

#define CALC_BYTES     3     /* how many PIN bytes to calculate (1 to 4), the rest is brute-forced */
#define CEM_PN_AUTODETECT    /* comment out for P2 CEM-L on the bench w/o DIM */
//#define  DUMP_BUCKETS                               /* dump all buckets for debugging */

The car has left my shop, so I have no chance to try with this car one more test. CEM files I do have, if any.

Any ideas?

[vtl]

The response time is very wrong

Code: Select all

1000 pins in 572 ms, 1748 pins/s, average response: 21 us, histogram 10 to 31 us

Do you have a logic analyzer or digital oscilloscope that can capture one request-response sequence?

[ZRimaZ]

I do have Rigol DS1054Z. But the car is already left my garage

[vtl]

I do have Rigol DS1054Z. But the car is already left my garage

Next time plz capture the signal when the latency is way off.

[ZRimaZ]

Which moment exactly?

[vtl]

Which moment exactly?

Unlock message sent, replied received. Especially the gap between those two CAN messages.

Where do you connect CAN_L_PIN to? RX of the transceiver or directly to CAN-L?