Wednesday, November 7, 2012

Poking bits

Ok, today was the first time I tried to duplicate the messages I had previously analyzed. What is there more to science than proving your hypotheses right or wrong: scientific principle!

I was pretty confident I had managed to unravel the format in the messages SWM (steering wheel module) sends while pressing audio control buttons and playing with cruise control (ignition off, mind you).

Typical message is:

Header: 00 40 00 66 
Data:   c0 00 00 01 1f 40 40 7f

1st data byte: High nibble: Rolling counter (either 0/4/8/c). This changes every message.

   Low nibble: 0 always
2-3: 0x00
4: rolling counter (0-7), advances only when there's a change in the message content
5-6: cruise control button commands: 
   1f 40  (nothing pressed)
   1e 41 (cruise main button)
   0f 50 (0/zero)
   17 48  (reload/return to previously set speed)
   1d 42 (+ speed)
   1b 44 (- speed)

7: 0x40
8:  audio 
   7f=nothing pressed
  77 volume up
  7b volume down
  7d forward
  7e backward     

With this information, I was ready to construct my first message: Fast-forward to next song in audio-cd. And it worked! God damn that felt good after passive logging for so many days :) Then I tried other audio related commands with success. Only thing that needs to be taken care of is advancing those two counters. Second one is easier, since it changes only after each key press, but first counter advances every new message (dozens of times/sec). Thus sometimes the receiving end dismisses the message (thinking that it was old one, if current latest msg index is 'c' and we tried sending ours with index '4').

Now, I wasn't going to fiddle with cruise control while driving (after childhood one starts accumulating these boring self-preservative tendencies), but I couldn't resist forging remote fob central locking messages. And with a little bit anxiety, I sent the message. Cold chills went up my spine when I heard the central locking mechanism engage! Then tried the unlocking message, and off the locks went..  I'm not going to describe the messages in detail here (I'm little bit paranoid should they contain specific details of my car security), even if I know one must be physically connected to the CAN bus to send the aforementioned commands. Most likely they are just messages where CEM (central electronic module) is commanding doors to unlock (unencrypted messages) after the more secure encrypted wireless messaging between the remote fob and CEM.




1 comment:

  1. What did you send in each Canframe? Header, length, frametype, and data?
    Did you send it in Hex format?

    ReplyDelete