 Next talk in schedule in Roomba is the Face Dancer 2.0. It will be presented by Dominic Spill and Kate Tamkin, both are open-source software developers, and this talk contains device security around USB devices. So the stage is yours. Thank you very much. Give them a warm applause, please. You may want to save that applause to see what kind of job we do first. So this is Face Dancer 2.0. I'm Dominic. Kate Tamkin. It's not your name. And this talks about USB. It's about USB spoofing, hacking. We're going to do some sniffing. The idea is building USB devices in software, and let's get into it. So I think we're going to start off by thanking a number of people. This isn't all our own work. This is how we've built another people's work. Starting from the top, Travis Goodspeed and Sergey for the original Face Dancer 2.0. Right, the two original developers of Face Dancer 1. Mike Osman, who is my boss, and designed some of the hardware we're using. Mike or Elizabeth Scott, also known as ScanLime, and she did some... Thank you, person in the audience. And she did some amazing work with Face Dancer a couple of months ago, which we'll talk about. And then our employers are short information security and great Scott Gadgets, who are very indulgent for letting us come here and talk to you and spend time on these things. Anything else you want to add? No. All right, so it turns out USB is absolutely everywhere. See the map? Lots of USBs. So a couple of years ago, a guy called Josh Wright came up with a concept that we're not going to improve the security of our devices, of our software and things like that, until it's really easy to attack those systems. I heard this described recently as, like, it's not a real attack until a script kitty can run it, and someone else said, no, no, it's not a real attack until a journalist can run it. And I think it's the same idea. The better your tools are for attacking something, the more likely we are to fix the security because it's going to be more obvious that it's broken. Right, and so what we're actually building here is a USB attack tool, so a tool that you can use. We're not demoing exploits today, even though we have a couple that will show you kind of the periphery of. Our actual goal here is to show you a tool that we've built and enable you to use it, so you can actually pick this stuff up and start hacking on USB devices yourself. Yeah, I think it's important to know, like, we're not developing these things too because we have some great USB exploit. Like, I don't think any of our attacks are incredibly new, at least not conceptually anyway, but the idea is to make the tool easier and more accessible so that we can kind of multiply that endeavor. We've only got a certain amount of time to play with USB, but if we make the tool easier for hundreds and possibly thousands of people to use, then we're going to see much better improvement in USB security. Right, so when the original FaceDencer tool came out that actually brought a lot of people out of the woodwork who are already attacking USB, giving them the tools to do this really actually was, I think, what led to shoring up of the first USB stacks. And we'll kind of go into the history in the talk, but the point here is that we are giving you the tools here to explore that attack surface, and by doing that to do really cool things yourself. Yeah, all right. So I mean, I think we've already described why we want to hack on USB, but it is absolutely everywhere. I think I counted recently and there are more USB ports in my house than there are power outlets. Everything has a USB port on it. Yeah, it's surprising what has USB. My car has a USB port for firmware updates that's just sitting there in the center console. So it looks like it's a charging port, but actually you can plug a flash drive in, update the firmware on the car. The controller, obviously, because reprogramming all the firmware has complete access to the CAN bus, and this is something that's probably running a shoddy Honda-ridden USB stack that they shoved into some Linux single board computer that's also on the infotainment system. Exactly, I don't know if you've looked to the version of the Linux kernel that runs on most routers and car infrastructure and things like that, these embedded devices, but a lot of them are running old 2.6 kernels and things like that. There's no known vulnerabilities in them, but there's no incentive to upgrade because we're not attacking them. My television has a whole load of USB ports, and I think it's manufactured by Samsung, and there was a report a couple of months ago of those TVs being attacked, and one of the ways they were attacked was by plugging in a USB device to run a firmware update. One of the wonderful things about the vendor ecosystem right now is you start off with the core mainline Linux kernel, everyone forks it and starts building their special sauce on top of that, and so what you wind up with are televisions that have very old versions of the Linux kernel that are never being updated because now it's become too much of a pain for someone like Samsung to pull Linux patches into Tizen, which is their derivative Linux distribution. Exactly, they fork it at some point and add their own things, but don't merge future changes and never merge back, and so that's got security implications for us all. Right, and it's not like anyone's hanging smart TVs, right? Right, exactly. And the photo on screen here is a little tool that we built a couple of years ago called Turnip School, which is not specifically a USB hack, but it turns out we were able to build something into a USB connector, so here you can see it in the mold right before we squished in the Sugru to turn it into what looked like a USB-A connector, and hidden inside that plug was a USB hub, so your cable still worked as if your USB device was connected, but the hub also had a wireless microcontroller hanging off it that we controlled the firmware on remotely. Right, so the goal here is by enabling you to do these things, you can start really getting your foot in the door with embedded systems, so one of the use cases that I think is really cool was actually, if you take our software and plug it into a USB port and something like your car, you can actually tell what version of the operating system that car is running, because a lot of the individual steps that it does as it configures that USB device are specific to the implementation of USB, so by now having done USB for a few years, I can actually look at the list of steps that happen and say, oh, that's Windows, that's Linux, that's Linux before 2009. And I think we'll come on to that as we describe how USB works because we're going to give it a very brief overview of the simplest high-level aspects that you need to know about how USB works as a technology. Do you want to share this? So we're going to start off with a brief description of how USB works, trying not to stray out of the video range here, but a question that most people ask themselves as they start wanting to hack something like USB is how do I get into this? The spec is probably 500 pages if you're looking at USB 2, significantly longer if you're looking at super speed, there's a lot of documentation there, so how much do you really have to know in order to be able to start hacking USB? And the answer is not much. We can still hack USB without having a ton of background knowledge. Yeah, so I mean this is exactly the face I would make if you asked me for specific details of the USB spec because I've not read it. And it turns out, as Carl said, it's 500 pages, and to implement a device you need maybe what? 10 of them. 10, 20 of those pages at most. There's a lot of complexity in the host side and so it seems like that would be where all the bugs are and maybe it's worth trying to attack them. And so while you can definitely get better at attacking these things, if you're willing to spend time looking at the spec and do crazier and more progressive things, all the low-hanging fruit really requires you to know maybe 10 things about USB. So we'll go over those. Let's try and go over those 10. So USB came about because there were a lot of disparate various serial and parallel port technologies. USB was an attempt to unify them. I think it is the only attempt I've seen to unify things that has actually really worked. Yeah. People complain about USB every now and again to me and I think those people clearly don't remember trying to get a serial mouse working and a parallel port printer and then... Install mouse.com. Yeah. And set up the IRQs. Exactly. Oh, wow. That takes me back. And those weird little serial PS2 adapters to plug your one mouse into the other port. Yeah. It's just so nice to be able to buy a device and know that it plugs into almost anything. And I think it really, as a technology, I mean, I love USB. I'm not trying to attack it because I think it's bad. I'm trying to attack it because I think it's interesting. It's prevalent and it's so useful. The idea that I can take a drive from one place and plug it in somewhere else and it just works and so on and so forth is a concept that was slightly alien in the 90s. Yeah. And then, I mean, it's true that when you describe things as I love USB, people accuse you of having Stockholm syndrome. Yeah. It's an actual accusation that's been levered several times this week. But USB is really, really nice, especially compared to the old days where you'd plug something into a DB9 connector. You have all this stuff that you'd need to configure in order to have the communication work, like Baud Rate, which you'd need to kind of do as a user and you need to know as a user and you need to know how to do in order to actually get communication going. So USB was an attempt to take all of these various disparate ports and squish them down into just this port here. So just the USB port right in the center of that diagram. And again, it is dead simple if you're a device. Really, the whole goal of USB is to give you a protocol that lets you take bytes and squish them through a narrow, single differential pair back and forth over a cable. And if you kind of take in the USB abstractions, it really does look like you are just moving bytes back and forth over a series of pipes. So just like you would be doing on kind of your RS232 level stuff, you can actually send bytes along USB one way and the other. And if that's what you want to do, it is actually pretty simple. The only constraint is that USB requires you to do some things in the vein of needing that standardization. So it does force you to do some initial setup in order to have a device plug-in and nicely say, yes, I'm a hackRF. This is my vendor ID and product ID. Operating system, here's a hint if you want to figure out what driver you should be using for me. And I think, like you were saying, when you had to plug in a seal report, you had to configure the board rate. And there were however many different hundreds of modes of parallel ports for printers, and you'd never get them quite right. And things like that. And so USB standardized that in that it forces the device to initially say, here is my information and here is how you configure me. And that gives us the ability to plug and play. And so that's... No, that's fine. I forgot which slide was next. I was segwaying into the wrong slide. So the way it's broken down is you have these things called endpoints. And I guess it's possible that if you think about a network connection between two places, thinking about that network connection having ports, this is a little bit similar to that. Yeah, so if you imagine you might have a network where you have five computers on each side and it's all narrowed down to a single wire in the middle, those computers on either side of your endpoints. And USB conceptually has a very similar concept. An endpoint is a communications channel and the associated buffer and control hardware for that. So I can have a USB device and want to do five or ten different things on it if you ever plugged in a device that acts both as a mouse and a keyboard and a camera, like our projectors do. Those kind of devices actually, it's nice to be able to have multiple communications channels multiplexed over that single USB line. So, or the single differential pair. I say single, but it is worth noting that at USB3 it is multiple. There's actually three differential pairs in USB3 and technically power is also part of the USB spec. So hence the two with the asterisk. But for most of the USB stuff you will see pretty much every device is piping all of its data over a single signal line that is actually represented as D plus and D minus. So single differential signal line. So what endpoints do is let you take all the different things that you might want to do with a device. Configuration, bulk data transport, that equivalent of RS232 where you're bulk spewing bytes from place to place. And endpoints are your conceptual abstraction on top of all the different ways you might multiplex them onto a single differential pair. Yeah, I've actually just realized how slightly misleading this diagram is. But you might have, quite often your keyboard for example have a pair of endpoints where they transfer your key presses in one direction and feedback for the caps lock LEDs or whatever in the other direction. And then maybe that device also has a mouse and that will appear as a second set of endpoints. And so quite often a pair of endpoints will map to a given function of the device as well which is slightly misleading in here. So if you were to extend this diagram out you could actually have more than one function on a single device as well. Yeah, so you can have multifunction devices that appear as multiple devices and composite devices. The key here is that everything is grouped down into that one single differential pair for you. So this image credit, I don't know if the audience can see this because it's behind a wavy cap. But it's from BeyondLogic's USB in a nutshell which is a website that kind of breaks down the things you need to know about USB. And that is, again, it's like we're saying the spec is 500 pages, you need about 10 of them and USB in a nutshell has done that. It's pretty much that 10 page version. Yeah, I don't think I've used any other resources. The other book that people recommend is USB Complete which I've not ever got around to reading but I hear is really good for getting much deeper into this. But USB in a nutshell is everything you need if you're going to implement devices. So there are four key types of endpoints that changes in USB 3 but for USB 2 for now it's true and it's true for the vast majority of devices. An awful lot of devices out there will be a control endpoint and two bulk endpoints, one in either direction. And that's kind of how you hit those higher data rates with USB 2 and the idea is control is used for configuring the device, sending data backs and forwards for the device to tell the host here are all my functions, here's how I work, here is my board rate, all that sort of thing. Any simple packetized configuration data. Control is your simple I want to get some information that's very short back and forth to a device or back to set it up things like I want to turn the keyboard LEDs on and it gives an opportunity for the device to provide standard information about itself. It is the only transport that also specifies a packet format, the reason for that is that control endpoints are what is used for the basic discovery and enumeration. So when you plug a device in your host can say who are you and that control endpoint format is actually what is used to basically provide all of the descriptions of the device and we'll get into that. Yeah, and I think it's nice it's standardized, it means it's very simple to write code on the other end that talks to it so we use that in, for example, the Hacker F control library to do things like set the frequency turn on and off the amplifiers and things like that all those kind of very short settings that you make to stream data at 480 megabits you use the bulk endpoints because they are just an arbitrary buffer and you say here's some data, I'd like this to appear at the other end of this USB cable please. And that's what the bulk endpoints will do for you. So those top two are most of the communications you have on most devices, control being your control signals, bulk being any of that real long higher bandwidth data stream that you use to get the things like disc contents back and forth, interrupt and isochronous are much less used, probably the exception is keyboards and mice which tend to use interrupt transfers which are just transfers that tend to be shorter but have a bounded latency and isochronous is mostly used for things like webcams where you don't actually care if you lose data you just want the most recent data that's available. If you're hacking USB probably the first two will get you 90% of the way there. Yeah, the first two are a significant number of devices will just appear like that. In fact, we had a tool that I wrote a couple of years ago which I would reference later called USB proxy but it turns out we only ever supported the first two types of end point and people didn't notice for months because everything they tried to hack on was one of those devices. So I think we've already covered this but control requests are pretty simple. Again, this diagram comes from USB in a nutshell but they're pretty simple. They have a predefined format but then you just append a bunch of bytes to the end for the kind of your user to find stuff for the blobs of data but they have what was the word I'm looking for? They have some specific structure up at the front end so you can do things like request the descriptors from the device. Right, they have a packet format. Yeah, exactly. Thank you. And so I think we've mostly covered this slide. Yeah, I think the only thing that's worth noting and this is important if you're going to hack on USB, USB is almost a non-terminated protocol when you're talking setup in that if you start sending packets the way that it denotes the end of a transfer is by you sending a packet that has a length set that is less than its maximum and that enables us to do some interesting stuff because if you, for example, compromise a USB controller and start just having it read out all the contents of its memory as long as you never send a packet that is less than maximum length, it will just continue. So this is a perfect analog for all of your string exploits if you're using the C standard library ever because you basically have what amounts to null termination. Also, people mess up null termination all the time and we fixed null termination bugs in three USB stacks in the past two weeks I believe, that we found by doing this project. And then over those control endpoints we have enumeration and enumeration is the way that the device says tells the host what it is and the first thing the host does is giving you a device descriptor and the device says, I'm a hacker ref and then it says, okay how do I communicate with you, what endpoints do you have, what configurations do you have and it sends that data back in a standardized format and you'll have seen that if you've ever used things like LS USB or if you've ever drilled down into the device properties in Windows or anything like that. If you've ever used Windows and you plug a device in and it makes that horrible sound and tells you what it is, what it has done is gone through the standardized pieces of the USB enumeration protocol in order to ask the device who it is what's a description or a descriptor that what is a binary block that describes what you do, who you are, your vendor and product ID, give me some strings that tell me how I can show the user who you are all those things are encapsulated in these standard binary blocks called descriptors. But as Carl was saying earlier and as it says at the bottom of this slide they do things differently. So you have bugs where my device works perfectly on Linux but when I connect it to a Windows system it just entirely fails to ever appear because they enumerate them in different ways and we can actually use this to fingerprint the operating system that's talking to our device. We don't really need to communicate with them we don't need to get down into the nitty gritty of the driver we can just use that initial configuration section of the host system to fingerprint which operating system it's using, which version of Windows potentially we don't have very complete documentation on this yet we haven't gone through and profiled them all but I can certainly tell you the differences between a couple of Linux systems and Windows If you look at the UMAP project they actually have a full library which is based off the original phase dancer they actually have a complete library of essentially tricks that they use presenting a bunch of virtual devices and seeing both how enumeration happens and how the operating system interacts with those devices and they can tell you to a pretty good degree of granularity whether you're using Ubuntu or an older Debian or you've plugged this into a Playstation or you're using Windows 2000 with the USB stack that was delivered in the service pack Oh yeah I almost forgot I didn't initially have it and then on top of this we're kind of going up the layers of abstraction here but there are these single classes which defines a specific sub device or interface on the device so you don't have to again if you remember those old days with your serial mouse you plug in your serial mouse and then that thing needs a driver and if you're lucky it uses the standard one but in general if you bought the fancy looking mouse it probably uses the ridiculous driver that you had to get on a floppy disk and you have to install drivers to get those devices working in the first place and that's still the case for a lot of USB devices especially custom devices it's more obscure devices things like HackRF for example we write all our own host code but if you're implementing a keyboard or a mouse and you comply to one of these classes any operating system that worth itself will already have a driver that supports these standard methods the same goes for serial and storage there's a reason I can take a USB stick from my laptop and plug it into my TV into a car's car or anything like that and that is that that is predefined as part of the spec and so those are some interesting devices because they appear almost everywhere but again their code was written by whoever implemented it on that operating system or whoever fought that kernel at that time and has kept all the bugs from 10 years ago in their system so they're kind of interesting places to go because you don't require there to be you know it's not a if there's a vulnerability there that vulnerability is not if we're lucky they have this obscure driver for this piece of hardware on their system it's if there's a vulnerability in the way something handles mass storage it affects every one of those devices because it's always present and so that's kind of interesting to look at from that point of view it also makes them much easier to implement because they're very well defined as opposed to some other devices and so one of the examples of standardization is it also means that a lot of the implementation moves into these kind of interesting third-party libraries and so if you find a vulnerability in a third-party USB library there's a good chance that that is going to be reused in lots of different places so for example free BSD drivers often are pulled from Linux so if you find a bug in the Linux USB stack dealing with for example human interface devices then there's a good chance that standardization is going to be used in free BSD and other operating systems and if you're like me and your task to write a USB stack for your custom operating system the first thing you're going to be using is reference is the Linux kernel so you'll actually have gone and looked at this driver because you know that's the one working implementation you're able to find implement the same behavior and chances are introduce the same bug two other points I'd like to make on this slide one is Kyle is added here next to human interface devices if you read the human interface device spec that the USB group published you'll find that they were incredibly 90s about it and incredibly optimistic about the fact that data gloves were going to be the thing that we're all using to interact with computers and it's interesting because the spec talks about touch screens and they were like absolutely right that everyone was going to be using a touch screen in a few years but they also talk an awful lot in their examples about data gloves and the idea that I'd have some glove where I'm you know I'm interfacing with my hands and it's I don't know it's a more optimistic time and the other one it's actually pretty amazing because they were really far looking when they designed the hidden specs and that's the reason why you have all these fancy multi-touch controllers and they still work with that same spec they were able to come up with a protocol that was configurable enough that you could do all kinds of crazy and wonderful things and not just did they have basic descriptions of how you might do them for things like touch screens they also made the protocol flexible enough that it could self-describe new types of devices so if you've ever seen something that identifies as a human interface device that is not something you would think of as a normal human interface device like I think some of the teensy bootloaders and microcontroller bootloaders do this just because if they say they're a human interface device they know that an operating system is going to have a driver that's not going to do much with them but they can actually still kind of pipe data over that and anytime I say that there's something that's a complex self-describing description the first thing you should be thinking is that there's probably a shotgun parser that is sitting there behind the scenes that someone wrote at the last minute saying I need to parse this complex binary data format and if you've ever really tried to fuzz parsers you'll know that they're not they're probably one of the weaker pieces of most modern software so if you're going to find vulnerabilities you should be looking for complex things like ASN.1 or human interface device descriptors we should be a little bit careful criticizing shotgun parsers because I wrote one two days ago for this project and I criticized it yeah and it does make some really big assumptions that you're behaving yourself our USB man in the middle tool makes some assumptions that you're going to behave yourself while talking to it but use it for malicious things which is it will happily fuzz itself and fail I guess that's dog-fooding the other one here is networking I think is important to note because there was an interesting case a couple of months earlier this year last year where I've completely forgotten who it was Mubix, Rob Fuller did where he plugged a USB networking device into a Windows host and because it appears as an ethernet device it takes priority over the wireless connection that it already had the machine was still locked and he was able to extract all sorts of information about the networking system networking stuff from the locked Windows machine because he was able to increase his network priority over the existing connection and do some interesting it made some automatic proxy requests and things like that because USB is kind of in this weird trust position where it's both a user facing board that you would not expect to have a lot of power but it's also viewed as something that the kernel is commonly interfacing with there's a lot of interesting trust boundaries that have not quite been drawn correctly with regards to USB so if you go and plug a USB network interface card and there's a lot of trust on the host part that this is a real network interface card that is not trying to attack your device so if you're sitting there with a locked PC you can still plug in that card it will enumerate it'll load the network drivers the network can say hey by the way I happen to have the correct routing to route literally every packet on the system and then every packet you have from that point forward will start going through your custom USB device and so what was actually done in this attack was that lots of things were proxied through that connection and including things that normally probably would have been done over HTTPS but if you haven't seen that particular connection before and you don't want to set the SSL only then exactly and yeah I believe he served up a proxy config file and the host just took it and accepted it and lots of things do this my laptop is running a bunch at the moment and if I plug in a USB network card it will automatically enumerate the device, load the network stack, grab an IP address and probably advertise itself using all that zero comp stuff that I should have disabled by now and this is all enabled entirely by something that is capable of acting as a network device that's not entirely designed in good faith so if you have something that lets you really easily write a network device you can start doing this kind of attack really easily so I mean show off real USB devices yeah, LSUSB the implication there being that the devices that we create are not real oh yeah I got you now so I mean I assume most people have seen LSUSB before if I run LSUSB it shows me the devices hooked up to my system OpenMoco I believe a lot of people are probably familiar with the existence of the phones a few years ago at some point they ceased building USB devices and said well I mean we've got this vendor ID we paid for if anyone making open source hardware wants a free product ID so they can have a unique identifier when they connect to for their product we'll start giving them out so you just email them and ask really nicely and they come back to you and give you a USB ID and that enables us to much more easily differentiate and talk to these things without paying thousands of dollars for a license for a vendor ID from the USB spec for our four devices that we make if you want to do a VVM one of those devices we can show you this is all the information that the USB device provides in standard format to the host so we have the vendor ID and product which are encapsulated in there we have strings that describe the device and we actually have these configurations which are a description of how the device to be used which is absolutely fantastic because you were talking about configuration difficulties 20 years ago but like last week if you had a USB to serial adapter and you were also running something like Debian that comes with modem manager it'll just pick that up and start spamming whatever data it wants into there because of the vague possibility that there's a modem on the other side there's some interesting things in here for example we can tell the host how much power we want now for USB 2 you're only going to get 500 mA maximum from a host that's enumerating you with these descriptors but that dynamic changes when it comes to USB C we're not looking at USB C right now we're not looking at USB 3.0 but there's a lot more power available and a lot more power delivery available to people to do interesting things and that's definitely our to-do list and then lowdown we come down to these endpoints we were talking about before they have a direction, they have a size they have a max packet size we can from this approximate that actually this is a USB 2 device this is these got bulk endpoints that are 512 bytes and it's going to try and transfer a reasonable high-rate data but it's got none of those isochronous or interrupt endpoints that are used for things like the human interface device and so on and so forth so you can see the hackrf here just uses two bulk endpoints and the control endpoint that every device has those are just two data pipes that are used to spew samples back and forth to the computer and apparently my device status is in debug mode which is not a mode I've ever read about so that's worrying so I faced answer a really brief history because I think we spent long enough talking about the intons of USB and things like this but we just want to give some credit to Sergei and Travis so this started with Travis Sergei and a bottle of whiskey as I understand it and the discussion was all for a tool called LibUSB that lets you really easily talk to USB devices and that's fantastic if you want to start fuzzing USB devices but nothing existed that would let you fuzz USB hosts so there's no easy equivalent so a bottle of whiskey and some prototyping later Travis had taken his goodfet which was a microcontroller board and taken a SPI based USB controller hooked it up to that and created a USB controlled was the very first face dancer and so this board is actually if you were to cut it off here, this is a goodfet and then they just kind of stuck on this tiny USB chip which enables them to talk to other hosts and basically act as a USB device on one end and a USB device on the other so it is a USB controlled USB device this is Travis' design for this thing is incredibly simple and very smart on the left hand end there it's an FTDI device it makes use of the fact that a bunch of operating systems know how to speak to a USB serial device and so you don't need a strange driver or anything to program this thing you can plug it in and it will immediately work you then use that serial connection to program the MSP430 in the middle to speak SPI and then it speaks SPI over the next couple of traces of the USB device chip and the USB device chip is a part that was designed to go into USB devices so if you're trying to spoof a USB device using the same hardware that real USB devices use is a pretty smart way to do it you have the same capabilities as an awful lot of devices out there now this board was incredibly limited in terms of its compliance with the USB spec there are awful lot of things that USB allows that this board does not allow but it turns out it's able to spoof so many different devices the majority of those really basic class devices it's able to spoof and act as and that gives us the opportunity to do some interesting attacks that's really a testament to the flexibility of USB that we had this simple device here which actually did not support everything you could do with USB it had only four fixed type endpoints of which one was the control endpoint one was in, one was out and just using those four endpoints and those four data types the USB spec actually allows enough reconfigurability that Travis was able to create USB mice USB keyboards, FTDI emulators USB serial emulators in the USB consumer device control class this was enough that we could actually emulate a pretty huge subset of devices but if you wanted to go and emulate a vendor device or you wanted to take a device that you had personally found and were interested in fuzzing the software for the fixed type endpoints meant that you were never going to be able to create a complete reproduction of that device unless you happened to have stumbled upon exactly the four endpoints that the device was already configured to use one of the things this would be great for is emulating devices that already are based on the max 3421e part but if your device is based on something else and uses a slightly different configuration that part didn't provide then it wasn't going to help you out there and so what we wanted to do was look at other options for speaking USB but with more flexible configuration controllers so we have the face dancer 2 project which probably needs a better name but mostly because it gets confused with one of Travis's so there was a face dancer 20 board if you look at this board the number is face dancer 21 the previous one of that was face dancer 20 and we actually were literally describing this to someone so what the heck would I use face dancer 2 when face dancer 21 is out yeah so there's only there's only two hard problems in infosec naming things cache and validation and off by one error and we had two of those things so we supported a load of different back ends and in fact we were up at the Munich CCC group the other day and talking to them about the radio badge and they said oh we've got two USB ports and an interesting USB controller on there and we said oh yeah that looks an awful lot like great that shouldn't take us too long so the next thing is if you have one of those badges from 2015 it will support the attacks we're about to do as soon as we get round to writing the software so you don't so for those of you who regularly attend these camps you're in luck you don't have to go and buy any hardware you already have it and for those who didn't attend Camp 2015 I'm really sorry because that badge was amazing yeah and if we don't get to you in like a few months someone email me and just tell me I should do that just push it back up to the top of the priority queue you can find our Twitter handles and just bug us every day until we until we block you but it already works with FaceDancer RossDancer and BeagleDancer RossDancer was someone called Philip Tuen I've probably just completely murdered his name but he saw that there's a choke point in the way that FaceDancer works and so you you can't support like high-speed devices and you can't support and not even high-speed devices but like reasonable data rate devices incredibly slow so if you look at this guy because everything is going through this FGDI USB to serial chip it's limited to the BOD rates that an FGDI chip can reasonably do which in this case was something like 15k BOD in this particular implementation and so what he did then is just said well the chip speaks spy I can just plug it into a Raspberry Pi and I said oh the chip speaks spy I can plug it into a BeagleBind because I like open source hardware so that's how these two boards on the bottom left hand side on the right hand side of the screen exist and then at the top right there is a greatfet and that's what we'll be running our demos on today greatfet is a board that we've been building at Grayscale Gadgets that it's the microcontroller section of the Hacker F and so if you have the radio badge from 2015 it's the microcontroller section on that too which is why it's so simple to port that code across to the radio badge but this is basically a USB Swiss Army knife it's in the same vein as goodfet it's literally I mean I'm pretty sure Travis sold that to Mike oh yeah that's sorry I completely forgot we keep referring to Travis Goodspeed's Goodfet project it's actually Grayscale Gadgets Goodfet project because we bought it for him for five bucks and I believe over drinks but did not we refused the price one up but greatfet is our next generation USB Swiss Army knife hardware hacking tool supports all sorts of thing interesting protocols for playing around with hardware we've given talks about it in the past and I'm sure we'll continue to do so and have examples up there so if you go and look up the greatfet project there's some interesting stuff happening there but it's important to note that we've put a reasonable amount of effort into making sure that the FaceDancer 2 code works with other hardware so you don't have to have that hardware but I like it a lot so we're not just trying to sell you this it works on lots of variety of other things we use this because it's easy so if you want easy that's an option other than that it's probably going to be as easy on the radio badge same thing and it's feasible that this will work something that happened when I built this BeagleDancer board at the bottom this is the only working BeagleDancer because it turns out the conversation went hey I've designed this thing that will do FaceDancer but attached to the BeagleBone and my boss Mike said but it's got two USB ports it's got a USB host and USB device port can't you just implement the same thing in software and so then I spend a bunch of time implementing in software and BeagleDancer board because building this thing is vaguely pointless when the hardware the only hardware it connects to supports the same functions without having to build any hardware right so the goal is that eventually we'll be able to take things like the RPI 0 which is the $5 version of the Raspberry Pi and be able to do all the same FaceDancer stuff on that it's a little bit messy and that we have to work with basically write kernel drivers for that but the hope is that if we do that the right level abstraction that will work on literally Linux single board computer that has device support so anything that's OTG anything that has just a device port should be able to act as a FaceDancer device so that will be the ultimate in cheap because I don't think anything you build is going to get down to like $5 we just don't have the Raspberry Pi volume so let's we actually need to pick up the pace a little bit because we've waffled on about USB for such a long time and I want to show some demos so the additional features the beauty of like removing those limitations from the original FaceDancer platform is that we're now able to emulate different devices more complicated devices those different configurations that aren't limited to the endpoints that that chip supports so we can use much more flexible configurations of endpoints and things like that in the using the great fat and we're also able to perform manual middle attacks on USB connections. Now this is the thing I did previously with the Beaglebone Black but I'm able to we're able to do it with new FaceDancer now and it's a lot simpler and we're going to show a demo of that in a minute as well so what can we do with FaceDancer we can continue to do the same things the original FaceDancer was commonly used for we can fuzz USB host which means that if you have something like a PlayStation that has a older or custom USB stack we can start attacking that USB stack and you'd be surprised how quickly and easily these things fall over. I used to say that this was true mostly for custom USB stacks but in development of the USB proxy stuff that we were doing here at camp this week I think we managed to lock up your laptop reliably find codes that reliably would Yeah this thing's running a 4.10 kernel and we have a pretty reliable piece of code that I accidentally wrote that will lock this thing up so I have to re-fuse it. We weren't even trying to fuzz we were just trying to get USB working which shows that getting us to develop software for you is a great way of having everything you have fuzzed. Someone recently said to me FaceDancer too as long as it will still reliably crash my PlayStation I'll use it and so that's apparently what they wanted the original FaceDancer for. We already discussed fingerprinting USB implementations and so again going back to those classes of device there are already code to implement those in FaceDancer and because the old FaceDancer and it was just a simple port to the new FaceDancer when we wrote it to enable those things to exist so we already have implementations for a serial device and FTDI device which is slightly different. And if you look at Travis's blog there's actually great things on like stealing USB device firmware by pretending to be that device and asking for firmware updates which is a cool technique. So this is all super easy to use and we'll actually show you the code for a USB serial converter and you can see how easy it would be to take our library our back end library and technology here and build a USB serial converter on top of that. I realize my font size was wrong in the did you open a visual studio code? Yeah I did. You're right to judge me for it. So the USB serial device lets wow how do I increase my font size there it is. So essentially you start off by importing a load of things from FaceDancer to configure the various sections of those requests, those descriptors All the standard stuff we do already. You just pull it in, cancel it. You specify a couple of endpoints that's the data we're going to transfer in each direction control endpoints always going to be there you describe the device which basically is the endpoints the descriptors are an empty dictionary for some reason we don't have any custom descriptors the rest are here wow I'm not good at interfacing with an editor as anyone who's overwritten software with me will know these bytes here just say hey we're custom we don't conform to a spec at the interface level so that's all the data that USB is going to ask for and enumerate the device so that is all the boilerplate that's supplied by the USB spec so far it's boilerplate you can pick up this file and copy and paste it that's how the USB proxy encode works I took this file, copied and pasted it and altered the bits I needed to and from here to here that is the actual implementation of the device so that is everything that's not already boilerplate so when data is available over this serial connection we remap the the carriage returns we uppercase the data and we send it back so literally USB to serial data comes in on one bulk endpoint and send it back on the other endpoint this basically has an endpoint for send an endpoint for receive our whole emulation code is so simple both because the devices are simple and because our library makes it super simple and if you were to play code golf I think you'd get this down to two lines and still have to be reasonably readable so it is that easy to implement USB devices so why don't we attempt to run it yeah let's dance the serial so face dance serial is just a wrapper script that sets it up so it finds a great fit rather than something else Trevor's having used an FTDI device on the original face dancer implementation means that every time I have a face dancer plugged into my laptop our code tries to use that and gets really confused when it's connected to something else and not a face dancer but if I just run this again because he was using legacy serial exactly so what I've done is I've run this thing against my own laptop I don't have a second target device here this thing is just plugged into two different USB ports so what I do is I communicate with that over one and say hey spoof a serial device and the other port suddenly sees that there's a serial device so if I just ls ls USB you'll see a Hewlett Packard which claims to be Hewlett Packard calculator classic Travis and if I ls slash dev you will see that I suddenly have TTY USB 0 here which suddenly exists and you can actually see just like we were talking about this is Modem Manager saying hey there's a serial port here let me try sending it data you can see the face dancer response so over here this is the log of what's going on this what's coming from the host that we're targeting and the first thing my host does when it sees this thing is start trying to talk to it as if it's a serial device or a modem or something and it's sending AD commands at every possible board rate it can so it tries doing that and obviously they all work because we don't have to care about board rates anymore in quite the same way because we're never talking over a real serial link and I could do a quick demo and do sudo screen slash dev slash TTY USB 0 and then if I start typing if I type lowercase it will just respond with the uppercase version and that's going out over a fake serial link come to a bit of Python code and coming back so I type that you can see on the right hand side I typed it lowercase it comes back as uppercase because it just goes through that function and so now I can do that with anything that any serial device any driver that talks to a serial device on a host system I'm now able to have anything that speaks go through that function on my attack system and I can do whatever I like with it I can pretend to be a modem I can pretend I'm a real device that they want to talk to I can pretend I'm a device that they have a what I know as a sketchy driver for or something along those lines like if I know that there's a bad driver that tries to talk serial I can just pretend I'm that device right and extending out from serial we can do literally anything that USB talks down to we could be serial devices we can be flash drives and one of the cool things about USB being this transport layer for a lot of other different things is that you can do everything using SCSI devices because USB attached SCSI is a thing so we have you want to attack the system SCSI stack sure you have an in to do that without building a whole other piece of hardware we emulate everything at the transport level and you can do whatever you want so we can obviously emulate devices and we can behave really nicely which we do sometimes I've heard but we can also do things that are complete violations of the host expectations and I think that's a fundamental assumption that if I have a disk that's just sitting there and I'm not doing any rights to it that its contents are not going to change so most systems assume that this containers don't change on this contents don't change on their own but in practice they totally can and what that means is that on most embedded systems which don't have enough memory to store a whole firmware update but which actually do their firmware updates over USB the way they do that they read the whole firmware back and say okay I'm going to continue this looks good and then after they've done that they reread it from the disk and flash it to ROM most of you probably can already see the problem if we have complete control over the USB device because now it's trivial for us to do things like take that device provide the correct firmware the first time and then provide our modified firmware the second time and if you want to go to the next slide before we do the demo we have some great tweets oh yeah so it turns out this attack works pretty reliably against a full size office photocopier but Char was not entirely enthusiastic about us bringing one to a field especially we didn't really have a plan to get it here and we had even less of a plan to get it away oh Char was not super happy let me vaporizing it so yeah exactly so it turns out you can't get one of those things in your hand luggage on an international flight so we're going to have to demo this against my laptop in a really silly way instead because we couldn't just wheel on a giant photocopier and show that we can like do the update but I promise you it does work against a I mean if you think of a photocopier brand that's the one that it works against yeah yeah we found photocopiers projectors all kinds of things that meet that criteria of not having very much memory totally vulnerable to this wait I have to do the thing turns out I'm not good at computers so this is just going to take me a minute oh wow all right all right okay so what I'm doing on the right hand side is I'm running the double our double fetch script that does exactly what we just described we give it two files it serves up the first one from the first read and then all subsequent reads it serves up the second one what I've done up here on the top left is I've just disabled my disk caching but it's okay to run that again between the two oh yeah thanks yeah so I run it once that's when we have a USB drive Linux is saying hey let me try to figure out what you are so it can auto mount right and then I'm going to try and mount it when it when it finds the gets there this is also a great way to figure out who you are talking to in terms of operating system because each of the operating systems is a different thing when you plug a disk in Linux if you have the user lands stack setup for auto mounting for example if you're using most of the desktop window managers actually goes and reads a whole bunch of sectors right off the disk in order to try to figure out what file system is on there so here I've been looking at things that take USB flash drives and say hey this thing's got a custom USB stack because I don't recognize any of the access patterns on the disk so we look at the file the first time there's the second time I mean given the round of applause I assume everyone understands what just happened but I was able to calculate the check some of the files the same file twice I mean on this system I had to drop my disk cache in between because it's a more complicated system that's not the case obviously with things like embedded devices because the whole point is that they don't have enough memory to cache this thing and so that's why they're reading it twice you want to jump to a proxy demo yeah do you want to just go straight for it okay so the next thing we can do which is really cool is proxy USB commands through our face dancer interface which means you can plug a USB device into the host and have the face dancer act like a proxy for that same device exactly the same thing you do on most network connections where once you have that proxy in place you can do really nasty things except there's no such thing as a certificate validating the USB device so the first thing we can do is we're going to write a full emulation layer for a disk in order to be able to change the data you can write a really simple filter driver that sits in line waits until it sees a certain data packet modifies just that packet and continues so what we're going to do now is I have a hackerf hooked up as you can see on the left-hand side that's the information about the hackerf I'm not going to attach any more devices I don't have a second hackerf up here I'm going to run the face dancer USB proxy I give it hackerf's USB identifiers so it knows to pick it up it just talks to it via LS USB it doesn't need a driver for it it doesn't need to care it doesn't have to care about a driver for it or anything like that it can use lib USB to generically talk to the endpoints and then proxy them through great for here the face dancer and generate those endpoints at the other end I should hit return the right window so it's going to do that the enumeration has hopefully happened you can ignore messages that say fail nothing has actually failed that's our note to ourselves that we want to do something there later but now I should see that instead of just having one hackerf hooked up to my system my system should think it has two hackerf hooked up and you'll notice it does the other thing is you'll notice when you apply change the firmware revision to still hackerf anyway that demo is exclusive for you because I wrote it at two o'clock this morning but you'll see wow I'm in complete the wrong file yeah you are I'm a professional it's alright this is our filter this is the filter that makes that change happen and all it does is have a string encodes it to utf8 and then puts that back into the packet so it takes a packet that is a vendor request to get the firmware revision and takes the data from it throws it away and then puts the new data in there instead so that allows us to modify things on the fly it's also going to allow us to do you're welcome I was going to skip over a couple really sorry we're going to have to skip over ScanLime's demo but we'll shut off at Torcon and we'll also show anyone outside in the field afterwards just to clarify USB proxy lets us access the data on the fly so we can log that data to do things like log to pcap I could pull up Wireshark now as we're enumerating this device and I could have my target Windows system with a completely closed source driver that I can't access and I can have that USB device plugged into my machine and I can proxy that traffic through my laptop at which point I can just use the USB mon on Linux to get those packets in Wireshark and reverse engineer that driver and the really cool thing about that is unlike most of the software solutions that do similar things, you do not need to control the USB host so unlike something that works as a kernel module we can actually plug one of our ends into a PlayStation plug a flash drive into the other end and then be monitoring the communications that that flash drive communicates with a PlayStation which is something you wouldn't be able to do just by manipulating things in the Linux kernel which has been previously used for the old version of USB proxy has been used for point of sale systems, somewhere in the world there's a regulatory requirement for something to do with the USB device hooked up to point of sale systems and someone emails me about it once a month and what they want to do is perform this attack on a point of sale between a point of sale system and the receipt printer and then the other three times I know it's been used have been reverse engineering games console controllers for the Wii U for the PlayStation 3 and for the Xbox 360 and in fact for Xbox 360 we went further than just reverse engineering and kind of dumping that information and we were able to inject things so we made a little device that when you hit a little button on it it would inject a series of key presses so you could do some kind of power move in whatever game you're playing as long as you have a device in line between you and the you and the other end and this enabled a friend of mine to cheat games while playing with his friends and so like that's really where this project comes from so the things that are coming up we need to get it work on the radio badge we need to get it working on systems that have an embedded Linux distribution with embedded device controller my printer has a host port and a device port so I'm pretty certain I could use my printer as a face dancer so you're just one printer exploit away from you take over the Linux kernel on your printer it could be a face dancer too and nicely because I've already got a great fit I can fuzz my printer to try and find that exploit to turn it into a face dancer to fuzz other printers right so if you get a face dancer you can get a face dancer so yeah it's easy to get root once you've got root so we want to look at power delivery especially over USB-C there's a lot more power available there and you can do some pretty nasty things hopefully and the power delivery protocol is a whole new frontier for USB some reasonably complex parsing that is done to enumerate power delivery and then I think one of the coolest things that there if you search that has been done with face dancer technologies is Micah Scott's face whisper which was a she built a derivative board based off the original face dancer that was actually capable of repeatedly requesting enumeration from various devices as she glitched their VCC and because of that null termination issue we were talking about earlier one of the things that would happen if she interrupted the DMA just the right time is that the controller would actually say oh I'm not supposed to stop now let me just keep reading memory forever and so the DMA would continue past the descriptor which is usually what was being transferred on to the rest of the firmware and so she was able to basically and because USB is not terminated it never ends she was able to extract the firmware from a variety of USB devices including a Wacom tablet just by sitting there on the USB bus controlling enumeration and also power glitching she's a video about that in YouTube if you search for I think USB glitching scanline that will come up I think that's right so here are the links to the project Great Fair Experimental is the firmware you require on the Great Fair if you are lucky enough to have one at this stage I don't know when they're coming out based on the code to make all this USB stuff happen everything we've done so far is already up on GitHub so we've released everything already months ago it's already publicly available we're about to be thrown off stage we won't have enough time but we will absolutely take questions just outside the stage afterwards if there's not time to take them now indeed there's about one minute for questions perfect, very quick question why Python can I do the same in C instead of using Python so the original USB proxy was written in C designed to run an ARM core the reason we use Python is because it means that I can write it in like three lines and not really have to worry about all that but there's no reason you couldn't it's just the original face dance code was in Python and we kept going from there two of our goals are that we want to be able to do USB hacking really quickly this is more of a prototyping thing something you would actually build a product off of so Python really great for developing quick code and two it's multi-platform a lot more easily than C is so a lot of our users don't want to be bothered compiling things but you can absolutely, it would be feasible to write these things and see if you want to there's no reason you can't re-implement this in C because it's all you can talk to the USB device and you can look at that API which is in the face dance code and re-implement it and see if you'd like all right we'll take other questions outside if there are any and thank you very much for being patient thank you very much, that goes to the session