IoT Village - H(ACK)DMI: PWNING HDMI FOR FUN AND PROFIT
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Jeong, Hyejin
" HDMI is used by many display devices as an interface for transmitting high-definition video and audio data. The HDMI usage rate is expected to increase further as many global IT companies such as Samsung, Google, and Apple are joining the HDMI Forum. HDMI is provided for transmitting digital television audiovisual signals from HDMI source device to the HDMI sink device. It delivers not only the audiovisual signal but also controls, status and data information in both directions. Although there is a weakness that HDMI requires a direct line connection, considering the HDMI usage rate of AV devices, the impact of HDMI vulnerability is huge. So we will explain the CEC and DDC protocols that transmit bidirectional data in detail and explain the reason why they are considered as attack vectors. Simply put, CEC protocol is used to control devices connected to HDMI. The DDC protocol is used by the HDMI source device to obtain information about the status and function of the HDMI sink device. In particular, we will talk about the structure of each protocol's messages and how we sent them. After that, we will introduce the fuzzer we made and release the source code of it. There are CEC fuzzer with USB-CEC adapter, DDC fuzzer with our own test cable, and DDC fuzzer of Ubuntu graphics driver. And I will present about the vulnerabilities which we found in the set-top box as a result of our fuzzer, and the crash we got from Windows. If we find something else, we'll disclose it also."
 Hello, I'm Hyejin and thank you for coming here. The topic I will talk about today is HEC DMI, PONING H-DMI for fun and profit. Yes. First of all, my name is Hyejin and I am a vulnerability assessment treatment of B.O.B. which is the next generation cyber security without training program in Korea. And his name is Jung Eun-jin and who is sitting down there. And he's working as a researcher and a company named Theory and he is a mentor at B.O.B. We are both members of the team, Shin Ki-hajin. And actually I was a mentee and he was a mentor. We worked on the topic of vulnerability assessment for H-DMI based embedded device at B.O.B. Our team is made up of two mentors, one PL and five mentees. The table of contents is as follows. First, I'd like to give you a quick introduction about previous talk and one day vulnerabilities about H-DMI. And after that, I'm going to talk about the CEC and DDC protocols that we regard as attack vectors. Finally, I'd like to introduce you to each protocol forger that we've made and tell you about the result. This is the previous talk about H-DMI. Hacking display made interesting at Blackhead Europe and what the HEC at Fofocon and high depth buzzing at Defcon. This is the one day of the H-DMI and it was the vulnerabilities of memory correction type that occurred as CEC and DDC protocols. Now let's talk about the H-DMI protocols. Here I will give you a brief description of the H protocol and the knowledge required to transmit the message or command that each protocol use. If you listen to this part, you will probably be able to send the message to your device that support H-DMI. H-DMI is provided for transmitting digital television, audio visual signals from DVD players, set up box and other audio visual source to the television sets and projectors or other video displays. Maybe even without this explanation, you already used H-DMI to connect your laptop to a TV or a beam projector and also I connected my laptop with H-DMI today. H-DMI has four separate channels. It is TMDS, DDC, CEC and H-EAC. At first looking at the TMDS part of the figure, you can see the video and the audio data on both the input and the output part. TMDS is used to carry audio and video data. The DDC channel is used by an H-DMI source to determine the capabilities or characteristics of the sync by reading the EE-DID data structure. H-DMI source are expected to read the sync EE-DID and to deliver the audio and video formats that are supported by the sync. In addition, H-DMI sync are expected to detect info frames and to process the received audio and video data appropriately. The next one is CEC. CEC channel is optionally used for a higher level user functions such as automatic setup task or task associated with the infrared remote control users. The last one is the H-EAC, which is optionally used as a high speed bi-directional data channel and stands for H-DMI internet and audio return channel. The four protocols mentioned above are mapped from the actual H-DMI piece as follows. TMDS is from one to 12, which is multi yellow and pin 13 is the CEC and pin 14 is the utility line used by the H-EAC. 15 and 16 are SCL, SDA and 17, 18 and 19 are internal ground, VCC and HPD. Here we were interested in functions such as carry controls, status and data information rather than the video data transmission. In addition, the protocol supports the both directions. So today we are going to talk about the CEC and DDC protocols. The first one is CEC. CEC stands for consumer electronics control. You can connect your laptop or smartphone to your TV using H-DMI. Of course it's possible to connect multiple devices as shown in the picture if you have multiple H-DMI cables. And you may want to control each devices. For example, you can adjust the volume of the home theater or change it to TV channel. The CEC protocol allows you to control each devices with single remote control. CEC is a protocol that provides high level control functions between all of the various audio visual products in a user's environment. It provides a number of features designed to enhance the functionality of devices within an H-DMI system. Because CEC provides functions in the user's environment, each manufacturer has a different brand name. So maybe NINEP plus or EZ-Link, EZ-Sync rather than the CEC can be more familiar. And in H-DMI, there are two types of the address. Physical address and logical address. And the address used by the CEC message is the logical address. However, CEC is a protocol based on a bus system. So therefore cannot only ascertain the physical connectivity of the network. So it uses the DGC protocol to allocate physical addresses to devices in the network. All CEC devices therefore have both physical and logical address whereas non-CEC devices only has the physical address. The physical address is four digit long. It seems like the IPv4 address. And it has a five device D-Pyro key. For example, the root device TV has 0, 0, 0, 0, and the connected device on TV have 1, 0, 0, 0 and 2, 0, 0, 0. In addition, the DVD and STV connected to the amplifier become 2, 1, 0, 0 and 2, 2, 0, 0. When a physical address is allocated like this, then allocates a logical address. Logical address defines the device type. For example, TV is 0, a recording device is 1, 2, or 9 depending on the device type. Logical address is allocated through the polling message. First, text the first address and send the polling message. If it is a recording device, it sends a polling message to the first of 1, 2 and 9. Actually, it will be 1. And if polling is acknowledged, it takes the next address. It will be 2. And if not, it stops the procedure and retains the address. That is, its logical address becomes 1. The CEC message frame has this structure. The first is the type to be it, which is followed by the header block and the data blocks. And it is a special bit indicating the start. The header block and the data blocks are each composed of 10 bits, which consists of eight bits of information bits and two bits of the control bits. And the data block is optional block. Information bits and control bits are described in detail in the next slide. First is the header block. The information bits in the header block contain the logical address. The addresses of the initiator and destination are each full bits. And the control bit has the same format for both the header block and the data blocks. The control bit includes the EOM bit and the EC bit. The EOM bit stands for end of message. If the current block is followed by one or more blocks, it becomes zero, and if the current block is the last one, it becomes one. The EC bit stands for technology, which contains the value of the technology of the data or the header blocks. The data block also consists of information bits and control bits. The header block is essential, but the data block is an optional block. The data block has data block one and data block two, where data block one contains the OP code in the information bits, and data block two contains the OP RAND. The OP RAND has a dependency on OP code. If the OP code is three two, which corresponds to the set menu language, the OP RAND will contain the language of what you want to set. Data block one is one block, and data block two can be the multiple blocks depending on the OP code value. However, the maximum message size is 16 blocks. That is the message with the maximum length is one block of header and one block of the data block one, and 14 blocks of the data block two. The second protocol is TDC. TDC stands for Display Data Channel, and it is used by the HDMI source to read the sync EED ID in order to discover the sync configuration and capabilities. We're easily illustrated when you connect the TV and the laptop with the HDMI, the sync TV sends the EED ID data to the source laptop. So what data does the TDC send? It's called EED ID Extended Display Identification Data. The EED ID is a metadata format for display devices to describe their capabilities to a video source such as graphics card or set up box. This format is defined by a standard published by the VESA. However, EED ID is for PC monitors, and EED ID is an extension of the EED ID used to illustrate more advanced features. For example, PC monitors generally did not support audio, so a traditional EED ID structure is not a country this, whereas an EED ID would. Therefore, it sends the EED ID data. The EED ID data consists of the EED ID 1.3 and CA extension. And they have the following structures, because data sent by the folder is also this EED ID data, so we need to know a little bit about the data structure. EED ID 1.3 includes information such as horizontal size, vertical size, and color characteristics. And there is also an extension flag, which means that extension data follows the EED ID structure. And if you are not sure what the EED ID is yet, turn on your laptop. If your laptop is now connected to a TV or a monitor with HDMI, you can probably find the EED ID data in your laptop. On Windows, it is stored in the registry, and on Ubuntu, it can be found in the past since class DRM, and on Mac OS, you can check it through the IO registry. The HDMI transmits EED ID data over the I2C bus. As you know, I2C is a serial computer bus, and it is widely used for attaching lower-speed peripheral ICs to processors and microcontrollers in short distance in troubled communication. I2C uses only two bi-directional open-collector lines, SDA and SCL, pulled up with registers. Typical voltages use 5 or 3.3, although systems with other voltages are permitted. We use Arduino to transmit the EED ID data directly. You can use other things, but you can easily use I2C slave mode with Arduino compared to the Raspberry Pi. You can connect the register and the wire to each pin as shown in the picture. The wires connected to the breadboard is in turn R, SCL, SDA, ground, VCC, and HPD, and each line is connected to the pin that is mapped in the HTT mine. With this connection, the hardware preparation is finished. So far, we have looked at the brief description of the CEC and the DDC protocols and each message. Now, I will use them to create a further. The first is CEC. Any device that supports the CEC can be the target device. For example, smart TV, beam projector, set up box, play, smartphone, and game controllers, and so on. In the case of a smartphone, it is highly likely to purchase an additional adapter. Make sure that the adapter is supported the CEC. And for CEC protocol, whether to support CEC, rather than the type of the device is a more important factor to determining the target. For the CEC further, all you need is a USB CEC adapter and a HDMI cable. We will use a pie serial for serial communication. Now, it's time to send the CEC to the CEC. Now, it's time to send the CEC message directly to the device. There is a USB CEC adapter communication library, which is called LIPC. It can be found in the GitHub. And if you have a USB CEC adapter created by Perse, you can send the CEC message. Of course, other adapters are also supported. And if you are having trouble to buying a new adapter, you can use Raspberry Pi. With LIPC, you can send the CEC message as a book. But this library is so well made that it can be dropped our foreign data. So we will not use this library when forging. Since the adapter shown above is the USB CEC adapter, data can be transferred via the serial communication. Of course, you can use pie serial. You can send the message with just three lines of the code as a verb. This is a comment to power off the setup box. Let's first look at the code that sends messages to the CEC adapter without using the LIPC CEC library. Before that, you've probably seen this picture. When data is transferred using the adapter, one block is represented by full bytes. More precisely, the information bits in a block. This works for both the header block and the data blocks. The full bytes consists of messages type, message code, message value, and message end. The actual data bits are the data bits that the message value contained in the information bit are stored in message value. Message start and message end are the bytes representing the beginning and end of a block, respectively FF and FE. Message code can be thought of as a control bit. Here, the message to be transmitted has a structure of message start, message code, message value, and message end. At this point, you can see that message code is different, which can be found in the LIPC CEC code in CEC adapter message code. For basic message transmission, you need to know about full message codes in your code. In particular, OV and OCR message codes are related to message transmit, and I said that the message code is similar to the control bit. For the EOM bit of the control bit, that is represented by OV and OCR. And the acrobat is also similar. We create a folder for the three parts of the CEC message frame. First is an OP code. Three six was excluded because it is OP code to power off the device. And the second is one is operand. And we randomly selected a value from zero to FF to transmit the operand of 13 blocks. And the header block is fixed to the logical address of the target device. In the case of an OP code, to increase the probability of a crash, we use the list of OP code that are likely to cause vulnerabilities. And finally, the message length. In the case of the CEC protocol, the maximum message size is fixed to 16 blocks. That is 160 bits. In addition, each block is recognized as one block over header block, and on OP code and operands in order. Therefore, data of various message sizes were transmitted, including messages that exceeded the maximum size. Now it is a DDC protocol. The target device is an HDMI source device. Maybe you can probably guess the reason, because the DDC protocol allows the sync device to send the EEDI data to the source device. Therefore, the source device, which is the device that received the data, was targeted. Source device includes desktop, laptops, set up box, and smartphones. And we used the Arduino Mega2560 and transmitted the data via the wire library provided by Arduino. Also, we cut and soldered the HDMI cable for more reliable data transmission. If you cut the HDMI cable, you can get 19 pins and a wire connected to the each pin. And we connected the appropriate registers and wires to the required SCL, SDA, ground, VCC, and HPD locations, and soldered them to make the same cable as the last picture, and then connect each of the five jumper wires to the Arduino. Now, we can transfer the actual data through the wire library, supported by Arduino for communication with I2C devices. The main functions for the data transfer are taking only quest, only ship, read, and write. Note that it uses a 32-byte buffer. Therefore, any communication should be within this limit. Exiting bytes will be just dropped. But we will send the EDI value of 128 bytes. So I modified buffer lengths in the header file to 128 as follows. As a result, EDI data can be transmitted as shown in the picture. On the left is a code written using Arduino IDE, and on the right is the result of sending EDI data to the laptop via Arduino. And it will now send the EDI data. It consists of EDI 1.3 and CA extension. It's the CA861D. At this time, if the value of the Fridt, such as header, padding, and checksum, which are marked in red, are set red, the buzzing effects can be enhanced. We created the data in the above three ways when mutating. First, each structure of EDID, and second, random among the structure that are likely to cause vulnerabilities, and finally, a random value for all data. And one more thing to note here. To follow the HDMI cable, the process of connecting and disconnecting HDMI should be repeated. However, if you have to plug in and out every time you send data, it's very inefficient and it will not be called a further. This is confirmed by the HPD signal. When the file force is applied to the sync TV, the sync sends the HPD high to the source. And then the source sends an EDI request to the sync, and as a result, the sync sends the EDI to the source. So we repeatedly send low and high to HPD pin, giving the same effect as connecting and disconnecting HDMI. Now, let me tell you about the results we have obtained through our further. First, if you look at the CEC protocol in the main copy function, you can see a 1 byte stack overflow resulting in a memory leak. In closer look, the top part of the right function is the CEC message value we sent. And we can see that the on-transject function in live HDMI CEC contains the header and data blocks we sent. And the read into 32 and read C string functions are just that part. If you look at the on-event update function in live HDMI CEC JNI, copy it to V8 using the value received above. At this time, a 1 byte overflow occurs. And the following is the DDC, and you can see that the counterpanics then fails to reboot when you send the EDI data. Also, we can see that the value is modified to 6-1 that we sent. In fact, we want more influential results. But, buzzing with the real HDMI cable creates a problem of stability and speed. At the time, we thought that the graphics driver vulnerability is highly influential. So, we made a graphics driver for HDMI on Ubuntu. So, I'd like to briefly introduce the Ubuntu DDC for that we made. The process of creating this for can be summarized in four main steps. First, with this code editing, I found a part that has HDMI EDI data. We confirmed that the EDI data is stored in the second parameter of the DRM-DU-Proof-DDC-EDID function, which is named BUFF, after calling this function. The second is hooking with K-Proofs. The K-Proofs is debugging mechanism for the Linux kernel. It enables you to dynamically hook into the kernel and allows you to do various actions through the callback function. The following source code is a basic example. In ADDR field of K-Proof struct, you can set the address of function to break. And you can set with the symbol using the symbol name and offset field instead of the ADDR field. When the break point, what you set in the address field is hit, K-Proof code pre-handler, and after that instruction is executed, it calls the post handler. Each handler's second parameter, which names, likes, it's pointing to the structure containing the registers saved when the break point was hit. So you can counter the register value with it. Actually, we want to break when a function returns, so we use the return proofs. It's the other type of proofs and also called K-Lab proofs. And maybe K or Sims could be helpful for you to get all connection booths. And anyway, the code is similar to the K-Proofs. In the entry handler, we have saved the address of the buffer where the EDID data is stored. And before returning, the days after the EDID data is stored, we modified its value by accessing that address. In fact, we did not read or write the return value at RT handler, but instead changed the EDID value at the point of return. Now, we can mutate the EDID data, but there is one more problem to be solved here. That is calling this function interactively as if we had repeatedly send HPD signal at the Arduino for the part. I thought that using X-Render will solve this problem easily. X-Render is used to set the size, orientation, and reflection of the outputs for a screen. So we thought that EDID related functions would be triggered. However, when I used X-Render to create a fuzzle, I got too much noise. So we needed another way and we checked the code stack. There are various tools to trace the code stack and we used ftrace. ftrace is an internal tracer designed to help our developers and designers of these terms to find what is going on inside the kernel. The files for using ftrace are in the path, cscunner, debug tracing, and there are several types of the tracers. The types are defined in the file available tracers, and the traceable function list is in the file available filter functions. Trace results are stored in the file trace. First, we set the options to check the code stack of DRM-Duproof-DDC-EDID as shown in the multiple echo comments. And this will give you the result shown in the picture. The result shows that this function is called from the IOC-TL, and I checked the source code for DRM-IOC-TL, and it would get connected. Now, the final step is to call this one. And this is the libDRM-UserSpice library for accessing the DRM on Linux that supports the IOC-TL interface. And you can see the code for DRM would get connected in this library. So we used it to call this function. As a result, we were able to complete the puzzle. The presentation software can be summarized in these pictures of two protocols and each protocol for this. And it is our future work, and source and images are as follows. Thank you for listening to this software. If you have any questions, please send me an email. Thank you so much.
 Hello, I'm Hyejin and thank you for coming here.  The topic I will talk about today is HEC DMI,  PONING H-DMI for fun and profit.  Yes.  First of all, my name is Hyejin and I am a vulnerability  assessment treatment of B.O.B.  which is the next generation cyber security  without training program in Korea.  And his name is Jung Eun-jin and who is sitting down there.  And he's working as a researcher and a company named  Theory and he is a mentor at B.O.B.  We are both members of the team, Shin Ki-hajin.  And actually I was a mentee and he was a mentor.  We worked on the topic of vulnerability assessment  for H-DMI based embedded device at B.O.B.  Our team is made up of two mentors,  one PL and five mentees.  The table of contents is as follows.  First, I'd like to give you a quick introduction  about previous talk and one day vulnerabilities about H-DMI.  And after that, I'm going to talk about the CEC  and DDC protocols that we regard as attack vectors.  Finally, I'd like to introduce you to each protocol  forger that we've made and tell you about the result.  This is the previous talk about H-DMI.  Hacking display made interesting at Blackhead Europe  and what the HEC at Fofocon and high depth buzzing at Defcon.  This is the one day of the H-DMI  and it was the vulnerabilities of memory correction type  that occurred as CEC and DDC protocols.  Now let's talk about the H-DMI protocols.  Here I will give you a brief description  of the H protocol and the knowledge required  to transmit the message or command that each protocol use.  If you listen to this part,  you will probably be able to send the message  to your device that support H-DMI.  H-DMI is provided for transmitting digital television,  audio visual signals from DVD players,  set up box and other audio visual source  to the television sets and projectors  or other video displays.  Maybe even without this explanation,  you already used H-DMI to connect your laptop  to a TV or a beam projector  and also I connected my laptop with H-DMI today.  H-DMI has four separate channels.  It is TMDS, DDC, CEC and H-EAC.  At first looking at the TMDS part of the figure,  you can see the video and the audio data  on both the input and the output part.  TMDS is used to carry audio and video data.  The DDC channel is used by an H-DMI source  to determine the capabilities or characteristics of the sync  by reading the EE-DID data structure.  H-DMI source are expected to read the sync EE-DID  and to deliver the audio and video formats  that are supported by the sync.  In addition, H-DMI sync are expected to detect info frames  and to process the received audio and video data appropriately.  The next one is CEC.  CEC channel is optionally used  for a higher level user functions  such as automatic setup task  or task associated with the infrared remote control users.  The last one is the H-EAC,  which is optionally used as a high speed  bi-directional data channel  and stands for H-DMI internet and audio return channel.  The four protocols mentioned above  are mapped from the actual H-DMI piece as follows.  TMDS is from one to 12, which is multi yellow  and pin 13 is the CEC and pin 14 is the utility line  used by the H-EAC.  15 and 16 are SCL, SDA and 17, 18 and 19 are  internal ground, VCC and HPD.  Here we were interested in functions  such as carry controls, status and data information  rather than the video data transmission.  In addition, the protocol supports the both directions.  So today we are going to talk about the CEC  and DDC protocols.  The first one is CEC.  CEC stands for consumer electronics control.  You can connect your laptop or smartphone  to your TV using H-DMI.  Of course it's possible to connect multiple devices  as shown in the picture if you have multiple H-DMI cables.  And you may want to control each devices.  For example, you can adjust the volume of the home theater  or change it to TV channel.  The CEC protocol allows you to control each devices  with single remote control.  CEC is a protocol that provides high level control functions  between all of the various audio visual products  in a user's environment.  It provides a number of features designed  to enhance the functionality of devices  within an H-DMI system.  Because CEC provides functions in the user's environment,  each manufacturer has a different brand name.  So maybe NINEP plus or EZ-Link, EZ-Sync  rather than the CEC can be more familiar.  And in H-DMI, there are two types of the address.  Physical address and logical address.  And the address used by the CEC message is the logical address.  However, CEC is a protocol based on a bus system.  So therefore cannot only ascertain  the physical connectivity of the network.  So it uses the DGC protocol to allocate physical addresses  to devices in the network.  All CEC devices therefore have both physical  and logical address whereas non-CEC devices  only has the physical address.  The physical address is four digit long.  It seems like the IPv4 address.  And it has a five device D-Pyro key.  For example, the root device TV has 0, 0, 0, 0,  and the connected device on TV have 1, 0, 0, 0  and 2, 0, 0, 0.  In addition, the DVD and STV connected to the amplifier  become 2, 1, 0, 0 and 2, 2, 0, 0.  When a physical address is allocated like this,  then allocates a logical address.  Logical address defines the device type.  For example, TV is 0, a recording device is 1, 2, or 9  depending on the device type.  Logical address is allocated through the polling message.  First, text the first address and send the polling message.  If it is a recording device, it sends a polling message  to the first of 1, 2 and 9.  Actually, it will be 1.  And if polling is acknowledged, it takes the next address.  It will be 2.  And if not, it stops the procedure and retains the address.  That is, its logical address becomes 1.  The CEC message frame has this structure.  The first is the type to be it, which is followed  by the header block and the data blocks.  And it is a special bit indicating the start.  The header block and the data blocks are each composed  of 10 bits, which consists of eight bits  of information bits and two bits of the control bits.  And the data block is optional block.  Information bits and control bits are described  in detail in the next slide.  First is the header block.  The information bits in the header block  contain the logical address.  The addresses of the initiator and destination  are each full bits.  And the control bit has the same format  for both the header block and the data blocks.  The control bit includes the EOM bit and the EC bit.  The EOM bit stands for end of message.  If the current block is followed by one or more blocks,  it becomes zero, and if the current block  is the last one, it becomes one.  The EC bit stands for technology,  which contains the value of the technology  of the data or the header blocks.  The data block also consists of information bits  and control bits.  The header block is essential,  but the data block is an optional block.  The data block has data block one and data block two,  where data block one contains the OP code  in the information bits,  and data block two contains the OP RAND.  The OP RAND has a dependency on OP code.  If the OP code is three two,  which corresponds to the set menu language,  the OP RAND will contain the language  of what you want to set.  Data block one is one block,  and data block two can be the multiple blocks  depending on the OP code value.  However, the maximum message size is 16 blocks.  That is the message with the maximum length  is one block of header and one block of the data block one,  and 14 blocks of the data block two.  The second protocol is TDC.  TDC stands for Display Data Channel,  and it is used by the HDMI source  to read the sync EED ID  in order to discover the sync configuration  and capabilities.  We're easily illustrated when you connect the TV  and the laptop with the HDMI,  the sync TV sends the EED ID data to the source laptop.  So what data does the TDC send?  It's called EED ID Extended Display Identification Data.  The EED ID is a metadata format for display devices  to describe their capabilities to a video source  such as graphics card or set up box.  This format is defined by a standard  published by the VESA.  However, EED ID is for PC monitors,  and EED ID is an extension of the EED ID  used to illustrate more advanced features.  For example, PC monitors generally did not support audio,  so a traditional EED ID structure  is not a country this, whereas an EED ID would.  Therefore, it sends the EED ID data.  The EED ID data consists of the EED ID 1.3 and CA extension.  And they have the following structures,  because data sent by the folder is also this EED ID data,  so we need to know a little bit about the data structure.  EED ID 1.3 includes information such as horizontal size,  vertical size, and color characteristics.  And there is also an extension flag,  which means that extension data follows the EED ID structure.  And if you are not sure what the EED ID is yet,  turn on your laptop.  If your laptop is now connected to a TV  or a monitor with HDMI,  you can probably find the EED ID data in your laptop.  On Windows, it is stored in the registry,  and on Ubuntu, it can be found in the past  since class DRM, and on Mac OS,  you can check it through the IO registry.  The HDMI transmits EED ID data over the I2C bus.  As you know, I2C is a serial computer bus,  and it is widely used for attaching lower-speed  peripheral ICs to processors and microcontrollers  in short distance in troubled communication.  I2C uses only two bi-directional open-collector lines,  SDA and SCL, pulled up with registers.  Typical voltages use 5 or 3.3,  although systems with other voltages are permitted.  We use Arduino to transmit the EED ID data directly.  You can use other things,  but you can easily use I2C slave mode with Arduino  compared to the Raspberry Pi.  You can connect the register and the wire  to each pin as shown in the picture.  The wires connected to the breadboard  is in turn R, SCL, SDA, ground, VCC, and HPD,  and each line is connected to the pin  that is mapped in the HTT mine.  With this connection, the hardware preparation is finished.  So far, we have looked at the brief description  of the CEC and the DDC protocols and each message.  Now, I will use them to create a further.  The first is CEC.  Any device that supports the CEC  can be the target device.  For example, smart TV, beam projector, set up box,  play, smartphone, and game controllers, and so on.  In the case of a smartphone,  it is highly likely to purchase an additional adapter.  Make sure that the adapter is supported the CEC.  And for CEC protocol, whether to support CEC,  rather than the type of the device is a more important factor  to determining the target.  For the CEC further, all you need is a USB CEC adapter  and a HDMI cable.  We will use a pie serial for serial communication.  Now, it's time to send the CEC to the CEC.  Now, it's time to send the CEC message directly to the device.  There is a USB CEC adapter communication library,  which is called LIPC.  It can be found in the GitHub.  And if you have a USB CEC adapter created by Perse,  you can send the CEC message.  Of course, other adapters are also supported.  And if you are having trouble to buying a new adapter,  you can use Raspberry Pi.  With LIPC, you can send the CEC message as a book.  But this library is so well made  that it can be dropped our foreign data.  So we will not use this library when forging.  Since the adapter shown above is the USB CEC adapter,  data can be transferred via the serial communication.  Of course, you can use pie serial.  You can send the message with just three lines  of the code as a verb.  This is a comment to power off the setup box.  Let's first look at the code that sends messages  to the CEC adapter without using the LIPC CEC library.  Before that, you've probably seen this picture.  When data is transferred using the adapter,  one block is represented by full bytes.  More precisely, the information bits in a block.  This works for both the header block and the data blocks.  The full bytes consists of messages type,  message code, message value, and message end.  The actual data bits are the data bits  that the message value contained in the information bit  are stored in message value.  Message start and message end are the bytes  representing the beginning and end of a block,  respectively FF and FE.  Message code can be thought of as a control bit.  Here, the message to be transmitted has a structure  of message start, message code, message value,  and message end.  At this point, you can see that message code is different,  which can be found in the LIPC CEC code  in CEC adapter message code.  For basic message transmission,  you need to know about full message codes in your code.  In particular, OV and OCR message codes  are related to message transmit,  and I said that the message code is similar to the control bit.  For the EOM bit of the control bit,  that is represented by OV and OCR.  And the acrobat is also similar.  We create a folder for the three parts  of the CEC message frame.  First is an OP code.  Three six was excluded because it is OP code  to power off the device.  And the second is one is operand.  And we randomly selected a value from zero to FF  to transmit the operand of 13 blocks.  And the header block is fixed to the logical address  of the target device.  In the case of an OP code,  to increase the probability of a crash,  we use the list of OP code  that are likely to cause vulnerabilities.  And finally, the message length.  In the case of the CEC protocol,  the maximum message size is fixed to 16 blocks.  That is 160 bits.  In addition, each block is recognized  as one block over header block,  and on OP code and operands in order.  Therefore, data of various message sizes were transmitted,  including messages that exceeded the maximum size.  Now it is a DDC protocol.  The target device is an HDMI source device.  Maybe you can probably guess the reason,  because the DDC protocol allows the sync device  to send the EEDI data to the source device.  Therefore, the source device,  which is the device that received the data, was targeted.  Source device includes desktop, laptops,  set up box, and smartphones.  And we used the Arduino Mega2560  and transmitted the data via the wire library  provided by Arduino.  Also, we cut and soldered the HDMI cable  for more reliable data transmission.  If you cut the HDMI cable,  you can get 19 pins and a wire connected to the each pin.  And we connected the appropriate registers and wires  to the required SCL, SDA, ground, VCC, and HPD locations,  and soldered them to make the same cable as the last picture,  and then connect each of the five jumper wires to the Arduino.  Now, we can transfer the actual data  through the wire library,  supported by Arduino for communication with I2C devices.  The main functions for the data transfer  are taking only quest, only ship, read, and write.  Note that it uses a 32-byte buffer.  Therefore, any communication should be within this limit.  Exiting bytes will be just dropped.  But we will send the EDI value of 128 bytes.  So I modified buffer lengths in the header file to 128 as follows.  As a result, EDI data can be transmitted as shown in the picture.  On the left is a code written using Arduino IDE,  and on the right is the result of sending EDI data  to the laptop via Arduino.  And it will now send the EDI data.  It consists of EDI 1.3 and CA extension.  It's the CA861D.  At this time, if the value of the Fridt, such as header, padding,  and checksum, which are marked in red, are set red,  the buzzing effects can be enhanced.  We created the data in the above three ways when mutating.  First, each structure of EDID,  and second, random among the structure that are likely to cause vulnerabilities,  and finally, a random value for all data.  And one more thing to note here.  To follow the HDMI cable,  the process of connecting and disconnecting HDMI should be repeated.  However, if you have to plug in and out every time you send data,  it's very inefficient and it will not be called a further.  This is confirmed by the HPD signal.  When the file force is applied to the sync TV,  the sync sends the HPD high to the source.  And then the source sends an EDI request to the sync,  and as a result, the sync sends the EDI to the source.  So we repeatedly send low and high to HPD pin,  giving the same effect as connecting and disconnecting HDMI.  Now, let me tell you about the results we have obtained through our further.  First, if you look at the CEC protocol in the main copy function,  you can see a 1 byte stack overflow resulting in a memory leak.  In closer look, the top part of the right function is the CEC message value we sent.  And we can see that the on-transject function in live HDMI CEC  contains the header and data blocks we sent.  And the read into 32 and read C string functions are just that part.  If you look at the on-event update function in live HDMI CEC JNI,  copy it to V8 using the value received above.  At this time, a 1 byte overflow occurs.  And the following is the DDC,  and you can see that the counterpanics then fails to reboot  when you send the EDI data.  Also, we can see that the value is modified to 6-1 that we sent.  In fact, we want more influential results.  But, buzzing with the real HDMI cable creates a problem of stability and speed.  At the time, we thought that the graphics driver vulnerability is highly influential.  So, we made a graphics driver for HDMI on Ubuntu.  So, I'd like to briefly introduce the Ubuntu DDC for that we made.  The process of creating this for can be summarized in four main steps.  First, with this code editing, I found a part that has HDMI EDI data.  We confirmed that the EDI data is stored in the second parameter  of the DRM-DU-Proof-DDC-EDID function, which is named BUFF, after calling this function.  The second is hooking with K-Proofs.  The K-Proofs is debugging mechanism for the Linux kernel.  It enables you to dynamically hook into the kernel  and allows you to do various actions through the callback function.  The following source code is a basic example.  In ADDR field of K-Proof struct, you can set the address of function to break.  And you can set with the symbol using the symbol name and offset field instead of the ADDR field.  When the break point, what you set in the address field is hit,  K-Proof code pre-handler, and after that instruction is executed, it calls the post handler.  Each handler's second parameter, which names, likes,  it's pointing to the structure containing the registers saved when the break point was hit.  So you can counter the register value with it.  Actually, we want to break when a function returns, so we use the return proofs.  It's the other type of proofs and also called K-Lab proofs.  And maybe K or Sims could be helpful for you to get all connection booths.  And anyway, the code is similar to the K-Proofs.  In the entry handler, we have saved the address of the buffer where the EDID data is stored.  And before returning, the days after the EDID data is stored,  we modified its value by accessing that address.  In fact, we did not read or write the return value at RT handler,  but instead changed the EDID value at the point of return.  Now, we can mutate the EDID data,  but there is one more problem to be solved here.  That is calling this function interactively as if we had repeatedly send HPD signal at the Arduino for the part.  I thought that using X-Render will solve this problem easily.  X-Render is used to set the size, orientation, and reflection of the outputs for a screen.  So we thought that EDID related functions would be triggered.  However, when I used X-Render to create a fuzzle, I got too much noise.  So we needed another way and we checked the code stack.  There are various tools to trace the code stack and we used ftrace.  ftrace is an internal tracer designed to help our developers and designers of these terms  to find what is going on inside the kernel.  The files for using ftrace are in the path,  cscunner, debug tracing, and there are several types of the tracers.  The types are defined in the file available tracers,  and the traceable function list is in the file available filter functions.  Trace results are stored in the file trace.  First, we set the options to check the code stack of DRM-Duproof-DDC-EDID  as shown in the multiple echo comments.  And this will give you the result shown in the picture.  The result shows that this function is called from the IOC-TL,  and I checked the source code for DRM-IOC-TL, and it would get connected.  Now, the final step is to call this one.  And this is the libDRM-UserSpice library for accessing the DRM on Linux  that supports the IOC-TL interface.  And you can see the code for DRM would get connected in this library.  So we used it to call this function.  As a result, we were able to complete the puzzle.  The presentation software can be summarized in these pictures of two protocols  and each protocol for this.  And it is our future work, and source and images are as follows.  Thank you for listening to this software.  If you have any questions, please send me an email.  Thank you so much.
Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_0_311.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_312_1127.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_1128_1715.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_1716_2495.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_2496_2867.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_2868_3215.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_3216_3275.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_3276_3335.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_3336_3395.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_3396_3503.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_3504_3803.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_3804_3899.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_3900_7295.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_7296_8771.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_8772_9923.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_9924_10907.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_10908_13139.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_13140_14447.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_14448_15491.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_15492_16847.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_16848_18527.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_18528_19343.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_19344_19559.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_19560_21047.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_21048_21851.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_21852_22691.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_22692_23747.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_23748_24839.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_24840_25223.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_25224_26243.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_26244_26627.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_26628_27503.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_27504_28511.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_28512_28871.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_28872_30143.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_30144_31415.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_31416_33323.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_33324_34187.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_34188_34667.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_34668_34919.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_34920_35543.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_35544_36083.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_36084_36767.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_36768_37247.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_37248_37883.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_37884_38411.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_38412_39587.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_39588_39887.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_39888_40055.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_40056_40367.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_40368_41363.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_41364_41771.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_41772_42455.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_42456_43331.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_43332_45095.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_45096_46955.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_46956_48035.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_48036_48779.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_48780_49559.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_49560_50255.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_50256_50531.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_50532_50663.png Hyejin_Jeong_-_HACK_DMI_PWNING_HDMI_FOR_FUN_AND_PR_kDlA3hVB9Os_50664_50977.png