 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 yeah, I guess I've been on TV a long time ago. Rich and 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've got guys like Charlie Miller and Chris Valasek hacking cars. Those are traditionally software guys. You have lots of other people starting to look at embedded systems in 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 RS232 Enum. And these were better than the original proof of concept, but they were missing key features. He was using 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 CyberfastTrack, which is a really cool program, I had submitted. So once I did all this research, I wrote like this whole proposal for CyberfastTrack. I was like, this is awesome. All my friends are doing CFT. I want to do CFT and get paid to develop JTAGular, like 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 wrote 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, or 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, okay, that's an I2C interface, interchip 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. So 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, okay, 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 silkscreen 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, you know, 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. It gets a little bit harder if there's no, you know, obvious markings, but in this case, we can 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. We 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, okay, 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, right? So they have these unpopulated R24, R29, 315, 316. So 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 those, what that pinout is, then you win. It's not gonna 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, right? So you look at a grouping like that, grouping of black braid pins, you're like, okay, crap, what am I gonna 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 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 gonna 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 know, you don't really have one at your house, I hope. Yeah, some people do. I'm not gonna ask for what. And then you can identify the parts that are the target components, look up the datasheet, 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 gonna go into some details of JTAG and of UART, of asynchronous serial communication, just to get an idea of how all the kind of 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 like this low level finite state machine and like 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 wanna communicate directly with the chip to figure out the pin out, right? That's the only goal. So the beauty of JTAG is 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 like flash updates through JTAG port on a 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 like 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 like 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 pin out, 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 like a tiny little CPU that you can just send like 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 eight bit instruction or 16 bit instruction. And then for data registers you have a bypass register which we're gonna 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 gonna 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 gonna 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 it 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 JTAG 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 IO pins. That's the boundary scan cell. So that will control inputs and outputs which is totally crazy to just be able to control a chip like that. It's really cool. Then you have your data register and instruction register and depending on what you shift in and depending on what state you're in defines which register is gonna be shifted out on the TDO line. So here's the tab 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 the 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 gonna 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. Right? That's pretty safe to say. Especially at DEFCON. 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 gonna 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, right? 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 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 gonna send data to the device and then we're gonna 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 botter rate. So say you do discover the interface but the botter 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 botter 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 wanna 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 and 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 gonna 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 Digi-Key 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 gonna let Parallax do it from now on. So the block diagram is we have a propeller, Parallax propeller device in the center, which is a great tool for hacking with, as you'll see. We have a standard FTDI FT-232 USB serial interface. That's gonna power the device and that's gonna provide power through USB and also provide our programming interface and our command interface. I'm using a D to A, I'm actually 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 like 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 a basic setup and so there's 24 channels either through screw terminals or through the two by five 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 kind of 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 gonna build my own. So it's a great hacker tool. It has eight independent cores which are called COGS and sort of 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, DEF CON 20, right? You guys have DEF CON 20 badges? Yeah, okay. 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 and 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 Parallax has the object exchange where you can grab things. It's like, oh, I wanna do a D to A, grab that code. I wanna do debug interface through serial, grab that. And you can put stuff up there as well. So it's 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 loaders and ROM and then each cog has 2K. So it's just, yeah, 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 virtual C report, you can start communicating with JTagulator. I have a MIC 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, you're 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, okay, you're enumerated, you're ready to go, then we enable the rest of the system. That's the 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 gonna 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 AD8065 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 wanna 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 gonna 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 gonna 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 gonna need to change. Maybe we wanna 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, you know, C files or H 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, you know, pop that into whatever cog I want. And that's gonna be the interface that's doing the UART detection. So for actual functionality, I'll go through a few of the, I'll go through 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 gonna 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 gonna come out on the TDO line. We don't need to send any data in. So that's gonna 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 gonna define the entire internal structure of the part. You can find a lot of that stuff like 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, okay, 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 gonna ask for the number of channels to use, and then for every possible pin permutation, it's just gonna go through, try to get the device ID, if it reads all ones, or if the final, if bit zero is not one, then we're gonna ignore it. But if we get something with a bit zero of, if we get, 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 you're not gonna get lots of, hopefully you're not gonna 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, right? Because it's sort of a black box. So we just send in a shitload of ones and kind of 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 to 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, okay, 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, so you can actually send any outputs string you want. So normally, if you connect up to an interface, you'd hit carriage return to see if you get a response with old, if you want to hang up on a modem or whatever you do plus, plus, plus, or whatever you wanna do, maybe escape key, you can tell JTAGulator what user string you wanna send out on, what it thinks is the TX line, and then it's gonna look on the RX line to see if it gets anything back. So it's gonna 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 gonna move on to the next thing, and 20 milliseconds is pretty long in computer time anyway. If there is a valid response, it's gonna 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. If it's 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, so it just happens to be 13.37 permutations. It's totally leap. And you can see like, you know, most of the time it's like, you know, 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 UART ends up being 24 bot rates per permutation, so it ends up being about one permutation a second. 10 minutes for 24 channels. Here's some demos. Let's see, let me bring up my cool term, which is what I'm using on my Mac. How's that look up there? Is that nice and big? Good, okay. So let's see, I'm already connected. So I have my JTAGulator plugged in through mini USB, 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 gonna 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 two that has DDWRT on it already. So I just have a bunch of these like little individual female to 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. 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 as 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 a UART there because I tested it, but I don't know which pin is which. So four channels, it's gonna be 12 possible permutations, reminds you use channel zero through three and we'll hit space bar to JTAGulate. Hopefully something will come up. Okay, so a bunch of stuff came up. See if there's anything else. Okay, UART scan complete. So a bunch of stuff came up. You can see the TX and RX lines are all the same, one and three. That's a good sign. That means something's there. That means when we send a carriage return on pin one on channel one, we're getting a response on channel three. But the JTAGulator can't figure out what the data is because it doesn't know what the data should be. Right, if we have some interface, maybe it is 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, okay, 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 zero D, 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 gonna do this one. Okay, so remember, it's transmit is pin one, receive is pin three, and it's 115.2K. So now what we can do, we think we know the UART. Now we can do a pass through mode where we can say TX is pin one, RX is pin three, border eight, 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 and here, yeah, thanks. 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. Okay, so I'm gonna disconnect. Oh, and you know what I'm gonna do first? Disconnect target voltage, set it back to zero so I don't fry anything as I'm taking these off. Take off all these pins. And now we'll do the JTAG detection. I'll do it with the DEF CON 17 badge. You guys remember that? Yeah, like two people. Okay, great. That's good enough. Okay, three people. Okay, so the DEF CON 17 badge had a free scale MC56F8006 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 badge hacking 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'm gonna 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. This is a three-volt system, target voltage is set. So now let's do the ID code scan first. That's gonna 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. Well, let's see, let's try bypass scan, screw it. Bypass 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? Too much demo, 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 gonna do it on this connector. Ground goes to ground. Now I'm just plugging in. I don't care which pins they go to on here. So channel zero through three. 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. Oh, did I 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, right? We have TDI, we don't know. TDO is pin three, TCK is pin two, TMS is pin one. So let's go ahead and try to find TDI. We're gonna do four channels again, 24 permutations. Takes a little 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? Zero, three, two, one. Zero, three, two, one. Oops, ah, I messed that up. Ugh, okay. Yeah, so ID code, we only need the three, so we need three, two, and one. Three, two, one, one device in the chain and there's our ID code that's zero, one, C, zero, six, 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 zero, three, two, one. 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 we 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 a 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, or maybe there just is no on-chip debug interface. Future work, we wanna 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, someone will write a module to do it. There's lots of possibilities for this type of tool. It's basically like a general purpose propeller development tool with lots of IO that you can do for stuff. We do have a few more available at the Hacker Warehouse at the DEF CON vendor area. All the stuff is available on jtagulator.com which goes to my website. Parallax is selling assembled units and bareboards and if they run out of stock, they're gonna make more so they'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 and 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 so I don't know, maybe you can make some sense of it but I'll just read it. Okay, let's see. 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 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.