HDMI Firewall
git.cuvoodoo.info
git.cuvoodoo.info
Before finding a way to use DDC on Apple Silicon [1] for Lunar (https://lunar.fyi), I contemplated creating a universal DDC/CI device that can change brightness, contrast, volume, input and colors of a monitor, by either receiving commands through HTTP, or acting as an Adaptive Brightness standalone device.
In my mind, it would have been an HDMI dongle with an ESP32 that gets power through the 5V line of the HDMI port, and which has an ambient light sensor to adapt brightness by itself.
In the end, I found the I2C APIs on M1 so this was not so sorely needed anymore, but given the limitations of the M1 Display Coprocessor, I still think it might be a good idea. I just have no idea where would I start with hardware distribution and mass production, this domain seems so intangible from the software development side.
[1] https://alinpanaitiu.com/blog/journey-to-ddc-on-m1-macs/
It has a time schedule feature, and my hacky-but-functional setup is to have it reduce the brightness a bit every 30 minutes between 5:30 and 9pm -- on my setup it goes 80% to 20%. I have it reset back to 80% before I start using it in the morning.
Fortunately there’s an open source alternative called TwinkleTray: https://github.com/xanderfrangos/twinkle-tray
Someone determined enough could add adaptive brightness to it. You can even use Lunar’s wireless ambient light sensor [1] for that as it’s simply sending lux values through Server Sent Events [2]
Sadly it is no longer hosted by the company where the developer worked. I mailed them, asking where the dev went or if they could put me in contact with him so he could release the source code. Regretfully I never got a response.
How did you learn about all this? Would you be kind enough to go into more depth? I’m curious.
Your comments also gave me my daily reminder of how little I know (in the best way)
So computer monitors have support for a communication protocol called Display Data Channel which is normally used by the host (Mac, PC) to get info about supported resolutions, frame rates, signal timing etc.
On top of that, a command interface has been created called MCCS or Monitor Control Command Set [1] which allows changing brightness, volume, input and a ton of other aspects of the monitor, by sending specific bytes through the cable. That cable can be HDMI, DisplayPort, Thunderbolt, VGA, DVI. It doesn’t matter, as long as it has dedicated wires to carry the I2C signal.
I2C is the 2-wire communication protocol used by DDC, and it basically defines things like “a pulse of 5V (volts) of x milliseconds followed by 0V of y milliseconds means the 0 bit. The 1 bit is represented by a pulse of 5V of 2x milliseconds”. It’s a bit more complex than that, also defining TCP-like features with data frames and ACK packets, but you get the idea. It’s something that both devices agree on so that they can send raw bytes using 5 volt pulses.
I’ve created Lunar as an adaptive brightness app for macOS after finding out about a little CLI called ddcctl: https://github.com/kfix/ddcctl
That’s where I learned how DDC packets look like, where to place the payload (brightness value between 0 and 100, input ID, etc) and how to write that to the monitor using the macOS I2C APIs.
When Apple Silicon came out, none of that was possible anymore so I had to go looking around kernel assembly and private macOS frameworks for “the Apple Silicon way” of writing data through I2C.
If you’re also curious how I learned that, it’s a very cool domain called “reverse engineering” and I learned it while working as a Malware Researcher at Bitdefender. A bit hard to get started, but so many gems to discover once you know how to open binaries in IDA/Hopper and look around their disassembled code.
Both of the monitors on my desk have ESP32 based HDMI dongles plugged into a spare HDMI port. I have 2 USB 3.0 switches that have been retrofitted with ESP32s as well, one for my keyboard and mouse, and one for a hub on my desk. A short press of the button on the switch on my desk will switch my keyboard/mouse between my desktop and a thunderbolt 4 dock, which will then trigger both of the monitors to switch the the inputs that are also connected to the dock. A long press of the button will do the same, but will also switch the secondary hub over (speakers, mic, webcam, and a few free ports for flash drives and the like).
I was looking for an alternative option to an expensive KVM that would do the job I needed. As a 'poor man's KVM' it works pretty well, though I do hope to flesh out the rest of DDC/CI to get some of these other features implemented as well.
The HDMI dongle repo is still private, and I really want to do some cleanup before making it public. But, as for parts, I just used a breakout off amazon, and some cheap perfboard to make a hat containing the ESP32.
USB Switch Repo: https://github.com/byt3swap/mqtt_usb_switch
HDMI Breakout: https://www.amazon.com/gp/product/B075Q83W5F
Or did you end up coding your own raw I2C implementation?
A lot of what was available seemed to be Arduino based with Arduino specific calls in the libraries. I'm using standard ESP32 libs/build system and am trying to keep this one generic.
I hope I’m not stepping over the line, but if it’s not already open source, would you be willing to send me a source code tarball? I’d love to prototype a DIY solution with it for the people having trouble with DDC on DisplayLink connected monitors.
My email is on my HN user page in the About section.
I maybe could have been clearer on this, but the DDC dongle I made isn't using this library, just hardcoded i2c calls for input switching. I started working on the library to eventually integrate with that dongle, but I'm still using the 'hacky' firmware on the dongles hooked to my monitors.
I even use it for the network-based DDC in Lunar through a Raspberry Pi when wire-DDC from the Mac is not available: https://alinpanaitiu.com/blog/journey-to-ddc-on-m1-macs/#the...
Well it kinda is up to the monitor. Given how many monitors don’t implement the DDC/CI standard correctly and flash and crash and blackout on simple brightness change commands, it would turn into a PR nightmare at the scale of an operating system.
I’m overwhelmed by the daily support I have to provide for Lunar users and I barely have 20k users. I can’t even imagine how bad it would be if 100k users started having their monitor crash or lose color on “such a simple thing as changing brightness”.
However, I have non-Apple displays as well. Just tried https://lunar.fyi/ via usbc and it worked great so far!
And that’s only possible because Apple implements a proprietary USB protocol inside their monitors for changing brightness so they have smooth transitions and be sure it works every time.
I’m pretty sure they’ll never touch DDC/CI for that, and rightfully so as it has very spotty support, especially with these new Thunderbolt hubs/adapters and smart monitors.
I’m glad Lunar works for you!
I personally blame Apple for not supporting CEC. I have over 19 apps running in the background to “fix” macOS.
https://extensions.gnome.org/extension/2645/brightness-contr...
Edit: The monitor is connected via USB-C. Haven't tried with using my Macs HDMI port.
https://www.dell.com/en-nz/shop/dell-ultrasharp-43-4k-usb-c-...
Because even with Lunar I couldn't make it control my monitor. A nuisance, actually.
And could a hypothetical Asahi Linux make it work?
These HDMI ports use an internal MCDP29xx chip to convert the HDMI signal to DisplayPort. That chip supports DDC, but the method we use to write the DDC commands to the monitor (IOAVServiceWriteI2C) fails when used through it.
There are other WriteI2C methods specifically for this chip inside the DCPAVFamilyProxy.kext but they’re not available to be used inside an app like Lunar.
> Lunar can't be built from this repo yet as the source code for the paid features is hidden.
All the work on MC after Apple Silicon is done by a previous Lunar user (@waydabber) which I helped for months on Discord until he got the implementation right, and then eventually got to do his own paid implementation called BetterDisplay.
Lunar is my full time job, I can’t have it fully open source and still earn money from it. I would still be working at some corp on gluing web APIs if I hadn’t done this.
I had a quick look to your website at in all fairness, it's pretty clear that the product is proprietary and paid (at least it doesn't claim "the de facto open source app to ...").
In your comparison table I would suggest to put at least a yellow tick (rather than the green one currently) in the open source line though, because that is slightly misleading.
The free parts of the app are fully open source with an MIT license, you’re free to modify it and add mocks for the paid parts. It’s gonna be hard, but infinitely easier than having to rewrite such an app from scratch.
For me, the source code is there and open, call it whatever you want, they’re just vague terms anyway. I’m gonna keep calling it open source.
No, but, the actual code clearly is compilable (because you've compiled it). So this is only part of the code. So it's partially open source. So it shouldn't have a green tick and you shouldn't call it "open source".
But whatever, since all I've had is attacks and flat out stealing from the "open source community", I'll only release closed source binaries from now on so that I'm staying away as much as possible from this drama.
I'm not gaining anything from calling it "open source", it's just what regular people understand easier than "source available" or "semi-closed source" or however OSS people would like to call it just for the sake of pertaining to an arbitrary Open Source Definition like it's the law.
Lunar started as open source until v4 and Lunar v3 is still in the lunar3 branch, as compilable and usable and open as it ever was. I wanted to contribute my knowledge just how I got help from reading and using part of the ddcctl source code.
And people did profit from that: all current M1 DDC solutions (MonitorControl, DisplayBuddy, m1ddc and BetterDisplay) are based on my code from the DDC.c and DDC.swift files. I've created competitors for the only business that's keeping me afloat financially, so I'm definitely not liking when people attack even this gesture.
I'm probably sounding like an old man shouting at the sky, these words are not a direct reply to your comment anymore so hopefully you won't take it personally.
Each people have their own reasons to want open source software. Some people like it for knowledge sharing as you mentioned, but other use cases include make it easier to package in Linux distributions (I don't know the Macos equivalent, maybe that one doesn't make sense), or making it possible to customize the software for my own need (and sharing it with the community in case it's helpful for someone else). For those use cases, it's very useful to have enough code to build the software. Maybe you should suggest whoever would be interested to have this to contribute the missing pieces / mock.
Anyway, I wish you luck with your business, personally it makes me happy to see people build software independently, OSS or not :)
Thank you for your open source contributions.
> I can’t have it fully open source and still earn money from it.
I understand. No one asked you to make it 100% open source, but it would be great if the open source parts of the app are decoupled and can be independently built.
Actually, I knew several partially open source apps, similar to Lunar. For example, Rectangle [1] has both an open source version and a pro (paid) version. However, unlike Lunar, the open source code of Rectangle is buildable. In fact, Lunar might be the first partially open source app I know that is not buildable.
Is there a single proof of concept of this out there? This seems wildly theoretical to me.
Seems like you have to know:
* the projector/TV model/firmware
* the employee laptop and firmware
* a bug in the projector/TV that would let you insert arbitrary data in a way that will stay around and be sent to other devices that connect to HDMI
* a bug in the laptop that would let you install something malicious with the data could get the projector to send
* your hack wont be detected by software on the laptop or the IDS/whatever on their network
That’s pretty heavy lifting. I mean is any of that reasonable outside of nation-state level attacks?
Its not exactly what you are outlining, but close enough for me to think 'yeah, does not need a nation-state level actor to do'.
It would be a different exploit chain for HDMI, and I am no expert in either HDMI or thunderbolt to make a claim that its possible, but I've been surprised with the amount of complexity HDMI offers.
I mean, if part of what you're trying to do is deliver a persistent payload to the target machine then the T1/T2/SIP with the M1/2 will make your life more difficult after the machine reboots, but that is probably the least of your worries trying to chain off an attack like this.
Assuming someone builds a database of vulnerable displays and related exploits, your software can choose the correct exploit because HDMI sends the display model. But if the display is not connected to the network, it would have to exploit an unpatched vulnerability over HDMI in a laptop that connects to it. Not entirely impossible but the time window might be slim if it's not a zero-day.
At one point malicious USB charging cables that owned your machine were just the fever dreams of paranoid people thinking the NSA was out to get them. Now you can buy them for less than $200.
Will nation states launch this type of attack? They probably are.
Do you have to worry about this happening in your meeting rooms? Probably in 3-4 years.
* https://en.wikipedia.org/wiki/HDMI_Ethernet_Channel
With televisions having all sorts of questionable software installed that wants to phone home, it's probably best not to connect them directly, but rather stream things to the display from either your mobile device or a box (e.g., Apple TV).
Of course if you accidentally do connect it online via a box that does have Internet access, who knows what kind of Lovecraftian horrors will be enabled on the television.
And, just because it is "dead" commercially does not mean there are not drivers in your OS watching for any traffic claiming to be ethernet, and eager to respond to it.
Background: HEC uses 3 pins. Those pins can be used for 3 different protocols: HEC (100Mbps differential signal slightly modified from the Ethernet standard)(1), ARC (1 Mpbs SPDIF signal over a single wire)(2), and eARC (~40 Mbps SPDIF differential signal)(3).
Modern computers with integrated graphics send the HDMI signal from the CPU pins. But in all the examples I could find, those pins are all Displayport (4)(5)! This is because DisplayPort supports HDMI video data wthin its signal. This allows manufacturers to convert that to HDMI with a cheap IC (that is mostly a redriver and level shifter). So they just have a DisplayPort signal exit the CPU/GPU and convert it to HDMI if necessary.
At this point I should note that DisplayPort does not support high-bandwidth auxiliary channels. So higher bandwidth features like HEC would require the converter IC to have a separate data channel to the CPU/GPU. But I couldn't find a DP-to-HDMI IC that supports HEC or eARC. I guess there's just not enough interest.
In theory, some computer/GPU manufacturer could connect the HEC pins to an FPGA that has a high-bandwidth connection to the CPU/GPU to support eARC. But even with that, your hacker would need to reprogram the FPGA to stop being a SPDIF encoder and start being an ethernet bridge. And this hypothetical FPGA can't support just ARC - it would be way too slow to be reprogrammed for Ethernet.
Of course, this leaves out home theater devices. They support eARC, and if their ICs are flexible enough, might be able to speak Ethernet with a lot of programming. But since no devices support HEC, you would have to reprogram devices on both sides of the HDMI cable. And at that point, you could just transmit data over SPDIF.
In short, there's a 99.9% chance that HEC pins are physically disconnected in any computer's HDMI port. Even if they were connected, a hacker wouldn't be able to establish an Ethernet connection unless the device under attack is using a very obscure IC or is ridiculously over-engineered.
1: https://patents.google.com/patent/US20110096793
2: https://www.ap.com/technical-library/more-about-arc/
3 (PDF warning): https://www.latticesemi.com/-/media/LatticeSemi/Documents/Wh...
4: https://www.reddit.com/r/Amd/comments/gzkxux/the_am4_pinout_...
5: https://images.anandtech.com/doci/14657/ASUS%20Pro%20WS%20X5...
It's not dead in that it never caught on, it's dead in that as far as I'm aware no one ever produced hardware that supported it. So no, there's no concern about it being used as a stealthy attack vector.
Also it's not exactly rocket surgery to see what network hardware your system sees available. All major general purpose OSes make it really easy to see what drivers are loaded, what hardware is attached, etc. Unless you want to propose that GPU and/or SoC vendors are hiding the fact that the hardware even exists until it's activated and rootkitting the OS to prevent the driver from being detected there is absolutely no reason to believe HEC is a threat to anyone anywhere.
Now, there could certainly hypothetically be exploits discovered against the CEC or ARC/eARC implementation but AFAIK ARC is generally implemented in dedicated hardware and CEC is simple enough to present a very limited attack surface.
That's missing the point when the threat vector is a smart display running an opaque binary blob.
It sound from other discussions here that maybe that isn't very likely given that the network support sounds like it was seldom if ever implemented, but it's certainly a valid concern and the type of scenario I've come to expect from adversarial consumer device vendors who now seem focused less on their products than on how their products can be a conduit for data mining their 'customers'.
And while I tried to find any evidence of that on the net I stumbled upon video[0] titled "Ethernet Over HDMI Is Useless"... from 2013
Old days: “You should talk to a psychiatrist.”
Modern times: “You should talk to my cousin Ernie, he's an IT whiz.”
(via https://twitter.com/kennwhite/status/403584069923270656 )
It's dumb though because it will usually play on DisplayPort which has nothing like HDCP.
DisplayPort absolutely supports HDCP.
Unfortunately people often look at the projector and want to do something else with it, such as play video from one of the numerous sites that enforce DRM now, and will quickly become annoyed if they can't. It can go various different ways from here, but it usually ends up with firewall being removed one way or another because someone in the chain doesn't agree with or understand the importance of it.
[1] I've used both
https://www.amazon.com/Monoprice-115242-Blackbird-HDCP-Conve...
and
https://www.hdfury.com/product/vertex-4k60-444-600mhz/
in similar scenarios, and both worked. Come to think of it, though, while I love my Vertex dearly, it's exactly the sort of highly programmable[2] device this firewall exists to protect against.
[2] Over (out-of-band) USB, RS-232, and, using an optional external adapter, Bluetooth. AFAIK, it's at least not intentionally configurable or reprogrammable over HDMI.
As of 2016, the BBC still claimed they work, though, even for non-TVs:
> 1.37 The BBC’s final detection and enforcement option is its fleet of detection vans. Where the BBC still suspects that an occupier is watching live television but not paying for a licence, it can send a detection van to check whether this is the case. TVL detection vans can identify viewing on a non‐TV device in the same way that they can detect viewing on a television set. BBC staff were able to demonstrate this to my staff in controlled conditions sufficient for us to be confident that they could detect viewing on a range of non‐TV devices.
From: https://www.nao.org.uk/wp-content/uploads/2016/07/British-Br...
The basic truth is that over time it got harder and harder to build "simple" detectors to work out if people were using their TVs to watch the BBC (and this is the tricky part, a valid argument is "I don't watch the BBC", so they need to detect BBC channels being displayed on the TV and not detect other channels) and so it gradually became a less and less directly useful tool for the license enforcement teams to use, so it has sort of transformed from a genuine relatively accurate tool that doesn't need too much equipment, into a sort of mythical boogeyman that gets used to scare people into paying for the license, potentially backed up by cutting edge signals intelligence type equipment to occasionally prove it can be done and maintain the story. The wikipedia article is actually pretty good for explaining how the older detection mechanisms worked https://en.wikipedia.org/wiki/TV_detector_van#Detection_tech...
The wikipedia article I linked to references three separate old government documents over the span of nearly 20 years, each detailing subsequent method used for the first, second and third generation of TV detection equipment.
- First Gen - https://archive.org/details/poeej195207/page/n1/mode/2up
- Second Gen - https://archive.org/details/poeej196301/page/n1/mode/2up
- Third Gen - https://archive.org/details/poeej196910/page/n13/mode/2up
I'm not going to bat for the notion they have vans roaming the streets today with some sort of magically cutting edge NSA/CIA/GCHQ grade ELINT suite packed into a van that can sniff the digital signals leaking from the wiring from a flatscreen TV and run it through some sort of BBC only content ID while compensating for whatever distortions would obviously be introduced (and can be seen in the demo video in the reddit article I linked to) ... this notion is basically absurd, its clearly a scare tactic. No one is practically using the sort of technique documented by this 2013 research paper ( also linked from the wikipedia article, and showing with attached pictures that you can still theoretically do this sort of thing to a "modern" TV ) https://www.cl.cam.ac.uk/~mgk25/temc2013-tv.pdf to "detect" people watching The BBC on flatscreens TVs bought in the last 2 decades.
Whats not absurd, is that this clearly used to be pretty easy to do, like the circuitry for the first gen detector, could be built by any reasonably confident radio equipment person and definitely would work to detect the sort of TVs and TV broadcast technology used back in the early 50s. You can see it get more complex over time in each of the linked documents and obviously as it gets more complex it gets more expensive, and so you would probably see less of them built and operated... if they had a version that could actually do it in the 90's or early 00's then it probably cost them millions per van, so why would they ever risk that leaving the depot on off the chance it gets T-boned in an accident. This is classic mythos progression stuff, where the slightly extraordinary gets told and retold with each version seeming more implausible, turning ordinary events into mythic tales of heroes larger than life battling the gods... Except in this case its progressively more complicated and implausible sounding technology transforming into genuinely impossible for them to pay for it with their budget, transforming into a lie, into a myth, into a complete fabrication and conspiracy.
I’m not questioning the feasibility of the concept, but it is undeniable that no prosecution has ever arisen from evidence gathered by a TV detection van and the BBC refuses FOI requests for any details of investigations instigated by a detection. There were no detections.
The vans are and always have been a hollow deterrent.
The complete lack of direct evidence tying a ban to a prosecution reminds me of the way the FBI are now treating Stingray cell site hijack tools… But it likely comes down to a combination of the enforcement agency’s limited powers and inherent ambiguities that couldn’t be eliminated from the technology. If they couldn’t prove that their signal couldn’t be coming from a TV in the neighbouring row house with perhaps a meter of separation and mirrored layouts placing rooms like master bedrooms and lounge rooms commonly back to back on the adjoining wall, and they lack the power to force someone to let them in, they effectively have their hands tied… but I can definitely see how it would be useful as a tool to quickly cull down lists of hundreds of potential unlicensed premises and to provide the sort of inadmissible hearsay that would provide internal evidence/justification for investigations using other means that could then actually be used for prosecution.
I suppose it was a hollow threat in the sense they could never just lock you up because some detector van snooped you out driving down the street. But in the sense that it was likely an efficient tool to help the agents doing the enforcement work over a large area, the side effect of selling it to the public was probably a bit of clever PR scam pulled by the enforcement agency, who needed all the help they could get since famously, you didn’t have to let them in which sort of cuts off a lot of ways for them to prove/investigate anything.
As a PR effort, it was obviously very effective.
You need a TV license to watch any broadcast TV, or streaming TV at the same time as it is being broadcast, not just the BBC.
RPi4 should support power and network through its usbc plug, however you'll still need another cable for video currently.
the frame.work "SBC" would allow all 3 through the same connector, but, you'll be looking at ~400+ per SBC just to achieve this, but the key thing is, its 100% doable if you get the hardware combination right
The different bits will locally need a number of wires to join them together, but you might manage to run the whole thing off a single ethernet cable.
This seems like a very unlikely attack vector. For one, you have to identify the projector used, develop an exploit for the projector (assuming it's even vulnerable), and also develop a projector for windows/mac/linux that allows the payload to spread. This seems like a lot of trouble to go through compared to visiting the office, "accidentally" leaving a usb drive/dongle, and hoping someone ends up using it. Bonus: usb dongles allow you to spoof input devices, so you don't even need to develop an exploit.
For certain selected targets, it might install something for later. Or maybe just everybody, and you only use the one on the target's machine, and ignore the rest.
Note, you don't need to hack the projector. You just interpose between the computer and the projector, just like this thing does.
It's good education though. Much like there's danger in plugging your phone into random USB chargers, there's danger in plugging your PC into random HDMI cables. I didn't know that.
It would be nice if there was a way it could preserve the EDID information without needed to manually clone it. It looks like this device is good for protecting the display, but I'd be more interested in a device that can protect my laptop when I travel.
Also, if you have that level of paranoia, you probably don't invite people to present in your office.
Yes, leaving around a USB drive would be easier, would also be easier to attach something to the first network port you can find, or attack some weak target in the network (for example, ask to use the printer to print something, and install something on them, printers are super vulnerable and the firmware gets never updated, also because the company that manages the printers is usually an external company with little knowledge about informatics in general).
The firewall dongle as it is is just holds an EEPROM, ancillary components, and the video passthrough traces.
Malicious HDMI (and VGA, and DisplayPort) devices can feed bogus i2c data into the video drivers, which are probably never security audited. With VCP / DDC-CI, the attack surface grows.
So what? The retimer chip doesn't touch the i2c lines, or even if it provides some ESD protection and buffering, it doesn't alter their data content. Software running in the PC is still talking to software running in the monitor's scaler chip.
You can play with i2c-tools under linux to verify this. I've been using HDMI's i2c port to talk to the i2c EEPROMs on SFP transceivers: https://i.imgur.com/T7cY01m.png
Nothing's getting in my way, it's just a generic i2c interface. There are other folks abusing it even worse: https://hackaday.com/2022/04/01/making-your-own-technically-...
Nearly everything is DDC-CI now, where the scaler chip _pretends_ to be an EEPROM in the initial negotiations but there's a few magic "memory locations" that change each time you "read" or "write" to them, and a full bidirectional protocol layered on top of that. This allows arbitrary sized message transport, reflashing of the monitor firmware, and all sorts of goodies. And baddies.
Then there's the HDMI constraint; HDMI is a bidirectional interface by design, and while it looks nice, it's built for packet streams rather than data blocks.
From a user's perspective, this is a dead-end; however, for a hacker, there must be a way to wrap data blocks into packet streams; especially since the HDMI port/cable does transfer data from PC to TV, such as information about the movie you're watching, time left, and so on, in addition to commands and selections from TV to PC, this is known as HDMI-CEC (Consumer Electronics Control), and there is also the HDMI-HEC (High-speed Ethernet Channel) which provides internet sharing for devices connected with the HDMI cable.
So yes, it's a possible threat vector as is everything nowadays. Does it fit inside your cybersecurity threat scenario/risk scheme? Up to you to decide.
But yeah HDMI can have Ethernet too! Very overlooked and potentially dangerous attack vectors in HDMI
[1] http://etim.net.au/nesrgb/ (see first image, lower centre).
has anybody actually hacked a monitor yet? has anybody actually hacked a monitor in a meaningful way yet?
Having to flash firmware on a TV just so that it can successfully connect to a DVR is peak techno dystopia.
"Andy Davis HDMI - Hacking Displays Made Interesting
Picture this scene, which happens thousands of times every day all around the world: Someone walks into a meeting room, sees a video cable and plugs it into their laptop. The other end of the cable is out of sight – it just disappears through a hole in the table. What is it connected to? Presumably the video projector bolted to the ceiling, but can it be trusted to just display their PowerPoint presentation?...
This presentation discusses the security of video drivers which interpret and process data supplied to them by external displays, projectors and KVM switches. It covers all the main video standards, including VGA, DVI, HDMI and DisplayPort. It also details the construction of a hardware-based EDID fuzzer using an Arduino Microcontroller and a discussion of some of its findings."
I wonder which of the things that happen when an HDMI cable is plugged in are negotiated in hardware or laptop firmware, before the host system driver gets to talk to it. It's short odds a binary blob for that chip is loaded at startup. So, turning off services that respond at the OS level likely would not suffice. And, does code in that binary blob have full DMA access to the main memory bus, and PCI devices?
Anyway this gadget should protect against the projector.
Another dumb fucking project..