Hey everybody, this is Anqui and Jatin Kataria. They want to talk to you about a monitor
Darkly. Give them a round. Come on, congratulate them for getting up here. Vegas. Thank
you. Alright, we're gonna get stuff shown on the monitors. It's all gonna work. Alright.
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. Okay, my name is Ang. Jatin is underneath this table. He
will sometime reappear for this talk. We have a very strong Canadian named Francois, who
we worked with, but he couldn't show up to this today. We have a person named Igor, which
we'll talk to you about in a minute. And then we have this guy here. He's a really
cool guy to talk about. We have a very, uh, a concerned area man named Chris. And, uh,
last but definitely not least, we have area man of concern named Shakiv. And if you see his face
on your monitor, things are really gonna be bad and he's actually in the, in the audience
today. So, watch out. Alright, 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, uh, you know, motivation for why we are interested in monitors.
You know, a good hacker, right, is a lazy hacker. And, uh, you know, you know, you know,
a good hacker. So, if you think about this page, right, uh, when you see this page, you, you
think you're talking to your bank, right, the little green pixels on the, uh, 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, and the, the money we spent to create this
infrastructure, uh, 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 have to secure, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh,
uh, uh, uh, uh, uh, uh, uh, uh, uh, uh. You know, the infrastructure for doing
certificates and all this other stuff, I would say we probably quiminatively, 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. So, we view it through this tiny
little computer with this big screen on it that we called the monitor, all right, so the lazy
hacker would say, you know, if I wanted to break the pixels that showed me green, I could either
break the security for, you know, that's, you know, built with a billion dollars of 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 uh when Jad and I got really sweet new monitors okay so we bought these things and
we said wow this is beautiful and uh as soon as we plugged it in you know we noticed uh this
really curious thing right the USB device on it said you know TUSB 3410 boot device right and
USB to I2C solution so we looked at that and we said oh it's very interesting right so like a
minute of googling later we found this really useful uh Dell forum uh response by Chris uh so
somebody asked hey you know I I don't have a driver for this you know T34 you know 3410 boot
device you know what is it for is it a problem and Chris from Dell says yeah 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 I looked at that and I said how interesting
right.
So Jad and I started thinking and I say hey Jad let's tear down this 34 inch monitor that we have
lying around.
Well we already have awesome monitors uh why don't we take that uh 34 inch which is not doing
anything.
Yeah and then we're cool with this but then Chris hears this right you know 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 and we said oh this is really the saddest thing
I've ever seen so where are we gonna find these monitors?
Why don't we go to the interns they don't need monitors and they have like Dell 2410 sitting
around doing nothing.
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 uh 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 this 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 uh U2410 ISP tool insert in circuit or in service programmer uh and then
we get you know 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 app tests and a lot of
other mystery and uh just does the firmware upgrade for you so we looked at the the output of
this program we said you know what is an app test?
Like what is this software?
What is this all about?
We started googling right we found a lot of you know the documents mentioning Genesis and G
probe and and all this other stuff and we also found these documents from you know the late 90s
early 2000s that had this 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 on monitors uh so we started
googling more right we find mention of SD micro, Interlux, Athena and Dell so we're trying to
figure out what this is all about okay uh like days and days of googling later we figured out
roughly how this happened so app test uh 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 G probe were Genesis was in 2008 later sold 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 Interlux which is partially owned by Foxconn which is then w- something that's the
Interlux 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
pern- uh monitors in the world being vulnerable today so that's you know how it happened basically
and uh we were able to get some of their IP and created this chip called the STDP6000 something right
and we had a copy of G probe right so this is a screenshot of what it looks like you know the in-
interesting thing to look at here is it the software says we can connect to the monitor via things
like serial right and also USB and uh we're looking at things like the DDC to BI right so that's
something that's important we'll come back to later so we got a copy of this from our 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 we got a copy of this from our update tool
okay so Jaden's gonna talk a little bit about what DDC is so uh DDC is like a display data
channel communication set up by uh VESA so it is uh 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 the there are multiple versions of uh DDC which exist uh there is
DDC 2B, 2BI, AB, 2B plus and what we are working with here is 2BI and which is uh a next version of
2B which works over I2C and talks to the host adapter so here is what uh initiation of uh
communication started with the host adapter to the monitor happens it sends a SCSI command uh with
the code CF uh which is a generic vendor code uh and it is wrapped over uh it's wrapped in uh
USB mass storage uh packet which is sent over to USB then uh the uh USB request block contains
a DDC 2BI packet which is an encapsulation over G-Probe packet uh and it's uh it's uh it's uh it's
a DDC 2BI packet uh to do like 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 how convenient right
and uh if we look into the G-Probe documentation right uh all of the checksum algorithms are
are laid out for you they're very simple so again we're taking messages that are supposed to go
into I2C packing it in to USB and sending it over to the monitor via the USB interface. Okay so
yeah let me show you a really simple uh communication between the host and the the monitor to
monitor. So I'll play the monitor. Jad will play the host. Okay? Uh monitor initiating
communication. Give me register read. I as the monitor say I acknowledge your request for
initiation of communication. I acknowledge your acknowledgement that you started uh you
wanted to do initia- communication. Okay I have uh acknowledged that you have run the read
register command. End of acknowledgement. Okay but we're not done yet. Right this is just a send
the command. So this is like six packets to send the command. Uh hey monitor let's do a
communication again. Uh 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
communication. Okay I have the result for you from read register. End of communication.
Goodbye. So twelve packets to get two bytes out of the monitor. Alright. But uh it works. You
know that's how 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 computer.
Okay so we read some documentation. Let's void the warranty. Let's figure out what the hardware
looks like. So we open up the back of the monitor. This is pretty typical. Right the top of the
board is where all the power stuff is and the digital stuff is on the bottom. Okay and uh here's
an architectural diagram. Right so you have the main SD micro uh 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 uh the forty fifty three. Right and that multiplexer again sits on a second I2C bus.
Which is connected to a USB controller. Right which is the thing that we're talking to. So
traffic comes into this USB controller. Goes into the I2C bus. Goes through this multiplexer.
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. Okay and that's how things work.
And uh we flip 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
rend- you know visualization of entropy. So we're able to send raw I2C packets to this machine.
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 we're you know we saw in the documentation. So there's app tests. Right?
Mentions of you know picture in picture. And things like OSD hide and OSD show. Right? So you
know 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 uh the architecture here. So we started googling around
and it seems like somebody on OpenRC in 2018. Uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh
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 uh firmware 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. Uh and then 2016 comes along. Right? And John 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 ill fucking email. Right?
And uh in six hours or eight hours Igor responds and he says like here's a long insightful
explanation of how IDA works and turbo 186. And also already disassembled this thing for you.
Simple. So this Mars hex is basically a piece of handler run on the monitor to update the
firmware on the device. And he was it was like a 200 kilobyte um I think 2 megabyte. Uh and he
reversed uh everything and uh it was perfectly uh disassembled and he gave it back to us. So we
thought like we would do something like this with the firmware on 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 segment
city everywhere and nothing worked out and I failed. And then John says let's not do that.
Let's be monkeys and press space. So we we added a hot key which uh if you add like um space
or like it jumps to different references you won't get a control flow analysis but at least it
will help you in analyzing things. So if if oh fuck he's looking at it please. Sorry. Uh so
while so we have now uh we can run code but we want to do our uh we we want to do our uh uh
we want to run some kind of code on it. Right? So we you uh we went through the G probe um
documentation and we found three commands. One is a register read which helps us to read any
registers. Run code placing uh PC anywhere we want. And uh RAM write which allows us to patch
shellcode uh into the memory. And uh there is no MMU so this is you can execute anywhere you
want. Okay. So we want so the the there's a concept of app test uh which is basically a unit
test inside the monitor. Uh so it creates a context and it uh tears down the code. So we want to
run 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 uh to see if we can do a very simple hello world. So we found there's 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 Jadon 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. Uh so we want to
uh. And I 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. Um. It will get gross. And Jadon 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
notice that mo 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 uh we thought like um
there is no reference to it and we do not understand how to get this code. So we started
dumping code. Um we um so we wrote a USB dumper and uh so we took there is there is a command
which is listed called RAM read. Uh but we were not able to make it work. Although it it works
now. Uh so we used uh reg read uh which allowed us to dump two bytes at a time. So imagine
like uh doing those twelve packet transfer to get two bytes out. Uh so uh I wrote a memory
dumper which allowed us to do uh one megabyte dump for eight minutes. Perfect. So we
remember those twelve commands that you had to do. Right? We're doing those USB commands for
what is it a hundred bytes at a time. Right? So. Yeah. We this is what we did. We say let's
dump. Judd 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. Like I'm going to totally do this differently. So he went off and he said I'm just
going to re-implement the UR using GPIO pins on the sock. Uh 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 UR implemented. Okay. He also hijacked standard in and standard out. So all of a sudden
we had a UR over GPIO pins on the monitor that not only allowed us to dump arbitrary memory. It
also allowed us to hijack all these these very important very useful debug messages. So it
is uh very important important to know that right now we are working with the assumption that
there is only one uh microcontroller in that sock. Uh but after dumping the F thousand range we
realize that it's actually a hardware abstraction layer to talk to another chip uh another
processor inside the sock which which uh is called OSD now. On screen display whose uh main uh
function is to display images on the on the on the monitor. But the other OCM which is on chip
microcontroller is actually talking to other device uh other components inside the sock and
other um external interfaces. So the which is uh A thousand to B thousand is mapped to uh
OCM and F uh and OSD has its own uh OSD. Uh OSD has its own uh OSD. Uh OSD has its own
code running inside SRAM uh 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 sock right and they communicate using some memory map register that we don't really
understand yet. And uh 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. Doc 88 which is a place where people upload you know awesome proprietary
documents for the internet and stuff. And uh we're now working with just one processor. So
you'd probably want to open this in a VM. But uh it did give us the exact data sheet for this chip
that we're working with. And from there we found pretty much everything we needed to know about how
this chip works. Uh and we were right about this assumption that there is an OCM and an OSD chip
and or OSD processor and they're completely separate and they work more or less asynchronously
from each other. Okay so now that we have the data sheet we've done all this stuff you know let's
try to display a picture right? Let's get that to work. First uh there are three things we have to
solve and if we solve these things we we got picture to solve. So let's try to display a picture
on display. Okay? We 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 uh when you start boot a Dell monitor right? Like
if this image comes up. So uh 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 uh I uh we had uh so uh
sober and professional. Very sober professional discussion about it. Very sober and professional
discussion. Yeah. And uh after a few hours we came up with our own analysis and uh we both said
that this is not a Dell 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 to your brain. Um okay so then you know front spot comes along right? And uh
we you know. You know after like after a few days uh he came up with me like multiple megabytes
of data to stare at and uh I looked at it for hours and uh duh. Come on that's obviously an OSD
command packet. Uh. Right I mean don't you see that? Obviously right? This is just you know in
memory at run time right? Just a big old blob of binary and John stares at this thing and he says
obviously this is this structure. So uh 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. Uh and uh what we understood after a lot
of reverse analysis uh of the um IROM which is the hardware abstraction layer uh 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 uh as along like uh as OSD is
working asynchronously uh.
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 uh the APIs which were used to do this was SD RAM read uh 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 uh box blinking program I have ever done. And if
you look at it for hours you I have definitely vomited once.
Uh hold on. Wait.
You gotta see it. You guys all have to watch this with us now. Wait. Hold on. Why isn't it.
So you will see.
No. It doesn't want to play. Hold on. No no. You're not gonna get.
It doesn't want to come up.
You're not off the hook. You gotta watch this video.
Okay. So as you see that the block I'm able to like move the box around anywhere on the screen.
And uh.
It's so nauseating.
There is there was a blinky bug which I figured out after a week on.
Alright. But this is after days of looking at this nonsense.
So the last question we have to figure out you know what is a color right? I mean is it 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 0, 1, 2, 3, 4, etc. Uh so instead of
getting very similar colors we got these colors right? So you know why is color 0 basically the
same as color 2? Why is 1 totally different? Okay. And uh we didn't really know. Let's do some
science. We take a tiny little microscope and we point it.
Add specific pixels in order for us to figure out what you know color gets rendered into what um
pixel value. So we filled it 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, 0x6 uh 00. So John how many bits are there?
How many bits does the monitor use to represent each color? So if you see 0 represents
transparency and there are 2 pixels missing. So it's 4 bit per pixel. Right. And then. How do you
encode colors with 4 bits right? In normal RGB world each color each component is represented
using 8 bit and there is an alpha component uh so it represents a 32 bit color. So how do you do
this John? Yeah. So right if you have 4 bits then you can have 1 bit for R, 1 bit for B you
know etc. And that's clearly not what's happening here. So if you have 4 bits then you can have
32 bit colors. So it turns out this monitor uses a thing called color lookup table which is
basically this index structure right? That uses 4 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. Um so now the big question is how where is the lookup table?
Can we change it? Can we modify it? Uh 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. And then we did a
lot of work with him to try to figure this out where he dumped lots of memory and we helped a lot
and uh like 2 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 transferring the images in the command package so
you you generate a specific color lookup table structure and you write it to the OCM memory uh
memory map that uh 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. Display images. And we did it. Okay so look at that.
We have tiny little SSL logs. We have as many as we want wherever we want and that was sort of the
point of this right? Uh but I looked at it and I said we still have only 16 colors and that SSL
log actually had something like 20. 26. 26 colors. So that's not enough colors John. We
gotta get more colors. But it is really hard. It has been really hard now. Yeah. So we went
through some docs and uh we figured out like uh it the hardware does support at least 8 bit per
pixel. So uh and and till recon we didn't have we had only 4 bit per pixel but now we have uh
fixed up to get 256 colors and the code is submitted into GitHub. Uh but after going over more
analysis of the documentation the register documentation list we found we we found a break
point. So which means that we can halt the monitor, figure out everything and this is after
like 90% of the research we have already done. And we have spent like weeks on it uh even
months and now if 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 the air and was like oh I can't believe we missed that one right? 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 and friends will help. So the interns went out uh dumped the
stack dumped the heap you know found pretty much everything we needed to do all the demos that
I'll show you later. Uh 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 on the screen but it should it is
very surprising that it has the capability to read pixels anywhere on the screen. Yeah. So we
presented some of the research uh 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 I2C channels on uh DVI, HDMI and VGA etc. So we actually
ported the code to run over the I2C interface and now our demos do not require USB at all.
Although it can be done over both channels. Um and that stuff is unquestionable. So we
decided to build it up 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 can 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 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.
Uh now so in the end what do we do? Okay. We figured out that we can change whatever pixel on
the screen whenever we want. Uh we can also see every pixel on the screen which is really
cool. And uh for those folks who have followed our previous research we even got Fontana to work
on the monitor as well. But that's it's own conversation that we'll have later. So you know
enough talk. Right. We're gonna do some demos. Okay. Uh and then first I have to figure out how
this works. Huh? No you gotta. We swear there's an actual monitor underneath this table and
the demo is now rigged. Uh but shooting a camera at the monitor is a little bit difficult. So
does it work? I think your. Yup. You have to put on like this thing. This thing. Wow.
Alright wait there we go. Alright. Okay. So I'm gonna talk at the table. Yeah. So first I'm
gonna show you how to put random people. Uh. Uh. Uh. Uh. Uh. Uh. Uh. Uh. Uh. Uh. Uh. Uh. Uh. Uh. Uh.
Uh. But we are gonna do theunching. This emικ we're the I faster for you. Now I'm going to
you the game screen. Obviously I'm gonna put these específic pictures on the screen and you can
uh not remove it. So I'm going to so this is shakeeb as we talked about. And his picture is
gonna be on the monitor. So this is a typical you know is an even machine no uh administrative
privilege and we're just showing you know putting up image on the screen. Now we didn't do
this in Git hub but we can actually make this permanent. So imagine if that happens to you how
terrible your life would be. So my second attack will be you all know about 4 Gen right? And it is
not uhh enter anything before 4 Gen. For example if you get onto your computer to dosta data if you
uh it doesn't have any TLS uh capabilities but I'm gonna give it to you. We're gonna 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'll be right on the browser where the SSL lock ought to be. So now 4chan has SSL so
yay. Uh the next attack will be the you if you guys know about HMI interfaces uh where you
know in power plants and uh how an operator uh determine 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 uh that
uh whatever gun barrel is perfectly working fine but I'm gonna change that to. Right so what
if we were able to right 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 were able to
change the operators behavior just by changing the pixels that said this pump is good this pump
is bad. What if we were able to change the operators 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 will be displayed on the monitor and we're seeing that this is actually
not even true. Okay so the last one we're gonna do is we're gonna show the uh the blinky
pixel command and control thing that we talked about. So on the left side right we have a
paypal page or a paypal account. Uh I don't have any money in this paypal account which is
really sad. Uh Jadon's gonna change that for me right. I'm gonna put how much money do you
want? Like a million dollars. Okay let's do that. One million dollars. Okay let's do that.
One million dollars. Alright so I also gave it uh SSL protection that phishing 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 this specific pixel value and uh we can do this of course in real
time. But Ang 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 uh we're gonna so let's suppose if you're going we're gonna send a
command and control packet uh from our server. Oops. Is it even working? My server has gone
down.
Okay so anyway that's the demo right. And all the uh all the code that went into this demo is up on our github.
Oh it's all it's all. It's working? It's working? Okay yep. Yeah? Okay.
Okay.
Oh.
Uh.
It's not working.
Uh.
Shit.
Shit.
Okay.
Okay that's it.
Now. Yep. It's working now.
Okay. So I'm gonna give you how much you want whatever to.
Now yeah.
Okay so anyway all the code that went into this demo is on github already. Uh the link is on the slide.
Okay so let's talk about what this means, okay. Implications.
application-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. Uh, 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 mon- inch monitors that are approximately between
$100 to $200. Okay, we, we looked at Samsung, Dell, Acer, HP. And, uh, what's inside these
guys? Uh, these chips, these boards. Uh, the bad news is, they're not, uh, SD micro, they don't
run G-code or G-probe. Uh, 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, uh, you know, very
pervasive, very, uh, popular, uh, OSD controller that's used in the lower, uh, 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, uh, do firmware updates to all the Amstar
uh, mic, uh, on-screen controllers. And, uh, this is actually a, a feature inside the, uh, the
Linux kernel now, right? So, that's the link, this work has already been done. Um, 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've probably made more
than a billion monitors, right, in the last 10 years. And most of those, it looks like, will be
vulnerable to some type of attack like this. Okay? And, uh, the next question is, you know, how
practical is this attack? And, uh, 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, uh, on the, 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, uh, the last big question is, you know, how
realistic is this fix? You know, because I, 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. Um, and, uh, you know, this is,
um, something that I would like the community to talk about. You know, is monitor security
important? I think it is. How do we actually, uh, secure the monitors that we have now, right?
And how do we build more secure monitors in the future? So, uh, that's pretty much my, my
presentation. And, uh, I have to say this, you know, we're, we're from, uh, Rebel Insecurity. We
do embedded security stuff when we're hiring. So, if you want to do this type of research, uh, get
in touch with us. And also, big thanks to Con, Connor Abbott, who did a lot of the demo code. Uh,
Bob drew all this stuff that wasn't terrible. And, uh, Brian also helped a lot and he's in the
front row. So, thank you very much. This is where the code is, uh, for the, all this work. Uh,
check it out.
Thank you.