Hacking Honda Odyssey 2007 RES DVD-player: part 1

Part 1: Overview (this part)
Part 2: Hardware

Infotainment/NAVI system in Honda Odyssey 2007 is a huge monster – it has a luxury audio unit with 6 CD changer, a DVD-player, large NAVI screen in the dashboard, dashboard and steering wheel controls, rear screen with controls, IR remote and IR headphones. Awesome, isn't it?

Well, the problem is that we live in 2016 and it really does suck when you are stuck with the only choice between CDs and DVDs. If you want MP3, computer video, USB input, Bluetooth or anything else – your only option is the AUX input (composite video + stereo audio). It's definitely something, but if you are a maker, you can't be really satisfied with it, can you?

So I thought – why don't I look into how the hell this DVD works and if it would be possible to replace it with something more interesting and flexible – think a Raspberry PI or alike.




I googled the car (Honda Odyssey 2007), the DVD-player etc, and found a video on how to remove the DVD from the car:

And so I did; I learned that I have model 3911A-SHJ-A800, capable of playing CDs and DVDs and priced on eBay anywhere from $300 to $700. Nice. How do you feel now about accidentally braking it?

Pretty fast I found a few diagrams of the audio/NAVI system wiring, it seems to be really the same for Honda Pilot 2005-2010, too.

DVD-drive 22 pin connector pinout

Interesting, so DVD actually seems to be spitting out composite video and stereo. This will definitely work with a Raspberry PI, that's what I thought. Too easy.

That's unless the audio head knows that somebody is messing with the DVD-drive. Try unplugging the drive, and it will not even be possible to switch to DVD source. Bummer. So, OK, not a big deal – on the pin out diagram there are two COMM wires, let's tap in there and see what's going on there.

At this stage I deviated from the right path because I found a seemingly very similar TOYOTA Corolla MP3 Player Project, and convinced myself too easily that it is gonna be the same communication protocol. I built hardware and spent some time troubleshooting it because it was not doing the job. Finally I decided to see what's actually going on on the buss, hooked up my scope to see… this:

Well, this looks nothing close to a differential master-slave communication line, it looks more like the two devices are talking to each other in an UART-like language using unidirectional lines. I spent a few days trying to find details on this protocol online and nobody seemed to know what it was. Here's a closeup of what seemed to be a single frame:

I'll not go into a lot of details on how I was actually able to figure that this was an inverted UART 9600b/s with 8e1 (that is 1 start, 8 data, 1 even parity and 1 stop bits) protocol, although that is somewhat entertaining: involves luck and interesting effect of moire when printing the waveform chart from LibreOffice, that produced specific pattern so I was kinda able to see unique bits in that communication with a naked eye - ikr).

