 Now it's my very great pleasure to introduce Dominic and Kate who are going to talk about opening close systems with Glitchkit They brought a bunch of interesting looking electronics with them And I'm very curious to hear how they are going to help us liberate all our Devices so please give a warm welcome to Dominic and Kate Thank you Yeah, there we go. Everyone can hear me. All right. I'm Dominic. This is Kate these are our faces And Twitter handles if you want to Live tweet about how terrible this is Right. I work for great Scott gadgets and mostly I work on software and firmware for embedded devices things like hacker F great-fet ubertooth Do you want to explain who you are? Hopefully my microphone is working perfect. So I am not really in the infosex scene. I'm more of a reverse engineer So I maintain projects, especially that lets you get more information about systems and see inside them I especially love things that help people to learn about Different systems and kind of get a foot in the door in various things face to answer for example is something I maintain the newer version of and that lets people get their fingers into USB great-fet. We both Maintain and that's a multi tool that lets people get their fingers into all different kinds of things so we're coming at this talk from a perspective of people who really Neither of us really are interest like people think you say you write software for a living exactly I do reverse engineering which is kind of on the periphery of the core like hacking culture kind of thing and Really what we're here to talk about today is a tool that we built that helps people do things like reverse engineering and learning about systems more effectively So yeah, mostly what we build is is interesting tools to open up things And then we rely on the idea that other people will pick up those tools and do really interesting security things with them. So Naturally if we want other people to pick up our tools, it seems to make sense that we make most of them open source and available to people and In that spirit that we'd like to thank a couple of people up front Micro Elizabeth Scott scanline she does some fantastic reverse engineering work and Is very good at explaining things if you haven't seen her Streams and YouTube videos and things you should absolutely check them out And there's some stuff in this presentation that there was directly inspired by her work Colin O'Flynn has done an awful lot of really interesting glitching work and talk people about that over the past couple of years And also we should thank great school gadgets because they do Enable us to come and attend events like this and spend our time working on these things Right and so in this talk, we're not really the you know the brilliant people doing anything. That's absolutely earth-shattering We're not coming up with new You know techniques that a light enable you to like sit on the cutting edge of science But instead we're tool builders we build things that let you do cool things And so we kind of have like the foundational people who have you know kind of Started blazing some of these past forward and we're building on a lot of their work so yeah, and I mean the reason that the first two are listed as people who are smarter than us is I tried to I actually tried to pick up Colin's work and it's it's fantastic His chip whisper is really cool and the software is kind of great and I knew nothing about glitching and I think we got into a conversation about a This stuff's really cool But like wouldn't it be great if someone who's like not a genius like someone like me can pick it up and Like glitch a system and so that's that's kind of where this project came from It's just trying to make those things just a little bit more accessible a little bit easier for everyone to use So let's right and a lot of this came out of conversations with those first two people so yep It's really awesome. I really appreciate the the foundation they built so Kind of give you background for why we're doing this kind of thing This is a the circuit board for an HDMI switch nothing super special about it other than the fact that I was using it a few months ago and it was Incredibly it had an incredibly irritating flaw in that sometimes when you're doing something like playing a video game or watching TV It would sometimes flicker on and off and so naturally I did what anyone does when their Electronics stop working and they took a you know, I took it apart Figured out what the problem was in this case It was all the little signals the hot plug to hot plug detect signals that tell you whether their HDMI cables Whether those cables are present and plugged in the signals that indicated presence actually had a little bit of noise on them and The system wasn't properly compensating for that noise So every once in a while a cable that didn't port that didn't have a cable plugged in would suddenly see a Cable for just a split second and it would try to automatically switch over to that input and This device happens to be driven by an Intel 8051 Equivalent microcontroller a derivative microcontroller and if I had the firmware for that microcontroller It would have been probably 10 minutes of work to you know put a little bit of debouncing put a little bit of noise filtering into that System and be able to have fixed this and have this work But without the firmware and without this kind of thing. It's the kind of thing where you have to start off by rewriting the firmware from scratch or Coming up with some other hacks and analog filtering order to make this thing work or as I did buy a slightly better HDMI switch. Yeah, yeah, sometimes the solution is to build a glitching framework and sometimes the solution is to spend 50 bucks and I'm really pleased that you chose both here's another device that Was messing around with a little while ago. This device is the inside of a thermal camera. So it's the third 2g 165 It's a relatively inexpensive something like 200 or 300 usd thermal camera And it's actually a really cool piece of electronics. It's got an SD card Micro SD card that it captures pictures onto it's got a USB port that it uses only to upload those pictures to Computers and then it's got a pretty powerful Pretty large microcontroller on there and it would be really lovely to use a board like this for all kinds of you know Experiments where you could take in thermal data and pass it to a PC But the designers of this didn't really think about that use case didn't identify that as a use case They were interested in and so despite the fact that you have this giant microcontroller with 512 kilobytes of flash Which was only using something about a hundred kilobytes. There's without the firmware That is on this device. You can't really do that much and so luckily this particular device has its firmware in a Accessible format because it takes firmware updates over USB and if you look at the file that they upload onto the Onto this device it has what looks very clearly like an arm cortex and vector table at the beginning But that's not the only thing that's in this file There's also some metadata in the beginning and scattered throughout this file and unless you want to sit there Guessing it what the metadata means, you know, like what kind of checksum is this? What kind of CRC could this be is this you know a length here that describes how much firmware there is before there's another blob Unless you want to guess at those kind of things. You're kind of not even able to upload new firmware to the bootloader Right the bootloader itself that's on there. That's not continued in those firmware update images. It knows what is used to Actually talk to it and to upload things onto there And so if you have this bootloader if you're able to get that water out somehow Then you can easily go reverse engineer the code and figure out what the actual structure that metadata is and Though I didn't actually get the bootloader out by glitching eventually I figured out the format was able to Find another vulnerability and then get the bootloader out via some simpler exploits This device was able to be hacked and there's tools for it And it would have been a lot easier to do that if we had the ability to get the bootloader out almost immediately I'm gonna hand you a slight clicker now. Oh, wow, I don't get to play with this very awesome responsibility. Excellent. All right click click click so Not all but many many security Issues that we have come from us making assumptions and those some assumptions not being valid Such as oh let Dominic write the code. He knows how to code bad assumption things like string copy like String copy is like generally known to be a pretty bad idea if you're not giving it a length field if you If you use that like you have no way to know how long your input was and it's gonna just be capital of your stack And I hear from some hackers that that's bad On the right hand side here. There's a paper by Sergey and Julian about parsers and We have this concept that if we design a file format that those the two people build a parser for that very well-defined file format That those parsers will treat things the same way and it turns out people are very bad at coming up with unambiguous file formats And so you know parsers are bad now It turns out you do exactly the same thing in hardware One of the things you do is you have to make an assumption that if in the data sheet you say power this chip with a voltage of between this and this you kind of have to make the assumption that That power supply is stable and that power supply is constant and the same goes for the clock You you make this assumption that as long as the clock speed is within your valid range Everything should should work probably and you kind of have to make this assumption that the the clock is not gonna You know go away or change dramatically or the power is going to increase or lower dramatically and to This is where glitching comes in because what we do is we subvert those assumptions and are able to use them to To change the behavior of a part right and so we're able to secure systems usually by Identifying the assumptions we make and constraining those assumptions so we can do things like say I'm not gonna assume that the user is handing me a nice null terminated string that fits nicely in my buffer It's a lot harder to build a chip that behaves correctly when you start pulling its power away for a period of time It really drives up the cost of your chip same thing with the clock you start having these kind of fundamental assumptions It's really not worth coming up solutions Not worth constraining your device to necessarily have to work without power or without a stable clock And so when you start subverting these assumptions just like when you separate the assumptions of someone designing software You get all kinds of interesting and potentially exploitable behaviors Yeah, and I think at point you touched on which is that there are methods for for avoiding this They absolutely exist, but they're expensive. They They add complexity to the to the part you're using they add it cost And and what you end up with is is much more expensive microcontrollers Which do you then means you're not gonna get your you know dirt cheap? Internet connected camera or whatever other like cheap IOT rubbish that you buy is gonna go up in price and and the manufacturers want to use the lowest cost thing so like The vast majority of parts that we see out there like don't have any of those kind of protections on them Well, I can use the slide clicker. Come on. There we go So it's kind of a quick show of hands who has like knows how glitching works has glitched something before Brief I can't really see because there are huge stage lights, but I don't think that's a huge percentage of the audience so I was in everyone else's shoes up until very recently and So I'm gonna try and give you an explanation and then when I do it badly Kate is gonna fill in the gap But essentially there are there are two key types that we're gonna be talking about and that a lot of people use one is clock glitching And the other is is power or voltage glitching with with clock glitching what you do is you take this nice Wait, there's one of these a laser Well, that is almost invisible to me. So good luck to the okay What you have is you have these nice clock pulses that you can you can see on the slides and they The the I think the way a lot of people visualize what happens inside a Processor when the clock signal comes on it's like everything happens as soon as that clock pulse happens But realistically what what happens is those things happen in stages So first of all, maybe we increment the program counter and then we go and decode the instruction that we're pointing to and then we Work out what that's going to do and and maybe implement like you know is it an ad is it not just really stages But in parallel we have all the intermediary pieces of those computations coming together Right, so here we can see if we were to take a look inside the circuit We see all these different pieces working kind of together Coming up with different pieces of the computation and then finally right before the next clock edge or some period of time before the next Clock edge everything resolves to a stable state right Thank you but What happens if we if we shorten that clock pulse and we we Bring the the clock line back down midway through that can we can we make it so that maybe the some of that computation happens But other parts don't happen and spoilers the answer is yes And so we can do things like have the the instruction the instruction pointer increment and then the next the result of whatever the next that piece of computation is Doesn't go anywhere. It just doesn't happen and then on the next pulse the program counter is exactly where where it was But the previous instruction didn't happen. So if that previous instruction is a jump, we've now just moved over it in in the code Happy you can move on excellent This is the one that I don't know as well right voltage glitching So inside the chip or a lot of transistors. Yeah, this is my cue. No, I know a little bit more Don't do hardware So there's a lot of transistors and they when they're when they're stable when they're not switching They have they they draw very little power Right, okay Sorry that I have to keep checking it. I just don't want to get it wrong But when they are switching they draw they draw a lot more power And so the idea being that that they're fairly stable if you can make it so that when they're switching You rapidly change you very briefly change the voltage that you're supplying to the chip You will very great. You have a much better chance of influencing them in a way. That's that's unintended So if we suddenly drop the power on a chip as it's calculating say the Final stage of a checksum or something is that yeah Then it's much more likely that those values will come out Incorrectly right the takeaway here is that if you have a portion of the chip that is making Some kind of computational change something that's changing state And you were to suddenly deprive the chip of the energy it needs those pieces are much more likely to be affected by the rapid brown out the rapid dropping of voltage then Pieces that are in a steady state Right if the if the chip's not doing anything and you move its power supply around it's actually gonna take have that much effect It's only the things that are changing right now So the register the value that it's currently writing or or something like that is much more likely or the value It's currently calculating. It's much more likely to change at the point that you you move that that power rail Well, we got through that. Okay. Is anyone genuinely feel more informed than they did two slides ago? Wow, it would be much more flattering if it wasn't my employer So here's some pseudo code This is this is just something let's say we've got a buffer. We want to send that buffer somewhere We have a function called send bite and we iterate over that buffer sending a bite I've written code like that on the left. I've imagined many people here have and this might be what it looks like when it's compiled So let's say that what we really want to do is send out that buffer, but we want to subvert this system To to send out everything that comes after that buffer. We want to send out the rest of RAM Now there are a couple of things here a couple of steps in this in this program, which Might be of interest to us and before we did this is disclaimer. This is all pseudo code So this is assembly that I wrote to be representative on a plane I think it's a weird mix that I come up with between like a risk processor in it 851 because that's how it was natural to express this particular thought but I think this is something that people who are familiar with Assembly could understand excellent. All right. So this is written in Temkin micro architecture So first up what we do is we we multiply We multiply out this works better on black background We do this multiply to work out the the size of our list if we could modify that in some way We could get a length field that's way way bigger than than the length field that we're supposed to and and so therefore So when when we compare in this length, we're gonna get much more Alternately every time we go around the loop we we decrement the length if we can make this decrement fail Or happen in a strange way we might be able to Get a much bigger number Load it into the the length field and therefore again We get a lot right out and the final one is this this jump if we can make that jump get skipped then The length will already been decremented next time around the loop The length will become negative one and we'll just keep decrementing the loop until we run out of Until we we loop through that entire integer again And so we have these opportunities that we can if we're a capable corrupting values or we're capable of skipping instructions We have these kind of windows that we can use to see things that are past that buffer and memory and Depending on the individual device and what you're sending out that could be Transmission from something that's in read-only memory and you could get what's next after that read-only memory Which might be firmware or might be secrets if it's in Ram potentially with other values that the device may not want to disclose and we'll see in more complex cases We can actually take advantage of this to get more than just the data that's immediately following in RAM But the key is that that timing is absolutely critical in order to be able to do this We need to be able to we don't necessarily know at what points exactly the device is going to be vulnerable We can kind of guess here that it's in those instructions in red that we're likely to have the effects we want But we don't know when during those clock cycles. We might want to glitch We don't necessarily know, you know, what kind of glitches are going to be effective or if any you're gonna be effective on a given system So in order to do that we need to be able to experiment in order to be able to experiment and have those experimental results mean anything We really need a very precise way of identifying time as is relative to the thing that is executing the program itself Yeah, so this this diagram just kind of shows that that like this red line here These are all the options we have to have a successful glitching attack And and it's you know, it's fairly spread out, but there are there are a lot of them So this is the multiply we've got one chance at that then then this kind of decrement happens every time around the loop and And we always we have lots of chances to hit that one each time and then finally we have this this jump When when we finish the loop and and like we only have one chance at really Skipping that step as well because there's only one time that that jump is meaningful And that's when we hit zero right and so this may seem pretty synthetic No, go ahead for the next life. So this may seem pretty synthetic That may seem like the kind of code that you'd hopefully not see in a lot of Programs depending on the use case and depending on the constraints But this is exactly the way in hardware a DMA control that works, right? It is constantly Subtracting from its length register by one or more It is constantly incrementing the address that it is Reading from the address that's sending down the bus in order to gather data So even if that's off for example looked a bit synthetic. It is absolutely applicable to embedded hardware Yeah, and there's absolutely no error checking because what I mean you've got a DMA controller on a microcontroller What's it gonna do when it errs? It can't pop me up a dialogue that says hey something's gone wrong or you're not writing to the right bit of memory It's just doing what it's told So we've we've done a lot. Don't this isn't This isn't like a super Clever attack against something right through it. This is a little Python script that That Kate hacked up which talks to the DMA controller on our great Fed board That's connected to the system and just allows us all it does is take the parameters We give it and program it programs it into the DMA controller and I'm not specifically an amputee forty three forty three thirty Yeah, my controllers This is not something that you're gonna see in every DMA controller But on a lot of the embedded DMA controllers error checking is a premium feature and has left out of a lot of the individual Preferrals that use DMA so the CPU itself may execute on the bus execute transactions and get notified if it Requests memory that doesn't exist a lot of times a DMA controller will have absolutely No error checking just because there's no way to handle errors one hardware is executing them So it won't stop transactions. It won't generate a fault It won't generate an interrupt It's just happy to do things like read all zeros right and so this is the thing I just read a section of memory that I know is RAM And I read 128 bytes out of it and it and it gave it to me But if I were to do the same thing again and read what address do you want me to read? Oh Give it like the three zero zero zero zero zero zero zero let you do that But there's sections of memory that that don't mean anything their memory maps I oh There are just like reserve sections that don't exist. It doesn't error it all the DMA controller We're we're just representing on screen exactly what the DMA controller is giving us back And when it has when it gets nothing back over the bus it says to memory. Hey, I'd like to read this this value and The various peripherals no one no one responds and DMA controllers as I guess it zeros then and it just keeps going And so if we can convince a DMA controller to To read a section of RAM and just keep going it will just read us zeros until it runs out until its Counter overflows and then I'll just start again at the bottom of RAM sometimes And so we can just keep reading as long as we can get the DMA control to do the thing we want We can get it to keep reading us out And this is really cool because if you actually go and ask it for some an address that is all the way at the end of RAM this particular microcontroller has a 32-bit address space and if I say I want the absolute last byte that's in Address space and 127 bytes following it it will happily read that last byte and then the 127 bytes It gets when it increments that last address and Rolls back around to zero. Yeah, this gives us almost unlimited opportunity if we're willing to read absurd amounts of data To explore the address space and if we happen to for example corrupt a length field That's supposed to have a value of 10 and it's 32 bits long and we get something. It's really really really long There's chances that we're going to get things that are you know after that in memory wrapping back around and starting again Yeah, exactly. So if we do manage to take the the 32-bit length field and and Glitch it to become negative on jump that jump that Comparison to zero and gets been become negative one It will continue reading all the way all the way around until that integer loops Which happens to be about the point that memory loops on this thing. So like we get all of RAM Don't know describe that the chip whisperer. So one of the foundational pieces of technology We are using and we're basing a lot of our work on is the chip whisperer So picture it as the chip whisperer light, which is the inexperienced inexpensive variant of Colono Flynn's glitching toolkit and this is a toolkit that lets you do some power side channel analysis and some basic glitching attacks it has modules for clock glitching and for power glitching so we can implement both of those two kinds of attacks and It provides software and firmware on a microcontroller and FPGA that are designed to let you precisely time glitches Relative to some known synchronization point, but that synchronization point has to be specified for the chip whisperer So the chip whisperer light has only the capability to synchronize to a single rising edge or single level Triggered event so it can't go and say I want to time this to for example a USB Communication or to a UART communication. It can only say tell me When something happens on the host by building your own piece of hardware and having that hardware indicate to me that something's happening Yeah, so what we want to do is we want to be able to tie that that you know DMA something that's using the DMA controller and and Decrementing that that length value or whatever to to the chip whisperer where we want to just be able to say yeah go for it glitch now and so we we want to tie those two things together and We did So if you look at a typical microcontroller datasheet what you see is something on this side these lines the All the little boxes around the outside of peripherals that implement various protocols and things like that We've got you arts. We've got us be somewhere on here. We've got 80 season DAX this SGP. I think up here is a high-tech throw thing all these protocols that you might want to speak So the challenge is an attacker is if I take a device that has a lot of these buses populated I take a board that is using you starts and you know, it's using a you are and it's using USB And it's using the SD port and it's connected to an emmc card if I Want to start breaking into that device I have to build purpose-built triggering hardware right now that is capable of identifying exactly when Those individual peripherals are being used and for what so in order to synchronize up with this I have to go and build purpose-built pieces of hardware to test on an attack that I'm not even sure is Necessarily going to work and it would be a lot nicer to be able to Instead of having to build that purpose built hardware have some kind of toolkit that provides a lot of those missing pieces That you can actually go and say hmm. I wonder if attacking USB is going to work. Let me try USB today Okay, this pre-made toolkit is showing me that USB seems to be a good option You know 12 hours later when you've run just for a while. I seem to have some interesting behavior Let me go more into more depth with USB. Yep So this is where glitch it comes in This is something that we that we've been working on over the past couple of months And it ties together a lot of these features that we that we want to use It ties together Various different like it has got a synchronization features of Do I go into this now? So this is just an overall diagram of glitch kit. We're gonna go into it in detail in a second Yes, that is that this is our open source software toolkit with that is designed to work with some existing open source hardware But kind of bridges that gap and lets you go from Kind of having interest in exploring a system to attacking that system as quickly as you can you still gonna have to make some hardware modifications to Your target device, but that's you know adding transistors and rerouting wires instead of building purpose-built hardware in order to be able to try testing those individual Glitching those individual buses and often the modifications that you make our modifications that Are actually useful across all of those different buses for example modifying the power supplies that you can glitch its power Exactly useful no matter which one of those buses you're trying to attack with With voltage glitching. Yeah, the goal is that you you know We're not trying to bring the amount of hardware hacking you have to do down to zero because that's virtually impossible in this and with this technology But we're trying to take it from I've got to spend two weeks Like designing a custom board sending off to a PCB fab getting it back building this thing with a Compost to like a couple of hours. Okay Well, I've pulled off all the decoupling capacitors and now I've hooked up my hardware to it Now let's go and see if we can glitch it. So like just trying to produce that turnaround time and make it easier Especially if you don't want to have to design hardware. So what we really need is something that takes the influence a bunch of these different These different peripherals and things like that. So it seems like if we're gonna in trying to Play with those we should just find out what part this data sheet is from and and build that onto a board Which turns out we already did because we did this the other way around And this is great for that. That's one of my hand. It's about this big me for scale it is It is a microcontroller board that Mike Ostman designed his some guy He is open source hub where it's it's like a breakout board to build interesting modules to sit on top of it does various USB stuff that we've spoken about before and It's you can go build one yourself right now, but designs are all on github And so this is this microcontroller here Kind of the way this board wound up existing is that this was used previously in hackrf It's a really deep yeah, we use this chip in hackrf and and I think Mike was reading dates sheet at some point. It's like this part's really cool I'd love to use some of the other peripherals and I'd love to make it easier for other people to use some of these peripherals and and see how And and have easy access I want I want to be able to plug something into my USB port and then I want to be able to speak GPO or Spy or something directly and I want to be able to do all those things on a single board and that's kind of where great Thank you, so great that provides this base platform Which which you can build on top of to add other features that are these Add on boards that are similar to shields called neighbors that theoretically add other You take your head of the name a little bit Thank Travis good speed for that, but I have no problem calling them neighbors I have a problem with the fact that I spell neighbor differently to the rest of my company Um So let's step through let's step through glitch kit. They're a column one more thing. Oh, I'm sorry So when we talk about great that we are talking about both that board and other boards that are compatible with it So if you have a radio badge because you went to CC camp a few years ago in 2015 Yeah, 15 Then you already have a great bet because the great that software runs currently on that and it's not the preferred form She can't stack those additional headers on there, but it'll work just fine for doing glitching attacks Yeah, remap a couple of GPIO right so bet you watching you bought camp tickets now Anyway, so right let's step through loop through Glitchkate There are three main kind of sections of this this code first up We've got an event router and the event router lets us Take various things that are happening in our target hardware and combine them in interesting ways. So, you know, we've got Looking really quizzical about me about this. I'm sorry So so maybe we want to you know only bring up the power supply when this other thing happens and we want to like Fiddle with the clock in some way when this GPO line goes goes high And we are able to kind of connect those events and and make more complicated structures of of The hardware state right so a common kind of task when you're using these devices You're trying to glitch devices is to get things synchronized Across a variety of tasks So you might let's say be attacking a USB device where you need to apply power and then wait for the system to boot Wait for it to show you that the mic controller on board has started up and then at that point You're ready to apply some stimulus in order to generate an attack Or you might have a device that you need to power up and then immediately provide a clock Which is going to drive that device But you don't want to provide that clock before power is on otherwise you're driving current into a chip that has No VCC that's no supply rail. So this event routing system is kind of the heart of glitch kit And it lets you take all these different pieces of information all these pieces of stimulus and use them to drive things like All right when VCC turns on for the target board I also want to start a clock and I want to wait for The system to appear to boot by monitoring one of its GPIO and seeing when that goes high and then Finally when that happens I want to throw some stimulus at it and then finally when that stimulus has taken I want to trigger a glitch So that event routing system is what connects all those individual pieces. We also have a clock management section, which is the Which handles things like Making sure that all the individual pieces of your system share a common clock when you can It's a lot easier to get everything synchronized up if they're all executing on the same time base So the clock management will take in an external clock and allow the glitch kit hardware the great Fed itself to be To execute on the same clock as your either your target or as the chip whisperer And so you can get all of the chip whisperer and the great Fed pieces of that stack synchronized up Yep, and it'll also provide clocks to things that are better off being given an external clock so it can then go and apply clocks and Theoretically in the future modify those clocks for clock glitching. So if you're using this particular path So it gives you the ability to buffer clocks and spread them out throughout a system without having to necessarily build purpose-built hardware in order to ensure that the clock is stable as it's being distributed right if you I guess the short way of saying that if you if you're gonna do things that require like incredibly tight timing It's useful to be running from the same time So we can have the chip whisperer board and the great Fed and whatever our target device that we're trying to glitch All running from the same clock So they're kind of running in lockstep with each other so that we know if we're trying to like if we've got a time offset between You know the star and and when we like do that that voltage glitch. We know that's consistent across the boards So the other thing you might want to do a lot of Glitching kind of to try and get the the bootloader or something might happen like Or doing something weird to the bootloader might happen super early on you might like turn on the chip And then immediately try and do something after a short couple of instruction delay or something, but sometimes you want to Probe the hardware in some way you want it to boot up normally, and then you want to modify in some method some some some style and so we can act as a USB host and a USB device and sometime in the future Flash chip or an emc emmc device and so the idea being you know maybe maybe the thing that I think is actually going to be the the the request to the device that I want to glitch is like some some USB command that has to happen after we've enumerated the device So we've got like five or six USB commands that need to go between the host and the device before I can start sending it this This command and and then trying to glitch it during that command And so what we're able to do is we're able to bring up the device enumerate it get into the right state Send it that command and then immediately tell the chip whisperer Now's your time to start glitching right this gives you the ability to do really precisely time Stimulation of that device. So if you think that's a vulnerable piece of code or a vulnerable hardware function is only ever exercised Once you've received a certain command. Let's say, you know, I'm a USB device. I have a capability to self describe I'm only going to do that when you ask for a descriptor You need to be able to go and start poking that device and prodding it in order to get it into a state where it's doing the Test that you think are vulnerable and in it while you're doing that you often want to Know what stimulus are being applied and where they are in time because sometimes the stimulus for triggering is I've just asked it to Respond to a given command. So all of these stimulus modules both exist and to move the device through You know a given device into a given state and exists so that they can provide inputs to the event routing system So you can do things like say turn on the USB V bus and then send the command and use those as inputs for Both for glitching and triggering glitching and for generating other events like turning on clocks Yeah, so so by extending the the By allowing us to kind of interact with the device for longer and do more to change the state of the device before We try and attack it we massively increase the attack surface because we can now we're not just going for For a small subset of the Of the code that's running on a device We're going for we can you know start to play around with all sorts of weird arbitrary USB functionality of this thing because like you don't know where which part of it is going to be the most susceptible And like there's a fair chance that the descriptor stuff might be really Solidly written it might even be implemented like in hardware on the peripheral But like those USB vendor requests that someone's like thrown together to like you know the day before they have to ship This piece of hardware they might be written in that slightly more sketchy style of yeah Let's just take them. Let's just decrement an integer and see what happens Or there might be more than one thing going on in the hardware as a descriptor is sent out And that makes it very difficult to glitch because if you start glitching the descriptor request you might also knock out Something that is responsible for the core functionality device and the device's memory bus may go down Right so being able to explore a lot of that is really important also worth noting I think this is probably the first pitch you've heard today where we tell you that a Project massively increases attack surface Yeah, vendor pitch Increasing your attack surfaces. Okay, so so trigger feature. This is this is kind of where this I guess all came from originally is that One of the things we wanted to do was be able to have these kind of more complex methods for deciding. Okay, well So like they for example the simple event trigger here what it does It allows us to hook into a bunch of IO lines on there on the target device and say well when this thing happens Five times and these two lines are high and like this this line pulses That's when you trigger and so this is kind of fun because you can just hook up to like a spy chip and you can say Well, I know this thing's gonna read like Four times when it starts up and then what I want to do is try and like glitch it right after it does the fourth read And so all you do is you you hook up to like the enable line and you say well when that one's pulsed four times That's when you trigger or like you had a more complex example The simple event triggers let you take a variety of just general boolean conditions for input pins and build complex Conditionals out of them. So common example, and I think the the more complex thing that I was talking before is I might have a microcontroller that reads some information of an external flash and I might want to know where it is in that read and I could go and build a whole SPI peripheral and you know kind of fake an SPI flash chip and know that by Emulating that SPI flash trip I get this insight or I could say okay I know that this thing behaves the same way every time the fourth Read the fourth thing it reads is always that piece of information that I'm interested in using as my time base So let me just say okay the you know 24th clock edge here or the 30 second clock edge here While the chip while the chip enable pin is low happens to be the thing that I'm interested in triggering on and this Necessarily have to be the thing that generates that final which trigger this can be the thing that prompts you to let's say turn on the systems clock Turn on the clock to the right to it another target device or you know You can use that as a time base to start executing some simulus. So when it gets to this point, that's when I want to start sending it USB Packets yeah, and to a science and you might might do that because you might want to apply power to device and then wait for It to come up before you start trying to talk to it over USB and and things like that And so you might just wait for for example like those those IO lines don't have to be like complex chip chip interfaces You can just hook into one of the LEDs and say well when this LED comes on, I know it's booted something like that you arts I don't really want to talk about you up because I influenced it and it currently doesn't compile But you are it. I mean, it's not surprising you art is Is like a pretty common kind of debug interface that you're gonna find like if you just tear open one of those like Standard routers that you get from your ISP Like that thing's got a gonna have a serial connection on it And so you might want to use that to work out when its bootloader has started up or something like that because it will dump some information And then these things can be used the final thing is to then talk to the chip whisperer and trigger some output from it So I didn't this is a cool thing because you can you could take that trigger signal And you can trigger the chip whisperer to start doing its glitching process Or if you want to you can use that to you know drive the trigger input to your oscilloscope or logic analyzer So you can use this as a source of debunk information outside of glitching even though it's not our main purpose So really this is a general purpose stimulus and triggering engine that we happen to be using for glitching so one of the kind of Pieces of work that happened a couple of years ago before a couple of years ago before we are now that was Kind of really inspiring for this was done by my friend Micah who wanted to be able to take a USB tablet that she had and use it as Kind of a general code execution engine to prove out dead an idea that she had which was that these things are awful lot Like RFID readers and she kind of had the idea that she wanted to be able to take this run her own firmware on it and be able to You know read an RFID token that was held really close to the actual switching matrix of this Wacom tablet This is the kind of thing that you normally use with an inductive drawing pen the kind of thing where the pen has no battery But by holding it close to the tablet, it's able to receive power modulate the its load on that Switching matrix and thus kind of communicate a little bit of information like yes I'm a pen I'm being pressed this hard and That kind of functionally looks a lot like an RFID chip which also does kind of a load modulation So whereas the pen was receiving power and then loading the power lines more or less In order to communicate where it was on a grid and communicate how hard it the nib was being pressed an RFID takes power And then just transmits back feel that load modulation a simple fixed ID And so she had kind of the idea that those things could be It was basically the same pieces of hardware just the pen in this case was a little bit more complex and so she wanted to Be able to get some firmware execution on this device But looking at it she found that it had a custom mic controller called an LC 87 Which was a completely custom architecture by Sanyo or on semi and it Had a debug interface exposed and on that was completely undocumented So she wasn't able to extract the firmware in any easy way. So What she did because she is really good thing. Yeah What she did because she's super devoted and really loves getting in depth these kind of things and she decided to try to extract the firmware by Taking advantage of the way USB packets are sent and trying some voltage glitching techniques If you look at the way a USB Control request is sent it happens in a few stages first you send it a command In a stage is called the setup stage which can contain the standard USB commands that Force compliant devices to describe themselves. So like a get descriptor request will make a USB device respond with some descriptor Describing its own functionality. So when you plug in a USB device and it says, you know, hello, yes, I'm a Wacom tablet Your operating system knows that because it asked the device first for its device descriptor which contains the USB Device descriptor which contains a vendor ID and a product ID and a couple of string descriptors that contain that string Yes, I'm a Wacom tablet. I'm a CTE 450 and in In order to be a compliant device every device has to be able to do some amount of self-description and the way That's usually executed is by taking small pieces of data that are usually either in RAM or in read-only memory and Just DMAing them right out of the device So here we have a get descriptor request. It's executing It has a single packet that is transmitted back in response and then we have an acknowledgement that packet was Indeed received so we have the host sending get data, please give me that descriptor We have the descriptor being transmitted in response and the host says yes I got this theoretically doesn't have to be one packet in the center If the whole the device decides to respond with a very very long packet that could also theoretically be valid So there might be multiple packets that make up a longer transaction So let's say you want to send 512 bytes on a bus that has a maximum packet length of 64 that could be packetized and broken up into a lot of sequential packets if you look at the way a USB Device works. It's often very similar to a host controller in that it has a linked list that contains Basically an amount of bytes to transfer and then pointers in memory to the pages that contain the data that you want to send So really you have a length and an address here And if we look at the way I did get descriptor request might work for a long descriptor You could have the device Essentially populating a little DMA descriptor that says I want to send 256 bytes and they start at address hex 1000 and The device is going to start doing that. It's going to send out a single packet of length 64 It's the most you can fit on this particular bus Mostly can fit in a single packet on this particular bus rather It's going to decrement the length and increment the address This looks a lot like the example we provided in the beginning it's going to keep doing that until it gets the point where the length field reaches zero and USB is almost the null terminated kind of protocol in that when it finishes a transfer It indicates that by sending a packet that is shorter than the maximum length So in this case it sent all maximum length packets until it was done So it has to send a zero length packet in order to indicate that it is indeed complete Now if we're able to start applying voltage glitching or a clock glitching if we're able to glitch something in the system and Corrupt that length and what we'll get instead of those nice orderly transaction where we send four Individual packets to just to let's say send out that configuration descriptor is we'll get a length that is potentially much larger Which continues to transmit and transmit and transmit well beyond when the device should have stopped And if you have a device with the DMA controller that works like most of them do on my controllers It will continue not just out of that descriptors location in RAM or ROM But continue throughout the entire memory map until that length field is brought down to zero and so In order to be able to do those that kind of glitching to the system You really need a way to be able to synchronize with the system and provide the stimulus So Micah built a custom piece of hardware called the face whisper name because it's use of the chip whisper technology it's descent from chip whisper technology and its inspiration in the face dancer project and this particular board Contains a microcontroller which happens to be the same one that is on a chip whisper and a USB host chip Which happens to be the same one that is on a face dancer and then some clock buffering hardware and all that it does is With very precise timing synchronize itself up to a particular point in the tablet's execution tablet microcontrollers program execution and then send it some USB packets and Simultaneously trigger the chip whisper to start executing glitches. So in doing that she was able to actually steal the firmware from this microcontroller and Using that she was able to find vulnerabilities in the firmware and eventually prove out that indeed you could read RFID tokens using a USB tablet as long as they're pressed exactly against the tablet and This is very cool both because it showed a novel way of getting firmware out of the device and Because it was a really ingenious solution to get at something that was a whole bunch of steps away from what she initially wanted So she's the kind of person who has that kind of like hyper focus and dedication to say Oh, I'd like to see what the firmware is in this Let me build an entire build piece of purpose built hardware Firmware and everything you need in order to be able to you know get the firmware out of a tablet So they can then go and look for vulnerabilities. Yeah, so I feel having having said all that I do feel slightly bad about the next slide Which is we we've essentially taken her idea and tried to make it easier and so like bear in mind glitch kit And all this stuff that didn't exist when she did this and she went like designed a board built a board attached it glitched the thing Got the firmware out what's our vulnerabilities? So now we can implement that in this Python code and so one of the conversations that Mike and I had afterwards was just So both of us really love making technology accessible to people right so one of the purposes of this and one of the things I kind of promised Michael when I started doing this is that we would take this this whole Technique which required a custom piece of hardware and you know required a whole lot of different levels of understanding and a whole lot of development in order to test on an idea and make it into something that you could apply kind of Relatively easily so here's the back-end code for Applying the same things with glitch kit. This is written in Python We were gonna go through this, but I think we're running low on time and I want to get the demo Done so so like I'm we're happy to explain this at some point But possibly not now just we only got five ten important part is that you don't actually even have to write this code because The final form of glitch kit has fancy GUIs that sit there right in chip whisper So if you want to apply the USB attack that Micah did you can start configuring that right from the GUI of chip whisper So demo time first. Oh, okay first demo. I just show off the chip whisper GUI and then we'll talk about our work Well, so this is the chip whisper GUI. We now have added these various glitch kit Methods so they'll talk to a great fit. So I mean there's a there's a big mess of wires and connectors and things On the table here and but essentially a we have a great fit and a chip whisperer hooked up to our target Great fat and so the the process of configuring this for the you go and you select instead of You know the type of target you want to select directly you say, okay? I would like to talk to The great Fed that's running a USB stack. So I'll select glitch kit USB and then from the UI you can Immediately configure guess I'd like to read a device descriptor. I'd like to have that device descriptor Be read immediately when a certain pins go high, right? So you can start building everything you need to Allow you to walk the interface you you wrote it I think it's kind of difficult to see on the board, but if you look over here, here's all the configuration settings you would Use to these are preconditions that determine what an individual USB event is generated up here on the side So you can go into this interface now and you say when this when this GPO pin goes high Then and and this one goes low and you know this one happens on the fourth time whatever and those complex conditions That we're talking about you can just have the at that point the software will then like set the trigger the The chip whisper to do its thing so Naturally, you know, we're not content was just reproducing other people's work. We wanted to try doing some cool things of our own so At some point we had to turn against our own creation, right? And so here is a great Fed that has been kind of actually sloppily modified So that I promised the board had all the flux on it before we made modifications But I've yanked every one of the decoupling capital capacitors rather roughly off this device Tried to make it easier to start depriving the device of power. I've added a couple of pretty nasty barge wires here one that Connects the VCC rail to a couple of SMA connectors that you can do things like Inject voltage in your inject glitching signals in pull the voltage down to zero and Because we still want some decoupling I have a decoupling network here that is replacing all the decoupling capacitors on the board and That is connected via a small impedance that we can pull the device really readily to zero But it can recharge the VCC bus through from these capacitors via that small in this case approximately 10 arm resistor and so Sorry to my cost man because we totally destroyed this thing that he's created or I totally destroyed this PCB that he created But more importantly, I'm sorry to everyone else because look at this thing Actually treated this picture and both they've got you know a significant number of likes and retweets And I got a couple of people being like clean your PCB It's not about how clean it is. It's about it's about the glitching I'm like this this actual like modification was done like after a couple of drinks like on the night of Christmas Which is like the perfect time to start switching new targets So so yeah the the great thing about this is we're now able to glitch this board and where we might even be able to get the Firmware off it, but there's some problems with that one is the it's open source So we already have the firmware because we wrote it But also it turns out the manufacturer of this board is incredibly litigious and he sends out cease and desist letters when people try and reverse injured in his devices I mean he sometimes writes them in Sharpie, but you never you know, he might Right so because we just yeah because one way already have a source code to this and it's on github And that doesn't make it a particularly interesting reverse engineering target and to because we're terribly afraid of litigation we decided instead of attacking the Grapefet software that we're running on the application processor that we would attack the bootloader that is sitting in ROM on the LPC 43 thousand forty three hundred series microcontrollers. Yeah, the LPC 43 hundred series have a have a USB DFU Bootloader and also some other USB functionality, which is sat in ROM and there's only one ROM section Here, which I can't laser point to but you probably do right so that This device has a USB bootloader that does all the same things as that tablet because it's compliant to the USB standard So it can do things like You know respond to a get Device descriptor request and so we started applying the same kind of glitching attacks to the ROM And you might be kind of saying well Why is it interesting to attack this ROM one is that on a bunch of these devices? It runs from this shadow area that is at the start of RAM because the Cortex and microcontroller once its vector table to be Located at address zero so it's very low in RAM everything. That's interesting follows it including on device parts with flash the contents of flash over here and Also, because if you look at the secure mode parts one of the things that they do inside this bootloader is read encrypted images from things like flash chips decrypt them and stick them in SRAM immediately following the Shadow area from which it's running. So if we're capable of doing glitches So if we can read out from the shadow area, we can continue reading doing that that DMA trick To continue reading into SRAM and pull out that deep now decrypted firmware from secure parts We only have five minutes left. So I think we should go ahead. I do not know how to stay this gooey as well as you do So I'm gonna let you do this This is the hard part. All right. All right See see that's what happens when you run it on my machine The grave hurt. This is tragic If in doubt turn it off and wait for it to connect and start blinking But here I am impatient wanting to just like click on it immediately. This is actually the hard part. So Let's clear the upper table from previous runs Essentially, this is issuing USB requests to the device and capturing the response because we have limited time I haven't told it what's a good response and what's a bad response So it's telling me every one of these responses has failed But realistically if you expand that dialogues that we can see what's happening there Scroll all the way down to the initial ones It's worth mentioning that this is a actually a simulacrum of the device running the way it normally would normally when you're glitching You would actually step through lots of intervals in order to find the few glitches that work So because we don't have several hours to do this glitching attack What this is actually the code has been slightly modified to Instead of always reading the correct descriptor It jumps to different points in the glitching stack that we've found having to work for this particular device So what you'll see here is we get a lot of a lot of responses that are the standard response They're what we expect to come out of it. They are it's reading. It's trying to read 18 bytes That's hex 12 of USB descriptor it reads 18 bytes to get 18 bytes But this one here it appears to have got significantly more data And so on a previous run earlier today as we said as Kate said this is this is simulated because it is not as quick as That when you actually run it on a previous run we dump this to To hex and somewhere Can anyone see that? Anyone read that at all? So I'm just gonna turn up my font size. I'd be appreciated. I think So what you can see here is what we were able to read out of that file in is Is a what we're able to dump to this file was just all the memory we're able to read from the USB descriptor location onwards and We were kind of going through it looking at it earlier and we're like, yeah, we haven't had chance to analyze it yet and then what we found was over here See it says USB C and under here it says USB s and those are incredibly telling strings if you've Designed USB systems before this is a USB command that's sent it's actually a scuzzy command sent over USB that's used in USB bulk only storage and this is the Token that precedes a response of status when one of those commands is executed So this Significantly suggests that this rom bootloader happens to have inside of it Some USB mass storage functionality and our first response was that's weird We didn't think this had USB mass storage and then we went back to the datasheet and reread it and it does and it turns out We've dumped the code of some of a some wrong functions that we didn't even know were in the chip so We were able to pull out nxp's ROM code for the LPC 4300 series And and obviously you'll be able to go ahead and analyze this and That's not particularly novel because you could grab that up with GDP as well But yeah, yeah, it's not the most novel but if you were to continue doing this work One of the theories that we have is that we didn't let this go for that long. We didn't capture that much data I don't have any secure mode chips on me But the theory is that after this kind of thing the SRAM You would grab would have theoretically a decrypted firmware image if it was sent a firmware image over usp so you could kind of use this as an oracle to take encrypted firmware images and Generate the decrypted ones We're now unfortunately completely out of time to meet so we have to go so we will take questions outside And if anyone has any questions will be outside Towards the internet Twitter our Twitter handle Sort of the beginning or or just fine as there's a great fair ILC channel on free node if you want to ask questions there and Thank you very much for for listening