 All right, everybody, this is Anqui and Jatin Kataria. They want to talk to you about a monitor darkly. Give them a round. Come on. Congratulations on getting up here. Thanks. Thank you. All right, we're going to get stuff shown on the monitors. It's all going to work. All right. Okay, so this is work that we've done for the last two years in our spare time. So I wanted to tell you the story of how we did it and what we found over that time. So we have a big cast of characters. My name is Ong. Jatin is underneath this table. He will sometimes reappear for this talk. We have a very strong Canadian in Francois, who we worked with, but he couldn't show up to this today. We have a person named Igor, which we'll talk about. We have a very concerned area man named Chris. And the last but definitely not least, we have area man of concern named Shaquib. And if you see his face on your monitor, things are really going to be bad. And he's actually in the audience today. So watch out. All right, so today's primary main objective is to go after these little devices that you connect to your computer that puts pixels up. Right, monitors. We all know what they are. Okay. And, you know, motivation for why we are interested in monitors. You know, a good hacker, right, is a lazy hacker. So if you think about this page, right, when you see this page, you think you're talking to your bank, right, the little green pixels on the left side here, right, makes you think this is an encrypted communication and you're safe. Now, think about all the resources and the research and the money we spend to create this infrastructure so that we can have this internet with, you know, SSL, right, that will show you these green pixels. You know, you have to secure the browser, you have to secure the kernel, you know, the infrastructure for doing certificates and all this other stuff. I would say we probably, cumulatively, probably invested over a billion dollars to make this infrastructure exist today the way it does. Okay, so let's look at the context in which we see this website. Okay, so we view it through this tiny little computer with a big screen on it that we call the monitor. Right, so the lazy hacker would say, you know, if I wanted to break the pixels that show me green, I could either break the security for, you know, that's, you know, built with a billion dollars in investment or whatever the security is inside this little monitor, right, and, you know, maybe it's not so great and that's what we're here to talk about. Okay, so this whole thing started back in 2015 when Jaden and I got really sweet new monitors. Okay, so we bought these things and we say, wow, this is beautiful and as soon as we plugged it in, you know, we noticed this really curious thing, right, the USB device on it said, you know, TUSB3410 boot device, right, and the USB to I2C solution. So we looked at that and we said, it's very interesting, right, so a minute of googling later, we found this really useful Dell forum response by Chris, so somebody asked, hey, you know, I don't have a driver for this, you know, T3410 boot device, you know, what is it for? Is it a problem? And Chris from Dell says, don't worry about it, you know, that driver is only there for firmware updates which we'll probably never do, right, but if you want the driver, here it is. And I looked at that and I said, how interesting, right? So Jaden and I started thinking and I say, hey, Jaden, let's tear down this 34-inch monitor that we have lying around. Well, we already have awesome monitors. Why don't we take that 34-inch which is not doing anything? Yeah, and then we're cool with this, but then Chris hears this, right, you know, and nearby and he says, like, these monsters have no heart, like there's no end to their savagery and I also have a million Vim plugins and my life is sad, right? And we said, oh, this is really the saddest thing of everything, so where are we going to find these monitors? Why don't we go to the interns? They don't need monitors. And they have, like, Dell 2410 sitting around. Yeah, we got a pit of interns, they get 24-inch monitors, they don't need them, right? So we started looking at the 2410s instead of the curved ones and, like, 15 minutes of Googling later, we found this really nice document that describes a USB firmware upgrade instruction, okay? And this instruction is just insultingly clear because the first instruction that says the power goes into the power wall thing, right? And then the USB goes into the USB thing, but then, you know, it talks about this U2410 ISP tool in-service programmer, and then we started to get very interesting results, right? So we're seeing screenshots of this Dell utility that doesn't require any administrative privilege, that, you know, starts up a bunch of stuff and at the end of the day, right, runs, you know, things like AppTest and a lot of other mystery and just does the firmware upgrade for you. So we looked at the output of this program. We said, you know, what is an AppTest? Like, what is this all about? We started Googling, right? We found a lot of, you know, documents mentioning Genesis and G-Probe and all this other stuff. And we also found these documents from, you know, the late 90s, early 2000s that had all these mystery hardware that updates firmware from these really old monitors. So if you see the one on the bottom, there's a parallel port with power supply going to VGA, right, and somehow this hardware changes firmware on monitors. So we started Googling more, right? We find mention of SD Micro, Inelux, Athena and Dell. So we're trying to figure out what this is all about, okay? Like days and days of Googling later, we figured out roughly how this happened. So AppTest is a thing that's used by G-Probe, which was created by a company named Genesis and they were a big player in the on-screen display controller market, you know, in the early 2000s, right? From that, we did a lot of Googling and here's what happened, okay? So in 2002, Genesis created G-Probe and Genesis was in 2008 later sewed to SD Micro and the SD Micro threw in some of their IP and created this chip called the STDP6000 something, right? That chip was then sourced to Inelux, which is partially owned by Foxcon, which is then something that's, the Inelux built a board that was eventually used in Dell monitors, right? So this is how, you know, somebody wrote two various insecure code in 2002 that caused, you know, probably a few hundred million monitors in the world being vulnerable today. So that's, you know, how it happened basically. And now we were able to get a copy of G-Probe, right? So this is a screenshot of what it looks like. You know, the interesting thing to look at here is the software says we can connect to the monitor via things like serial, right, and also USB and we're looking at things like the DDC to BI, right? So that's something that's important to come back to later. So we got a copy of this firmware update tool, right? We ran it in a virtual machine. We dumped a lot of USB traffic and we noticed that there are DDC packets embedded inside USB packets, okay? So Jaden's going to talk a little bit about what DDC is. So DDC is like a display data channel communication set up by VESA. So it is used by the host adapter to query the monitor about the hardware capabilities, what is the vendor, what resolution it supports, and blah, blah, blah. And then if you go to this, there are multiple versions of DDC which exist. There is DDC2B, 2BI, AB2B+, and what we are working with here is 2BI and which is a next version of 2B which works over I2C and talks to the host adapter. So here is what initiation of communication started with the host adapter to the monitor happens. It sends a SCSI command with the code CF, which is a generic vendor code. And it is wrapped over, it's wrapped in a USB mass storage packet which is sent over to USB. Then the USB request block contains a DDC2BI packet which is an encapsulation over G-Probe packet to do different commands. So one of the commands if you're looking here is a run code command which allows us to put PC anywhere in the monitor. How convenient, right? And if we look into the G-Probe documentation, all of the checksum algorithms are laid out for you. They're very simple. So again, we're taking messages that are supposed to go into I2C, packing it into USB and sending it over to the monitor via the USB interface. So yeah, let me show you a really simple communication between the host and the monitor. So I'll play the monitor. Jaden will play the host, okay? Monitor, initiating communication. Give me a register read. I, as the monitor, say I acknowledge your request for initiation of communication. I acknowledge your acknowledgement that you started or you wanted to do initiation of communication. Okay, I have acknowledged that you have run the read register command end of acknowledgement. Okay, but we're not done yet, right? This is just to send the command. So this is like six packets to send the command. Hey monitor, let's do a communication again. Give me the response of my previous command. I acknowledge your request for initiation of communication. I acknowledge your acknowledgement that you wanted to do initiation of communication. Okay, I have the result for you from read register end of communication. Goodbye. So 12 packets to get two bytes out of the monitor. Right, but it works. You know, that's how the monitor is doing it, right? And this is the mechanism that the monitor uses to update the firmware from USB into the on-screen display controller. Okay, so we read some documentation. Let's avoid the warranty. Let's figure out what the hardware looks like. So we open the back of the monitor. This is pretty typical, right? And the hardware is made up of the auto-enhancing and auto-enhancing and auto-enhancing, which is the one that shows you the low stuff is on the bottom. Okay, and here's an architectural diagram. Right, so you have the main SD micro chip on the upper left hand corner. Notice that that chip sits on an I2C bus, which is connected to a multiplexer chip. And that's the 4053. Right, and that multiplexer again sits on a second I2C bus, which is connected to a USB controller, right, then eventually ends up directly on the I2C bus for the uh on screen display controller. So we're able to send raw I2C packets through USB to this machine. And that's how things work. And uh we flipped the board over. This is pretty typical. We found an SPI flash chip that we were able to dump. So we dumped the code. And uh this is something we like to do. We like to do 2D rent, you know, visualization of entropy. Uh so you know off the top of uh off the top of our heads we looked at this thing and we said I have no idea what that is. That looks pretty sweet, right? Uh it's high entropy followed by low entropy. There's certainly pattern there. Uh this stuff you know somewhere in the middle probably looks like code. Uh stuff over here maybe data, right? It's high entropy, right? I mean it's low entropy but it looks like there's some stuff in there that's interesting and who knows maybe this is compressed data. We don't really know. And then we took it and we just ran string on this thing and you know we're seeing a lot of stuff that were you know we saw in the documentation. So there's app tests, right? It mentions of you know picture in picture and things like OSD hide and OSD show, right? So this looks like we're on the right track. We want to play with these things. So then I said obviously let's throw this in IDA and see what happens, right? And this is what IDA did, right? And you know we looked at it and we said oh this is really hard. We can't figure out how to disassemble Turbo 186 which is the the architecture here. So we started googling around and it seems like somebody on OpenRCE in 2008 probably did exactly this research but maybe didn't tell anybody because they're asking about exactly the same architecture in exactly the same format. And I think the binary is actually from one of these from our updates. So we looked at this and we said oh we don't like X86. We're gonna go do something more fun, right? And we put it down. We didn't work on it for like six months. And then 2016 comes along, right? And Jad and I are sitting around and this is really bothering us. You know I have no idea how this works. Like computers are hard. So we just write Elfak an email, right? And in six hours or eight hours Igor responds and it says like here's a long insightful explanation of how IDA works in Turbo 186 and also already disassembled this thing for you. Simple. So this Mars X is basically a piece of handler run on the monitor to update the firmware on the device. And it was like a 200 kilobyte, I think 2 megabyte. And he reversed everything and it was perfectly disassembled and he gave it back to us. So we thought like we'll do something like this with the firmware of the monitor. Yeah. So you know I read his email and I said I'm just gonna do exactly what you did, right? And I got segmented everywhere and nothing worked out and I failed. And then Jad and said let's not do that. Let's be monkeys and press space. So we added a hotkey which if you add like space where like it jumps to different references you won't get a control for analysis but at least it will help you in analyzing things. So if Elfak is looking at it please sorry. So while so we have now we can run code but we want to do our we want to run some kind of code on it, right? So we you we went through the G probe documentation and we found three commands. One is the register read which helps us to read any registers, run code, placing PC anywhere we want and ram write which allows us to patch shell code into the memory and there is no MMU. So this is you can execute anywhere you want. So we there's a concept of AppTest which is basically a unit test inside the monitor. So it creates a context and it tears down the context and does something inside it. Yeah so now that we have this ability to write code into memory and then run code, right? We want to hijack something that seems like it might be useful to see if we can do a very simple hello world. So we found this one function that says you know OSD fill rectangle, right? That sounds like a good idea. We want to just put a rectangle on the screen to see if we can actually do this. Let's patch it using ram write. Right. So John wrote this thing and it turned out to be the grossest code that we've seen to that point. It gets way worse than this, right? So this is what it looks like. And I have looked at this for three weeks. Yeah and if you stare at this for hours and hours it will make you want to puke. It will get gross. And John definitely did stare at this for hours and hours. Okay so now, okay now that we are able to dump some memory from the firmware, right? We're looking at the code with some, most of it disassembled, right? We noticed that the virtual memory address map is between this and this, okay? But there are all these far calls to this very mysterious memory region. So we started, we thought like there is no reference to it and we do not understand how to get this code. So we started dumping code. So we wrote a USB dumper and so we took, there is a command which is listed called ram read but we were not able to make it work. Although it works now. So we used a reg read which allowed us to dump two bytes at a time. So imagine like doing those 12 packet transfer to get two bytes out. So I wrote a memory dumper which allowed us to do one megabyte dump per eight minutes. So you remember those 12 commands that you had to do, right? We're doing those USB commands for what is it 100 bytes at a time, right? So we, this is what we did. It was let's dump. John writes the USB dumper. We dump and we wait and we dump and we wait and we dump and it's very slow, right? And then Francois comes along and says like, you guys dump too slow. I'm going to totally do this differently. So he went off and he said, I'm just going to re-implement the UART using GPI opens on the SOC. That's going to be way faster. And we're like, no way that's going to work. You know, two days later he comes back and he says, you are implemented, okay? He also hijacked standard in and standard out. So all of a sudden we had a UART over GPI opens on the monitor that not only allowed us to dump arbitrary memory, it also allowed us to hijack all these very important, very useful debug messages. So it is very important, important to know that right now we were working with the assumption that there is only one microcontroller in that SOC. But after dumping the F-thousand range, we realized that it's actually a hardware abstraction layer to talk to another chip, another processor inside the SOC, which, which is called OST now, on screen display, whose main function is to display images on the, on the monitor. But the other OCM, which is on-chip microcontroller, is actually talking to other device, other components inside the SOC and other external interfaces. So the, which is 8000 to 8000 is mapped to with OCM and OST has its own code running inside SRAM and its own kind of processor. Yeah. So at this point, you know, we know that we're now working with just one processor. There's at least two different processors inside the SOC, right? And they communicate using some memory map register that we don't really understand yet. And we kind of hit a wall. So we spent like a million years Googling and clicking on pretty much everything that we're not supposed to, right? Until we found this beautiful site, Doc88, which is a place where people upload, you know, awesome proprietary documents for the internet and stuff. And you'd probably want to open this in a VM, but it did give us the exact datasheet for this chip that we're working with. And from there, we found pretty much everything we needed to know about how this chip worked. And we were right about this assumption that there is an OCM and an OST chip or OST processor and they're completely separate and they work more or less asynchronously from each other. Okay. So now that we have the datasheet, we've done all the stuff, you know, let's try to display a picture, right? Let's get that to work. First, there are three things we have to solve. And if we solve these things, we, we got picture display, okay? We'll have to figure out where to transfer the image to the monitor, right? We have to figure out how to trigger the image display function to, you know, display that image we transferred. And then we also have to figure out, you know, what a color is, right? How the color is represented in, in this monitor. So when you start, boot the monitor, right? Like if this image comes up. So the, the theory was that if you find this image, we will be able to find the code which loads this image and our quest will be over. But we had a dron, sober and very sober professional discussion. Yeah. And after a few hours, we came up with our own analysis and we both said that this is not a deli image. So what is this on? Well, I mean, you know, so we looked at some part of the code, right? This clearly doesn't hold the Dell logo, right? But you know, what about stuff like this on the, on the left side, right? Like maybe that's, you know, some representation of image, you know, what is the thing on the left, right? And if you stare at that for too long, it also does crazy things through your brain. Okay. So then, you know, friends what comes along, right? And we, you know, you know, after like, after a few days, he came up with me like multiple megabytes of data to stay at. And I looked at it for hours and come on, that's obviously an OSD command packet. I mean, don't you see that? Obviously, right? This is just, you know, in memory at runtime, right? Just a big old blob of the binary and John stairs at this thing. And he says, obviously, this is this structure. So this OSD command packets allows the OSD to display packet anywhere in the screen. You can specify the coordinates. You can specify the size. You can specify the color, how many bits per pixel have to be used. And what we understood after a lot of reverse analysis of the IROM, which is the hardware detection layer, this is how it actually works. So you write the OSD packet inside the OCM virtual memory map and then you engage a DMA engine to map this memory over to the SRAM of OSD. And as along, like as OSD is working asynchronously, it reads the packet and displays the image. And the similar way you can transfer the image to the OSD using the DMA memory mapping. So this solved our first two questions, which was transfer and display image, right? And the APIs which were used to do this was SD RAM read to check verify our write and the SD RAM write, which helped us to do all this. And this is what we came with. This is probably the most gross blinking box blinking program I have ever done. And if you look at it for hours, I have definitely wanted one. Hold on. Wait, you got to see it. You guys all have to watch this with this now. Wait, hold on. Why doesn't it? So you will see. No, it doesn't want to play. Hold on. No, no, no. You're not going to get. I just want to come up. You're not off the hook. You got to watch this video. Okay, so as you see that the block, I'm able to like move the box around anywhere on the screen. That's so nauseating. There was a blinking bug, which I figured out after recon. All right, but this is after days of looking at this nonstop. So the last question we have to figure out, you know, what is a color, right? I mean, is a 32 bit color? How is it represented? So we did the reasonable thing and filled a rectangle with rows and rows of, you know, colors, incremental value from zero, one, two, three, four, etc. So instead of getting very similar colors, we got these colors, right? So, you know, why is color zero, this basically the same as color two, why is one totally different? Okay, and we didn't really know. Let's do some science. We take a tiny little microscope and we point it at specific pixels in order for us to figure out what, you know, color gets rendered into what pixel value. So we filled every rectangle with the value 0x33. Okay, and this is what we saw. So if you look at it, like R is blank, G is 100%, and B is 100%, right? So this is, you know, individual pixel cells that we're looking at. And then we said, okay, let's do instead of, you know, the same pattern we do 0x33, 0x00, 0x33, 0x00. So John, how many bits does the monitor use to represent each color? It all is. So if you see zero represents transparency and there are two pixels missing, so it's four bit per pixel, right? And then how do you encode colors with four bits, right? In normal RGB world, each color, each component is represented using 8-bit and there is an alpha component, so it represents a 32-bit color. So how do you do this on? Yeah, so right, if you have four bits, then you can have one bit for R, one bit for B, you know, etc. And that's clearly not what's happening here. So it turns out this monitor uses a thing called color lookup table, which is basically this index structure, right, that uses four bits to index into 32 bit colors. So this allows you to save space, right? You can have at most 16 different colors, but you can have colors that are 32-bit deep. So now the big question is, how, where is the lookup table? Can we change it? Can we modify it? And then we did a very, you know, again very sober, very collaborative work with Francois, right? And we did this for days and days to try to figure this out, where he dumped lots of memory and we helped a lot. And like two days later, okay, we finally find the structure that we think is the lookup table. So it works in a similar way, how we were transmitting the images in the command package. So you generate a specific color lookup table structure and you write it to the OSM memory, memory map that memory region over to the SRAM of OSD, OSD picks it up and displays the color for that specific image. Okay, so we have everything we need. Okay, we're gonna display photo and we did it. Okay, so look at that. We have tiny little SSL locks. We have as many as we want wherever we want. And that was sort of the point of this, right? But I looked at it and I said, we still have only 16 colors and that SSL lock actually had something like 26. 26 colors. So that's not enough colors John. We gotta get more colors. It has been really hard now. Yeah. So we went through some docs and we figured out like the hardware does support at least 8-bit per pixel. So and till recon we didn't have, we had only 4-bit per pixel but now we have fixed up to get 256 colors and the code is submitted into GitHub. But after going over more analysis of the documentation, the register documentation list we found, we found a break point. So which means that we can halt the monitor, figure out everything and this is after like 90 percent of the research we have already done. And we have spent like weeks on it, even months and now if we would have access to this break point, we would have finished it in probably like one and a half weeks or two weeks. Yeah. So at this point, Jad and I just kind of like put our hands up in there. I was like, I can't believe we missed that one. That's terrible. You know, so we said like interns, go do the rest of it. Right? Break point everything, reverse it, tell us what it is. In front so I help. So the interns went out, dumped the stack, dumped the heap, found pretty much everything we needed to do all the demos that I'll show you later. And then we find the treasure. This was very surprising because we, the OSD should be allowed to display a pixel on the image, on the screen but it is very surprising that it has the capability to read pixels anywhere on the screen. And what can you do with that now? Yeah, we'll talk about that in a little bit. So we presented some of this research at recon and after the presentation, people who actually knew how monitors work came up to us and said like, hey, stupid, you don't actually even need the USB cable because, you know, there are ITC channels on DVI, HDMI and DJI, et cetera. So we actually ported the code to run over the ITC interface and now our demos do not require USB at all, although it can be done over both channels. And that stuff is on GitHub today. Now, let's have some fun with it, right? Let's make a monitor implant. So let's assume that we have a very simple base implant in the monitor. Okay, and let's also assume that I'm a sneaky guy and I have control over a pixel. Right, so if I blink the pixel, I should be able to transmit data to my, you know, base monitor implant and I can do something very much similar to a command and control, right? So every time I sample a pixel, I can change the data and I can do something like a command type, data, data, data, which allows me to load arbitrary code, arbitrary data, execute code and do all sorts of other things. Now, we take this pixel, we put it on the internet, right? And as we know, the internet is used for one thing, right? So we can put this pixel on photos of cats, right? We can do YouTube videos of cats. We even do, you know, movies about cats. And once we do this, we can distribute this pixel down to millions and millions of monitors and we can update them all at the same time and we can have direct command and control down to those exact monitors, okay? And within our organization, this is commonly known as cat-based world domination plan number seven, okay? Now, so in the end, what do we do? Okay, we figured out that we can change whatever pixel on the screen, whatever we want. We can also see every pixel on the screen, which is really cool. And for those folks who have followed our previous research, we even got Fontana to work on the monitor as well. But that's its own conversation that we'll have later. So, you know, enough talk, right? We're going to do some demos, okay? And then first I have to figure out how this works. There you go. We swear there's an actual monitor under this table and the demo is now rigged. But shooting a camera at the monitor is a little bit difficult. So does it work? I think you should put on this thing. All right. Okay. So, I'm going to talk from the table. Yeah. So first I'm going to show you how to put random people pictures on the screen and you can not remove it. So I'm going to, so this is Shakeeb as we talked about and his picture is going to be on the monitor. So this is a typical, you know, you've been to a machine, no administrative privilege and we're just showing, you know, putting an image on the screen. Now we didn't do this in GitHub but we can actually make this permanent. So imagine if that happened to you how terrible your life would be. My second attack will be, you all know about 4chan, right? And it is not, it doesn't have any TLS capabilities but I'm going to give it to you. We're going to secure 4chan for everybody. We did. So check it out, right? Can you like move it a little bit if you can see that closely, right? So we get to put SSL locks wherever we want and if we just line it up, right, it would be right on the browser where the SSL lock ought to be. So now 4chan has SSL. So yay. The next attack will be the you, if you guys know about my interfaces where, you know, in power plants and how an operator determined what has gone wrong in a power plant system or a nuclear efficient system. So if you look at that green light it tells that, that whatever gun battle is perfectly working fine but I'm going to change that too. Right, so what if we were able to show the different status of the industrial control system just by changing the pixels that said this pump is good, this pump is bad. What if we are able to change the operator's behavior just by changing the pixels on the monitor, right? We have a fundamental trust of, you know, we trust that whatever pixels coming out of the computer would be displayed on the monitor and we're seeing that this is actually not even true. Okay, so the last one I'm going to do is we're going to show the Blinky pixel command and control, the thing that we talked about. So on the left side, right, we have a PayPal page or a PayPal account. I don't have any money in this PayPal account which is really sad. Jaiden's going to change that for me, right? I'm going to put how much money do you want? Like a million dollars. Okay, let's do it. One million dollars. All right, so I also gave it SSL protection at Fishing Page. Right, there you go. And I put a million dollar on it. And the way this is working is there's a tiny little Blinky pixel on the right screen that's communicating to the monitor, telling the monitor to put this image at the specific pixel value and we can do this of course in real time. But Aang, I don't want to give you a million dollar. I want to change it now. No. No, let me let me. So what we are doing is we're gonna, so let's suppose if you're going, we're gonna send a command and control packet from our server. Okay, so anyway, that's the demo, right? And all the all the code that went into this demo is up on our GitHub. It's working, is it? Okay, yep. Yeah? Okay. No. Nope, it's working now. Okay, so I'm going to give you how much you want, whatever. No, yeah. Okay, so anyway, all the code that went into this demo is on GitHub already. The link is on. Okay, so let's talk about what this means, okay, implication-wise. You know, the first question is, how big is this problem really, right? We looked at a single on-screen display implementation for one type of monitor. You know, we certainly found some vulnerabilities in it but, you know, is this a pervasive thing? So to answer that question, we bought four other types of monitors that are very common. You know, they're on the budget end of things, 24 inch monitors that are approximately between $100 to $200. Okay, we looked at Samsung, Dell, Acer, HP. And what's inside these guys, these chips, these boards, the bad news is they're not SD micro, they don't run G code or G probe. The good news is this one is Amstar, that one is Amstar, this one is also Amstar, and so is this one, right? So it seems like Amstar is, you know, a very pervasive, very popular OSD controller that's used in the lower the cheaper segment of the market. And it turns out this really cool dude named Alex Boglin already did all the work for us. So he figured out the way to do firmware updates to all the Amstar on screen controllers. And this is actually a feature inside the Linux kernel now, right? So that's the link, this work has already been done. So it looks like the same type of vulnerability that's fundamental to the Dell monitor is also within, it's also inside all of these other Amstar monitors, which means, you know, we probably made more than a billion monitors, right? So in the last 10 years, and most of those it looks like will be vulnerable to some type of attack like this. Okay. And the next question is, you know, how practical is this attack? I mean, you guys have to make up your own mind about it, right? But keep in mind that we don't have to have any privilege on the computer in order to launch this type of thing. So any unprivileged code execution will allow permanent persistent firmware modification inside the monitor, right? And the last big question is, you know, how realistic is this fix, you know, because the way to fix this now, right, without a physical recall would be to have the vendor distribute a firmware update tool that patches some of these, you know, insecurities about firmware update and code execution. Okay. But if they did that, they would also release exactly the algorithm and the protocol for updating all the firmware on all the monitors. So this is not exactly a simple thing to do. And, you know, this is something that I would like the community to talk about, you know, is monitor security important? I think it is. How do we actually secure the monitors that we have now, right? And how do we build more secure monitors in the future? So that's pretty much my presentation and I have to say this, you know, we're from Rebel and Security. We do embedded security stuff when we're hiring. So if you want to do this type of research, get in touch with us. And also, big thanks to Connor Abbot who did a lot of the demo code, Bob, Jewel, the stuff that wasn't terrible. And Brian also helped a lot in the front row. So thank you very much. This is where the code is for all this work. Check it out.