WEBVTT 00:00.000 --> 00:01.860 I have pushed the button. 00:02.000 --> 00:04.520 Now we're waiting on it to kick over. 00:06.900 --> 00:18.220 And see, I learned I have to actually refresh this thing, because for some reason sometimes the stream will just continue playing whatever source it was playing. 00:19.100 --> 00:20.940 And now it's music. 00:24.520 --> 00:26.260 It's still music. 00:34.010 --> 00:35.010 Let's do it. 00:35.010 --> 00:37.770 Oh, oh, oh, oh, that's looking good. 00:37.890 --> 00:40.170 Hey, there's a bunch of faces. 00:40.670 --> 00:41.990 All right. 00:41.990 --> 00:43.770 Hello, DEF CON. 00:43.930 --> 00:47.950 Welcome to your early morning Sunday content. 00:48.250 --> 00:50.150 My name is Fallible. 00:50.150 --> 00:52.010 We have got Jethro here. 00:52.010 --> 01:02.530 Joining us from the speaker side is Mickey and Jesse with the Q&A portion for their talk of Bytes in Disguise. 01:05.390 --> 01:06.630 Oh, hold on. 01:06.630 --> 01:10.050 Before I do this, I have one more button I have to push on my side. 01:10.110 --> 01:10.630 Okay. 01:11.030 --> 01:27.790 So before we get going here, I guess I'd like for the two of you to tell us a little bit about yourselves and your DEF CON history, because I know that neither of you are strangers to the hanging out in the desert with a bunch of geeks for a weekend. 01:27.790 --> 01:30.830 So tell us a little about yourselves. 01:33.050 --> 01:34.370 Go ahead, Jesse. 01:34.810 --> 01:36.910 Okay, I can start that. 01:37.230 --> 01:48.590 So I first started coming to DEF CON in 2003 when I was still back at the Alexis Park and was playing CTF back then and ended up winning a couple black badges. 01:48.590 --> 01:58.670 So I've been coming to DEF CON every year since 2003 and enjoying myself a lot and having a lot of fun and ended up starting giving talks a few years ago. 01:58.670 --> 02:02.590 So I think this is number five, maybe. 02:02.590 --> 02:05.990 I need to go count how many talks we've actually given, but I've had a lot of fun here. 02:06.270 --> 02:08.990 Casual drop in there, a couple black badges. 02:11.150 --> 02:16.150 Yeah, I'm not as acquainted with DEF CON as Jesse is. 02:16.470 --> 02:26.350 I started coming to DEF CON since DEF CON 19 and been speaking since 20, except 21, I think. 02:27.530 --> 02:29.010 I didn't get a black badge. 02:29.010 --> 02:30.430 I had to make my own. 02:32.530 --> 02:34.630 Give a talk about that, too. 02:35.570 --> 02:40.410 Yeah, I love the vibe, love the community. 02:41.230 --> 02:44.450 Great experiences, horrible stories. 02:45.310 --> 02:47.270 Yeah, it sounds about right. 02:47.270 --> 02:48.210 Well, excellent. 02:49.710 --> 02:55.690 I know that Jethro over here has a lot of interesting things to say about your talk. 02:55.690 --> 03:03.610 I have some interesting things to say about your talk, but I'm not into the niche that you occupy. 03:03.610 --> 03:14.810 So I will be watching for some of the questions that come in and maybe we'll have my fellow goon ask our initial question while I watch channels. 03:15.970 --> 03:16.490 Sure. 03:16.490 --> 03:16.790 Yeah. 03:16.790 --> 03:24.590 So for me, I watched the talk and I thought it was kind of cool, just the number of different places that you could actually hide information. 03:24.910 --> 03:36.730 And the joke I was saying is like, you've literally covered everything from like, hey, you need to wear a wrist strap when you go into this to, you know, Google hacking, like just run these searches and get this information to, you know, here's how to write random chips and, 03:36.730 --> 03:37.610 you know, code release. 03:37.950 --> 03:42.410 I guess like so quick 30 seconds, like what I guess what's the someone hadn't seen the talk yet? 03:42.410 --> 03:44.570 How would you recap everything for them? 03:44.570 --> 03:45.830 What are the high points? 03:47.590 --> 03:49.430 Not wearing a wrist strap. 03:50.570 --> 03:53.670 Let's, let's, let's do a 30 second recap for an hour talk. 03:55.910 --> 03:57.730 What's the best part they should look out for? 03:57.730 --> 03:59.370 Why should they go and watch it? 04:00.030 --> 04:01.610 The demo music. 04:03.050 --> 04:05.530 Yeah, the bossanova thing. 04:05.530 --> 04:06.370 Well done. 04:07.750 --> 04:08.770 No, no. 04:08.770 --> 04:08.950 Yeah. 04:08.950 --> 04:13.730 So, so really, I mean, like guys, what inspires you to take like such a complete look at the attack surface, right? 04:13.730 --> 04:17.630 Like, how did you think to start to look at all these different ways that you could go after devices? 04:22.900 --> 04:27.640 We both have similar perspectives, but they're slightly different. 04:29.120 --> 04:30.460 What got us into this? 04:30.460 --> 04:34.340 Well, I'd say we got tired of getting caught. 04:36.380 --> 04:48.800 So when we do the red team exercises or whatnot, and we want to hide our payloads and we always get caught and, you know, adding in a memory and on disk and all kinds of locations. 04:49.080 --> 04:52.360 And we've had a lot of experience dealing with hardware and firmware. 04:52.360 --> 04:53.280 And we thought, why the hell not? 04:53.280 --> 05:01.320 I mean, there's so many places that everyone thinks that once you go, the lower you go in the stack, the more complicated things get. 05:01.360 --> 05:08.960 They don't actually, they're way simpler, but they're just a little bit low level than most people are comfortable with. 05:08.960 --> 05:11.520 But they're not too complex. 05:11.640 --> 05:16.320 And once you get over that hurdle, you go, oh, I can just do that. 05:16.320 --> 05:17.000 That's awesome. 05:17.000 --> 05:19.480 I'll just write firmware to this thing. 05:20.660 --> 05:22.140 As simple as that. 05:23.260 --> 05:23.820 Yeah. 05:23.820 --> 05:31.340 I mean, there are a lot of mitigations in the operating system and application level that there's been a lot of attention there. 05:31.340 --> 05:40.640 So there's all kinds of OS level application security stuff, looking at the file system, doing scans of the file system are really common. 05:40.640 --> 05:46.860 And there's been a move towards like fileless malware and doing stuff only in memory. 05:47.160 --> 05:56.820 But a lot of that is just, you get code execution on the box and run fileless in, or just in memory. 05:56.820 --> 06:13.540 But being able to store stuff in places that people aren't looking gives you that additional persistence where the loader that you actually have on disk looks completely benign because people don't understand how these access mechanisms work in most cases. 06:13.540 --> 06:33.760 So being able to have something that looks benign on disk and it'll pass all the, like you can throw it up on VirusTotal and everything is 100% clean, but it still can go read the actual malicious payload out of the GIGI region or from some random USB controller firmware that's unsigned. 06:33.940 --> 06:46.820 And maybe it has some encryption key or something like that, where the only thing that happens in memory is malicious, but the thing that actually happens on disk is completely benign. 06:46.820 --> 06:50.860 And it's an interesting mechanism for persistence. 06:50.860 --> 06:58.500 And we wanted to provide more visibility into that and let people know that this type of capability exists in the system. 06:58.980 --> 07:00.780 Were you inspired? 07:01.220 --> 07:02.560 Go ahead. 07:02.600 --> 07:08.420 I was going to say, yeah, if you were inspired by any particular researcher attackers using similar techniques. 07:10.400 --> 07:21.000 I mean, there's generally been, like I said, there's been all this research and attackers in the operating system space and attackers have started moving down in the stack. 07:21.000 --> 07:23.220 Like we've seen UEFI implants. 07:23.220 --> 07:25.160 There was like a Lojax implant. 07:25.280 --> 07:27.720 There were some other ones were found in the wild. 07:27.800 --> 07:34.260 There was something in the Vault 7 leak that was talking about an EFI implant that they were using there. 07:34.380 --> 07:38.420 So I think there's a trend towards people moving further down into the stack. 07:38.720 --> 07:49.440 And a lot of these firmware components at those lower levels in the stack don't have all those same hardening protections that the application and operating system has. 07:49.440 --> 07:56.180 So you don't have things like code signing protecting your firmware in the stack or firmware in some of these devices. 07:56.180 --> 08:05.820 A lot of these are lower cost, lower power devices that maybe they don't have like a nice crypto engine built into this chipset. 08:05.820 --> 08:12.860 So a lot of that is lagging behind just because there isn't this additional visibility and people going after these components. 08:12.860 --> 08:18.600 And it's an area that's ripe for exploration and exploitation. 08:18.640 --> 08:25.560 And like we talked about in our talk, some friends of ours gave a talk about doing this type of thing using UEFI variables. 08:25.560 --> 08:28.240 And we were like, but wait, there's more. 08:28.240 --> 08:30.860 So let's go out after some of these other areas. 08:30.860 --> 08:34.460 So that was kind of the inspiration for this talk. 08:34.900 --> 08:37.320 So a lot of what you're saying is really interesting. 08:37.320 --> 08:39.680 I work way higher. 08:39.680 --> 08:51.740 I'm kind of in the website usually, and there's a lot of things that have happened over the years in the website that make it harder-ish to do the web hacking world. 08:52.120 --> 09:04.940 It sounds like there's maybe less... because there's less people working in the space of attacking low level, are there less mitigations that I would run across if I got into it? 09:07.100 --> 09:08.280 That depends. 09:08.280 --> 09:10.320 I mean, it is lagging behind to some degree. 09:10.320 --> 09:19.800 There are some... so people, depending on what people's understanding, like you said, you work in the web space. 09:19.800 --> 09:22.700 So you may be familiar with web stuff. 09:23.160 --> 09:25.440 People can talk about a full stack. 09:25.440 --> 09:35.640 And there's the full stack of the web stuff that's externally facing, going down to a lot of these underlying levels of the operating system. 09:35.640 --> 09:44.420 And you can get down to the point where you end up looking at bugs in CPU microcode that have side channel implications. 09:44.420 --> 09:48.620 And there's a lot of different vulnerabilities all throughout that stack. 09:48.620 --> 09:54.760 And there's been a lot of effort to do the easier stuff that's more directly exposed to the user. 09:54.760 --> 10:05.580 But there are some of these underlying things, some of these foundational technologies that everything is built on top of, that are kind of lagging behind those exploit mitigations. 10:05.580 --> 10:13.760 Where like when the system powers on and boots up, the processor starts executing code at the reset vector. 10:13.840 --> 10:18.780 It used to be the case this was BIOS, where there was no protections whatsoever there. 10:18.780 --> 10:23.820 Then people have standardized on UEFI, where there's the UEFI firmware that executes. 10:23.880 --> 10:27.060 And a lot of that is they're adding protections there. 10:27.060 --> 10:33.680 But a lot of the times when the UEFI firmware is running, there aren't things like address randomization. 10:33.800 --> 10:36.420 Sometimes the stack and heap are fully executable. 10:36.440 --> 10:42.540 A lot of those mitigations that you're totally used to in the operating system and application space aren't there. 10:43.120 --> 10:49.380 And there is some effort to put some of these mitigations into the reference code. 10:49.380 --> 10:58.800 So there's a... UEFI has a reference specification EDK, EFI development kit, development environment. 10:59.080 --> 11:01.560 And people take that specification. 11:01.560 --> 11:04.340 There's a reference implementation called TianoCore. 11:04.480 --> 11:15.300 Some of these exploit mitigations are going into TianoCore, but there's this whole big supply chain for getting those out to actual customer systems. 11:15.300 --> 11:25.340 So there's reference code in TianoCore that then independent vendors like AMI Phoenix inside take that code, add their own special sauce. 11:25.340 --> 11:34.420 Then the OEMs like HP Lenovo Dell take the code from the independent virus vendor and do their own value add. 11:34.460 --> 11:38.540 And then quite a bit later, that actually ends up shipping in production firmware. 11:38.540 --> 11:43.020 So there's kind of this... there's a lot of components that are going into it. 11:43.020 --> 11:45.840 And it's just lagging behind a little bit. 11:45.840 --> 11:51.980 So something going into the reference code in TianoCore it might not be enabled by default. 11:51.980 --> 11:58.580 And even if it is enabled by default, it's going to take a little while before it actually gets out into the systems that are shipping to customers. 11:58.580 --> 12:07.680 So the other problem is that updating firmware is a lot harder than just pushing out a patch through some Windows update in general. 12:08.240 --> 12:18.620 So there's... they've tried to standardize on firmware updates for system firmware to some degree, but a lot of different vendors are doing things differently. 12:18.620 --> 12:21.620 And that isn't fully easy to do yet. 12:21.620 --> 12:31.980 And so there's the system firmware for your device, the UEFI firmware, but there's also all the firmware for all these embedded controllers like the S-Media controller that Mickey talked about. 12:31.980 --> 12:40.280 And there's a GigE controller that's as part of the Intel PCH chipset that we can write to that region. 12:40.280 --> 13:06.700 We're not reading and writing to the firmware directly for that GigE region, but there's other controllers on the system like there's a lot of servers have a Broadcom 5917 chip that we talked about in some research a while back that also has unsigned firmware that that's a common server chipset where maybe an HP DL380 will have that chipset and you can write firmware there as well. 13:06.700 --> 13:07.940 Sorry, I kind of rambled a lot. 13:07.940 --> 13:08.780 Did you want to say anything? 13:08.780 --> 13:11.600 I need to change my background after that. 13:14.080 --> 13:20.440 Yep, that's pretty much it summarizes everything Jesse talked about. 13:20.440 --> 13:40.180 Yeah, so you have like a operating system security which maybe is updated through Windows Update or maybe Debian or Canonical or Red Hat SUSE repositories where they're providing updates there, but there is a little bit of an effort to update firmware, 13:40.180 --> 13:45.820 all of these different components are out there and some of them just don't have the capability to have signed firmware. 13:45.820 --> 13:58.580 So there's a lot that you can do there and there's not a really good easy way to fix it other than just waiting for the next generation to come out and hopefully it has the capability to have signed firmware as well. 13:58.740 --> 14:05.920 Sometimes they'll have checksums and stuff like that, but that's not a security mechanism and it's pretty easy to bypass and recalculate a checksum. 14:07.220 --> 14:15.600 Excellent, there's a lot there and I'm sure that I'll be watching through this talk later to make sure I get more of what you just said. 14:15.680 --> 14:19.360 We do have some questions coming in from the audience, so I'm going to get to one of those. 14:21.380 --> 14:34.400 So RPTK2015 says, question, do you know of a way to write some code into one of the various EEPROMs that will be capable of executing code by itself without code in the disk? 14:35.580 --> 14:59.820 Yeah, I mean that depends on the capabilities of the specific device, but as an example, there's all the rubber ducky bad USB devices where a lot of flash controllers or flash devices use an 8051 processor as part of the controller and you can write firmware to that and have that essentially act as a keyboard and inject keystrokes, 14:59.820 --> 15:01.060 mass storage, stuff like that. 15:01.060 --> 15:17.880 So if you have the ability to update firmware depending on the capabilities of the device, if it's an internal USB device, it might have the ability to essentially act as a rubber ducky and execute code and basically restage back from the device. 15:18.160 --> 15:30.620 We had given a talk a number of years ago also at DEF CON about an internal Huawei LTE modem that we were able to update the firmware for that and this was an internal device. 15:30.780 --> 15:46.700 Basically it was an M.2 card that was connected to the rest of the system over a USB interface and it essentially was running a version of Android with the Android gadget interface inside of this little M.2 card. 15:46.700 --> 15:52.320 So it was a complete Linux distribution inside of the USB device inside of your laptop or tablet. 15:52.320 --> 15:56.520 So you could essentially update the firmware there and have your payload there. 15:56.520 --> 16:09.660 The cool thing about that one is that you can have that inject keystrokes back to your tablet or laptop and it also had a cellular connection so you could do a CNC out to AWS. 16:09.900 --> 16:13.560 So that was a fun talk also that was a few years ago at DEF CON. 16:13.560 --> 16:30.800 So yes, you definitely have the capability where if you can update the firmware for the device, depending on the capabilities of the device, you might have the ability to directly attack it again without needing that loader within the operating system that's on disk in the file system. 16:30.860 --> 16:37.840 Additionally, if you have like a PCI device, you could potentially do DMA attacks against the system and do that same type of capability. 16:37.840 --> 16:46.520 Sometimes the operating system has DMA protections but the boot process doesn't and you can do an injection into the boot process while the system is booting up. 16:48.120 --> 16:53.180 There was a quick follow-up question on that from the same user. 16:53.180 --> 16:55.960 Did you use this in an assessment? 16:57.700 --> 17:06.440 Well, we don't work as consultants or red teamers. 17:06.560 --> 17:07.940 Not currently. 17:07.940 --> 17:15.820 So we were on a red team and we've since moved to different positions doing more hardware and low-level security. 17:16.000 --> 17:21.400 And it was like this is the type of thing that we would have wanted while we were still actively red teaming. 17:21.400 --> 17:28.280 But we haven't specifically used this on an engagement, just proof of concepts and playing around with our own systems. 17:28.340 --> 17:32.100 We've heard others use the high trick in an engagement. 17:32.340 --> 17:34.920 But not the rest of it. 17:34.920 --> 17:38.340 The rest of it's just so many options we haven't had a chance to try them all. 17:40.360 --> 17:42.920 That's kind of the problem across this space, isn't it? 17:42.920 --> 17:45.620 There's a target-rich environment. 17:48.460 --> 17:52.640 While I read this next question in my head... 17:54.760 --> 17:56.660 We'll just go right into it. 17:57.480 --> 18:01.460 It was like this when I found it. 18:01.520 --> 18:06.520 So the demo jumps right into and here's this stuff and we can write and read to it. 18:06.520 --> 18:07.940 Isn't this cool? 18:08.040 --> 18:11.460 And the natural is it is. 18:11.460 --> 18:12.440 It totally is. 18:12.440 --> 18:14.220 Plus one for elevator music. 18:14.360 --> 18:18.480 Any more pointers on enumerating access methods for these things? 18:18.480 --> 18:19.340 White papers? 18:19.340 --> 18:24.960 I presume you're not using physical methods, JTAG or in-circuit programming. 18:24.960 --> 18:30.680 So, point three, what APIs functions are you using for this kind of thing in general? 18:30.680 --> 18:37.740 It seems like you could drop stuff into legit update image and flash it, but it looks like this is on the fly. 18:38.480 --> 18:43.120 So a couple of... I can go through the TLDR of that. 18:43.800 --> 18:45.000 We can answer that. 18:45.000 --> 18:49.420 Well, it's going to take 15 minutes, but I'm going to jump right at it. 18:49.420 --> 18:56.480 So there are certain tools you can use to flash a pre-infected image. 18:56.860 --> 19:05.540 Like you can modify the legitimate image and then use the provided tool by the vendor to send it to the device and have the device flash it to its image. 19:07.240 --> 19:19.300 There was another way where we use one of the code releases was actual talking directly to the spy controller in the computer. 19:20.040 --> 19:23.140 So, Jesse, you're itching to say something, so go ahead. 19:23.140 --> 19:29.200 I just wanted to point out that if you haven't taken a look at it, we do have a sample code up on GitHub now. 19:29.700 --> 19:42.360 Basically, GitHub hacking things slash bytes in disguise that shows how some of this code works where... I will beg you after this thing to post that GitHub to the TrackOne channel, but go ahead. 19:42.500 --> 19:43.300 Okay. 19:43.300 --> 19:48.860 So, yeah, basically we have some examples to show off doing things like reading and writing to CMOS. 19:49.440 --> 20:05.240 Essentially, the low-level hardware interfaces that the processor uses to talk to some of these resources are things like IOPorts, where there's an x86 command called in and another called out that are literally for doing reads and writes to these IOPorts, 20:05.240 --> 20:08.400 and that's an architectural feature of the system. 20:08.440 --> 20:20.940 There's also a PCI access where you can do IOPort read and write to IOPorts CF8 and CFC in order to do what's called legacy PCI access. 20:21.260 --> 20:33.160 And then there's also what's called memory mapped IO, where if you can read and write to specific physical memory addresses in the system, you can basically talk to these PCI devices through the PCI controller. 20:33.560 --> 20:53.820 And generally, in order to talk to these interfaces, IOPort, you can basically do a privilege access like IOPL in Linux in order to set your IO privilege level, so then you can do IO reads and writes from ring three and talk to these ports. 20:54.120 --> 21:07.940 But in order to do reads and writes to the memory mapped IO, you generally need a ring zero access, kernel access, or a privileged proxy that can do that for you. 21:07.940 --> 21:13.280 So we gave a talk last year about a lot of drivers that provide this access for you. 21:13.280 --> 21:25.860 Basically, you can do IO controls to talk to the driver, and then the driver will go do reads and writes to these IOPorts, or PCI access, or reads and writes to physical memory. 21:25.860 --> 21:30.480 And we found a number of these drivers that can provide this type of access. 21:30.500 --> 21:37.800 And we took one of the specific examples that's pretty commonly found, the PMX driver from Intel. 21:37.800 --> 21:46.980 And it has a lot of capabilities, like you can do an IO control to talk to the driver, and it'll do an arbitrary read write to a port, or arbitrary PCI access. 21:46.980 --> 22:01.740 So we have some code that shows how to do that, including things like talk to the CMOS, read and write CMOS, read and write different areas of memory, talk to PCI devices. 22:02.640 --> 22:23.060 So one complication is that if you use the direct PCI access mechanism in that driver, it goes through the IO, or it goes through the Windows API functions to do that IO, which is how get bus by offset, bus by offset. 22:24.600 --> 22:34.620 The interesting thing is that the spy driver, or the spy device, when the Windows system is booted up, is actually hidden. 22:34.620 --> 22:35.780 It's a hidden device. 22:35.780 --> 22:45.720 So if you try and go through the API in Windows, you won't be able to talk to that spy device at bus 0, device 31, function 5. 22:46.240 --> 22:54.900 But if you do legacy PCI access by going through that IO read write of CF8CFC, you can directly talk to the spy controller in that device with no problem. 22:54.900 --> 22:57.640 So we have some code to demonstrate that. 22:57.640 --> 23:04.780 And using what's called hardware sequencing, where you basically say, here's the address within the spy chip that I want to talk to. 23:04.980 --> 23:07.820 Go read the 64 bytes from that and give me that data back. 23:07.820 --> 23:09.800 So we have an example of doing that. 23:09.800 --> 23:21.460 We have an example of basically mapping the physical address, the last page of the four gig region, and printing the bytes from the reset vector in the physical memory region. 23:21.460 --> 23:31.660 So all of that is using this driver and DLL that was included in a number of software packages for update mechanisms. 23:31.880 --> 23:36.140 And if that answer went way over your head, you can just go to the GitHub. 23:36.140 --> 23:36.800 No, that's fine. 23:36.800 --> 23:37.540 That's fine. 23:38.660 --> 23:41.280 Go to the GitHub and look at the code. 23:41.280 --> 23:46.620 It mostly is in C sharp, which is easier to understand than most things. 23:46.640 --> 23:50.740 It goes a little bit low level at some places. 23:50.740 --> 23:54.880 But if you go there and you look at the code, it's not big. 23:54.880 --> 23:55.640 It's not scary. 23:55.640 --> 23:56.800 Just take your time. 23:56.860 --> 23:59.340 If you have any questions, you can ask us later on. 23:59.340 --> 24:07.720 But whatever, everything that Jesse just said, and if you completely went over your head, it's not that complicated once you spend an hour reading on the internet. 24:07.720 --> 24:09.240 It's not that big of a deal. 24:09.240 --> 24:10.020 I promise you. 24:10.020 --> 24:12.420 It should be fairly straightforward. 24:12.680 --> 24:19.340 There are some defines and register offsets that are specified for certain things like the spy controller. 24:19.780 --> 24:30.000 If you look for the Intel PCH chipset data sheet, you'll be able to find the definitions for those registers and offsets. 24:30.000 --> 24:35.560 This was specifically put together on a Kaby Lake system, at least from my side. 24:35.560 --> 24:43.100 So some of the registers, like the fields, are a little bit different sizes between a couple different generations. 24:43.420 --> 24:48.380 But this code should work on everything from Sandy Bridge onward, I believe. 24:48.700 --> 24:49.540 All right. 24:49.540 --> 24:52.720 So I love where you're heading with this. 24:52.720 --> 25:09.600 And this is particularly the way that you're explaining how to... for some of us who don't have the depth of experience in the low level stuff, you're giving us some entry points so we can go look at your code. 25:09.600 --> 25:12.560 We can try and replicate some of this on our own. 25:12.800 --> 25:18.520 Are there other thoughts for those of us who might want to do this on our own? 25:18.520 --> 25:27.740 Do you have other places you would like us to maybe go point and get some base experience to start playing with you? 25:28.300 --> 25:29.080 Yeah, I mean... 25:29.640 --> 25:38.380 Before you do anything, before you start playing with anything, you got to remember too, if you're going to do something with something, back shit up. 25:38.800 --> 25:45.860 If you're going to experiment with non-volatile memory, first learn how to physically back it up and flash it back on. 25:47.440 --> 25:53.420 That said, go for whatever you see has a chip on it that contains data. 25:53.420 --> 25:54.620 Go wild. 25:55.380 --> 26:04.140 Yeah, to follow up on that, there are some things you can do, like writing to some locations in your system, where the system won't boot anymore. 26:04.140 --> 26:06.960 So you'll need to physically open the case. 26:07.620 --> 26:30.520 In the case of writes to just bare SPI chips that are easily accessible, like the BIOS or UEFI firmware or BMC firmware in a server, you could use something like a Dediprog with a chip clip and physically clip onto the SPI chip and read that, make a backup copy using physical access before you start messing with it. 26:30.920 --> 26:36.140 There's also, you can use a bus pirate to do SPI read and write if you don't have a Dediprog. 26:36.320 --> 26:39.700 But you can often find a Dediprog on eBay for like 50 bucks or so. 26:39.700 --> 26:54.180 What I recommend is if you don't want to do that, I have an alternate method, which is you have a Thunderbolt capable device, you just plug in a PCI Thunderbolt adapter you can pick up for 100-150 bucks off Amazon. 26:54.600 --> 26:57.760 And then you just plug in one of these PCI cards. 26:57.760 --> 27:00.020 This is one of the cards we worked on for the demo. 27:00.020 --> 27:02.280 This is a USB controller PCI device. 27:02.360 --> 27:03.360 It has its own EEPROM. 27:03.360 --> 27:05.820 And if you mess it up, it's 15 bucks. 27:06.480 --> 27:11.800 Isn't that the thing too, but was not the controller you actually writing to? 27:12.040 --> 27:18.480 This is the same controller that I thought I was writing to, but apparently I had one in my motherboard that I've been reading and writing to. 27:18.480 --> 27:20.280 So yeah, be careful about doing that. 27:20.280 --> 27:27.680 It's nice if you can just pull out the PCI card and your system boots again, but sometimes it's more difficult. 27:27.880 --> 27:31.380 Remember to check you don't have your target already in your computer before you start flashing. 27:33.040 --> 27:34.920 This is all great advice. 27:34.920 --> 27:40.020 All right, gentlemen, we are right at the end of our allotted time. 27:40.380 --> 27:45.360 You two are incredibly easy to talk to about this stuff, so we appreciate that. 27:45.880 --> 27:51.160 I like to provide everybody an opportunity to distill a takeaway. 27:51.160 --> 27:56.800 What is the call to action you would like to provide for the community who is watching this? 27:58.460 --> 28:06.420 I would just start out by saying this might seem intimidating and difficult to get into, but it's really a lot easier than you think. 28:06.420 --> 28:15.580 And if you just start experimenting with this case and do some of this yourself, it's actually a lot of fun and it's not as hard as it might initially seem. 28:15.580 --> 28:18.320 So we have some code examples you can get to. 28:18.460 --> 28:22.120 Like I mentioned, the Intel PCH chipset data sheet. 28:22.500 --> 28:32.800 It's a pretty big document, but if you just look at certain things like the SPI controller registers, it can help guide you and get you started. 28:32.800 --> 28:35.100 So I totally recommend people to go. 28:35.160 --> 28:38.860 Don't be intimidated by this and just try it out and see what you can do. 28:39.100 --> 28:45.860 I'm just going to add that feel free to ask other people for advice. 28:45.860 --> 28:54.220 And I'm just going to caveat this with if you ask me for advice, I will gladly help you under the condition that you help others if they ask you. 28:55.980 --> 28:57.920 So don't be an asshole. 28:57.920 --> 28:59.100 Help others. 28:59.100 --> 29:00.860 This is the point of community. 29:00.960 --> 29:06.460 Yeah, that is one of the best takeaways that I've heard so far. 29:06.460 --> 29:14.300 So you have a whole series of people in chat wanting to buy you drinks next time they see you in person. 29:15.200 --> 29:26.460 Well, thank you two very much for coming and providing another deep load of content for DefCon and all that you do for us. 29:26.580 --> 29:40.600 So if anybody has additional questions, I'm going to see if I can get these two to post more of their contact information in the TrackOne channel so that people can find you later. 29:40.600 --> 29:47.820 Other than that, I hope you have a wonderful rest of your Con and that's pretty much it. 29:48.000 --> 29:48.880 Cool. 29:48.880 --> 29:49.200 Thank you. 29:49.200 --> 29:49.620 Thank you both. 29:49.620 --> 29:50.080 Thank you.