 So, a couple of years ago I did run a Mac, and I was working with the MSP430 microcontroller. This was before virtualization and got into the point that it's at today where you can actually share a USB device with your virtual operating system. And it was just before Bootcamp came out. So, I had this Macintosh, it was running OSX, it was Intel compatible, and there was not a damn thing I could do to debug an MSP430 on it. Because the MSP430 requires a driver for its USB to serial chip, sorry, the MSP430 JTAG programmer. Requires a driver for a USB to serial chip that's inside of it. Linux had this driver, OSX did not. Even if OSX did, there's no Macintosh application for debugging the MSP430 chips. And the Linux one required a closed source library. So, even though you could debug a chip under GCC and Linux, there was nothing that you could do to debug that same chip from a Macintosh workstation. And then new chips were released which weren't supported on Linux. They began to let the GCC, so the GDB, the new debugger library, this closed source library that would allow for GDB to debug an MSP430. They began to allow it to Atrophy, and they stopped patching it. So today, I have several MSP430 devices that have been given to me by friends or that I've purchased which I cannot debug or develop for using the official tools because the official tools are out of date and I run Linux. If I ran Mac or openBSD, I would have further issues. So today, I suffer through X11 hell every time I get on stage just so that I can retain compatibility with that one piece of hardware without running Windows. So to remedy this, I've begun building my own JTAG adapter that's open source and that supports as many chips as I can get my hands on. In some cases, this can be done with the official documentation. The basics of how JTAG is supposed to work are very well documented. It's very simple in the hardware sense. So while it's a low-level protocol, the method with which you send an instruction or send data is very standardized. So these are the badges from NeighborCon, which some of you might have attended over the past few days. It was a two-day conference that took place during Black Hat, but it was a lot more neighborly and was free to attend. At NeighborCon, we gave away 180 of these. Just a quick disclaimer. Dealing with these things at such a low level will make you dyslexic. I wasn't when I began working on this, but then I had to deal with differences between Big Indian and Little Indian for the way in which a byte fit into a word. And beyond that, I had to deal with the ordering of the bits within a byte. Because in some cases, the most significant bit comes first, and in some cases, the less significant bit comes first. Even in JTAG on the MSP430, data comes LSB first, and instructions come MSB first. Or vice versa. I can't really remember right now. And then some things occur on the rising edge of a clock. Some things happen on the falling edge of a clock. In SPI, you write your output on the rising edge and you sample your input on the falling edge. But then some SPI chips do it the other way around, and it's just held a deal with. And then some things are inverted and some things are un-inverted. So for example, the reset pin is actually reset with a bar over it or an exclamation point before it. And that means that it's inverted. So the chip is held in its reset state. When the reset pin is low, and it's in its normal non-reset state when the reset pin is high. This is done for reasons of physics and hardware convenience. So I'm going to screw some of this minutia up. If you're trying to build JTAG based upon my spoken documentation at this conference, you're going to get a couple of things backward. So please double check the minutia in writing. JTAG itself is a testing standard. The idea is that if you're manufacturing circuit boards or when this first came out, computers, you have many different chips on these boards. And you have to know that the chips are wired to one another properly, that you have good solder joints and all of that stuff. So decades ago, they began to use shift registers in the edges of the boards so that you could debug an individual board in isolation without removing it from the containing computer. This was back when a single computer chip would be made of stacked boards rather than a single chip of custom silicon. And when they began to build chips in silicon, they needed this even more because if you manufacture a chip that's too small for a technician to stick needles into without extreme efforts. And it's running too quickly for things to be caught on the scope and all of these other issues. What happens when you do a production run and it doesn't work? You'll find yourself with 10,000 units that are utterly worthless. No idea of how to repair them or rebrand them or anything like that. And more importantly, you don't know where you screwed up. So the next time you try it, it's likely that you'll have the same problem. So while in software, recompiling takes a couple of minutes or a couple of hours for an extraordinarily large operating system, in the case of hardware, you're looking at a turnaround time of months between deciding that you made a mistake and actually getting to try the next iteration of your design. So you need some sort of debugging, both to verify that what you intended to put into the design was fabricated correctly in hardware and to determine that the software that you're running works properly. Because when computers began to come up in this form, it was necessary to single-step and to debug the software that they were running, even though the chips themselves had too little memory to store a debug monitor or an operating system like Linux. So the JTAG machine exists within almost every chip for the sole purpose of debugging it and ensuring that it was manufactured correctly for programming it for all of these different things. And because it has to exist in hardware for the hardware to be manufactured, it's a very interesting thing to play with as a hacker, because you can take the chip apart. You can run instructions on it. You can do bug software on it. You can do all of these crazy things that are useful for development but also for breaking into things. Because you can single-step a program on physical hardware waiting to see what happens. If you're trying to fuzz a wireless sensor, you can run it at one-one-thousandth of real-time and the device will still work. The radio doesn't care how slowly the microcontroller speaks to it. The application itself will chug along. So you can fuzz these devices and actually watch the stack grow just as you would in a simulator but on actual hardware without having to re-implement all of the hardware and simulation. So you can use this to program a device, to read the programming out of it. If you purchase a device, you can dump its firmware and then begin to analyze it and look for problems, or you can clone it. You can manufacture your own unit with similar hardware and then flash the original software into it. And the access control mechanisms of this are only intended to prevent that. They don't really care that you might be able to debug. They don't really care that you might be able to view RAM. All they worry about is that you might be able to copy the contents of flash memory into another chip and then execute that or sell it, making a counterfeit product. So this is my DEF CON badge. And to hack this, I decided I'd actually hack the free-scale JTAG standard because you can't program the free-scale chips very easily from Linux. It's the same situation that the MSP430 had when I began to work on it. So if you see these little testing pads on the back of your badge near the chip and you can look at your own badge for this. You don't have to rely on the screen. Those are wired up. This is a diagram that someone lent me in the hardware hacking village. I'm not sure where he got it, but probably from your CD. And if you wire all of the pins up correctly, you can then speak to your badge externally. And unlike the bootloader, which connects to the serial pins, I think it's those two there. Unlike the bootloader, this never goes away. So even though you might be able to damage the bootloader of your chip, through software there's nothing that you can do to hose JTAG. And if you put a fresh chip onto your board, after the lecture we'll be blowing mine up in the name of science. So I'll need to swap it out with another chip. And when I put that fresh chip onto my board, it won't have a bootloader, and it won't have the software that it currently has. It won't be blinking, it won't be running anything. So the only way to flash new software onto it is by JTAG. And this being undocumented, there's a little challenge in figuring out exactly how JTAG works for it. FreeScale intends to publish it at some point, but for now it's a black box that can only be had by an NDA that I can't sign because I intend to release my implementation as open source. So then once this connector is on, you can run it to a JTAG debugger, or an adapter. This adapter will be connected to by your development environment, whether it's a commercial IDE or whether you're using open source tools. The standard itself only tells you how to populate two registers and then send a trigger for execution. So when I say that it's a standard, I don't mean that chips can be read and written in a standard way. So the standard verbs only allow you to pass traffic from one chip to the next, or to identify a given chip. And there are a few others that are semi-standard that might be supported. In the case of the MSP430, no other verbs are supported that are in the standard set. So if you want to read or write memory, JTAG fuse, especially if you want to write flash memory, you have to understand how the chip works, how it expects to be told, what programming method to use. So to quickly review, and I swear that this will be brief, there's the serial peripheral interface. The way that this works is that you send one line to tell the chip that you're ready to speak to it, and then it begins counting bits. You send it eight bits, and at the very end of it, it might do something or it might just wait for more traffic. And every time you send a bit, for every bit that you send, rather, you receive a bit. So it's always an exchange of information. If you want to write one byte to an SD card, for example, you are also receiving a byte. And it might be garbage, but it is received nonetheless. And that allows for a nice trick that I'll explain near the end. JTAG works similarly, except that you've got two registers instead of one, and you actually mark when you're finished writing that register. So you can send both an instruction and a data. The data value will be of a fixed width, but the width is unique to each chip, as is the instruction. So while an instruction might be eight bits wide on an MSP430, on other chips it could be 16 bits. And the data register varies more. Some FPGAs have odd widths, 237 bits of width to the data register. And you have to determine these widths before you can begin to reverse engineer the JTAG protocol of a given chip, of a given family. So the GoodFet is an open debugger. It supports the BSD license on both its hardware and its software. If you need something more liberal, just ask me for it and feel free. If you want to make your own production run, do it. You have every right to. I only ask that you send a couple of neighborly gift units to myself, and I don't even legally require that. As far as the architecture goes, you've got C running inside of an MSP430. This is compiled by GCC. To compile the firmware, link it, install it, and restart the machine to be executing it, you just type make install. It's quite neighborly in that regard if you're used to the UNIX environment, because you don't need to deal with the embedded development tools or IDEs that are specific to each chip. So you don't have to know anything about the MSP430, which I use on this board, in order to begin adding support for new protocols. And then I use Python for the workstation code. And the Python is written in a style that it's very easy to copy or port. I don't use proper class inheritance or things like that, because it hides the code that you're looking for when you're trying to copy something. And then you use it like this. You say goodfet. And then the name of the chip to choose your Python script, followed by a verb, followed by maybe a file name and a range. So here I'm asking it to dump from data memory of a chipcon radio to a file called foo from dead to deff. And having done that, I wind up with this Intel hex file called foo. And when I call the head function on it, you see that it's all ones. This is because I chose a region of RAM that doesn't actually exist on the target chip. But I could dump software in the same way. And I can do it from multiple chips with the same adapter. So while that was taken with a chipcon radio that supports a non-JTAG debugging standard, the same thing works with, say, the MSP430 with a rather awkward JTAG debugging implementation. Now, the pins on SPI are rather simple. You just have master and slave out, which is how the board receives input from the chip. Master out, slave in, which is how the chip receives input from the board. A clock line and a slave select line. You write data on the rising edge. You read it on the falling edge. And it's full duplex by necessity. So every time you send something, you have to receive something as well. To send a single bit, let's say we wanted to... So if we want to send a bit, we also receive a bit. And if we just want to send a single bit in a session, let's say this SPI device was a single bit wide, we would drop the clock, then output our bit at this edge, then raise the clock to sample it. So both the master and the slave write some bit here, and then they read it here. And that's how they exchange their information. So neither knows what the other is writing until the transaction is completed. If you compare this to a regular serial line, it's a lot simpler, even though it requires more wires. On a regular serial line, you have timing. So you have to know exactly how wide each bit will be. You can't pause it in the middle. You can't use nonstandard timing. You can't do any of the things that make SPI easier. Instead, what you do is you keep the line high until you're ready to transmit. Then you send a zero, followed by your actual traffic. So in this case, we'd have the zero here as the start bit. And then just to its right, this first upper bar, that would be our one bit of data, followed by a stop bit, which is always a one and then nothing. But you couldn't really tell where this ended on a scope visually. I mean, you don't know which of these would be ones. You don't know how wide this is. This might be five bits for all, you know, or it might be eight. And it requires each device to have a standard clock. So if you remember dialing into bulletin board systems, if you typed in 2400, 8N1, that would be eight bits wide, no parity bit, one stop bit. It's 2400 bot, and you had to know exactly how fast you were communicating. JTAG doesn't care about speed. You can run it faster or slower, and the slave will automatically match to the master. And you have two registers to populate. You have an instruction register and a data register. You don't know the instruction set, and you don't know the register widths until you actually look up the documentation for a chip, which might be secret. And it's implemented in hardware, so there's no actual program receiving the JTAG sequences on the target device. Instead, it is interpreted by a state machine, where you push your way around the state machine by the TMS line. Let me grab some water. Someone would grab me a beer. Blue Moon or Sierra Nevada. So this differs from SPI in that you have two shift registers instead of one, and that you actually say at some point, I am done transmitting. I'm done transmitting this register. You never say that in SPI. By the time you raise the slave select line, you're saying this transaction's over, and you can't continue anymore. I don't care about any reply. I'm never going to hear from you again. So this allows JTAG to have more complicated commands and things like that. The pins themselves are just output input. There's a clock line and also a machine select line, which is how you move around the thing. And then there are two wire variants of this, such as SPI by wire. SPI by wire works by having just a clock line and an everything line. The everything line multiplexes between the four signal lines on the clock. So you'll send one, then the other, then the other, then the other. The state machine itself is called a TAP. It has the two registers that we discussed. There's also a run and idle state, which is what happens when the chip is held as single stepping instructions if it's paused. In this state, the chip isn't doing very much, but it has time to work. So sometimes when you're writing flash memory, you might go through the run idle state at a particular frequency. In a bit, I'll get to how you can damage the chip by setting the wrong frequency, and perhaps some of you can figure out how to work that into an exploit. There's also a fuse, which denies your access. So if the fuse is blown in hardware, this means that you're physically locked out of the device. You're unable to read or write it. You're not allowed to send any commands except for the one that forwards data onto the next device in the chain. And if you can get past this fuse, then you've broken the copy production of the chip. You're able to access information that it expects to hold privately. Further, if the fuse is in software, then instead of physically blowing something up, instead you're waiting until boot time, and then you're reading a value out of flash memory, and that is setting a control register, which denies your access. When this happens, you can sometimes break the chip by slowly ramping its voltage up, or by violently jerking it when you started, or by starting it without a clock. Not gonna shoot a neighbor. It's such that it never gets a chance to read the fuse setting until after you've already done something malicious. The state machine itself looks like this. You've got your run check state, which is a fuse check state, where it actually looks to see whether or not you're allowed to enter. This is followed by the run test idle state, and you see ones and zeros in this diagram. That's the value of TMS. And you advance from one state to the next on any given TCK cycle. So here where you've got a zero, and then it's a bit obscured by the X11 garbage, but if you see the zero with the arrows circling around it, that's jumping out of run test back into itself. So if you want to stay in any given state, you have to be in a state that allows you that luxury, and then you have to know whether it's a one or a zero that loops back. So from here, if on the first edge TMS is high, you'll move into the select data register state. Then you can set it either high to move into the select instruction register state, or low to fall down into the capture data register state. And this is arranged so that you can actually navigate back to the run test idle state from anywhere, not knowing where you are. So if you were to fall into a random state, you can move back to the beginning. This isn't terribly relevant on a modern JTAG device because very few clock edges are missed. But if you're trying to break into a device, you can hit it with a flash bulb. And on those without protection, sometimes you fall into a random state. You might find yourself here in the exit data register state, moving into update data register where it would maybe read a byte of memory by mistake or something. But if you can move back to the beginning, then you can start sending clean commands. Then you can start breaking into the chip. The fuse check itself is performed in an interesting way. You've got these lines here on TMI, and you have to have two pulses and it has to end high. Why does it have to be two pulses? And we'll get back to that in a minute, but what happens if you send zero and what happens if you send a million? Is it more likely to fail with one or with 100 and which way is it likely to fail? The instructions themselves are here. You can read and write registers. You can capture data values. You can push things into different registers, and everything else is done as a combination of these macros. So in the documentation for the MSP430, which is incomplete but still quite helpful, you'll see that it sends the prepare, blow, fuse instruction into the instruction register. Then you apply the programming voltage, which will be several volts more than the chip normally takes as is necessary to blow the fuse. You follow that by the command that actually blows the fuse. Then you wait a millisecond and you remove the programming voltage. And the interesting thing is at the end, you're told to reset. Because if you don't reset, you don't actually leave the JTAG state and you won't even know that the fuse is blown because it's not checked anywhere except at the beginning. So you can glitch it. You can drop voltage very quickly and then raise it very quickly so that the reference voltages change. And then whatever is being sampled as an input to a latch and flip flop is sometimes misread, missampled, and it will latch incorrectly. So if you do this at power-up on a chip that reads a value out of a flash memory, you might wind up with all ones or all zeros held in that register instead. This is a probabilistic attack. It won't work very well on any given attempt, but you can try it a hundred times, a thousand times. This is what it looks like on a scope. So going back to the diagram, and you can see in this line here the actual pulses that are required. You are told to send two. So there are two ways of implementing this. You can either have it default to your failing the fuse check and then transition into passing once it succeeds, such that if any of the pulses say that you are allowed through, you become allowed through. Or you can begin in a pass state and then fall into a failure state, such that if you try it zero times, you automatically fall through. So in the first case, you can just try a million times and you keep on glitching them. If they succeed, then in the end, you've broken your way into the chip. In the second case, you can just not try anything. Just never send edges. And when implementing the JTAG adapter, a second beer, this is extra neighborly. Kindly neighbor. So because this is hardware, and because it's implemented by a hardware engineer who's never had to worry about security that it's commonly dealt with in IT, he's never had to deal with one of his chips being broken into and had to come into work early on a Sunday morning because of it. He really doesn't care as long as he gets paid at the end of the project. And even if he does care, he doesn't think that anyone's looking at how the JTAG implementation of his chip works. The only exception is being smart cards. And even then, they still make mistakes and they still design machines as if all of the rules of digital logic were followed when that's not true if the attacker can change the analog supply voltage and can change it quickly. Because these are analog transistors implementing a digital computer. They still behave as analog transistors. So back to the state machine itself. You can see that each of these two columns is used for populating a register. And you can see that the two columns are pretty much just copies of each other. But one is further out from the idle state. If you wanted to add a third register, you could just by putting it further out here. And then there are primitive sequences that you use for these exchanges. So inside of the firmware of the Goodfet, there's a command JTAGTrans8. It takes in a byte and it returns a byte. And all this is doing is swapping that byte out. And this is called by two functions, drshift16 and irshift8, which populate the 16-bit data register of the MSP430 and the 8-bit instruction register of the MSP430. The instruction register should actually swap the byte around because the bytes are sent in opposite directions. One of them comes most significant bit first. The other comes least significant bit first. And from these, you build higher level functions. There's JTAG430s at PC, Hulp, CPU, Release CPU, all of the different things that you would need in a debugger. And these are documented, but others are not. I haven't yet figured out how to set a hardware breakpoint. I haven't yet figured out how to read registers other than the program counter. I'm working on it and I've got the recordings to do it, but the point is that those things are not in the documentation and getting them can be a bit fun. It's also worth noting that writing flash memory is very different from anything else that you might do over JTAG. On most chips, you have to send debugging waveform, not a debugging waveform, a clocking waveform. And it has to be of a specific frequency within a particular tolerance. I'm sure you're aware that solid state disks were initially decried as unreliable because flash memory could only be written so many times, and that this is managed by write controllers that actually map the physical blocks of the flash memory to virtual blocks that your PC sees to do ware leveling, so that if you write the same file in the same location a million times, it doesn't destroy the disk. If your timing is wrong when writing flash, you can actually destroy the disk early, which gives you a chance to experiment with exactly how it's destroyed. I'll get to that in a bit. This is how the program counter is set. First, you send the control register, and you set that to 34.01. This is just a magic constant, but the individual bits are defined in the documentation. Following that, you shift the instruction register, and you tell it that you want to execute 40.30 to load the instruction register. Sorry, to load the program counter. From there, you send these clock pulses, and then you write in the value that you want in the program counter through drshift16. You've got to clear the line after that, and then you have to shift in the instruction register command to capture the value that is held within the data register to the program counter. This is rather complicated, and it's not how things would behave if you were receiving commands in software. If you were receiving them in software, you would just have, say, a single verb to say that you wanted to set the program counter, and then you'd have the value itself. But there's considerable value in being able to automatically come up with this function for a given chip. And it's not so complicated that it would be impossible to exhaust all possible ways of doing it. Now, for writing the flash pulses, on the MSP430, you need 350 kilohertz, give or take 100, and writing this in pure C is quite difficult. TI tries it in their implementation, and between versions of their JTAG debugger, the flash will actually be written with different timing, because the optimizations that the embedded compiler supports have changed. This must be held for them to maintain and debug. So in my implementation, I went the other route and I did it in pure assembly. And in the red, which is quite difficult to see on the screen, you can see that I actually counted the number of clock cycles that these instructions would take to figure out how long each body of the loop took. And I calculated that at 3.68 megahertz, I had 7 to 14 clock cycles allowed per iteration of the loop in order to get the right timing width. My initial implementation was in C. I thought it's a square wave. What the hell does it matter what speed it is? And in doing so, I damaged the flash. And this frequency can come internally or externally, but in either case, you have to set it somewhere. You have to make the internal clock be divided by the proper value, or you have to provide an external wave from the proper value. And this is a hell of a lot harder to figure out without having observed it, because it might be too high or too low, I mean, how many attempts do you get? If you guessed this wrong seven times you've destroyed your chip, you no longer have anything to play with. So when they're damaged, writing becomes sort of semi-permanent, and it creates erratic rights on future attempts. So on one of the chips that I damaged, I wrote, say DEAD with slow timing. My clock was 35 kilohertz instead of 350. And then I erased that entire segment, including this word. When you erase flash memory, it goes up to ones, and then when you write it, you're actually clearing out individual bits to get zeros. If I wrote anywhere else within the same segment, suddenly the erasure for this word would fall apart. And the next time I write it back, I would see the original value that I'd written previously. And then if I were to write anything else there, the two words would be bitwise-handed. So if you write DEAD and BEEF into the same address, you get 9 EAD. You wind up with a zero in the result if there's a zero in either of your initial values. But this is after an erasure. This is after the programmer assumes that the region has been cleared. And this would even have passed a verification for the erasure, because just after the erasure, it was once. It would not pass a verification after the second word had been written, after BEEF was written. So it might be possible to use this into a sort of exploit. On the MSP430, the MSP430X2, which is the very most recent chip from Texas Instruments, you can actually kill the last word of flash memory. Not quite the last, but near the last, which controls JTAG access. So I can take an MSP430 and I can damage a word of its memory, and then there's nothing that you can do to that same chip to lock me out of JTAG. Now working this into a meaningful exploit is rather difficult, because I would have to do this to a chip, sell the chip to your factory, then grab the unit that included that chip out of the factory to steal your design or something like that. And there are easier ways of extracting such things. But it's still worth thinking about. And then there are physical questions to answer about each chip. For example, how wide are the registers? On the MSP430, the instruction register is 8 bits wide. And the data register is 16 bits wide. On newer MSP430s, it's actually 20. So it's handy to be able to figure out such things quickly. And you can do this because the registers are cyclical. It's shifting in on one end and out on the other. You're writing the most significant bit as you're reading the least significant bit, again with the dyslexia, but it makes sense if you view it as a ring. Data comes in one side, it shifts all the way around, and then it comes out the end. So if you shift a thousand zeros into that register, and then you shift a single one end and you count the number of shifts it takes for that one to come back out, you can determine the width of that register. And it won't execute the instruction that you send it because unlike SPI, you actually tell it when you're finished. So you don't have to worry about accidentally shifting in a command that will destroy the chip because you're never telling it to execute the command. So in this case, you can just keep spinning around in this region of the data register until you figure out how wide it is. And you can automate figuring out how to read from memory by flashing a chip with a particular value at a particular address using the official tools, then running back and trying every instruction until you can get it back out. And you can automate this for reading. You can't automate it for flashing because of how complicated it is and how many chips you would destroy in the process. But if you're unable to do that, you can still look up in the documentation of the chip how to write flash memory from inside of the chip, how to write a program that will write flash memory. And on the chips that allow you to execute from RAM, which are the minority, but not a small minority, you can just write a program to write to flash memory, throw that program into RAM, and execute it there. On some chips, officially, you're even supposed to write flash memory by debugging individual instructions. It's telling the CPU, run this command, run this command, run this command, run this command while they're all CPU instructions, not JTAG instructions. So because it isn't very elegant and because software can't keep up with sniffing the traffic, you can use either a logic analyzer or a tap emulator. This is a logic analyzer recording of an MSP430 being written by the Spy by Wire protocol. Every one of these clumps of clock edges is actually a sequence of four values being written. Because on each edge, you choose one of the four lines and you write it out to the target. So if you decode this by script, a friend of mine wrote scripts to handle it. It's quite the neighbor to do that for me. You can actually dump it out and see what's being shifted in and where. And it's also possible to build a tap emulator. If you had, let's say, two chips of the same model and you wanted to program them at the same time, you could just connect them in parallel but leave one of the TDO pins disconnected. Then you could send whatever traffic you liked into the chip, the commands to read and write flash memory, and while you will only hear responses from one of those chips, both chips will be written. So in the same way, you could run it out to a state machine that does nothing but capture the transactions and hardware and then flush them out to SRAM. And when you're done programming the chip or when you're done doing a particular small action on the chip, you can read the contents of that SRAM to figure out exactly how the command that you asked the debugger to do was performed. And in doing so, you can reverse engineer the JTAG protocol of a given chip. So prototype boards are available for free. They can presently program the MSP430, the chip con 2430, and a few other chips, as well as SPI flash ROMs and ITC eProms. The Eagle CAD schematics and layout and Gerbers and firmware and even the client are all available for free under the BSD license. You can grab them from goodfet.sourceforge.net. Do we have the question room? Yeah. Okay, so if you'll follow me to room 106, a neighbor and I in the hardware hacking village assembled a stun gun out of a camera. So we're trying to see exactly how much voltage you can run through the JTAG pins without damaging the rest of the chip. We haven't quite figured out what this will do, so it might blow up the chip entirely or it might just break the JTAG pins. But it stands to reason that if you could write, if you could burn out the input and output pins of the JTAG state machine, then when an attacker tries to break into the chip through JTAG, he'll have no way to communicate with it. The Ember EM250 vulnerability that I presented at Block Hat recently could be fixed by this, because you can't connect to the chip externally once the pins are broken. In any case, sparks are going to fly and this thing shocks like living hell. Yeah, so room 106 and we can dump that and then blow up a chip. Thank you for your time and be neighborly.