[00:00.000 --> 00:04.520]  I have pushed the button. Now we're waiting on it to kick over.
[00:06.900 --> 00:12.620]  And see, I learned I have to actually refresh this thing, because for some reason sometimes
[00:12.620 --> 00:20.940]  the stream will just continue playing whatever source it was playing. And now it's music.
[00:24.520 --> 00:26.260]  It's still music.
[00:34.010 --> 00:40.170]  Let's do it. Oh, oh, oh, oh, that's looking good. Hey, there's a bunch of faces.
[00:40.670 --> 00:47.950]  All right. Hello, DEF CON. Welcome to your early morning Sunday content.
[00:48.250 --> 00:55.310]  My name is Fallible. We have got Jethro here. Joining us from the speaker side is
[00:55.310 --> 01:02.530]  Mickey and Jesse with the Q&A portion for their talk of Bytes in Disguise.
[01:05.390 --> 01:10.050]  Oh, hold on. Before I do this, I have one more button I have to push on my side.
[01:10.110 --> 01:17.150]  Okay. So before we get going here, I guess I'd like for the two of you to tell us a little bit
[01:17.150 --> 01:23.230]  about yourselves and your DEF CON history, because I know that neither of you are strangers to
[01:24.690 --> 01:27.790]  the hanging out in the desert with a bunch of geeks for a weekend. So
[01:28.350 --> 01:30.830]  tell us a little about yourselves.
[01:33.050 --> 01:34.370]  Go ahead, Jesse.
[01:34.810 --> 01:42.310]  Okay, I can start that. So I first started coming to DEF CON in 2003 when I was still back at the
[01:42.310 --> 01:48.930]  Alexis Park and was playing CTF back then and ended up winning a couple black badges. So I've
[01:48.930 --> 01:55.450]  been coming to DEF CON every year since 2003 and enjoying myself a lot and having a lot of fun
[01:55.450 --> 02:02.710]  and ended up starting giving talks a few years ago. So I think this is number five, maybe. I
[02:02.710 --> 02:05.990]  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:18.270]  Yeah, I'm not as acquainted with DEF CON as Jesse is. I started coming to DEF CON
[02:18.270 --> 02:26.350]  since DEF CON 19 and been speaking since 20, except 21, I think.
[02:27.530 --> 02:30.430]  I didn't get a black badge. I had to make my own.
[02:32.530 --> 02:34.630]  Give a talk about that, too.
[02:35.570 --> 02:44.450]  Yeah, I love the vibe, love the community. Great experiences, horrible stories.
[02:45.310 --> 02:53.030]  Yeah, it sounds about right. Well, excellent. I know that Jethro over here has a lot of
[02:53.030 --> 02:58.630]  interesting things to say about your talk. I have some interesting things to say about your talk,
[02:58.630 --> 03:07.050]  but I'm not into the niche that you occupy. So I will be watching for some of the questions
[03:07.050 --> 03:13.930]  that come in and maybe we'll have my fellow goon ask our initial question while I watch
[03:13.930 --> 03:20.390]  channels. Sure. Yeah. So for me, I watched the talk and I thought it was kind of cool,
[03:20.390 --> 03:25.930]  just the number of different places that you could actually hide information. And the joke I was
[03:25.930 --> 03:29.150]  saying is like, you've literally covered everything from like, hey, you need to wear a wrist strap
[03:29.150 --> 03:33.090]  when you go into this to, you know, Google hacking, like just run these searches and get this
[03:33.090 --> 03:38.510]  information to, you know, here's how to write random chips and, you know, code release. I guess
[03:38.510 --> 03:42.750]  like so quick 30 seconds, like what I guess what's the someone hadn't seen the talk yet? How would
[03:42.750 --> 03:51.310]  you recap everything for them? What are the high points? Not wearing a wrist strap. Let's, let's,
[03:51.310 --> 03:57.730]  let's do a 30 second recap for an hour talk. What's the best part they should look out for?
[03:57.730 --> 04:06.370]  Why should they go and watch it? The demo music. Yeah, the bossanova thing. Well done.
[04:07.750 --> 04:12.270]  No, no. Yeah. So, so really, I mean, like guys, what inspires you to take like such a complete
[04:12.270 --> 04:15.730]  look at the attack surface, right? Like, how did you think to start to look at all these different
[04:15.730 --> 04:27.640]  ways that you could go after devices? We both have similar perspectives, but they're slightly different.
[04:29.120 --> 04:34.340]  What got us into this? Well, I'd say we got tired of getting caught.
[04:36.380 --> 04:41.780]  So when we do the red team exercises or whatnot, and we want to hide our payloads and
[04:42.500 --> 04:48.800]  we always get caught and, you know, adding in a memory and on disk and all kinds of locations.
[04:49.080 --> 04:52.680]  And we've had a lot of experience dealing with hardware and firmware. And we thought,
[04:52.680 --> 04:57.160]  why the hell not? I mean, there's so many places that everyone thinks that once you go,
[04:57.160 --> 05:02.840]  the lower you go in the stack, the more complicated things get. They don't actually,
[05:02.840 --> 05:08.560]  they're way simpler, but they're just a little bit low level than most people are comfortable
[05:08.560 --> 05:14.280]  with. But they're not too complex. And once you get over that hurdle, you go,
[05:14.280 --> 05:19.480]  oh, I can just do that. That's awesome. I'll just write firmware to this thing.
[05:20.660 --> 05:26.840]  As simple as that. Yeah. I mean, there are a lot of mitigations in the operating system
[05:26.840 --> 05:32.600]  and application level that there's been a lot of attention there. So there's all kinds of
[05:33.160 --> 05:38.740]  OS level application security stuff, looking at the file system, doing scans of the file system
[05:38.740 --> 05:45.860]  are really common. And there's been a move towards like fileless malware and doing stuff only in
[05:45.860 --> 05:55.040]  memory. But a lot of that is just, you get code execution on the box and run fileless in,
[05:55.040 --> 06:00.140]  or just in memory. But being able to store stuff in places that people aren't looking
[06:00.800 --> 06:05.960]  gives you that additional persistence where the loader that you actually have on disk
[06:06.780 --> 06:12.220]  looks completely benign because people don't understand how these access mechanisms work
[06:12.220 --> 06:18.360]  in most cases. So being able to have something that looks benign on disk and it'll pass all the,
[06:18.360 --> 06:23.700]  like you can throw it up on VirusTotal and everything is 100% clean, but it still can go
[06:24.580 --> 06:31.400]  read the actual malicious payload out of the GIGI region or from some random USB controller
[06:31.400 --> 06:38.640]  firmware that's unsigned. And maybe it has some encryption key or something like that, where
[06:38.640 --> 06:44.920]  the only thing that happens in memory is malicious, but the thing that actually happens on disk is
[06:44.920 --> 06:51.540]  completely benign. And it's an interesting mechanism for persistence. And we wanted to
[06:51.540 --> 06:57.600]  provide more visibility into that and let people know that this type of capability exists in the
[06:57.600 --> 07:05.380]  system. Were you inspired? Go ahead. I was going to say, yeah, if you were inspired by any particular
[07:05.380 --> 07:13.240]  researcher attackers using similar techniques. I mean, there's generally been, like I said,
[07:13.240 --> 07:19.780]  there's been all this research and attackers in the operating system space and attackers have
[07:19.780 --> 07:25.160]  started moving down in the stack. Like we've seen UEFI implants. There was like a Lojax implant.
[07:25.280 --> 07:30.700]  There were some other ones were found in the wild. There was something in the Vault 7 leak that was
[07:30.700 --> 07:36.360]  talking about an EFI implant that they were using there. So I think there's a trend towards people
[07:36.360 --> 07:42.160]  moving further down into the stack. And a lot of these firmware components at those lower levels
[07:42.160 --> 07:48.580]  in the stack don't have all those same hardening protections that the application and operating
[07:48.580 --> 07:54.320]  system has. So you don't have things like code signing protecting your firmware in the stack
[07:54.320 --> 08:00.120]  or firmware in some of these devices. A lot of these are lower cost, lower power devices that
[08:00.120 --> 08:08.020]  maybe they don't have like a nice crypto engine built into this chipset. So a lot of that is
[08:08.020 --> 08:11.840]  lagging behind just because there isn't this additional visibility and people going after these
[08:11.840 --> 08:19.360]  components. And it's an area that's ripe for exploration and exploitation. And like we
[08:19.360 --> 08:24.420]  talked about in our talk, some friends of ours gave a talk about doing this type of thing using
[08:24.420 --> 08:29.980]  UEFI variables. And we were like, but wait, there's more. So let's go out after some of these
[08:29.980 --> 08:36.440]  other areas. So that was kind of the inspiration for this talk. So a lot of what you're saying
[08:36.440 --> 08:43.340]  is really interesting. I work way higher. I'm kind of in the website usually, and there's a lot
[08:43.340 --> 08:50.460]  of things that have happened over the years in the website that make it harder-ish to do the web
[08:50.460 --> 08:58.280]  hacking world. It sounds like there's maybe less... because there's less people working in the space
[08:58.280 --> 09:04.940]  of attacking low level, are there less mitigations that I would run across if I got into it?
[09:07.100 --> 09:13.760]  That depends. I mean, it is lagging behind to some degree. There are some... so people,
[09:14.740 --> 09:20.420]  depending on what people's understanding, like you said, you work in the web space. So you
[09:20.420 --> 09:26.320]  may be familiar with web stuff. People can talk about a full stack. And there's the full
[09:26.320 --> 09:33.520]  stack of the web stuff that's externally facing, going down to a lot of these
[09:33.520 --> 09:37.720]  underlying levels of the operating system. And you can get down to the point where you end up
[09:37.720 --> 09:46.040]  looking at bugs in CPU microcode that have side channel implications. And there's a lot of
[09:46.040 --> 09:51.200]  different vulnerabilities all throughout that stack. And there's been a lot of effort to do
[09:51.200 --> 09:55.920]  the easier stuff that's more directly exposed to the user. But there are some of these underlying
[09:56.640 --> 10:01.200]  things, some of these foundational technologies that everything is built on top of,
[10:01.200 --> 10:08.000]  that are kind of lagging behind those exploit mitigations. Where like when the system
[10:08.000 --> 10:13.760]  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:29.240]  And a lot of that is they're adding protections there. But a lot of the times when the UEFI
[10:29.240 --> 10:34.660]  firmware is running, there aren't things like address randomization. Sometimes the stack and
[10:34.660 --> 10:39.240]  heap are fully executable. A lot of those mitigations that you're totally used to in the
[10:39.240 --> 10:45.880]  operating system and application space aren't there. And there is some effort to put some of
[10:45.880 --> 10:54.040]  these mitigations into the reference code. So there's a... UEFI has a reference specification
[10:54.040 --> 11:02.220]  EDK, EFI development kit, development environment. And people take that specification. There's a
[11:02.220 --> 11:06.780]  reference implementation called TianoCore. Some of these exploit mitigations are going
[11:06.780 --> 11:14.160]  into TianoCore, but there's this whole big supply chain for getting those out to
[11:14.160 --> 11:19.260]  actual customer systems. So there's reference code in TianoCore that then independent
[11:19.860 --> 11:26.860]  vendors like AMI Phoenix inside take that code, add their own special sauce. Then the OEMs like
[11:26.860 --> 11:31.960]  HP Lenovo Dell take the code from the independent virus vendor and do their own
[11:32.940 --> 11:38.540]  value add. And then quite a bit later, that actually ends up shipping in production firmware.
[11:38.540 --> 11:44.340]  So there's kind of this... there's a lot of components that are going into it. And it's
[11:44.340 --> 11:48.620]  just lagging behind a little bit. So something going into the reference code in TianoCore
[11:49.640 --> 11:54.100]  it might not be enabled by default. And even if it is enabled by default, it's going to take a
[11:54.100 --> 11:59.500]  little while before it actually gets out into the systems that are shipping to customers. So
[11:59.500 --> 12:05.000]  the other problem is that updating firmware is a lot harder than just pushing out a patch
[12:05.000 --> 12:11.580]  through some Windows update in general. So there's... they've tried to standardize on
[12:11.580 --> 12:17.500]  firmware updates for system firmware to some degree, but a lot of different vendors are doing
[12:17.500 --> 12:24.540]  things differently. And that isn't fully easy to do yet. And so there's the system firmware
[12:24.540 --> 12:28.780]  for your device, the UEFI firmware, but there's also all the firmware for all these
[12:28.780 --> 12:34.960]  embedded controllers like the S-Media controller that Mickey talked about. And there's a
[12:34.960 --> 12:40.520]  GigE controller that's as part of the Intel PCH chipset that we can write to that region.
[12:40.520 --> 12:45.060]  We're not reading and writing to the firmware directly for that GigE region, but there's other
[12:45.060 --> 12:52.080]  controllers on the system like there's a lot of servers have a Broadcom 5917 chip
[12:52.080 --> 12:56.540]  that we talked about in some research a while back that also has unsigned firmware that
[12:56.540 --> 13:04.700]  that's a common server chipset where maybe an HP DL380 will have that chipset and you can
[13:04.700 --> 13:08.780]  write firmware there as well. Sorry, I kind of rambled a lot. 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:25.160]  Yeah, so you have like a operating system security which maybe is updated through
[13:25.160 --> 13:34.420]  Windows Update or maybe Debian or Canonical or Red Hat SUSE repositories where
[13:35.040 --> 13:40.180]  they're providing updates there, but there is a little bit of an effort to update firmware,
[13:40.180 --> 13:44.380]  all of these different components are out there and some of them just don't have the capability
[13:44.380 --> 13:50.720]  to have signed firmware. So there's a lot that you can do there and there's not a really good
[13:50.720 --> 13:55.140]  easy way to fix it other than just waiting for the next generation to come out and hopefully
[13:55.140 --> 14:00.020]  it has the capability to have signed firmware as well. Sometimes they'll have checksums and
[14:00.020 --> 14:04.360]  stuff like that, but that's not a security mechanism and it's pretty easy to bypass
[14:04.360 --> 14:10.120]  and recalculate a checksum. Excellent, there's a lot there and I'm sure that
[14:10.120 --> 14:15.600]  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:27.820]  So RPTK2015 says, question, do you know of a way to write some code into one of the various
[14:28.860 --> 14:34.400]  EEPROMs that will be capable of executing code by itself without code in the disk?
[14:35.580 --> 14:41.300]  Yeah, I mean that depends on the capabilities of the specific device, but as an example,
[14:41.300 --> 14:48.640]  there's all the rubber ducky bad USB devices where a lot of flash controllers or flash devices
[14:48.640 --> 14:55.480]  use an 8051 processor as part of the controller and you can write firmware to that and have that
[14:55.480 --> 15:01.280]  essentially act as a keyboard and inject keystrokes, mass storage, stuff like that. So
[15:01.280 --> 15:07.440]  if you have the ability to update firmware depending on the capabilities of the device,
[15:07.440 --> 15:13.360]  if it's an internal USB device, it might have the ability to essentially act as a rubber ducky and
[15:13.920 --> 15:20.860]  execute code and basically restage back from the device. We had given a talk a number of years ago
[15:20.860 --> 15:28.360]  also at DEF CON about an internal Huawei LTE modem that we were able to update the firmware for that
[15:28.360 --> 15:35.040]  and this was an internal device. Basically it was an M.2 card that was connected to the rest
[15:35.040 --> 15:42.100]  of the system over a USB interface and it essentially was running a version of Android
[15:42.100 --> 15:47.560]  with the Android gadget interface inside of this little M.2 card. So it was a complete Linux
[15:47.560 --> 15:53.960]  distribution inside of the USB device inside of your laptop or tablet. So you could essentially
[15:53.960 --> 15:58.380]  update the firmware there and have your payload there. The cool thing about that one is that
[15:58.380 --> 16:04.640]  you can have that inject keystrokes back to your tablet or laptop and it also had a cellular
[16:04.640 --> 16:12.620]  connection so you could do a CNC out to AWS. So that was a fun talk also that was a few years
[16:12.620 --> 16:16.940]  ago at DEF CON. So yes, you definitely have the capability where if you can update the firmware
[16:16.940 --> 16:21.500]  for the device, depending on the capabilities of the device, you might have the ability to
[16:22.000 --> 16:28.300]  directly attack it again without needing that loader within the operating system
[16:28.300 --> 16:33.580]  that's on disk in the file system. Additionally, if you have like a PCI device, you could potentially
[16:33.580 --> 16:39.980]  do DMA attacks against the system and do that same type of capability. Sometimes the
[16:39.980 --> 16:44.380]  operating system has DMA protections but the boot process doesn't and you can do an injection into
[16:44.380 --> 16:50.420]  the boot process while the system is booting up. There was a quick follow-up question on
[16:50.420 --> 16:55.960]  that from the same user. 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:13.940]  Not currently. So we were on a red team and we've since moved to different positions doing more
[17:13.940 --> 17:18.040]  hardware and low-level security. And it was like this is the type of thing that we would have
[17:18.040 --> 17:23.780]  wanted while we were still actively red teaming. But we haven't specifically used this on an
[17:23.780 --> 17:29.120]  engagement, just proof of concepts and playing around with our own systems. We've heard others
[17:29.120 --> 17:35.840]  use the high trick in an engagement. But not the rest of it. The rest of it's just so
[17:35.840 --> 17:42.160]  many options we haven't had a chance to try them all. That's kind of the problem across this
[17:42.160 --> 17:45.620]  space, isn't it? There's a target-rich environment.
[17:48.460 --> 17:52.640]  While I read this next question in my head...
[17:54.760 --> 18:03.520]  We'll just go right into it. It was like this when I found it. So the demo jumps right into
[18:03.520 --> 18:11.460]  and here's this stuff and we can write and read to it. Isn't this cool? And the natural is it is.
[18:11.460 --> 18:17.680]  It totally is. Plus one for elevator music. Any more pointers on enumerating access methods for
[18:17.680 --> 18:23.980]  these things? White papers? I presume you're not using physical methods, JTAG or in-circuit
[18:23.980 --> 18:30.680]  programming. So, point three, what APIs functions are you using for this kind of thing in general?
[18:30.680 --> 18:36.460]  It seems like you could drop stuff into legit update image and flash it, but it looks like this
[18:36.460 --> 18:45.360]  is on the fly. So a couple of... I can go through the TLDR of that. We can answer that. Well, it's
[18:45.360 --> 18:52.260]  going to take 15 minutes, but I'm going to jump right at it. So there are certain tools you can
[18:52.260 --> 18:59.220]  use to flash a pre-infected image. Like you can modify the legitimate image and then use the
[18:59.220 --> 19:05.540]  provided tool by the vendor to send it to the device and have the device flash it to its image.
[19:07.240 --> 19:13.760]  There was another way where we use one of the code releases was actual
[19:14.560 --> 19:22.060]  talking directly to the spy controller in the computer. So, Jesse, you're itching to
[19:22.060 --> 19:26.640]  say something, so go ahead. I just wanted to point out that if you haven't taken a look at it, we do
[19:26.640 --> 19:33.800]  have a sample code up on GitHub now. Basically, GitHub hacking things slash bytes in disguise
[19:33.800 --> 19:39.680]  that shows how some of this code works where... I will beg you after this thing to post that
[19:39.680 --> 19:45.360]  GitHub to the TrackOne channel, but go ahead. Okay. So, yeah, basically we have some examples
[19:45.360 --> 19:52.000]  to show off doing things like reading and writing to CMOS. Essentially, the low-level hardware
[19:52.000 --> 19:58.700]  interfaces that the processor uses to talk to some of these resources are things like IOPorts,
[19:58.700 --> 20:03.540]  where there's an x86 command called in and another called out that are literally for doing
[20:03.540 --> 20:09.120]  reads and writes to these IOPorts, and that's an architectural feature of the system. There's also
[20:09.360 --> 20:18.600]  a PCI access where you can do IOPort read and write to IOPorts CF8 and CFC in order to do
[20:18.600 --> 20:24.940]  what's called legacy PCI access. And then there's also what's called memory mapped IO, where if you
[20:24.940 --> 20:30.020]  can read and write to specific physical memory addresses in the system, you can basically talk
[20:30.020 --> 20:36.810]  to these PCI devices through the PCI controller. And generally, in order to talk to these interfaces,
[20:39.040 --> 20:46.150]  IOPort, you can basically do a privilege access like IOPL in Linux in order to
[20:47.740 --> 20:51.880]  set your IO privilege level, so then you can do IO reads and writes from ring three
[20:51.880 --> 20:58.280]  and talk to these ports. But in order to do reads and writes to the memory mapped IO,
[20:58.280 --> 21:06.880]  you generally need a ring zero access, kernel access, or a privileged proxy that can do that
[21:06.880 --> 21:13.880]  for you. So we gave a talk last year about a lot of drivers that provide this access for you. Basically,
[21:14.520 --> 21:20.380]  you can do IO controls to talk to the driver, and then the driver will go do reads and writes to
[21:20.380 --> 21:27.080]  these IOPorts, or PCI access, or reads and writes to physical memory. And we found a number of
[21:27.080 --> 21:33.620]  these drivers that can provide this type of access. And we took one of the specific examples that's
[21:34.640 --> 21:39.820]  pretty commonly found, the PMX driver from Intel. And it has a lot of capabilities, like
[21:40.360 --> 21:45.280]  you can do an IO control to talk to the driver, and it'll do an arbitrary read write to a port,
[21:45.280 --> 21:50.640]  or arbitrary PCI access. So we have some code that shows how to do that, including things like
[21:51.880 --> 21:55.380]  talk to the CMOS, read and write CMOS, read and write
[21:57.080 --> 22:05.800]  different areas of memory, talk to PCI devices. So one complication is that
[22:06.400 --> 22:13.540]  if you use the direct PCI access mechanism in that driver, it goes through the IO,
[22:13.960 --> 22:21.900]  or it goes through the Windows API functions to do that IO, which is how get bus by offset,
[22:21.900 --> 22:29.380]  bus by offset. The interesting thing is that the spy driver, or the spy device,
[22:29.380 --> 22:36.060]  when the Windows system is booted up, is actually hidden. It's a hidden device. So
[22:36.060 --> 22:41.120]  if you try and go through the API in Windows, you won't be able to talk to that spy device
[22:41.120 --> 22:49.540]  at bus 0, device 31, function 5. But if you do legacy PCI access by going through that IO
[22:49.540 --> 22:54.900]  read write of CF8CFC, you can directly talk to the spy controller in that device with no problem.
[22:54.900 --> 22:59.780]  So we have some code to demonstrate that. And using what's called hardware sequencing,
[22:59.780 --> 23:04.780]  where you basically say, here's the address within the spy chip that I want to talk to.
[23:04.980 --> 23:09.800]  Go read the 64 bytes from that and give me that data back. So we have an example of doing that.
[23:09.800 --> 23:15.520]  We have an example of basically mapping the physical address, the last page of the four
[23:15.520 --> 23:21.880]  gig region, and printing the bytes from the reset vector in the physical memory region. So all of
[23:21.880 --> 23:30.740]  that is using this driver and DLL that was included in a number of software packages for update
[23:30.740 --> 23:36.480]  mechanisms. And if that answer went way over your head, you can just go to the GitHub. No, that's
[23:36.480 --> 23:44.760]  fine. That's fine. Go to the GitHub and look at the code. It mostly is in C sharp, which is easier
[23:44.760 --> 23:51.520]  to understand than most things. It goes a little bit low level at some places. But if you
[23:52.000 --> 23:56.800]  go there and you look at the code, it's not big. It's not scary. Just take your time.
[23:56.860 --> 24:02.280]  If you have any questions, you can ask us later on. But whatever, everything that Jesse just said,
[24:02.280 --> 24:06.640]  and if you completely went over your head, it's not that complicated once you spend an hour
[24:06.640 --> 24:11.200]  reading on the internet. It's not that big of a deal. I promise you. It should be fairly
[24:11.200 --> 24:17.540]  straightforward. There are some defines and register offsets that are specified for certain
[24:17.540 --> 24:24.820]  things like the spy controller. If you look for the Intel PCH chipset data sheet, you'll be able
[24:24.820 --> 24:32.880]  to find the definitions for those registers and offsets. This was specifically put together on a
[24:32.880 --> 24:39.720]  Kaby Lake system, at least from my side. So some of the registers, like the fields, are a little
[24:39.720 --> 24:45.140]  bit different sizes between a couple different generations. But this code should work on
[24:45.140 --> 24:52.200]  everything from Sandy Bridge onward, I believe. All right. So I love where you're heading with
[24:52.200 --> 25:01.120]  this. And this is particularly the way that you're explaining how to... for some of us who don't have
[25:01.120 --> 25:08.360]  the depth of experience in the low level stuff, you're giving us some entry points so we can go
[25:08.360 --> 25:14.840]  look at your code. We can try and replicate some of this on our own. Are there other thoughts for
[25:14.840 --> 25:20.440]  those of us who might want to do this on our own? Do you have other places you would like us to
[25:20.440 --> 25:29.080]  maybe go point and get some base experience to start playing with you? Yeah, I mean...
[25:29.640 --> 25:34.320]  Before you do anything, before you start playing with anything, you got to remember too, if you're
[25:34.320 --> 25:40.980]  going to do something with something, back shit up. If you're going to experiment with
[25:40.980 --> 25:45.860]  non-volatile memory, first learn how to physically back it up and flash it back on.
[25:47.440 --> 25:54.620]  That said, go for whatever you see has a chip on it that contains data. Go wild.
[25:55.380 --> 25:59.920]  Yeah, to follow up on that, there are some things you can do, like writing to some locations
[26:00.490 --> 26:05.900]  in your system, where the system won't boot anymore. So you'll need to physically open the
[26:05.900 --> 26:15.180]  case. In the case of writes to just bare SPI chips that are easily accessible,
[26:15.180 --> 26:21.040]  like the BIOS or UEFI firmware or BMC firmware in a server, you could use something like a
[26:21.040 --> 26:27.460]  Dediprog with a chip clip and physically clip onto the SPI chip and read that, make a backup copy
[26:27.460 --> 26:33.300]  using physical access before you start messing with it. There's also, you can use a bus pirate
[26:33.300 --> 26:37.820]  to do SPI read and write if you don't have a Dediprog. But you can often find a Dediprog
[26:37.820 --> 26:43.460]  on eBay for like 50 bucks or so. What I recommend is if you don't want to do that, I have an
[26:43.460 --> 26:50.000]  alternate method, which is you have a Thunderbolt capable device, you just plug in a PCI Thunderbolt
[26:50.000 --> 26:55.980]  adapter you can pick up for 100-150 bucks off Amazon. And then you just plug in one of these
[26:56.900 --> 27:01.560]  PCI cards. This is one of the cards we worked on for the demo. This is a USB controller PCI
[27:01.560 --> 27:08.880]  device. It has its own EEPROM. And if you mess it up, it's 15 bucks. Isn't that the thing too,
[27:08.880 --> 27:13.760]  but was not the controller you actually writing to? This is the same controller that I thought
[27:13.760 --> 27:18.480]  I was writing to, but apparently I had one in my motherboard that I've been reading and writing to.
[27:18.480 --> 27:22.820]  So yeah, be careful about doing that. It's nice if you can just pull out the PCI card
[27:22.820 --> 27:28.480]  and your system boots again, but sometimes it's more difficult. Remember to check you
[27:28.480 --> 27:31.380]  don't have your target already in your computer before you start flashing.
[27:33.040 --> 27:40.020]  This is all great advice. All right, gentlemen, we are right at the end of our allotted time.
[27:40.380 --> 27:46.860]  You two are incredibly easy to talk to about this stuff, so we appreciate that. I like to
[27:46.860 --> 27:53.100]  provide everybody an opportunity to distill a takeaway. What is the call to action you
[27:53.100 --> 28:00.240]  would like to provide for the community who is watching this? I would just start out by saying
[28:01.020 --> 28:06.420]  this might seem intimidating and difficult to get into, but it's really a lot easier than you think.
[28:06.420 --> 28:12.560]  And if you just start experimenting with this case and do some of this yourself,
[28:12.560 --> 28:15.800]  it's actually a lot of fun and it's not as hard as it might initially seem. So
[28:15.800 --> 28:22.120]  we have some code examples you can get to. Like I mentioned, the Intel PCH chipset data sheet.
[28:22.500 --> 28:28.020]  It's a pretty big document, but if you just look at certain things like the SPI controller
[28:28.840 --> 28:35.100]  registers, it can help guide you and get you started. So I totally recommend people to go.
[28:35.160 --> 28:40.560]  Don't be intimidated by this and just try it out and see what you can do. I'm just going to add that
[28:42.240 --> 28:48.300]  feel free to ask other people for advice. And I'm just going to caveat this with if you ask
[28:48.300 --> 28:54.220]  me for advice, I will gladly help you under the condition that you help others if they ask you.
[28:55.980 --> 29:00.860]  So don't be an asshole. Help others. This is the point of community.
[29:00.960 --> 29:09.180]  Yeah, that is one of the best takeaways that I've heard so far. So you have a whole series
[29:09.180 --> 29:16.340]  of people in chat wanting to buy you drinks next time they see you in person. Well, thank you two
[29:16.340 --> 29:25.460]  very much for coming and providing another deep load of content for DefCon and all that you do
[29:25.460 --> 29:31.600]  for us. So if anybody has additional questions, I'm going to see if I can get these two to post
[29:32.160 --> 29:40.600]  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:50.080]  Cool. Thank you. Thank you both. Thank you.