This increases the attack surface, and since the security of their implement in embedded devices is far from ideal, an attacker could exploit them and inject malicious code.
It is based on the research of Pierre-Michel Ricordel and José Lopes Esteves from ANSSI/SDE/ST/LSF presented at the IT security conference [SSTIC 2021](https://sstic.org/2021/presentation/un_pare_feu_pour_le_hdmi/).
Some security research and vulnerabilities around CEC and EDID are listed in [slide 4](https://www.sstic.org/media/SSTIC2021/SSTIC-actes/un_pare_feu_pour_le_hdmi/SSTIC2021-Slides-un_pare_feu_pour_le_hdmi-lopes-esteves_ricordel.pdf).
1. when connecting the device back in, you should see the same name as the monitor, with a '|' at the end, indicating you are using the EDID from the firewall
- 5V: some monitors require this line to detect when a device is plugged in, and since currently no other information is transferred over this line, it is rather safe to enable it
- Display Data Channel (DDC): High-bandwidth Digital Content Protection (HDCP) uses this interface. To enable it, switch SDA and SCL on. Warning: since the EDID is also transferred over this interface, the firewall can't provide a write-protected copy of it. Instead the original monitor EDID is used, maybe not write-protected.
- Consumer Electronics Control (CEC): this interface allows to remotely control equipment, such as setting the volume and powering on/off all connected devices and monitors at once
- HDMI Ethernet Channel (HEC), Audio Return Channel (ARC), and Mobile High-Definition Link (MHL): to enable these interfaces, switch UTIL and HPD on to forward the HEAC+ and HEAC- lines
The HDMI firewall can also be used to provide custom EDID, as it sometimes is faulty in the monitor.
For that you need to program the raw binary EDID (with up to 1 extension block) onto the STM8S103 EEPROM using the RST and SWIM lines made available on the back of the board.
The firmware and sources for the HDMI firewall embedded programmer are available [here](https://git.cuvoodoo.info/kingkevin/stm8s/src/branch/hdmi_firewall).
If the monitor does not detect the device or does not display anything (but should), try to re-enable the 5V forward (as per default) by switching the 5V/1 switch to ALLOW/ON.
It is possible to write custom EDID on the HDMI firewall, for example because:
- the monitor's original EDID is corrupted
- you want to disable a feature or resolution causing your device to misbehave
- you want to re-enable a feature the monitor actually supports
- the KVM switch does not reflect the HDMI monitor change
- you want to do security research
For that you can use the debugging pins left on the board, and [program](https://git.cuvoodoo.info/kingkevin/stm8s/src/branch/hdmi_firewall/README.md) the raw EDID in the STM8S EEPROM area using an ST-LINK/V2 programmer.
If you switch EDID to the ALLOW position, the HDMI firewall's EEPROM is not write-protected (on devices shipped after 2022-08-19).
This allows to use the HDMI connection to write the EEPROM content using the DDC's I²C bus, and does not required an external programmer.
These instructions are for Linux.
For Windows see the instructions provided in the [original research slides](https://www.sstic.org/media/SSTIC2021/SSTIC-actes/un_pare_feu_pour_le_hdmi/SSTIC2021-Slides-un_pare_feu_pour_le_hdmi-lopes-esteves_ricordel.pdf) (untested).
Install tools to read/write I²C devices:
- for Debian-based distributions
~~~
sudo apt install i2c-tools
~~~
Make the I²C buses user accessible (under /dev/i2c-*):
~~~
sudo modprobe i2c-dev
~~~
Now we have to figure out which I²C bus corresponds to the HDMI port.
First list the available buses:
~~~
sudo i2cdetect -l
~~~
You should see something like this:
~~~
i2c-0 smbus SMBus PIIX4 adapter port 0 at 0b00 SMBus adapter
i2c-1 smbus SMBus PIIX4 adapter port 2 at 0b00 SMBus adapter
i2c-2 smbus SMBus PIIX4 adapter port 1 at 0b20 SMBus adapter
i2c-3 i2c AMDGPU DM i2c hw bus 0 I2C adapter
i2c-4 i2c AMDGPU DM i2c hw bus 1 I2C adapter
i2c-5 i2c AMDGPU DM i2c hw bus 2 I2C adapter
i2c-6 i2c AMDGPU DM i2c hw bus 3 I2C adapter
i2c-7 i2c AMDGPU DM aux hw bus 0 I2C adapter
i2c-8 i2c AMDGPU DM aux hw bus 2 I2C adapter
i2c-9 i2c AMDGPU DM aux hw bus 3 I2C adapter
i2c-10 i2c DPMST I2C adapter
i2c-11 i2c DPMST I2C adapter
~~~
Candidate buses are 3 to 9, used by the GPU (number after i2c- in the first column).
Disconnect everything from the HDMI port, and scan for devices on each I²C bus (replace BUS with the bus number):
~~~
sudo i2cdetect -y BUS
~~~
Since nothing is connected, no device should be detected, and the output should look like this:
Write your custom EDID data `edid.bin` to the HDMI firewall (replace BUS with corresponding bus number):
~~~
for addr in `seq 0 255`; do echo $addr; sudo i2cset -y BUS 0x50 $addr 0x`xxd -p -l 1 -s $addr edid.bin`; done
~~~
To verify the data has been written correctly, compare original data with the one on the EEPROM:
~~~
# display original dumped data
xxd -g 1 edid.bin
# display data written on EEPROM
sudo i2cdump -y BUS 0x50
~~~
Once writing the EDID to the HDMI firewall memory succeeded:
- re-enable write protection by toggling the EDID switch to the BLOCK position
- re-plug the HDMI firewall for the device to retrieve the newly written EDID
To read and play with EDID under Linux, you can use the tips provided for the previous [HDMI firewall v1](https://git.cuvoodoo.info/kingkevin/board/src/tag/hdmi_firewall_v1/README.md).
