NSA Playset: JTAG Implants
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 109 | |
| Author | ||
| License | 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. | |
| Identifiers | 10.5446/36379 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
DEF CON 2351 / 109
12
19
20
23
24
29
32
33
36
51
58
60
62
66
67
68
69
70
71
77
82
84
85
88
89
92
98
99
103
104
107
00:00
Non-standard analysisComputer hardwareInformationInformation securityStatistical hypothesis testingBefehlsprozessorSystem programmingRight angleBitWritingSystem programmingInformation securityComputer hardwareComputer sciencePhysicalismLevel (video gaming)Social classDemo (music)Multiplication signFocus (optics)Food energy
00:52
ComputerStatistical hypothesis testingSystem on a chipFirmwareComputer hardwareMultiplication signBlogComputer engineering
01:41
Data centerHacker (term)AreaLibrary catalogHacker (term)Projective planeComputer hardwareOpen sourceAreaCountingSoftwareRight angle
02:18
Product (business)Computer hardwareInterface (computing)WordGodService (economics)SoftwareCartesian coordinate systemWeb pageBitFluxServer (computing)CoprocessorPower (physics)
03:03
Statistical hypothesis testingStandard deviationWordHookingStatistical hypothesis testingDigital electronicsComputer hardwareGroup actionComputerSoftwareInterface (computing)
04:20
Data modelStatistical hypothesis testingConnectivity (graph theory)Tap (transformer)Assembly languageStandard deviationSystem programmingOperator (mathematics)Cartesian coordinate systemLogicPersonal identification numberSerial portStatistical hypothesis testingDigital electronicsGoodness of fitAdditionMereologyInterface (computing)Sheaf (mathematics)Functional (mathematics)Range (statistics)Product (business)Right angleGame controllerPoint (geometry)Computer animation
05:51
Link (knot theory)Data modelUser interfaceComputer hardwareCartesian coordinate systemSelectivity (electronic)Right angleLevel (video gaming)SoftwareFrame problemStatistical hypothesis testingEndliche ModelltheorieCommunications protocolAsynchronous Transfer ModeInterface (computing)Statistical hypothesis testing
06:37
OSI modelStatistical hypothesis testingAsynchronous Transfer ModeConnectivity (graph theory)Game controllerOptical disc drivePersonal identification numberLogicCircleEmailOverhead (computing)Range (statistics)Slide ruleConnected spaceChainRight angleInterior (topology)Figurate numberMessage passing
08:19
Data modelTap (transformer)Finite-state machineLink (knot theory)Finite-state machineSelectivity (electronic)Asynchronous Transfer ModeMultiplication signLimit (category theory)QuicksortState of matterReading (process)Revision controlDatabase normalization
09:24
Data modelTap (transformer)Finite-state machineStatistical hypothesis testingNetzwerkschichtFinite-state machineSystem programmingStatistical hypothesis testingMicrocontrollerBoundary value problemCodeBitProxy serverInformationView (database)QuicksortPoint (geometry)Game controllerLatent heatState of matterRight anglePersonal identification number
10:40
Data modelFinite-state machineTap (transformer)TransportschichtLatent heatLevel (video gaming)Latent heatTable (information)Type theorySoftwareComputer hardwareBus (computing)Game controllerNumberArmBefehlsprozessorDifferent (Kate Ryan album)Range (statistics)MereologyRule of inferenceCodeEndliche ModelltheorieAddress spaceSystem programmingSemiconductor memoryDescriptive statisticsInterface (computing)Point (geometry)Set (mathematics)Core dumpRight angle
12:05
Table (information)Latent heatTransportschichtSystem on a chipArmPattern languageComputing platformOcean currentMereologyCubeArmOrder (biology)Computer architectureCore dumpRevision controlDifferent (Kate Ryan album)Similarity (geometry)Interface (computing)ImplementationPoint (geometry)Pattern languageInformation retrievalMoment (mathematics)Computer animation
13:16
Data modelTap (transformer)Finite-state machineHypermediaSoftwareWritingPresentation of a groupReading (process)Endliche ModelltheorieRight angleCartesian coordinate system
13:53
EmailLink (knot theory)Control flowBoundary value problemRead-only memoryData modelFinite-state machineTap (transformer)Asynchronous Transfer ModeReading (process)EmailStaff (military)Power (physics)InformationHooking2 (number)Cartesian coordinate systemGame controllerBoundary value problemSemiconductor memory
14:47
Asynchronous Transfer ModeStatistical hypothesis testingBitPersonal identification numberStatistical hypothesis testingGoodness of fitFunction (mathematics)Virtual machineTracing (software)Proper mapBoundary value problemMereologyWhiteboard1 (number)Real numberMotherboardHookingChainRight angleSlide ruleCuboidStreaming media
16:34
Computer-generated imageryResultantBus (computing)MereologyMultiplication signGame controllerPersonal identification numberCycle (graph theory)BitCorrespondence (mathematics)Function (mathematics)Single-precision floating-point formatSoftwareBoundary value problemFlash memorySystem on a chipLogikanalysatorHookingLevel (video gaming)Figurate number
17:40
Control flowComputer programmingPoint (geometry)Multiplication signGame controllerSemiconductor memoryRepetitionRight angleMathematicsContent (media)CodeComputer animation
18:17
Control flowSlide ruleDifferent (Kate Ryan album)MicrocontrollerBefehlsprozessorRight angleCoprocessorDebuggerFirmwareSoftware bugKernel (computing)Operating systemElement (mathematics)Form (programming)Latent heatType theoryGame controllerProcess (computing)Multiplication signPoint (geometry)SoftwareAsynchronous Transfer Mode
19:06
Workstation <Musikinstrument>Moment (mathematics)Statistical hypothesis testingInformation securityMultiplication signGame controllerExpert systemStatistical hypothesis testingReading (process)NumberExploit (computer security)ResultantPeer-to-peerFunctional (mathematics)NewsletterCASE <Informatik>Axiom of choiceWritingPresentation of a group
21:56
Data centerGame controllerInverter (logic gate)Electronic signatureBoundary value problemBootingSemiconductor memoryContent (media)outputWhiteboardBinary codeSource code
22:43
Perfect groupDemo (music)Source code
23:28
Electronic program guideSymbol tableConnected spaceGastropod shellInterface (computing)Demo (music)Computing platformMereologyTap (transformer)CodeTrailContent (media)Real-time operating systemFile systemQuicksortKernel (computing)Point (geometry)Electronic visual displayMultiplication signGroup actionCore dumpComputer programmingLatent heatGame controllerProcess (computing)Time zoneLevel (video gaming)QuarkKey (cryptography)BitComputer fileSound effectRight angleSemiconductor memory
29:45
Analog-to-digital converterFile formatStandard deviationComputer wormKernel (computing)Server (computing)Revision controlPoint (geometry)Computer fileVector spaceFile formatSpeicheradresseSerial portComputer programmingSequenceOpen sourceKernel (computing)Adaptive behaviorStandard deviationSoftwareWritingStatistical hypothesis testingSemiconductor memoryLibrary catalogCASE <Informatik>Tracing (software)Open setComputer animation
31:39
Content (media)WhiteboardMultiplication signComputer fileSemiconductor memoryPatch (Unix)Projective planeInterface (computing)BootingSerial portControl flowRight angleVideoconferencingCodeCoprocessorSystem programming
33:07
2 (number)Multiplication signPower (physics)Computer fileData storage deviceComputer wormCodePresentation of a groupIntrusion detection systemMereologyTouchscreenDemo (music)Whiteboard
35:11
TrailDemo (music)VideoconferencingRight angleStandard deviationArmMultiplication signGraph coloringWhiteboardComputer animationSource code
36:04
System programmingPasswordRootProper mapLaptopComputer fileCodeChainRight angleHidden Markov modelStandard deviationDebuggerSequenceFile systemSource code
38:20
Computer hardwareRight angleSpacetimeVideoconferencingGame theoryWhiteboardLaptopHookingHacker (term)
39:36
Moving averageMultiplication signVideoconferencingAcoustic shadowPassword1 (number)Programmable read-only memoryCodePatch (Unix)CASE <Informatik>Computer fileSemiconductor memoryIterationType theoryLaptopDifferenz <Mathematik>Real numberComputer animationSource code
41:50
Information securityControl flowComputer hardwareSystem programmingComputer hardwareSemiconductor memoryReverse engineeringSoftwareGame controllerRight anglePoint (geometry)Computing platformLevel (video gaming)Chaos (cosmogony)Demo (music)EncryptionCASE <Informatik>MiniDiscFlagAdaptive behaviorPatch (Unix)LaptopFunctional (mathematics)WordRootFigurate numberBinary codeWritingComputer animation
Transcript: English(auto-generated)
00:00
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 education
00:21
with a focus on computer science and information security. Ten years spending time doing hardware debug, security hardware stuff. Right now I spend my time teaching classes on low level physical attacks on systems. I teach a new class coming up on x86 systems which should be lots of fun too. I also didn't sleep last night trying to get this
00:44
demo working. 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
01:01
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
01:23
with the transcription of Joe's mumbling. They just said blah, blah, blah. They didn't get it right. So really 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
01:42
NSA play set, many of you are familiar with it already. Basically you go to the website, NSAplayset.org, you have a whole bunch of these little projects that we're making. There was an ant catalog that was leaked and we've been reimplementing 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 so you know, there's going to be a few of
02:03
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 is 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
02:20
page, this is God surge. You're probably not going to get fired for looking at this page. This is a leaked classified document, though. So basically God surge, I hope you can see it, because I can't really see it. God surge runs on the flux babbit hardware implant. It provides software application persistence on Dell power edge servers by
02:43
exploiting the JTAG debugging interface of the server's processors. 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 God surge and what our take on God surge. And so we'll start out with the liturgy of the D
03:04
word. Let's talk about JTAG. JTAG was originally developed, there was a big committee, this was back in the 80s when
03:22
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
03:42
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
04:02
hard, might as well change the hardware, that will be easier. You're laughing, I'm not kidding. Where are my speaker notes? I don't know. I don't know.
04:29
There we go. All right. So we have a passage from the. We need to read it. So I've got a passage to read from
04:40
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 and 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
05:02
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.
05:21
Instructions that cause internal reconfiguration of the component's system logic such that the test operation is enabled may be shifted into the component through the tap. So ‑‑ that's pretty insightful. Like wow. Thank you. This is the most interesting part of the spec
05:42
too. Good thing we've got 50 minutes though. Go ahead. Okay. So what is this? Right? 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
06:04
to this to sort of 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. 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
06:24
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 ‑‑ if you have a JTAG header on
06:42
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. So when you put data in, data out,
07:04
it ends up flowing all through all of your devices, comes out the other end and you can read it back out. This gives you access to a wide range of internal registers that they build inside these things with really low overhead. The control logic for this is really small. So this gets used for a lot of
07:20
things because the odds are this will always work. Even if you build a chip and it doesn't come out and something is 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
07:45
JTAG serves 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
08:02
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?
08:26
Right? So there's a state machine defined. It uses the mode select signal to control what is actually happening with the TDI and TDO signals at any given time. And there's a state machine. There's a bunch of states in there. Most
08:42
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. 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,
09:01
you're either writing an instruction or you're reading writing data. Right? 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
09:22
access these registers? Okay. So we can use the state machine, we can get to this instruction in 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
09:42
registers in the system for you to read and write. Most of these data registers, there are a couple that are required. Bypass is a 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
10:02
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 special commands they can send to a micro controller to control how it's executing. This is all really,
10:22
really device specific. It's whatever they implemented. But from the point of view of the 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
10:46
up that lower level, 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
11:02
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 can look right down and we have 0x01, right, that's ID code. This is just a number
11:23
that it spits out that identifies the part. So we know we're talking to a CPU, a network adapter, 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
11:44
control. And basically these are three registers and 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 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
12:01
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. Different architectures will define their different custom IRs and DRs in order to debug their
12:21
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
12:42
moment where we're talking about stuff that's the manufacturer's implementation of their debug interface over JTAG. And, you know, we got to have a verse to relate to this. Romans 12, 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
13:02
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 reuse something. No, do not conform. So let's keep moving up the stack though. Here we have back to the OSI model. JTAGs, wait.
13:23
Okay. Well, who has like written stuff like with that Stevens networking book or something like that, you know, like actually written a network application, right? Who has 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 and then I was going to say, okay, put your hand down if it was an academic
13:42
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.
14:04
And Joe, tell me, what is JTAG for? Like I understand all these wires and we hook things up and we have these registers, but what can I do with it? Like what's the power of understanding this great information? When we go up the stack, we get to, you know, what probably best relates to
14:22
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 manufacturers choose to implement that and some don't.
14:41
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. You've got
15:03
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. 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
15:20
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 mandating that. Like I said, Matt did all the real work for this. I just made the
15:41
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
16:02
solder a BGA part on that has like 10 billion pins onto a board, you want to make sure all those pins are connected well, you can't get in there with a soldering iron, maybe you can 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
16:21
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, 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
16:42
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 sit there with a multimeter or logic analyzer or something and just spit ones out of these boundary scan pins, you should be able to match that, map out which bit of your data register corresponds to which output pin of your part. And the
17:01
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 it's JTAG, it's
17:20
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 clock cycle of 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
17:44
your program is running, it's running, 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 modify registers, we can read from memory right to memory,
18:02
when we're done, go back to running, run, run, run, run, run, run, and then halt. Okay. Let's check the contents of memory. What do we put in there? Let's modify some code and let's make something not behave properly. We'll change where he runs and actually that would be cool if we put a glitch in a slide or something, but we didn't do
18:21
that. You run again and run different stuff. But yeah, 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
18:42
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. If you don't have a kernel mode debugger and you don't have JTAG, you're basically debugging blind. So this is how you debug your firmware on pretty much everything. At
19:00
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 Glaufrag's expert control
19:23
newsletter. I have a reading, a little excerpt from a rant or a sacramental whine about Wassenaar. So heretics as we are, we turn our baleful and envious eye towards the hallowed halls of science. Behold, there are a number of people
19:42
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 peers. Indeed, what we call a zero day, they call a discovery or a publication. It's weird how advancement among
20:01
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 weird people in robes tended to be surprised by other
20:21
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. This is a pretty old writing. It's
20:43
thousands of hours old. And we should relate it to current day and what we're talking about. JTAG. So who knows about Wassenaar? Okay. Really I should spend more time talking about it, but I'm not going to. You should read about it
21:01
and be concerned about it. So Wassenaar 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 regulate the tools used to test and debug and do
21:20
security testing. And if we go even further, what are we doing? What is JTAG for in the beginning? 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
21:40
it's really out of morality and choice that we have to decide whether we want to use JTAG for debug or exploitation. So think about that. How do we ‑‑ you want BGA? So how
22:01
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 get boundary scan to talk to flash chips and modify their contents. You could have a locked this or a locked that, a locked boot loader that's text signatures and all that crap, but if you can use run control to halt your processor and modify a binary in memory that
22:20
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 ‑‑ how do I invert the colors? Preferences.
22:49
There we go. Style. Where? Yeah. No. That was opacity.
23:15
Yeah. There we go. F‑ yeah. Maybe I can help. That
23:34
concludes our demo. All right. So ‑‑ I'm sorry to interrupt.
24:07
This is the place to interrupt. Okay. Well, so ‑‑ so okay. Does everybody know what's going on here? I swear in the
24:22
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. Anyway, so new speakers. So even though there was a little bit of slow down there, are these
25:05
things going to work? Yeah. I haven't been drinking for 12 hours. Now everything is going to work. And if it doesn't, we know whose fault it is. So on the right‑hand side, this is
25:22
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? I told you I'm not responsible for the puns. So over here, we are
25:44
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. So we
26:01
have an SOC tap and we have an x86 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
26:23
registers. It will show us the contents of all the registers. We can dump memory. So here's the beginning of the Linux
26:42
kernel memory. We can dump some more memory. This is the instruction that controls a return code for file system
27:01
access control. We'll come back to that. So we can skip. So all right. We looked at things. We can resume. Target should ‑‑ this is where you start getting into the fun
27:20
part of all the target specific stuff and how they implement things differently. Some of the targets ‑‑ some of the actions don't immediately 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 I can get the
27:42
demo working on it. 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.
28:17
So you can also ‑‑ there's a GDB interface to this. You
28:21
can open up and you can debug your Linux kernel and GDB. So we're going to connect to our JTAG. Connected.
28:48
We're going to halt our target. We're going to load our symbol file. And then we can step through instructions. All
29:04
right. So every time I do a step by, the target executes one instruction and GDB is showing us where that is. So if you have an application, if you're trying to get your realtime OS running on this thing and you need to figure out where it dies, this is how you can connect to it. You
29:23
can watch it. You can go through all the instructions. You can see what's going on at each point in its execution. And, you know, do your debug, whatever you need.
29:43
You need the cable back. Here's the cable back. Oh, hey, it didn't even die. I think I need to reboot that, though. Okay. So we can do debug, right? We can read and write
30:04
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, right? If you want to, you know, 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
30:21
software running on that server. So if you actually want to 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
30:42
so we were able to generate from our open OCDD debug, we captured the commands that we were issuing over JTAG in the log file. We went through them and transformed them into the serial vector format and you can play them back on any device that plays JTAG. So pretty much anything that can play this format, which is the standard format for
31:03
capturing JTAG commands, this is used on everything from, you know, two $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 it's plugged into and,
31:22
you know, whatever those commands do, it will 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 it will go continually just write the memory, that memory address that we had set up. So Joe is going to tell us about the implant that
31:41
does this. So, I present to you the solder peak, right, which luckily we have enough to share. We're going to break boards together and have some PCBs. So solder peak, sorry, solder peak is basically a tiny little board. It's
32:02
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 little ‑‑ a UART interface, a serial port, which is how normally ‑‑ sorry.
32:22
This is actually based upon an existing project called JTAG whisper. It's an Arduino sketch that turns ‑‑ gives you UART access to JTAG. So what I've done is I took a board and I added a little EPROM to it, an I2C EPROM, 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
32:43
time it boots, it will wait a little while and then it will start playing back its XSVF file. 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
33:03
thought it will be uploaded to GitHub and it will all work. So flash it, run the code, that will basically transfer an XSVF file to it, stores it in the EPROM, and then next time it powers up, it waits 20 seconds and then dumps its
33:20
payload, essentially. And again, transubstantiation 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 they need hats, but
33:43
it's the NSA play set, so they have tinfoil hats. And
34:32
cheers. So you've got the PCDs. And you just want to
34:58
download it. And we'll continue with demos. Do you want to do
35:14
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
35:28
colors. Hey, keep it down. So what we're going to do since
35:46
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 ‑‑ Arduino or the Galileo? We've got the Galileo right now. If
36:01
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
36:23
and it doesn't. The stand‑alone device is actually doing something. It's getting TDO out properly. So it means we're talking to the device properly but the data we 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'm logging in here. I have a super secure password. And you
36:44
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
37:06
launch the debugger again. I'm going to go in here and I'm going to find my command line. And this is our
37:29
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.
37:53
All right. We're going to reboot it and try again. We'll give it one more try. Okay. Can you explain what you're
38:02
patching? Yeah. Okay. I know what the problem is. What? It didn't take a drink this time. Okay. Sometimes this
38:27
stuff works without drinking. You don't actually need to drink to do hardware hacking. Since when? But why else do it, right? Yeah. Yeah. My drinking space has a hardware
38:43
hacking problem. And also the bars kind of look at it funny when you bring like laptops and cables and wires and hook
39:01
things up. They're just kind of like, but it's Portland so everybody's kind of weird. Just tell them it's a board game. And they're like, oh, okay, you must just be hipsters. So Matt hauled all this done and he showed it to me
39:24
two weeks ago and I said, Matt, like, we still got two weeks. Like this is when we start. I didn't know you did the whole thing. We're going to have to play the video. Luckily I took a video when he did that. This worked every
39:42
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
40:03
video at all. I'm typing in my real ‑‑ it's 12345 in case anyone was curious. So here ‑‑ so you can see I don't
40:22
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
40:58
able to get access to the shadow password. And how many
41:09
bytes did you write? Four. Four bytes 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
41:23
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. So yeah, four bytes ‑‑ writing four bytes in memory took ‑‑ I want to say it was two or 300 actual commands in the SVF file. The first
41:44
iteration when I just did a diff and generated a patch, the SVF came out to like 500K. So I put a little work into optimizing the write. I was going to say it can take a while to ‑‑ it can take a while to do that. And as you
42:04
can see it's not 100% reliable. We can put a little more work into getting it more reliable. But we got our demo. So ‑‑ yeah. We got a drink on stage. So ‑‑ so the point
42:26
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 that works in the first place. But this is not
42:40
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. 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, you know, in cases like this, this is an embedded platform. This is designed to be used by people. JTAG is enabled intentionally on purpose because
43:03
they're expecting people to need and want to use it. But, you know, as the NSA did, you can plug this in, you can do this on pretty much anything. Almost everything ‑‑ as long as you have patience. As long as you have patience and potentially money to reverse engineering it. So if you are
43:23
building something, you need to give ‑‑ it's not just about, you know, selling it to the OEM and letting the OEM build it because eventually the user has to be able to use this. I don't necessarily want anybody who picks up my phone or my laptop to be able to do this. So, you know, you need to be able ‑‑ ideally the user would have some say in
43:42
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, you know, for $15 ‑‑ how much are these? $15?
44:03
Which the ‑‑ the adapter? Those are the Adafruit FT232H chips, so 15 bucks. So you can't plug a $15 JTAG adapter into it and get full access to everything on it. Because we're patching memory, right? It doesn't matter if you've got disk encryption, it doesn't matter what you're running. We plug this in and we get full access to
44:22
everything the OS has. So, you know, hopefully we can get to the point where it does require user involvement to actually turn some of this on. Otherwise, you know, the old assumption that, you know, 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
44:41
not everything is behind a locked door anymore. That is it. Thank you.