 Howdy y'all. Who enjoys neighborliness? So wireless sensors are small little computers which can be connected over very low power radios so that you don't need a long battery life in order to keep them running. So if you have a laptop, it's called wireless and will run for a couple of hours without power but that's useless if you want it to run on its own. So while it's helpful for you, is there a reason why this one isn't working? Ah, see? So it goes. So anyways, while your laptop is useful to you without continuous power it would be useless if you intended for it to act as a server somewhere. But you don't always need that much computational power. You don't need a full disk. You don't need many of these things. You don't even need to be awake all the time. So the idea is that you can have a very small computer, like a microcontroller, sitting with the radio so it's still accessible on the network. It can run IPv6. It can run ZigBee. It can run all of these different networks. And then you can adjust its lifetime and its power cycling to do very useful things. But the question comes about exactly how secure are these things? How can you take them apart? How can you exploit them? So in this lecture I cover several different ways to do these things and I'll be adding some recent news as well in the commentary. And then at the end we'll go into the session room for the questions. But instead of questions I'm going to bring my entire toolkit and we can plug up to things and start breaking into them. And that'll be very neighborly. Oh, gotta switch this on. At some point this will work. Ah, bloody hell. At five. Just for the record I hate open office. Please excuse the blasphemous artwork. I hope that none of you are offended. I sincerely do. Oh, congratulations. This is the bargain edition. Okay, so today we're going to discuss a schematic capture which allows you to reverse engineer the actual design of a chip and why it's easier than you might otherwise expect. If you have a microcontroller and a radio, based upon only their part numbers I can give you a good idea of which pins will connect to which others. Because they connect in the way that they are physically intended to. In that you have hardware accelerated serial ports on the microcontroller side and you have a single serial port on the radio side. We'll also discuss the protocols themselves, the DC and SPI, and exactly how easy they are to sniff. So if traffic is going from the microcontroller to the radio, you can sniff it there even if it's encrypted from the radio to the rest of the wireless network. I'll also cover methods of dumping firmware, some of which are newly developed since February and will be in the commentary rather than in the slides. I'll discuss how to reverse engineer the firmware. So once you get a copy of the code that is within a wireless sensor, these methods will allow you to take it apart in the same way that you're used to taking apart PC software except that because the architectures are more varied, you often have to rewrite them from scratch. So if you sit down with Perl and you follow a few simple rules, it's easy to do things like identifying the starting and stopping addresses of functions. From that, you can easily make a call graph that shows you how the functions relate to one another. And I'll discuss how to simulate these chips and how to fuzz them in simulation or in hardware to come about with exploits for them, including a demo of a Stack Overflow exploit which allows you to inject foreign code into the microcontroller and run it in the same way that you would do a Stack Overflow on a PC. There are very rarely unbounded heap buffers on this platform because the heap itself isn't used. You'll very rarely find malloc or free anywhere within the firmware image. Because of that, the Stack attacks are more relevant than the heap attacks, which might be more effective on a PC. And I'll discuss how to fuzz a microcontroller in hardware when you don't have a simulator available. How can you tell when the device is crashed if it reboots in a fraction of a second? There's some neat little tricks for that. Now, a wireless sensor itself is composed of a 16-bit microcontroller, or occasionally an 8-bit or a 32-bit in more recent designs. It has RAM, ROM, flash memory, and EEPROM. EEPROM being optional and the same with PureROM. PureROM exists on the chip, on the surface of it, and it chemically exists there. It's not something that you can remove by changing a state in the same way you can clear flash memory or might accidentally clear RAM. Because there's code in ROM that can't be removed, you can sometimes exploit that code, or you can jump back to that code as a sort of return to libc attack. Now, flash memory contains the majority of the executable code for the wireless sensor. Your application runs from a non-rightable region. This means that when your application is running, it's very rare that you'll accidentally overwrite it with new executable code, as several attacks against the lower levels of PC software work. The recent SPI BIOS attacks, for example. Now, the radio itself, in the older revisions, would be a chipcon 2420 or a chipcon 2500 or an EM250... Oh, sorry, not an EM250, an EM... model numbers aside. The older radios existed separate from the microcontroller. There'd be a single bus connecting them, and commands would flow over this bus. In more modern radios, you instead have the two combined into a single device. Those are the ones that I published attacks against the Black Hat briefings yesterday. I won't be getting into those today, but tomorrow at 2 o'clock in the hardware hacking village, I'll be presenting those as well. And we'll be playing with some of those attacks in the break room after this lecture. Now, the sensors themselves are used for getting input, because the original ideal for this would be that you could throw a bunch out into a field and you could return the temperature at each point within that field. So if you're trying to do global warming experiments or things like that, you could just blanket an entire area with a bunch of sensors, watching the temperature at each point or the infrared light at each point or anything else that can cheaply be measured. And with MEM sensors following, you can also do things like acceleration. You can put them all around your car and you can tell exactly how the car is bouncing on the road. If the left side is going up or the right side is going down, you can get all of that information. In airplanes, they're looking at doing fly-by wireless, using these sorts of radios in lieu of previously wired sensors because you don't have to worry about the weight or the maintenance of the wires. If a wireless link is going bad, you know instantly. You begin to see packets be lost or things like that, but if a wire is beginning to fray, you might not know until it's so late that it breaks in the middle of the air. And they also have serial ports. There's some other maintenance connector, or JTAG, which is neighborly in its own, right? The two of the most popular chips for wireless sensor networks are the MSP430 and the Atmel AVR chips. The MSP430 is a von Neumann chip, which is the same thing that a PC is, in that you have pointers to either code or data. You have a single unified memory and any pointer can be resolved without ambiguity. So if I give you a pointer in hexadecimal as the word with, if I say it's f8b4, on an MSP430, there's no ambiguity as to where that is. It's different on the Harvard architecture chip, such as the AVR. On an AVR, if I give you a pointer, I'm either referring to code memory or to data memory, and you don't know which. If you're writing custom assembly code, you can ask to fetch data from code memory. There's no way to ask to execute code from data memory, though. So if I send you a packet, I can't just give you a pointer to that packet overriding a return pointer, because there is no RAM that is executable in these chips. So exploiting them becomes a lot more difficult. We will be discussing methods with which they can be exploited, though. These were pioneered by Aurelian Francian out at Inria-Ronault in Grenoble, France. Now, there are also differences in the way the fuses work. The AVR uses soft fuses. You have EEPROM bits that can be cleared and set. They're set during a reset when you erase everything in the chip. And then they're cleared individually, so you can remove writes, but you can never add them back until you erase everything. And the MSP430 uses a different method, or at least it did when these slides were written, in that it has a hardware fuse. And if you're trying to lock someone out by JTAG from an MSP430, you blow this hardware fuse and then the state machine itself that is used for debugging the JTAG state machine, it refuses to move beyond the initial state. There are ways around this, though, and we'll be getting into those soon. The soft fuses in the AVR can be broken in a different manner. If you change the voltage of the chip, sometimes it will misread from memory. And if you do this quickly, the chip doesn't recognize that it's running at the wrong voltage. You're also given a considerably wide window of voltages that you're allowed to run it at. Many of these chips will go from 1.8 to 3.3 volts, or as high as 5 volts. And you can drastically shift between one or the other without causing any of the battery indicator warnings to fire. Now, if I gave you a microcontroller and a radio, and I gave you all the documentation for them, and I locked you in a room and I said, come out with the design in which they're connected, you would connect them in a very specific way. This corner down here at the bottom right, you'll notice that it has pin labels. I see a different slide on my screen. And the names of my old pins for hardware-accelerated serial ports. So if you have a serial port, it is connected to this corner. And you have different types of serial ports. So in the case of the Chipcon 2420, you'll be connected to the SPI port. This chip has a single hardware-accelerated SPI port. So when you come out of that room, that's where you'll connect it. And if I see a wireless sensor for the first time that uses these two chips, I know that they will make the same design decision. Because if they don't, the chip runs a lot slower. And this performance penalty isn't worth the additional cost. So all implementations follow this, almost without exception. Zooming in further, actually these slides are wrong. I apologize for that. These would be used to speak to a computer. These pins up at the top, the SOMI-1, SOMI-0, those are where the radio would be connected. There's an oversight on my part. And you can watch these lines. Because they're intended for one device to communicate with another, you can stick needles into the board. And you can watch the traffic flow in the same way that you might wiretap a telephone line or you might packet sniff an ethernet network. And by this point you're probably asking yourself why it matters that it's possible to break these things physically. Because on a PC you never believe that if your computer is in the hands of an attacker physically that there's that much that you can do. Even encrypting the hard disk isn't sufficient. Here it's different though because these devices are intended to be disposable. So if you throw 100 of them into a field where they're physically within reach of an attacker, you can grab one, pop it open, stick some needles in, hit the reset button, then as this device associates with the network, the attacker can watch the microcontroller talking to the radio. He can catch the keys going from the microcontroller to the radio. And these are such low data rate that you can very cheaply buy equipment for packet sniffing rather. And in the case of ITC it even supports multi-master networks. So unless one of the master devices is actually holding the lines to intentionally prevent anything else from communicating, other parties can participate on the same line. In this case I have an ITC eProm here and I have a USB to serial chip which is reading it here to the left. These two syringes carry an ITC signal. One of them does data, one of them does clock. Not only can I watch the USB to serial chip boot from the eProm, but I can also dump out the contents of the eProm by speaking to it while the USB to serial chip is busy with other things. And there's even collision avoidance, so I don't have to worry too much if it's booting at the exact same time that I dump the firmware. You can use the Hackaday bus pirate to do this for ITC chips. You build a little kit, you wire it up and you can dump everything out. I've also got the Goodfet project which also implements ITC and you can buy commercial devices for the same. Now the access firmware which is held within the microcontroller, there are often multiple methods. In addition to connecting to it with JTAG where it's protected by a fuse, you can also connect with a bootloader. So it will run software internally to accept an update. You can start the software and then as the software is running, you perhaps need to present a password to it in order to extract the contents of memory. And there's often a loophole here which is that you can erase everything. The idea being that there's nothing left for you to steal and then you're allowed access. So you can upgrade a device even though you're not allowed to read anything out of it. The attack that I presented yesterday at the Black Hat Briefings hinged upon being able to erase everything that was in flash memory but nothing that was in RAM. And on a Harvard chip, the keys would be copied over into RAM because the Harvard chip has to move everything into RAM for C pointers to be consistent. When you have a pointer in your C code on a Harvard chip, it always refers to data memory unless you're calling it as a function. So you boot the chip up, you wait for the firmware to initialize, loading keys into RAM, then you erase everything in the chip, perhaps destroying the functionality of the device in the process, but you can then copy keys out of RAM. And this works on the MSP430, it works on the chipcon radios. The more recent ones which combine both a microcontroller and a radio into a single package where there is no ITC line or SPI line between the microcontroller and the radio for you to tap. And to do this, all you need is a debugger. You can use the official debugger. You just send the command to erase, then you send the command to dump RAM and all of the keys come out. JTAG itself uses Fuse, either one that's broken or one that exists in EEPROM. And it used to be that EEPROM chips would have a quartz crystal window on top. So if you want to program the ROM chip, you put it into your burner and the EEPROM cells are cleared. So they begin as all ones and then you pick individual bits and you say these bits will be cleared to zero. If you write it twice, you wind up with the bitwise AND of the two images. There's no way to individually turn a bit from a zero to a one. But you can put it under an ultraviolet light. So you would put these chips under a light in a little box, wait 20 minutes, and then they would be erased because the ultraviolet light would pump up the charge of each cell. And then later you can clear that charge out. Well, when the fuse is implemented in EEPROM, you can sometimes hit the fuse with ultraviolet light to not get over. Or you can take a photograph of the chip at the right moment and it will misread as a one when it's actually a zero. And on some chips this will damage them. Some chips will have two fuses next to each other. One needs to be cleared while the other needs to be set. Or something like that to keep you from hitting it with ultraviolet light. But others have no such protection. If you hit an MSP430 with a camera flash, it continues to execute. Sometimes things will mess up accidentally, but it doesn't set off any tamper-proofing mechanism. You can even use it to skip over the fuse deck sometimes in that it will jump to the wrong JTAG state. You'll find this with a debugger in that you'll accidentally start reading out ones. Wait long enough, transfer through enough states and the debugger finds itself in the proper state and you've cleared out of that. I took this at DEF CON last year. Chris Tarnofsky had a demo set up where he stuck a needle into a chip to actually spy on the data bus. And he can do the same thing to skip over a fuse. This equipment is expensive, but not prohibitively so. Here on the left you can see the needle going into the line. And hardly any chip is properly defended against this. His company Flylogic, when they get chips in to play with, they almost never fail to find some unprotected line of the bus to tap and then they can watch what's going on inside. But with the boards themselves, you have the same access between chips and you have it without this expensive equipment. You have it without hand study enough to move a microscopic needle. You have it without a chemistry lab to remove the lids from the chips and remove the top of the glass from the die. You can also do bootloader attacks. At Black Hat Briefings last year in Las Vegas, I presented a timing attack against certain versions of the MSP430. I picked up this watch in the vendor area that contains an MSP430. And if you dump the bootloader from it, it's a program. And it's a program that an attacker is always free to start. Even in the more recent models, which allow you to disable it, the attacker can still start the program. It just gets stuck near the beginning. And on this particular device, I can extract the firmware in that the timing of the password is unbalanced. So if I present a password to it, it takes it longer to compare two bytes which are not equal to each other than it takes to compare two bytes which are equal to each other. And this difference is caused by it clearing a bit out of a register to deny access. So first, it gives you access to the chip, but you have to send it a password. And with each byte, it will disable your access again if the two do not equal. In later versions, they fixed the timing. And then they broke it again and now it's fixed again. But the point is that this program can't really be taken out. Because it's in flash memory, you can always start it. And you'll find similar things in many of these chips, either built into masked ROM by the chip vendor or intended as an update or debugging mechanism by the product vendor. And you can use voltage glitching. You can drop and then raise VCC very quickly. You can skip over an instruction. You can make the wrong immediate value be read. So if the programmer intended to, say, compare something to something else, if you glitch at the right minute or the right second, it might compare that to all zeros or all ones by mistake. In the new MSP430s, the ones with soft fuses, the JTAG fuse has been replaced. Instead of actually having a physical device that's blown, there's actually a word of flash memory that's read. If that flash memory is all ones or all zeros, you're allowed access. If it's anything else, access is denied. Well, if the voltage is rising or falling, the most common things that you'll accidentally read are zeros and ones. I've yet to get a working exploit of this, but believe me when I say that it's coming. Donkashun, neighbor. Oh, chairs for Daniel. This was a device that I built for implementing the timing attack. The idea is that the board is programmed to the left, and on the right, you actually have a serial port going to the victim device. Then you can have buttons or you can just control it through JTAG entirely. This is a glitch on a scope. You can see the voltage falling and coming back up, and the entire width here is 250 nanoseconds. So four times this width would be a single millisecond. On the board itself, if you look at the parts, there's a microcontroller here that implements the attack, and to its right, there are glitching registers, 74HC, 4053, analog bi-directional moxes. For those of you who aren't double E nerds, I'm terribly sorry, yes. Got a question? Oh, don't mind. So for those of you who don't deal with hardware directly, these are just switches that run from one voltage to another. So in the same way that a digital MUX would switch between a one or a zero based upon a control line, these jump to either full voltage or whatever the microcontroller has decided to put out. You can also do voltage analysis and power analysis to make this glitching more reliable. This waveform here is what happens when you don't properly decouple a microcontroller from its power supply. So on each clock edge, the chip begins to use power, and the available voltage drops. And you can see this drop here. So every sharp drop, such as this one, occurs when the chip begins to perform calculations on a clock edge. And a single instruction might be four or more clock edges. And you don't know which is rising and which is falling. So the chances of you're getting a break on any given glitching attempt are rather small, but if you consider that you have infinitely many attempts, you can leave this running overnight. You come back in the morning and it's connected, it's logged in, and you have access to firmware. And the timing attacks depend upon mistakes in compiled C code. How long does a comparison take? In clock cycles. For any C program you've written, do you actually know how long any given region runs? If you have an if-else statement, not only do you have to worry about the timing of the bodies themselves, but you also have to worry about the timing of the conditional clause. In this case, if the comparison takes a different amount of time, then you'll have trouble. If the body takes a different amount of time, then you also have trouble. I ran a timing simulation against this. So I tried a password of all repeated bytes, all zeros, all elevens, all three a's, and then everything else. And I counted the number of clock cycles that it took. And most of them took 6,543 clock cycles. This is how long it takes if every single byte of the attempt is wrong. These others, though, took less time. And if you take the difference in time and you divide it by two, you get the number of times that that byte occurs in the password. So you can see here that zero occurs once, and that's right there on the top right. Eleven occurs 16 times. It's the more significant byte of every word. And three a occurs 15 times, because it's in every word except for this one. And the reason why the password looks so predictable is that it's actually the list of interrupt handler addresses. So instead of a human being choosing the password and getting something that's easy to guess, the compiler chose a password, and it just so happens to be something easy to guess. There's a paper by Becker and a few other German students where they actually looked through and they figured out how long it would take to brute force these things. And they concluded that the average password had 40 bits of entropy, and that it would take 128 years to brute force it. Their numbers were inaccurate in that they assumed that the device couldn't be overclocked. And they also assumed that every program was complicated. In this case, the password is so simple because this isn't an application that's doing lots of things. All it's doing is starting up, and then it has a main function with different bodies in it. It has no interrupts. It has no timers. It never goes to sleep. It has no buttons. And if you write a program in this way, you're doing it because you're used to writing programs for a PC. If you're trying to hire a C programmer, it's a lot easier to find one with experience on a PC than one with experience on microcontrollers. I expect that many such programs will have issues like this. They will use polling instead of interrupts, and therefore their password won't be as random as it might be. Further, 1100 is chosen because that's the bottom of flash memory on this chip. Everything else is the same word because they go to the default handler, which in GCC is at least something. You at least have to guess the 3A. On competing compilers to save a bit of space, they do nothing. They don't handle these at all. So these would all be FFFF. Now there are complications. There's a start bit that you have to consider. The way that serial traffic works, I can jump ahead. I don't have a diagram of this. The way that serial traffic works is that the line stays high so long as it's idle, or for us 232 invert everything I'm saying about high and low. The line stays high so long as it's idle, and then you drop it low to begin a word. A word being a byte in this case. After you drop it low, you send a single bit that's a zero just to indicate the beginning of that byte. And you follow it by the bits of the byte in at least significant bit first. And the reason they did least significant bit first is that it allows you to send 7 bits instead of 8 if you're trying to do ASCII. And then your terminal can just clear out the high bit all the time. This was useful for maybe a couple of years in the 50s or 60s, but it still hangs around because of that. Now, when you're disassembling firmware, it's a very different environment from doing so on a PC. When you disassemble firmware on a microcontroller, you have a small address space. You only have 64 kilobytes of memory. And in the very largest chips, you'll have a few times that, 128 or maybe a quarter megabyte. You have a single process. Everything is one application linked together. You don't have competing applications. You don't have an operating system. You don't have system calls. At best, you have a scheduler that calls functions. The most complicated you'll ever see is a scheduler that calls function pointers. And you have no I2PRO support. There are very few high-end tools to do this reverse engineering. Tools which you might be familiar with from the PC world. So you have to build your own tools when you're the first one to begin reverse engineering software for one of these chips. So I wrote MSP430 Static in late 2007 and early 2008. And it began as a way to generate slides from my talk about an MSP430 exploit that I'd made. I needed diagrams that showed how the functions flowed into one another. And I could either sit there for a couple of minutes doing it in open office. We all saw 20 minutes ago how reliable open office is. So instead, I wrote a tool in Perl and SQLite where Perl functions are exposed to SQLite, and then you can request, say, call graphs in SQL. On a PC application, this would be a wretched idea. It wouldn't be fast enough. It wouldn't be high-performance enough. You'd have to use all sorts of very complicated database optimizations. But on a microcontroller, you don't. You just throw it in there, and it works. Not only does it work, but it works quickly. The only time at which this tool is slow is when it's initially loading the application and building the tables. So you can select the hexadecimal address and function name of a function. You can order it by descending address, and you can ask for only five. This gives you the five functions at the top of memory. You can draw a memory map, and this is just a bitmap spat out by requesting every word of memory and then seeing whether it was properly disassembled. Everything red here is properly disassembled, and everything blue is the target of an immediate pointer. Data is drawn in red and gray because some data looks like a valid instruction, and this being a von Neumann chip, the machine itself can't tell the difference between weird data and instructions because you can always jump to data and execute it as code. The interrupt vector table is in green at the top right here. I doubt that you can see it. And then everything that's all ones I draw in black and everything that's all zeros I draw in white. You see neither here because this came from a compiler rather than being ripped out of an image. If it were ripped out of a chip, if I'd actually connected to a board and copied this particular example out, you would see the data regions up here if they were used for temporary variables as being spotted in gray. If you ripped the firmware out of an MSP430 JTAG adapter, that's what you'll find. And you'll also find a second application at the top which forwards the interrupts to the lower image. This is what a bootloader looks like and it's also what a worm looks like. If you were to take apart the smart grid worm that Mike Davis released yesterday, you would find something similar to that. And here's what that looks like. You've got data tables here. You've got the compiled code as the clean red block in the middle. And beneath that, you've got some sort of randomized values for the unused parts of RAM. The used parts of RAM are cleared to be zero. And that's where you get the white. And that's also where these blue pointers come from. Each object in memory, if you have, say, a string, you'll see a little blue dot at the beginning of that string and then you won't see another blue dot until the end of the string. You have the least significant byte of the address as your x-axis. And the most significant byte is your y-axis. And you can sort of see how things are arranged here. You can see that flash memory is always at the top and it always runs to the very top while RAM comes beneath it. And then these little lines at the very bottom aren't RAM or ROM. They aren't flash. These are IO addresses. If you want to write a byte out of a serial port, you simply write it to the address of the hardware-accelerated serial port. And then it takes care of actually blasting it out. And then it'll optionally fire and interrupt to tell you that the transmission is complete. So even though you don't have an operating system to call, you have hardware to call. And that can be searched for. So if I'm trying to identify functions within an application, I can search for these things. And it's very easy to automate. I know that all functions begin as the target of a call or a branch. And I know that all simple C functions, those that are called by a proper name instead of by a pointer, I know that those use immediate addressing. You have a 16-bit word that says call the next word as a function pointer. And then you have that next word. If you search for the first one, you'll get every function pointer in the image. Perhaps one false positive, but quite likely not. And you can find the exit points because they're a return or a return i, a return from interrupt. And they're always after the last relative jump. So if you have an if statement, it might say if this is not equal, jump over the body. Even if there's a return in that body, you know that it's jumping to the end. And this is true without exception as a side effect of the way that the compilers work. Now, in a call graph, every function is a vertex, and every function call is an edge. So in this case, main might call printf which calls putc and scanf which calls getc. You can draw call graphs of microcontroller code, and you can do it very easily. In my case, I just use an SQL query to dump out our graph is.diagram. Then I get a PDF which I could print onto a wall or I could zoom into it with an image viewer. And you can see that there are different regions to the code. And as far as figuring out what these functions do, you can look for those same IO ports that I mentioned a moment ago. If you want to find the function that receives a byte, all you have to do is look for the function that actually reads from the incoming serial port register. You can even tell which function reads from which port. If you have two serial ports, you have an incoming byte address for both of them. And you can just read from there. So, example, in the MSP430-200 series, the UART-0 transmit buffer is at 0x0077. And an example fragment of code that might write to it is move the byte from register 11 to memory at 0x0077. That's all that that word will ever do. There's no other reason to have that word of code within a function. And you can find this with MSP430 static or with any tool that you might throw together yourself for any microcontroller that you wish to take apart software for. By just saying, select the name from functions where the assembly is like 0x0077. And this always works. You can also do name hashing. This was a little project of mine for a while. I started collecting lots of firmware images and reverse engineering them. And then I would know the names of individual functions, but it would be very difficult for me to share that. Because if I just post a list, that's horribly boring writing. But you might grab a function with similar contents. Now, while I can't share the code with you, I can share the one-way hash of the code with you. Because that's not copyrighted. So MSP430 static actually ships with a table. It's just function names and MD5 checksums. And there's a command that restores all of the function names that are missing from that table. So if you have an image, and that image shares files to an image that I have, you can recover the names of the functions that exist in both of our collections. You can also look for call frequency. There are atomic start and atomic end functions in TinyOS, which are used for Mutex. So if you have two processes that you don't want to collide with one another, you call these functions. So everything calls these functions as necessitated by preprocessing of the code. They're called hundreds of times. The majority of function calls that any given MSP430 image go there, if it's made with TinyOS. And you can look at the interrupt vector table to tell what happens when, say, a byte comes in, or the chip wakes up. It's very easy to trace these things. And you have... Here, you can see that the interrupt vector table goes to these handlers. And then all of the unused ones go to this default handler, which moves on. And you find these things in multiple images. But there are also headaches that you don't have to deal with on a PC. How many times have you had an IO function be inlined? On a PC, you're not allowed to do it outside of the kernel. You have to defer to the kernel to do your IO for you. But that's not true. If foo is only called by one parent, it will be inlined. And if it's called by many parents, then it won't be. And in the larger development environments, this is done automatically. You can simulate with scripts written in Python or Java to actually pretend to be the microcontroller. And they can run through and they can stab. You can do stack overflow exploits in the same way that you do on a PC for the von Neumann chips. Of course, you have to actually trick the existing code into copying your code into flash memory. And where no function exists to do that, you have to use return-oriented programming to combine the tails of different functions together. You also have to worry about word alignment issues and that sort of thing. But once you have these simulators running and once you have these tools written, you can use them to very clearly describe how things happen. So I assume that many of you are familiar with a standard vanilla stack pointer overflow exploit. This is how it works on a microcontroller. If the program counter is at 11 DC in the main function, we know we'll call load, which does not have an overflow, and then load over, which does. And each of those is just going to copy a string. We can step through. We can see the stack grow downward as main calls load. Then we can see the stack being expanded to support all of the stack variables. And stack variables are very commonly used on these architectures because the RAM space is only used while the function is executing. You don't have to worry about running out of RAM, which is a very real concern when you only have three or four kilobytes. So if CafeBabe is being copied to the stack, you can see the individual bytes of it appear here. So the BA will appear next, and there it goes. And it keeps copying until it hits a zero, that being the zero. Now that the copy is complete, string copy will return, and then load returns. So then inside of main, main calls load over, and this one will have the actual return pointer be overflowed. You see it growing here, and then load over starts writing just all Fs, or anything that's not zero-zero in the case of an all-terminated string. And this is common on a PC. On IT software that's being attacked daily, you're looking for these things, and you're doing your best to stop them. Because you know that as soon as your software is deployed on a web server or in any other public place that you'll be attacked. Here they assume that they'll never be attacked. So at this point, if I step backward a bit, you can see that it just keeps growing until the attacker gets to the main return pointer, and then he can list any address he likes. And when the function returns, it will jump to this word instead of the spot in main that it left off to call. And there we go. It's now pointing into RAM. If the packet's here, it executes. Then everything wraps up, and now the program counter points to RAM. Okay, on a PC, this is a trivial example. You can see with IT software, if your vendor supplies this to you, and I know that many of them do, but they're still looking because they're getting attacked. Microsoft would be incompetent to ship this on IIS today. Now, a decade ago, they might have had issues with it, but they got over it. And they got over it because they were attacked regularly. These wireless sensors are not being attacked in the field, which means that these vulnerabilities exist, and they're exploited, so they remain. So anyone who looks for them, if you look at this in your smart meter, or your thermostat, or your wristwatch, you find vulnerabilities like this, and they can be exploited. I need to wrap up in five minutes, but you can do fuzzing, and you can do fuzzing on the actual hardware. You can either use a simulator or a JTAG debugger, and even the JTAG debugger isn't strictly necessary. Ryan and I were playing around with fuzzing a microcontroller, trying to make an automated exploit that would return back into the bootloader. And we wound up succeeding by watching an IO pin to see exactly when the chip reset. Whenever this chip reboots, it makes all of the pins go into an input state. In an input state, the chip doesn't assert a one or a zero. It just sort of lets it float. Now, later, after the chip booted, it went to an output state, and then it would assert a one. So we had a resistor pulling downward to make it a zero by default. And whenever that line dropped zero, we then knew that the chip had reset. Well, that lets you know when you got a crash. And if you know when you got a crash, then you know that the packet you sent just beforehand is doing something interesting. And if you start sending random addresses in that packet, there you can occasionally jump to the wrong place. If you put an address in master on, then you can make it return to a particular spot in a program that you can talk to. Then you know when you've overwritten the address perfectly. And you can fuzz this just as you could on a PC with the debugger attached to the application. You might not be able to follow the execution traces easily, especially if the JTAG fuse is blown. But similar attacks apply. So you can do all of these things. You can do blind injection. In the case of Harvard architecture chips, you can use return-oriented programming to copy things over. So even though you can't execute RAM easily, you still can execute it. And in the case of code that you don't understand, in case you don't have a copy of the imagers trying to attack, you could still use probabilistic return-oriented programming. I love this coming out at a Usenix paper in detail. I believe the wood papers are available online if you Google for it. The workshop on offensive technologies. But the gist here is that you return to a common gadget, and that gadget returns to a common bootloader. So if you wanted to say, make sure that all of the bits in register 11 are high, and that you're executing the bootloader to say elevate your access, which was how we extracted firmware from this device, even after it was locked. The way you do it is you just assume that you're going to have a pop-r11 followed by a return. The odds of that are 1% on any given attempt. You attempt it 300 times, you succeed with three-nines of accuracy. It won't hold up that long to an attack. You can also use an extra-neighborly belt buckle. At one point, a friend and I, Joshua Gornot, in the front line, he lost his virginity because of the belt buckle, and we appreciate it. But let's give him a hand. And then, thanks to the technical confusion at the beginning, I've run out of time. But if you'd like to join me in the breakout room, we can play with some of these toys, and I can show you how to exploit chips. We've got a scope and some needles here, and we can do all sorts of fun stuff. Room 105. Thank you.