JTAGulator: Assisted Discovery Of On-Chip Debug Interfaces
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Grand, Joe
On-chip debug (OCD) interfaces can provide chip-level control of a target device and are a primary vector used by hackers to extract program code or data, modify memory contents, or affect device operation on-the-fly. Depending on the complexity of the target device, manually locating available OCD connections can be a difficult and time consuming task, sometimes requiring physical destruction or modification of the device. In this session, Joe will introduce the JTAGulator, an open source hardware tool that assists in identifying OCD connections from test points, vias, or components pads. He will discuss traditional hardware reverse engineering methods and prior art in this field, how OCD interfaces work, and how JTAGulator can simplify the task of discovering such interfaces. Joe Grand is an electrical engineer and hardware hacker. He runs Grand Idea Studio (www.grandideastudio.com) and specializes in the design of consumer and hobbyist embedded systems. He created the electronic badges for DEFCON 14 through 18 and was a co-host of Discovery Channel's Prototype This. Back in the day when he was known as Kingpin, he was a member of the infamous hacker group L0pht Heavy Industries.
 Hello, hello, hello, hello, hello. Hello. Wow, it works. Good. You guys ready to j-tagulate? We're going to have a group j-tagulating session. You guys bring all your j-tagulation stuff, Kleenex and stuff. Good. OK. I did. I'm ready. My name is Joe Grand. I am an electrical engineer and a hardware hacker. And I guess I've been on TV a long time ago. Not Rich and Famous. Just Famous. Yeah, right. OK. So we're going to talk about j-tagulator. J-tagulator is a device I just put together, a fully open source device that will let you hook up to 24 unknown test points on a circuit board. And it will detect if there's any sort of j-tag interface, which is an on-chip debug interface, or also UART interfaces, so things like Root Shell, Serial, Debug, Ports, whatever. So I'm going to go through sort of an introduction about the design, the process, j-tag, how j-tag works, how UART works, and then, of course, give you demos of all of this stuff. So on-chip debug interfaces are basically like the Achilles heel of embedded systems these days. There's so many people getting involved in hardware. And you got guys like Charlie Miller and Chris Valesek, hacking cars. Those are traditionally software guys. You have lots of other people starting to look at embedded systems in a hardware that don't come from that space. So it's really gone to this point. And on-chip debug interfaces are one of those ways that you can totally just own systems pretty much. If you find the interface, you can win a lot of times. So it's a well-known attack vector. The problem is being able to find those interfaces. And the one thing that we can always take advantage of is that vendors and manufacturers and engineers need to use these debug interfaces to actually design their product and to test their product. And during manufacturing, they would do final system tests. So it's an interface that's used. Vendors know that it's a potential problem, but they normally don't do anything about it. So we can take advantage of all of that. So the goal for the project is just to create a tool that will get people interested in hacking devices in hardware hacking, especially for non-hardware folks that don't have the equipment or the time to have to manually go through everything and remove chips and all of that crap. It's just to get it done, get it done right, find the interface, and then start hacking. As with anything, you're sort of building on other work. And this is no exception. I first had seen some work about JTAG finding with Hunze's JTAG finder, which was basically like a proof of concept from 2006 that proved that it was possible to brute force or enumerate through all the different permutations of different test points for JTAG. That was pretty cool. He did it on some sort of Atmel development board. But that's as far as he went with it. The next thing I saw after seeing that, I'm like, OK, so there is some work out there. Saw JTAG Enum by Dead Hacker and also RS-232 Enum. And these were better than the original proof of concept. But they were missing key features. He was using an Arduino for the platform, which limited things to either 3.3 volts or 5 volts. Code left much to be desired. They didn't have input protection. And just a bunch of stuff on there that I saw. And I was like, OK, well, I want to build a tool that I can actually recommend to people and feel good about having them connect up to stuff. Because if you don't have that protection, if you don't have certain things in there, you could fry your target board. And that's not a really good idea. And then Cyber Fast Track, which was a really cool program, I had submitted. So once I did all this research, I wrote this whole proposal for Cyber Fast Track. I was like, this is awesome. All my friends are doing CFT. I want to do CFT and get paid to develop JTAG-ULAR. That would be totally awesome. But it didn't actually work out that way. They said, oh, too much engineering. Sorry, not enough research. And at that point, I had already done all of the work to get to that point. I remember the proposal and the studying of JTAG and everything. And I'm like, forget it. I'm going to do it anyway. And then just get it out there anyway and not get paid while I do it. And that's fine. So this is the result of all of that effort. There's a bunch of other work as well. So Travis Goodspeed's GoodFet. That was originally like this kind of open JTAG debugger. Some black box reverse engineering that Felix Domka did a few years ago, which is basically, as you'll see when we go through this, trying to brute force undocumented JTAG commands. Whereas we're taking advantage of things that are existing. He's looking for other stuff, which is kind of interesting. And then there's a really cool paper from NFI, from the Netherlands Forensic Institute, about this sort of JTAG discovery, but in a different way. So first, we have to identify interfaces before we even try to hook up JTAGulator to it. External interfaces are things that we don't even have to open up the product to look for. So their accessibility to the outside world, usually, they're intended for engineers or manufacturers, not for end users. So you'll see them hidden under batteries, or under stickers, or covers, or something on the back of the device, or somewhere on the device. And usually it's used for system programming, final system tests, something like that. Maybe it's a proprietary connector. So if you look up there, we see there's like a Garmin GPS. I think that's a serial interface in this example. An RSA secure ID token with five pins on there. They had once told me, oh, that's only for programming the device. I don't know if that's true or not. I guess it doesn't matter anymore. But it's a good picture. And then the other one is from the Jawbone Up, that wristband accelerometer with the cap removed. So those of you guys that have it, there's a button on the end that you can push to do something with. If you take that cap off, you see the buttons in the center. And then there's four posts on those corners. And that's some sort of final programming interface. So if you can discover the interface, then you have to figure out what to do with it. But those are external interfaces. Internal interfaces, if you get access to the circuit board, which is really part of that hardware hacking process, sometimes you do need to get physical access. Sometimes you do need to get to the circuit board. That's not a big deal. That's the excuse that vendors say, oh, they have to have physical access. That's just a total fallacy. There's lots of ways you can get physical access to things. So you look for things like test points, unpopulated, component pads, silk screen markings might give you some information about, here's some interesting test points. Or here's the name of the interface. Engineers like to put things on circuit boards that make their job easier and that make the assembly facilities job easier. So we can take advantage of all of that stuff. Usually, debug interfaces are going to be in an easy access location. So if you look on the picture on the right, that is a very obvious interface. There's four gigantic holes there, four gigantic pads, test points. And I don't know if you can see, but on the silk screen, it says VBAT, ground, I2C clock, and I2C data. So we know right away, OK, that's an I2C interface, internship communication, bus. We know that. We don't need a JTAGulator. We can hook up a bus pirate or a logic analyzer and a oscilloscope or whatever. Start capturing communication. That's no big deal. The engineer was nice and made that very obvious for us. The one on the right, that's one of the BlackBerry devices. In that case, there's these, you know, there's kind of test points sprinkled all over the place, but then there's very obvious grouping of some test points. So I would look at that and say, OK, that's probably some sort of interface. Usually, connections or signals that perform a similar function are all together. So a bus would all be there. So that's probably a debug interface. And it is. It's JTAG. Sometimes, it gets even easier. So these examples are, one is from the Xbox on the right. The one on the left is from Barnaby Jack's ATM talk from a few years ago. And in those cases, you see nice silk screen markings around the whole thing. And on the left, in Barnaby's case, that was a Windows CE-based platform in that ATM. He opened it up and saw the JTAG interface right there using an industry standard interface. It said JTAG. He just got his off-the-shelf tools, plugged it right in, and started his ponage. So basically, no hardware reverse engineering necessary at that point. So we can take advantage of that. JTAG.test.com has a list of common pinouts that people use. And if you encounter that, you don't need a tool like JTAG that you just plug in. Gets a little bit harder if there's no obvious markings. But in this case, we could take advantage of the groupings of traces. So that picture on the left are six test points and see all the traces are going down together. That's probably some sort of interface. It's right on the edge of the board, very easy to access. That would be a target interface for us. You can also take into account the location of resistor arrays or pull-ups or pull-downs on different bus lines, because those are normally used to set the static state of some sort of interface. So if we see a grouping like that, like a resistor array right next to a connector, it's like, OK, that connector is probably some sort of bus. That needs pull-ups or pull-downs. That's a target. Let's take a look. Things get a little bit harder when there are no obvious test points. So things like this where we have just four unpopulated component pads in place of a connector or in place of test points. So this is a Buffalo wireless access point trying to be sneaky. So they have these unpopulated R24, R29, 315, 316. They're trying to obfuscate the interface. But as soon as you discover what those are, and those red markings obviously are the pinouts for JTAG, as soon as you discover what that pinout is, then you win. It's not going to change device to device, right? For that particular device, now you know. So security through security doesn't work. We say that all the time, and it's true. If you do discover an on-chip debug interface or what you think might be an interface or test points, currently you have to manually determine pin function. So you look at a grouping like that grouping of BlackBraid pins, like, OK, crap, what am I going to do? You can first try to use your oscilloscope and see what's going on. But actually what I like to do first is try to see if I can trace the signals back to a microcontroller or to some sort of device. So I'll either visually look. I'll use continuity test if I can with a multimeter. If it's a BGA part, a ball grid array part, that's going to get a lot harder, right? Because you can't access the balls underneath the part. So probing only gets you so far. You could use X-ray if you have access to X-ray equipment, which is becoming more common, but still you don't really have one at your house, I hope. Yeah, some people do. I'm not going to ask for what. And then you can identify the parts that are the target components, look up the data sheet, find the pinouts of what those parts are, see if they trace out anywhere. That's sort of the standard manual process. It's fine for certain things. It's totally valid. But for other devices like highly integrated mobile phones and stuff, it's just not even a possibility. Then you can start probing the connections, use your scope, use your logic analyzer, see how the states of those pins change. As you pull the other pins higher or low, lots of permutations, just a total pain in the ass. And I'll show you why the JTAGulator is better, but not yet. So I'm going to go into some details of JTAG and of UART, of asynchronous serial communication, just to get an idea of how all the technology works. And then it will make sense when we start to essentially brute force the connections. You'll understand. It makes total sense. So JTAG is one of these interfaces. It's an industry standard interface. And it basically, the IEEE 1149.1 standard basically defines this low level finite state machine and very low level functionality. So usually what you see is the vendor might add extra functionality or might abstract all of that low level stuff. But for our purposes, we don't care what happens at a higher level what the vendor does. We want to communicate directly with the chip to figure out the pinout. That's the only goal. So the beauty of JTAG, as opposed to a lot of the other types of on-chip debug interfaces that you see that are more vendor specific, is that we can access every single individual pin on the device. So we can send data out. We can read data in on every single pin. That's what allows when you do flash updates through JTAG port on the device. Because we control the main CPU. And we're basically treating it as a puppet. And now we can communicate with everything that that thing is connected to. So we can program devices. We can do debug and essentially use standard development tools to now communicate with these parts. As opposed to some of the other interfaces as well, which is why JTAG is so popular. You can chain connections together, chain devices together. So you can have a single interface, but then you can have two or three parts on the board that you can communicate with through that single interface, or even multiple dies within the same part. So you might have a CPU, memory, and a crypto crypto processor, or a Kodak, or whatever, all in the same package. But now you can still individually through JTAG communicate with each of those parts. Because JTAG ends up being a gigantic shift register of varying lengths once you figure that out. And I'll talk about that. And the vendor, again, will abstract all of that low level stuff. And we don't really care. Once we know the pinout, we can then load legitimate development tools that the vendor makes, or some of the open source stuff that's out there, and then start our attack process. JTAG's a synchronous serial interface, which means it's a serial interface with input and output. And then we need a clock to align itself to synchronize that data flow. So we have TDI, which is data in. We have data out. Test mode select and clock. Mode select is what we use to change state of the system. And I'll show you a diagram on the next few slides. Change state of that system to basically change function, or to shift data in, or to load an address, or load an instruction. I basically think of JTAG as a tiny little CPU that you can just send a very finite number of commands to. Then you also have test reset, which is an optional pin. So sometimes you see it on board. Sometimes you don't. All it's used for is to reset the tap, which is the test access port asynchronously. You can also do it by holding TMS high and clocking five cycles, which is what we do. So you don't really need the external test reset pin. So we don't look for that, because we don't care about it. So we have the tap, which is the state machine, and has different shift registers that we can take advantage of. So the first one is the instruction register. So this is where you would load in a low level JTAG instruction. It has to be greater than two bits wide. That's just per the spec. Usually it's like an 8-bit instruction, or 16-bit instruction. And then for data registers, you have a bypass register, which we're going to take advantage of. That's just a one-bit register, where you shift data in, and one clock cycle later, you get data out. That's what you can use to bypass one chip and get to another chip in the chain. Then you have boundary scan. That's going to be the definition of how you access every single pin. So you know the length of the register that it needs to be. And that's going to be defined on how many pins the part has. But so the boundary scan, you shift data into this gigantic register, and then you can latch everything at once. And then the device ID, which we also take advantage of for a different type of scan, is a 32-bit register. It's optional. So it's not required in the spec, but pretty much every device out there will have a device ID. But I wanted to make another way to test, in case the device didn't have a device ID, we can still do it with a bypass scan. Here's just a quick little view of the inside of the kind of high-level JTAG view. You have the core logic in the center of the chip, and then the BSC cells that are attached to each of those IOPins. That's the boundary scan cell. So that will control inputs and outputs. We're just totally crazy to just be able to control a chip like that. It's really cool. Then you have your data register, instruction register. And depending on what you shift in and depending on what you're in, defines which register is going to be shifted out on the TDO line. So here's the TAP controller. This is the state machine. It looks a little bit confusing, sort of like spaghetti, but it's very simple. You're either shifting in to work with the data register, or you're shifting in to work with the instruction register. Once you do that, then you just load data into either one, and then you latch it, and then you can exit, and then you can shift data out. So it's not as complicated as it seems. And I'd read through all of the IEEE standards, and they make this stuff so boring and so complicated, but it doesn't have to be. And I think that's just one of those things. It's like, why? I don't know if they like, people just write this stuff to look smart, and then it's our job to distill it and make it not smart. So this stuff is not as complicated as it looks. And again, we don't care about anything above this level, this low level. So these are the JTAG instructions that are available. I don't know how well you can see that slide. There's three required commands, and then a bunch of optional ones. Everything else, all the debug functionality that might be available on a part, anything else that vendor specific is all at a higher level. At a lower level, it's just shifting things in. It's calling commands. It's shifting stuff out of the various data registers. Maybe they add extra data registers for other memory locations or for debug stuff or a command to read memory or write memory. It's all vendor specific at that point. The things we take advantage of are the bypass command, which is just going to shift data in and out, and then the ID code command. If you do this enough, you will run into JTAG implementations that do have some sort of protection. But like anything else, most people don't use protection. It's pretty safe to say, especially at Def Con. But you do run into it once in a while. Vendors are aware of what's going on. But making changes in silicon is really hard. So even if a vendor knows about JTAG and they try to do some sort of password protection or whatever, it's a big change for them to do that. Then they're going to have to update everything else from that point that uses JTAG. What you might see are physical security fuses that are blown on the chip itself to prevent JTAG access from happening at all. Of course, once you do that, then the vendor can't use it as well. So it's a kind of risky maneuver. You might be able to do silicon dye attacks, sort of like what Chris Tarnofsky does, or Karsten Nol, to physically repair that fuse and then get into the device through JTAG. Some devices have some sort of password protection. Usually, if there is a password, it will still enable bypass mode. So we can still use it to determine the interface. But then at that point, we have to figure out, how do we bypass that password protection? There is one case I've heard of, maybe more, but here's one example of a device that had internal flash memory that would erase after some amount of invalid password attempts. But it wasn't keeping track of the password attempts between power cycles. So it was in some sort of volatile memory somewhere. So you could just figure out what that upper limit is and then just do some number of password group forcing, reset the device, and do more. Once you do find the JTAG interface, you can use a bunch of available hardware tools, HJTAG, Riftbox. There's lots of stuff out there. Again, we only care about finding the interface. And then you use tools that are actually designed to use JTAG in a higher level, because there's no point in recreating the wheel to do these things. And then you can use some of the open source software stuff as well. So that's JTAG. UART's a little bit simpler. We've all used some sort of serial interface of some sort. UART, it's an asynchronous serial communications method. So there's no external clock. All of the bits are sort of determined by time. So if we have that time right, then the data bits will line up. So you have start bit, data bit, parity, stop bit. JTAGulator is just checking 8n1 for UART, because that's the most standard UART interface. And even if you had like 7e1, which is also common, we would see that with 8n1. And then we would just have to fiddle with the settings in terminal program or something like that. Yeah, so it's asynchronous. We're only looking at two lines. We're looking for TX and RX. So we're going to send data to the device. Then we're going to look for a response on all of the other pins. And we'll change through all the different permutations of that. All the control signals that are used, that were sort of for legacy types of equipment, modems, and teletypes, or whatever, we're not looking at those, because we normally don't need those. Here's a little screenshot of the UART, just showing the data communications. I have digital decoding functionality on my scope, so I can actually see the data being transferred. And then to determine the bottom rate. So say you do discover the interface, but the bottom rate isn't quite lining up. You could just measure the smallest bit time, the bit width, do one over that, and you'll have the bottom rate. So in this case, it's 8.7 microseconds. So it's around 115.2 kilobits per second. All right, so a little bit of hardware about JTAGulator. As with lots of stuff that I designed, I want it to be open source. I want it to be hackable. I want people to use it. I don't want it to be over complicated. I don't want to try to show off how smart I can be, because I'm not that smart. But I wanted something that you guys can use. That's the whole point. So I have a simple command-based interface. Everything is done through the USB port to a host. And I'll give you a demo of that. It has proper input protection, so we can hook up to a device. We don't know what we're connecting to, right? We're just looking at a board. We don't know if we're connecting to proper voltage levels that are going to work with our part. So we have input protection. We have adjustable target voltage. So we can match the target voltage of the target device. So we're not accidentally damaging that device as we're sending signals to it. All components off the shelf, you can get them from DigiKey. And you could hand solder these boards if you want. I soldered four of them, and I'm like, forget it. I'm done. I'm going to let Parallax do it from now on. So the block diagram is we have a Parallax propeller device in the center, which is a great tool for hacking with, as you'll see. We have a standard FTDI FT232 USB serial interface. That's going to power the device, and that's going to provide power through USB, and also provide our programming interface and our command interface. I'm using an op amp and a filter as a D to A to generate the target voltage, so 1.2 to 3.3. And I'll go through details of each of these parts. And then the voltage level translators to translate our voltages and some power stuff. Here's the board. I figured it had to be pink with a heavy metal J-tagulator logo. Someone's clapping. They like pink. I like pink, too. Yeah. What better contrast, right? So I don't know. It was fun. But here's the basic setup. And so there's 24 channels, either through screw terminals or through the 2 by 5 headers, which are compatible with the bus pirate probes. So you can just plug in to the headers, and then you'll have little mini clips that you can use. So depending on what your interface is, you could use either one. So the propeller is the core of the system. For those of you guys that aren't familiar, it's a device completely built from the ground up, by PowerLax, meant to be a device that's fun to work with, and fun to hack on, and fun to develop with. Chip Gracie, the guy that designed it, grew up with 6502 and hacking Z80 and early pick devices. And he's a hardware hacker to the core. And he was just kind of tired of all the restrictions of different types of tools and NDAs and all this crap. So he's like, I'm going to build my own. So it's a great hacker tool. It has eight independent cores, which are called COGs, and some time slicing of that. You can code it in spin, which is what I'm using, assembly or C. There are a bunch of new tools being developed that are cross-platform tools. For now, you can do PC and Mac, at least with spin. And the open source spin tool should be coming out soon. If you guys were here last year, Defcon 20, right? You guys have Defcon 20 badges? Yeah, OK. Those are all propeller processors. So in theory, you could load the JTAGulator code onto your badge and connect up to stuff, but you don't have the input protection voltage, target voltage settings. But you could if you wanted to. The other cool thing about the propeller is, like some of these other hobbyist platforms, there's a huge amount of code sharing. So PowerLax has the object exchange, where you can grab things. Oh, I want to do D to A, grab that code. I want to do debug interface through serial, grab that. And you can put stuff up there as well. So it's a really kind of cool hacker developer community. We're running at 80 megahertz, which leaves lots of possibilities for not only detecting interfaces, which is what we're doing, but also generating all sorts of different things to go further with devices if you wanted to. The prop has 32K of RAM, boot loader is in ROM, and then each cog has 2K. So it's a good part. Of course, you can look into more detail if you want. USB interface, I mentioned the standard FTDI part. So it'll work. It'll just recognize virtual C report on any sort of machine. So any machine you have that recognizes this virtual comport, you can start communicating with JTAGulator. I have a MIT 2025. That's this distribution switch. Because according to the USB spec, you're not just supposed to plug in a device into USB and just let it go to town right away. During enumeration, you're supposed to just only given 100 milliamps by the host, and then you're supposed to enumerate and then request more for the rest of your system. So what we're doing is we're only enabling the FTDI part. Once the host comes back and says, OK, you're enumerated, you're ready to go, then we enable the rest of the system. That's a safe way to do it, so we're not damaging any USB ports. Target voltage, PWM output from one of the pins on the prop. And the duty cycle is going to determine what the output voltage is. And I have a little RC filter and an op amp, very simple implementation of a D to A. And I have a lookup table that actually defines the duty cycles for each voltage level in 0.1 volt increments. So we can be very fine in our output voltage. And I picked the 808065 because it has a high output current on that one output, single supply in that one output. So we can get about 150 milliamps output through that part for our voltage range. So that way maybe we need to use the adjustable target voltage, which there's a breakout on here. It's the VADJ line. If we want to use that to maybe power something on the target board or maybe do some extra circuitry with, whatever we need to do, 150 milliamps is a pretty decent amount. Level translation, I'm using the TXS0108, which are bi-directional level translators, which will convert our 3.3 volt signals which are coming from the propeller to our VADJ level, our adjustable voltage level. So 1.2 to 3.3 output. And then it has this high impedance state if we disable the output enable line. So we can connect all of our test points up while the thing is not driving the lines at all. So we don't cause something to happen when we're not ready to start our search. And then the input protection, which we need, that's because we don't know what we're connecting to. So we have diode limiter clamps in there that are going to clamp to some level of negative voltage and some level of high voltage. And also we have a current limiting resistor in there. For each channel, we have this setup. So as long as our forward voltage for these diodes that we're using are less than half a volt, which they are, then we're going to limit ourselves to the adjustable voltage plus forward voltage and minus forward voltage. That's our limit. So we're not going to damage any other of our pins with unknown input voltages. Bill of materials, there's quite a few parts, but none of them are really that expensive. So again, everything from Digi-Key, the bill of materials is online, around $51 in single quantity if you feel like building your own. So that's the hardware design. Pretty straightforward. And the good thing is the hardware is never really going to need to change. Maybe we want to develop some plug-in module to do higher voltages for SCADA equipment or industrial equipment or something. But the core hardware doesn't change. The firmware can change as we add more functionality as people start hacking on stuff, we can add things in. So here's the current source tree. I have the main object file. These spin files are the individual modules just to keep things modular. So if we add in, say we do a microchip ICSP interface, we can add that as a separate file and link that in. Sort of like C files or header files, whatever. You get it. So the main file is JTAGulator. And then we have the serial terminal, parallax serial terminal, which is the user interface. Real random is a pseudo random number generator that we're using for the bypass scan, which I'll show. Prop JTAG is all of the low-level JTAG routines. And then the JD cog serial is something I grabbed from the object exchange that is another UART interface. And I can just pop that into whatever cog I want. And that's going to be the interface that's doing the UART detection. So for actual functionality, I'll go through a few of the ways that we're scanning. And then I'll give you a demo. The ID code scan is the first thing that we can do. And this is assuming that the device actually supports ID code, supports the device ID, this 32-bit device ID. If it's available, on reset, it's going to be in the data register. So all we have to do is enter the shift data register state and just send a clock. And if there is a device ID, it's going to come out on the TDO line. We don't need to send any data in. So that's going to speed up our search, because now we're only looking for three pins instead of four pins for our various permutations. If we do get a device ID, if we get a valid one, or a one that we think might be valid, we can validate that by checking data sheets or BSDL files, which are boundary scan files that are going to define the entire internal structure of the part. You can find a lot of that stuff with development tools, legitimate development tools, open source tools, we'll list some of this stuff. Maybe look in reference code to make sure that the device ID you get is the correct one. If it is, then you know you have the interface. You can also just verify the manufacturer ID, which is a specific code assigned by JDEC, which is a standard. You can go to that website, grab the actual document for free, and then you compare. When you get your device ID back from the device, you can go, OK, make sure it's an analog devices part, or Broadcom part, or Qualcomm part, whatever it is, to see if that data is actually correct. So the way the scan works is going to ask for the number of channels to use. And then for every possible pin permutation, it's just going to go through, try to get the device ID. If it reads all ones, or if the final bit zero is not one, then we're going to ignore it. But if we get something with a bit zero of, if bit zero does not, yeah, if bit zero does not equal one, we ignore it. If it does equal one, then it's potentially a good device ID. We don't fully know. So there is still some human interaction. But usually, hopefully, you're not going to get lots of false positives. So that's ID code scan. Bypass scan is what we can use to actually get TDI as well, because now we need to shift data in and compare it to data coming out. So bypass scan just takes data one clock cycle delayed, as you can see on the scope screen shot here. So by doing the bypass, we can also figure out how many devices there are in the chain, which is called blind interrogation. All we're doing is basically, first we need to force all devices into bypass. And on that instruction sheet, bypass mode, you can enter in by sending a command of all ones. But we don't know the instruction register length, because it's sort of a black box. So we just send in a shitload of ones. And flush the entire device. We do 1,024 ones, because we don't know how many devices are there. We don't know how many instruction registers there are. So we send a ton of ones. Then we assume we're in bypass mode. Then we load in a bunch of ones. The data register, flush everything full of ones. And then we send a single zero, cascade it through until we see it on the output. Once we do, then we know, oh, OK, great. And we can figure out the number of devices as well. So bypass scan does exactly what I mentioned, just with every different pin permutation. So then UART scan, now we're looking at the UART interface, is kind of cool, because normally you can actually send any output string you want. So normally, if you connect up to an interface, you'd hit carriage return to see if you get a response. If you want to hang up on a modem or whatever, you do plus, plus, plus. Or whatever you want to do, maybe escape key. You can tell JTAGulator what user string you want to send out on what it thinks is the TX line. And then it's going to look on the RX line to see if it gets anything back. So it's going to try all different bot rates and basically wait 20 milliseconds to see if it receives a byte back. And if it doesn't, then it's going to move on to the next thing. 20 milliseconds is pretty long in computer time anyway. If there is a valid response, it's going to display 16 bytes of data. So we can kind of quickly go through and see if there's any human readable stuff or something that makes sense for what we're looking at. We're doing 8n1. Here's the bot rates that are stored in the lookup table. These are all the standard bot rates. If you do encounter something, maybe you find out the pinup, but you don't know all of the, you know, you're not seeing data that makes sense. Like I mentioned earlier, use your scope, figure out the bot rate, load it into a terminal program, and see if that helps at all. Give it some sort of non-standard bot rate. Here's some timings. This stuff happens pretty fast. ID code scans, since we're ignoring TDI, it's only three possible pins that we need. So the number of permutations go down, and it's pretty fast. It's 264 permutations a second. Bypass mode, we have that extra pin, that TDI pin. And because we have to flush so many ones through there, it takes a little bit longer. Just happens to be 13.37 permutations. It's totally lit. And you can see, like, most of the time, it's like two seconds, five seconds, or 13 seconds for ID code scan. At the max, it's 46 seconds for all 24 channels. Once you know that, usually I'll do an ID code scan first to make sure there's a JTAG interface there. And if there is, then I go to the bypass mode, the bypass scan, to get that extra pin. Because it takes a little bit longer. So maximum time, though, 24 channels, five hours. Big deal, you just take a really long lunch break, and you come back, and you're good. And then you are, ends up being 24 bot rates per permutation. So it ends up being about one permutation a second. 10 minutes for 24 channels. All right, here's some demos. Let's see, let me bring up my cool term, which is what I'm using on my Mac. How does that look up there? Is that nice and big? Good, OK. So let's see. I'm already connected. So I have my JTAGulator plugged in through MiniUSB, and I believe I'm already connected. So if I hit Enter, yeah. You guys see that response? Question mark, invalid command. So I get the colon sign that tells me that command prompt. So here we go. Here's a list, type H, here's the list of commands. We're going to do, let's see, what do I have hooked up first? First, I actually have UART hooked up, because I wanted to get everything set up before the talk. So I have a bunch of connections from the JTAGulator onto a Linksys WRT54G version 2 that has DDWRT on it already. So I just have a bunch of these little individual female leads connected up from the JTAGulator to that. So if we go ahead, first thing we need to do is set the target voltage. And I think I already did this. Yeah, so I'll do it again just for fun. Set the target voltage to 3.3 volts. Now target voltage is set. Then let's go ahead and do Identify UART pinout. We'll do carriage return, that's just the standard. Number of channels, I have one, two, three, four channels, four wires set up onto this port of the Linksys device. And pretend I don't know what it is, but I just arbitrarily connected things. I know that there's UART there, because I tested it. But I don't know which pin is which. So four channels, it's going to be 12 possible permutations. Reminds you, use channel 0 through 3. And we'll hit Spacebar to JTAGulate. Hopefully something will come up. OK, so a bunch of stuff came up. See if there's anything else. OK, UART scan complete. So a bunch of stuff came up. You can see the TX and RX lines are all the same, 1 and 3. That's a good sign. That means something's there. That means when we send a carriage return on pin 1, on channel 1, we're getting a response on channel 3. But the JTAGulator can't figure out what the data is, because it doesn't know what the data should be. If we have some interface, maybe it is a, some sort of debug interface. But maybe it's not ASCII. Maybe it's something else. Maybe it's some binary thing that we need to decode. So it lists everything there. But we can go through manually and say, OK, tell me when you guys see something that might be like a useful character. Let's see. Keep going here. Yeah, 57.6 has a 0D, which is what? A line feed or carriage return or something. And then you see this one that has a carriage return and line feed. So now we can test both of those and see which one it is. To save time, I'm just going to do this one. OK, so remember, it's transmit is pin 1, receive is pin 3, and it's 115.2k. So now we can do, we think we know the UART. Now we can do a pass-through mode, where we can say, TX is pin 1, RX is pin 3, border 8, 200. Enter that. Now we're in UART pass-through. So now we're just using the JTAGulator as a pass-through. So now we should be able to just communicate directly with the DDWRT. So here we are. And we're in the shell and stuff. So that's cool, because it saves you the trouble of disconnecting everything, putting in your own USB to serial adapter and stuff. So when we're done, we can just hit Control-X, and now we're back in JTAGulator side. OK, so I'm going to disconnect. Oh, and you know what I'm going to do first? Disconnect target voltage. Set it back to 0, so I don't fry anything as I'm taking these off. I take off all these pins. I'm going to take off all these pins. I'm going to take off all these pins. I'm going to take off all these pins. I'm going to take off all these pins. I'm going to take off all these pins. I'm going to take off all these pins. I'm going to take off all these pins. And now we'll do the JTAG detection. I'll do it with the Defcon 17 badge. You guys remember that? Yeah, like two people. OK, great. That's good enough. OK, three people. OK, so the Defcon 17 badge had a free-scale MC56F80006. That was a digital signal controller that just happened to have JTAG on it. And I'd broken out the different pins as test points on the board that we were using during the Badgehackin contest. You could reprogram the device and everything because they would constantly get bricked when people were trying to write code for them. So doing development, I just took all those test points, wired it up to a connector so I can connect it up to here and give the demo. But in real life, you wouldn't have a connector there, right? You would just solder wires on or something. So I'll plug this in. All right, so now it's plugged into the JTAGulator. Let's see. I have to set my target voltage. If I don't, and I try to do identify JTAG, it should tell me I need to set the target voltage first. So this is a three-volt system. Target voltage is set. So now let's do the ID code scan first. That's going to be the fast way. We have four channels, 24 possible permutations, and we'll JTAGulate. Uh-oh. Failure, good. Just what I like. Let's see what I screwed up. I don't know. Well, let's see. Let's try bypass scan. Bipass scan takes longer, not long enough for me to actually try to debug this thing. All right, how much time do we have? Good. Enough time for me to plug it in a different way. Oh, you know what? Did my ground pin fall off? No. Too much demo. Not enough time. As much time as I want. Okay. Thanks. Nothing after me. Good. Okay. So we'll see. So ground goes to ground. So now I'm just arbitrarily plugging stuff in. I'm going to do it on this connector. Ground goes to ground. Now I'm just plugging in. I don't care which pins they go to. So I'm just plugging in. On here. So channel 0 through 3. All right, let's see if I get lucky. Who knows. If not, I'll have to reboot. Reboot the JTAGulator. How lame is that? Okay. Target voltage set. Identify pinouts. Four pins. Okay. Reset. Type 30. That's fine. It will go to 3.0. That's the easy way to do it. Yeah. Okay. So a bug in the firmware. Great. When you go from UART mode to JTAG mode. Anyway, I'll fix that. Now we have a response. We have TDI we don't know. TDO is pin 3. TCK is pin 2. TMS is pin 1. So let's go ahead and try to find TDI. We're going to do four channels again. 24 permutations. Takes a little bit slightly longer. One device detected and there's our JTAG pinout. Enjoy. You can clap. Okay. So now what we can do is now that we know that pinout, what was it? I forget. 03210321. Oops. I messed that up. Okay. Yeah. So ID code we only need the three. So we need 321321. One device in the chain. Our ID code that 01C06 whatever. It corresponds to this free scale part. You can look it up. And then let's do the final one which is the testing bypass. So that's 0321. One device in the chain. And then pattern in matches the pattern out. So there we go. Now we're pretty sure we can do it again and get a different pattern. So yeah. Now we know that's the JTAG interface. Now we can go and hack with it. So that's our demo. Okay. So like everything there's limitations to the tool. Like having to press reset. The first thing you could possibly cause the target to do some sort of unintended thing as you're like fuzzing all these test points that you don't know what they are. But that's somewhat of a limitation but also it could be useful if you're hacking on a device and you don't know. If you somehow cause it to like do something unintended that might be useful. Maybe the OCD interface isn't enabled. Maybe it's some sort of if it's password protection or if it requires some sort of reset sequence we might not be able to detect it. Vendors try to be sneaky by cutting traces. Leaving out jumpers on connections to try to prevent somebody from using it. So we'd have to do a little more reverse engineering to find that first. Maybe there just is no on-chip debug interface. Future work we want to add all sorts of support for other stuff which hopefully will happen as needed. As somebody says I need to spy by wire on ti. Then I can write a module. There's lots of possibilities for this type of tool. It's basically like a general purpose propeller development tool with lots of I.O. That you can do for stuff. We do have a few more available at the hacker warehouse at the Defcon vendor area. All the stuff is available on jtagulator.com which goes to my website. Powerlax is selling assembled units and bare boards and if they run out of stock they're going to make more so you'll be able to get it. Okay so final thing I've been dying to read this poem that I went up to this guy that just writes random poems in San Francisco. I said I developed a tool called the jtagulator and explained what it was and he looked at me for a second and then he wrote this poem. Maybe you can make some sense of it but I'll just read it. To take an object from made to modified, customize interfaces between past and few truths can maintain their veneer in the face of signal feedbacks, size of diamond screwdriver doesn't fit circuit, exit, enter the drag net on all sides, caught with tools that are not on all sides, debugging as form of how to gain access to what you have but can't quite double blind verify, ascertain, make salient discoveries about how electricity keeps its secrets from anything that's not luckily everything electric is jtagulator. Take apart a ball of and find particles that can't be broken into. So there we go, the end. Thank you.
 Hello, hello, hello, hello, hello.  Hello.  Wow, it works.  Good.  You guys ready to j-tagulate?  We're going to have a group j-tagulating session.  You guys bring all your j-tagulation stuff,  Kleenex and stuff.  Good.  OK.  I did.  I'm ready.  My name is Joe Grand.  I am an electrical engineer and a hardware hacker.  And I guess I've been on TV a long time ago.  Not Rich and Famous.  Just Famous.  Yeah, right.  OK.  So we're going to talk about j-tagulator.  J-tagulator is a device I just put together,  a fully open source device that will let you hook up  to 24 unknown test points on a circuit board.  And it will detect if there's any sort of j-tag interface, which  is an on-chip debug interface, or also UART interfaces,  so things like Root Shell, Serial, Debug, Ports, whatever.  So I'm going to go through sort of an introduction  about the design, the process, j-tag, how j-tag works,  how UART works, and then, of course, give you  demos of all of this stuff.  So on-chip debug interfaces are basically  like the Achilles heel of embedded systems these days.  There's so many people getting involved in hardware.  And you got guys like Charlie Miller and Chris Valesek,  hacking cars.  Those are traditionally software guys.  You have lots of other people starting  to look at embedded systems in a hardware that  don't come from that space.  So it's really gone to this point.  And on-chip debug interfaces are one of those ways  that you can totally just own systems pretty much.  If you find the interface, you can win a lot of times.  So it's a well-known attack vector.  The problem is being able to find those interfaces.  And the one thing that we can always take advantage of  is that vendors and manufacturers and engineers  need to use these debug interfaces to actually design  their product and to test their product.  And during manufacturing, they would do final system tests.  So it's an interface that's used.  Vendors know that it's a potential problem,  but they normally don't do anything about it.  So we can take advantage of all of that.  So the goal for the project is just  to create a tool that will get people interested in hacking  devices in hardware hacking, especially for non-hardware  folks that don't have the equipment or the time  to have to manually go through everything and remove chips  and all of that crap.  It's just to get it done, get it done right,  find the interface, and then start hacking.  As with anything, you're sort of building on other work.  And this is no exception.  I first had seen some work about JTAG finding  with Hunze's JTAG finder, which was basically  like a proof of concept from 2006 that proved  that it was possible to brute force or enumerate  through all the different permutations of different test  points for JTAG.  That was pretty cool.  He did it on some sort of Atmel development board.  But that's as far as he went with it.  The next thing I saw after seeing that, I'm like, OK,  so there is some work out there.  Saw JTAG Enum by Dead Hacker and also RS-232 Enum.  And these were better than the original proof of concept.  But they were missing key features.  He was using an Arduino for the platform, which  limited things to either 3.3 volts or 5 volts.  Code left much to be desired.  They didn't have input protection.  And just a bunch of stuff on there that I saw.  And I was like, OK, well, I want to build a tool  that I can actually recommend to people  and feel good about having them connect up to stuff.  Because if you don't have that protection,  if you don't have certain things in there,  you could fry your target board.  And that's not a really good idea.  And then Cyber Fast Track, which was a really cool program,  I had submitted.  So once I did all this research, I wrote this whole proposal  for Cyber Fast Track.  I was like, this is awesome.  All my friends are doing CFT.  I want to do CFT and get paid to develop JTAG-ULAR.  That would be totally awesome.  But it didn't actually work out that way.  They said, oh, too much engineering.  Sorry, not enough research.  And at that point, I had already done all of the work  to get to that point.  I remember the proposal and the studying of JTAG and everything.  And I'm like, forget it.  I'm going to do it anyway.  And then just get it out there anyway and not get paid  while I do it.  And that's fine.  So this is the result of all of that effort.  There's a bunch of other work as well.  So Travis Goodspeed's GoodFet.  That was originally like this kind of open JTAG debugger.  Some black box reverse engineering  that Felix Domka did a few years ago, which is basically,  as you'll see when we go through this,  trying to brute force undocumented JTAG commands.  Whereas we're taking advantage of things  that are existing.  He's looking for other stuff, which is kind of interesting.  And then there's a really cool paper from NFI,  from the Netherlands Forensic Institute,  about this sort of JTAG discovery, but in a different way.  So first, we have to identify interfaces  before we even try to hook up JTAGulator to it.  External interfaces are things that we don't even  have to open up the product to look for.  So their accessibility to the outside world, usually,  they're intended for engineers or manufacturers,  not for end users.  So you'll see them hidden under batteries,  or under stickers, or covers, or something  on the back of the device, or somewhere on the device.  And usually it's used for system programming,  final system tests, something like that.  Maybe it's a proprietary connector.  So if you look up there, we see there's like a Garmin GPS.  I think that's a serial interface in this example.  An RSA secure ID token with five pins on there.  They had once told me, oh, that's only  for programming the device.  I don't know if that's true or not.  I guess it doesn't matter anymore.  But it's a good picture.  And then the other one is from the Jawbone Up,  that wristband accelerometer with the cap removed.  So those of you guys that have it,  there's a button on the end that you  can push to do something with.  If you take that cap off, you see the buttons in the center.  And then there's four posts on those corners.  And that's some sort of final programming interface.  So if you can discover the interface,  then you have to figure out what to do with it.  But those are external interfaces.  Internal interfaces, if you get access to the circuit board,  which is really part of that hardware hacking process,  sometimes you do need to get physical access.  Sometimes you do need to get to the circuit board.  That's not a big deal.  That's the excuse that vendors say, oh,  they have to have physical access.  That's just a total fallacy.  There's lots of ways you can get physical access to things.  So you look for things like test points, unpopulated,  component pads, silk screen markings  might give you some information about,  here's some interesting test points.  Or here's the name of the interface.  Engineers like to put things on circuit boards  that make their job easier and that make the assembly  facilities job easier.  So we can take advantage of all of that stuff.  Usually, debug interfaces are going  to be in an easy access location.  So if you look on the picture on the right,  that is a very obvious interface.  There's four gigantic holes there, four gigantic pads,  test points.  And I don't know if you can see, but on the silk screen,  it says VBAT, ground, I2C clock, and I2C data.  So we know right away, OK, that's an I2C interface,  internship communication, bus.  We know that.  We don't need a JTAGulator.  We can hook up a bus pirate or a logic analyzer  and a oscilloscope or whatever.  Start capturing communication.  That's no big deal.  The engineer was nice and made that very obvious for us.  The one on the right, that's one of the BlackBerry devices.  In that case, there's these, you know,  there's kind of test points sprinkled all over the place,  but then there's very obvious grouping of some test points.  So I would look at that and say, OK, that's probably  some sort of interface.  Usually, connections or signals that  perform a similar function are all together.  So a bus would all be there.  So that's probably a debug interface.  And it is.  It's JTAG.  Sometimes, it gets even easier.  So these examples are, one is from the Xbox on the right.  The one on the left is from Barnaby Jack's ATM  talk from a few years ago.  And in those cases, you see nice silk screen markings  around the whole thing.  And on the left, in Barnaby's case,  that was a Windows CE-based platform in that ATM.  He opened it up and saw the JTAG interface right there  using an industry standard interface.  It said JTAG.  He just got his off-the-shelf tools,  plugged it right in, and started his ponage.  So basically, no hardware reverse engineering  necessary at that point.  So we can take advantage of that.  JTAG.test.com has a list of common pinouts that people use.  And if you encounter that, you don't  need a tool like JTAG that you just plug in.  Gets a little bit harder if there's no obvious markings.  But in this case, we could take advantage  of the groupings of traces.  So that picture on the left are six test points  and see all the traces are going down together.  That's probably some sort of interface.  It's right on the edge of the board, very easy to access.  That would be a target interface for us.  You can also take into account the location of resistor arrays  or pull-ups or pull-downs on different bus lines,  because those are normally used to set the static state  of some sort of interface.  So if we see a grouping like that,  like a resistor array right next to a connector,  it's like, OK, that connector is probably some sort of bus.  That needs pull-ups or pull-downs.  That's a target.  Let's take a look.  Things get a little bit harder when  there are no obvious test points.  So things like this where we have just four unpopulated  component pads in place of a connector  or in place of test points.  So this is a Buffalo wireless access point  trying to be sneaky.  So they have these unpopulated R24, R29, 315, 316.  They're trying to obfuscate the interface.  But as soon as you discover what those are,  and those red markings obviously are the pinouts for JTAG,  as soon as you discover what that pinout is, then you win.  It's not going to change device to device, right?  For that particular device, now you know.  So security through security doesn't work.  We say that all the time, and it's true.  If you do discover an on-chip debug interface  or what you think might be an interface or test points,  currently you have to manually determine pin function.  So you look at a grouping like that grouping of BlackBraid pins,  like, OK, crap, what am I going to do?  You can first try to use your oscilloscope  and see what's going on.  But actually what I like to do first  is try to see if I can trace the signals back  to a microcontroller or to some sort of device.  So I'll either visually look.  I'll use continuity test if I can with a multimeter.  If it's a BGA part, a ball grid array part,  that's going to get a lot harder, right?  Because you can't access the balls underneath the part.  So probing only gets you so far.  You could use X-ray if you have access to X-ray equipment,  which is becoming more common, but still you don't really  have one at your house, I hope.  Yeah, some people do.  I'm not going to ask for what.  And then you can identify the parts that  are the target components, look up the data sheet,  find the pinouts of what those parts are,  see if they trace out anywhere.  That's sort of the standard manual process.  It's fine for certain things.  It's totally valid.  But for other devices like highly integrated mobile phones  and stuff, it's just not even a possibility.  Then you can start probing the connections,  use your scope, use your logic analyzer,  see how the states of those pins change.  As you pull the other pins higher or low,  lots of permutations, just a total pain in the ass.  And I'll show you why the JTAGulator is better, but not yet.  So I'm going to go into some details of JTAG and of UART,  of asynchronous serial communication,  just to get an idea of how all the technology works.  And then it will make sense when we start to essentially brute  force the connections.  You'll understand.  It makes total sense.  So JTAG is one of these interfaces.  It's an industry standard interface.  And it basically, the IEEE 1149.1 standard  basically defines this low level finite state machine  and very low level functionality.  So usually what you see is the vendor  might add extra functionality or might abstract all  of that low level stuff.  But for our purposes, we don't care  what happens at a higher level what the vendor does.  We want to communicate directly with the chip  to figure out the pinout.  That's the only goal.  So the beauty of JTAG, as opposed  to a lot of the other types of on-chip debug interfaces  that you see that are more vendor specific,  is that we can access every single individual pin  on the device.  So we can send data out.  We can read data in on every single pin.  That's what allows when you do flash updates through JTAG  port on the device.  Because we control the main CPU.  And we're basically treating it as a puppet.  And now we can communicate with everything  that that thing is connected to.  So we can program devices.  We can do debug and essentially use standard development tools  to now communicate with these parts.  As opposed to some of the other interfaces as well, which  is why JTAG is so popular.  You can chain connections together,  chain devices together.  So you can have a single interface,  but then you can have two or three parts on the board  that you can communicate with through that single interface,  or even multiple dies within the same part.  So you might have a CPU, memory, and a crypto  crypto processor, or a Kodak, or whatever,  all in the same package.  But now you can still individually through JTAG  communicate with each of those parts.  Because JTAG ends up being a gigantic shift register  of varying lengths once you figure that out.  And I'll talk about that.  And the vendor, again, will abstract all  of that low level stuff.  And we don't really care.  Once we know the pinout, we can then  load legitimate development tools  that the vendor makes, or some of the open source stuff  that's out there, and then start our attack process.  JTAG's a synchronous serial interface,  which means it's a serial interface with input and output.  And then we need a clock to align itself  to synchronize that data flow.  So we have TDI, which is data in.  We have data out.  Test mode select and clock.  Mode select is what we use to change state of the system.  And I'll show you a diagram on the next few slides.  Change state of that system to basically change function,  or to shift data in, or to load an address,  or load an instruction.  I basically think of JTAG as a tiny little CPU  that you can just send a very finite number of commands to.  Then you also have test reset, which is an optional pin.  So sometimes you see it on board.  Sometimes you don't.  All it's used for is to reset the tap, which  is the test access port asynchronously.  You can also do it by holding TMS high and clocking  five cycles, which is what we do.  So you don't really need the external test reset pin.  So we don't look for that, because we don't care about it.  So we have the tap, which is the state machine,  and has different shift registers  that we can take advantage of.  So the first one is the instruction register.  So this is where you would load in a low level JTAG instruction.  It has to be greater than two bits wide.  That's just per the spec.  Usually it's like an 8-bit instruction, or 16-bit instruction.  And then for data registers, you have a bypass register,  which we're going to take advantage of.  That's just a one-bit register, where you shift data in,  and one clock cycle later, you get data out.  That's what you can use to bypass one chip  and get to another chip in the chain.  Then you have boundary scan.  That's going to be the definition of how  you access every single pin.  So you know the length of the register that it needs to be.  And that's going to be defined on how many pins the part has.  But so the boundary scan, you shift data  into this gigantic register, and then you  can latch everything at once.  And then the device ID, which we also  take advantage of for a different type of scan,  is a 32-bit register.  It's optional.  So it's not required in the spec, but pretty much every device  out there will have a device ID.  But I wanted to make another way to test,  in case the device didn't have a device ID,  we can still do it with a bypass scan.  Here's just a quick little view of the inside of the kind of high-level  JTAG view.  You have the core logic in the center of the chip,  and then the BSC cells that are attached to each of those IOPins.  That's the boundary scan cell.  So that will control inputs and outputs.  We're just totally crazy to just be  able to control a chip like that.  It's really cool.  Then you have your data register, instruction register.  And depending on what you shift in and depending  on what you're in, defines which register is going to be shifted  out on the TDO line.  So here's the TAP controller.  This is the state machine.  It looks a little bit confusing, sort of like spaghetti,  but it's very simple.  You're either shifting in to work with the data register,  or you're shifting in to work with the instruction register.  Once you do that, then you just load data into either one,  and then you latch it, and then you can exit,  and then you can shift data out.  So it's not as complicated as it seems.  And I'd read through all of the IEEE standards,  and they make this stuff so boring and so complicated,  but it doesn't have to be.  And I think that's just one of those things.  It's like, why?  I don't know if they like, people just  write this stuff to look smart, and then it's  our job to distill it and make it not smart.  So this stuff is not as complicated as it looks.  And again, we don't care about anything above this level,  this low level.  So these are the JTAG instructions that are available.  I don't know how well you can see that slide.  There's three required commands, and then  a bunch of optional ones.  Everything else, all the debug functionality  that might be available on a part,  anything else that vendor specific is all at a higher level.  At a lower level, it's just shifting things in.  It's calling commands.  It's shifting stuff out of the various data registers.  Maybe they add extra data registers for other memory  locations or for debug stuff or a command to read memory  or write memory.  It's all vendor specific at that point.  The things we take advantage of are the bypass command,  which is just going to shift data in and out,  and then the ID code command.  If you do this enough, you will run into JTAG implementations  that do have some sort of protection.  But like anything else, most people don't use protection.  It's pretty safe to say, especially at Def Con.  But you do run into it once in a while.  Vendors are aware of what's going on.  But making changes in silicon is really hard.  So even if a vendor knows about JTAG  and they try to do some sort of password protection  or whatever, it's a big change for them to do that.  Then they're going to have to update everything else  from that point that uses JTAG.  What you might see are physical security fuses  that are blown on the chip itself to prevent JTAG access  from happening at all.  Of course, once you do that, then the vendor  can't use it as well.  So it's a kind of risky maneuver.  You might be able to do silicon dye attacks,  sort of like what Chris Tarnofsky does, or Karsten Nol,  to physically repair that fuse and then get into the device  through JTAG.  Some devices have some sort of password protection.  Usually, if there is a password, it  will still enable bypass mode.  So we can still use it to determine the interface.  But then at that point, we have to figure out,  how do we bypass that password protection?  There is one case I've heard of, maybe more,  but here's one example of a device  that had internal flash memory that would erase after some  amount of invalid password attempts.  But it wasn't keeping track of the password attempts  between power cycles.  So it was in some sort of volatile memory somewhere.  So you could just figure out what that upper limit is  and then just do some number of password group forcing,  reset the device, and do more.  Once you do find the JTAG interface,  you can use a bunch of available hardware tools,  HJTAG, Riftbox.  There's lots of stuff out there.  Again, we only care about finding the interface.  And then you use tools that are actually  designed to use JTAG in a higher level,  because there's no point in recreating the wheel  to do these things.  And then you can use some of the open source software stuff  as well.  So that's JTAG.  UART's a little bit simpler.  We've all used some sort of serial interface of some sort.  UART, it's an asynchronous serial communications method.  So there's no external clock.  All of the bits are sort of determined by time.  So if we have that time right, then the data bits will line up.  So you have start bit, data bit, parity, stop bit.  JTAGulator is just checking 8n1 for UART,  because that's the most standard UART interface.  And even if you had like 7e1, which is also common,  we would see that with 8n1.  And then we would just have to fiddle with the settings  in terminal program or something like that.  Yeah, so it's asynchronous.  We're only looking at two lines.  We're looking for TX and RX.  So we're going to send data to the device.  Then we're going to look for a response on all of the other pins.  And we'll change through all the different permutations  of that.  All the control signals that are used,  that were sort of for legacy types of equipment, modems,  and teletypes, or whatever, we're not looking at those,  because we normally don't need those.  Here's a little screenshot of the UART,  just showing the data communications.  I have digital decoding functionality on my scope,  so I can actually see the data being transferred.  And then to determine the bottom rate.  So say you do discover the interface,  but the bottom rate isn't quite lining up.  You could just measure the smallest bit time, the bit width,  do one over that, and you'll have the bottom rate.  So in this case, it's 8.7 microseconds.  So it's around 115.2 kilobits per second.  All right, so a little bit of hardware about JTAGulator.  As with lots of stuff that I designed,  I want it to be open source.  I want it to be hackable.  I want people to use it.  I don't want it to be over complicated.  I don't want to try to show off how smart I can be,  because I'm not that smart.  But I wanted something that you guys can use.  That's the whole point.  So I have a simple command-based interface.  Everything is done through the USB port to a host.  And I'll give you a demo of that.  It has proper input protection, so we  can hook up to a device.  We don't know what we're connecting to, right?  We're just looking at a board.  We don't know if we're connecting to proper voltage levels  that are going to work with our part.  So we have input protection.  We have adjustable target voltage.  So we can match the target voltage of the target device.  So we're not accidentally damaging that device  as we're sending signals to it.  All components off the shelf, you can get them from DigiKey.  And you could hand solder these boards if you want.  I soldered four of them, and I'm like, forget it.  I'm done.  I'm going to let Parallax do it from now on.  So the block diagram is we have a Parallax propeller device  in the center, which is a great tool for hacking with,  as you'll see.  We have a standard FTDI FT232 USB serial interface.  That's going to power the device,  and that's going to provide power through USB,  and also provide our programming interface  and our command interface.  I'm using an op amp and a filter as a D to A  to generate the target voltage, so 1.2 to 3.3.  And I'll go through details of each of these parts.  And then the voltage level translators  to translate our voltages and some power stuff.  Here's the board.  I figured it had to be pink with a heavy metal J-tagulator  logo.  Someone's clapping.  They like pink.  I like pink, too.  Yeah.  What better contrast, right?  So I don't know.  It was fun.  But here's the basic setup.  And so there's 24 channels, either through screw terminals  or through the 2 by 5 headers, which  are compatible with the bus pirate probes.  So you can just plug in to the headers,  and then you'll have little mini clips that you can use.  So depending on what your interface is,  you could use either one.  So the propeller is the core of the system.  For those of you guys that aren't familiar,  it's a device completely built from the ground up,  by PowerLax, meant to be a device that's fun to work with,  and fun to hack on, and fun to develop with.  Chip Gracie, the guy that designed it,  grew up with 6502 and hacking Z80 and early pick devices.  And he's a hardware hacker to the core.  And he was just kind of tired of all the restrictions  of different types of tools and NDAs and all this crap.  So he's like, I'm going to build my own.  So it's a great hacker tool.  It has eight independent cores, which are called COGs,  and some time slicing of that.  You can code it in spin, which is what I'm using, assembly  or C. There are a bunch of new tools being developed  that are cross-platform tools.  For now, you can do PC and Mac, at least with spin.  And the open source spin tool should be coming out soon.  If you guys were here last year, Defcon 20, right?  You guys have Defcon 20 badges?  Yeah, OK.  Those are all propeller processors.  So in theory, you could load the JTAGulator code onto your badge  and connect up to stuff, but you don't have the input protection  voltage, target voltage settings.  But you could if you wanted to.  The other cool thing about the propeller  is, like some of these other hobbyist platforms,  there's a huge amount of code sharing.  So PowerLax has the object exchange,  where you can grab things.  Oh, I want to do D to A, grab that code.  I want to do debug interface through serial, grab that.  And you can put stuff up there as well.  So it's a really kind of cool hacker developer community.  We're running at 80 megahertz, which leaves lots of possibilities  for not only detecting interfaces, which is what we're doing,  but also generating all sorts of different things  to go further with devices if you wanted to.  The prop has 32K of RAM, boot loader is in ROM,  and then each cog has 2K.  So it's a good part.  Of course, you can look into more detail if you want.  USB interface, I mentioned the standard FTDI part.  So it'll work.  It'll just recognize virtual C report on any sort of machine.  So any machine you have that recognizes this virtual comport,  you can start communicating with JTAGulator.  I have a MIT 2025.  That's this distribution switch.  Because according to the USB spec,  you're not just supposed to plug in a device into USB  and just let it go to town right away.  During enumeration, you're supposed to just  only given 100 milliamps by the host,  and then you're supposed to enumerate and then request  more for the rest of your system.  So what we're doing is we're only enabling the FTDI part.  Once the host comes back and says, OK, you're enumerated,  you're ready to go, then we enable the rest of the system.  That's a safe way to do it, so we're not damaging any USB ports.  Target voltage, PWM output from one of the pins on the prop.  And the duty cycle is going to determine what the output  voltage is.  And I have a little RC filter and an op amp,  very simple implementation of a D to A. And I have a lookup  table that actually defines the duty cycles for each voltage  level in 0.1 volt increments.  So we can be very fine in our output voltage.  And I picked the 808065 because it has a high output current  on that one output, single supply in that one output.  So we can get about 150 milliamps output  through that part for our voltage range.  So that way maybe we need to use the adjustable target  voltage, which there's a breakout on here.  It's the VADJ line.  If we want to use that to maybe power something  on the target board or maybe do some extra circuitry with,  whatever we need to do, 150 milliamps  is a pretty decent amount.  Level translation, I'm using the TXS0108, which  are bi-directional level translators,  which will convert our 3.3 volt signals which  are coming from the propeller to our VADJ level,  our adjustable voltage level.  So 1.2 to 3.3 output.  And then it has this high impedance state  if we disable the output enable line.  So we can connect all of our test points up  while the thing is not driving the lines at all.  So we don't cause something to happen  when we're not ready to start our search.  And then the input protection, which we need,  that's because we don't know what we're connecting to.  So we have diode limiter clamps in there  that are going to clamp to some level of negative voltage  and some level of high voltage.  And also we have a current limiting resistor in there.  For each channel, we have this setup.  So as long as our forward voltage for these diodes  that we're using are less than half a volt, which they are,  then we're going to limit ourselves  to the adjustable voltage plus forward voltage  and minus forward voltage.  That's our limit.  So we're not going to damage any other of our pins  with unknown input voltages.  Bill of materials, there's quite a few parts,  but none of them are really that expensive.  So again, everything from Digi-Key,  the bill of materials is online, around $51 in single quantity  if you feel like building your own.  So that's the hardware design.  Pretty straightforward.  And the good thing is the hardware  is never really going to need to change.  Maybe we want to develop some plug-in module  to do higher voltages for SCADA equipment  or industrial equipment or something.  But the core hardware doesn't change.  The firmware can change as we add more functionality  as people start hacking on stuff, we can add things in.  So here's the current source tree.  I have the main object file.  These spin files are the individual modules  just to keep things modular.  So if we add in, say we do a microchip ICSP interface,  we can add that as a separate file and link that in.  Sort of like C files or header files, whatever.  You get it.  So the main file is JTAGulator.  And then we have the serial terminal,  parallax serial terminal, which is the user interface.  Real random is a pseudo random number generator  that we're using for the bypass scan, which I'll show.  Prop JTAG is all of the low-level JTAG routines.  And then the JD cog serial is something  I grabbed from the object exchange that  is another UART interface.  And I can just pop that into whatever cog I want.  And that's going to be the interface that's  doing the UART detection.  So for actual functionality, I'll go through a few of the ways  that we're scanning.  And then I'll give you a demo.  The ID code scan is the first thing that we can do.  And this is assuming that the device actually  supports ID code, supports the device ID, this 32-bit device  ID.  If it's available, on reset, it's  going to be in the data register.  So all we have to do is enter the shift data register state  and just send a clock.  And if there is a device ID, it's  going to come out on the TDO line.  We don't need to send any data in.  So that's going to speed up our search,  because now we're only looking for three pins instead  of four pins for our various permutations.  If we do get a device ID, if we get a valid one,  or a one that we think might be valid,  we can validate that by checking data sheets or BSDL files,  which are boundary scan files that  are going to define the entire internal structure of the part.  You can find a lot of that stuff with development tools,  legitimate development tools, open source tools,  we'll list some of this stuff.  Maybe look in reference code to make sure  that the device ID you get is the correct one.  If it is, then you know you have the interface.  You can also just verify the manufacturer ID,  which is a specific code assigned by JDEC, which  is a standard.  You can go to that website, grab the actual document for free,  and then you compare.  When you get your device ID back from the device,  you can go, OK, make sure it's an analog devices part,  or Broadcom part, or Qualcomm part, whatever it is,  to see if that data is actually correct.  So the way the scan works is going  to ask for the number of channels to use.  And then for every possible pin permutation,  it's just going to go through, try to get the device ID.  If it reads all ones, or if the final bit zero is not one,  then we're going to ignore it.  But if we get something with a bit zero of, if bit zero does  not, yeah, if bit zero does not equal one, we ignore it.  If it does equal one, then it's potentially a good device ID.  We don't fully know.  So there is still some human interaction.  But usually, hopefully, you're not  going to get lots of false positives.  So that's ID code scan.  Bypass scan is what we can use to actually get TDI as well,  because now we need to shift data in and compare it  to data coming out.  So bypass scan just takes data one clock cycle delayed,  as you can see on the scope screen shot here.  So by doing the bypass, we can also figure out  how many devices there are in the chain, which  is called blind interrogation.  All we're doing is basically, first we  need to force all devices into bypass.  And on that instruction sheet, bypass mode,  you can enter in by sending a command of all ones.  But we don't know the instruction register length,  because it's sort of a black box.  So we just send in a shitload of ones.  And flush the entire device.  We do 1,024 ones, because we don't know how many devices are  there.  We don't know how many instruction registers there are.  So we send a ton of ones.  Then we assume we're in bypass mode.  Then we load in a bunch of ones.  The data register, flush everything full of ones.  And then we send a single zero, cascade it through  until we see it on the output.  Once we do, then we know, oh, OK, great.  And we can figure out the number of devices as well.  So bypass scan does exactly what I mentioned,  just with every different pin permutation.  So then UART scan, now we're looking at the UART interface,  is kind of cool, because normally you can actually  send any output string you want.  So normally, if you connect up to an interface,  you'd hit carriage return to see if you get a response.  If you want to hang up on a modem or whatever,  you do plus, plus, plus.  Or whatever you want to do, maybe escape key.  You can tell JTAGulator what user string you want to send out  on what it thinks is the TX line.  And then it's going to look on the RX line  to see if it gets anything back.  So it's going to try all different bot rates  and basically wait 20 milliseconds  to see if it receives a byte back.  And if it doesn't, then it's going  to move on to the next thing.  20 milliseconds is pretty long in computer time anyway.  If there is a valid response, it's  going to display 16 bytes of data.  So we can kind of quickly go through  and see if there's any human readable stuff or something  that makes sense for what we're looking at.  We're doing 8n1.  Here's the bot rates that are stored in the lookup table.  These are all the standard bot rates.  If you do encounter something, maybe you find out the pinup,  but you don't know all of the, you know,  you're not seeing data that makes sense.  Like I mentioned earlier, use your scope,  figure out the bot rate, load it into a terminal program,  and see if that helps at all.  Give it some sort of non-standard bot rate.  Here's some timings.  This stuff happens pretty fast.  ID code scans, since we're ignoring TDI,  it's only three possible pins that we need.  So the number of permutations go down, and it's pretty fast.  It's 264 permutations a second.  Bypass mode, we have that extra pin, that TDI pin.  And because we have to flush so many ones through there,  it takes a little bit longer.  Just happens to be 13.37 permutations.  It's totally lit.  And you can see, like, most of the time,  it's like two seconds, five seconds,  or 13 seconds for ID code scan.  At the max, it's 46 seconds for all 24 channels.  Once you know that, usually I'll do an ID code scan first  to make sure there's a JTAG interface there.  And if there is, then I go to the bypass mode,  the bypass scan, to get that extra pin.  Because it takes a little bit longer.  So maximum time, though, 24 channels, five hours.  Big deal, you just take a really long lunch break,  and you come back, and you're good.  And then you are, ends up being 24 bot rates  per permutation.  So it ends up being about one permutation a second.  10 minutes for 24 channels.  All right, here's some demos.  Let's see, let me bring up my cool term,  which is what I'm using on my Mac.  How does that look up there?  Is that nice and big?  Good, OK.  So let's see.  I'm already connected.  So I have my JTAGulator plugged in through MiniUSB,  and I believe I'm already connected.  So if I hit Enter, yeah.  You guys see that response?  Question mark, invalid command.  So I get the colon sign that tells me that command prompt.  So here we go.  Here's a list, type H, here's the list of commands.  We're going to do, let's see, what do I have hooked up first?  First, I actually have UART hooked up,  because I wanted to get everything set up before the talk.  So I have a bunch of connections from the JTAGulator  onto a Linksys WRT54G version 2 that has DDWRT on it already.  So I just have a bunch of these little individual female  leads connected up from the JTAGulator to that.  So if we go ahead, first thing we need to do  is set the target voltage.  And I think I already did this.  Yeah, so I'll do it again just for fun.  Set the target voltage to 3.3 volts.  Now target voltage is set.  Then let's go ahead and do Identify UART pinout.  We'll do carriage return, that's just the standard.  Number of channels, I have one, two, three, four channels,  four wires set up onto this port of the Linksys device.  And pretend I don't know what it is,  but I just arbitrarily connected things.  I know that there's UART there, because I tested it.  But I don't know which pin is which.  So four channels, it's going to be 12 possible permutations.  Reminds you, use channel 0 through 3.  And we'll hit Spacebar to JTAGulate.  Hopefully something will come up.  OK, so a bunch of stuff came up.  See if there's anything else.  OK, UART scan complete.  So a bunch of stuff came up.  You can see the TX and RX lines are all the same, 1 and 3.  That's a good sign.  That means something's there.  That means when we send a carriage return on pin 1,  on channel 1, we're getting a response on channel 3.  But the JTAGulator can't figure out what the data is,  because it doesn't know what the data should be.  If we have some interface, maybe it is a,  some sort of debug interface.  But maybe it's not ASCII.  Maybe it's something else.  Maybe it's some binary thing that we need to decode.  So it lists everything there.  But we can go through manually and say, OK, tell me when you  guys see something that might be like a useful character.  Let's see.  Keep going here.  Yeah, 57.6 has a 0D, which is what?  A line feed or carriage return or something.  And then you see this one that has a carriage return and  line feed.  So now we can test both of those and see which one it is.  To save time, I'm just going to do this one.  OK, so remember, it's transmit is pin 1, receive is pin 3,  and it's 115.2k.  So now we can do, we think we know the UART.  Now we can do a pass-through mode, where we can say, TX  is pin 1, RX is pin 3, border 8, 200.  Enter that.  Now we're in UART pass-through.  So now we're just using the JTAGulator as a pass-through.  So now we should be able to just communicate directly with  the DDWRT.  So here we are.  And we're in the shell and stuff.  So that's cool, because it saves you the trouble of  disconnecting everything, putting in your own USB to  serial adapter and stuff.  So when we're done, we can just hit Control-X, and now we're  back in JTAGulator side.  OK, so I'm going to disconnect.  Oh, and you know what I'm going to do first?  Disconnect target voltage.  Set it back to 0, so I don't fry anything as I'm taking these  off.  I take off all these pins.  I'm going to take off all these pins.  I'm going to take off all these pins.  I'm going to take off all these pins.  I'm going to take off all these pins.  I'm going to take off all these pins.  I'm going to take off all these pins.  I'm going to take off all these pins.  And now we'll do the JTAG detection.  I'll do it with the Defcon 17 badge.  You guys remember that?  Yeah, like two people.  OK, great.  That's good enough.  OK, three people.  OK, so the Defcon 17 badge had a free-scale MC56F80006.  That was a digital signal controller that just happened to  have JTAG on it.  And I'd broken out the different pins as test points on  the board that we were using during the Badgehackin contest.  You could reprogram the device and everything because they  would constantly get bricked when people were trying to write  code for them.  So doing development, I just took all those test points,  wired it up to a connector so I can connect it up to here  and give the demo.  But in real life, you wouldn't have a connector there, right?  You would just solder wires on or something.  So I'll plug this in.  All right, so now it's plugged into the JTAGulator.  Let's see.  I have to set my target voltage.  If I don't, and I try to do identify JTAG, it should tell me  I need to set the target voltage first.  So this is a three-volt system.  Target voltage is set.  So now let's do the ID code scan first.  That's going to be the fast way.  We have four channels, 24 possible permutations, and we'll  JTAGulate.  Uh-oh.  Failure, good.  Just what I like.  Let's see what I screwed up.  I don't know.  Well, let's see.  Let's try bypass scan.  Bipass scan takes longer, not long enough for me to actually try  to debug this thing.  All right, how much time do we have?  Good.  Enough time for me to plug it in a different way.  Oh, you know what?  Did my ground pin fall off?  No.  Too much demo.  Not enough time.  As much time as I want.  Okay.  Thanks.  Nothing after me.  Good.  Okay.  So we'll see.  So ground goes to ground.  So now I'm just arbitrarily plugging stuff in.  I'm going to do it on this connector.  Ground goes to ground.  Now I'm just plugging in.  I don't care which pins they go to.  So I'm just plugging in.  On here.  So channel 0 through 3.  All right, let's see if I get lucky.  Who knows.  If not, I'll have to reboot.  Reboot the JTAGulator.  How lame is that?  Okay.  Target voltage set.  Identify pinouts.  Four pins.  Okay.  Reset.  Type 30.  That's fine.  It will go to 3.0.  That's the easy way to do it.  Yeah.  Okay.  So a bug in the firmware.  Great.  When you go from UART mode to JTAG mode.  Anyway, I'll fix that.  Now we have a response.  We have TDI we don't know.  TDO is pin 3.  TCK is pin 2.  TMS is pin 1.  So let's go ahead and try to find TDI.  We're going to do four channels again.  24 permutations.  Takes a little bit slightly longer.  One device detected and there's our JTAG pinout.  Enjoy.  You can clap.  Okay.  So now what we can do is now that we know that pinout, what was it?  I forget.  03210321.  Oops.  I messed that up.  Okay.  Yeah.  So ID code we only need the three.  So we need 321321.  One device in the chain.  Our ID code that 01C06 whatever.  It corresponds to this free scale part.  You can look it up.  And then let's do the final one which is the testing bypass.  So that's 0321.  One device in the chain.  And then pattern in matches the pattern out.  So there we go.  Now we're pretty sure we can do it again and get a different pattern.  So yeah.  Now we know that's the JTAG interface.  Now we can go and hack with it.  So that's our demo.  Okay.  So like everything there's limitations to the tool.  Like having to press reset.  The first thing you could possibly cause the target to do some sort of unintended thing  as you're like fuzzing all these test points that you don't know what they are.  But that's somewhat of a limitation but also it could be useful if you're hacking on a  device and you don't know.  If you somehow cause it to like do something unintended that might be useful.  Maybe the OCD interface isn't enabled.  Maybe it's some sort of if it's password protection or if it requires some sort of  reset sequence we might not be able to detect it.  Vendors try to be sneaky by cutting traces.  Leaving out jumpers on connections to try to prevent somebody from using it.  So we'd have to do a little more reverse engineering to find that first.  Maybe there just is no on-chip debug interface.  Future work we want to add all sorts of support for other stuff which hopefully will happen  as needed.  As somebody says I need to spy by wire on ti.  Then I can write a module.  There's lots of possibilities for this type of tool.  It's basically like a general purpose propeller development tool with lots of I.O.  That you can do for stuff.  We do have a few more available at the hacker warehouse at the Defcon vendor area.  All the stuff is available on jtagulator.com which goes to my website.  Powerlax is selling assembled units and bare boards and if they run out of stock they're  going to make more so you'll be able to get it.  Okay so final thing I've been dying to read this poem that I went up to this guy that just  writes random poems in San Francisco.  I said I developed a tool called the jtagulator and explained what it was and he looked at  me for a second and then he wrote this poem.  Maybe you can make some sense of it but I'll just read it.  To take an object from made to modified, customize interfaces between past and few truths can  maintain their veneer in the face of signal feedbacks, size of diamond screwdriver doesn't  fit circuit, exit, enter the drag net on all sides, caught with tools that are not  on all sides, debugging as form of how to gain access to what you have but can't quite double  blind verify, ascertain, make salient discoveries about how electricity keeps its secrets from  anything that's not luckily everything electric is jtagulator.  Take apart a ball of and find particles that can't be broken into.  So there we go, the end.  Thank you.
DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_0_1679.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_1680_3455.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_3456_3995.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_3996_4991.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_4992_6623.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_6624_7403.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_7404_9131.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_9132_10967.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_10968_11555.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_11556_12671.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_12672_13703.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_13704_14819.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_14820_16955.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_16956_17243.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_17244_19067.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_19068_20291.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_20292_23495.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_23496_24239.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_24240_25475.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_25476_26531.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_26532_29123.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_29124_29387.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_29388_29711.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_29712_30779.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_30780_31343.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_31344_32027.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_32028_32135.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_32136_33383.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_33384_34511.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_34512_35375.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_35376_37367.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_37368_38387.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_38388_39575.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_39576_40907.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_40908_41735.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_41736_42779.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_42780_43223.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_43224_44855.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_44856_45887.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_45888_47159.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_47160_48071.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_48072_48575.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_48576_49847.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_49848_50063.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_50064_51155.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_51156_51815.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_51816_53279.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_53280_53567.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_53568_53723.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_53724_53855.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_53856_53903.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_53904_55439.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_55440_56651.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_56652_56831.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_56832_56903.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_56904_56963.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_56964_57431.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_57432_57491.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_57492_57551.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_57552_57623.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_57624_57971.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_57972_58103.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_58104_58151.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_58152_58811.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_58812_58871.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_58872_59147.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_59148_60803.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_60804_61163.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_61164_61751.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_61752_61811.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_61812_64151.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_64152_64703.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_64704_65159.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_65160_66467.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_66468_66515.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_66516_67751.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_67752_68387.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_68388_68855.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_68856_70427.png DEF_CON_21_-_Joe_Grand_-_JTAGulator_Assisted_Discovery_Of_On_Chip_Debug_-3zWnIupqYM_70428_70632.png