Hello everyone.  I'm Josh AKA kernel Smith and this is high deaf fuzzing, exploring the
vulnerabilities in HDMI-CEC as it says. 
     This is not my first time speaking at a conference however it is my first time speaking at DEFCON.  So hopefully there will be a resultant effect of that.
     Feel free to ask questions any time but it's on you to remind me where I was in the presentation. Because I have a squirrel kind of approach.  In order to introduce myself and snap you guys out of any hangovers or any food comas you might be in, we're going to start with some really easy audience participation.  First, if there is anyone here from the U.S. postal service, please come forward so I can kick you where it hurts.
     The lesson learns, don't ever ship medication to you hotel room if you're in Vegas because apparently they're incapable of doing that.
       I mean they can so I've been told, but ... Anyway.  Now onto the quiz.  Which of the following is not true about me.  This is my intro or who am I, whatever?  You don't have to raise your hand or anything.  I know you're all dying to raise your hand. You don't have to, just think about which one might be false.  Had ten knee surgeries, I worked at Johns Hopkins university applied physics laboratory.  Was voted most athletic in high school, previously ran assessments of the 90 second information warfare aggressor squadron in the Air Force.  I have a BS in
computer engineering from -- poly tech institute. Represent all right.  I'm an external meta Sploid  developer and I had command and control of 50 nuclear ICBMs on 911?
     Three?  I have had ten knee surgeries.  I've had five other ones as well.  If you have any -- need 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, APL.  I did weapons system vulnerability assessments.
     I was actually voted most athletic in high school. Don't judge a book by its cover.  Referencing No. 1. Right.  And referencing No. 1 now you know why I'm so FAT.
     I did previously run assessments at the 92nd information warfare special squadron which is now the 92nd specific information squadron.  I did and ran the unit that did vulnerability assessments 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
CI I studied while working at Hopkins.  I am a meta school aid developer.  Since 2013.  And I was in charge of 50 nukes on 911.  They were sitting on the ground in Montana.  If you want to hear the whole 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 the specks and design details.  We'll get into the protocol a bit and discuss the attack surface and how it 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 in a state of there is more to be done which I could use some help with from all you DEFCONers. 
     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 ten years.  And the first 7 had nothing to do with info tech.  So early in my career I lacked the knowledge to do anything innovative research.  So later in life, it's kind of hard now to find some stuff that is interesting but also has not been covered before.
     In addition I kind of enjoy risk assembly more so than CD6 et cetera.  And as I looked into this area I found that there's actually quite a few other avenues and mobile device, a lot of mobile devices that use CEC.  So 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.  My coworkers can vouch for this.  Especially when he showed up for take your child to workday and -- you better save your work.  That's all I'm saying.  He might be unplugging some of you 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 when I figured it out which was really a fail of my Google foo because it was not hard to find the second time around.  But Andy Davis presented at black hat EU in 2012.  We wrote a GUI python CEC puzzler using WX python which was great as far as the GUI standpoint.  I would definitely not go through this effort.  But it was somewhat simplistic, I have not exception monitoring and no crash data gathering.  So it was kind of on you to watch what was going on.
     So what is a HDMI?  As you 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.  The successor to DBI. It has quite a few features, some of which are potentially quite interesting to folks like us.
     What is CEC.  That is consumer electronics control and it's one of the features defined by the HDMI speck. It's defined to simplify system integration with a common protocol that allows the user to command the control up to 15 devices.
     CEC is what allows the HDMI connected devices to turn on the TV, change the input and that kind of thing.  If you have a fire TV stick or chrome pass, but not apple TV, no support for CEC on apple TV.  Anyway, you turn it on and it automatically changes the input on your TV and that sort of thing, that is 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 is -- import.  Let me do MHL first.  MHL is an industry standard for mobile audio video interface that allows consumers to connect portable consumer device to high def TVs and audio receptors, et cetera.
     MHL is a consortium founded by Samsung and 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, say you have a Samsung but not a G6 because they got rid of it in the G6.  In theory you can use the TV remote to control your device.  I think this is more commonly used with
