It's Just a Keyboard, I Swear

Thank you. So, uh just just a forewarning here. Uh my demo doesn't work. I'm sorry. I tried I didn't try hard enough and it was a little too last minute, but [ __ ] it. We ball. Let's go. So, this is Well, first it's always was always always a supply chain hack. Anyway uh so I wanted to [ __ ] with a keyboard in a more than just what if we put it what if it's a bash bunny or what if it's a rubber ducky? Like I want to bake a actually malicious keyboard that is a legitimate in this case Dell B5 B522, the most generic Dell keyboard you can imagine. Uh, but what if we put

something in there that does key logging and saves all that to an SD card and Xfills over Bluetooth? Uh, and you can inject keystrokes over Bluetooth or whatever else. Um, and then a little bit about how to stop this. But the main focus of this is how to actually hide it because there's so many easy ways to detect a bash bunny. It's it's not even challenging. I'm Neco or Necode as some of you may know me or Isaiah. Um I'm horror hacker. I do automation. I can't I can't hold this [ __ ] mic. I'm sorry. Um I love cats. That's the important part. So first off, we're going to do how USB works because that is kind of

fundamental to this whole thing. Um important distinction here between or important that USB does not do polling or sorry does pulling unlike interrupts. Uh PS2, the the fun the fun one that we don't use anymore, unfortunately, uh is interrupts. It just yells straight to the CPU, "Hey, I have something for you, um USB instead uses polling where it just yells, "Hey, do you have something for me? Do you have something for me? Do you have something for me? Do you have something for me?" Um and if the if the device has something for it, it says, "Yeah, I have something for you. Here you go." And it's literally just in Yeah. Yes, I got something. Cool. or

do you have something? No. Okay. So, another fun thing about USB. Well, yeah. Any another fun thing about USB is the speeds. It's so many different speeds. There's high speeds, low speed, full speed. There's even higher speeds. Keyboards are usually full speed or low speed. Um, for device over keyboards that have an actual microcontroller in them, like a like I like a custom mechanic. There's probably some keyboard people here. I'm a keyboard person. We all have [ __ ] [ __ ] fancy mechanical keyboards anyway. They have probably some microcontroller like uh a Pico or something that's doing full speed. You don't really need it. It's just easy and whatever. Um but these keyboards are using low speed because

why would you spend money when you don't have to? So for low or for full speed you uh use a pull up resistor or 1.5 khm resistor on D plus and for low speed you do that on uh D minus. That's the only difference. There's once you're at full speed then or if you uh have the pull-up resistor on D+ and you say you're full speed then the device can try once enumeration has started it can the device and the post can talk to each other and upgrade to a higher speed but this this part separates these super super super low power like slow speed devices from the actually fast ones. Um, and this is where the accessible

host controller interface comes in. This is incredibly important. This is your USB controller. And this is how it still hands data to the CPU. Instead of the device directly sending to the CPU, hey, I have something for you, it sends it to the controller. Well, the controller really is the one pulling the device. And then the controller says, okay, now I have something. Hey CPU, I have something. And that way you you just have something between the CPU having to constantly deal with interrupts um and it also the CPU doesn't have to do the polling. So now we can observe some information here little bit about how USB works. Let's let's see what we can see. So if

you're on Linux, I use Linux for all of my stuff like this, but um a pretty easy way is literally just to GP D message for USB. It's a great troubleshooting step. You see all these really fun things like here's it's a Dell wired multimedia keyboard manufacturer prem primax. Perfect. Well, you can see that the input HID raw one and it's USB HID 1.10. Uh HID stands for human input device and it is the standard that all of these use. If your computer uses an input device, it's that you can use as a human. it's probably a human input device. Um that so D message is just kernel logs basically. It it gives you some

information but not everything. What's actually really useful is ls USB which is like ls u like ls or ls block or whatever it it just lists all the USB devices. But if you run it with V, then it gives you all the information. We don't need 90% of this. But there's some cool things in here. Like we can see the vendor. There's so many there's so many [ __ ] fields in this. And this is just for keyboards. This isn't even all of them. I had to cut off some at the bottom. Uh if you have a hub, there's even more. And for cameras, like uh webcams, um you just don't stop scrolling. It's like eight

pages of these [ __ ] thing. Anyway, um sorry. For these fields, there's some there's some useful ones here, like there's the vendor ID, that one's important. Product ID, that one's also important. Uh the manufacturer is good. Product's good. Dell doesn't actually have a serial number for their keyboards or mice for like most of them or at least their shitty wired ones. So, you don't have to you don't have to do anything. It's it's just not there. Um, and then another fun one is the max power. Um, I don't know if any of you know this, but the or how many of you know this, but the USB typeA like to USB 2 type A, the spec for that is 500

