 Hello everyone. I'm Josh aka Colonel Smith and this is high def fuzzing, exploring vulnerabilities in HDMI CTC as he said. This is not my first time speaking at a conference however it is my first time speaking at DEF CON. So hopefully there will be a resultant effect of that. Feel free to ask questions anytime but it's on you to remind me where I was in the presentation. So because I have a squirrel kind of approach. In order to introduce myself and kind of snap you guys out of any hangovers or you know food comas you might be in we're going to start with some really easy audience participation. First is if there's anyone here from the U.S. Postal Service please come forward so I can kick you where it hurts. Lesson learned don't ever ship medication to your hotel room if you're in Vegas because apparently they're incapable of doing that. I mean they can so I'm been told but anyway. Now onto the quiz. Which of the following is not true about me this is my intro or my who am I or whatever. You don't have to raise your hand or anything. I know you're all dying to raise your hand but you don't have to just think about which one you think might be false. I've had ten knee surgeries I worked at Johns Hopkins University applied physics laboratory I was voted most athletic in high school previously ran assessments of the 92nd information warfare aggressor squadron in the Air Force. I have a BS in computer engineering from Rensselaer Polytechnic Institute. Represent all right. I'm an external Metaspoil developer and I had command and control of 50 nuclear ICBMs on 9-11. Three. So I have had ten knee surgeries. I've had five other ones as well. If you have any advice or anything I'm full of it I thought about writing a book about it for a while. Knee surgeries anyway. I did work at Johns Hopkins University applied physics laboratory aka PL. I pretty much did weapons system vulnerability assessments. I was actually voted most athletic in high school so don't judge a book by its cover. Referencing number one. All right. And referencing number one now you know why I'm so fat. I did previously run assessments of the 92nd information warfare aggressor squadron which is now the 92nd information operation squadron. I did vulnerability assessments, pen tests and red teams and that kind of stuff. I do not have a BS in computer engineering from RPI. I have a BS in aeronautical engineering from RPI. Go figure. Also an MIS and some CS I studied while working at Hopkins. I am a Metaspoil developer since 2013. And I was in charge of 50 nukes on 9-11. I was sitting underground in Montana. If you want to hear the full story feel free to buy me a drink and we can talk about it. You don't have to buy me a drink but it helps. So this is what we're going to speak about. I'll explain what CEC is. We'll talk about some of the specs and design details. We'll get into the protocol a little bit. We'll discuss some of the attack surface and how we can go about analyzing it. Finally we'll talk about some of my test results and what I hope to accomplish moving forward. It's definitely in a state of there's more to be done. Which I could use some help with from all of you deaf counters. Why did I look at this area? Well I was kind of late to the hacking game as I mentioned before. I did some time in the air force. I did 10 years. And the first seven had nothing to do with Infosec. So early in my career I kind of lacked the knowledge to do anything innovative research. So later in life it's kind of hard now to find some stuff that's interesting yet also has not been covered before. In addition I kind of enjoy risk assembly more so than like city six, et cetera. And as I looked into this area I found that there's actually quite a few other avenues in mobile device. A lot of mobile devices actually use CEC. So essentially a lot of things started to open up as I looked into it before I committed to presenting on it. Also as it says there my son is completely obsessed with HDMI cables among other cords and whatnot. And I think my co-workers can vouch for this. Especially when he showed up for take your child to work day. And man if you better save your work as all I'm saying you might be unplugging some of your stuff. So there has been some previous research in the area. I actually was not aware of this in the beginning and it was kind of late that I figured it out which is really a fail of my Google foo because it was not hard to find second time around. But Andy Davis presented on at Black Hat EU in 2012. He wrote a GUI Python CEC fuzzer using WX Python which was great as far as the GUI standpoint. I mean I definitely would not go through that effort. But it was somewhat simplistic. I had no exception monitoring and no crash data gathering. So it's kind of on you to watch what was going on. So what is HDMI? As you probably know it stands for high definition multimedia interface. It's ultimately just an interface specification which is implemented in the form of cables and connectors. It's the successor to DBI and has quite a few features some of which are potentially quite interesting to folks like us. So what is CEC? CEC is consumer electronics control and it's one of the features defined by the HDMI spec. It's designed to simplify system integration with a common protocol that allows the user to command and control up to 15 devices. CEC is what allows your HDMI connected devices to turn on the TV, change the input and that kind of thing. So if you have like a Fire TV stick or Chromecast but not an Apple TV absolutely no support for CEC on an Apple TV. Anyway you turn it on and it automatically changes the input on your TV and that kind of thing. That's all CEC. It's also been adopted into some other technologies that we'll talk about in a second. For instance these don't necessarily look like HDMI devices because they're basically not. There's Slimport. I should say I'm going to go with MHL first. MHL is an industry standard for a mobile audio video interface that allows consumers to connect portable consumer devices to high def TVs and audio receivers etc. MHL is a consortium founded by Samsung and you know various others. Interestingly the MHL remote control protocol allows you to use your TV's remote control to operate the MHL device. So for instance let's say you have a Samsung but not a G6 because they got rid of it in the G6. In theory you can use a TV remote to control your device. I think this is more commonly used with inside your car for automobile car stereos and stuff like that. Slimport is a proprietary alternative to MHL which was made by Visa and it's based on the VESA not VISA. It's based on the display port standard and is integrated in the common micro USB ports as well. Both of these are vendor or excuse me connector agnostic which is kind of bizarre. The thing about it the standard is designed to permit port sharing with the most commonly used ports which is why they usually double as micro USB connectors or USB type C, the kind of newfangled everyone's jumping on board recently. There's a ton that could be discussed here so much though that I'm actually starting to think that this could be its own research topic but that's not where I started so that's not where we're going. The early versions of the HDMI spec don't really interest us all that much. Pretty much one through 1.2 is all basic stuff that we don't really care about in this talk. The thing to remember here is that 1.2A is the lowest version with fully featured CEC. However, there are some differences when you get to the upper versions from 1.2A as far as CEC goes. Of course as well as other parts of it. So 1.2A is kind of the lowest we want to look at for vulnerabilities or any kind of interesting functionality. Versions 1.3 through 1.3C add some cool capabilities from if you're an AV person but not much of interest us here. Version 1.4 is definitely the sweet spot for us for our purposes as it's the most widely deployed and if you have something at home it's almost it's very likely 1.4 could be 1.3 unless you bought it like I don't know eight years ago. We're going to keep an eye however on or at least I am on 2.0 since it implements new fuzzable features and CEC commands. I'm going to start testing that as soon as I find something that supports HDMI 2.0. I'm sure they're out there I just honestly haven't looked very hard. One interesting thing to note about CEC in 2.0 is the extensions quote provide expanded command and control of consumer electronics devices and that's it. That's all I know. The spec, I'm not an HDMI adopter personally so I don't have access to the full 2.0 spec and I haven't been able to find it online. If you are able to find it online let me know. It would be very interesting. So some interesting 1.4 features since I mentioned before it's kind of a sweet spot. The audio return channel could be interesting. It essentially allows audio to be returned to the sender. I'm not sure exactly what we're going to attack there. Could make for some interesting like command and control. Maybe if you have a payload that's CEC capable you could have it sending stuff back over the arc. I don't know. However, HEC is quite interesting. It's HDMI ethernet connection and supports up to 100 megabits per second. It's pretty much standard networking over HDMI. So in this picture you can see that's kind of what most people might have going on if they wanted their devices to have network connectivity. And in theory, I threw in the Apple TV there again just for another whack at that. Essentially if you enable it and all of your devices are capable of it then you could go with this configuration which if you didn't have an Apple TV would be completely dependent on the TV for network connectivity. So the TV is connected to the network, you know, regular network and everything else is actually connected to the network as well over HDMI which may not be something you expected. You know, you might think this thing is just connected over an AV cable so it's not network connected but it may actually be. So a few details about CEC itself. An HDMI CEC is implemented as a one wire bi-directional serial bus. It's quite slow, it's 500 bits per second. It uses the AV link protocol which is another industry standard to perform remote control functions so you can essentially relay your remote control commands to other devices without having line of sight. It should be noted that an HDMI CEC wiring is mandatory, however the functionality is optional. Some notable implementations. The commercial brands use various trade names to market their CEC functionality as you can see. What libraries they might be using under the hood, I don't know. And if any of you know, I'd love to know. I almost tripped myself. As for the open source implementations, we have Lib CEC from Pulse 8 which is dual licensed so it may actually be running under the hood on some of these devices. I haven't found any though yet. It's also a pretty fat CEC++ code base and has multiple example clients which is handy for my perspective for developing a fuzzer. As you can imagine, the Android implementation is mostly Java which is somewhat less likely to be terribly interesting. Still could be but I kind of put it lower on the let's play with this list. So CEC addressing is pretty similar although at the same time a little bit bizarre compared to IP addressing. The physical address is similar to a regular IP address in its appearance like 1.1.1.1. However, it's more akin to the hardware MAC address as far as its functionality goes. It's determined by which physical port on the TV or your AV receiver the device is connected to. The root display aka the TV is always 0.0.0. So I say 3 or 4 0s. Anyway, you get the picture. Some implementations they won't even initialize if you don't have something at 0.0.0.0.0. One of the major uses of the physical address is to allow for CEC switching so you can actually have this concept of regular network switching except for CEC. So that's essentially what forced them to have a physical address. In addition to the logical address, the logical address is a 4-bit address negotiated on the HDMI network by the device and is used in basically all CEC messaging as a source and destination. Non-CEC capable devices get a physical address but not a logical one because they don't actually support CEC. There's kind of your mapping of general logical addresses. It's not that exciting of course but if you were interested to know why you plugged in one HDMI device and you got, you know, address 4 instead of address 1 it was because it was a playback device and that's where they start. The CEC protocol is quite simple. Essentially what you're dealing with is blocks of 10 bits. The first 8 bits are the information. The trailing 2 bits are an end of message bit and an act bit. Of course the end of message bit should be set to 1 if you don't have any data following that but of course we're going to play with that because who knows what the device will do when it's getting improperly formatted messages. So the header block, the first 8 bits are split across the source and destination logical addresses. They're 4 bits each and I think I already said that. All blocks have 2 trailing control bits which I mentioned earlier. Data blocks are the same thing and they just instead of being divided into 2 4 bit areas it's 1 8 bit area. An out code block is just a data block except for the data that it has in it is an out code. Pretty difficult. Here's our second quiz. I'm just kidding. Here's some examples of a few messages. Zero F by itself is a broadcast pane. Zero is the source. F is the destination. F is broadcast. For our second one we have 1 is the source. F again broadcasts as the destination. The out code in this case is 82 which is essentially I want to be active source. Active source meaning input to the TV. And the last thing is 2 data blocks of the parameter which represents the physical address of the thing that's actually going to become the active source. And our third example again 1 is the source. Zero is the destination which is the TV. We have an out code is 64 and then we have some data. So we have the source, the destination, the out code which in this case is set OSD string which is on screen display. I use that one as an example because it's string based so if we're going to try to attack it that's kind of a fun one. And then we have message parameters. And the first is 44 which is essentially just bit flags for how to display whatever it is you want to display. Then the rest is an ASCII string. So generally speaking source, destination, out code, data, source, destination, out code, data or message parameters and things. The ping is essentially a message where the header's end of message is set to 1 and therefore there are no data blocks. It's used to pull for devices. You saw the example before of zero F. It's also used for logical address allocation. So essentially what you do is I want to be 1. You say anybody 1? You don't get a response, you're 1. It's a lot like IPPA addressing. I'm hoping this isn't a bad thing. Do I keep talking? All right, just a second. You want to be rude. That means I get a bigger shot. That means I get a bigger shot, right? Because they said yes. Some extra information while they're preparing that, the CEC protocol. It's basically big Indian all the time, most significant bit. First, text is only printable ASCII, which I find kind of interesting since obviously a lot of consumers are not in ASCII language territory. I don't know what I'm saying. All right, all right. Messages can be well played sir. Well played. You all know the drill. We have a new speaker. It's very hard to get accepted at DEF CON. So I think we owe him another round of applause. And he's saying desperately do not introduce Jeff with Tesla. That's Jeff with Tesla. How about the Tesla talk yesterday? Did you guys go to that? That was awesome. All right. He'll just keep your car secure. But you know. The last little bit out of it. Where was I? No, kidding. I mentioned before. Messages can be directly addressed, broadcast or either. Devices should ignore a message coming from address 15 unless the message invokes a broadcast response. Messages have been sent by a CEC switch or the messages stand by which is basically the power off. Wrong way. The CEC protocol has a transmission flow control. There's three mechanisms for that. For reliable frame transfer. Framerine transmissions up to five. Flow control, frame validation, which is essentially ignore messages that have the wrong number of arguments. Of course that's going to be implementation specific. At least that's my hope. A message is assumed correctly received when it has been transmitted and acknowledged. A message is assumed to have been acted upon when the center does not receive a feature abort within one second, although that's typically 100 milliseconds. This could be useful for doing fuzzing, obviously. So moving on to attack vectors and thoughts about things we might be able to play with. HDMI network exploitation via CEC is kind of my holy grail. In addition, since we have this HEC concept where we can essentially set up networking over a kind of a not expected medium, I think it could lead to some interesting scenarios where you have, you know, you set up a network connectivity and then you're able to, for instance, you could attack it further if it's got server listening code. Or you could just use it for faster, you know, command and control or X fill or whatever else because obviously 100 megabits per second is slightly greater than 500 bits per second. This could also be a great place to hide on a network because who in their right mind is going to look on your Blu-ray player for you? And generally I would say, you know, well, yeah, Blu-ray players at home, but what about at work and enterprise? Well, think about most enterprises, they're going to have something that's CEC capable. It may just be the telecom, you know, teleconferencing system or it could be any number of things. Not saying it's your A number one target, but it could be interesting. There's also quite a range of targetable devices as it kind of alluded to earlier. TVs, Blu-ray players, receivers, TV sticks, Chromecasts, Amazon, etc. Some game consoles. Of course, the more interesting I think area that most people are going to want to know about is mobile phones and tablets and the devices that implement MHL or Slimport are almost always CEC capable, they're supposed to be. So what is the actual attack surface? Well, somewhat debatable, but I think these are the four most interesting. CEC commands, CEC vendor specific commands, which are definitely who knows what they, who wrote that and how and everything else. The problem is you have to discover those unless you find some sort of documentation. HEC commands, you know, to set up and tear down HEC, etc. And the HEC functionality itself. So as far as finding vulnerabilities goes, we have various approaches in some of which I'm better at than others, but first I want to identify at risk messages and fuzz them. We could do some source code analysis. It can be a little hard to come by except for lib CEC and of course the Android implementation. We can do some reverse engineering, which can be a little hard to get the firmwares, so it kind of depends on your situation, whether or not they offer firmware downloads, etc. Or if you have another way of getting on a device and you could possibly just obviously rip the code that way and look at it. In general, you're going to want to expect different architectures. You're not going to see, as far as I know, any x86 unless someone actually creates a computer that has HDMI, CEC support, because like I said before, or maybe I haven't, but a lot of them have HDMI, but I'm actually CEC. I think that's coming up actually. The popularity of MIPS is probably picked 32. Yeah, I would agree. There's definitely quite a bit of arm as well, and there's something called ARC, which may or may not have heard of. I know my, I have a Denon AV receiver and it has an ARC processor. MIPS is definitely what I've run into the most so far. So what are some of those interesting messages? Well, pretty much the string operations, right? That's a good place to start. We've got set OSD name. Again, OSD is on screen display. Set OSD string, which is very similar. Set timer program title. And then there's, of course, vendor specific messages, which again, you have to discover on your own. So we need to answer some questions if we're going to actually fuzz. One of those questions is how can we send arbitrary CEC commands? And the second is how can we detect if a crash occurred? And both of those are a little, a little wonky. As far as sending messages goes, you're probably going to need some sort of hardware. As I did say earlier, no lap or desktops have HDMI CEC support. They have HDMI. There's just no CEC functionality there. There are a few adapters you can buy. The Pulse 8 USB HDMI converter or adapter is pictured there. There's also the rain shadow, which I, for some reason, makes me giggle the name of the company. The rain shadow HDMI CEC to USB bridge. The big difference here is the Pulse 8 USB HDMI adapter actually has HDMI pass through. So you can actually still look at some video that's being displayed through that adapter. Whereas the serial bridge, it just sends CEC commands of serial. That's it. One of the more interesting things that does support CEC is the Raspberry Pi. It uses lib CEC and you can compile it, which is a slight adventure, but once you get it running, now you have a very portable device you can use for fuzzing, as well as monitoring your fuzz, because it's pretty hard to, it can be hard anyway to watch your fuzz, the stuff that's going out on the wire while you're sending it. As far as the software side of actually sending messages, the Pulse 8 driver is open source, as I mentioned. That's dual licensed. Pretty recently, they started shipping SWIG based bindings for Python. And thank you to Jayzel over there who knows far more about SWIG than I do. I was originally trying to create my own SWIG bindings. I was going to use Ruby because I'm more proficient in Ruby. Turns out I didn't realize until I saw their version of the SWIG bindings that that's actually, I was never probably going to pull that off. There's all sorts of callbacks and kind of disgustingness that goes on there. Even after seeing the Python version of the SWIG bindings, I could not convert them to Ruby without, I would have to miss DEF CON kind of thing. Also lib CEC supports a small number of devices, but more than one. Of course it was being generally the Raspberry Pi as well as the adapter that they make, as well as some X and O stuff and a couple of others that are less interesting. But then the question becomes, can we actually send arbitrary CEC messages with the Raspberry Pi or lib CEC? Turns out you can. Although I'm kind of embarrassed to tell you how long it took me to go through the code base to figure out whether or not I was actually going to try to validate my CEC messages. But let's say, for instance, we wanted to send a couple extra 4-1s. Can we do that? Yes. Onto the fuzzing process. It has been done before, specifically fuzzing CEC by Davis, as I mentioned before, with Python and the Rainbow Tech Serial API and Serial Bridge. I actually didn't know that until late in the research. The Rainbow Tech device is nice because it has a very simple serial API. So looking at the code bang X send message. Awesome. Lib CEC, totally different story. Much larger API. The Rainbow Tech and the associated fuzzer from Davis don't have a whole lot of complex functionality. However, they do the basic job. I did already start doing the lib CEC thing, so I just stuck with it since obviously I don't want to regurgitate what's already been done. So I went with the lib CEC plus Python since they do ship that Pi CEC client. Granted, it's pretty minimal, so you're going to write all kinds of your own code. Could also use the Raspberry Pi for that, which I do have, and did use a little. Maybe someday I'll port it to Ruby. So generally speaking, the fuzzing process or major steps are ID, the target, and inputs, which we already have kind of given. Generate fuzz data, execute fuzz data, monitor for exceptions, and determine exploitability. For generating fuzz data, I started with the long strings and string-based messages, threw in some format strings, threw out some parameter abuse, you know, a message is not expecting to have any parameters, I'll give it six, or a message is expecting to have four, I'll give it two, that kind of thing. Some simple bit flipping, and I adopted some of what Davis had previously done. As far as executing fuzz data, essentially all I did was pull the device, send the message, and then pull it again. In a straight black box scenario, right? I don't know anything about the device, I don't have a shell on, I don't have a debugger on anything else. That's about what I could do. Then onto monitoring for exceptions, I can check for the ACK, I can pull it again. If I have the debugger, or capability of debugging, then I'm obviously going to use that. If I have a shell at least, but maybe not a debugger, then I can check if the service or app is still running. If it's a TV that you're fuzzing, you'll probably notice it crash, and we'll see an example of that later. Which is fun, kind of hard to automate, unless you're like Charlie Miller and you have 50 million interns working for you or whatever. If there is an exception, obviously you want to record hopefully the message that you believe sent it, some state, and the debug details if you have any. If you have a shell, but not a debugger, then you're kind of in the situation where you can at least monitor the process. In the case of the Samsung Blu-ray player that I played with, thank you to Ricky Lachey over there, since he already had a root shell, a local root shell on it. So that was kind of an ideal target, because I could get on the shell. In that particular instance, the Blu-ray player has bash, but not the watch command, so I wrote a little loop, it's not exactly rocket science. Something you also want to do if you're in that situation is monitor the TTY output. If you have it, which is in our case that's how Ricky discovered you could get on the device. So in this case, you can see kind of around the middle. I haven't been able to root cause this and even know if it's purely related or not, but you can see how there's a couple fatal messages about the starting the background widget manager. This was a while after starting the device, so I don't know why the background widget manager would be starting randomly 10 minutes after I booted the thing, but I don't know for sure. The implication could be that maybe it crashed and it was restarting, but obviously that's a stretch. So we need to determine exploitability, right? That's kind of an adventure, because unless you have a debugger, I mean it's purely black box, so you kind of do your best. It's also very specific to each device that you're messing with. Some complications for fuzzing, which I've probably already covered a couple of these, but getting a hold of devices, since you want to get one of every Blu-ray player, I hope you have some money, although at least they're not like 400 bucks like they used to be. But they are around you, sometimes it's hard to know, realize that something is actually CEC capable until you play with it. For instance, the HP Chromecast or Chromebook 11 actually has CEC and I had gotten one for my son and boom, play with that, although it's flaky and not when I'm fuzzing it. You can also emulate using QEMU and some firmware. That's something I'd like to look into. The speed is, you know, it's so slow that if you're going to fuzz multiple devices, obviously you want to do that in parallel. And one thing you can do is reverse engineer the targets as best you can in the beginning in order to focus your fuzz. Some other complications, again, debugging, you need access to the device. There's probably no debugger on it anyways. In compiling for it's probably a PETA. You might be able to pull it off, you might not. I would say keep an eye out though for GDB server files because you may be able to use GDB server to debug it even though there's no debugger there locally. Obviously collecting data can also be an adventure depending on how much access you have as well as deduplication and reproduction. And for me like reproduction was a total adventure. One area I need to definitely improve the fuzzer. Some targets we can talk about, at least that I had access to. Again, the Samsung Blu-ray player, which is MIPS based thanks to Ricky as well as John Anderson. I don't think he's here but he's one heck of a solder, let me tell you. So that was great because we had a local shell get on the device, look around, rip the file system, that kind of thing. I also have access to a Philips Blu-ray player, Samsung TV, Panasonic TV, which we'll see a video of, Chromecast, Amazon Fire TV stick, Kindle Fire, Galaxy S5 and S4 actually I believe. Galaxy Note and that one particular HP Chromebook 11. So I think obviously the more interesting part is what results did you have? I had some. I didn't have a ton. You're not going to see a full CEC purely CEC exploit. Sorry. So the two devices that I'm going to talk about as far as being interesting are the Panasonic TV and the Samsung Blu-ray player. I'm intentionally not giving model numbers because I haven't root caused and reported some of this stuff if it's even reportable. Although I highly doubt they're actually going to respond to anything. Having worked at the ZDI, vendors like that just almost never respond to that kind of, those kinds. That department doesn't even usually know what a vulnerability is. It's pretty frightening. So in this, I don't know if you can read it. It's a little fuzzy. Suddenly, this is the Panasonic television, it suddenly just said, hey, I'm trying to upgrade from the SD card, put in an SD card. I'm like, what? That was kind of a, that could be expected functionality. I did find some vendor specific commands. I don't know what they do yet for Panasonic. But that seems bizarre. Like, why would you want to have someone on the CEC, the HDMI CEC network be capable of triggering an upgrade? Like, if you're going to have, you need an SD card anyway, so you're already local. So I don't know. It just seems weird. So here's a video, the Panasonic television as well. And you can't really tell, it's going to shut off. You know it's on, obviously. And Jayzl starts the fuzzer for me. And really quickly, it turns off. So I'm pressing the power button trying to turn it back on. And obviously, squat is happening. Well, maybe that's not obvious, but I can tell you. Don't pull the serial number up there. So I'm plugging it. And I had reproved this a number of times. So I was like, oh, if I wait, you know, six or seven seconds, it'll be alright. The first time I did this, it's actually Works TV, and I thought I'd totally bricked it. I was somewhat excited and somewhat scared at the same time. So I'm pressing power, nothing's happening. Super exciting video, I know. Had to cut the audio out because I dropped the F-bomb in the middle of it. So I unplug it again. And I'm not going to make you wait through that, but it does not start the second time either. I wait like ten seconds. I don't know. And it still doesn't start. Eventually you get to the screen where it's functional again. On to the Samsung Blu-ray player. Because we get a local shell on it, we were able to rip the binaries and what not. So there's a binary called app player which handles the CEC functionality. I did some manual RE on it, and I also did some rudimentary, very rudimentary analysis with some ghetto IDAPython that Jayzel helped me with a bit. And basically I just said, you know what, let's look for banned functions, right? It's brutal how many times you'll see code, and I see Fritz Downeyer smiling, how many times you'll see people that, you know, they wrote the code 20 years ago, and every function they use is banned now, nowadays. But it has been updated, of course not. So I did this quick, hey, let's look at all the banned functions and see how often we're going to see these code. So here's just a couple of those. Stir copy shows up 333 times. These are all jump and link register and MIPS is call, right? So these are just what I call jailers, they're just jailers. Stir in copy, there's 409. Men copy, there's 310. Print F which is, you know, it's not always exploitable of course, to say the least. But all the variants of print F, there were 11,685 calls. So, you know, I'm doing that, right? Well, then I started to cross reference them with, at least symbolically, like debugger symbolically, CEC namespace, and it got way less interesting, really quick, which was very disappointing. But I did find there are three mem copies, two of which I'd already found just by doing reverse engineering and looking at the receive, and just looking at receive functions, anything that hadn't received in it, and I found the two mem copies, which as far as I can tell, I can't confirm that they're not exploitable, because I can't tell anywhere that the size of the mem copy is limited. But it may just, at some point you reach something called the OSL, the operating system abstraction layer, and it gets ugly at that point. Also, I don't have the debugger at this point, and so I can't dynamically look at what sizes are being passed in. So the third mem copy was definitely not exploitable. There are 73 prenefs, but so far none of them actually call system or anything else. So you can, I don't know, maybe you can or cannot see in the lower right-hand corners where those mem copies are located. Not horribly exciting, but... So if we can pull off a CEC exploit, what can we do? Well, enable ATC, I've kind of beat that down, I'm not going to go over that again, but... When we enable the LAN, we can attack LAN services possibly, enable higher-speed exfiltration. We could possibly control an MHL device, which are getting pretty popular. We may be able to use that as a beachhead for attacking other devices, and of course you could hide there like nobody's business, right? I mean, I don't know of anyone who's ever even thought about hey, maybe they're persisting on this, you know, TV or Blu-ray player. So these are some of the things that I'd like to do moving forward. I'd like to un-uglify my Python, because it is pretty awful. Before I put that out on ZDI's GitHub page, because it's just kind of embarrassing at the moment, and like I said, I'm more of a Ruby person. I'd like to integrate it into a bigger, better fuzz framework that has more capability as well as more management and interface, et cetera. Right now I have a fairly command line. Ultimately I'd like to exploit CEC and at first I'd like to bind a shell to the network interface, and then moving forward I'd like to be able to enable HEC and then bind the shell to that interface, and then ideally be able to exploit CEC and kind of bind the shell straight up on CEC so there's no communication over the regular network. Also going to be exploring the attack surface of 3D and audio return channel and more with HEC, especially because 2.0 has quite a few future ads to the CEC capabilities and of course more devices. Luckily working at ZDI I've accessed a lot of mobile devices and all sorts of what not. So that helps, but it's still only a few things and only a few things are CEC capable, so I'd love some additional help. An emulation would be great because then I don't have to have direct access to some of those devices. In conclusion, this stuff is becoming more and more pervasive and invasive. Some of those old bone types might be new again. I do think at least in Samsung's case they're benefitting from the fact that the code is just straight up newer, right? It was written probably, I don't know, four or five years ago as opposed to 20 years ago, so hopefully some newer developers have walked in and realized that the code is pervasive. For most of these devices, it's hard to upgrade them, sometimes impossible. But in general, let's face it, the risk in this situation, your vulnerability, times your exposure and times your impact, it's not super high. I'm not going to try to float that to you. But the exposure is definitely growing. Those devices are getting everywhere. The impact is probably privacy, because we're talking about stuff that can film you and all that kind of stuff. Here's some links if you want to know more. The code is not up on ZDI's GitHub yet, as I said before. It's a little awful right now. HDMI.org is the HDMI consortium or whatever. They have a lot of good useful information. If you're interested in what I did the presentation in, it's called reveal.js. And a website that's pretty useful when you're first figuring stuff out, it's called CEC-O-Matic. It has kind of a web app that allows you to pick, like, I want the source to be four, and I want the destination to be broadcast. What does that message look like? And it'll figure it out for you. It'll do the reverse, too, so you can type stuff in and see what it actually is. That's all I have. Any questions? As far as I know, no, because the CEC protocol itself has absolutely no type of security at all. Yeah. They definitely keep some information private, you know, for HDMI adopters only, but I don't think there's any consideration at all. At least not from our type of security perspective, you know. Sure. Any other questions? Was the local JTAG out to USB converter, interrupt the I thought about showing it, but interrupt the boot process, give it your own boot command, establishes telnet on the network interface, and then just telnet in with a known root password. Any others? Sir. Can you say that again? A little louder. Other than, like, the protocol management part where you obviously can't necessarily stomp on other people while they're talking, there's no other limitation. Squat so far. It's flaky enough. Sometimes I'd connect it up, and then the video would come up for two seconds and then just go down on its own. So it's been a little bit of an adventure. Thanks very much. Oh, I have ddi.coin. So come on up if you want one. Thank you very much.