the -- inside the car for automobile car stereos and stuff like that.
     Symport is a proprietary alternative to MHL which was made by Visa.  And based on the VESA not VISA. It's based on the display port standard and integrated in the common micro USB ports as well. 
     Both of these are connector agnostic which is kind of bizarre if you think 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, that newfangled everyone
is jumping on board recently.
     There is a ton that could be discussed here.  So much so that I'm starting to think this could be its own research topic.  But that's not where I started. So it's not where we're going.
     The early versions of the HDMI speck don't really interest us all that much.  Pretty much 1 through 1.2 is 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.  There are differences when you get to the upper versions from 1.2A as far as CEC goes as well as other parts of it. 1.2A is the lowest we want to look at for vulnerabilities or any interesting functionality.
     Versions 1.3 to 1.3C adds cool capabilities if you're an AV person.  But not much of interest to us here.  Version 1.4 is definitely the suite spot for our purposes as it's most widely deployed.  If you have something at home it's very likely 1.4, it could be 1.3 unless you bought one 8 years ago.
     We're going to keep an eye, or at least I am on 2.0 since it implements new fuzz able 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 all I know.  I'm not an HDMI adopter personally, so I don't have access to the full speck. And I haven't been able to find it online.  If you are able to find it online, let me know, that would be very interesting.
     So some interesting 1.4 features since I mentioned before it's kind of the suite spot.  The audio return channel can be interesting.  It allows audio to be returned to the sender.  I'm not sure exactly what we could attack there.  Could make for interesting command and control, maybe if you have a payload that is CEC capable you can have it sending stuff back over the arch.  I don't know.
     However ATC 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.  But essentially if you enable it in all of your devices that are capable of it, you can go with this configuration, which if you didn't have an apple TV could be completely dependent on the TV for network connectivity.  The TV is connected to the network,
regular network.  And everything else is connected to the network as well over HDMI which may not be something you expected.  You might think this thing is connected over an AV cable.  So it's not network connected but it may actually be.
     A few details about CEC itself.  In HDMI CEC is implemented as a one-wire bidirectional serial bus. Buy itself it's quite slow, 100 bits per second.  It uses the AV link protocol which is another industry standard to perform remote control functions.  You can essentially relay the remote control demands to other devices without having line of sight.
     It should be noted that in HDMI CEC wiring is mandatory however the functionality is optional.
     Notable implementations.  The commercial brands use various trade names to market their CEC functionalities as you can see.  What libraries they're using under the hood, I don't know.  If any of you know, I would love to know. 
     As for the open source implementations, we are LIB CEC from pulse 8.  Which is a dual license.  So it may be running under the hood on some of these devices.
     I haven't found any though, yet.  It's also pretty FAT CEC plus plus code place and has multiple example clients which is handy from 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 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.0.  Did I say three or four zeros?  You get the picture.  In some implementations they won't initialize if you don't have something at 0.0.0.0.  One of the major uses of the physical address is to allow for CEC switching so you can't have the concept of regular network switches except for CEC.  That's essentially what forced them to
have a physical address in addition to the logical address.  The logical address is a four bit address negotiated on the HDMI network by the device.  It's 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 even support CEC. There's kind of the mapping of general logical addresses.  It's not that exciting of course.  If you were interested in know why you plug in one HDMI device and you got, you know, address 4 instead of address 1, it's because it was a play back device and that's where
they start.
     The CEC protocol is simple.  Essentially what you're dealing with is blocks of ten bits.  The first eight bits are the information, the trailing two bits are end of message bit and an act bit.  The end of message bit should be set to one.  If you don't have any data following that, but of course we play with that.  Because who knows what the device will do when it's getting improperly formatted messages.
     Ladder block, the first 8 blocks are slid across the source and destination logical addresses. They're four bits each.  Blacks have two controlling bits which I mentioned earlier.
     Data blocks are the same thing.  Instead of divide into two four bit areas it's one 8-bit area.  An on code block is a data block except the data that it has in it is a not code.  Pretty difficult.
     Here is your second quiz -- just kidding.  Here is some examples of a few messages.  0F by itself is a broadcast ping.  0 is the source and F is the destination.  F is broadcast.
     For a second one we have 1 as the source, F is broadcast as the destination.  The out cast is 82 which is essentially I want to be active source.  Active sourcing meaning input to the TV.  And the last thing is the -- two data blocks of the parameter that represents the physical address of the thing that is going to become the active source.
     The third example, one is the source, 0 is the destination which is the TV.  We have an out code of 64 and we have data.  We have the source, the destination, the out code which is set OS D string which is onset display.  I use that one as an example because it's string based.  If we're going to try to attack it, it's kind of a fun one.  And we have message parameters and the first is 44 which is essentially bit flags for how to display whatever you want to display and the rest is
