HDMI is implemented on just about every piece of sufficiently advanced consumer electronics. You can find it in low-end cellphones, and a single board Linux computer without HDMI is considered crippled. There’s some interesting stuff lurking around in the HDMI spec, and at DEF CON, [Joshua Smith] laid the Consumer Electronics Control (CEC) part of HDMI out on the line, and exposed a few vulnerabilities in this protocol that’s in everything with an HDMI port.

CEC is designed to control multiple devices over an HDMI connection; it allows your TV to be controlled from your set top box, your DVD player from your TV, and passing text from one device to another for an On Screen Display. It’s a 1-wire bidirectional bus with 500bits/second of bandwidth. There are a few open source implementations like libCEC, Android HDMI-CEC, and even an Arduino implementation. The circuit to interface a microcontroller with the single CEC pin is very simple – just a handful of jellybean parts.

[Joshua]’s work is based off a talk by [Andy Davis] from Blackhat 2012 (PDF), but greatly expands on this work. After looking at a ton of devices, [Joshua] was able to find some very cool vulnerabilities in a specific Panasonic TV and a Samsung Blu-ray player.

A certain CEC command directed towards the Panasonic TV sent a command to upload new firmware from an SD card. This is somewhat odd, as you would think firmware would be automagically downloaded from an SD card, just like thousands of other consumer electronics devices. For the Samsung Blu-Ray player, a few memcpy() calls were found to be accessed by CEC commands, but they’re not easily exploitable yet.

As far as vulnerabilities go, [Joshua] has a few ideas. Game consoles and BluRay players are ubiquitous, and the holy grail – setting up a network connection over HDMI Ethernet Channel (HEC) – are the keys to the castle in a device no one  would ever think of taking a close look at.

Future work includes a refactor of the current code, and digging into more devices. There are millions of CEC-capable devices out on the market right now, and the CEC commands themselves are not standardized. The only way for HDMI CEC to be a reliable tool is to figure out commands for these devices. It’s a lot of work, but makes for a great call to action to get more people investigating this very interesting and versatile protocol.

10 thoughts on “DEF CON: HDMI CEC Fuzzing

      1. I remember asking about this in uni ages ago about the 360 when we had a “Microsoft day” and one of the devs there said dealing with CEC is more hassle than its worth due to it not being standardized. So could be both :P though for my Xbone i dont use a remote i just use smartglass and now the streaming part (as i am that lazy to change the input of my monitor)

  1. The problem is 99% of all devices screw up CEC badly. the standard CEC command for TV off works only on a small minority of tv sets. LG for example ignores that command.

    It’s because the HDMI spec should have REQUIRED tv manufacturers to support all of the CEC common commands or they are not allowed to say “HDMI” or use the connector.

    1. the nice thing about standards is there are so many to chose from. The things needs the features checkboxed that sell it in the store, all the other stuff that ‘consumers’ don’t know about can safely be ignored. There is something to say about keeping your features as minimal as required.

  2. Its just freaking i2c, how can so many companies fuck it up?
    How hard is it to have working what can be reduced to a list of commands and responses for each one?
    My LG tv always tries to wake-up the STB, but the STB(a Samsung piece of crap) ignores all the commands, just great.

  3. HDMI Ethernet Channel (HEC) – sounds so sweet, especially when you have DVRs and game consoles plugged into a same TV. But in reality every consoles and PCs ever developed kindly decline to support HEC and anything related to network on DVRs simply suck. And such is life.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.