[HN Gopher] HDMI Firewall
___________________________________________________________________
HDMI Firewall
Author : zdw
Score : 212 points
Date : 2022-06-21 19:38 UTC (3 hours ago)
(HTM) web link (git.cuvoodoo.info)
(TXT) w3m dump (git.cuvoodoo.info)
| post_break wrote:
| This is interesting, I didn't know this was an active attack
| vector for devices.
| jacquesm wrote:
| Blackhat.com talk:
|
| "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."
| jaywalk wrote:
| I'm not sure it actually is. Seems purely theoretical.
| hatware wrote:
| You can bet there's 0-days that exploit this, whether they
| are useful is another thing entirely. HDMI has way too much
| feature creep.
| alin23 wrote:
| HDMI offers so many protocols I didn't know of.
|
| 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/
| byt3swap wrote:
| I also started working on something similar a while back,
| unfortunately got sidetracked with other things before I got
| many of the features (color adjustment, contrast, etc)
| implemented.
|
| 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.
| alanbernstein wrote:
| Any chance you could share more details, photos, product
| links, etc? I am working on something similar.
| byt3swap wrote:
| I have a repo for the switch firmware, which has some pics
| and other details. Keep in mind though that was pretty
| quick and dirty, and I think there is a fix for the
| secondary switch that I still need to push. I should
| hopefully have some free time to get back to it soon
| though.
|
| 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
| alin23 wrote:
| That sounds awesome! Have you ended up using this DDC
| library? https://www.arduinolibraries.info/libraries/ddc-ci-
| vpc-libra...
|
| Or did you end up coding your own raw I2C implementation?
| byt3swap wrote:
| My own implementation. I actually started writing a more
| full featured DDC library with things like capability
| scanning on the roadmap. I should have some time next month
| to potentially get back to it.
|
| 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.
| alin23 wrote:
| Whoa that sounds even more awesome.. or awesomer?
|
| 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.
| alanbernstein wrote:
| Looks like lunar.fyi is just for Mac, right? Any idea about an
| equivalent on Linux? I want to add an input switch shortcut on
| my keyboard, but I want it to work on both machines.
| alin23 wrote:
| ddcutil is the standard utility on Linux for that. It is just
| command line but it's highly compatible and very easy to use:
| https://www.ddcutil.com/
|
| 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...
| Xeoncross wrote:
| Wow, this looks fantastic! No one ever mentions that the Apple
| displays integrate with the brightness controls on macs. This
| can be a major quality-of-life feature if you work during the
| day and night and don't want to keep changing brightness on
| multiple monitors every day.
|
| However, I have non-Apple displays as well. Just tried
| https://lunar.fyi/ and it worked great so far!
| alin23 wrote:
| I see a lot of questions on the internet on "how do I control
| monitor brightness on macOS?" and a lot of "just use
| Control+Brightness Up/Down" answers from people not realizing
| that only Apple vendored monitors support that.
|
| 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!
| sharikous wrote:
| Do you happen to know if the HDMI port on 2021 MacBook Pros
| passes DDC commands?
|
| Because even with Lunar I couldn't make it control my monitor.
| A nuisance, actually.
|
| And could a hypothetical Asahi Linux make it work?
| alin23 wrote:
| The HDMI port on newer Macs doesn't work with DDC, I've tried
| to document that here: https://lunar.fyi/faq#brightness-not-
| changing 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.
|
| Asahi Linux shouldn't be limited by the API, but the problem
| might be in the MCDP chip firmware itself. 1 year later, I'm
| still investigating new methods to fix this but so far I have
| no results.
| ajolly wrote:
| Oh man, I want lunar.fyi for windows, especially auto
| brightness, for multiple monitors based on ambient light.
| gregmac wrote:
| It doesn't have ambient light sensing, but I use Twinkle Tray
| [1] for controlling multiple monitors at once.
|
| 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.
|
| [1] https://github.com/xanderfrangos/twinkle-tray
| alin23 wrote:
| Well, unfortunately that will never happen because the app
| would need a full rewrite using DirectX and WinAPI.
|
| 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]
|
| [1] https://lunar.fyi/sensor
|
| [2] https://github.com/alin23/lunarsensor
| mintplant wrote:
| There's also Monitorian for Windows:
| https://github.com/emoacht/Monitorian
| vuciv1 wrote:
| I'm sorry, but most of this is gibberish to me.
|
| 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)
| alin23 wrote:
| No worries! The same sentiment is what keeps me enthusiastic
| about programming day after day :)
|
| 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.
|
| [1] https://milek7.pl/ddcbacklight/mccs.pdf
| a-dub wrote:
| you can do i2c/ddc over dvi as well... i think even old vga
| analog cabling supported it.
|
| has anybody actually hacked a monitor yet? has anybody actually
| hacked a monitor in a meaningful way yet?
| thehappypm wrote:
| I wonder if eventually peripherals will go back to pure analog,
| just aux and VGA, after a few major hacks are discovered.
| topspin wrote:
| I don't. The ads and tracking enabled by digital offset the
| cost of manufacturing; sans that products will cost more, and
| price is a major factor in purchasing decisions.
| buildbot wrote:
| This would also be really useful for monitors with broken/missing
| EDID info
|
| But yeah HDMI can have Ethernet too! Very overlooked and
| potentially dangerous attack vectors in HDMI
| ncmncm wrote:
| It would not be surprising if spooks rely mainly on plugging into
| HDMI to suborn machines now. Of course this is no help with that
| unless spooks have substituted a doctored monitor. Or cable. The
| doctored presentation-room projector would be a plausible place
| for that.
|
| 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.
| sudobash1 wrote:
| I could see this also becoming useful with Smart TVs. I don't
| want my TV to be having Ethernet-over-HDMI or other non-
| video/audio connection to any hardware that I connect to it (EG
| laptops). I'm not sure how much of a concern this is, but I don't
| trust the security of them, nor do I trust the manufacturers
| intent.
| javajosh wrote:
| Oh I see, you're worried that the TV manufacturer could hack
| your laptop if you connect it via HDMI. This is the point at
| which I have to wonder: what on earth can HDMI do?? What is the
| vector? I assume you have to break out of the target driver,
| which is probably OS/version specific. Then I suppose normal
| hackery applies, in terms of planting something on the disk. I
| assume that the HDMI driver does NOT have any legit API for
| writing to arbitrary locations on disk. I assume.
| nix0n wrote:
| This might not be adequate for keeping your TV off the
| Internet, they've been rumored to connect to unsecured WiFi.
| lancesells wrote:
| Has anyone ever confirmed this? I did a search and only found
| a thread on HN asking the same question:
| https://news.ycombinator.com/item?id=25275350
| netsharc wrote:
| Feels like some beliefs like this are like the Korean
| superstition that leaving the fan on while you sleep will
| kill you.
| closewith wrote:
| In the UK, BBC vans drive around with unsecured WiFi
| networks to see if any houses have smart TVS connect, and
| then fine them if they don't have a TV licence.
| kllrnohj wrote:
| Source? That sounds both fascinating and fake.
| kllrnohj wrote:
| Nothing uses Ethernet-over-HDMI. It doesn't actually exist
| outside of a spec proposal. Even though in theory it'd be
| really cool. Imagine if your receiver could also be the network
| switch for all the devices. I'd actually pay money for such a
| thing. But, yeah, not actually a thing it turns out. So you
| definitely don't need to worry about your smart TV using it any
| time soon.
| Uehreka wrote:
| It would be super silly and probably against every spec ever
| written, but I'd love to be able to plug a digital signage
| Raspberry Pi into a TV and not need any other cables thanks
| to Power-over-Ethernet-over-HDMI.
| josephcsible wrote:
| Wouldn't dip switches be better than breaking circuit boards and
| cutting traces? After all, this can't protect against physically
| present attackers anyway, since they could just unplug it and
| plug directly in.
| sudobash1 wrote:
| As for a physically present attacker, many projector systems
| are out of reach and have a cable running through the wall or
| table to produce a socket for users to plug in to. Or they are
| mounted inside a cabinet with a similar cable reaching to the
| outside. If the "firewall" device is present at the
| (inaccessible) projector, this would not be a problem.
| josephcsible wrote:
| Sure, but dip switches would still be fine then, since
| attackers wouldn't be able to reach them to change them.
| bee_rider wrote:
| They have some little pads you can solder across to re-enable
| writes. Perhaps it would be possible to put a switch across
| those?
| myself248 wrote:
| Oh, good. Glad to see this getting some attention.
|
| 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.
| mschuster91 wrote:
| You can in theory hijack the projector/monitor, okay. But the
| chances of reverse-hijacking are really REALLY slim - virtually
| all HDMI devices employ a retimer/redriver chip in front of the
| output, which means the only way "in" would be to exploit the
| CEC stack. HEC (Ethernet over HDMI) support is extremely rare
| in support.
| myself248 wrote:
| > But the chances of reverse-hijacking are really REALLY slim
| - virtually all HDMI devices employ a retimer/redriver chip
| in front of the output
|
| 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-...
| asojfdowgh wrote:
| There are so many devices where I already want a sequel to them,
| HDMI Firewall 2, with the ability to solder spots to re-enable
| features
| hobo_mark wrote:
| Does anything actually use Ethernet over HDMI?
| gwbas1c wrote:
| Cool, but why can't the device just automatically copy the EDID
| from the monitor?
| ncmncm wrote:
| That would be a nice improvement.
| dasv wrote:
| The readme says there is also an additional device that can be
| used for copying the ERPROM, instead of doing it via the
| computer. It would be possible to integrate the copier in the
| firewall dongle but that would mean having a microcontroller in
| each device that is just used once, driving the unit cost and
| the size up.
|
| The firewall dongle as it is is just holds an EEPROM, ancillary
| components, and the video passthrough traces.
| [deleted]
| gwbas1c wrote:
| FYI: It seems strange to use branches to differentiate between
| entirely different projects. Normally different projects have
| different branches; a branch is used to make a change in
| isolation and is then merged back into master.
| nix0n wrote:
| This is kind of a neat hack, if you want to use the same build
| setup for all of these projects: just check out whichever
| project you're working on. Shared stuff can go into a separate
| repo. You could still have feature branches, it's just not
| master that they're merged into.
| gwbas1c wrote:
| That will get confusing extremely fast, especially when
| collaborating in groups.
| throw0101a wrote:
| The main thing I'd be interested in blocking is Ethernet:
|
| * 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.
| js2 wrote:
| HEC is dead. Those pins are used for ARC/eARC on every device I
| know of.
| ncmncm wrote:
| Wouldn't be surprised if it muxes ethernet and ARC on the
| same pins.
|
| 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.
| giobox wrote:
| Neat idea, but lack of HDCP support could be deal breaker for a
| lot of applications - I'd even consider listing this limitation
| nearer the top, it's currently at the end of a long README. HDCP
| is used in a huge number of HDMI devices.
| js2 wrote:
| You could combine with an HDFury device such as
| https://www.hdfury.com/product/dr-hdmi/ to fix that. Of course
| the HDFury device would have to be before the HDMI Firewall
| (closer to the source), so you have to trust the HDFury not to
| be hackable on its own.
| jfim wrote:
| Is it used outside of playing DVDs and other copy protected
| content? It seems like the use case presented in the link
| (malicious presenter connecting a laptop that hacks the
| projector) would not need HDCP.
| api wrote:
| Things like Netflix often query HDCP via browser extensions.
| There are workarounds but sometimes they won't play full
| screen without it.
|
| It's dumb though because it will usually play on DisplayPort
| which has nothing like HDCP.
| happyopossum wrote:
| That would fall under the 'other' playback GP mentioned.
| Still wouldn't apply to a PowerPoint preso...
| randombits0 wrote:
| Or could. With the push to "secure data", DRMed internal
| docs already exist.
| kllrnohj wrote:
| DisplayPort has both it's own thing called DPCP but also as
| of displayport 1.1 it literally has HDCP, too. Which it has
| been tracking (so eg DP 1.3 has HDCP 2.2)
| gzer0 wrote:
| Let's start with the theory: if you have access to the
| television, you should be able to install your own custom
| firmware.
|
| 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.
| MBCook wrote:
| > For example, let's imagine you invite an external guest for a
| presentation inside your company. You offer to connect to a
| video-projector so he can show his slides. This is the perfect
| opportunity for the guest to hack the video-projector. Next time
| an employee connects to this projector, his laptop is hacked
| back.
|
| 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?
| flatiron wrote:
| not when the alternative is "hey disgruntled employee, i'll pay
| you 25k for these files" is the low hanging fruit
| javajosh wrote:
| This is only low-hanging fruit if the company/engineer in
| question makes HDMI firmware.
| MBCook wrote:
| I believe they meant the employee of the company you're
| trying to hack, not a TV/laptop maker.
| javajosh wrote:
| Yes, I know. The people best positioned to write an HDMI
| hack are the ones already working with HDMI, not your
| random webapp developer
| vdqtp3 wrote:
| the point is there's no sense in spending man-years
| building an hdmi hack and implementing it by going onsite
| when you can bribe an employee instead. it's low
| likelihood
| lalopalota wrote:
| No, the original comment meant: pay a disgruntled
| employee to get what you want instead of developing an
| HDMI exploit for your target.
| jedahan wrote:
| Check out trmml's thunderstrike for an example of a working
| hardware worm.
|
| 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.
|
| https://trmm.net/Thunderstrike/
| gruez wrote:
| >For example, let's imagine you invite an external guest for a
| presentation inside your company. You offer to connect to a
| video-projector so he can show his slides. This is the perfect
| opportunity for the guest to hack the video-projector. Next time
| an employee connects to this projector, his laptop is hacked
| back. And voila, the innocent guest managed to infiltrate your
| company network, and can exfiltrate confidential information.
|
| 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.
| ncmncm wrote:
| If your organization often gets outsiders in to present, it
| could slurp off the interesting contents of anything plugged
| in. Or, if you can get access to the projectors (or just the
| HDMI cables) at e.g. DEFCON.
|
| 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.
| rtkwe wrote:
| You might be able to get a persistent hack attacking the HDMI
| controller chip directly instead of having to develop one
| specific to each projector, that's a more generic component.
| That said though this does feel a bit like a very hypothetical
| attack because you'd have to package both an exploit for the
| projector and target
| bentcorner wrote:
| Defense in depth - after you're done gluing USB and ethernet
| ports closed, this might be something to consider. I agree it's
| unlikely but if it's a low cost mitigation then why not? And if
| you're at a shop that doesn't do anything about open physical
| ports in the office then yes, this is way down on your risk
| assessment checklist.
|
| 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.
| nonameiguess wrote:
| I see comments here expressing skepticism that any but a nation
| state threat actor would try to pull off an exploit taking
| advantage of this, but considering the possible targets, that is
| exactly who you might be looking to defend against. The clearest
| target, to me, is air-gapped systems that also disable USB ports,
| but still allow workers to use external monitors. That is
| effectively any classified computing environment, and clearly the
| threat actors targeting state secrets are overwhelmingly going to
| be other states.
___________________________________________________________________
(page generated 2022-06-21 23:00 UTC)