[Discussion] Further protocol reversing

[zivillian]

I started to look into the protocol and stumbled upon the undetermined XOR algorithm - so I decided to dig deeper. Instead of looking at PCAPs or the responses from the car I started implementing a car simulator and connected the official app to it. As of now it looks promising, since I already found that the XOR value is only dependent on the Init connection packet (not the IP, or MAC or anything else I can think of). By modifying the Init connection packet content, I can reproducably change the XOR used by the app.

As of now, it looks like the app uses the data of the Init connection packet AND 0x00080808080808080800 while the first byte has to be 0x01 and the last byte is discarded. So we get 8 relevant bits, which is the byte used for determining the initial XOR value. All three of the following init packets result in the exact same XOR value (0x66) used by the app:

5e 0c 00 01507a37cfe11583d801 8d
5E 0C 00 01000800080000000800 83
5E 0C 00 01F7FFF7FFF7F7F7FFF7 32

After looking at the app (using my scissor ;-) I found three constants to enable debug logging in the app. The modified app can be found here.

By looking at the log output I can tell that the one byte from the init connection packet is logged directly as security_key and used further to create the XOR value by some kind of KEY_MAP lookup:

iMobile2: send sync time-------------------------------
iMobile2: -------security_key------ 138
iMobile2: send: E5 04 01 01 00 EB
iMobile2: -------KEY_MAP[0]------ 102
iMobile2: recv: 5E 0C 00 01 50 7A 37 CF E1 15 83 D8 01 8D

iMobile2: -------security_key------ 128
iMobile2: send: E5 04 01 01 00 EB
iMobile2: -------KEY_MAP[0]------ 128
iMobile2: recv: 5E 0C 00 01 00 00 00 00 00 00 00 08 00 73

iMobile2: send sync time-------------------------------
iMobile2: -------security_key------ 0
iMobile2: send: E5 04 01 01 00 EB
iMobile2: -------KEY_MAP[0]------ 0
iMobile2: recv: 5E 0C 00 01 00 00 00 00 00 00 00 00 00 6B

iMobile2: send Mac Addr
iMobile2: -------security_key------ 192
iMobile2: send: E5 04 01 01 00 EB
iMobile2: -------KEY_MAP[0]------ 115
iMobile2: recv: 5E 0C 00 01 00 00 00 00 00 00 08 08 00 7B

So the bits are interpreted with the LSB first:

0x0008000800000008 -> 0b_1000_1010 -> 138
0x0000000000000008 -> 0b_1000_0000 -> 128
0x0000000000000000 -> 0b_0000_0000 -> 0
0x0000000000000808 -> 0b_1100_0000 -> 192

My biggest obstacle right now is that I have only remote access to a car, so it would be great if someone could trace the registration process (so I can at least add a static example to my vehicle emulator). The log output of a registered app would be helpful as well.

To create the log file, you would need to install the modified app (which may remove the registration and all the data associated with the app - at least it did for me) and enable USB debugging. The log can then be extracted with adb logcat -s iMobile2.

If you don't trust my binary, you can also create your own, by using the commands and changes documented in the history of the app repo.