an ASCII string.
     Generally speaking, source, destination, op code, data.  Source, destination, op code, data.
     The ping is essentially a message where the header's end of message is set to one and therefore there is no data blocks it used to pull for devices. You saw the example before of 0F.  It's also used for logical address allocation.  Essentially what you do, I want to be one, anyone one.  You don't get a response? You're one.  It's a lot like IP addressing.  I'm hoping this isn't a bad thing.  Do I keep talking or ...?
     >> Yes.
     >> All right.  Just a second.  I didn't want to be rude.
     >> Is he doing a good job?
     >> Yes, ...(applause)...
     >> I could take a bigger shot.  That means I get a bigger shot, right.  Because they said yes.
     >> Yes.
     >> Excellent.  Extra information while they're preparing that, the CEC protocol.  It's basically a big ending all the time.  Most significant bit first, the text is only printable ASCII which I find interesting since obviously a lot of consumers are not in ASCII language territory.
     >> Keep going.  Keep going until we tell you ...
     >> All right.  Sorry. 
     Messages?
     >> Stop.
     >> Well played, sir, well played.
     >> Well, what the hell.  Anyway, you all know the drill.  We have a new speaker.  It is very hard to get accepted at DEFCON so I think we owe him another round of applause.   ..(applause)... to DEFCON.
     >> To DEFCON.
     >> Do not introduce 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 ...
     >> Get the last little bit out of there.  Where was it?  No, I'm kidding.  I mentioned before ...
Messages can be directly dressed, broadcast or either. 
     Devices should ignore a message coming from address 15 unless the message evokes a broadcast response.  The messages have been sent by a CEC switch or the message is standby which is basically power off. 
     Wrong way.  The CEC protocol has transmission flow control.  There are three mechanisms for that, for reliable frame transfer.  Frame transmissions, up to five.  Flow control frame validation which is essentially ignore messages with the wrong number of argument.  That is going to be implementation specific at least that is my hope.
     Messages assume correctly received when it's been transmitted and acknowledged.  And messages to have been acted upon when the center does not receive a future abort within one second although that's typically 100 milliseconds.  This could be used for fuzzing, obviously.
     So moving onto attack vectors and thoughts about things we might be able to play with.  HDMI network exploitation by CEC is kind of my holy grail.  In addition since we have the ATC concept where we can set up networking over a not expected medium, I think it
could lead to interesting scenarios where you have, you set up a network connectivity and you can attack it further if it has a server listening code or you can use it for faster command and control or whatever else. Obviously 100 megabits per second is slightly greater than 500 bits per second.
     This can be a great place to hide on a network. Who is going to look on your blue ray player.
Generally I would say yes, the blue ray player is at home but what about at work or enterprise, well think about most enterprises they're going to have something that is CEC capable.  It may just be the teleconferencing system or any number of things.
     Not saying it's your No. 1 target but could be interesting.  There is also a range of target able