milliamps per port. that that's all it is. So this is just saying hey the maximum that I'm going to draw is 98 milliamps. The thing is that's device the device says that it this is not a real number. This is just what the device thinks it might draw. So you can draw more than that but it might be a little weird. Um another one is the BCD USB. This is just saying what version of USB we're using. So in this case, we're using version 1.1, which is low speed. It's 1.5 megabits. Stupid slow, but it's it's good for this. It's cheap. Oh, I already I already mentioned this. Oops. And and that. Okay. So now we can observe some of this

data in Wireshark. Um there's not the only real easy way to view all of the uh communications between like all the polling uh over the USB device or the USB device is with um some man in the middle device like a PCO just sampled every single thing but that it's not even worth it. You don't actually care that much. Uh I don't know if how many of you know this but Wire Shark does USB. It's really great at it actually. Uh you just need USB mod or wind USB something. I don't wind cap USB. I don't know what it's called. I don't use it for opening Windows. Um, but here once we sort down to actually what we want to see, um, you

can see some really interesting things like you can see the protocol in the frame. It's USB HID. That's good. I'm glad that the US the protocol in the frame is consistent with what the device said it was going to send. And then there's some really, really useful things. Very important because if you're trying to build a fingerprint for a device, you need to know what it's going to look like. So for instance here the URB length is 8 bytes the data length 8 bytes. Okay it's going to be commun communicating in 8 byt packets and also you can see here the time from request basically just how long it took to deal with the request

23 milliseconds. It's good to know because I don't know maybe you want to build a profile for this like how long does it take on average to respond? It's good to good to have this information. Um, so now that we have some understanding of how USB works and what you might want to mess with with USB, we can see how bad USB works. Most of you know what bad USB is, but it's just a malicious. Well, it's basically misreporting because enumeration that whole process that uh LSU USB shows is just what it's what uh your computer is has received from the device when the it asks the device hey do you have anything really interesting like do you have any

information for me like what are you what do you do how do I talk to you uh when the device responded it say that that's enumeration that's the enumeration that first thing it does when you plug it in and it just asks what it is response with what it is and information about it. You can spoof that. None of this is cryptographically signed in any way. You can just do whatever the [ __ ] you want with this. Um, you can also enumerate as multiple devices. I don't know if you guys know about how many of you know about the Bash Bunny. Um, but it's a great fun product from Hack 5 that's just a whole

Linux computer you plug in that enumerates as whatever you want it to be or however many things you want it to be. You can say I'm a hub and I have a Nick plugged in. Like I have a hub right now that has a HDMI cable and a the controller like the receiver for this. Like you could say I have a Nick. I have a flash drive. I have a keyboard and I when you look at that that Nick is actually connected to a network uh 1010.10.10 and here's a server and a a or a router and all this. And yeah, you should you should use this. Let's just move some files to this file share over

here. You can just do that because there's no mechanism to be like, are you actually who you say you are? I'm really good at getting ahead of myself. I love talking about this. Sorry. Sorry, guys. So, the an easy way to detect bad USB is Huh. Weird. I just plugged this uh device in and now magically there's three new devices and they're trying to move files. That's kind of weird. So, I mean it sometimes it's obvious, but you can be subtle. It It's just hard. Crowd Strike's going to get you. So, an an important difference between bad USB and keystroke injection is more of a I'm not great at wording this. Bad USB is I think of it as like a class

of I'm pretending to be something I'm not. Keystroke injection is I'm just sending I'm I'm being a keyboard. I am a keyboard. You may not be a keyboard with buttons, but you're a keyboard because keystroke injection is literally just whenever asks whenever the host asks the device, "Do you have anything for me?" It says, "Yeah, I do. Here's an HID scan code here. Here's the code for this character." Press that character. So, you can just say, "Oh, I want to send an F." You just send 09. It's that simple. It's a shrimple. Is that There are some very fun keys in conjunction device. Everyone knows about the rubber ducky, but OMG makes an amazing cable that is very, very good at

this and has a lot of capabilities. And I wish I could make something that cool, but I'm not that cool. An easy way to detect keystroke injection because a lot of people when doing it are lazy, is it's kind of suspicious if you type 300 characters a second. Um, I don't know about you guys, but I can't do that. Um, and also time in between keystrokes can be analyzed because you have like if I'm typing, I don't know, I'm typing 80 words per minute. I don't know how many characters per second that is, but it's probably not more than 30. And we can say, okay, well, there's like a reasonable amount of time between keystrokes, but it's not

