We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

A Monitor Darkly: Reversing and Exploiting Ubiquitous On-Screen-Display Controllers in Modern Monitors

00:00

Formal Metadata

Title
A Monitor Darkly: Reversing and Exploiting Ubiquitous On-Screen-Display Controllers in Modern Monitors
Title of Series
Part Number
14
Number of Parts
20
Author
License
CC Attribution 4.0 International:
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.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
There are multiple x86 processors in your monitor! OSD, or on-screen-display controllers are ubiquitous components in nearly all modern monitors. OSDs are typically used to generate simple menus on the monitor, allowing the user to change settings like brightness, contrast and input source. However, OSDs are effectively independent general-purpose computers that can: read the content of the screen, change arbitrary pixel values, and execute arbitrary code supplied through numerous control channels. We demonstrate multiple methods of loading and executing arbitrary code in a modern monitor and discuss the security implication of this novel attack vector. We also present a thorough analysis of an OSD system used in common Dell monitors and discuss attack scenarios ranging from active screen content manipulation and screen content snooping to active data exfiltration using Funtenna-like techniques. We demonstrate a multi-stage monitor implant capable of loading arbitrary code and data encoded in specially crafted images and documents through active monitor snooping. This code infiltration technique can be implemented through a single pixel, or through subtle variations of a large number of pixels. We discuss a step-by-step walk-through of our hardware and software reverse-analysis process of the Dell monitor. We present three demonstrations of monitoring exploitation to show active screen snooping, active screen content manipulation and covert data exfiltration using Funtenna. Lastly, we discuss realistic attack delivery mechanisms, show a prototype implementation of our attack using the USB Armory and outline potential attack mitigation options. We will release sample code related to this attack prior to the presentation date.
Revision controlJSONXMLUML
Event horizonWater vaporComputer animation
Casting (performing arts)Metropolitan area networkAreaPhysical lawMereologyInternetworkingSharewareEmailObject (grammar)Computer animation
Information securityVideo gameOffice suiteSpeech synthesisVirtual machineKernel (computing)Degree (graph theory)Bit rateWeb browserMultiplication signPhysical systemMusical ensembleTraffic reportingHacker (term)PixelCryptographyMaxima and minimaEncryptionEndliche ModelltheorieAreaRight angleComputer iconDevice driverForm (programming)WindowSphereRouter (computing)GoogolTouchscreenGreen's functionBootingSuite (music)Metropolitan area networkFirmwareInternet forumComputer animationMeeting/Interview
Right angleMultiplication signStandard deviationComputer programThermal radiationCommunications protocolString (computer science)Endliche ModelltheorieType theoryMereologyProcess (computing)Information securityOpen sourceQuicksortSoftware protection dongleControl engineeringFood energyBit rateTouchscreenDependent and independent variablesPole (complex analysis)Computer hardwareWordData transmissionSoftwareParallel portMetropolitan area networkParameter (computer programming)SpacetimeMedical imagingComputer fileFigurate numberPower (physics)WhiteboardReading (process)File formatSanitary sewerStaff (military)Data structureInformationPlotterMonster groupOffice suiteSCSIRevision controlVariable (mathematics)Motion captureSerial portBus (computing)CASE <Informatik>FirmwareGoogolInheritance (object-oriented programming)Mobile appMass storageCodeRadio-frequency identificationVirtualizationService (economics)Computer wormBitComputer animation
CodeRight angleLogikanalysatorGreatest elementBus (computing)Copyright infringementControl engineeringStandard deviationMereologyGradientPower (physics)Bit rateMicrocontrollerDifferent (Kate Ryan album)Message passingRaw image formatFrequencyAsynchronous Transfer ModeControl flowFile formatSCSIFlash memoryInheritance (object-oriented programming)WhiteboardPlastikkarteEngineering drawing
Medical imagingRight angleFlash memoryVolumenvisualisierungEntropiecodierungGradientData structureQuicksortDifferent (Kate Ryan album)CodeTable (information)BitWhiteboardDevice driverFirmwareFunktionalanalysisSocial classBit rateString (computer science)HexagonComputer animationSource code
BitQuicksortRight angleOpen sourcePhysical systemTurbo-CodeComputer fileWordDependent and independent variablesComputer animationJSON
Hand fanComputerWritingSemiconductor memorySoftware testingRectangleCalculationCodeMobile appTurbo-CodeStandard deviationBitRight angleSpywareFunktionalanalysisComputer programWordTelecommunicationCartesian coordinate systemSheaf (mathematics)RadiusStudent's t-testLine (geometry)Computer fileUser interfaceComputer animation
Point (geometry)Message passingBit rateCore dumpSystem callRange (statistics)Sign (mathematics)Touch typingQuicksortEigenvalues and eigenvectorsComputer hardwareMereologyProcess (computing)Bus (computing)Personal identification numberSystem on a chipReading (process)FirmwareComputer animation
Directed graphFunktionalanalysisPoint (geometry)Personal identification numberSerial portReal-time operating systemString (computer science)Water vaporComputer animationJSON
Link (knot theory)Core dumpMicrocontrollerBridging (networking)ComputerBit rateMedical imagingSoftwareSpacetimeSemiconductor memoryControl engineeringPeg solitaireDevice driverRight angleFile formatRevision controlMereologyWeightFlow separationSystem callUniform resource locatorTouchscreenPixelSingle-precision floating-point formatBitHeat transferCodePhysicalismComputer animation
FirmwarePower (physics)BootingAreaProduct (business)Fluid staticsComputer animation
Data structureStability theoryHeat transferControl engineeringControl flowDynamical systemInformationComputer fontCoordinate systemCuboidMedical imagingWater vaporBitPoint (geometry)Form (programming)
Bit rateCuboidPoint (geometry)Cellular automatonMountain passComputer animation
Buffer solutionCountingForm (programming)Right angleMultiplication signBitComputer animation
PixelFinitismusEndliche ModelltheorieFigurate numberCellular automatonPattern languageSingle-precision floating-point formatComputer animation
BitSharewarePixelString (computer science)WordTouchscreen
Synchronous dynamic random-access memoryFirmwareTable (information)Procedural programmingStructural loadAlpha (investment)FunktionalanalysisNumbering schemeProcess (computing)BitMultiplication signAxiom of choiceRight angleMedical imagingLinearizationLogicBit ratePhysical systemOptical disc driveWeb pageGreen's functionParsingCore dumpMappingPoint (geometry)InferenceNominal numberComputer animation
Mathematical analysisVertex (graph theory)Data managementMaxima and minimaMedical imagingMultiplication signStapeldateiAddress spaceMatching (graph theory)Figurate numberPoint (geometry)System callSelf-organizationArithmetic meanException handlingRight angleString (computer science)Control flowTouchscreenWeb pageDynamical systemPixelBitOverlay-NetzProcess (computing)Thread (computing)SoftwareStructural loadPower (physics)CodeBit rateExpected valueNP-hardLevel (video gaming)CryptographyForm (programming)TrailComputer hardwareProbability density functionSlide ruleFunktionalanalysisComputer animation
CASE <Informatik>Table (information)TouchscreenSparse matrixMetadataContent (media)Bit ratePower (physics)CodeComputerSystem callOrder (biology)MetreWhiteboardPersonal identification numberSharewareComputer hardwareSingle-precision floating-point formatComputer animation
Bit ratePresentation of a groupSharewareAreaMetropolitan area networkCode2 (number)WebsiteInformationComputer animation
WebsiteProcess (computing)Graphical user interfaceTouchscreenLink (knot theory)WordRight angleUniformer RaumComputerState of matterFactory (trading post)Speech synthesisEndliche ModelltheorieSharewareBit rateVector spaceRadical (chemistry)Order (biology)Touch typingOnline helpSoftware testingMultiplication signMenu (computing)Control engineeringType theoryPlotterPoint (geometry)Revision controlProof theoryDifferent (Kate Ryan album)User interfaceBridging (networking)10 (number)WhiteboardPixelCodeMedical imagingPolygonSet (mathematics)SoftwareTheoryTrailGraph (mathematics)Physical systemGoodness of fitMereologyPattern languageCurveUser interfaceInformation securityFirmwareBus (computing)PhysicalismGreen's functionVirtual machineBitProper mapComputer animation
Information securityPresentation of a groupBit rateControl engineeringComputer programSet (mathematics)TwitterSystem callWordGoodness of fitProcess (computing)Video cardOpen setComputer animation
Computer animation
Transcript: English(auto-generated)
Hi, guys. Sorry for the delay. Before we start the talk, I just wanted to let you know that we will be giving this awesome artistic ThinkPorna version 2 if you answer all our questions, so please pay attention. It's very hard. You guys will never get it.
Hey, I just want to make a quick announcement before I introduce these guys. Just a reminder that there's an event tonight at 9 at the SAT, which is where the concert was last night, and it's at the SATosphere. For those of you who haven't been there before, in the past, it's an experience. So with that, I'd like to introduce Aung Shui, Francois Charbonneau, and Jatin Kataria,
who will be talking about monitors, so thanks. Okay. Yes, like Jatin said, we're going to give out that really cool thing if you answer one really hard question. The title of our talk is Monitor Darkly, and here is the cast of characters. I'm Aung. Jatin is trying to set up the demo down over there.
Strong Francois is right here. I'm not going to do that. He's a Canadian. He's great. And this is Igor from Hexrays, and I've never met Igor, so we just kind of made him up. Not in person. I speak to him over email a lot. Here is a concerned area man named Chris. He will be part of the story.
And an area man of concern, Shakib, which will also be part of our story. Okay, so primary main objective. We're going after monitors. That's what this talk is about. Why monitors? What is this? Is this really a security problem? That's what we're here to talk about. So I thought, in retrospect, why I did the monitor thing, and I think it had a lot to do with...
Back in the day, I used to exist in cubicle life. It was very sad. I found a picture of my actual hedge fund cubicle office thing. I think that was my actual desk, and it contains actual sadness. And I think I went back to school.
I maybe subconsciously wanted to dismantle cubicle life technology. So Jatin and I, at Columbia University, did a lot of work on Cisco phones. We looked at HP printers, and we did some work with Cisco routers. So the last thing that's left in that picture is the monitors. So the monitor is going down today. That's what we're doing.
But in more of a serious note, let's look at this website. It's chase.com. There's a green little lock over there. Green means good. I would probably posit that we've probably spent about a billion dollars creating all of the technology, the infrastructure, the support, the kernel. All the technology to support an infrastructure where we can put a green icon on that browser window.
So we can feel safe about encryption. Looking at the lens in which we see this browser through, it's a monitor. So if you want to compromise this system as a whole, maybe let's look at the minimum cost of one billion dollars for the crypto and all the infrastructure and all the security we put around the kernel and the browser,
and maybe whatever the cost of bypassing the security on the monitor is. Maybe it's a lot. Maybe it's a little. That's what we're here to talk about. And a good hacker is a lazy hacker, so instead of going after the kernel and the browser to change the pixel from that end, let's see if we can just change the pixel and the screen itself.
Okay, so this story starts back in 2015. We're traveling back through time. Right, so I get this really sweet new monitor in my office. In fact, I think Jaden has one too. And we look at it, we plug it into our machine, and the first thing that it says is,
ah, USB to I2C solution from Texas Instrument, and also TU, what is it, like a 3410 boot device. Right, so we look at that, and we say that's pretty cool. That's very interesting. And then like a minute of googling later, we find this post from Dell Support Forum. Right, and they said don't worry about it. You can download this like weird driver. But really, you know, we only use it for firmware update,
and you should never need this, so everything's fine. Right, and I also thought, huh, that's also really interesting. So, you know, I say to Jaden, hey, Jaden, let's tear down that spare 34-inch monitor we have in the office. But we already have a suite monitors. Why don't we take out that 34-inch? Yeah, like, who cares?
And then area man, concern area man Chris overhears his conversation, and he says, like, have you guys no hearts? Like, there's no end to your senseless savagery. And also, I have a million VIM plug-ins, and I'm very sad. And then I said, oh, that's the saddest story I've ever heard. Why about, how about interns? Let's give it, let's do it to the interns, right?
They won't be sad. So, right, this is our intern pit. We love these people. They're very talented, dedicated people working in our office, and it just so happens that the interns get standard issue, you know, Dell U2410 monitors. Okay, and, you know, like 15 minutes of Googling later, we find this really very informative document that says, you know, Dell U2410 USB firmware upgrade instruction, right?
It is so clear that I think it's almost, like, insultingly clear, because if you look at this instruction, it literally says, like, you plug the power cord in the power cord wall thing, okay, as a step, right? And then you do the rest. But the rest of the document is very informative. They actually show screenshots of this tool that Dell released to do firmware update, right?
Lots of very useful information, like if you look up there, the name of the firmware image, right? So, you know, if we can find it, we maybe can do this process and figure out how, you know, a firmware update works on a monitor. Very interesting thing is app tests, right? Super sneaky command, OX500, who knows what that does, right?
But whatever this thing is, this process takes firmware, copies it from USB, and puts it directly into Persistent Surge on your monitor. And we thought, that's kind of cool. Okay, so we do more Googling. You know, we find all sorts of things like Genesis, and then G-Probe, and then this hardware from the 90s, right? This thing takes a 12-volt power supply, right?
And then it has a parallel port, and it goes to VGA and some other mystery dongle. Every vendor, you know, every manufacturer of monitor makes something sort of secretly similar to this, but it's not the same. And we found this in tons and tons of monitors made, you know, like late 90s, early 2000s.
Okay, more Googling we find. STMicro somehow is involved. Analux is there. Athena is a thing that, you know, STMicro makes. And then somehow all of this stuff ended up in a Dell monitor. Okay, so what's a little bit Googling? This is what we found. The string app test, right? That's where we started. That's part of a tool that G-Probe or Genesis created
called G-Probe, okay? And this, you know, in the early 2000s appeared to be a very industry standard type of software that people used to manage the software running on monitors. Okay, more Googling later, and this is the story. So Genesis Inc. was, you know, operating, and at around 2002, they sold themselves to STMicro, right?
But they were also the people who created G-Probe, and they were very active in creating the VESA standard for this protocol called DDC, which I'll talk about. All right, and then SDMicro bought Genesis in 2008, right? They took their own IP and G-Probe and stuff that they wanted to mix together and created this chip called the SDDP600 or 60XX and 80XX.
And then that was put into an intellects board, and intellects is a company that designed these screen controllers, which is, you know, partially owned by Foscon, and then later, you know, Dell sourced the intellects board right into the Dell monitor. And this is kind of the reason why we have terrible security,
you know, in monitors today, this mishmash of, you know, where this technology came from. And, you know, we got a copy of G-Probe just by looking around and Googling. That's what it looks like. You know, it has the ability to connect to the device, in this case, the monitor over, you know, parallel serial USB.
Basically, the story is, as long as there's some way to get onto the I2C bus of the monitor, G-Probe can update the firmware and do all sorts of other diagnostics, which is cool. Okay, and then we took the USB firmware tool. We captured the USB traffic, right, and it's very noisy, lots and lots of traffic. And this is a capture of, like, a snippet,
a tiny snippet of firmware update process. And before we get into the details of that, let me just, brief story about DDC. DDC stands for Display Data Channel, right? It's a standard that, you know, was created by VESA, and there are many versions and sub-versions of DDC. There's DDC version 1, 2, I think 3, and then 2B,
and sub-versions, you know, BI, B+, AB, blah, blah, blah. Who knows? Okay, but now let's look at what a packet that has this information looks like going over the USB port. So, this is a SCSI command, which is sent using USB mass storage protocol over USB. And then, this is another packet
which encapsulates DDC2BI packet, which has a payload of gprobe packet, with which you can, you know, ask about, like, register read, or you want to do, like, run code or anything like that. This is a DDC2BI packet structure, which contains a DDC destination, service length, VCP prefix,
which is, like, virtual control panel, and the gprobe message, and it checks that packet. So, let me tell you, like, how you do a small command and talk to the monitor about this. A very simple command. A very simple command. It's basically a monitor asks, hey, I want to talk to you by sending a vendor-specific CF code
and ask for a register read. As a SCSI command. As a SCSI command. And then, monitor says that I acknowledge that you want to talk to me, and monitor say, PC says that I acknowledge that you acknowledge that you want to talk to me. So, and I also acknowledge that you want to do register read. Over.
So, the last two packets is, like, end of transmission for the acknowledgement of the request command. And then, again, the PC says, could you please give me a response by first sending a SCSI command and then asking for a get response command. And it says that I acknowledge that you want to get a response.
So, it says that I acknowledge that you acknowledge that you want a response. So, here is the response. Over. Yes. So, 12 packets, right, to do this very simple command. And we saw this over USB. You know, we figured that out. And now, we decided it was time to take apart some poor intern's monitor and see what we see. So, you know, that's, if you take off the back cover,
this is what our monitor looked like. The logic analyzer and the bus pirate did not come standard. That's ours. We put that in there. Yeah. And, you know, on the top, you have all the standard powered equipment, right. On the side is this little USB controller, which we'll get back to. And on the bottom is a USB hub.
And that big old thing with the aluminum, right, heat sink, that's the sock. That's the thing that we want to execute, code in. And then Francois mapped out all the different parts, right. So, the main sock is the SDP8D28, right. And right next to it is the multiplexer for I2C.
And connected to that, right via I2C, is this USB2649. It's a programmable controller slash hub, right. And that's the thing that's on the side of the monitor that you can plug in a CF card to. But we're connected on the left side at the bottom. Exactly. So, that one is a dumb USB hub, right, which we'll get to. So, when Jatin sent this packet, right, as the URB packet,
what happened was the packet went through the USB hub. So, the reason why the first command is a undocumented SCSI OXCF command is it goes up to the hub to the 2649 over USB, right. And that puts that device into, like, super sneaky I2C instruction receive mode.
Okay, and the second packet that you send, right, if it's the right format over URB, right, gets sent to the hub to the controller. And the controller then takes, decapsulates that packet, takes the raw I2C message, right, puts it right on the I2C bus and just sends it directly to the microcontroller, the SOC, right.
And that's why you have so many packets. Basically, you know, you put this thing, and the USB controller actually does the decapsulation. And this allows you to put whatever I2C message you want onto the bus. And if you can do I2C messages, then you can communicate with the SOC, right. And we'll show you what you can do with that. You know, you flip the board over, we found a two megabyte SPI flash, right.
So, we did the obvious thing, dumped the flash. And this is a in-house entropy analyzer that we have, which just renders entropy. White is really random, black is not random at all, right. Just, you know, right off the cuff, you know, looking at the image, that's obviously some kind of weird table structure, so we're interested in that.
This kind of looks like code, right, three different segments of code, who knows what it does. Probably data, right, it's a little bit low entropy. And this thing, you know, probably looks like some sort of compressed data, so we're interested in that as well. The next obvious thing is, you know, let's do strings, right. And we found exactly what we wanted to find. There's analogs, Mars, right,
is the internal designation for the board class, I'm guessing. And in fact, the firmware update tool shows up with Mars.hex, which is a small driver that allows you to communicate with the board. Dell 2410, and, you know, if you look at the other commands, right, you have really cool stuff like gm underscore osdshow and osdhide, right. Those are exactly the kind of functions that we want to play with.
So we do the next obvious thing, it's like, let's open it up in IDA, right. And IDA didn't really like it, and I don't like x86 either, that's why. You know, ugh, right, it didn't really do well with the disassembly, and the reason why is because this is Turbo 186, right,
which is a 16-bit x86 system that can extend to either 24-bit, right. 24, 20? Yeah, 24 bits for segment select, so it does all sorts of funky stuff, and I didn't really, you know, know what to do with it. And then I Googled a little, it turned out somebody in 2008, exactly when SDMicro, bot, Genesis, and all this stuff,
posted on openRC with a very specific question about a very specific file. So I'm guessing somebody probably worked on this in 2008, and Igor, right, wrote a very reasonable response, like this is, you know, how IDA works, and, you know, Turbo 186 is blah, blah, blah, right, just do this. And then I looked at it, I looked at x86, and I'm like, ugh,
I don't want to do this anymore, I'm going home, right, because I'm not a fan of working with x86 in general. And then a year passes, because I didn't do it, right, 2016. Jad and I, like, were sitting around, and we really, this wouldn't sit well with us, you know, we wanted to know how this stupid computer worked,
we have to do x86 this time, you know, and we were like, I don't know, let's just ask Ilfac, hi Ilfac, right. And then Ilfac didn't respond, and Igor did, and Igor just wrote this very long, insightful explanation of exactly the innards of IDA and how to do Turbo 186. And, you know, he was even nice enough to actually disassemble Mars.hex.idb,
just to show us that, like, look idiots, you can just do this, obviously. So, you know, we did it. And if you know IDA, right, like, so many segments, that's definitely not what you want to see. Like, we failed, it was hard. And then... Ilfac, and Igor, please don't look at this slide, because I basically put cross-references in every function,
there was no visualization, so I just added a hotkey, which did in-place calculations to find, do the jumps, and as documented in the g-probe documentation we found was register read, through which we can read any registers, we can put EIP anywhere we want, so definitely there is code execution.
And this is one of the commands we found, which is undocumented through the Dell upgrade tool, which allowed us to put shellcode in the OCM, in the memory of the monitor. So, keep in mind, this is all just straight, standard g-probe interface, right? It has run code, it has read memory, it has write memory, right?
It's all legitimate communication, we're not exploiting anything. So the next thing we say is, okay, let's write a hello world program, okay? So we found this really cool app test, right, which is, you know, a way to run diagnostics, and the app test is OSD file, a fill rectangle, right? Like, let's do a rectangle with color in it, that's exactly what we want to do. And then Jatin says,
let's do ram write, let's write shellcode and hijack this. Yeah, and then it worked, but it was like really gross. It was epileptic. And if you're a little bit hungover from last night, it's going to get worse, but this is kind of what it looked like. We had to look at this and debug it for hours and hours, and it will make you puke. It did once. We don't know why it blinks, by the way.
Yeah, Jatin, why does it? Science. Science. Great. Okay, so at this point, this is what we know about the firmware. We got it more or less disassembled. You know, we have this range of 80000 to B0000, okay? And then we saw, you know, pretty quickly that there were all these little far calls to the F0000 range.
And we were really curious about that, because that's not part of the firmware, okay? And, you know, it's definitely something that's part of the SOC that the firmware update process doesn't even touch. Okay, so I said, huh, let's dump some data. Definitely, I have registered read. I can dump data through USB.
And then he did. Wait for it. Dump. And dump. It's very slow. It is. So it's like 1 kilobyte every 8 minutes or something? Yeah, I was able to dump that out. Because every 120 bytes requires like 12 messages on the USB bus to get, right? And you can only extract up to 120 bytes.
It says 127, but something weird comes out. So while these guys are doing this, I'm mucking with the hardware, so I figure maybe there's a way to do something with hardware. Maybe we can play with the GPIOs. Maybe we can exfiltrate data using something else aside from USB. Maybe we can find a GPIO that we can repurpose.
So I just used everything that's available, and I flipped the pins until I finally found something. I found one pin we can actually flip. There's probably more out there. We figured out there's more later. But at this point, I have one. So with one, I can do async serial or something like that. And then I can exfiltrate data at maybe like a megabot or something, which I did.
And we also figured might as well just hijack the printf function and do some dynamic and have a look at what's happening in the monitor in real time and extract some strings, because we had no UART by then. And we couldn't find it. Maybe you guys can find it if you play with it, but maybe it's there. But at this point, we actually see some activity when we press buttons. This did not take us anywhere, but it still was worth a shot.
So Fred's literally walked off and said, guys, I'm just going to go re-implement UART and GPIO in this monitor. I'll be back in a day. Bye. And he came back in a day, and he did it, and it worked. How cool was that? Okay, so we did some dumps, dynamic data coming out of the monitor finally. And we realized, also a little bit of Googling,
we realized we were really wrong about what we thought about this firmware. It's not OSD firmware. That was a misnomer. It really is OCM executable. OCM stands for on-chip microcontroller. And it turns out there is an OSD, but inside the SOC, the OCM and the OSD are two separate computing devices. There's two effectively, two cores running, and the red part is what's called iROM.
And the purpose of iROM is it's an actual ROM that sits inside the chip that acts as a driver that allows the OCM controller to connect and work with the OSD controller, which is all done through shared memory and DMA. So it's basically a tiny little network
inside a tiny little I2C network on a monitor. There are so many cool things to do in this monitor. You can do actually PIP, which is display inside itself. You can display two screens on one go. So we had that, and we Googled for like a million years, and then we find this piece of gold.
It's doc88.com. It's definitely a place where you want to go to and click on links in a VM, but you should click on every single link because it's such a great website. But it does have a datasheet for exactly the chip that we're looking for. So with this chip and with this datasheet, we learned a ton about internals and all the registers
and stuff that we never thought we would find in a tiny little microcontroller inside the monitor. So with that, with the document, with physical access, with code execution, we're ready to put at least a single pixel on a screen, the color we want, the location we want. So we're like, let's display a picture.
The only three questions we have to ask, what's the first question? Where to transport image. And the second question is, how do you display the transfer image once you get it there? And the third one... And also, what about the colors? We don't know how the colors work. Is it like a compressed image? Is it a JPEG? What is the format of each pixel? What is the format of the image, et cetera?
So we thought we would look at, if you plug the power into the monitor and nothing happens, you don't connect anything to it, the Dell logo comes up. This is kind of like the monitor's boot screen. And we saw that, and we're like, well, this thing must be in the firmware. And after many constructive, sober, and entirely productive discussions
between Jad and I, we were just looking at the static stuff, and Jad is like... That's obviously code. Yeah. So maybe that's a picture. Who knows? But I'm like, well, but look at all this. What is that? Maybe that's a thing. A menu or something. And if you stare at this thing for long enough...
I don't know why it does this to me, but it does crazy things to people's brains. It gets you more drunk. All right, so we're doing this in Francois. Yeah, so these guys like to stare at things and hallucinate. I prefer to just press buttons and see what's happening. So I'm pressing buttons, and I'm dumping at the same time, because I have this sweet dumper now.
So I'm dumping all this information, trying to compare what's happening in RAM, what's stable and what's changing, to see if we can get a better picture of what's happening. So a lot of great dynamic data as things are happening, as menus are coming up and down. So then we get this, which I don't see anything in there, but Jadon's been analyzing all this information for so long,
and he just comes and points this to me. Francois, that was definitely a command structure. Obviously. Don't you get that? So this is a command control structure for the OSD. You can specify the coordinate system and the size of the image which you want to display, which color do you want.
And you can also compress the image and expand it in the OSD itself. So this is an adjust. It works. The OCM talks to the OSD, sends commands, sends data, sends control structures and font structures. They are like three or four structures you send through DMA engine.
And that's how we fixed our transfer and display image. And this is a control structure. If you pass this, you will be able to display a blinking box and get epilepsy or something. So there are two APIs which are required, which is SDRAM read, through which you can read what is in the OSDS RAM, and the write API.
And that's what happens. So now we're getting better at doing this. It's getting pukier, right? But it's still blinking. I have no idea why. Yeah, it's blinking faster now. Hey, Jaden, why does it blink faster than before? I don't know how to click. And we also have no idea why it blinks.
But it's really gross if you look at it. It does make you nauseous. So you see this, I'm able to move the command box now. And I was really happy. And that's weeks of work, by the way. So weeks of work and we get a pink box. We're pretty proud of ourselves here. OK, so we got one and two down.
All we need to know is how to form a picture, what is the color, pack that data up. We're done. We can display whatever we want. So we filled the buffer with incrementing values starting from zero, one, two, three. And then we got that, which is definitely not what we expected. Because we were expecting maybe slightly different colors
because we're moving one byte at a time, changing one bit, really. But that's not what happened. So we looked at that and we're like, OK, we don't understand, but it's science time because we're scientists. So we took a microscope and we put it right on the monitor. We're like, we're going to display a byte. We're going to look at exactly what comes out of it, eight pixels, and we're going to figure this one out.
We can even decode the color, get a colorometer in there, and we're just going to do it. Obviously on top of a writer book. Yeah, exactly. And also the other one. Oh, it can't be the CE book. That's gross. OK, so I've never seen this before and I thought that's really cool because you're literally seeing the R, which is dark, the G, and the B.
Those three things is a single pixel cell. And the value we put up there is 0x33, 0x33, 0x33, 0x33, 0x33. So same color, same pattern. Now we get each individual RGB value through this little microscope. And that's what we got.
OK, so instead of the same value, we said, OK, let's just do 33003300. And this is what we got here on the microscope. So for one super amazing thing that we're going to run our demo on, you win this if you answer this question, right? OK. How many bits per pixel is it?
Six? Yeah, so we're putting in the word 33003300, and we're getting this thing on the screen. Who said four bits? You won't get it.
Four bits? Can you actually do it with four bits per pixel? But I thought in a normal world, you do it with 32 bits, right? There's 8-bit R. There's 8-bit green and 8-bit blue and 8-bit alpha. So how can you encode using 4-bit? Obviously, you have to use some kind of color lookup table. And we went through the documentation.
That's what they use. So you get access, with a 4-bit system, you get access to 16 arbitrary 32-bit colors. So you can display any color of your choice, 16 colors of your choice, right? And zero, we found out later that it is a transparency. So where is the color lookup table?
I'll actually go back. And what we found is that, OK, you can only have 16 colors, but each color is actually 32-bit deep. So you can do all the colors you want. You're just limited by the number of colors you can use in any image, OK? All right. So cool. Let's find a color lookup table. Let's modify it. Let's see if we can change the colors now, OK? And then we're like, well, how do we do that?
And then, you know, Francois comes in. Yeah, of course. I'm obsessed, or so it seems. But at this point, we found out there's an external SDRAM, which is like more data to dump. So I perfected the procedure. And now we can dump 128 megabytes of external SDRAM and just try to see what's in there, if we can find images or if we can find more.
And we did continue. We all continued to work. We did see that the OCM firmware is mapped in SDRAM. So definitely it's also x186. Right? So we also worked really hard while you were doing this, right, obviously. OK, so this went on for a long time. And like two days later, we all find what we're looking for. We're like, oh, that's what it is.
And it turns out it's exactly the same, OK? So it's the same as how the command goes from the OCM processor to the OSD. Basically, there is a color lookup table that sits inside the OCM firmware. A function loads it, sets up a DMA engine. And there are four DMA engines inside this little processor. And it puts it into the SDRAM. And the OSD picks that up, deparses it,
and does its magic, OK? All right, so this is where we went, OK? Like we actually were able to frame, like form our own image. We were able to load it and display it, put it wherever we want. So we made this cool unicorn instead of a rainbow. It has a tiny little SSL locks that comes out of it. Because now we can do as many SSL locks as we like.
We can put it anywhere we want. And that's why this unicorn is magic. I mean, all this work for just making a unicorn fart. Yeah, but with locks for crypto, right? That's good. OK, so at this point, you know, I'm pretty happy. I'm not working, right? It's like very late at Friday night. And I go to John. And I'm like, John, the SSL lock only has 16 colors.
It doesn't look great, you know? We need more colors. It's so hard on. It's really hard. But we looked around. And we saw that the hardware does support up to 8 bit per pixel. We, like, instead of finding this, I found a break point. So 8 bits, right? That allows you to have instead of 16, 256 colors,
which is definitely enough for that SSL lock. Yep. And instead of that, I found how to put break points on the chip. And then we can do dynamic analysis and figure out, like, how every call is working. So you can also do code batch. So if we would have found this before, instead of, like, a one and a half month work, it would have been only a week maximum? Yeah, so we found this, like, when we're 95% done with this work, right?
And if we used this from day one, it would have been so much less painful. But it's just we have to scroll through all the pages manually. It's not a PDF. So it loads slowly, one page at a time. And you have to give them e-gold to download it or whatever, like Ali gold or something. It's terrible. I refuse to pay. Right? So we're really happy. We're like, break point for the win.
We could now stop working, right? Yeah, so of course I don't drink, so I just keep working with the – and I need someone to work with. So I get some interns, and we just keep working at it until we figure out pretty much everything, except for the 256 colors. But that'll come. And at this point, yeah, I'm dumping more and more, and to the point where we actually can put an API together
and get something working. So we have all the stuff that we're going to show and some more into this sweet API that you can just call and show some stuff on the screen and whatever you want to do. Yeah, so the API lets you load an image, put it to a different place. We have a really cool thing I'm not going to talk about until later, but actually it's literally the next slide. We found this really amazing treasure.
So somewhere deep in the code, there's this function called grabPixel, right? You know, the entire time our expectation was that the OSD's job is to put pixels on the screen, to overlay menus and whatever. But apparently it can also see every pixel too. Like, why it has that power, I don't really know. It's cool. The fact that it's there means you can have a piece of software
that looks at the screen and also manipulate the screen. So use your imagination, right? Maybe you can track where things are on the screen and change them dynamically. Who knows? So in the end, in review, we were able to change every pixel, we can see every pixel on the screen, and there's this other thing we did called Fontana.
I don't really have much time to... Actually, we have a little bit of time. So the idea of Fontana is to take software, right, and use the very ubiquitous hardware you find on all these embedded devices in order to turn those devices into data transmitters, radio data transmitters. And in this case, we adapted a friend's SWAT code.
So we found a GPIO with a longer trace or a longer cable on the board, which was long enough for us to transmit something probably a few meters away. So probably outside this room or something like that. Yeah, so we're flipping just the single GPIO pin. And you know, this is kind of cool because this is building off of the Marcus Kuhn stuff he did, right? From Venek freaking to doing Venek freaking on LCDs. And here we now have the power to compute on the data on the screen
and then use the screen itself to actively transmit not just the raw content of the screen, but the computed metadata that you find on the screen. And over here is a cheap TV antenna that's an intern, right? That's an SDR, and we're transmitting somewhere like 16 MHz, right? So that's cool too. And that code is also in GitHub.
Okay, so enough talk. We're going to run some live demos. Okay, John, take it away. So this is, I think, Bonadu again. Can we put it to the TV? Give me a second. So the first attack, we call it, it's a very special attack.
We call it Shaq attack. If you remember from our presentation, there is an area man of concern, Shaky. And so I'm going to just execute it. He promised, he made his promise that we wouldn't use this for the demo. But here it is. Yeah, sorry.
Oh, I should also explain that's a USB armory, right? With all of our POC code. It's basically running Linux and it's just doing all the USB traffic that we were talking about before. So if you want a random guy just watching you,
use our API, download it on GitHub, and you're getting this picture also. You can't get rid of him, by the way. He's there to stay. Yeah, that's Creative Commons. It's out there. It's done. Let me clear this attack. Let's do a second one.
So let me go and get a very informative discussion website. Oh, wrong. That's our next demo.
Okay, sorry. I have to. So as we all know about this website, it is very informative as I have learned all these years,
but it has always missed one thing, which is TLS. Let me give it. Yeah, let John do that for you. There you go. And it has TLS. Yes. Yay.
Everything is secure now. Whatever I see. Everything's okay. Everything's okay. All right, let's set up the last demo. Okay, so this is just a screenshot. There's no factory behind this thing. But maybe you guys are familiar. This is what a typical HMI, a human machine interface,
will look like. It's a graphical interface to something like an industrial process thing. So you have computers controlling flow rates of tanks and blah, blah, blah. And they're all reporting back real-time status. And generally speaking, green is good, red is bad. And when you have a red light on a big tank or whatever,
it's probably something you should look into. People probably freak out. So just look at this green, and we'll see what happens. Oh, do you see it? Did you catch it? There you go. So instead of going after the HMI, the PLCs, the network, you know, what if you wanted to influence human behavior just on the monitor?
I mean, good luck tracking that down, right? And here it is, right? So that's our demos. No, wait, we have one more attack. Oh, that's right, that's right, yeah. Oh, that's just for fun. That's our proof of concept. We just put it in there.
All right. Oh, it's the unicorn. Demands obedience. And we got it wrong the first time. You can see the image is not squared properly. Yeah, this is our first picture ever. It's a proof of concept. It's the first one. Okay. So, you know, let's talk a little bit about implications of this thing.
You know, how big is the problem? Okay, so we actually had some folks look into the business end of this. And we estimate that over the last 10 years, we've made over a billion monitors, right? And I would guess, you know, by and large, the majority of the monitors that we have work in some way very similar to this Dell monitor, in the sense that it has an OSD controller. It could put a menu thing on the screen.
And it runs software, right, that drives that system. So, yeah, pretty much every one of your monitors is probably vulnerable to this or some variant of this today, right? Now, that's a problem. And, you know, how practical is this attack for, you know, how practical is the attack vector?
So, if you notice, the way we did this attack, we had to physically plug in a USB cable, right? And that's how the USB to I2C interface worked. But keep in mind, one, the DDC2BI and the DDC commands were originally designed to be able to go back over all of the data channels, including VGA and HDMI.
So, there's always a possibility that that command can go through that data channel. And also, right, as soon as you have access to the I2C bus, right, even if you didn't have a legitimate, you know, bridge that got you there, however you get there, as long as you're on the I2C bus and you're working with something similar to this, right,
you should be able to, you know, do something like what we've done here. And if you notice the very modern, the very new, you know, 34-inch curve monitor with the USB to I2C solution, right, I mean, that tells me that maybe the board is not exactly the same, maybe the firmware versions are different, but today we're still using this methodology of, you know, getting some bridge to talk to I2C in order to talk to these on-screen controllers
to do something like a firmware update. And so, here's the big one. How realistic would the fix be if there was a fix? You know, I thought this one through a little bit, right, so in order to fix this thing, you either have to do something like a physical recall of, like, a bailing monitor, which is never going to happen, or you're going to have to release a software update to fix the issue,
which means probably you're going to have to do something similar to our, you know, our path, right, or you're going to have to release the firmware update process, right, to all of the users of the world, which will actually help the adversary, the bad guys, faster than it helps the good guys, right, because, you know, the reason why we can't do this on a hundred different models today
is because we don't have a hundred monitors, but if you release the way firmware update is done on everything, then that's probably not good. So the way we fix it is going to be slightly tricky, and we haven't put the code up on GitHub, but we're going to not be lame, we're actually going to do it today. So that's supposed to be a link, but we're definitely going to do it.
And this is like, you know, like Francois said, all of the code that we came up with, all the code that, you know, ran in this demo, and a lot of documentation of the APIs that we found, you know, ways of using GradPix, so ways of displaying images, and ways of doing Fontana and all that stuff. You know, so lastly, right, please contribute if you like this work,
you know, take apart your monitor, take apart your friends' monitors, right, see what's inside, because, you know, this is one data point, and obviously there are thousands of different manufacturers for monitors, and probably tens of thousands of different firmware versions, blah, blah, blah, but, you know, if we started getting more data points, we'd probably get a better idea of, you know, how widespread this type of attack can be.
And, you know, lastly, right, like we're now entering a time, you know, where we probably have to doubt the pixels coming out of our screen, as just yet another security problem we have to worry about, right, and that's not great, so, you know, if we can come together and try to fix this problem in some tangible way, that would be most excellent.
So, in conclusion, right, there are happy endings to this story. We spoke to Dell, and as of yesterday, Dell has not released a security update to fix the shack attack, so that's still going to happen, and many monitors were harmed in the making of this presentation, but the happy ending is that Chris now lives happily
with his semi-unmodified 34-inch monitor. So, he got that one. That's not dead, so that's it. Questions? Yes.
Oh, yo, hi. Yeah, thanks for the picture. We never met, you totally just made that one up, sorry. First question. How much alcohol was consumed during your work? John, what do you think?
How much alcohol is consumed during the making of this presentation? 25 bottles of wine? I don't know, it's... I would say that, two bottles per day. We don't, you know, it's... I'm kidding. It clearly got the job done, so we're good. And second, you mentioned that you have to use USB, but did you look into, like, using just the video card to talk directly to DC?
So, that's the next thing that we would look into. We started to look at it, actually. We didn't get a chance to finish it. That's a big opening question, right? And, like I said, any peripheral on the monitor that gets you onto the I2C bus, no matter what way you do it, right,
will probably be able to get you to this goal. Any other questions? I guess let's drink. We done? Alright. Okay, we're done. Thank you.