devices that I alluded to before.  TVs, blue ray players, receivers, TV sticks, chrome cast, Amazon, et cetera.  Some game consoles.
     Of course the more interesting area that most people are going to want to know about are mobile phones and tablets and devices that implement MHL or slim port are almost always CEC capable, they're supposed to be.
     So what are the actual attack surface?  Well, somewhat debatable but I think these are the four most interesting.  CEC commands, CEC vendor specific commands, who knows who wrote that and how and everything elevators.  The problem you have to discover those unless you find some kind of documentation.  HTC commands to set up and turn on.  And the HTC functionality itself.
     So as far as finding vulnerabilities, we have various approaches and some of which I'm better at than others.  First I want to identify at risk messages and fuzz them.  We can do source code analysis.  It can be hard to come by except for CEC and the Android implementation.  We do reverse engineering, it can be hard to get firmware so it depends on your situation whether or not they offer firmware downloads, et cetera.  Or if you have another way of getting on a device and you can possibly just 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 XED6 unless someone actually create as computer that has HDMI CEC support.  Because a lot of them have HDMI but not actually CEC.  I think that is coming up actually.
     Popularity of MIMs is probably bit 32.  I would agree.  There is definitely a bit of arm as well. There is something called arch which you may or may not have heard of.  I have a Denon AV receiver and it has an arch processor.  MIHs is what I've run into the most so far.
     What are some of the interesting messages.  Pretty much the string operations.  That's a good place to start.  We have OSD name, OSD is on screen display. Set OS D string which is similar.  Set time or program title.  And of course vendor specific messages which you have to discover on your own.
     We need to answer some questions if we're going to fuzz.  And one of those questions is how can we send arbitrary CEC commands and the second is how can we attack if a crash occurred and both of those are a little -- can be 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.  If they have HDMI, there is just no CEC functionality there.  There are a few adapters you can buy.  The pulse 8USB HDMI converter or adapter is pictured there.
     There is also the range shadow which I for some reason, makes me giggle, the name of the company.  The range shadow HDMI CEC bridge.  The big difference here is the pulsate USB HDMI adapter actually has the pass throw.  You can still look at video displayed through that adapter whereas the serial bridge, it just sends CEC commands over serial and that's it.
     One of the more interesting things that does support CEC is the raspberry pie.  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. It can be hard to watch your fuzz and stuff that is going out on the wire while you're sending it.
     As far as the software side of sending messages, the pulse A 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 JAZEL 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 versions of the swig bindings that is -- I was never probably going to pull that off.  There are all sort of call backs and 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 DEFCON kind of thing.  LIB CEC supports a number of small number of devices but more than one.  Of course those being generally the raspberry pie as well as the adapter they make as well as XNO stuff and others that are less interesting.
     The question is can we send arbitrary CEC messages with the raspberry pie or the CEC?  It 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 it was actually going to try to validate my CEC messages but let's say for instance we wanted to send a couple extra, four ones.  Can we do
that?  Yes.  Onto the fuzzing process.
     It has been done before, specifically fuzzing CEC. Davis as I mentioned before with python and the rainbow tech serial API and serial bridge.  I didn't know that until late in the research.  And the rainbow tech device is nice because it has a very simple serial API. Looking at the code it's like bang X, send message, awesome.  LIB CEC totally different story.  Much larger API.  The rainbow tech and associated fuzzer from Davis don't have a lot of complex functionality, however, they do the basic job.
     I already started doing the LIB CEC thing so I just stuck with it.  Only I didn't want to regurgitate what has already been done.  I went with the LIB CEC plus python since they ship that PIE CEC client. Granted it's pretty minimal.  So you're going to write all kinds of your own code.  You can also use the raspberry pie for that which I do have.  And did use a little.
     Maybe some day I'll port it to ruby.  Generally speaking the fuzzing process, the major steps are ID the targets and inputs which is already a given. Generate fuzz data, execute fuzz data.  Monitor for exceptions and determine exploitability.
     For generating fuzz data, it started with the long strings and string.
     Based messages, threw in some format string, some parameter views, a message is not expected to have any parameter, I'll give it six or messages expecting to have four, I'll give it two.  That kind of thing. 
     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 a device, send a message and pull it again.  In the straight black box scenario, I don't know anything about the device, I don't have a shell or a debugger or anything else, it's just about what I could do.
     Then onto monitoring for exceptions.  Check for the act.  I can pull it again.  If I have a debugger or the capability of debugging, I obviously use that.  If I have a shell but maybe not a debugger, 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, it's 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 we want to record hopefully the message that you believe sent it, the state and the debug details if you have any.
     If you have a shell but not a debugger then you're kind of in a situation where you can at least monitor the process.  In the case of the Samsung blue ray player that I played with, thank you to [indiscernible] over there since he had a root shell on it, so that was kind of an ideal target.  I could get on the shell. 
     In that particular instance the blue ray player has bash but not the watch command so it was a little loop.  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 is how Ricky discovered you could get on the device.
     So in this case you can see around the middle, I haven't been able to recause this and know if it's purely related or not.  But you can see how there's a couple fatal messages about 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 ten minutes after I booted the thing but I don't know for sure.  The implication could be that it crashed and restarted but obviously that is a stretch.
     So we need to determine exploitability, right. That is an adventure unless you have a debugger.  It's purely black box.  So you do your best.
     It's very specific to each device that you're messing with.  Complications for fuzzing which I
