Vida CEM swapping

[RickHaleParker]

I get pin after disconnecting battery

Do you mean a Reinitialization by disconnecting the negative terminal and reconnecting with the key in POSII ?

[raikonen]

I get pin after disconnecting battery

Do you mean a hard reset by disconnecting the negative terminal and reconnecting with the key in POSII ?

I was trying around 10 times and nothing was happening, my key was in as I was doing manual conversion(and if ECU,CEM thinks that gearshifter is not in P you cannot get key out)... but not in second position, just tried to disconnect battery and give another try and it worked for me

[RickHaleParker]

I was trying around 10 times and nothing was happening, my key was in as I was doing manual conversion(and if ECU,CEM thinks that gearshifter is not in P you cannot get key out)... but not in second position, just tried to disconnect battery and give another try and it worked for me

The P2s crack without the key in. The above process will force all control units to reinitialize to a ready state.

[RickHaleParker]

CEM-L & CEM-H always on power pins ( No key inserted condition ).

B2, B3, B16, B24
E:A & E:B The heavy red wires. Power to the fuse banks.

Grounds D:6 & B:5

----------------------------------------------------------------------------

Ignition switch symbols
30 = Constant power from the battery to switch

Switched side of Ignition switch.
S = Powered upon insertion of key, CEM D:15.
X = Accessories, CEM D:8.
15 = The switch remains connected during start, CEM D:16.
15l = Contact is broken while starting. Not use on CEM-L & CEM-H.
50 = Start. CEM D:60.


Key insertion ( S ) CEM D:15 .
POS I ( S, X ) CEM D:15, D:8 .
POS II ( S, X, 15 ) CEM D:15, D:8, D:16 .
POS III ( 15, 50) CEM D:16, D60 .

[raikonen]

I was trying around 10 times and nothing was happening, my key was in as I was doing manual conversion(and if ECU,CEM thinks that gearshifter is not in P you cannot get key out)... but not in second position, just tried to disconnect battery and give another try and it worked for me

The P2s crack without the key in. The above process will force all control units to reinitialize to a ready state.

c70 mk2 is P1

[RickHaleParker]

c70 mk2 is P1

Has any of the P1 owners tried cracking without the key inserted.

[vtl]

c70 mk2 is P1

Has any of the P1 owners tried cracking without the key inserted.

Yes. Not the owner, but tried on @sparacis C30. The P1 code was overcomplicated back then, the crack attempts failed, buy he got it cracked with P2 code path. It cracked even with the wrong pin bytes shuffle order

[RickHaleParker]

It cracked even with the wrong pin bytes shuffle order

That is interesting!
Makes me wonder if the byte order even matters on a P1. Could it be that a P1 will accept any of the 720 permutations ... ?

[vtl]

That is interesting!
Makes me wonder if the byte order even matters on a P1. Could it be that a P1 will accept any of the 720 permutations ... ?

Motorola in P1 is very slow. The cracking code essentially does permutations while it cycles through the value. For Motorola it's enough just to step on a right pin subsequence to raise the latency significantly enough for cracker sw to notice it.

But with the correct pin order the process is more reliable.

[RickHaleParker]

The cracking code essentially does permutations while it cycles through the value.

Correct me if I am wrong, for the three unknown bytes not all six bytes.

For Motorola it's enough just to step on a right pin subsequence to raise the latency significantly enough for cracker sw to notice it.

Would only need to measure 100 latencies to step on all six. If it works for a sub-sequence of one.

At least in theory, the top six candidates could be the correct six bytes. Knowing the six correct values, narrows it down to 720 possible pins numbers. Would fail if two or more bytes are the same value. I do not see any way to detect that two or more are the same.

But with the correct pin order the process is more reliable.

Recall somebody saying their cracker would not crack a known Pin but the correct byte values where coming up the the top five candidates. I keep that in the back of my head because that could exploitable if it is reliable. Possibly, could be used to factor out anomalies that strew the latency measurements.