the same every time. It's not like every 10 milliseconds I send a keystroke. It's like, oh, sometimes it's 10, sometimes it's 30, sometimes it's like 26. You never know. And so if you see incredibly consistent packets, it's a little suspicious. Also, typing meta r like when r and typing 259 characters and enter kind of suspicious. Just just make it do it slowly. So, a way that you could still detect keystroke injection other than the incredibly obvious stuff is fingerprinting, which basically going through all the things that like all the variables and fields I was talking about earlier and saying, "Okay, does this match?" Like, I have a database of what this keyboard is supposed to be sending me. Is it the

same? So onto the actual project. I want it to be small, needs to be power efficient, and I need to already have the hardware because I love to do things last minute um and with cheap things because I'm cheap. So I Oh, it cut off. Oh, what I ended up with here was a PI Pico 2040 cuz it's form fac because its form factor is the size of my thumbnail. Um, and that's the exact reason I went with the ESP32C32 super mini as well, because I uh was going to use an nrf 52840, but I didn't have one as anywhere near as small as my uh USB 32. So, that's why I went with that choice. It sucks. It's so

much more power inefficient. Uh, its deep sleep is awful in comparison, but I needed it to be small. I also wanted to add a micro SD card reader, so you could put like a 32 gig micro SD card in it and just log every single keystroke ever. I think that would be fun. And then an important thing here is we need to have a battery. I know you can get power over USB, but we're going to get to that later. Why why we need a battery. So, I picked this hardware because it was cheap, small, and I already had it in my lab. But for real, size. The size is so [ __ ] important.

It's It's not like you look at a keyboard and you're like, "Yeah, there's a lot of space in the keyboard." And it's like, is there though? Is there's a lot of structural integrity there. Um, and they've kind of already optimized a lot of this. And then the reason with the PI Pico 2040 is because PIO like the PI state machines um allows me to make a device USB interface and a host USB interface which is very important. Um, I can't really use the default or like the uh bakedin uh host or device interface on the Pi Pico. We're going to get to that. My inspiration for this, there's supposed to be a cat picture. My

inspiration for this was actually game hack, like hacking in games, uh, mainly Valerant because there are some incredibly creative cheat uh, cheaters and people who will do wild things for ELO in a game that doesn't matter. Also, I saw some EDNR vendor being like, "Ah, yes, we are very good at detecting uh, bad USB and keystroke injection." And I took offense to that. It's a It's a challenge. It's always a challenge. So to actually hide the hardware in the keyboard, right? Super limited space, but also we can't disrupt regular operation of the keyboard because that's going to be really suspicious like, oh look, I suddenly can't use like you plugged into this keyboard that I cannot

type on. That's kind of strange. So introducing the vict introducing the victim here, the the Dell 522. Everyone knows that keyboard. Here's one fresh out of the box. Um I acquired it from somewhere. Don't worry about it. There was supposed to be a picture here. Um, hiding the hardware in the keyboard is basically cracking it open. It's It's just a It's just a bunch of screws. It's not. And then you just go spudger around the edge. It's not hard. You can actually do it very easily without leaving any traces. Now, let's crack it open. It's a membrane keyboard. Got some buttons at the top. And then there's the USB cable. But really what we're interested in here

is the only place where there's any tiny bit of actual space on this board, which is right there. There's a little teeny tiny bit under that PCB between the USB ports on the hub, the bottom of the PCB for the keyboard, the uh the bottom of the case because that's where the little stands that flip up come or flip up into. Um, and then there's a tiny little bit of space right there. right here. So, we're going to hollow it out because there's not enough space for more than one of these four components. And they're all kind of large. So, this is the tiny tiny bit of space. We have a little bit of space right there, a

little bit right here, and a tiny little bit tiny little tiny little bit over here. And then we have these little pockets. So, oh, oops. You're supposed to have the picture here. Uh, basically I just cut all of this out. The structural integrity of this keyboard is [ __ ] It is not it is not structurally sound in any way, shape, or form anymore. Um, yeah. So, we're we can't disrupt the operation of the keyboard, but we are going to cheat a little bit because this is battery powered and it is manin and middle and everything. So, when the battery dies, the keyboard will stop working. It should last for like 12ish hours. Um, I have some ideas on how to make it last

forever, but I haven't done those yet. But to actually get the hardware to connect, sorry, to get our hardware to actually do anything useful here, not just live in this keyboard, we need to connect to the USB cable in some way. And the easy way to do it is literally to just cut the USB cable and just splice the Pico into it. It's just soldered. So, now that we have all this hardware kind of, there's supposed to be a picture of all hardware jammed. Anyway, now that we have a picture, now that we have all the hardware jammed into this little keyboard, how do we how are we going to hide it? Because we have this PI pico sitting in