probably already covered.  Getting ahold of the devices since obviously if you want to get one of every blue ray player, I hope you have some money.  At least they're not 400 bucks like they used to be.  But they are around you, sometimes it's hard to realize that something is CEC capable until you play with it. 
     For instance the HP chrome book 11, actually has CEC and I had gotten one for my son and boom, I played with that.  Although it's flaky and not when I'm fuzzing it.
     You can also emulate using QEMU and some firmware.  Something I'd like to look into.  Speed is, it's so slow, if you're going to fuzz multiple devices you want do that in parallel.  The 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, debugger, you need access to the device.  There is probably no debugger on it anyways in complaining for it is probably a PITA.  You might be able to pull it off.  You might not.  Keep an eye out though for GDBC server files because you may be able to use GDB server files to debug it when will is no debugger there locally.
     Obviously collecting data can be an adventure depending on how much access you have.  As well as the implications and reproduction.  And for me reproduction was a total adventure.
     That's one area I need to improve the fuzzer. Some targets we need to talk about.  At least that I have access to.  Again the Samsung blue ray player which is MIPs based, thanks Ricky.  As well as John Anderson, I don't think he is here.  He is one heck of a solderer, let me tell you.
     So that was great because we had a local -- to get on the device and rip the file system that kind of thing.  I also had access to a Phillips blue ray player, Samsung TV, Panasonic TV which we'll see a video of.  Chrome cast, Amazon fire TV stick.  Kindle fire, galaxy S5 and S4 I believe actually.  Galaxy note and that one particular HP chrome book 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 purely exploit.  Sorry.
     The two device I'm going to talk about as far as being interesting are the Panasonic TV and the Samsung blue 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 going to respond to anything. Having worked at the TDI, vendors like that just don't -- almost never respond to that kind of, they don't know, that department doesn't usually know what a
vulnerability is.  It's frightening.
     So I don't know if you can read it, the 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 that are specific commands.  I don't know what they do yet for Panasonic.  But that seems bizarre. Why do you want someone on the HDMI CEC network be capable of triggering an upgrade?  You're going to have an SD card anyway, you're local.  I don't know.  It just seems weird.
     So here is a video, the Panasonic television as well.  And you can't really tell, it's going to shut off.  It's on obviously.  Starts the de-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.  Maybe it's not obvious but I can tell you.  Don't pull the serial number off there.
     Unplugging it.  I reprod this a number of times so if I wait 6 or 7 seconds, it will be all right.  The first time I did this it was works TV and I thought I totally bricked it.  I was somewhat excited and totally scared at the same time.  I'm pressing power.  Nothing is happening.
     Super exciting video, I know.  Had to cut the audio out because I dropped the F bomb in the middle of it.
     So employed again and I'm not going to make you wait through that.  But it does not start the second time either.  I wait ten seconds, I don't know and still doesn't start.  That's not where I wanted to go.
     You get to this screen where it's functional again.  Ton the Samsung blue ray player.  Because we got a local shell on it we were able to rip the binaries and whatnot.  There is a binary called app player which handles the CEC functionality.  I did manual RE and rudimentary analysis with ghetto, I had a python that JAZEL PMed me with a bit.
     I said let's look for band functions.  It's brutal how many times you'll see code and I see Fritz smiling, how many times you see people that they wrote the code 20 years ago and every function they use is banned now. Has it been updated?  Of course not.
     I did this quick, let's look at the band functions and see how often we're going to see these things.  So here is just a couple of those.  Store copy shows up 333 times.  These are all jump and link register and MIHs call.  These are just what I call jailers.  Just jailers.
     409.  310.  Print out which is not always exploit able to say the least.  But the variants of print out, 11,685 calls.  So I'm doing that, right.  Then I started to cross reference them with at least
