 So we'll start off today with some introductory rights. You'll kind of get, there's a little bit of a theme to today's talk. First let's introduce our clergy. There's me. I'm Joe Fitzpatrick. I have an electrical engineering ‑‑ sorry. I have an electrical engineering education with a focus on computer science and information security. Ten years spending time doing hardware debug, security hardware, stuff. And right now I spend my time teaching classes on low‑level physical attacks on systems. I actually work ‑‑ a new class coming up applied physical attacks on X86 systems, which should be lots of fun, too. I also didn't sleep last night trying to get this demo working. So actually, I was drinking most of the time and at the very end I tried to get the demo working. So there's also Matt. I'm Matt. I was going to say I started out as a hardware engineer so I spent a lot of time working on JTAG stuff. I've designed a few of these, unfortunately. So I've been dealing with this for a very long time. Can you ‑‑ okay, there we go. I just wasn't close enough. I'm Matt. I have spent a lot of time designing and building and testing with JTAG. So I'm sure there's more than one person in the audience who's using some of my JTAG. I'm really disappointed with the transcription of Joe's mumbling before they just said blah, blah, blah. They didn't get it. Yeah, so really, like, Matt did all the work for this talk. So we should give him applause when he does stuff. Don't applaud for me at all, okay? So the NSA play set, many of you are familiar with it already. Basically, you go to the website, nsplayset.org. You have a whole bunch of these little projects that we're making. Basically, there was an ant catalog that was leaked and we've been re‑implementing a lot of these things in open source hardware and software. The idea is if the NSA can do it, why can't we, right? Just to say, you know, there's going to be a few of the toys, not this one, but some of the other toys for sale at the hacker warehouse in the vendor area tomorrow on Sunday. Tomorrow Sunday, right? If I don't count the days that I didn't sleep this week, I think it's still, like, Wednesday for me. So let's start off. This is a page. This is Godsearch. You're probably not going to get fired for looking at this page. This is a leak classified document, though. So basically Godsearch, which I hope you can see it because I can't really see it. Godsearch runs on the FluxBabbit hardware implant. It provides software application persistence on Dell PowerEdge servers by exploiting the JTAG debugging interface of the server's processors. It sounds like lots of fun, doesn't it? JTAG never sounds like fun, especially when you're doing it, but this makes it sound like fun, okay? So we'd like to tell you a little bit more about Godsearch and what our take on Godsearch. And so we'll start out with the liturgy of the D word. Let's talk about JTAG. All right, so JTAG was originally developed. There was a big committee. This was back in the 80s when they were working on this. And the idea was really the joint test action group. They got together. They needed a standard for hardware to do testing of integrated circuits. So if you want to build a chip and then you want to build something with a bunch of chips on it, you need to be able to test it to make sure it works before you sell it to somebody. People really don't like buying stuff that doesn't work from you. And so the goal of this was to come up with a standard so that all these chips, they could use the same test interface. You could test all of them at once and actually not have to hook up different devices to different chips on your computer to make sure it all worked. Because developing software is hard, might as well change the hardware. That'll be easier. You're laughing. I'm not kidding. Where are my speaker notes? It's this button. And it disappears. There we go. We have a passage from the... We need to read it verbatim. I've got a passage to read from the... This is the IEEE 1149 spec that defines the JTAG interface. So section 1.2.4, the use of this spec to achieve other test goals. In addition to its application in testing printed circuit assemblies and other products containing multiple components, the test logic defined by this standard can be used to provide access to a wide range of design for test features built into the components themselves. Such features might include internal scan paths, self-test functions, or other support functions. Design for test features such as these can be accessed and controlled using the data path between the serial test pins of the TAP defined by this standard. Instructions that cause internal reconfiguration of the components system logic such that the test operation is enabled may be shifted into the component through the TAP. That's pretty insightful. Wow. Thank you. This is the most interesting part of the spec, too. Good thing we've got 50 minutes, though. Go ahead. Okay. So what is this? So hopefully people are familiar with the OSI model. It defines a physical interface and application interface. How do you actually communicate using this protocol? So we've tried to actually map how JTAG works to provide a frame of reference for people who do software and who actually want to use this for something interesting and who aren't really concerned with all the fancy electrical interface. And if you're trying to do debug, you don't care so much about the hardware side of this. You just want to know how to use it to do your debug. So at the physical level, we have five wires. Data in, data out, mode select, clock and reset. And they have to put test in front of all of these because it's a test interface. So what does that look like? You really, you know, if you have a JTAG header on your device, you're going to have these five pins, probably a ground, too. And then you're going to have components on your PCB connected. And you're going to chain them together. You're going to take the data out from each one, connect it to the data in of the next one and just create longer and longer serial scan chain. And so when you put data in, data out, it ends up flowing all through all of your devices, comes out the other end and you can read it back out. And this gives you access to a wide range of internal registers that they build inside these things with a lot, really low overhead. The control logic for this is really small. And so this gets used for a lot of things because the odds are this will always work. Even if you build a chip and it doesn't come out and something's not working right on it, probably your tap will work. And you can get at whatever registers you put in there and you can test it and debug it and figure out and make sure it works before you sell it. So this is kind of what I would refer to as like the golden rule of JTAG, right? And that is TDO unto others as others TDI unto you. Okay. Think about that. So if you want to go back a slide, basically we have this circle of every interconnected device and the only way that this circle works is if you pay it forward, right? If you pass on the TDI that you have received to the next device was your TDO and you pass it on and pass it on. So there's a lot of deep inner messages that we can extract from this JTAG stuff, really I swear. I'm not responsible for the puns in this. Okay, so we've got five wires. What do we put on them? Right? So there is a state machine defined. It uses the mode select signal to control what is actually happening with the TDI and the TDO signals at any given time. And there's this state machine. There's a bunch of states in there. Most of it is just to deal with all sorts of limitations on either the device you're using or the device that's driving JTAG. So there's a lot of redundancy in here. You know, this is sort of the old, this is the complicated, this is what they put in the original spec. So the newer simplified version, if you really just want to think about what's going on here, you're either writing an instruction or you're reading writing data. So you're either sitting in idle waiting for a new command from whatever is driving your TAP interface or you're writing an instruction, new instruction and that determines what data you're going to read and write. So this is really what the state machine is trying to get you to is, you know, how do you access these registers? Okay, so we can use the state machine. We can get to this instruction and the data register. How does that look actually in the system? And it's really, it's a pretty simple picture, right? You write the instruction register and that selects one of the data registers in the system for you to read and write. Most of these data registers, there are a couple that are required. Bypasses are required. One, most things will implement the ID code register that lets you identify the device, but almost all the rest of these. If you have an 8-bit instruction, you can have up to 255 other registers in here for test purposes. They can be anything, right? It's whatever the manufacturer of the device put in there to test it. So they can have access to the external pins. It's called boundary scan. They can have access to internal state. They can have, you know, special commands. They can send to a microcontroller to control how it's executing. This is all really, really device specific. It's whatever they implemented. But from the point of view of a person using it, you're just sort of, you know, you're picking which register you want to access and then you're either putting data in or reading it out and you're either going to get status information or you're going to have control information that you can put into the device. So once we've kind of built up that lower level of those physical layers, right, we need to move on, you know, get ourselves up higher in the stack and we move more into the host layers of this, you know, if it were an OSI network type situation. This is where we might find some very target specific stuff. So this one table is an excerpt from a spec for a CPU. And basically what you can see on it is it tells you that you have a couple different instruction registers and they have a number associated with them and they have a purpose, you know, a brief description. You know, we look right down, we have 0x01, right, that's ID code. This is just a number that it spits out that identifies the part. So we know we're talking to a CPU, a network adapter, a, you know, this model arm core, stuff like that. Further down below you see in this one it says address. It's very hard. I have a very narrow range to point. Address and data and control. And basically these are three registers. We stuff stuff in there and that's going to give us access to the internal bus of the system. It's going to let us pull stuff out of memory. It's going to let us, you know, interface with the hardware we are hooked up to. But this is, you know, this is nice. These aren't the rules, though, right? This is all fitting into the JTAG umbrella. And this is just MIPS. That's part of the EJTAG spec which applies to most current MIPS platforms. And it's not going to be like that for everybody else, right? Different architectures will define their different custom IRs and DRs in order to debug their chips. So it's different for X86. It's different for ARM. It's different for different versions of different chips. So like an ARM V7 core by this manufacturer might be different from the one from that manufacturer. Sometimes you're lucky and there's some similarity. But, you know, when we get to this point where we're no longer talking about stuff that's like really JTAG spec stuff. We're at the point where we're talking about stuff that's the implementation of their debug interface over JTAG. And, you know, we got to have a verse to relate to this. Romans 12.2. Do not conform to the pattern of this world. And, you know, some people take this to heart. Really, this is the NIV version of the Bible, but really maybe we should just call it the NIH version. So just remember that verse. Maybe like write it in your cube or something. That way you can remember it when you need to, just no, do not conform. So let's keep moving up the stack, though. Here we have back to the OSI model. JTAG's session. Wait. Okay. Well, who has like written stuff like with that Steven's networking book or something like that, you know, like actually written the network application, right? Who's written stuff that uses the presentation layer? Anybody? See, what I was going to say is like raise your hand if you've written something with the presentation layer. Okay. Put your hand down if it was an academic assignment. And say, oh, see, nobody, but maybe academia is catching up. Nobody uses this crap, okay? So, yeah. Let's move on. We've got a second reading. This is a reading from the second e-mail from Joe to people with JTAG questions. And Joe, tell me what is JTAG for? I understand all these wires and we hook things up and we have these registers, but what can I do with it? What's the power of understanding this great information? When we go up the stack, we get to what probably relates to an application layer. We have boundary scan, run control and memory access. And these are all really fun things sometimes. So some of these things, some of these features are mandatory, which means if you have JTAG, you must have this. Some of these things are optional, which means that some manufacturers choose to implement that and some don't. Some of them are undocumented, which means the manufacturer implements them and doesn't tell you. So let's talk about boundary scan. What we've got is the same picture we saw before. Remember the golden rule? What is it? Okay. Good, good, good. I think a few of you remembered it. Just got to keep it in your mind. So what we have is we have data in and it kind of goes through these streams, hops through these boxes. We have a bunch of ones and zeros. And this is JTAG. It's one wire. We can send one bit at a time. Okay. And we send those bits through and all the way on that third chip over there, we have some traces on the motherboard that hook it up to, I don't know, a bunch of LEDs or like some other device. And what we're going to do is we're going to animate this slide. Ready? Oh, yeah. Oh, yeah, watch it go. There we go. Thank you Matt for maniating that because like I said, Matt did all the real work for this. I just made the puns. So what we're doing is we're basically modifying what the output pins of this device are. This scan chain, this boundary scan chain goes through all the external pins of the device and we can stimulate them or we can sense them. We can send data out, we can send data in. And this is really useful if you're testing a board. If you solder a BGA part on that has like 10 billion pins onto a board and you want to make sure all those pins are connected well, you can't get in there with a soldering iron and maybe you could get an X-ray machine and look through. But if you use boundary scan you can just twiddle all those pins and look for the outputs on the other end and you'll know not only that your pins are wired together, your chip is driving properly but you'll also know that your trace is going through and connecting to the other end properly. So this is really powerful for test. But again, test is one thing, you know, hacking things is even more fun. So we can have a scenario like this where you have an SOC that's connected to flash, right? And if you use boundary scan, boundary scan is a required feature of JTAG. Basically any JTAG device is supposed to have JTAG, supposed to have boundary scan. So if you can take the time to like sit there with a multimeter or a logic analyzer or something and just spit ones out of these boundary scan pins, you should be able to map out which bit of your data register corresponds to which output pin you have your part. And the result of that is you can figure out which pins connect to your flash chip. So instead of having to solder on like 20 wires to hook up to a flash chip, you can just write some software that will shift all these bits in and read and write your flash for you. You just have to set the right bits at the right time, wait a cycle, set different bits, wait a cycle. But it's kind of slow because, you know, it's JTAG, it's old school stuff, it's one bit at a time and you have to send in one bit at a time for every pin on the entire package, every single half cycle, every single bus access. So it takes a long time. But it's pretty cool, you can actually do quite a bit of stuff with this. The next pretty neat feature of JTAG is run control. So basically when you've got, you know, when your program is running, it's running, you know, run, run, run, run, run, run, run, run. But at some point in time, you want to debug it, you want to halt, okay? Stop control. What's great about this is this is the point in time where we can do all the neat stuff. We can modify registers, we can read from memory right to memory. When we're done, go back to running, right? Run, run, run, run, run, run. And then halt, okay. Let's check the contents of memory, like, oh, what do we put in there? Let's see. Oh, let's modify some code and let's make something not behave properly. We'll change where he runs. And actually that'd be cool if we like put a glitch in like a slide or something, but we didn't do that. But yeah, you run again and run control, run and stop. Anything to add Matt? So the run control is really, really processor specific. Everybody's going to implement this differently, but I have never seen any kind of CPU microcontroller, any type of general purpose processing element that does not implement at least a rudimentary form of run control. Because otherwise that's how you debug your firmware, right? If you don't have a kernel mode debugger and you don't have JTAG, you're basically debugging it. So this is how you debug your firmware on pretty much everything, right? At least until you get to the point where you have your OS running and you can do something in software. Okay. So let's move on. It's time for the Gospel. I've selected a reading from the International Journal. As exploits sit lonely forgotten on the shelf, your friendly neighbors at POC or GTFO proudly present Pastor Menel Glelfrags expert control church . So I have a reading a little excerpt from a rant or a sacramental wine about wasanar. So heretics as we are, we turn our baleful and an envious eye towards the hallowed halls of science. Behold, there are a number of people under a curious spell. They must talk of things that are not yet known to the multitudes. That which we call zero day. Or they will not be listened to by their neighbors. Indeed, what we call a zero day, they call a discovery or a publication. It's weird how advancement among them is meant to be predicted on the number of these zero day results they can discover and publish. And they are free to pursue discovery for either public and private ends after a few distinguished zero days are published and noted. What a happy idyllic picture it might or might not have been helped by the fact that those sovereigns who went after the families by other sovereigns who had the fancy to leave them alone and to occasionally listen to their babbling. But neighbors, this lesson took centuries. And anyway, do we not have any goddamn robes? So, of course, you know, we need to move on to a little homily. Which, you know, this is a pretty old writing. It's thousands of hours old. And we need to relate it to the current day and what we're talking about. What are we talking about? JTAG. So, who knows about Wassonar? Okay. Really, I should spend more time talking about it, but I'm not going to. You should read about it and be concerned about it. So, Wassonar regulates exploits and inadvertently regulates a lot of other things. And we can relate this to the fact that in some cases this is going to get the tools used to test and debug and do security testing. And if we go even further like, well, what are we doing? What is JTAG for in the beginning? What is JTAG? It's a test interface, right? Because in the beginning, all this functionality is created with an intended purpose. Well, sometimes it's not intended, but it's created with a purpose and sometimes there are unintended consequences. And it's really out of morality and choice that we have to decide whether to use JTAG for debug or for exploitation. So, you know, think about that. How do we... You want BGA? Yeah. So, you know, how can we do this? We've talked about ways we can use boundary scan to control all the IOs on the board. We've talked about ways to give boundary scan to talk to flash chips and modify their contents, right? You could have a locked this or a locked that, a locked boot loader but if you can use run control to halt your processor and modify a binary in memory that has already been...signature has already been checked, you've just won. Yahoo! So, let's start off with a little demonstration in this vein. You have... I can't really tell if you guys can see this or not, but I can. Invert the colors. Invert the colors. Oh. How do I invert the colors? References. There we go. Style. Oh, actually it's just the... Where? Yeah. Yeah, just essentially separate. I thought they were... They were white. Oh. No, that didn't work. That was opacity. Oh! Yeah. There we go. F, yeah. Maybe I can help. Yay! That concludes our demo. Alright, so... This is the place dinner. Okay. Well, so... Does everybody know what's going on here? I swear. In the last track, I asked that question. It was one of the really huge tracks. One guy goes, nope. So we actually brought him up on stage. Just remember that next time. Just remember that next time. Anyway, so... So even though there was a little bit of slow down there, are these guys doing a good job? Awesome. Cheers. Yeah, I haven't been drinking for 12 hours. Well, now everything's going to work. Now everything's going to work, yeah. And if it doesn't, we know who's fault it is. Right. Okay, so on the right-hand side, this is our little target platform. We've got JTAG plugged into it. I've got a shell. It's not terribly interesting. So we're just going to... Crunchy shell or soft shell? Never. I told you I'm not responsible for the puns. So over here, we are going to open up our JTAG debug program. And... There we go. So then we should be able to connect to it. And we can see... Hey, look, we're connected to something. Right, so we have an SOC tap and we have a X86 Quark core tap. And our target over here, it's still running. And we can do a halt. And it stops running. So then we can do things like display the registers. It'll show us the contents of all the registers. We can... We can dump memory. So here's the beginning of the Linux kernel memory. We can dump some more memory. This is the instruction that controls return code for file system access control. We'll come back to that. Dun dun dun. So we can skip. We looked at things. We can resume. Target should... This is where you start getting into the fun part of all the target specific stuff and how they implement things differently. Some of the actions don't take effect. Sometimes you have to keep driving the JTAG pins a little more. So if you do the command, you have to actually keep using JTAG more before it takes effect. There's all sorts of fun. If we can get the demo working on... We've got another target here. If we can get the demo working on that, there's some other quirks that have to do with that. So we can even... We can open up. So you can also... Open up. And you can debug your Linux kernel in GDB. So we're going to connect to our JTAG. It connected. We're going to halt our target. We're going to load our symbol file. And then we can step through instructions. So every time I do a step by, the target executes one instruction showing us where that is. So... If you have an application, if you're trying to get your real-time OS running on this thing and you need to figure out where it dies, this is how you can connect to it. You can watch it. You can go through all the instructions. You can see what's going on at each point in its execution. And do your debug, whatever you need. Do you need the cable back now? Here's the cable back. Oh. Okay. So we can do debug. We can read and write memory. I'm sure you can all think of lots of fun things to do if you can read and write kernel memory. We have one example. But how do you actually use that? If you want to... When Joe was talking about the ant catalog, they actually had an implant. They stuck it into a server. They left it there and it constantly updated the software running on that server. So when you replay your JTAG commands, there's helpfully several formats for doing this. You know, this is the whole point of it is industry standard format. And there are plenty of tools that will play back serial vector files or the Xilinx version of them that's binary compressed version. And so we were able to generate, you know, from our open-op CDD debug, we captured the commands that we were issuing over JTAG in the log file. We went through them and we transformed them into a serial vector format. And then you can play them back on any device that plays JTAG, right? So pretty much anything that can play this format, which is the standard format for capturing JTAG commands. This is used on everything from, you know, $10 million test equipment to $15 little JTAG adapters like we have with open-source software. And, you know, whatever device you have, you can play back this captured trace and it will, you know, issue the JTAG commands to whatever device it's plugged into and, you know, whatever those commands do, it'll do them. So, you know, in our case, if we want to go write memory, we capture our sequence of commands that writes a memory address, program it into the device, plug it in, and then it will go continually just write that memory address that we had set up. So Joe is going to tell us about the implant that does this. So, I present to you the solder peak, which luckily we have enough to share, right? We're going to break boards together and have some PCBs. So solder peak is basically a tiny little board. It's actually like Arduino compatible just because Arduino is really easy to get working, especially when we're doing stuff like for the play set that we want to be really accessible. It's got a little 18 mega processor on it. It's got a UART interface, a serial port, which is how normally, sorry, this is actually based upon an existing project called JTAG Whisperer. It's an Arduino sketch that gives you UART access to JTAG. So what I've done is I took a board and I added a little EEPROM to it, an I2C EEPROM, so we can set it up so we can actually store this SVF and have this thing be standalone and plug it into a system, walk away, and every time it boots away a little while, and then it'll start playing back its XSVF file, right? So this XSVF file is going to hold the contents to go and patch something nasty in memory. Of course, like I said, Matt did all the work. I was supposed to get this working, but it's not actually working right now. It's kind of dead, but it's okay. I swear that in three days the code will be uploaded to GitHub and it will all work. So Flash it, run the code. That will basically transfer the F file to it, stores it in the EEPROM, and then next time it powers up it waits 20 seconds and then dumps its payload, essentially. And again, transubstitiation happens with the Arduino IDE. And that kind of brings us right to the next part of our presentation where we need some volunteers to come up. We're going to distribute some boards. So come on. And of course, you know, it's the NSA play set, so they need hats, too. Well, I mean, so it's massively need hats, but it's the NSA play set, so they're tinfoil hats. And so you got the PCBs. So you got the PCBs. Two of you got boxes of wine and two of you got cups. And you just want to spread the good word. So we'll continue with demos. You need to do the screen. Do you want to do the video demo or do you want to do it live? We can do it live. Okay. All right, we didn't even screw up the colors. Hey, keep it down. So what we're going to do since the board that I have right here is having some growing pains, we'll demonstrate it with just a standard JTAG adapter hooked up to, are you going to use the, what do we know, the Galileo? We've got the Galileo right now. I'm going to try, if we have time I can do it with the arm also. So what we've got here, we're just going to play back the same JTAG chain command that we would on the Sutter peak implant. We're just doing it through a JTAG adapter and letting the laptop drive it instead of the stand alone device. The stand alone device, it should do something and it doesn't. Yeah, so the stand alone device is actually doing something. It's getting TDO out properly. Get out makes absolutely no sense. And so we just need to figure that out. I need to figure that out. All right, so I am logging in here. I have a super secure password and you can see that. All right. So you can see I'm just a regular user. I don't have access to things that are owned by root. So now I'm going to go over here and we're going to launch the debugger again. I'm going to go in here and I'm going to find my command line. And this is our sequence of commands. So what we're doing here, that the bytes I showed you in memory before that I said were the ACL return code for the file system permission check, we're going to change those. Oh, no. It didn't work. Oh boo. We're going to reboot it and try again. Do you explain what you're patching? Yeah. I know what the problem is. What? I didn't take a drink this time. Okay. Sometimes this stuff works without drinking. You don't actually need to drink to do hardware hacking. Wait. Since when? But why else do it? Yeah. My drinking space has a hardware problem. And also the bars kind of look funny when you bring laptops and cables and wires and hook things up. But it's Portland, so everybody's kind of weird. Just tell them it's a board game. And I was like, oh, okay. You must just be hipsters. So Matt had all this done and he showed it to me two weeks ago and I said, Matt, we still got two weeks. This is when we started. I didn't know you did the whole thing. I took a video when he did that. Yeah. This worked every time I did it for the last week. Except the times I was nearby. Talk to it. Okay. So we've got the same setup that we've got here with the JTAG adapter plugged into the laptop hooked up to the Galileo. And I cannot see the video at all. I'm typing in my real, it's in case anyone was curious. I changed my luggage from password. So you can see I don't have access to the shadow password file. So now I'm going over and I'm doing the same command here that I just tried and it worked eventually. And now you can see that I was able to get access to the password. How many bytes did you write? In memory there was a return code that was access denied and we changed it so it doesn't ever return access denied anymore. And the SVF when we got it down was just a couple K? It was less than a K after we cut it down. It was a couple hundred instructions in the file though. Writing four bytes in memory took I want to say it was like 200 or 300 actual commands in the SVF file. The first iteration when I just did a diff and generated a patch the SVF came out to like 500 K. So I put a little work into optimizing the write. So I was going to say and it can take a while to it can take a while to do that. As you can see it's not 100% reliable. We can put a little more work into getting it more reliable. But we got our demo. Yeah. I got a drink on stage. So you want to talk to me? Oh. So the point here is that everything you saw is working as intended. The JTAG is there because you don't buy a working laptop if you can't do all this over JTAG. You need this to build something but this is not software. You can't turn off debug flags and have it be compiled out of the binary. This is going in hardware. You can't take it out. So we need it in the hardware to make sure your hardware works before we sell it to you but it stays in the hardware. So really in cases like this this is an embedded platform. This is designed to be used by people. JTAG is enabled intentionally on purpose because they're expecting people to need and want to use it. As the NSA did you can plug this in. You can do this on pretty much anything. Almost everything's got this in there. As long as you have patience. As long as you have patience and potentially money to spend reverse engineering it. If you are building something you need to give it's not just about selling it to the OEM and letting the OEM build it because eventually the user has to be able to use this without my phone or my laptop to be able to do this. So you need to be able ideally the user would have some say in this and some of the newer things actually do give either the BIOS or the root user control over whether or not JTAG gets turned on and this functionality is enabled which is a very good thing because that means that somebody can't pick up your laptop, walk away with it plug something simple into it for $15. How much are these? The adapters? Those are the Adafruit FT232H chips that are $15. So you can't plug a $15 JTAG adapter into it and get full access to everything on it because we're patching memory. It doesn't matter if you've got this encryption it doesn't matter what you're running. We plug this in and we get full access to everything the OS has. Hopefully we can get to the point where it does require user involvement to actually turn some of this on because otherwise the old assumption that just don't let me walk up and plug my JTAG adapter into your system works when you have your system stays behind a locked door but not everything is behind a locked door anymore. That is it. Thank you.