 Hey guys, thank you for coming to our presentation. It's called keylogger video mouse or how did we turn our KVM into a raging keylogging monster. So before we begin, meet the team. My name is Yaniv Balmas and joining me in this project is Lior Offenheim aka the mid scientist and we are both security researchers and both work for checkpoints of technologies. So let's dive right into our problem. So our problem as with many other computer science problems starts with computers. All right? So we have computers. We have many computers. We actually have a lot of computers, right? And the problem is that each of these computers actually needs a keyboard, video and mouse set in order to operate, right? And when we have a lot of these computers, then we also have a lot of keyboards, a lot of videos and a lot of mice. And this creates a whole lot of mess on our desk, right? So we can't figure out which monitors goes to which computer and which keyboard should we use and so on and so forth. And the thing is that this is an age old problem and it was actually solved by this little device called a KVM. Now for those of you that are for some reason not familiar with this device, then KVM is practically just short for keyboard, video and mouse. And what it does is it's used to connect the same set of keyboard, video and mouse to one or more computers, right? So it all works something like this. You have two computers underneath your desk and they are both connected to a KVM device which is again connected to a keyboard, video and mouse set on your desk. And now everything is routed to computer number one and everything is cool. You consider your office and play your favorite video game and suddenly your boss steps in the office and you just manage to push the two button and boom, catastrophe is avoided, right? Everything is now routed to computer number two. So that's pretty easy and that's how it works. So where can we actually find those KVM devices? So we can find them on your desk such as the example I just showed you before or we can also find them inside your server X and that's practically because, you know, a server X holds like something like eight servers, let's say, and it only makes sense to put a KVM in there in order to avoid having, you know, eight sets of keyboard, video and mouse inside there. And last but not least, we can find KVMs in very secured environments, right? And that's mainly because in those environments we usually have several networks. Some of them are pretty sensitive and some of them are just a corporate network connected to the internet and, you know, for a user that needs to work on some of these networks at the same time it only makes sense to have a KVM on his desk, right? So to sum it all up, KVMs are everywhere. I mean, in every technologically rich environment you ever go to you probably find a lot of these KVMs just laying around here and there. So let's take a look at evolution of KVMs along the years. So it all started off in the 1980s or 1990s with something that looks like this. It's commonly known as an A-B switch and all it is just a stupid electronic box used to connect electronics from the A-port to the keyboard, video and mouse set and when you switch to the B-port everything is routed to the B-port, right? Stupid electronic boxes. And that actually worked pretty fine. I mean, that's until technology advanced just a bit and most notably came to be USB keyboards, all right? Then when we have USB keyboards KVMs need to be evolved also and that's how we met these modern KVMs. They actually contain some kind of, you know, USB stack in order to provide like smooth transitioning between the ports and a lot more other features like, you know, DVI outputs, HDMI outputs, they like support million types of keyboards and all that stuff and then the next evolution of KVMs is when we met this stuff called Matrix KVMs, those are huge machines. They control thousands of computers and use really big environments, right? So obviously we can see that KVMs really evolved a lot along the years, right? But the problem is that a lot of guys still consider those as those same old stupid boxes, right? But obviously, you know, they are not those stupid boxes because, you know, take a look at some of these KVM features. I mean, they have configurable hotkeys and on-screen display menus and they have web menus inside them, right? So obviously those devices now run code, right? There are actually many computers sitting on your desks. So merely over sitting there and thinking, I mean, okay, so if they run code then what can we actually do with them, right? So what is the one common thing between all the features I just showed you? So the one common thing is that all these features actually require the KVM to be able to process keystrokes, right? They don't just take the keystrokes from the keyboard and pass it on to the computer. Now they actually have to parse it and see what it is and maybe that's like a hotkey combo that you just press or something like that. And the thing is that if they process keystrokes then theoretically all we need to do is to find a way to alter the execution flow just a bit and find some kind of free memory space in there and then we can store those keystrokes over there and when convenient to us we can just dump them out. And so we effectively achieve the keylogger, right? I mean, how cool would that be? I mean, that's not a software keylogger obviously because no software is actually running on your computer, right? It's like running in ring minus four. I kind of lost track of the rings during the past few years. And on the other hand, that's not a hardware keylogger either because there's no hardware modification involved in this. I mean, you've connected a perfectly legit KVM to your computer, right? So that's really cool and that was our research subject. So, sorry for that. I think there was a funny meme here. And so what we did is I obviously didn't want to work on my KVM because I kind of needed it. So I went to our health test department and told them, you know, guys, my KVM kind of broke and, you know, I need a new one. And I said, okay, just grab this one from over there, grab this box and take it. So, yeah, I took it and I went to my office and opened the box and started unboxing it. So, first thing I take out of it is a KVM, well, that's luckily. And then there's some KVM cables and one strange cable that looks something like this. And manuals, warranties and a CD. Now, the CD actually contained a few interesting files. One of them was called the firmware upgrade utility, which is pretty cool. And the other file very conveniently named firmware dot bin. So we were thinking, okay, okay, so this file actually had like a really high entropy level. So it was probably compressed, but we couldn't really decompress it with any, you know, metal we tried. So both me and Lior are pretty advanced X86 guys and says this whole thing runs on Windows system. Then we said, okay, we can probably try and reverse engineer this and try and extract the firmware out of it, right? So that should be a pretty easy task and challenge accepted. Although when we tried to statically analyze this firmware upgrade utility, it turned out not to be such an easy task. And that's because we kind of figured out that this utility is actually used to upgrade the entire line of KVMs. I mean, it contains like thousands of functions. And on top of all that, it's like a C++ code full of v-tables and really, really messy thing. We didn't really want to mess around with it. But when we ran it in a debugger dynamically, then we quickly saw exactly what we expected to see. I mean, this thing actually reads this firmware dot bin file and then passes it on to some kind of decompression function and then stores the output at some kind of memory space. So we went to this memory space and looked at what was stored in there and really hope we can now find our firmware, right? So this is actually what we found, a blob. And it looks something like this and this is kind of its image representation, right? So we started looking at some of these blob features. So one of them is that this blob is a 64K long blob. That's pretty good. The other thing is that now it has a really low entropy level. So that kind of means it's no longer compressed and also probably not encrypted. And then it has no strings, absolutely not even a single string. Now, that kind of looked a bit strange to us, but we kept on going. So we made some frequency analysis on this and tried to compare this with other firmware and other assembly frequency analysis. And well, nothing even came close. I mean, nothing. So what we did is use BeanWalk. And for those of you who are not familiar, that's just a tool used to like find signatures of known firmware, known assemblies, really cool tool. And we used this on this blob and got absolutely zero results, nothing at all. I mean, then we were just sitting and staring at this blob and saying, well, we don't know what to do with it. So we must find another way. So that was a complete failure. So at this point, we kind of have two options. One of them would be to go back to the firmware update utility and start actually reverse engineering this. But that would probably be a really tedious job. Might take us days, you know, weeks, maybe even months, and we don't really feel like doing it. And the other option would be to be a bit creative about it. And by being creative, you must first understand how the firmware upgrade process actually works. So remember that cable I showed you before? Well, that's actually the serial cable connects to your RS232 port on your computer and then connects, this thing connects to the KVM. And then you run the utility and hopefully it somehow processes this blob and passes it to the device on this cable. So all we need to do is just to download some kind of serial sniffing software and try and sniff this thing here. And then hopefully we could, you know, probably just have to analyze the serial protocol and extract the data from it. And then we don't really need to reverse engineering anything. And that's pretty cool. And that's exactly what we did. So challenge accepted. So we started sniffing the serial protocol. We're sniffing it. Sniffing, sniffing. And that's what we get. All right? So what you see here is the serial protocol and messages marked in red are from the KVM and yellow is to the KVM, right? So let's start analyzing this thing. So first thing we notice is that each of these messages has some kind of fixed header to it. All right? And that fixed header has the X value of 4655, 55, which is the ASCII representation of a few. All right? So we were thinking, is anybody actually trying to tell us something here? And yes, well, obviously they are trying to tell us something. They are telling us this is a firmware upgrade. What were you thinking? So feeling a bit amused about all this, we just kept on analyzing this. And next thing we notice is this is some kind of up code. It goes like A0, A1, A2, A3, A3, A3, and actually most of this is composed of the A3 messages. So what this tells us is that this part must be some kind of handshake, right? And this part must be the data transfer and that's the part we're actually interested in. So keeping on analyzing this, we can find some kind of sequence number in each of these data messages. And it goes like its incremental number goes from 0, 1, 2, 3 up to the end of the file. And that's cool. And now there's only one thing missing because each serial protocol actually needs to have some kind of checks and value to it, yeah? In order for both sides to validate that the data actually get intact from side to side. And this is actually the last byte of each message. It's just an accumulative store. And that's our checks and value. And at this point, we couldn't find any more patterns, nothing. So we figured out that everything is now probably analyzed. So all we have to do now in order to extract data from it is get rid of the handshake part, right? Then take a look on the data part and then again get rid of all the serial protocol related bytes and just put it all together and now hopefully we have our firmware, right? Well, guess who? It's the same old serial blob. I mean, all these devices, all these firmware upgrade utility did is just take this blob and pass it to the device on the serial cable. So again, this got us nowhere. I mean, obviously everything is happening inside the device. So, you know, next logical step, the only logical step is, yeah, we failed to open up the device. So that's exactly what we did. We opened the device and it looks something like this under the hoods, right? Now, our first impression of this is, you know, hey, we are software guys. What are we even doing, looking at something like this? I mean, that's a whole lot of electronics in there. What can we find out, I mean, from this? And we felt a bit depressed about it. Then went to the bar just opposite of our office, you know, had a few whiskey shots and then, you know, set it to each other, you know, yeah, we might not be hardware guys, but we could try, you know, obviously there's some big chips over there. So we can try and find out what they are and maybe it will give us some kind of, you know, view about what's going on, how is this firmware actually being processed? So after a slight hangover, we did just that. So first thing we know, there's two big chips over there and we know nothing about them. It's the vendor name engraved on them and, you know, just judging by the amount of pins they have, we think they are A6 but we don't know anything more than that, so they are just big black boxes to us. The other thing is a commercial chip. It's called PLD. Now, a PLD is a programmable logic device and what it is, just if you're a PLD programmer, you open up a UI, you design your own logic circuit, then you burn it into the chip and then the chip runs the circuit, right? That's pretty easy. So we know it's a PLD but we have no idea what's the logic circuit running inside it. So you can say that's another black box for us and then we kept on going. And we found actually something we know. I mean, that's memory. It's a 2K external RAM. We know what it does. You write stuff to it and read stuff from it and we were kind of happy about it and it's also connected to something called a Dilege which again, you know, I remember from my university days something about flip flops and Dileges but at this point I have no idea what it does. Anyway, we just left off with one chip over there which actually turned out to be the most interesting chip of them all. That's an AD52 processor. Now, for those of you who are not familiar with this, AD52 is kind of the advanced version of AD51. It's an Intel-based chip and it actually runs Intel AD51 assembly which is a pretty easy assembly to learn. And the thing is that this is really common in the embedded world. I mean, you can find these chips anywhere from like toasters and up to space shuttles. It's really that versatile. So, okay, we now have everything mapped and now we need to understand how the firmware actually flows inside this PCB. So we know that it goes into this serial port and then it goes somewhere into the device but where? I mean, it can go and update this AD52 chip, right? But it can also go and update those A6 chips or, you know, maybe some kind of combination. Maybe chunks of it go to each chip. Maybe it goes to one chip and then to the other. We don't actually know. I mean, that's a big mystery to us right now. And what we did in order to solve that mystery is to Google it up. And when we did it for some reason, we can find this PCB which is the same KVM as we used. Only this one has eight ports while ours has only four ports, right? Same vendor, same everything. And look at it. I mean, there's something really interesting about this because you see those big black boxes I talked about? There's two of each now, right? So eight ports, double the ports and two of these chips. And the PLD is just the same. Two PLDs. However, there's only one external RAM and there's only one 8052 chip, right? So this is like a eureka moment. And we're thinking, okay, so maybe this 8052 chip is actually the brains behind this entire KVM. And maybe this entire blob is just going in there. I mean, so cool. So now all we need to do is to understand how are these 8052 chips being upgraded? So it turns out that each of these 8051 or 8052 chips has an integrated UART port in them. And UART, again, for those of you who are not familiar, is just acronym for universal asynchronous received transmit, I think. And what it is, just a generic serial protocol. And so now we just need to understand which IC pins, which of the chip pins are actually responsible for this upgrade process. And in order to do that, we can just go to the specs. And when we did that, we just saw that the UART port is connected to port three of this chip. And those are the RX and T expense that are used for the firmware upgrade process. So cool. Now it's just a matter of using just a bit of logic and finding it out. So challenge accepted. So 30 to 45 China mail shipping days later, we can finally use logic. We ordered this device. It's a logic analyzer and it's actually called logic. And what it is, is just, you know, it has a couple of wires there with clips. You clip them onto the IC pins and then you can see the electronic signals going on it. And that's pretty cool. So what we need to do now is to use this logic analyzer, tap those pins and just look at the signals going on there during the firmware upgrade process, right? So it looks something like this. We actually connected to the RX port, the X port, and the other one, if you were wondering, is just ground so we can differentiate ones and zeros. And doing that, we opened the logic analyzer UI and took a look at the results. And this is what we see. We have packets going to the UR port, sorry, from the UR port and packets going to the UR port. And if we zoom out of this entire picture here, then we can see an obvious pattern, right? These lines are actually going to the UR port and these are going from the UR port. So it's from the UR to the UR, basically a serial protocol, right? So now all we need to do is just to take all those signals and put them in the right order and then hopefully we can see a serial protocol going into the UR port containing the actual firmware, right? Does that look familiar? Well, yes. That's exactly the same serial protocol that we just seen before. So again, that's a great failure. I mean, what can we do now? I mean, we practically did everything and now we need to open up the chip and we don't really like messing up with chemicals and stuff like that. So we at this point thought that that's a complete failure. But then we gave it a second thought and we said, hey, there's something now that we know now that we didn't know before. I mean, before that, this big blob, we didn't know what it's being translated into. I mean, it was a complete mystery. And now we're kind of pretty sure that this is being translated into 8051 assembly, right? Because it's going into the 8052 chip. So if that's the case, then maybe we can, you know, some kind de-ophoscated ourselves and actually get the firmware, right? So I'm not a big code breaker, but I do know one really good code breaker. His name is Lior. He is a bit mad, but that's okay. So I went to his office and gave him a promise of a Vegas ticket, and I got him to join the project. So please welcome Lior. Thank you. So let's do a quick recap of what we already know. So again, as you said, this blob is somehow translated into 8051 assembly. That's our assumption. And also, this translation is happening somewhere inside this 8052 chip. So all we need to do is somehow break this office. And it's important to say this is, again, it's not encrypted, it's not compressed, so it's kind of some sort of an obfuscation scheme. So all we need to do now is just try and break the obfuscation. Challenge accepted. So let's remit the blob. So this is the same blob as before. But now let's take a look on the end of the blob. You see, in the end of the blob we have this padding byte, which is 53, almost to the end of the blob. And, well, you think to yourself, well, this might be like zero padding. It should be a zero padding or it might be like a knob slide in the end of the firmware, which is, we know it's common. But luckily for us in 8051, knob is equal zero. So it's the same operation. So all we need to do is like take this blob, sorry, with 53, and then we get this. And maybe this is it, maybe we've done. So I don't know, let's take this blob and open it up in IDA. And this is what we get. So at first glance, it looks like really good. You know, IDA managed to disassemble all the binary and even found all the function. But if you take a closer look, you see that something here is definitely wrong. You see that the last two lines are move A comma R6. It's happening twice in a row. Like maybe in 8051 you need to do everything twice in order to make sure it's actually happened. I don't know. But you know there's something here that's definitely wrong. So we took an IDA binary, and we opened it up in IDA as 8051 assembly, and we got the same picture. And of course, is not an 8051 binary, it's like x86. So we have like this strong assumption of what's going on here. But just to make sure, we took this picture of a cat, and we opened it up in IDA. And guess what? The same thing all over again. So then we realized that if you believe hard enough, everything can be 8051 assembly. Yeah, but it doesn't help too much. So we're back to our blob. And we decided to keep this XORing operation because we thought it's like, it's a move in the right direction. What's happening here? I was, okay. So it's a move in the right direction. But now we can take a look on this last 8 bytes. You see the last 8 bytes are different. They are not the padding one. And let's take a close look on them. So we said, what does this 8 bytes mean? Are there some clue left us by something better? Oh, we are safe. Thank you. I kid you not. I have somebody else's bag. I'm like, the fucking bottle's not in here. And then I'm like, and in fact, none of my stuff's in here. So I have a bag for sale. We'll be right back. Safe with the bag. Okay, so try to keep outgoing. So is this some clue left us by some adding better developer? I don't know. But at first we thought, well, this might be some sort of a checksum, some error correction. And so we took this byte, this last 8 bytes and we tried to calculate the checksum of the blob and also the CRC and some other algorithm. And none of them was like even a close match to our byte. So as far as we know, it's not some sort of error correction. And then we thought, well, right until now we only analyzed a single version, like the one that came with the CD, a single version. But we know that in the vendor website there are many more. So we decided to download some of them and let me show you this table of the last 8 bytes of like many different versions. And you see that these numbers are not random. Like, you see that this A1 byte repeating almost 70 times. So it's definitely not random. So we're thinking that these bytes somehow represent some data. But again, it's office head. So we can't see what it is. And then there are like Eureka moment came when we decided to take these last 8 bytes and list them next to the firmware versions as stated by the vendor. And then we saw some pattern like forming up here. Like, you see this byte 99, the byte 99 appeared 3 times in the first row. And also number 3 appeared 3 times in the corresponding firmware versions. And the number A1 appeared twice in the second row. So it could be the 4 or the one who appeared twice. But it's the 4. And why is that? Because it's consistent throughout all the different versions. So we did some work and found the mapping between every value from the 8 bytes and the corresponding digits. And then we like, we didn't know what to do with it. And then we thought like, let's take this value and also see their binary representation. So this table is consistent of the digit, the hex value, and the binary representation. And you see here that there is this constant, like this portion of the byte who is like constant. And also there are 4 bits in the middle who are keeps changing. And not only they are changing, they are incrementing. You see they are forming the solve of the counter. Well, the counter in the middle of the byte, it's pretty weird. So we thought, well, maybe we should like, rotate the entire byte like 3 position to the right. And then the counter will move to the right end of the byte. So we did just that. And then we got these hex values. And, you know, I guess that most of you recognize these hex value. But for those of you who don't, those are ASCII values. And not only they are ASCII values, they are the same, they are ASCII values that we want. They are mapped exactly to the digit that we found earlier. So now we know that this operation, like, it sounds pretty good. Let's do this operation on the entire blob. And when you do this, you get this, the blobs change. And now we actually have, like, strings. I don't know if you can see from here, but there are actually strings. Like, this string who is like, looks like a base 64 or like alphanumeric string. But you can see that it looks really good. But the sequence, you know, the sequence of the byte is not correct. So let's take a closer look on this one. So this is the 24 bytes long from the string. It's from the, oh, here, here there. Okay. I'll try and continue. So it's 24 bytes long string. And it's divided into an 8 byte chunks. And what I mean by that is that some of the characters are misplaced, but they are only misplaced within their own chunks. So let me try to explain this better. You see that the A, the I, and the Q in the first position are in the correct position. So let's just move them down. And the G, the O, and the W in the second position should be moved to the seventh position. And the C, the K, and the S in the third position also in the correct position. The fourth should move to the sixth, the fifth is in the correct position. And from there on, and that's it. We found a correct dispermentation which fixed the sequence of the bytes in these strings. So let's take this permutation table that we found out and operate it on the entire blob. And guess what? We actually managed to completely break the obfuscation and we actually got meaningful AD51 assembly. Thank you. And guess what? We have a tradition here at DEF CON for first time speakers. These guys got in. It seems like they're doing pretty well. You guys liking this talk? To DEF CON, to the new speakers and all your new attendees. Good job. Wait, hold on. String assembly. Yep. That is what it is. So yes, it's an actual assembly with loops and control flow and what not. So we know that now that we break the obfuscation. So now let's have some fun. So we know how to break the obfuscation scheme. So we can now design our own custom firmware and implement our keylogger inside it and upload it to the KVM. But first we need to learn like me and Eva, X86 guys, so we need to learn some AD51 assembly. So for your convenience, we did the AD51 review. So on the plus side, as you know, it's a very like easy to learn assembly language and even many students learn it and it has like only 40 instructions. On the downside, I don't know if it's a compiler problem, but some functionals are not really functional. You see the code jump to the middle of the function and some function doesn't do all the logic it's supposed to do. It's really hard to reverse. And also there is just a single memory access register and what it's called like the firmware keeps back up and restore this register and it discards all this code mayhem and also it's pretty hard to reverse. And in the end, the register keeps on changing and this is happening because of the code banks in AD51, register banks, sorry. And so it's like replacing between different banks and you need to keep tracks of the value of the register. So in the end, we decided to give it one and a half stars out of five. Like we appreciate their effort, but X86 is much better, so we'll stick with this one. But now let's take a look on this, the actual code. So this taken from either, this is like the visual representation of the main function. So let's take a look at it. And so this part is responsible for the heat parsing. Heat is the human interface device. It's responsible for passing the inputs from the keyboard. And this part is responsible for the hotkeys handling. You see like, you can, when you can like press some keys and it will change the ports. And this part on the bottom is responsible for the LED control. In some of the KVM operation, it can actually change the LED on the keyboard. So this part is responsible for that. And this is the interesting part. This part is responsible for the keyboard emulation. And what is so interesting is that at first we thought, well, we should implement a key logger. It's pretty like it sound, it sound trivial. But now we know that the KVM is actually capable of emulating keyboard and not only read the keyboard inputs, but actually type to the computer its own key strokes. We can implement some sort of a rubber ducky, you know, like bad KVM, bad USB stuff on each and every port. So let me show you some scenario where we can use this ability with this malicious KVM. So let's say we have an internet connected network and also an air gap network. And let's say like this security expert spends hours and hours in creating like a secure interconnect ability between the network to prevent any misuse. But in the end a user has to computer, one internet walk. And each of this computer needs to have a set of keyboard, mouse and screen. And of course this user is very upset, it's created a lot of messages and test stops, so let's go to the purchasing department and ask them for a KVM. And they give him one and you connect this KVM to the network and now you only need one set of keyboard video and mouse. And what would happen if this KVM is somehow infected with our malicious firmware? Let's say this malicious agent can wake up in the middle of the night and start typing things to the internet connected computer. So some of you might ask, well of course this computer is password protected. But I'll ask you how do you insert your password to the computer? Of course using the keyboard which is connected to the KVM. So we know the password. So we can just log into the computer and type some evil command which will download a malware from the internet to the internet connected computer. And now we have a complete persistency over this computer. You see you can reboot your computer, you can format it, you can even change it completely and we can still infect you every time we want from the KVM. But that's not it. Our malware can actually type itself to the memory space of the KVM. And from there the KVM can change for to the air gap computer, the simple secured one and type the malware back. And now we have two malware on each of the networks. And using the KVM we can actually connect these two malware and back to the CNC server in the internet. So the CNC server can actually control using the KVM the malware inside the air gap computer. And you see this completely breaks every network segregation of course. So I want to show like a quick demonstration of this scenario. So what you should hopefully see on the screen on the display in just a second. This guy can code break, okay? But he can't connect the display for just a second. Can you see it? No? Yeah. Maybe it's the KVM. Ah, okay, okay. Yeah. So what you see here on the screen is actually the internet, I'm sorry, that's the super secured network computer, okay? Okay, because the most like difficult part of our writing this malware KVM is to actually transfer the file from the internet connected computer to the super secured computer. So Lior has the internet connected computer over there and it will just start our malicious KVM in just a second. No hands. Yeah. Yeah. So what we're doing now is using just a really neat trick of creating a certificate using base 64 string and then using the integrated cert detail to like decode it again and make it binary, right? So we're actually typing the binary file that we want to transfer from the internet connected computer to the super secure network. Now this would take just a few more seconds. So roughly 20 minutes. 20 minutes? Okay. We have time for that, no? Okay. So an interesting thing is how do we do the uplink and the thing is that we actually use the keyboard leds for that. I mean the keyboard leds has some space in it that we can actually pass bytes back and forth and you know there's actually more than three leds. There's like something like five leds because two of them are Japanese or something like this. Yeah. So we have pretty much space there and we can transfer data back and forth from both the computers through the KVM. So that's what you see right here. And it feels like it's gonna end just about now. You have any jokes, Lior? No? Right out of jokes. Sorry. Yeah. That's kind of the end of it. And that's it. We write it all to encrypt the .txt file. Then end our certificate and use cert detail to decode it. Now we have a binary file and we run it. That's it. So the KVM can do one more thing. Hopefully. If it works. Yeah. Hey. Back to our presentation. Yeah. So yes. A lot of you guys are probably asking, yeah, well you needed to have physical access in order to do that. And the answer is yes. I mean our research, our POC actually use physical access. And there's two things, you know, two attack vectors that are possible in this scenario. One of them is, you know, hey, just give me 30 seconds alone with your KVM and it's kind of hacked. And the other is, you know, you can always attack the supply chain and we've actually know some, you know, incidents where this actually happened. And another thing is that, you know, actually we use the KVM that doesn't have any update over Ethernet and over IP. But the same vendor and lots of others actually have those. So this can theoretically be upgraded using IP and then it can be attacked remotely. And also some of these KVMs actually have, you know, web menus that let you do the firmware upgrade process and they are password protected. But, you know, KVMs are really not expert proof. I mean, just, you know, googling up quickly, we found, you know, all of these CVEs that are related to KVMs actually broke the web menu and let you upload your own firmware. So this can theoretically be done remotely, right? And what can you do? I mean, well, first of all, know your environment. I mean, you know, sometimes you don't really have to connect the KVM between an, you know, Internet Connecting Computer and Super Secure Network. So just know that this is a vulnerability. I mean, this can be done. We just showed you this. So if you can avoid it, then please, please do. And sometimes, of course, you can't avoid this. And when you can't avoid this, you have these little creatures called secured KVMs. They are actually military-grade KVMs, although I know no one that actually uses them because they cost like 10 times more than this KVM here. But, you know, sometimes it's money well spent. I think you're now convinced of that. And the last thing is, you know, just be innovative. I mean, we just said in our office and thought about, you know, what can we do in order to do that? Actually, we saw one presentation here. Defconn actually kind of, you know, maybe solved this problem. And what we did is, like, install agent on, you know, each desktop. What it does, it's basically a small keylogger and it just checks statistics of keylogging. So, you know, the thing is that we need to type a lot of keystrokes really, really fast. Same as bad USB and same as a lot of other stuff. And then when the statistics change and we see, like, you know, the user is not using backspaces or it's typing really, really quickly, or the difference between the keystrokes are really small, then we know something is going on and all we need to do is just to pop up this message box, which will, you know, kind of screw up the entire process and that will make our job like thousand times more difficult. So, it's not a perfect solution, but it's a cool thing and, you know, I guess we can be innovative about it. And that's it, guys. Thank you. Any questions? Yes. That was a USB, regular USB keyboard, but it could work on every keyboard. So, the question was if we used, like, a keyboard support smart cards or stuff like that, would it still work? The answer is yes. If you need to log on to the computer with a smart card or something, so it will prevent the attack, of course, but if you just password protected, so we can, we know your password, so we can log in as the user. Anyone else? Thank you.