Once I figured that out, things became a little easier. I built an adapter so I was able to connect the DVD drive back to the car and tap on their conversation (WARNING! There's ALWAYS +12V present on this connector, even when ignition is off!):

I used RealTerm to monitor the bus and here's what I was able to see:

863C0F000051863D0F000052863E0F000053863F0F00005486400F00005586410F00005686420F00005786430F00005886440F00005986450F00005A86460F00005B86470F00005C86480F00005D86490F00005E864A0F00005F864B0F000060864C0F000061864D0F000062864E0F000063864F0F00006486500F00006586510F00006686520F00006786530F00006886540F00006986550F00006A86560F00006B86570F00006C86580F00006D86590F00006E865A0F00006F865B0F000070865C0F000071865D0F000072865E0F000073865F0F00007486600F00007586610F00007686620F00007786630F00007886640F00007986650F00007A86660F00007B86670F00007C86680F00007D86690F00007E866A0F00007F866B0F000000866C0F000001866D0F000002866E0F000003866F0F000004

You will have to use some dirty CIA techniques or black magic to make me remember how I figured that 0x86 in this is actually the byte, signaling the start of a frame. Knowing this, we can parse it to make more human readable:

86 3C 0F 00 00 51
86 3D 0F 00 00 52
86 3E 0F 00 00 53
86 3F 0F 00 00 54

Just so you understand, by now I was listening to a single line, i.e. this is not both devices talking to each other, but rather what one says. After playing a little with the data I had, I was able to figure the frame format:

Byte 1	Frame start	0x80
	Length of frame	0x06
Byte 2	Frame ID
Byte 3	data
...	data
Byte 5 (n-1)	data
Byte 6 (n)	checksum

Checksum here is 7 LSB bits of sum of all bytes of the frame.

Then it was time to put this knowledge into perspective. I built a device that would listen to both lines simultaneously and send this information to me to process. I built a sniffer out of STM32VL-Discovery (it has three UARTs – just what I needed: one for the Audio head, one for DVD drive, and one to send info to computer).

STM32VL-Discovery sniffer

Some time to adjust the parser, and we now can see data in a few different formats, that help analyzing the exchange:

hea: 8516040120
DVD: A1160103220003490F01000101121211121F0F12002100207C007F7F0200000D0C
hea: 8517040121
DVD: A1170103220003490F01000101121211121F0F12002100207C007F7F0200000D0D
DVD: 86170F01002D
hea: 8518040122
DVD: A1180103220003500F01000101121211121F0F12002100207C007F7F0200000D15
DVD: 86180F01002E
hea: 8519040123
DVD: A1190103220003510F01000101121211121F0F12002100207C007F7F0200000D17

Or

1F (H) 04 01 (d) 01 03 22 00 03 55 0F 01 00 02 01 12 12 11 12 1F 0F 12 00 21 00 20 7C 00 7F 7F 02 00 00 0D (d) 0F 01 00

20 (H) 04 01 (d) 01 03 22 00 03 56 0F 01 00 02 01 12 12 11 12 1F 0F 12 00 21 00 20 7C 00 7F 7F 02 00 00 0D (d) 0F 01 00

21 (H) 04 01 (d) 01 03 22 00 03 57 0F 01 00 02 01 12 12 11 12 1F 0F 12 00 21 00 20 7C 00 7F 7F 02 00 00 0D

22 (H) 04 0F (d) 0F 00 00 (d) 0F 01 00

23 (H) 04 01 (d) 01 03 22 00 03 58 0F 01 00 02 01 12 12 11 12 1F 0F 12 00 21 00 20 7C 00 7F 7F 02 00 00 0D (d) 0F 01 00

24 (H) 04 01 (d) 01 03 22 00 03 59 0F 01 00 02 01 12 12 11 12 1F 0F 12 00 21 00 20 7C 00 7F 7F 02 00 00 0D (d) 0F 01 00

25 (H) 04 01 (d) 01 03 22 00 04 00 0F 01 00 02 01 12 12 11 12 1F 0F 12 00 21 00 20 7C 00 7F 7F 02 00 00 0D (d) 0F 01 00

26 (H) 04 01 (d) 01 03 22 00 04 01 0F 01 00 02 01 12 12 11 12 1F 0F 12 00 21 00 20 7C 00 7F 7F 02 00 00 0D 

27 (H) 04 0F (d) 0F 00 00 (d) 0F 01 00

And unique commands:

040F
0403
0402
0401
020F
0201
04390000
04280000
0418
042A2000
0420
0400
0421
000F
0001

These are different slices of (different) parts of exchange, but they also allow (after a few hours of staring at this) to guess all we need to make things work:

1. The head pings the DVD every second or so with frame:
   
   
   

   Example	85 1C 04 01 26
   Byte 1	Frame start	0x80
   	Length of frame	0x05	5 bytes
   Byte 2	Frame ID	0x1C
   Byte 3	Status	0x04	0x02 – idle 0x04 – active (when DVD source is selected)
   Byte 4	Command	0x01	0x0F – keep alive 0x01 – media status 0x02 and 0x03 – some extended status commands (e.g. current action, type of media etc)
   Byte 5	checksum	0x26

   
   
2. DVD may respond with “all OK, no changes”
   

   Example	86 26 0F 00 00 3B
   Byte 1	Frame start	0x80
   	Length of frame	0x06	5 bytes
   Byte 2	Frame ID	0x26
   Byte 3	Command	0x0F	Always repeats command in request (see Byte 4 of the request)
   Byte 4	Response byte #1	0x00
   Byte 5	Response byte #2	0x00
   Byte 6	checksum	0x26

3. But it may also tell the head it wants to make an update. In this case it would respond with the type of update it has:
   
   
   

   Byte 4	Response byte #1	0x03	0x03 – changes in media, e.g. disk is inserted, disk is being identified, DVD or CD media has been identified, the media is being read etc.
   Byte 5	Response byte #2	0x00

   
   
    
4. To which the head sends a different request (note 04 01 !!):

   85 20 04 01 2A

    
5. And then the DVD would respond with lots of data:
   

   A11F0103320000400F7F0F017F7F7F7F301F0F7F0F14002030007F7F403C040C2A

I'll not go into details on how this frame is composed ( I was able to figure out only about 30% of it anyways), but there's media type information, time stamps, number of current and total tracks for CD, number of titles and chapters for DVD and I also bet there's information about audio tracks as well.

I built a PIC16F1827-based circuitry to emulate DVD and verified that with just a few commands it is able to enable video pass-through to the rear screen.

DVD-drive emulator

In the next part I'll describe the hardware setup that was used for the hack and can be useful to connect your own media source to the vehicle RES (Rear Entertainment System).

Cheers!

P.S. It was risky and I had a few solid chances to fry some/all electronics in the car. There's always +12V present on the connector. Please please please think twice before doing something, especially doing something stupid. It's always better when you know what you are doing, or have what seems to be unlimited amount of luck (such as in my case).

P.S.S. Please support this blog by clicking some ads or using Donate button.

P.S.S.S. Meanwhile if your hands itch, check out this hack that allows to mirror RES screen to NAVI screen. Nothing is worse when your kids needing help starting video and you having to get out of the car, walk to the other side, jump in the back, wait till all the ads and warnings play through, click through long animated menus and all of this sitting on the laps of your kids feeling like sardines in a can.