can someone explain to me what the Snoopy and Taco binaries are for or do!? It's been driving me crazy but I see them all over the CIC system and have no idea what they are.
QNX Development for CIC
- Thread starter dolphin78
- Start date
Hi Deadknight,
iDrive controller input can be retrieved from this channel: /dev/ipc/ioc/ch4.
Here's how I'm getting it
Code:
void handle_cic_input(cic_input_data_t *data) {
switch(data->code) {
case CIC_ROTATE :
//position is from 0 to 255
unsigned rot_position = data->value;
...
break;
case CIC_CLICK :
//check if button was pressed or released
unsigned status = data->value;
...
break;
case CIC_...
}
}
...
//register CIC controller handler
init_cic_input(handle_cic_input);
...After looking at @dolphin78's code i found out a pattern on input binaries.
I'm uploading the files,
they are from /dev/ipc/ioc/ch4 and /dev/ioc/ipc/ch5
/fs/usb0 is glovebox usb path
For example ch4_1 means while i'm doing "cat /dev/ioc/ipc/ch4 > /fs/usb0/ch4_1.txt" on telnet i tapped "1" button on radio controller "10" times.
After opening files with hex editor (in little endian mode), i found out there is a pattern.
Start of ch4_1 looks like this:
1d 01 16 01 01 e0 00 05 15 0c 00 0b 06 00 00 00 05 13 19 13 1d 0f 08 07 e1 fa de 1e 01 0d 01 02 05 00 06 21 0c 00 02 06 00 00 00 fa de 1f 01 0d 01 02 05 00 02 21 0c 00 02 06 00 00 00 fa de 00 01 13 00 00 d6 01 02 00 0c 00 08 00 ff 00 00 01 01 00 00 00 00 fa de 21 01 13 01
There are a two bytes that recurs
1d 01 16 01 01 e0 00 05 15 0c 00 0b 06 00 00 00 05 13 19 13 1d 0f 08 07 e1 fa de 1e 01 0d 01 02 05 00 06 21 0c 00 02 06 00 00 00 fa de 1f 01 0d 01 02 05 00 02 21 0c 00 02 06 00 00 00 fa de 20 01 13 00 00 d6 01 02 00 0c 00 08 00 ff 00 00 01 01 00 00 00 00 fa de 21 01 13 01
I believe these two bytes may dictate two things.
a) Ending of that stream
b) Starting of stream
For us it doesn't matter if its ending or beginning, we can split data from these bytes.
The byte after fa de looks like some kind of counter.
1d 01 16 01 01 e0 00 05 15 0c 00 0b 06 00 00 00 05 13 19 13 1d 0f 08 07 e1 fa de 1e 01 0d 01 02 05 00 06 21 0c 00 02 06 00 00 00 fa de 1f 01 0d 01 02 05 00 02 21 0c 00 02 06 00 00 00 fa de 20 01 13 00 00 d6 01 02 00 0c 00 08 00 ff 00 00 01 01 00 00 00 00 fa de 21 01 13 01
After counter byte there are three bytes that indicates the what is data.(i believe)
1d 01 16 01 01 e0 00 05 15 0c 00 0b 06 00 00 00 05 13 19 13 1d 0f 08 07 e1 fa de 1e 01 0d 01 02 05 00 06 21 0c 00 02 06 00 00 00 fa de 1f 01 0d 01 02 05 00 02 21 0c 00 02 06 00 00 00 fa de 20 01 13 00 00 d6 01 02 00 0c 00 08 00 ff 00 00 01 01 00 00 00 00 fa de 21 01 13 01
From @dolphin78's code we know that idrive controller uses 01 12 01(or 00)
First byte is mostly 01
Second byte is some kind of identifier that changes (12,13,14,19), i'm calling this opcode
Third one is either 01 or 00 (maybe pressed state?)
These are my findings till now.
On all tests i clicked buttons ten times, but i could not find an opcode which was exactly written ten times. (It is possible that it cant register 10 clicks). After parsing data i found out there are two candidates for input from radio again. Opcode 12 or 13 (i might be wrong).
I havent looked ch5 data for now. If you are good at tracing data you can look too.
The purpose of this research is, it may be good to double tap radio buttons (mode button for example) to run our custom application, which may wait on idle state in usb drive.
Thanks to @dolphin78 for his initial research
I'm uploading the files,
they are from /dev/ipc/ioc/ch4 and /dev/ioc/ipc/ch5
/fs/usb0 is glovebox usb path
For example ch4_1 means while i'm doing "cat /dev/ioc/ipc/ch4 > /fs/usb0/ch4_1.txt" on telnet i tapped "1" button on radio controller "10" times.
After opening files with hex editor (in little endian mode), i found out there is a pattern.
Start of ch4_1 looks like this:
1d 01 16 01 01 e0 00 05 15 0c 00 0b 06 00 00 00 05 13 19 13 1d 0f 08 07 e1 fa de 1e 01 0d 01 02 05 00 06 21 0c 00 02 06 00 00 00 fa de 1f 01 0d 01 02 05 00 02 21 0c 00 02 06 00 00 00 fa de 00 01 13 00 00 d6 01 02 00 0c 00 08 00 ff 00 00 01 01 00 00 00 00 fa de 21 01 13 01
There are a two bytes that recurs
1d 01 16 01 01 e0 00 05 15 0c 00 0b 06 00 00 00 05 13 19 13 1d 0f 08 07 e1 fa de 1e 01 0d 01 02 05 00 06 21 0c 00 02 06 00 00 00 fa de 1f 01 0d 01 02 05 00 02 21 0c 00 02 06 00 00 00 fa de 20 01 13 00 00 d6 01 02 00 0c 00 08 00 ff 00 00 01 01 00 00 00 00 fa de 21 01 13 01
I believe these two bytes may dictate two things.
a) Ending of that stream
b) Starting of stream
For us it doesn't matter if its ending or beginning, we can split data from these bytes.
The byte after fa de looks like some kind of counter.
1d 01 16 01 01 e0 00 05 15 0c 00 0b 06 00 00 00 05 13 19 13 1d 0f 08 07 e1 fa de 1e 01 0d 01 02 05 00 06 21 0c 00 02 06 00 00 00 fa de 1f 01 0d 01 02 05 00 02 21 0c 00 02 06 00 00 00 fa de 20 01 13 00 00 d6 01 02 00 0c 00 08 00 ff 00 00 01 01 00 00 00 00 fa de 21 01 13 01
After counter byte there are three bytes that indicates the what is data.(i believe)
1d 01 16 01 01 e0 00 05 15 0c 00 0b 06 00 00 00 05 13 19 13 1d 0f 08 07 e1 fa de 1e 01 0d 01 02 05 00 06 21 0c 00 02 06 00 00 00 fa de 1f 01 0d 01 02 05 00 02 21 0c 00 02 06 00 00 00 fa de 20 01 13 00 00 d6 01 02 00 0c 00 08 00 ff 00 00 01 01 00 00 00 00 fa de 21 01 13 01
From @dolphin78's code we know that idrive controller uses 01 12 01(or 00)
First byte is mostly 01
Second byte is some kind of identifier that changes (12,13,14,19), i'm calling this opcode
Third one is either 01 or 00 (maybe pressed state?)
These are my findings till now.
On all tests i clicked buttons ten times, but i could not find an opcode which was exactly written ten times. (It is possible that it cant register 10 clicks). After parsing data i found out there are two candidates for input from radio again. Opcode 12 or 13 (i might be wrong).
I havent looked ch5 data for now. If you are good at tracing data you can look too.
The purpose of this research is, it may be good to double tap radio buttons (mode button for example) to run our custom application, which may wait on idle state in usb drive.
Thanks to @dolphin78 for his initial research
Last edited:
message format for buttons "1" through "8" is following:
Code:
16 01 13 00 00 15 0C 0C 02 0C 00 08 00 FF 00 00 00 00 00 00 00 00 FA DE
^ ^ ^
| |-- buttons 1..8-----|
message_id- first byte is message sequence number, incremental, 00->FF
- 01 13 00 00 15 0C 0C 02 0C 00 08 00 FF is the pattern you should be looking for for 1..8 buttons
- 8 bytes after FF are button statuses where each button is represented as separate byte:
- 00 - button released
- 01 - button touch sensor active (touching but not pressing)
- 02 - button pressed
- FA DA is end of message signature
btw, there is a tool called ipc-test which I found useful for reading and analyzing messages.
Put the attached script in CIC and run the following command there:
This is pretty much what I used to find all the iDrive controller messages and 1..8 buttons I posted above.
Modify the script if you need to read from another channel. It also can read data from files.
I think media button presses from steering wheel are also available (volume, mode, etc) but I don't need them as of now so I didn't bother to find the patterns. Cruise Control buttons are not available I think.
Sample output:
Put the attached script in CIC and run the following command there:
Code:
ipc-test read4.ipcModify the script if you need to read from another channel. It also can read data from files.
I think media button presses from steering wheel are also available (volume, mode, etc) but I don't need them as of now so I didn't bother to find the patterns. Cruise Control buttons are not available I think.
Sample output:
Code:
target:/fs/usb0> ipc-test read4.ipc
Verbose ON
Open channel ('/dev/ipc/ioc/ch4', 2)
Read from '/dev/ipc/ioc/ch4'
Timeout: 0
Count : 4294967295
00000192: 20 bytes received
CE 01 0F 00 00 15 02 04 01 0C 00 04 00 FF 00 00
00 01 FA DE
00000297: 24 bytes received
CF 01 13 00 00 05 00 02 20 0C 00 08 00 FF 00 00
01 01 00 00 00 00 FA DE
00000497: 17 bytes received
D0 01 0C 00 00 C0 03 0C 27 0C 00 01 00 FF 20 FA
DE
00000805: 41 bytes received
D1 02 0E 00 00 05 00 02 1F 0C 00 03 00 FF 0A 05
0D FA DE 13 00 00 05 00 02 20 0C 00 08 00 FF 00
00 01 01 00 00 00 00 FA DE
00000813: 18 bytes received
D2 01 0D 00 00 05 00 02 21 0C 00 02 00 FF 00 00
FA DE
00000814: 18 bytes received
D3 01 0D 00 00 05 00 06 21 0C 00 02 00 FF 00 00
FA DE
Last edited:
Does anybody want to try Doom?
To run it unzip the package to a flash drive and insert it in glove box.
The script/game does not modify anything in CIC except creating /HBpersistence/NO_HMI_WATCHDOG file in the hard drive to disable CIC watchdog as otherwise CIC reboots in about 30 sec after the script suspends HmiMain (slay -h HmiMain)
Use iDrive controller to play. Do not distribute the package as is as it has doom2.wad file inside (game resources) which is copyrighted by idSoftware.
This build was tested only in F30 with 1280x480 screen, can't guarantee it'll work on others.
Controls:
Menu - menu
Controller Up/Down - go forward/back
Controller Left/Right - strafe left/right
Controller Rotate - turn
Controller Press - shoot
Back - action
Radio - run (same as Shift)
Media/Tel - change weapons
Nav - map
There are 3 cheat codes available, good luck finding them
To run it unzip the package to a flash drive and insert it in glove box.
The script/game does not modify anything in CIC except creating /HBpersistence/NO_HMI_WATCHDOG file in the hard drive to disable CIC watchdog as otherwise CIC reboots in about 30 sec after the script suspends HmiMain (slay -h HmiMain)
Use iDrive controller to play. Do not distribute the package as is as it has doom2.wad file inside (game resources) which is copyrighted by idSoftware.
This build was tested only in F30 with 1280x480 screen, can't guarantee it'll work on others.
Controls:
Menu - menu
Controller Up/Down - go forward/back
Controller Left/Right - strafe left/right
Controller Rotate - turn
Controller Press - shoot
Back - action
Radio - run (same as Shift)
Media/Tel - change weapons
Nav - map
There are 3 cheat codes available, good luck finding them
Last edited:
That is sweet! I wonder if the heated steering wheel button can be identified using that script above.
I doubt it's available from ch4. My understanding is ch4 is a gate to MOST bus while heated wheel button is not connected there.
There's a lot of data coming from ch5 but I don't know what that is. Could be CAN bus but I'm not familiar with the message format
I'm aware of this approach. It's dangerous because it requires changes in flash memory. This is exactly why I was asking if anybody knows how to do it with no flash memory changes
Okay, this has evolved quite far from the original connected drive starting point. Would anyone more versed than myself be interested in making a simple thread summing some of the more public facing content of this CIC development? Should help drive some more contributors here to the private area.
Nobody's interested?Does anybody want to try Doom?
To run it unzip the package to a flash drive and insert it in glove box.
The script/game does not modify anything in CIC except creating /HBpersistence/NO_HMI_WATCHDOG file in the hard drive to disable CIC watchdog as otherwise CIC reboots in about 30 sec after the script suspends HmiMain (slay -h HmiMain)
Use iDrive controller to play. Do not distribute the package as is as it has doom2.wad file inside (game resources) which is copyrighted by idSoftware.
This build was tested only in F30 with 1280x480 screen, can't guarantee it'll work on others.
Controls:
Menu - menu
Controller Up/Down - go forward/back
Controller Left/Right - strafe left/right
Controller Rotate - turn
Controller Press - shoot
Back - action
Radio - run (same as Shift)
Media/Tel - change weapons
Nav - map
There are 3 cheat codes available, good luck finding them
I posted the default boot order in the info dump thread IIRC - I'm confident we can 'autorun' via optical or flash media with little effort.
...and you bet your ass i'll try doom
IDKFA/IDNOCLIP/IDKFAAlso, I love that every time I check this thread there's more and more fantastic progress in reverse engineering. This kind of stuff gives me such a nerd boner.
I'm just a *nix admin that loves attempting to reverse engineer things in his spare time - but some of you guys are little more, uh, leet
I'm just a *nix admin that loves attempting to reverse engineer things in his spare time - but some of you guys are little more, uh, leet
I'll try it once I get my combox retrofitted, until then I'm not messing with anything.
Hi
So i've installed my DEV environment for QNX and compiled the script below as "enc" and ran it in QNX X86 test vm
I created one file with simple command : "cd /tmp ; ls" and saved it as "Test"
then i ran command: enc < test > test.sh
When i run test.sh i get something weird and not the contents of encrypted commands.
I studied the code and it seems that it gets the char as input, encodes it and returns it back encoded, so that's why i used the above command to input a file.
Any help would be appreciated.
PS: what is the encrypt/decrypt seed, parameter 'seed = 0x...' ?
So i've installed my DEV environment for QNX and compiled the script below as "enc" and ran it in QNX X86 test vm
I created one file with simple command : "cd /tmp ; ls" and saved it as "Test"
then i ran command: enc < test > test.sh
When i run test.sh i get something weird and not the contents of encrypted commands.
I studied the code and it seems that it gets the char as input, encodes it and returns it back encoded, so that's why i used the above command to input a file.
Any help would be appreciated.
PS: what is the encrypt/decrypt seed, parameter 'seed = 0x...' ?
Code:
#include <stdio.h>
unsigned int seed = 0x001be3ac;
unsigned int prng_rand() {
unsigned int r1, r3, r0;
r0 = seed;
r1 = (seed >> 1) | (seed << 31);
r3 = ((r1 >> 16) & 0xFF) + r1;
r1 = ((r3 >> 8) & 0xFF) << 16;
r3 -= r1;
seed = r3;
return r0;
}
int main(int argc, char *argv[]) {
int c;
prng_rand();
c = getchar();
while (c != EOF) {
c ^= (prng_rand() & 0xFF);
putchar(c);
c = getchar();
}
}
Last edited:
- did you test your script in QNX before encoding it?
- CIC will not understand encoded files if you run them manually. Encoding is need only for autorun file (copie_scr.sh)
- you don't need QNX dev environment to encode/decode files. Any platform/OS/C compiler can be used
- seed is the encryption/decryption key used by CIC (same key is used by Audi MMI 3G). you must not change it if you want CIC to be able to decrypt and run your copie_scr.sh script.
- I attached a generic encoded copie_scr.sh script in this thread which runs run.sh from flash drive. you can put your code into run.sh instead of creating your custom copie_scr.sh. This way you don't have to deal with encoding, just put copie_scr.sh and run.sh in flash drive
Thanks for the answers and for the file, actually i ran the code via Target in QNX development workspace, and nothing happened (of course, because this code doesn't output anything), but running manually on QNX development doesn't work.
So from what i understand, the CIC shell interpreter "knows" that the file is encryped with the particular seed and runs the contents.
You guys are very knowledgeable, i would like to study about RTTI and how ConnectedDrive works, someone here started a thread on that, maybe we can build our own stuff. Didn't find many whitepapers about those technologies.
Similar threads
