Vida CEM swapping

[RickHaleParker]

Do a PCB at easyeda.com. Then anyone can order them etched, soldered and shipped for like $10/piece (+ Teensy).

Ran into a snag on that. LCSC does not have any J1962 ( OBDII ) connectors. The J1962 will need to come from a different source. Then married to the Shield. I'm going to ahead and finish the idea I have but it is going to take awhile. I need to order some Folded J1962 from China. Then I will need to work out the footprint because I cannot find a SCD for them.

In the meantime anybody got another idea?

I got a dead DiCE sitting on the shelf. I thought about doing a VCC PCB to drop in it. There a perfectly good case, USB and J1962 cable there. Anybody else got dead DiCE laying around?

[vtl]

Rick, we have to revert this commit: https://github.com/vtl/volvo-cem-cracke ... 86c1da641d

I've got a report that the cracker no longer works for a bunch of P1 CEMs after that commit. Looking further at flash disassembly, this code

Code: Select all

ldab 0x2,X
stab 0x11,SP
eorb 0x4,X
stab 0x12,SP
eorb 0x5,X
stab 0x13,SP
eorb 0x0,X
stab 0x14,SP
eorb 0x3,X
stab 0x15,SP
eorb 0x1,X
stab 0x16,SP

does a shuffle+XOR transformation over received bytes, so they would match later the encrypted/protected pin bytes in flash. The compare routing otherwise goes linearly, the cracker's shuffle order would need to be 0 (0, 1, 2, 3, 4, 5).

You can revert via github web UI or manually with git revert <commit id>.

[RickHaleParker]

Rick, we have to revert this commit: https://github.com/vtl/volvo-cem-cracke ... 86c1da641d

I've got a report that the cracker no longer works for a bunch of P1 CEMs after that commit. Looking further at flash disassembly, this code

I issued the revert.
Dam! what went wrong? Everything looked spot on when I compared the "known" PIN numbers against the bin files ZRimaZ uploaded.

Oh well ... screwing up is now one gains wisdom. Keeps me young in the head.

We learned another way not to crack a P1 and it looks like VTL discovered something he did not know before. That is a gain.

P1 owners download the code from the VTL:Master again.

[Sh4rp]

Confirmed!

With the change in the shuffle order my readouts were so clean, that I could abort the process after the first sampling, type in the numbers with my interface and skip to the bruteforce attack. Took 10 minutes all in all now.

Such a big headache for such a small change in code

[Dudde]

Hi and nice work you all have been doing so far.
Will begin dumping and cracking my cem collection in a few weeks when i get the time.

Dudde

[RickHaleParker]

Looking further at flash disassembly, this code

Code: Select all

ldab 0x2,X
stab 0x11,SP
eorb 0x4,X
stab 0x12,SP
eorb 0x5,X
stab 0x13,SP
eorb 0x0,X
stab 0x14,SP
eorb 0x3,X
stab 0x15,SP
eorb 0x1,X
stab 0x16,SP

does a shuffle+XOR transformation over received bytes, so they would match later the encrypted/protected pin bytes in flash. The compare routing otherwise goes linearly, the cracker's shuffle order would need to be 0 (0, 1, 2, 3, 4, 5).

ldab 0x2,X ; Load Accumulator B
stab 0x11,SP ; Store Accumulator B

eorb 0x4,X ; Logical XOR with accumulator B
stab 0x12,SP ; Store Accumulator B

eorb 0x5,X ; Logical XOR with accumulator B
stab 0x13,SP ; Store Accumulator B

eorb 0x0,X ; Logical XOR with accumulator B
stab 0x14,SP Store Accumulator B

eorb 0x3,X ; Logical XOR with accumulator B
stab 0x15,SP ; Store Accumulator B

eorb 0x1,X Logical XOR with accumulator B
stab 0x16,SP ; Store Accumulator B

0x2 - 0x11
0x4 - 0x12
0x5 - 0x13
0x0 - 0x14
0x3 - 0x15
0x1 - 0x16

Hum ... 245031 that is shuffle (3) not the shuffle (2) that I changed it to.


The change to shuffle (2) as the default was based on the Pin - Bin sets uploaded by ZRimaZ

All the P1s I could confirm are Shuffle #2 {5,2,1,4,0,3}. I am going to set Shuffle #2 {5,2,1,4,0,3} as the default for all P1s. Comment all entries as confirmed or not confirmed.

HW PN, BIN PIN, PIN
8690719, 31 36 45 34 52 03, 03 45 36 52 31 34 , Shuffle 5,2,1,4,0,3 (2)
8690720, 54 61 99 29 40 20, 20 99 61 40 54 29 , Shuffle 5,2,1,4,0,3 (2)
8690722, 57 08 45 68 46 55, 55 45 08 46 57 68 , Shuffle 5,2,1,4,0,3 (2)
30765015, 34 71 64 28 13 22, 22 64 71 13 34 28 , Shuffle 5,2,1,4,0,3 (2)
30765471, 83 90 04 14 00 40, 40 04 90 00 83 14 , Shuffle 5,2,1,4,0,3 (2)
31254317, 57 78 76 72 05 61, 61 76 78 05 57 72 , Shuffle 5,2,1,4,0,3 (2)
31254749, ??? , ????, Processor mask 1M84E, HWPN @ 0xFBEB4
31254903, 22 89 14 56 28 88, 88 14 89 28 22 56 , Shuffle 5,2,1,4,0,3 (2)
31327215, ???, 217108822803, Processor mask 1L15Y, HWPN @ 0x5FEB4

[RickHaleParker]

Could somebody with Pin Gauges measure the pad sizes and hole sizes along the edge of a Teensy 4.0. I need to create a PCB Footprint from scratch.

[Dudde]

Could somebody with Pin Gauges measure the pad sizes and hole sizes along the edge of a Teensy 4.0. I need to create a PCB Footprint from scratch.

Hope this helps, https://www.pjrc.com/teensy/dimensions.html

Dudde

[RickHaleParker]

Hope this helps, https://www.pjrc.com/teensy/dimensions.html

I seen that before. It shows Pad and Hole location but not Pad and Hole size.

I could guesstimate a Pad and Hole size that should work but I prefer measurements.

My current guesstimate is 2 mm pads with 1 mm holes. that leaves .54mm spacing between pads and .2 mm wiggle room on a header pin.

[swinokur]

I think you might be looking for this: https://forum.pjrc.com/threads/60348-Ea ... post239490 ?

In that thread there's also a link to this github repo: https://github.com/phil-barrett/grblHAL-teensy-4.x

If you scroll to the bottom there's a link to gerbers (https://github.com/phil-barrett/grblHAL ... .1x207.zip), which might also be useful