Thread: Renault "Tuner List" Head Unit/CD changer hacking - Controls

Originally Posted by Ale

I agree with "play" frame decoding and i suggest
2 : frame length, the length of following data byte before CRC

For ID3 tag perhaps there is a frame type to send some text data, becouse they say the vdo chm604 mp3 support ID3 tag...

According to some people on PlaneteRenault.com, although maybe the mp3 changer supports the ID3, the HeadUnit doesn't display them. E.g. Papoo says in this post (roughly translated) : "the mp3 songs are played one after the other. I mean, if you have 200 mp3's (in subdirectories or not), it displays TR1, TR2 .... TR200. It means the titles and directory names are not displayed, but I think it is due to the head unit..."

Originally Posted by Putput

It didn't find a way to attach a file to a PM so I used an email address that I found on your website.

Strange...
Well, the email works, but as sharing is the main goal, here's your software in rar format for everyone to see you're a very fast coder :-)

By the way, it works perfectly ! I tested it on the 96 first frames and it's perfect.

I guess we're all interested in the source code... Can you either attach it to a message or (if it's short) post it in the body, between <code></code> tags (replace <> by square brackets)

Thanks a lot :-)

I'll post the code tomorrow, have to go now. The FCS is very simple, take the first byte, XOR it with the second and XOR the result with the third byte and so on, thats it!

Originally Posted by Vicne

However, from frame 97 on, the alignment becomes corrupted, but it's most probably due to ACKs coming in the game when track changes are requested by the head unit, this has to be fixed manually in the dump...

It seems that the CDC replies with an acknowledgment (C5, I don't use ACK since it's ascii code 06) when it receives a command (disclaimer: I only looked at the first version of the dump without the reformatting, so I don't know if command/reply are synchronized).
Also note that 3D and 3F only differ in one bit (2), maybe the bit is used to signal something.
Can you try to capture the communication while powering up the HU and with the cd player not playing?

The party ended a little sooner then expected so here it is:

Code:

procedure TForm1.Button1Click(Sender: TObject);
var
   FCS  : integer;
   w_i  : integer;
   w_ii : integer;
   w_b  : byte;
begin
   // Line pointer in Listbox
   for w_i := 0 to ListBox1.Items.Count - 1 do
      // Check for correct string length
      if length(ListBox1.Items.Strings[w_i]) = 56 then
      begin
         FCS := 0;
         // Byte counter in frame
         for w_ii := 1 to 14 do
         begin
            // Move string hex byte into binairy byte
            HexToBin(StrLower(pchar(copy(ListBox1.Items.Strings[w_i], ((w_ii - 1) * 4) + 1, 2))), @w_b, 2);
            // XOR with previous Result
            FCS := FCS XOR w_b
         end;
         // Add FCS result to listbox
         ListBox1.Items.Strings[w_i] := ListBox1.Items.Strings[w_i] + ' FCS=' + IntToHex(FCS, 2)
      end;
end;

Its written in Delphi and its the procedure that runs when you push the Calculate button in the program.

Originally Posted by pippolippi

It seems that the CDC replies with an acknowledgment (C5, I don't use ACK since it's ascii code 06) when it receives a command (disclaimer: I only looked at the first version of the dump without the reformatting, so I don't know if command/reply are synchronized).

Yes, you're right, the acknowledgement byte (C5h) is not the ACK character. And indeed, it's send by the head unit as a reply after each frame coming from the CDC, but also by the CDC after each command coming from the head unit, so it's really an "OK" message.

Also note that 3D and 3F only differ in one bit (2), maybe the bit is used to signal something.

Yes, indeed.

Can you try to capture the communication while powering up the HU and with the cd player not playing?

I'll do my best to have a more complete capture, along with annotated operations, but I have to tweak the capture program first. I think I'll dump Rx and Tx into separate files, with each byte being timestamped and numbered, so that I can then mix them in Excel or something.
I'm thinking of the following operations :
start capture from scratch / head unit off / head unit on, with tuner as source / switch to CD changer / play / pause / next/previous tracks / change CD / fast forward/backward / random / switch back to tuner / head unit off

Originally Posted by Putput

The party ended a little sooner then expected so here it is:
...
Its written in Delphi and its the procedure that runs when you push the Calculate button in the program.

Excellent ! Thanks a lot. So it's really easy to implement. Cool.

We'll have to solve the mystery of the other frames now...

Originally Posted by Vicne

Status of the 15-byte frames decoding :
0 : ?? (3Dh or 3Fh)
1 : frame id ?
2 : frame length - 4 ? (0bh)

Yes, remaining length of the frame minus the checksum. The same seems to apply to commands from the HU, e.g. in the first dump (20060211_001701_SerialDump_cd_changes.log):

0: 3D
1: 14
2: 02 --> 2 "useful" bytes
3: 26 --> first useful byte
4: 01 --> second useful byte
5: 0C --> xor of bytes from 0 to 4

Originally Posted by Putput

When the frame starts with 3D it calculates the FCS perfectly, only when it starts with 3F it goes wrong. When I change the 3F to 3D the result is ok again, so maybe the 3F could be a glitch?

I have load the data in excel and with a small function in VBA i calculated the CRC, and can confirm that the frame that start with 3F results in wrong CRC, changing it with 3D it's OK.
the function accept a range of cell like =MyXor(B3:P3), if you include the crc in the range, when the result is zero the received data is correct (the last xor operation is between the calculated crc and the received one)
Here is the function:

Code:

Function MyXor(MyInput1 As Range)
crc = 0

For I = 1 To MyInput1.Cells.Count
    crc = Val("&h" & MyInput1.Cells(1, I)) Xor crc
Next I
MyXor = Hex$(crc)
End Function

So the byte in the frame:
0 : 3Dh, start frame
1 : nn a sequence number, cycling from 00h,01h...FFh,00h,01h

I have found error (3F) also in the sequence number and changing it with the next expect value, fix the CRC error.

I think that there is a software(buffer overrun) or hardware(threshold of the receiver) bug...