Vida CEM swapping

[vtl]

I did verify my Teensy HW HS CAN, sending and receiving is working even connected to CEM.
My CEM remains silent. There is no activity on CEM, except some clicky noise. When I try to power on the CEM separately I don't see any voltage levels changes on CAN lines (using multi-meter voltage measurement, I don't have an oscilloscope).

Is it so that it should not need any other messages or voltage signals to wake up the CEM?

Another thing is that P3 branch does have k-line serial3 codes used, is it the merge issues or should there be some HW connections from serial3 to CEM?

You need to start Teensy, wait a second while it says to power up CEM, then power the CEM up. Maybe there's a hw nuance that I'm not aware of, I tried it only with one P3 CEM from 2012 S60. I'm not a Volvo repair man, can't run dozens of CEMs.

K-line code if a leftover artifact for early P2 CEM, ignore it.

[RickHaleParker]

(using multi-meter voltage measurement, I don't have an oscilloscope).

Get you one of them $10.00 USB Logic Analyzers.

The P3 code is Alpha software. It is just in the beginning stage.


Parking lot note: Perhaps a clean up to get rid of the unneeded code and a loop that will cycle until communication with the CEM is established. That way one could just power up the CEM when ready. Might be a good idea on the P1 & P2 code also.

[eltoro]

(using multi-meter voltage measurement, I don't have an oscilloscope).

Get you one of them $10.00 USB Logic Analyzers.

The P3 code is Alpha software. It is just in the beginning stage.

I need to order something like that for sure.

No worries about the Alpha state I am will contribute. I do have experience from the embedded world, not exactly from the car industry, but everything is pretty similar after all.

[RickHaleParker]

No worries about the Alpha state I am will contribute. I do have experience from the embedded world, not exactly from the car industry, but everything is pretty similar after all.

Good! VTL is swamped and does not have much time to work on the code. We need another coder to chip in and work on the code.

The only formal education I have in coding is Fortran 77 and I never did anything with it after collage. I can and have contributed to the software design but my ability to contribute to the C code is rather limited.

I did dabble with Basic, Arexx and some 6510 assemblers code but that was like a lifetime ago.

[Sh4rp]

Yesterday I was sitting in my car for three hours watching some numbers running over a screen...
It seemed that your suggested modifications had an impact, the values are closer to each other and don't seem so random anymore.

I got the most consistent results with Key in Pos 1, getting "28 79 30" as my candidates twice but bruteforce didn't work.
28 turns up all the time as first candidate and it was a bit frustrating yesterday to always recalculate the same value so I sat down and tried to activate my programming skills from 15 years ago.

I wrote a little routine that would ask the user in the beginning if he wants to enter some candidates when he's confident that they're right. It might save some people some time and can make the process all in all a bit faster.

I have no idea how to use GitHub and I also didn't want to mess around with your clean original code, so I made a standalone sketch that you can try out first. It doesn't work 100%, e.g. it doesn't matter what you type in when you should be typing in "y" or "n" but the main skeleton is there and can be easily adapted I guess?

Let me know what you think, I kinda wish that I had this feature yesterday


//EDIT: I updated the code a bit. Wrong user input should be rejected now. However when you enter a char instead of an int, it just gets converted to 0. Not a big deal since you can re-enter the candidate.

Code: Select all

void setup() {


  uint8_t  pin[6];

  String input;
  int candidate;
  int i = 1;

  bool validate = true;

  memset (pin, 0x00, sizeof(pin));

  /*******************************************************************************

     candidate input dialogue

  */
  
  /* ask user if candidates should be added */
  while (validate == true ) {

    Serial.printf ("Enter candidates? (y/n)\n");
    while (Serial.available() == 0) { } //Wait for Input
    input = Serial.readString(); //Read User Input

    if (input == "y" || input == "n") {
      validate = false;
    }

    else {
      Serial.printf("Invalid input.\n\n");
    }

  }

  if (input == "n") {
    /* when no input is chosen, normal cracking process starts with first byte */
    Serial.printf ("No candidates chosen. Begin cracking process.\n\n");
    return;

  }
  else if (input == "y") {

    /* when input is chosen, user can define up to 3 bytes */
    while (i <= 3) {

      Serial.printf("Enter Candidate #");
      Serial.print(i);
      Serial.printf(": ");

      while (Serial.available() == 0) { } //Wait for Input
      candidate = Serial.parseInt(); //Read User Input


      if (candidate >= 0 && candidate < 100) {
        pin[i - 1] = binToBcd(candidate);
        Serial.print(candidate);
        Serial.printf ("\n\n");
      }

      i++;

      if (i <= 3) {
        Serial.printf("Enter next candidate? (y/n)\n");
        while (Serial.available() == 0) { } //Wait for Input
        input = Serial.readString(); //Read User Input

        if (input == "n") {
          Serial.printf ("\n");
          break;
        }

        else if (input == "y") {
          continue;
        }
        else {
          Serial.printf ("Invalid input.\n\n");
          i--;
        }

      }
    }

    /* when user entered 3 candidates, program skips to bruteforce attack */
    if (i == 4) {
      Serial.printf ("Begin bruteforcing with chosen candidates.\n");
      for (i = 0; i < sizeof(pin); i++) {
        Serial.printf ("%02x ", pin[i]);
      }

      /*
         INSERT BRUTEFORCE ROUTINE
      */

    }

    /* when user entered less than 3 candidates, remaining bytes are being cracked */
    else if (i < 4) {
      Serial.printf ("Continue cracking with ");
      Serial.print(i - 1);
      Serial.printf (" candidate/s.\n");

      for (i = 0; i < sizeof(pin); i++) {
        Serial.printf ("%02x ", pin[i]);
      }

      /*
         INSERT CRACKING ROUTINE WITH X CANDIDATES
      */

    }
  }
  else {
    Serial.print("Invalid input!\n\n");
    return;
  }

  Serial.printf ("\n\n");
  Serial.printf ("DONE");

}



uint8_t bcdToBin (uint8_t value)
{
  return ((value >> 4) * 10) + (value & 0xf);
}

uint8_t binToBcd (uint8_t value)
{
  return ((value / 10) << 4) | (value % 10);
}

void loop() {

}

[RickHaleParker]

Let me know what you think, I kinda wish that I had this feature yesterday

That is the grist of the idea I suggested for a function that runs only when the CEM fails to crack. A user query to gain permission to run is a good idea.

I suggest you collect a set of top candidates order in terms of probability for each of the first three bytes, B0, B1 B2. Sometime like the Range 3, candidates short lists from the main code.

Then use a Permutation Algorithm to shuffle through the permutations. Brute forcing each permutation . Because B2 is the least reliable, you cycle through the permutation the same way you count, Right to Left / B2 to B0.

Example

Data
B0 B1 B2 / Byte position.
01 04 07 / candidates 1
02 05 08 / candidates 2
03 06 09 / candidates 3

Permutation sequence.
01 04 07
01 04 08
01 04 09
01 05 07
01 05 08
01 05 09
01 06 07
.
.
.
03 06 09

By this time the first one has already been tried. Initialize the sequence with the second B2 candidate.

[Sh4rp]

Well, this is already a level too high for me. I would just like to enter the candidates that seem like the right ones to continue the cracking process from there. I don`t understand what permutations are. Do you mean you just create a set of values that popped up often?

[RickHaleParker]

Well, this is already a level too high for me. I would just like to enter the candidates that seem like the right ones to continue the cracking process from there. I don`t understand what permutations are. Do you mean you just create a set of values that popped up often?

VTL could probably do it in 5 minutes but we need to others to chip in.

I been try to learn Arduino C so I could do a little more. Been using the VTL:Master as an example. I could not make heads or tails out of a lot of it. Then yesterday I was looking at the code and it hit me ... where is setup () ? I found it way at the bottom of the sketch. The book I have been reading said there there are two parts of a Sketch. Setup () and Loop () does not say anything about the preprocessor section for the compiler.

Can anybody point me to "Arduino IDE preprocessor for dummies" ?

A little tip: If you want to learn GitHub forget about GitHub and learn Git first. It will save to a whole lot of confusion.

[Sh4rp]

Implementing it into the existing code is not too hard for me, I was already doing it but then thought, maybe I should try it out first before I pollute your work with my garbage and also wanted to hear what you think of it. I have a little experience with the Arduino IDE so I can help with a small text interface like above or organizing the code but not so much with the math involved in the cracking process.

[RickHaleParker]

Implementing it into the existing code is not too hard for me, I was already doing it but then thought, maybe I should try it out first before I pollute your work with my garbage and also wanted to hear what you think of it. I have a little experience with the Arduino IDE so I can help with a small text interface like above or organizing the code but not so much with the math involved in the cracking process.

When it comes to the code VTL is the master. Anything committed through Git has to meet his approval before it gets merged into the main code. Of course you want to make sure it works before submitting a pull request.

I think it is a fine idea. I am just suggesting a possible way to automate it. Can you figure out a way to store the top three candidates for each of the three bytes and call them as needed?

You want a small project. How about adding a abort command to cemCrackPin that when true will abort cemCrackPin and execute progModeOff (). That will let a user abort when they know it not working and avoid the need to disconnect the battery to get the CEM out of program mode. You could look for the string "abort" from the terminal, if true then end cemCrackPin and allow progModeOff () to run which is the next line in loop ().