 All right. Let's have some fun here. So this presentation is the setup for tomorrow. Tomorrow I will be back here in the hardware hacking village. We will have USB sniffers and fuzzers and you can come play to your heart's content. So today I just want to do a quick introduction to USB in general, a little bit about the protocol and a little bit about how we go and attack it. Now what I'm talking about today is not the bad USB type attacks. I'm talking about attacking an operating system via the USB port. So we're attacking system drivers via the USB port. It's a great way to get into the thing and I hope you see that today. So introduction to USB fuzzing. I'm Matt Duarte. You want to hear about stuff? Crypto monkey. Twitter handles a crypto monkey. And let's talk about it. So what is USB? Back in the olden days where I'm from, there used to be different ports for keyboards, things like that. They came up at the universal zero bus. You can put any kind of a device on it. These are the guys who got together. They came up with a standard for it and they revised it several times. Most of the revisions deal with two things. The speed at which you can transfer data and the amount of power that it consumes. So everything I talk about when I talk about the spec is out of this. If you get the presentation, there's a link here. It will have all the specs for you. So quick agenda, what we're going to do. Look at the USB hardware software. Talk a little bit about the protocols and then look at how we're going to get in. The tool tools I use are the Face Dancer 21 and UMAP Pi. I like this setup because you don't have to be like Uberly to do this. With the Face Dancer 21, it's a dongle made by Travis Goodspeed. It'll take care of creating packets for you. You can do the fuzzing, all sorts of tricks there. UMAP is a very nice Python fuzzing thing that you can get right off GitHub and try out. I'll demo it all tomorrow. So first of all, the hardware. What is USB? Some of you may know this already. USB is a four wire protocol. There's four wires inside that cord you have. Ground and power, five volts, and there's some amperage differences. The other two are data wires. There's no signal and transmit receive like in serial. It's differential data. So that means there's a positive and negative you just have to interpret them. Some connectors do have this fifth pin, the OTG, that's really so you can use your phone as a USB battery, things like that. Not really all that important when it comes to fuzzing. So everybody's seeing the connections. The key thing to remember is that with the exception of the USB 3 here, everything here is just different form factors of those same four wires. And why they all differ has to do with what their function is. Specifically the flat square type A's that you're used to, they're the only ones allowed to put power into the wire. All these other connectors should never put power into the wire. That's the key point. USB 3 just adds a few extra pins, but we're going to constrain USB 2 today. I think you've seen most of the connections, right? Everybody knows their connections. Cool. So only type A puts power on the wire. You got that. The key to a lot of this fuzzing stuff and this is just my advice from having done this for a long time, use the shortest USB cables possible. Because we're going to be putting several devices on a USB bus and there's only so much power you can get out of the USB bus. So one of the things I really enjoy are these really short six inch cables you can get off Amazon. Definitely if you're going to be doing the fuzzing where you put multiple devices in line, do this. You don't want to lose your power to the cable when you have to charge up multiple devices. So within the wire, no matter whether you're using all the way up to USB 3, there's multiple speeds. They can all exist on the same bus. In fact, they normally do. There's low speed, full speed and high speed in the USB 2 spec. If you use a keyboard, no matter what, latest computer, latest keyboards, you're still going to use this USB low speed, the 1.5 megabits a second. Also known as USB 1.1. Full speed gets you a little bit more and then high speed. Not only do they differ in speed, they also differ in the amount of data they can transfer at once and we'll take a look at that in a second. So let me talk a little bit about the USB networks. You have a laptop, you want to know a little bit about what USB you have and the idea of how these networks are set up. So there's always one host adapter. That's what you're going to see in your computer. This is the one USB master. Then below that, there can be a series of hubs. There's allowed to be up to five hubs between any device in the root hub, which is the one built into your computer. So you can chain these hubs all you want. Interestingly enough, there's probably a hub in your computer already, so you lose one off of that list. Also, you can only have on the entire network 127 devices, just the way the addressing works. So here's an example of my Dell desktop at home, the output of LS USB.T. You can see the tree of what we have here. The interesting thing is that this top one where you see I have four USB host masters, below it, there's another set of USB devices that are the hubs. They're actually built into the computer. So when you look at the back of a desktop and you see four ports, those aren't all independent USB. They're actually the first tier of hubs that you have. That's why you lose one. Then you can see the device is plugged into it. Now, what I'm going to be showing you tomorrow, back in here and a little bit later, is the idea of pretending to be a different device here to attack into the computer. It's actually pretty simple when you get a hang of it. So different computers have different ways of doing it. When you grab the slides later, they'll be posted. You'll see I have everything in here, how to do it on Mac, how to do it on Windows, and how to do it on Linux. So you'll see a little bit of redundancy in the slides, but I wanted to cover everybody's case. That's just the Mac version. It's out of the Apple Developer Hardware Tools for Xcode. It's called Ioreg Explorer. It gets you the same kind of thing. The tree with all the devices on it will need this later to do some fuzzing. And funny thing is, if you've got an older Mac that doesn't have USB 3, you may actually see some USB 3 ports on it. That's because they actually are coming in via the Thunderbolt connection. If you have a Thunderbolt hub that you connect your old Mac to, it might have USB 3 on it. So you're doing actually USB via Thunderbolt into your computer. You're getting to see this off a lot too. Newer computers, if you have a USB 2 port, it's probably a step down from USB 3. So again, watch out because there's a lot of different ways of sneaking USB ports in. Also, they're used internally in the computer. And finally, the Windows device manager has a little bit of data. I recommend you go look at this tool here called USB View. It'll get you to the same thing. So what we're looking at here is just trying to figure out what devices are on the computer, what ones are built in. The reason I care what's built in is because those are the ones the drivers will already be loaded. Later on, I'll show you how we're going to instantiate a driver that hasn't been loaded. So quick and dirty, you guys got the idea of the whole hierarchy hubs and addresses. You can dig into it. There's all sorts of things about how that work. But what I want to get on to is the kind of protocol. Before we go there, though, let's look at what happens when you connect a USB device to a computer. So I'm going to discuss the Linux 3x kernel, not because it's particularly any better or worse. They all work basically the same way. This is my lovely diagram of how it works. You have this idea of the USB hardware connects to the computer. It goes into something in the Linux kernel called USB Core. This is the first part of the Linux kernel that's there. It handles all the generic types of USB devices, no specificity, but it will hand it off onto a device driver that is specific to whatever you just plug in, a keyboard, a mouse, a video camera, whatever. These are the ones that we're going to start attacking more. This one's pretty robust and it doesn't do much. It doesn't have a lot of hooks into it. This one's a lot more fun. It's then exported as a device out to user land and then like computer other programs will attach to it. Yes. Oh. Sorry about that. As I was saying, USB Core is pretty generic. These other drivers are the ones that we're going to instantiate and play with quite a bit. I'll show you how to do that. Within each of the drivers then there's also this concept of there's a hierarchy of drivers. Besides the USB Core there might be a USB device driver and then a specific device driver on top of that. Think of attaching a USB key fob, right? Your storage device. Well, it's going to have a very generic USB Core, something that talks USB and then there'll be something that actually talks the file system itself, meaning going in through the USB port you're actually able to attack every one of these things depending on what the data you send in is and we can construct any kind of arbitrary packet using UMAP and the face dancer hardware. So, what kinds of things can you are already loaded in the kernel? I use the LS mod grep USB that will get you all the USB devices that are in there and if you want to take a look you can look in the libraries directory, you can see what also can be loaded. You can also see them as they're added by looking in var log messages or var log kernel or just tail off var log mess or a tail off D message and you'll get each of them as they connect. Again, that's telling us what device or what part of the operating system we're going to attack each time. And I just did a different way I looked at the PCI bus. You can see the different devices here. The key thing is when you do an LS PCI you will see the actual USB bus is device ID 1D. This means I can go into the proc file system and actually pull out all sorts of very interesting data about it. What the device is firmware was, what drivers, all the kinds of data here. All of these things give me ideas of what I can attack when I come in and send the different types of packets. So, getting a little more detailed, if I drive into each one there's another, I can take a look at all the different queues. Also notice there's a manufacturer, there's a specific device name and then there's your generic device name. So, you have the idea that you could have a hit device that is a keyboard and there's a generic keyboard driver for that. You can also have a Logitech MX700, there might be a specific driver for that. They both are valid when you plug in the keyboard and they both can be used. And the idea OSX, you can use the KX stack command to get the same thing. All we're doing right now is looking at a computer and seeing what was connected to it. So, now that I have an idea from the operating system, what can be seen, I'm going to take a step back and go, okay, what other devices got in there and what addresses do they have? This bus, I said, can only have 127 things on it, including hubs. So, let's look at how that all sets up. What I have here is some dumps. If you wonder where the dumps are from, I'm using a hardware thing called a Beagle 480 sniffer. I will show you also a little bit how to do it with just straight Linux and USB, the USB mon, kernel driver and wire shark, but I use the hardware because I get to see the electronics. But the idea is there is this thing called a transaction. This is the first transaction you have and it has this idea of a setup packet. The interesting thing here is while these two devices are talking on the network, there is no concept of an address. The device is actually just talking to the root hub and just saying, hey, I want to set up. The root hub will later on give it its actual address. So, it's completely controlled by the host adapter. Nothing happens. No packets are ever initiated way down at the devices. The host always asks, hey, who are you? Tell me, hey, use this address. Okay, I will use this address from now on. So, the first packet or the first transaction is set up, is made up of three packets, a setup, some data and an act. It's a little different than TCP IP where those are just flags. They are actually separate packets that are passed through. The idea of these transactions can be one packet long, two, three, four. I haven't seen any fives yet. But each of them go together. They all get slapped in and they make a single transaction. This is the initial setup transaction. And each one also is self identifying. They have different purposes. This is a setup. There's ones that do bulk transfer of data. There's ones that say, I want to leave the network or I want more power. All of those things are different transaction types that you can play with. Each one will begin with a token of a couple of bytes. We can go through this when you look at the stuff. This is what you'll need to start taking a look at it. This is what we're going to need to fuzz also. We need to understand the structure of a packet before we can start fuzzing. Skip through those. I just want to put this in. This is straight out of the manual, but what's important here is the different types of packets there are. Setups, starter frames, and then ins and outs. That's really actually a simple protocol. Just things I need to get my address, tell it I'm coming or going. Other than that, there's just the host telling you I'm sending you data or the host saying I want you to send me data. So again, like I said, that key fob that you put in will never send data to the host. It will always get asked, please send me the data and just respond. So the host initiates all the transactions. There's only one address in the transaction and that is what the device is. So when we initially set up to this and looked at the packet, you can't see it here, but source and destination were both zero. It doesn't even have an address yet. The first thing it has to do is go through and try to get that address so that you can have the different devices and you don't get confused here. The idea, there's some data packets, there's a bunch of checks. There's different kinds of data packets. They have different sizes if you want to do bulk data transfer or not. Not all that important, but you have to remember to fuzz each one of them individually because they'll come up in different ways. And acts and acts, stalls and yets are just different types of acts. There's more, in TCP IP, you only have the act packet. This has different ones. They can say things like I was expecting you to send me data and you did. That's a nyet packet, which I think is kind of funny, but I want to kind of get on to the actual fuzzing part. This is all, like I said, stuff straight out of the manual. You can take a look at it. But what we're trying to do is get an idea of the structure of a packet so we can begin to address that. And there we go. Okay. So now let's take a look at how you do these things. We've talked about how to look at the stuff on there. I've breezed through the kind of setup at this point, but how do we get at the data? In the case of a hardware sniffer, what you do is you actually put the hardware sniffer where that X is right in the middle of the wire. So this thing has a connection on it. Two connections here. One just goes to the device, the other goes to the computer, and it sits in line. There's another connection on the other side that actually leads to the analysis computer. But the idea here is I'm actually intercepting the data as it passes through and able to, you know, create basically a wire shark of that data. I do it outside, so I'm looking at what's actually on the wire. I'm able to look at how much power it's drawing, all of those things, by intercepting on the wire here. The nice part is neither one of these devices knows that it's being intercepted. There's no changes. There's no hop count changes or anything like that. It just happens, and I get to see what's there. The problem with these snivers is I can't insert data. So I'm going to show you how to do that in a second. There you go. Sorry, I did have a picture of it. You get the idea. It's about a $1,200 device. It's useful, but mainly if you want to look at the power stuff. So let's go back to that idea of that first handshake. You saw the setup packet saying, hey, I'm now on your bus. I would like to do something here. So first we do the hardware handshaking. Then we set up the first set of transactions and start a frame, a setup, some in data. All this goes from those two device, zero and point zero. That's these two columns up here. That is the root adapter up the top. So he's saying, hey, I'm on here. There's no source and destination address yet. So we're going to sign a destination address now from the host adapter. Take a look at the transaction here. All this is really saying, this is a fancy way of looking at it. It says address zero and point zero wants to set the address of hex 16, which is 22 and decimal to the device. He's saying, okay, I now see you. I want you from now on to talk as if your device 22. Think of this as the DHCP for the bus. But it's kind of nice because it means you don't have to ever pre-configure a USB device. It just connects and then the host adapter says here's your address, here's your address. It handles it all for you up to the 127 that's allowed. I put this up also because every one of these fields is now open when we start fuzzing it for overflows, wrong numbers, what happens if I give it a device ID above that can cause crashes. All these are ways that we can get to the software by screwing with these different types of package. And finally here I like this picture. So what you have is you have to set up with no addresses and then you'll notice after I told it to start using 22 from now on he's saying I'm device ID 22 root zero. I don't think you need much more. Everybody kind of get that idea? Cool. So there's a whole bunch of new transactions as a set up but mostly what it's doing is just negotiating. How large a packet do I accept? What should the address I should use? All before it goes into these kind of bulk transfers of data. Now there's lots of different modes that you can connect. Remember I said that the devices you connect never initiate a packet. So one of the things you negotiate with the host is well do I want you to pull me every second? Do I do bulk transfers like I'm a camera or a storage device? It has actually different modes for things that send just a little bit of data regularly like a keyboard or things that send a lot of data but irregularly like a flash drive. So there's all these different modes but all of them are negotiated in this initial handshake. Yeah, don't care. The second way of sniffing so let's change gears here a little bit. If you don't need to see the electrical part of it this is one of the ways I like to do it. There is a module built into most Linux's it's not loaded by default but you can mod probe it in called modUSB. When you insert it in here you mod probe it in it actually allows you to intercept the traffic between USB core and the USB driver. What this means is you're able to do this without any hardware. If you have a Linux box you probably already have this software. So as long as you don't care about the hardware side of it power stuff you're good to get traffic this way. Even better once you do that it shows up in wire shark. Once you mod probe that in you fire up wire shark it says oh hey do you want to sniff the USB device instead and you get all of that nice wire shark disector but for USB. So at this point what we're doing is we're just looking at a normal connection we're figuring out what fields we can attack but this is the cheap way to do it much easier. There are also equivalent drivers in uh well let me finish Linux first. Pseudo mod probe USB mod in and you can do this once you do that uh like I said wire shark is your friend and you don't have to have a special form of wire shark it's just built in it just doesn't show up until you mod probe that in. So fairly useful little thing that a lot of people don't know. On Windows you can use something called USB Pcap to do it it does the same thing it'll bring it in and allow you to capture the traffic that way. When you grab the slides there's a link to it here. So you can also do this I haven't found a good way to do it in OSX let's put it that way. Also another good way if you're a pen tester or you do a lot of your malware work in VMs since you know when you plug in a USB device to something running VMware it pops up and says do you want to connect to in my case your Mac or the Linux and I say oh Linux well once you do that VMware is actually passing all those Linux all those USB transactions through. A few modifications in the VMX file you can have it dump it to a file for you and then you can analyze it. So all of these are ways for you to intercept a USB transaction as it goes by and see all the things that are in a normal setup. And there is a program that helps you do it but this is actually just a giant text file. I personally like the wire shark way better I like the disectors. And you can try to do it with OSX but they have not updated this package in a really long time and I'm not sure you want to bring in the kernel extension from another version. So I don't do that. So up until now we've looked at this. When you connect a USB keyboard to something you think it's just a keyboard but I'm sure you've seen combined keyboards and mouses. I'm sure you've seen things like a video camera that does both video and has a microphone. One of the interesting things about USB is within one connection you can actually put multiple devices. In fact it's the thing that actually makes bad USB work. Because you can be a bad device and you can be a device that is perfectly normal. So you could have a key fob that when you insert it, oh it looks like I'm a storage device, shows up a storage device, the user doesn't know any better but it can also have other devices. What's interesting here is that it's built into the protocol and it doesn't require a different address. Within that one address you can have multiple streams of data acting like they're coming from different devices. This is kind of fun because this is how we hide malicious transactions and malicious attacks within what looks like normal traffic. Because the user never realizes it. They put the key fob in, it works like it's supposed to, they don't ever think that I put in extra things or extra channels of data and I'm attacking extra drivers that they never thought of. This also gives you access to drivers that aren't normally loaded. So what I'm looking at here in the dump here is just the total number of end points in the configuration and we're going to look at that concept next of where we're going to go with that. The other thing to take a look at this is you'll notice that there's device class, device subclass, that's what I was talking about the generic devices. I'm a keyboard, I'm a mouse, right? And then you get into the specific ones with like the manufacturer strings and there you have a device vendor ID and a version number within that. That's your one that I'm a, you know, Logitech M7000 keyboard. They both are valid and they both work in instantiating drivers. The other thing you can see here is if you look, what I was talking about multiple things in here, these interfaces are the parts. So it's one device but it has all these different interfaces in it that it can do. Hardware input, audio streaming, audio control, so I can do volume control and I can bring in data and I'm also a human interface device. All in one connection that you never saw. So the easiest way to describe this is to understand that you're probably generally used to thinking about a device. I had one cable, I plugged it in, it was one thing. But within the computers they're thinking of it as this idea of configurations which you rarely see more than one of, but then the interface descriptors say, hey, I am a type of device, I'm a microphone, I'm a keyboard. Then within that you have endpoint descriptors. All conversations are one way. So in other words if you have something that both reads and writes to a device, you define two different endpoints. One reads, it sends data out, the other receives it in. So it's kind of your equivalent of your transmit and receive in serial, except in this case they're both one-way channels. So even your normal key fob you're going to have several channels in there. One for when it gets written to, one for when it gets read to from. They get grouped together in an interface, I'm a key fob, which will eventually get into a device, I'm a, you know, whatever brand of key fob you use. So all of this is fun because this is how I hide different devices in there, but it also means that you can fuzz multiple parts of the thing at the same time. Because it is these interface descriptors that are the ones that are tied to a specific driver in the operating system. It's not a device, it's the interfaces. That's why you can have a microphone and a video in the same line. It might, it'll be just one, you know, Logitech camera, but it'll file up two different drivers when we bring it in. So a single USB device can set up a variety of things and just remember that they're always one way. They're either designated in or out. Out devices go from the computer to the device you attach in devices, means that I'm taking, I send a command, say send me data, and the device sends the data to up to the actual host controller. There's also control signals you can send, like I said, for changing with power. Again, you always go through this process where I send you data and you do whatever I say. In the different endpoint types we have this idea of guaranteed delivery for packets. So a control endpoint is one type. Remember I said there could be different ones there, ins and outs. There could also be one called a control endpoint. A control endpoint is for doing the configuration data. It is guaranteed to always get there. So it's your TCP on the UDP bus for one of a better term. But it always is sent to endpoint zero. Interrupts are ways of setting, you can change the different sizes of them. You can send small amounts of data and you're guaranteed delivery. Ah, so small amount of data, you're talking keyboards here. This is the like the low end of the USB. Those are interrupt driven ones. And then the big ones that you use for moving lots of data are the bulk and isochronous. That would be for your key fobs. So even we have, I told you we have these different interface types with the different speeds, that's what it's all about. Let's skip that one for now. Once you get the different flows in, they'll bundle together into an interface and we'll come up with stuff. So let me skip that part. Okay, so this part I want to get to. When you connect in, you're going to have all of these different things. So now I've connected it, I've got my power, I've got my address. I've told you here are my endpoints, all that. Each one of those endpoints is going to identify itself out as to where it comes from. With these things that in the spec are called B-class type, B-class subtype, B-device protocol. That's your bulk and all that. Each of those things are the fields that we use to identify ourselves. So when we go on and use the face dancer, those are the things we're going to fake to be a different fake device. So I can cause it to instantiate anything I want as long as I can fake those things. They also, they'll tell you what type of device it is. Again, hids are things like keyboards and mouses. Then you can go into specific models to load a driver, otherwise it'll just use a generic one. So how do you go about getting on this and attacking? All I've talked about so far is this idea of how the normal transactions are set up and how we see the data. The idea now is we're going to pretend to be another device. And last year we saw Kerson Knowles' presentation on bad USB. What he showed in that presentation was I'm going to take a USB key fob and I'm going to change the software in it so that it still looks like a key fob but I'm going to have it do other things. Great, but I don't want to have to write the stuff every time. So I go on and I'm going to go through and change what I want on the fly. Bad USB, he wrote it once and he was just able to keep doing the attacks. So the concept of a single device being able to come in and do multiple things was great. He showed it could be done but I want to be able to do it on the fly because for fuzzing I want to do it over and over again. And his problem, like I said, he had to write it once so he locked the firmware into the device. I want to be able to do it on the fly. The key thing to get here though is he didn't do anything that was not in the protocol. He just pretended to be another device. So all of this used a normal protocol. He didn't crash anything or do anything weird. He came in through the normal protocol and said oh yeah I'm not only a key fob I'm also a keyboard I want you to start typing this or I'm also this type of DMA device I want you to start pulling memory out. So if you want to take a look at his presentation it is posted here there's a video of it up. So again when you grab the notes you can take a look at if you're not sure what I'm talking about what he did. But what I want to do is start attacking the systems via the USB port. So way back I started with the Beagle 480 I could see the transactions and I started with a device called a teensy it's a special form of Arduino. What's special about it is the USB chip they used it didn't it could be programmed to identify itself any way you wanted. So it could say oh I'm a keyboard I'm a mouse we used to play with these things they were great but they had the same problem with bad USB you had to program it on one computer they carried over and connected to another computer. It worked great and there's some great slides about it there's some great presentations then I saw this presentation at Defcon where a guy said oh I can do that programmatically and I took a look and sure enough somebody had created a dongle that could do this. Travis Goodspeed created this thing called a face one face dancer 21 and you can now buy them. Zippeter sells them online and actually I think the hacker warehouse is selling them down in the vendor area right now. It's just a small USB dongle and it looks like this two USB ports that allows me to connect a computer to it say I want you to be this device with these endpoints and then it connects to your host computer and says hi I'm this device with these endpoints and you can do this over and over again because this computer this little dongle can also shut itself down remove it appear to remove itself from the computer and reconnect itself without removing any wires. So again this is the key to making this work this is why we can do this cheap now we have the software to do the fuzzing we have the little dongles we can buy it's now achievable for anybody to just go in a USB hack. You don't need a $1,200 sniffer or something you can just use this much cheaper and it took a little while to get the software out but I went through I got the software but this is really a pretty good circuit it's just a different form of his good fit the key thing is it has two USB chips on it one for one side one for the other and I use I connect my computer to it I say I want you to do this and then it goes out the other side and pretends to be the entire device very handy again he's got presentations up on it he first presented it in this YouTube you can go pull it out I think it was from a cc3 but again you can take a look at what it is yourself or you can come by tomorrow I'll be here all day and play with it I have several ones we can take a look at how it works the other part was it's not just the hardware we needed something to help it out he wrote some good basic software that lets you talk to it you know there's a scapey interface for those of you who want to just create custom packets but that's still not enough to fuzz we needed the kind of the next level my hardware setup I use my computer here to set it up and I just have it connect in I'm able to put anything I want on the wire so I went through all that protocol knowledge so we know what to put on the wire now we're going to take a look at how to do it I already said that so you can get the software straight out of github you know again totally open source to do with it if you buy one here's how to set it up and like I said he gives you a good basic scapey interface but nothing more so uh lots of people then took that basic interface and decided to play with it in different ways we've seen a couple of people create some nice custom software for doing the fuzzing but what they really did was they wrote their fuzzer and pointed it at these custom libraries I wanted one that did fuzzing right out of the box so again uh Daniel Mende's presentation about doing this is pretty funny he did his custom fuzzer Dizzy works beautifully but it requires an you to be fairly technical to get it to work programming the face dancers if you come by I'll give you the videos too I just have some videos of like programming it but I don't have them on this laptop again just this is just the programming info for how you do it in this case I like this way you just go pull the latest image off the web it installs it takes about 30 seconds and you're ready to go so next layer of software this is a presentation I saw several years ago at DEF CON it took them a little while to get up Andy Davis of the NCC group put out a set of Python libraries called UMAP this is what makes it easy now for anybody to come in fuzz if you have Python and PySerial on your box you're ready to use a face dancer it's that simple he's got his presentations are up his github accounts there if you want to pull this stuff this is what I've been working off of it does scanning as well as fuzzing so when you run it you just take a look at it it's a very basic framework for USB fuzzing when you uh the only trick is for me it's Python 3 all the good fed stuff's Python 2 but and it also requires Py3 Serial but as long as you have that installed you should be ready to go so this is what it can do out of the box it can list all the different devices that it can pretend to be identify the supported devices on a connected host so I can tell this go ahead and run that script minus i and it will go and connect to your host and say I'm this device I'm this device I just do it over and over again until it's enumerated all the possible devices that are there the interesting thing is that each time it does this it's causing that computer to load the appropriate driver now if you're on Windows or Mac and you've seen that driver before and accepted the signed driver it'll just load it without telling you at all it'll just go boom I'm loaded no problem if it's a new device that it's never seen before it'll cause a pop-up Linux doesn't do that Linux if it has the device somewhere in the memory or in its file system it just loads it it logs it but it never causes a pop-up so kind of fun there so he gives you one here it'll be in the source code tomorrow you can just walk through the different data classes and see all it's going to do is just step show me all the devices and again when you grab the other stuff there's videos I just don't have them here but I left the slide in so the nice thing about device scanning is you don't actually have to have the device you're just running through the list of numbers so you'll get to see all the device types regardless of the manufacturer if the driver is there so when I gave you before the case of the keyboard the Mx700 Logitech it'll tell you yes I am I have a keyboard driver for the generic but it'll also come back and say oh yeah when I ran through this list I also noticed he has the specific driver for the Logitech M700 or for the Canon camera or whatever that gives you an idea of your targeting if you're looking at attacking somebody the idea that in Linux there's no confirmation in Windows there's no confirmation as long as you've seen the driver before but it's also kind of fun to do because it causes somebody to have a lot of pop-ups which annoys the heck out of them if they don't know it's happening and example pop-up if you I'm sure you've all seen these before so it also has built in this idea of fingerprinting a system just like an end map where we send packets and we can tell what the operating system on the other end is by how they respond you can do the same thing with USB what drivers were built in already what messages did it handle this is kind of end map for operating systems that might seem kind of silly to you for like a desktop or laptop you can kind of know right but if you have say a small embedded router that has a USB port on it you can then look and see what the operating system is that'll give you ideas of where you can attack it what different operating systems are available it can also get down to about the version level though that's a little little sketchy sometimes but again it's similar to the way end map scans but handy for identifying embedded devices and there's the OS detection and finally the part that we're all here for right the fuzzing part you can set it to you can control the device what the vendor idea is what the pit is all of these are for the setup part of it once you do this it will just go through all the valid message types you told it to do and look and fuzz each one of the fields individually so you end up sitting there you know in the page it'll walk through all the fields that are there automatically you don't have to memorize them although if there is a field you're interested in then you're able to pick it specifically so that's why I picked this particular system to talk about just because it really lowers the bar it makes it pretty easy for anybody to get on this and do it you can also do entire classes so I can say just scan just attack the hidden devices just fuzz the hidden devices and leave the cameras out of it and the command lines for that are minus f and minus s sorry my laptop if I would add videos for all this so I could show you but different laptops sorry all the ones that are in there and this test cases.py you can edit it yourself it's pretty well documented Python for you to work with and you'll get a very good correspondence between what's in that list and the printouts that you get out on those USB spec sheets or all the sniffing you got and of course another fuzz run fuzz runs generally take 40 minutes to an hour to do a complete run so I would highly advise you target as much as possible that's about as far as I'm gonna take it I'll take you up to the point where you crash where you get a crash the kernel panics we get the dump now how you choose to exploit that is a whole different set of talks and a whole different art the idea is to get to a crash but when you're on the good side to be honest if you can fuzz something through USB and get a crash that's good enough to get you a bug bounty I know for personal thing all you need is the crash to win the bug bounty most of the time you don't even have to have an exploit you can just move on to the next one if you do an exploit they'll pay you a little bit more but a crash is almost good enough on a lot of these bug bounty programs that I've been doing also keep a close eye when you're doing your fuzzing on the pit of the process that might end up with the data because sometimes they'll restart on you and you might miss it you might get a crash and not realize it so and that's the goal right there we want blue screens because when we get blue screens from our USB device that means we've successfully managed to do our fuzzing we found something wrong and you'll notice that I am in usbb.sys so obviously I hit something good here specifically it's not out yet but they're going to pay me about three grand for this particular crash and like I said I'm not going to go too much into it once you have a crash you'll get the cord up and you'll go into the much more traditional exploit development so my advice of course is if you choose to do this obviously just report any crashes you find to the right people and what I mean by that is do not call Microsoft up with a crash in the Logitech stuff that goes to Logitech Microsoft probably gets tons and tons of reports that have nothing to do with code they wrote because everybody else all these third party drivers are the ones that cause the crashes so if you want more info grab the slides I have some links here here are some things that will help you get started with this obviously if you're in the Seattle area both NED9 and Black Lodge Research for where we meet we talk about this stuff a bit like I said feel free to stop by so that's it hope it was interesting I'm sorry I didn't get to show you the videos so I'm a little faster tomorrow I'll be here like I said with these with that come join me if you want to try fuzzing out for yourself take a look at what we can do with these things and I'll take any questions sorry yeah I cannot hear a word you're saying I will be here first thing when I wake up tomorrow and I will leave when this place closes so I so say 10 or 11 a.m. tomorrow through the day I'm not doing anything else I'll be right back there probably in that back corner table and like I said in addition to that this is the usb sniffer I have the i2c sniffer the spy sniffer the can bus sniffer for all you car types I have a million dongles whatever you want to talk about I'll talk pretty much any protocol but I'm primarily talking about usb today and we're going to do the usb stuff I have a system you can just straight ssh in to you don't have to install any software if you want to you need python serial pie twos pie serial and pie three pie serial and you can pull the software off github any questions cool so I hope that's a start you're welcome to the slides I know I zipped through them lots of links in there for you to follow and if you want you can have the videos too they're just mp4s and you can see fuzzing runs and things like that I show you things like here's the d message and what happens when I'm fuzzing and you just see it loading driver after driver after driver but like I said a good fuzzing run will take you about 40 minutes so the videos are sped up anything else yeah bring me a usb drive huh no any other questions cool thanks yeah there's a form of this presentation on the neg9 website if you want it if not I'll give you this presentation it's almost the same so anything else cool hey thanks for stopping by I hope that was interesting and uh like I said you got any questions come see me I got nothing better to do