symbolically debugger symbolically CEC name space and it got way less interesting really quick.  Which was very disappointing but I did find there are three MEN copies two of which I'd already found just by doing reverse engineering and looking at the receive. And looking at receive functions and anything that had RECV in it.  And I found the two copies.  Which as far as I can tell, I can't confirm they're not exploit able.  Because I can't tell anywhere that the size of the copy is limited.  But it may just -- at some point you reach the OS L, the operating system abstraction layer and you, it gets ugly at that point.  I don't have the debugger at this point and I can't look at stuff and see what sizes would be impassed in.
     So the third man copy was not exploit able.  There are 73 print outs and none of them call the system or anything else.
     So you can see or maybe you can't see in the lower right hand corner is where the MEN copies are located. Not exciting overly.  But ...
     So if we can pull off a exploit what can we do? You can enable ATC, I beat that down.  I'm not going to go over that again.  We enable the LAN, we can attack land services possibly and enable higher speed ex-filtration.  Possibly control an NHL device which are getting pretty popular.
     Maybe use it as a beach head for attacking others devices and of course you can hide there like nobody's business.  I don't know of anyone who has ever thought about, hey, maybe they're persisting on this TV or blue ray player.
     So this is some of the things that I'd like to do moving forward.  I'd like to unuglyfy my python because it is pretty awful.  Before I put that out on ZDIs GitHub page, it's embarrassing at the moment.  I'm more of a ruby person.  Would like to integrate it into a bigger better fuzz framework that has more capability and more management and interface et cetera.  Now it's
purely command line.  Ultimately I would like to exploit CEC and at first I would like to bind a shell to the network interface and then moving forward I would like to enable ATC and bind the shell to that interface.  And ideally be able to exploit CEC and bind the shell straight up on CEC so there is no communication over the regular network.
     Also going to be exploring the attack surface of 3D and audio return channel and more with ADC. Especially because 2.0 has quite a few future adds to the CEC capabilities.  And of course more devices. Luckily working at TDI allows us access to a lot of mobile devices and all sorts of whatnot.  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.
     And emulation would be great because 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 the old
[indiscernible] types may be new again.  I do think at least in Samsung's case they're benefiting from the fact that the code is just straight up newer.  It was written probably I don't know, four or five years ago as opposed to 20 years ago.  Hopefully some newer developers have walked in and realized, hey, let's not call sir copy all the time.  Et cetera.
     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, you're vulnerability times your exposure and times your impact, is not super-high.  I'm not going to try to float that to you. But the exposure is definitely growing.  Those devices are becoming, getting everywhere.  The impact is probably highest for your privacy because we're talking about stuff that can film you and all that stuff.
     Here is some links if you want to know more.  The code is not up on ZDI's GitHub yet.  As I said, it's a little awful right now.  HDMI.org is the HDMI consortium or whatever.  They have useful information. If you're interested in what a did the presentation in it's called reveal dot J OS.  And the website that's pretty useful when you're first figuring stuff out is called first CEComatic.  That's kind of a web app that allows you to pick, I want the source to be 4.  And I
want the destination to be broadcast.  What does that message look like and it will figure it out for you. It does the reverse where you can type stuff in and see what it is.
     That's all I have.  ...(applause)... any questions?  Sure?
     >> (question is off mic).
     >> As far as I know no, the CEC protocol has no concept of security at all.
     Yeah.  They definitely keep some information private for HDMI adopters only.  I don't think there is any consideration at all.
     At least not from our type of security perspective.  Sure.
     Any other questions?
     >> (question is off mic).
     >> Local J tag out to USB converter.  I thought about showing it.  But interrupt the boot process, give it your own boot command.  Establishes Telnet on the interface and then with a known root password.
     Any others?
     >> (off mic).
     >> Can you say that again a little louder?  Other than like the protocol management part where you obviously can't stomp on other people when they're talking, there is no other limitation.
     Sir?  Squat so far.  It's flaky enough, like sometimes I connected up and the video would come up for two seconds and go down on its own.  It's a bit of an adventure.
     Thanks very much.  Oops.  Oh I have DBI coin slash bottle opener.  I love you guys.  (off mic).
     Come on up if you want one.  Thank you very much.
...(applause)...