between this like this keyboard and the host and it has to be a host to the keyboard and a keyboard to the actual host without disrupting anything. and while still pretending everything is normal and giving all of the same signs and signatures that the actual keyboard will. So we need for this to work we need to hide the timings. We need to hide how long it take or we need to emulate a pretty much exactly how long it takes to norm like on average to respond either with a knack packet or with an actual packet like with data when asked by the host. We need to move the manufacturer ID, the vendor ID, the power draw, and

the USB port speed. So, oh wait, this is out of Okay, it's slightly out of order. I'm so sorry, guys. I threw this I I I'm a master procrastinator. I'm so sorry. Um, so hypothetically here, you could just give this to somebody or put it back in its box and hand it to them and then it's a perfectly legitimate looking Dell keyboard and they just install it and you can use it. Um, I swear to God I had more slides here. I don't know what happened. Anyway, we're going we're basically hiding timing by using the uh state machines on the pico to say, "Hey, we're going to train off of the first couple seconds of when the Pi

asks the uh keyboard, what do you got for me?" It will respond with whatever. And then the uh Pico is going to save that information like save how long on average it took to communicate, save its vendor ID, save its manufacturer ID, save the power draw that is said. Um the speed we aren't actually saving because we know the speed. The speed is never going to be changed. And then we're going to um emulate all of those. The real trick is with the Pi uh onboard USB controller, the Pico can do host or device, but it can only do full speed. It just it it cannot do low speed. It doesn't know how, which is a problem

here because it can do full speed and up, but it can't do full speed and below. So, we basically have to uh use state machines to have our own USB controller. Um, if you're smart, you would in fact use a separate USB controller. They're not very expensive and it would completely solve this problem and make it very reliable. But essentially, you just need to have something saying, "Hey, I'm low speed. Let me communicate." Another important thing that the Pico can't do is it will only communicate with 64-bit packages. And you might remember from earlier, it's we use 8 byt. This Dell keyboard only knows how to talk in low-speed USB 1.1 8 byt packages. So, we

need to spoof that as well. So, we need to run everything in this custom state machine for this to work. Or we could use an actual USB controller. But again, I'm cheap. I didn't have an extra USB controller. So, this is what I did. I hate myself. for power draw. If we end up actually pulling power or more if we end up pulling more power than we said we would, like if we're saying we'll draw 98 milliamps and weirdly we're drawing like 150 milliamps, that's a little strange. uh that in many cases you can't actually just get the live current off of the uh USB port but or at least in the operating system but many of these uh newer XHCI

controllers the actual USB controller itself will do actually report the live uh current draw. So you in some cases can and I wanted to make this in all cases thing. So the idea here was this is why it has a battery. So some more technical limitations of this is the hub doesn't work um at all because it it's not a keyboard and the battery will die and the keyboard will stop working. So here are some better ways to do this. And what I would like to do if in the future actually I have plans to do this later this year is basically build a custom PCB to put in the middle instead of this garbage

collection of microcontrollers that I had laying around my office. Um man in the middle only the keyboard and not the actual USB connection because if you might remember from earlier there's two separate PCBs. One that's the one that is the hub and one that is the keyboard or like the interface that handles the keyboard matrix. So if you put uh brain not work if you are man in the middleing the final USB connection you and you're only pretending to be a keyboard the hub is just never going to enumerate. It's never going to work. And another idea that I'd like to do is try charging the battery off of the caps lock key. uh because

you know like the caps lock power light key on the key because it's drawing power. It's drawing a consistent amount of power and you could totally say hey overnight the caps lock key was just left on overnight. It happens and now you have 16 or like 12 14 hours or whatever to charge your battery hopefully enough to last it couple of hours. there's not a lot of power going to an LED, but it's it's a thought. So, some ways you can defend against this um other than fingerprinting uh is looking for these. It it's really just fingerprinting. There's nothing else you can really do. Um or look for like, oh, you plug something in and immediately

something weird happened. That's kind of strange. But if you want to actually just block it before it happens, pretty much your only option that I'm aware of is fingerprinting. like in strange timings, device ID, manufacturer ID, power draw, and incorrect speed, like full speed instead of low speed because a lot of devices do full speed only. There's not a lot that do low speed.

If you want to actually get the reported power draw, not the real power draw, in Linux, it's in the Bmax power attribute of LSUSB. And in Windows, you can get PMP device property, which is PMP is plug-andplay. Uh, it's a fun USB protocol that has led to a lot of exploits. Um, the demo didn't work. I'm so sorry, guys. I was trying so hard to make it work. I've It did not It didn't happen. I have I have the keyboard, though. See, it's a perfectly fine. It's a Dell keyboard right?

Right. This This seems like a legitimate Dell keyboard. There's nothing There's nothing funky going on in there. No, you should plug this into your computer. It's a good idea. I promise it doesn't work. It'll It won't do [ __ ] Does anyone have any questions? I went through this way faster than I thought I would.