Vida CEM swapping

[aaivar]

EE.rar

(96 Bytes) Downloaded 155 times

[vtl]

P3 news: I've got the first hash collision in 1.8 hours, going at the rate of 860 hashes/s. The pin is unlikely a full match, but the CEM is unlocked till the next power cycle. It is time to upload SBL and pull the dump off the CEM, which I can't do.

So I wrote a program, which goes through all 100^5 pin combinations, computes hashes with the predefined seed and matches them against the known good hash. It takes about 15 minutes to find all those 600-700 matching pins. Down to under 2 minutes when you realize the hash does not need to be computed in full on every cycle. At 860 hashes/s CAN rate it would take approximately another minute to find the real pin in these 600-700.

Unfortunately, the 2 minutes hash time time is on a server-grade 3.0 GHz x86. Teensy goes at 50000 hashes/s at best, and it would take up to like 55 hours to compute all the hashes. Teensy is good for I/O-bound work, not for CPU-bound.

Now, all of this P3 work can be rewritten for the host CPU and, say, DiCE, however I don't write code for Windows and there's no such thing like DiCE protocol support available for not Windows. I'm thinking whether I need to write a host utility that will talk to Teensy and offload it from heavy computational work. Or, maybe, someone knows how to talk to DiCE without DiCE Windows driver?

[RickHaleParker]

EE.rar

It worked!

You can see the reduction cycle. Mathematically it follows the form of a Sawtooth waveform. Starts at 0x00 (00₁₀) climbing to 0xFF (255₁₀) then starting over at 0x00 (00₁₀).

Next step is to design a fake eeprom file that nullifies the reduction cycle in the Decrypt file. A series of fake flash files can be run against the nullify eeprom file to seek out the end of the key block. That way we will know if the key block is 49, 61, 256 or some other count. I think I will start with 49, 61 & 256. After I get the results from them, I will design the next set of flash test files.

I will upload the next set of test files and instructions when I get them done.

Still would like to know the name of the software you are using.

[RickHaleParker]

The results of the two test files I uploaded indicate that the first two files aaivar uploaded are not a matched set.

[RickHaleParker]

EE.rar

Here is the next test set.

1. Run EEPROM_Null.bin with Flash 49.bin , Name the Decrypt file D49.bin.
2. Run EEPROM_Null with Flash 61.bin , Name the Decrypt file D61.bin.
3. Run EEPROM_Null with Flash 256.bin , Name the Decrypt file D256.bin.
4. Upload files D49.bin, D61.bin and D256.bin .

[RickHaleParker]

Or, maybe, someone knows how to talk to DiCE without DiCE Windows driver?

As suggested back on page 120. Target a OBDII interface that has Linux drivers. You don't need a power house like DiCE just to talk.

Is there not some standard that lets you write applications on one operating system that will compile on another system .. Portable Operating System Interface (POSIX) ? Is POSIX a big headache you avoid like you do with Windows?

You could always leave the rest to somebody that does Windows and fruit baskets.

[vtl]

Or, maybe, someone knows how to talk to DiCE without DiCE Windows driver?

As suggested back on page 120. Target a OBDII interface that has Linux drivers. You don't need a power house like DiCE just to talk.

Is there not some standard that lets you write applications on one operating system that will compile on another system .. Portable Operating System Interface (POSIX) ? Is POSIX a big headache you avoid like you do with Windows?

You could always leave the rest to somebody that does Windows and fruit baskets.

ELM327 is not J2534-compatible (no passthrough).

I think I'll stay with Teensy and use Firmata to talk to host. Unfortunately, this still gets messier on host - I can't find find a good C library that is not a half-unfinished toy and is not a C++ NIH monster. But anyways.

Yeah, Linux implements most of POSIX. The code does not need anything besides the standard C language API and runtime, which Windows does implement, plus libusb to talk to Teensy, which supports Windows as well.

The bigger question is how to get the hash collision quicker. I was lucky with my PIN, but as is it can take up to like 36 hours for "bad" PIN. I have a couple of ideas, though...

[RickHaleParker]

Unfortunately, the 2 minutes hash time time is on a server-grade 3.0 GHz x86. Teensy goes at 50000 hashes/s at best, and it would take up to like 55 hours to compute all the hashes. Teensy is good for I/O-bound work, not for CPU-bound.

I see how you calculated the 55 hours on the Teensy but, if you apply the shortcut that got the hash time down from 15 minutes to 2 min on the server, would not the Teensy 55 hours drop to about 7.33 hours ? Eight hours is the average time Vdash takes, 24 hours max. Eight hours would put your Teensy code on par or better then Vdash.

[vtl]

I see how to calculate the 55 hours on the Teensy but if you apply the shortcut that got the hash time down from 15 minutes to 2 min on the server, would not the Teensy 55 hours drop to about 7.33 hours ? Eight hours is the average time Vdash takes, 24 hours max. Eight hours would put your Teensy code on par or better then Vdash.

55 hours is with optimized hash, straight dumb approach would take 310.

The hash computation can be made highly parallel. 32 cores (threads) AMD 7302 would fly over the whole pin space in under 4-5 seconds

Heck, why they don't make CAN controllers standard on x86? =)

[RickHaleParker]

I think I'll stay with Teensy and use Firmata to talk to host.

Do you need Firmata?
Can't you exchange information, instructions and data with the sketch over the serial with Serial.read() and Serial.print() ?