[00:02.640 --> 00:06.240]  Alright, just a couple of quick announcements before we get to our next discussion.
[00:06.680 --> 00:10.060]  If you haven't been downstairs, on the second floor, there's a lot of cool stuff going on.
[00:10.180 --> 00:14.000]  People soldering, taking stuff apart, putting it back together again.
[00:14.760 --> 00:19.160]  There's evidently some kind of dildo sculpture of some kind, if you've come across that.
[00:20.700 --> 00:24.320]  Also, Emmanuel asked me to give a couple of quick notes.
[00:24.340 --> 00:31.560]  If you could try to pick up after yourself, like soda bottles and stuff like that, just because we are cramming in, and a lot of people are going in and out.
[00:31.560 --> 00:33.540]  So, please use the trash receptacles.
[00:33.700 --> 00:43.180]  Also, if you see several people walking around with what looks like Old English, that's not liquor, that's actually what is called the Jolt of Germany.
[00:43.460 --> 00:52.020]  It's Club-Mate, and Emmanuel brought in several pallets that arrived on a container ship from Germany yesterday.
[00:52.940 --> 00:55.120]  It's this stuff, and it's awesome.
[00:55.500 --> 00:56.580]  So, it's for sale.
[00:57.000 --> 00:58.360]  We're not selling it right here.
[00:58.440 --> 01:00.220]  It's for sale downstairs on the second floor.
[01:00.220 --> 01:03.080]  They might have some up here as well, but definitely try it, because it's amazing.
[01:03.820 --> 01:07.440]  And you might need it to stay up for the late-night stuff.
[01:08.520 --> 01:12.320]  Also, DVD sales of all the discussions are in the vendor area on the 18th floor.
[01:12.460 --> 01:14.620]  They're burning them on the fly, from what I understand.
[01:14.760 --> 01:17.840]  So, if you missed a discussion, you can always pick up a copy.
[01:19.180 --> 01:24.360]  And also, again, please be nice to the hotel and leave their TVs alone.
[01:24.600 --> 01:27.540]  And there's a whole city to cause trouble in out there.
[01:27.740 --> 01:33.400]  So, please go meet our good friends, the NYPD.
[01:35.300 --> 01:37.320]  But, let's get on to our next discussion.
[01:39.180 --> 01:42.700]  Jacob Applebaum is a member of the Noise Bridge Hack Lab in San Francisco.
[01:43.080 --> 01:44.680]  He's also a professional photographer.
[01:44.920 --> 01:47.220]  You can see some of his amazing photographs on his website.
[01:47.540 --> 01:49.420]  And he's published in a lot of magazines.
[01:49.680 --> 01:51.800]  And he's been on Boing Boing about a bajillion times.
[01:52.660 --> 01:54.760]  He's also a developer on the Tor project.
[01:55.320 --> 01:59.540]  This discussion is advanced memory forensics, releasing the cold boot utilities.
[01:59.540 --> 02:01.240]  Let's give it up for Jacob Applebaum.
[02:15.510 --> 02:18.590]  Well, I'm going to readjust my resolution here.
[02:19.930 --> 02:21.610]  So, I'll carry on for a moment.
[02:21.870 --> 02:24.270]  Thanks to Lazlow, totally awesome guy.
[02:24.450 --> 02:25.590]  Also a really great photographer.
[02:26.030 --> 02:31.550]  And a couple of my co-authors are sitting over there in the corner as well, while I fix this.
[02:49.550 --> 02:53.630]  Yeah, what I wouldn't do for a mouse right about now.
[02:57.950 --> 02:58.430]  Great.
[03:02.130 --> 03:02.850]  There we go.
[03:03.710 --> 03:04.070]  Okay.
[03:04.390 --> 03:09.230]  So, as Lazlow was saying, I'm a member of the Tor project and also Noise Bridge.
[03:09.870 --> 03:16.050]  Though this project is only tangentially related to the Tor project, I'm interested just generally in security and forensics.
[03:16.270 --> 03:18.250]  And specifically, I have an interest in anti-forensics.
[03:19.190 --> 03:23.930]  Noise Bridge is where a lot of the work for the West Coast part of our team took place.
[03:24.110 --> 03:27.790]  Bill Paul and Seth Schoen from the EFF were working on this.
[03:27.790 --> 03:33.770]  Most, diligently, most of the time at our Noise Bridge meetings, but also other times at the EFF office.
[03:34.570 --> 03:38.150]  So, we had a ridiculous number of co-authors on our paper.
[03:39.390 --> 03:41.070]  This is the list of co-authors.
[03:42.290 --> 03:47.810]  Half of the team was Princeton, and they're pretty much the best computer scientists I've ever had the privilege of working with.
[03:47.970 --> 03:51.810]  They're incredibly smart, very humble, quick thinking, just wonderful people.
[03:51.810 --> 03:54.270]  And they're also really, really good hackers.
[03:56.450 --> 04:04.670]  So, basically, in the summer of 2007, I was hopped up on a lot of this MATE in Germany at the KS Communications camp.
[04:05.990 --> 04:25.450]  And Seth Schoen and I realized that it was possible, after seeing a small talk on memory forensics, to sort of create a memory stamp, which is this idea of creating a recognizable pattern in memory, and then taking that and searching for it after you've powered a machine off.
[04:25.690 --> 04:32.870]  And we had an IBM laptop, and that IBM laptop had memory retention times up to 25 seconds without cooling.
[04:33.450 --> 04:39.250]  And we realized, just by being able to inspect /dev/mem on a Linux machine, that this was possible.
[04:39.430 --> 04:46.170]  And we realized that /dev/mem, of course, in order to use that device, required a whole bunch of memory to be used, and it stomped on a lot of important bits.
[04:46.350 --> 04:49.150]  But we realized that the memory retention itself was quite interesting.
[04:49.490 --> 04:54.890]  There was a bunch of previous work, specifically by Skorv Borgatov and, of course, Peter Goodman.
[04:56.270 --> 05:00.190]  Nothing specifically about DRAM resistance, or persistence.
[05:00.190 --> 05:04.870]  So, basically, we realized that we could write some practical extraction tools.
[05:05.390 --> 05:07.910]  And those tools would be useful for all sorts of research.
[05:08.530 --> 05:17.310]  And, basically, the first thing that came to mind was that there are major security concerns with any sort of thing that relies on access controls of a computer.
[05:17.530 --> 05:30.730]  And, of course, if you're using some cryptography, and even if you wanted to securely use keys, if you can control when the machine is powered off, and you know that the memory will be retained for some amount of time, then it would be possible to extract the keys,
[05:30.770 --> 05:36.090]  even if the developer has gone to great lengths to stop you from having the keys.
[05:37.130 --> 05:41.710]  This is a sort of high-level overview of this.
[05:41.830 --> 05:43.330]  Our paper goes into a lot of detail.
[05:43.490 --> 05:46.010]  It talks about the retention times for different chips.
[05:46.910 --> 05:49.530]  The retention time can wildly vary.
[05:49.810 --> 05:52.070]  It can be something like half of a second.
[05:52.170 --> 05:53.090]  It can be 30 seconds.
[05:53.090 --> 05:57.610]  It can be, when cooled, it's pretty much uniformly no decay.
[05:57.890 --> 06:01.330]  If you do a soft reboot on a machine, it's also pretty much uniformly no decay.
[06:01.730 --> 06:09.290]  So, some of the things that we did in the paper were very useful when you have decay, and some of them were useful if you didn't have any decay.
[06:09.630 --> 06:16.970]  But, basically, both of them, both of those things are something you might encounter, depending on how you wanted to perform this research.
[06:17.830 --> 06:23.230]  So, there's also some videos that demonstrate it, and I won't play them, because you can just download them online.
[06:23.490 --> 06:24.730]  And there are a couple of caveats.
[06:25.170 --> 06:33.150]  A number of people here have mentioned that they were unable to reproduce certain parts of this research, and several of those people later told me that they had ECC memory.
[06:33.970 --> 06:40.670]  ECC memory generally scrubs the bits in the memory when it boots.
[06:40.970 --> 06:53.130]  The controller, basically, Intel's specs for certain memory controllers, specifically stipulates that in order to make sure that the ECC memory will be utilized properly so that you can have error correction, you need to scrub all of the bits.
[06:53.290 --> 07:02.530]  So, naturally, if you just reboot a machine and it has ECC memory, and you're using a memory controller that implements what Intel suggests, you will not see memory retention.
[07:02.790 --> 07:07.250]  But that isn't because the memory isn't actually there when you've done the reboot.
[07:07.390 --> 07:14.350]  It's that it's been specifically scrubbed, which can be useful if you have a machine that scrubs memory, and you can force a reboot upon detecting an event.
[07:14.350 --> 07:19.970]  But it does not actually mean that you aren't subject to these issues that I'm going to talk about.
[07:21.790 --> 07:25.130]  So, basically, these are the different file systems that we analyzed.
[07:25.710 --> 07:29.070]  We had BitLocker, FileVault, DMCrypt, TrueCrypt, and LoopAS.
[07:29.630 --> 07:31.310]  So, did anybody here use any of these?
[07:33.590 --> 07:34.050]  Cool.
[07:34.370 --> 07:34.550]  All right.
[07:35.870 --> 07:40.110]  So, BitLocker was simultaneously the weakest and strongest.
[07:41.490 --> 07:42.450]  It's kind of interesting.
[07:42.690 --> 07:45.810]  They basically have a mode where you turn...
[07:45.810 --> 07:47.250]  It's called BitLocker Basic.
[07:47.430 --> 07:49.770]  You turn the machine on, it gets you to a login screen.
[07:49.970 --> 07:52.890]  Well, at that point, the drive is already decrypted, and the AES key is in memory.
[07:53.410 --> 07:55.330]  And it relies on you not...
[07:55.330 --> 07:56.830]  Basically, being able to log in.
[07:57.750 --> 08:00.150]  And that is not very good, it turns out.
[08:01.650 --> 08:04.070]  Because there's no prompting, there's no pre-boot password.
[08:04.330 --> 08:05.930]  So, the key, once it's in memory, that's it.
[08:06.010 --> 08:06.310]  It's done.
[08:06.430 --> 08:06.790]  You win.
[08:08.370 --> 08:16.010]  The TPM, also, at certain select times, even though the key is in the TPM, that doesn't necessarily mean that the key stays in the TPM forever.
[08:16.170 --> 08:19.710]  In fact, during its normal usage, the key is copied out of the TPM.
[08:19.970 --> 08:29.650]  So, your sort of tamper-resistant, possibly, chip maybe could resist someone attacking it that way, but the way that it's used, it automatically attacks itself from this particular perspective.
[08:29.870 --> 08:32.170]  It's not necessary to attack the TPM at all.
[08:33.190 --> 08:40.770]  However, there are modes that BitLocker can be put into where it requires a pin, and it requires that you basically re-enter it all the time.
[08:40.910 --> 08:47.490]  It's not very practical for a server, because a server generally doesn't have an operator sitting at it, although it is a Windows machine, so we don't know.
[08:49.430 --> 09:00.310]  As far as FileVault goes, it was actually the most hilarious of all the ones we analyzed, because FileVault has a bug in LoginWindow.app.
[09:01.250 --> 09:10.590]  Basically, the way that this works is that you log in, and it keeps your login credentials in memory for the entire time you're logged in, even when you lock the screen, which is terrible.
[09:12.070 --> 09:13.510]  At least I thought it was pretty bad.
[09:13.670 --> 09:17.690]  When I reported the bug, I got about six emails from people saying, oh, I reported that bug like six years ago.
[09:17.770 --> 09:18.190]  It's still there?
[09:18.830 --> 09:24.930]  It turns out the reason it's there, according to one of my contacts at Apple Security, is because they used it.
[09:25.410 --> 09:30.890]  So they do privilege escalation in some way that requires them to take your password out of memory, and they don't want to prompt the user.
[09:31.210 --> 09:42.990]  And even though they have a framework for prompting the user, and getting this password from the user, there are times when, for whatever reason, they don't want to prompt the user, and they don't want to let them know they're elevating their privileges.
[09:43.590 --> 09:44.110]  Kind of strange.
[09:44.630 --> 09:45.770]  So they haven't fixed it yet.
[09:45.770 --> 09:49.610]  So if you see a Mac sitting here in sleep mode, It has its login and password in the memory.
[09:49.970 --> 09:51.490]  You can attack it with FireWire.
[09:51.750 --> 09:52.490]  You can do all sorts of stuff.
[09:52.590 --> 09:53.330]  It's a very bad bug.
[09:53.890 --> 09:54.850]  And it's pretty old.
[09:55.850 --> 10:00.190]  Sadly, GDM and Linux also has this problem, which I was kind of surprised about.
[10:00.290 --> 10:01.930]  I didn't find that someone else told me about it.
[10:02.350 --> 10:06.450]  I think it was Sherry Davidoff, who was with Intel Guardians, mentioned this.
[10:07.490 --> 10:18.170]  So that was great, though, because FileVault, basically, you need to have the SHA-1HMAC and, basically, the initialization vector, and the key.
[10:18.390 --> 10:19.970]  So you need to find several things in memory.
[10:20.190 --> 10:29.930]  But if you have the login and password, you can use a utility that Ralph Feynman and I wrote for the Congress a couple of years ago and, basically, just decrypt it without having to reconstruct the keys.
[10:30.090 --> 10:32.510]  So there are two possible ways to attack FileVault.
[10:33.470 --> 10:35.230]  It's... I mean, it's kid stuff.
[10:35.590 --> 10:37.990]  Like, FileVault is the easiest to break in that regard.
[10:39.190 --> 10:40.470]  DMCrypt was straightforward.
[10:41.750 --> 10:46.530]  Alex Halderman actually just wrote a small patch for, basically, taking the Rocky.
[10:47.270 --> 10:53.370]  And TrueCrypt was, I think, basically consistent with where it stored the things that were necessary.
[10:53.850 --> 10:58.510]  So if you knew a little bit about the memory layout, you could find the things that were necessary to decrypt it.
[10:58.950 --> 11:04.450]  And LoopAES, we didn't actually do the initial analysis, including LoopAES, because it was a little bit more complex.
[11:04.730 --> 11:06.750]  But it was just more confusing.
[11:07.210 --> 11:15.470]  Like, they store... they want to flip bits so that you don't leave memory persisting, because they don't want you to, I guess, oxidize the DRAM cells.
[11:15.690 --> 11:20.410]  I think this is Peter Goodman's basic attack from, like, 1992.
[11:20.810 --> 11:25.430]  So it was, like, flipping bits so you don't leave behind, like, a key that's imprinted in the chip itself that can be found.
[11:26.590 --> 11:31.310]  The irony of this is that means you keep twice as much keying information as necessary to reconstruct the key.
[11:31.630 --> 11:34.310]  So you have, like, you know, so that you can flip the bits.
[11:34.310 --> 11:38.850]  So that's good if you want to attack that, which is too bad.
[11:38.990 --> 11:43.430]  I really like LoopAES, but it turns out that it's, like, twice as vulnerable, I guess, in that regard.
[11:45.050 --> 11:48.270]  So we have five tools that we're releasing today.
[11:49.770 --> 11:54.750]  Primarily, they were written by Bill Paul, who, if you've ever used FreeBSD, he wrote your Ethernet driver.
[11:56.450 --> 11:57.130]  All of them.
[11:58.350 --> 12:08.770]  He also wrote Project Evil, which was the NDIS wrapper, basically emulating Windows so that you could use, you know, proprietary binary blobs for getting on Wi-Fi networks and stuff like that.
[12:09.130 --> 12:11.210]  The guy's, like, amazing guy.
[12:11.350 --> 12:14.390]  Works at Wind River, works on VXworks, just a badass engineer.
[12:14.770 --> 12:24.210]  He actually heard Seth Schoen and I talking about how we were having some trouble writing a memory dumper, an x86 assembler at a party, and he's like, well, you know, I could hack something up.
[12:24.290 --> 12:29.310]  So he went home from the party, and he wrote it, and, oh, I don't know, 48 hours.
[12:30.990 --> 12:31.970]  It was amazing.
[12:32.150 --> 12:34.490]  I mean, that guy is just amazing.
[12:34.670 --> 12:36.050]  Best engineer I've ever met.
[12:36.710 --> 12:43.830]  We also have, primarily written by Nadia and Alex over there, the ASFIX, ASKeyFind, and the RSAKeyFinder.
[12:44.470 --> 12:48.690]  The intellectual contributions here are definitely ASFIX and ASKeyFind.
[12:49.030 --> 12:53.190]  The BIOS MEME and EFI MEME are something that you could write.
[12:53.190 --> 12:58.210]  These ones were just specifically useful for what we wanted to do, and I'll get into each one in a second.
[12:58.370 --> 13:01.410]  And the RSAKeyFind, a lot of people have talked about doing this.
[13:01.510 --> 13:02.550]  Other people have implemented it.
[13:02.650 --> 13:05.930]  I've never seen a public implementation, so here's a public implementation.
[13:06.310 --> 13:09.450]  I think Nadia wrote it in just a couple of hours.
[13:10.070 --> 13:11.850]  She's like the crypto version of Bill.
[13:15.870 --> 13:21.310]  So there's one set of unreleased tools, which a lot of people have also asked me about, so I just wanted to mention this.
[13:21.430 --> 13:23.430]  The BitUnlocker tool is not going to be released.
[13:23.770 --> 13:33.170]  There is a file system component to the BitUnlocker where you can interoperate with BitLocker drives and anything that can support the, I think, Fuse system.
[13:34.230 --> 13:35.610]  That may someday come out.
[13:35.870 --> 13:43.970]  We were unable to reach the colleague that wrote that portion in time for this talk, but it's possible, though we never planned to release the fully automated exploit.
[13:44.190 --> 13:46.770]  Although a lot of people have asked for it, we aren't going to do that.
[13:47.490 --> 13:52.350]  We're interested in research, not attacks, I believe is the line that I am going with.
[13:54.590 --> 13:56.270]  So I just want to stress this.
[13:56.770 --> 13:57.570]  Not attack tools.
[13:58.110 --> 14:01.170]  These tools are the minimum we require to carry out our research.
[14:01.450 --> 14:03.530]  They're limited in what they do.
[14:04.010 --> 14:05.090]  Specifically, they do everything.
[14:07.310 --> 14:09.910]  But they are limited in that we don't have them automated.
[14:10.150 --> 14:11.070]  They are not weaponized.
[14:11.250 --> 14:12.670]  They require some user interaction.
[14:12.970 --> 14:20.550]  It's trivial to change this, but if you're doing this in a lab setting, it isn't necessary to do anything more than what we have.
[14:21.930 --> 14:27.990]  There's some room where you could add some timers to automatically shut the machines down and then boot them back up with a Wake Online packet.
[14:28.170 --> 14:29.070]  That's something that we did.
[14:30.570 --> 14:33.350]  If you care about that kind of timing stuff, you can definitely contact us.
[14:33.350 --> 14:36.070]  We can help you set up a laboratory to verify our results.
[14:37.670 --> 14:39.990]  Some of them will actually work in MinGW.
[14:40.490 --> 14:44.270]  So if you are on Windows and you want to build them, you can probably do that.
[14:44.470 --> 14:45.610]  It should work just fine.
[14:47.010 --> 14:51.330]  So as I was saying, Seth and I wrote this god-awful assembler dumper.
[14:51.450 --> 14:53.610]  Basically, it was a special boot block and you booted it.
[14:53.750 --> 14:57.150]  And it was like Ed for memory.
[14:58.730 --> 14:59.930]  It was horrible.
[15:00.090 --> 15:01.070]  It was so bad.
[15:01.070 --> 15:03.830]  We worked in QMU a lot to get it going.
[15:04.090 --> 15:04.950]  And eventually we got it working.
[15:05.110 --> 15:08.550]  And we got the first 640K of memory without stomping on it.
[15:08.630 --> 15:10.710]  And we were pretty sure that we had this.
[15:11.070 --> 15:11.810]  We threw it away.
[15:11.930 --> 15:12.650]  It was total crap.
[15:13.910 --> 15:19.230]  What Bill wrote in about an hour was so much better that it wasn't even worth looking at assembly ever again.
[15:19.350 --> 15:20.910]  Writing it in C was a much better idea.
[15:21.270 --> 15:24.790]  We were thinking too hard about the problem and we went in the wrong direction.
[15:26.310 --> 15:31.530]  So that brings us to the actual tool, BIOS Mem Image, which is a cool package.
[15:31.730 --> 15:32.490]  It's really useful.
[15:33.870 --> 15:37.610]  It is specifically supporting both 32 and 64-bit machines.
[15:37.630 --> 15:39.010]  And it's been tested on both.
[15:39.350 --> 15:43.230]  So you should definitely be able to use this and have no trouble.
[15:43.430 --> 15:45.910]  And it's written in C and it's very, very small.
[15:45.910 --> 15:48.030]  So the Pixie Boot Dumper is really great.
[15:48.230 --> 15:50.790]  You build the Pixie Dump utility.
[15:51.210 --> 15:55.950]  One sits on basically on a DHCP server and it's just a little payload.
[15:56.590 --> 16:01.810]  And you can basically, if you want to, we have our payload down to 3 kilobytes in size.
[16:02.490 --> 16:03.410]  And that's total.
[16:03.550 --> 16:04.430]  So you boot the machine.
[16:04.850 --> 16:08.070]  And once you've booted the machine, it gets a DHCP lease.
[16:08.270 --> 16:12.370]  It loads this program into memory and it's 3 kilobytes.
[16:12.530 --> 16:14.110]  So you don't stomp on a lot of bits.
[16:14.110 --> 16:23.570]  And depending on the operating system that you're specifically analyzing while doing your research, you will see that you are nowhere near the bits that are important in that operating system.
[16:24.570 --> 16:26.590]  But some people could try to get crafty.
[16:26.770 --> 16:31.490]  Maybe put like their secret keys in video, card memory, space, you know, stuff like that.
[16:32.390 --> 16:33.270]  It doesn't matter.
[16:33.450 --> 16:34.590]  This utility would probably find them.
[16:34.770 --> 16:36.870]  Except someone that wrote it specifically against this utility.
[16:37.070 --> 16:40.630]  But in a little bit, we'll show you how you can deal with that too.
[16:42.750 --> 16:44.470]  So basically, this is great.
[16:44.650 --> 16:49.390]  It's the best part of the utility suite, I think, because it's the most tested and it's so useful for automation.
[16:50.570 --> 16:55.130]  Being able to shut a machine down and wake it up and send it this payload again is really good for timing, measurement, stuff.
[16:55.510 --> 17:03.910]  So you could probably make it smaller by simply removing every, like, spurious printf call and all sorts of other things.
[17:04.090 --> 17:06.910]  So it's probably... you could probably hand optimize the assembler.
[17:07.190 --> 17:10.110]  You could get rid of some stuff that isn't necessary that GCC puts into it.
[17:12.590 --> 17:14.910]  Bill wanted also to have a disk boot dumper.
[17:15.010 --> 17:17.950]  We originally wrote one that was a syslinux program.
[17:18.130 --> 17:19.930]  And basically, it was a COM32 program.
[17:20.150 --> 17:22.730]  You booted syslinux and it stomped on a ton of bits.
[17:22.890 --> 17:27.550]  And it did all this stuff that made it possible to program very easily to dump the memory.
[17:27.550 --> 17:33.790]  And it was nice because it meant that all we had to do was, you know, turn the machine on with syslinux and run this really small C program and we were done.
[17:34.530 --> 17:36.930]  Bill was unhappy with this and thought we were being lazy.
[17:39.050 --> 17:47.290]  So, Bill... basically, being Bill, he had an iPod, one of the old minis, and that was the only USB disk that he had.
[17:47.410 --> 17:55.990]  So he figured out how to repartition it so that he could simultaneously boot and do memory dumps while also being able to listen to MP3s.
[17:57.930 --> 18:01.990]  Because, like, no joke, this wasn't a specific weaponization.
[18:02.210 --> 18:03.970]  This was the only USB disk he had.
[18:04.430 --> 18:06.850]  And he also only had one MP3 player.
[18:08.630 --> 18:11.190]  So what he did was pretty genius.
[18:11.370 --> 18:15.350]  He basically has a small partition for memory dumps and a small partition for MP3s.
[18:15.450 --> 18:18.350]  And the bootloader block isn't important to the iPod.
[18:18.470 --> 18:20.190]  And the firmware is stored somewhere else.
[18:20.230 --> 18:21.610]  So it's pretty simple.
[18:22.250 --> 18:26.410]  You know, the package actually explains exactly how to set up an iPod to do this.
[18:26.410 --> 18:31.530]  So, in theory, you could combine this with other iPod-based utilities if you wanted to.
[18:33.170 --> 18:33.950]  But it's great.
[18:34.190 --> 18:38.010]  Because it was just, like, I couldn't bring the USB disk over fast enough.
[18:38.210 --> 18:40.050]  So he wrote this before I got on the bus.
[18:42.390 --> 18:43.590]  It's ridiculous, but it's true.
[18:43.990 --> 18:47.810]  This utility is limited because we didn't feel like putting a lot more time into it.
[18:48.370 --> 18:50.910]  Basically, it captures a single dump to disk.
[18:51.170 --> 19:01.330]  So the first thing we thought about improving was probably to change this memory dump program so that it would dump and it would set an ID and it would have a couple of things from the system.
[19:01.430 --> 19:04.690]  Collecting some metadata, like the clock, things like that if we wanted to.
[19:05.650 --> 19:08.750]  It wasn't really a necessity, so we didn't bother.
[19:08.750 --> 19:19.190]  But if you were going to expand this to do timing on video memory decay in addition, or you wanted to see how it behaved, you could do that if you wanted to with this tool.
[19:19.390 --> 19:19.930]  It's pretty simple.
[19:20.170 --> 19:23.890]  And, of course, you could do that with the Pixie payload, too.
[19:25.410 --> 19:33.910]  So, Bill also, just ridiculously so, wrote this and he ported the BSD TCP/IP stack to EFI.
[19:36.030 --> 19:39.190]  Also, in like short amounts of time, it's crazy.
[19:39.890 --> 19:46.250]  This is only 32-bit because Apple has a lot of really undocumented interfaces.
[19:46.670 --> 19:49.870]  And basically, even though they use EFI, it's like Apple's special EFI.
[19:52.070 --> 19:55.130]  So, this works on Mac minis that are 32-bits.
[19:55.570 --> 20:01.850]  And it also works on Powerbooks that are, I guess, Powerbooks that are 32-bits as well.
[20:01.990 --> 20:03.450]  It sort of had some problems.
[20:03.650 --> 20:05.510]  We tried it on a 64-bit machine.
[20:05.530 --> 20:07.630]  We weren't sure that it was a 64-bit machine.
[20:07.750 --> 20:10.150]  And it kind of went crazy and crashed.
[20:10.330 --> 20:12.990]  And the person whose machine we were owning was very unhappy with that.
[20:13.550 --> 20:21.890]  But we eventually fixed their machine and figured out that they had the firmware password enabled and it was a little bit difficult to get around that with the technique we had tried just for rebooting.
[20:22.170 --> 20:27.110]  But eventually, we were able to get some 64-bit code bootstrapped.
[20:27.330 --> 20:30.590]  And it did work, but we didn't put any time into it.
[20:30.670 --> 20:33.010]  So, the only thing that's actually working is the 32-bit stuff.
[20:33.130 --> 20:37.150]  And I think some of the beginnings of the 64-bit stuff are also in here.
[20:37.150 --> 20:43.930]  So, it wouldn't be too much time, but it's probably not worth anyone's time to do this.
[20:45.450 --> 21:02.170]  Although, combined with the fact that Apple sort of refuses to fix that bug in any reasonable amount of time, five years, it might be worth making it 64-bit to measure decay of all the different Macs and to present that table to Apple and say, hey, this decay is a real problem.
[21:03.590 --> 21:09.190]  You know, it doesn't work well for me and my particular security culture of whatever company or whatever you're affiliated with.
[21:09.530 --> 21:12.330]  Although, I don't think anything will change their mind with how that works.
[21:12.490 --> 21:14.290]  So, it's probably not worth improving on it.
[21:15.970 --> 21:20.630]  Also, the tool chain, getting the tool chain set up for building EFI stuff is...
[21:21.310 --> 21:22.070]  It's interesting.
[21:23.250 --> 21:24.430]  And not in a fun way.
[21:25.270 --> 21:30.590]  So, the three tools that are useful, and I have a good anecdote about one of them, which I'll tell you in a second.
[21:31.190 --> 21:40.250]  One is the AES fix, which is something that Nadia finished writing like a couple of days ago and then improved it like 100% in speed improvements or something like that.
[21:40.350 --> 21:45.350]  Or, Alex improved it 100% in a couple of hours before getting on the train to come over here from Princeton.
[21:47.070 --> 21:51.150]  It's basically an implementation of the error-correcting code that we talked about in our paper.
[21:51.450 --> 21:54.750]  It's a very simple, unidirectional bit correction.
[21:55.070 --> 21:58.350]  So, it can unidirectionally correct up to 15% of errors.
[21:58.350 --> 22:07.950]  And to give you an idea about the kind of errors that we saw when doing these analyses, it was basically 0.1% error.
[22:09.050 --> 22:10.950]  And if we cooled it, it was pretty much zero.
[22:12.130 --> 22:17.110]  So, after an hour in liquid nitrogen, it's not even necessary.
[22:17.270 --> 22:19.550]  But if you had decay, this tool would be very useful.
[22:19.550 --> 22:21.790]  When you combine it with the AES key finder.
[22:22.270 --> 22:25.530]  Basically, it finds 128-bit and 256-bit keys.
[22:26.830 --> 22:30.690]  And the keys that it spits out are, you know, tells you the offset.
[22:30.970 --> 22:31.670]  Everything that you need.
[22:31.850 --> 22:32.790]  Nice little progress bar.
[22:32.870 --> 22:33.210]  It's great.
[22:33.630 --> 22:35.610]  And it finds the keys in memory and it reconstructs them.
[22:36.630 --> 22:39.070]  If it is necessary, you can use the AES fix with it.
[22:39.310 --> 22:43.710]  And the RSA key finder is, again, it's limited in how it has been tested.
[22:44.110 --> 22:45.910]  Tested with Apache on Linux, basically.
[22:45.910 --> 22:48.190]  And it successfully finds RSA keys.
[22:48.870 --> 22:51.010]  So, that might be of use.
[22:52.830 --> 22:54.250]  I'm not sure for what.
[22:57.110 --> 22:59.670]  If you want to download all this, this is the URL.
[23:04.730 --> 23:06.570]  It's blue on blue for a reason.
[23:09.170 --> 23:12.430]  And that reason is that I was having a little bit of trouble with my PowerPoint.
[23:14.790 --> 23:16.910]  All right, it's a crappy knockoff PowerPoint.
[23:16.910 --> 23:22.810]  But it's basically the same URL as the PDF we have.
[23:23.030 --> 23:26.830]  It's sitp.princeton.edu slash memory slash code.
[23:27.110 --> 23:32.850]  So, if you just Google for the cold boot attacks, the first hit in Google, and then slash code, you'll be able to find it.
[23:34.070 --> 23:37.090]  And the PGP signatures are actually not up right now.
[23:37.130 --> 23:38.990]  So, you might want to wait if you're using this network.
[23:40.970 --> 23:53.050]  So, one of the tools that was sort of instrumental in attacking FileVault was VileFault, which Ralph Weinman and I wrote, I don't know, some number of years ago in Germany.
[23:54.370 --> 24:00.030]  And basically, it's an open source implementation of FileVault for decrypting.
[24:00.770 --> 24:05.810]  So, you can take an image, and if you have the password, you can pass the password into the program, and it'll decrypt it.
[24:06.110 --> 24:15.890]  And at the same time, you can also, if you don't have the password, toss in an FPGA, and brute force it at about 2,000 keys a second, or in software, about 300 keys a second.
[24:16.050 --> 24:20.110]  And FPGAs run about $1,000 from Pico Computing.
[24:20.110 --> 24:22.230]  So, kind of useful tool.
[24:24.610 --> 24:30.210]  I was actually contacted by the Department of Homeland Security recently, which is really funny on so many levels.
[24:32.290 --> 24:35.050]  I have no idea why they thought it was a good idea to talk to me.
[24:35.310 --> 24:42.710]  But, basically, they were trying to get FileVault to work with VileFault, and they were having a bunch of trouble.
[24:42.910 --> 24:46.270]  Like, they just could not, for the life of themselves, crack this disk image.
[24:46.930 --> 24:57.010]  It was really interesting, too, because in the email, the thing that they told me was that they were trying to break the FileVault image so that they could find some evidence to hold some guy.
[24:59.830 --> 25:08.650]  So, I said, well, you know, I'm not really sure that I feel comfortable with, you know, an intern for the Department of Homeland Security contacting me to break into someone's computer when they aren't actually accused of a crime.
[25:09.730 --> 25:15.110]  And they said, well, you know, if you don't believe that we're with the DHS, we're happy to send you a photograph of us in headquarters.
[25:19.080 --> 25:21.320]  And I said, well, you know, only with a shoe on your head.
[25:26.720 --> 25:28.340]  And it went back and forth for a little while.
[25:28.400 --> 25:34.200]  And they said, well, you know, if you're not willing to give us the key finder code, you know, we'll have an agent contact you about the key finder code.
[25:34.460 --> 25:35.600]  And I said, yeah, you know, feel free.
[25:35.740 --> 25:39.500]  I don't know if you're actually from the DHS, because they were sending it from their .edu address.
[25:39.600 --> 25:44.060]  And I thought it was just some clever social engineering ruse that was actually not clever at all.
[25:44.960 --> 25:49.680]  And then I got an email from an actual agent at the DHS who actually authorized them.
[25:49.780 --> 25:53.660]  And looking at the mail headers, you could see all the mail systems that they used inside and out of the DHS.
[25:53.940 --> 25:59.420]  And sure enough, he authorized me to give them all of the things that they had asked for, whatever it was.
[26:01.000 --> 26:02.440]  And I thought that was kind of interesting.
[26:02.460 --> 26:05.600]  So I ignored their email for a while, and they wrote me a couple more times.
[26:07.200 --> 26:12.840]  And they wrote me to tell me that the key finder code, they had re-implemented it from our paper, and that it didn't work.
[26:13.300 --> 26:16.640]  They were trying to attack the sleep image on a particular person's computer.
[26:16.800 --> 26:22.680]  And I thought it was really funny, because they didn't ever actually send me any of the data that I'd asked for.
[26:22.680 --> 26:28.460]  And I don't think I would have helped them, but I was just curious if I could contact the defense with all of this evidence that's being mishandled.
[26:32.820 --> 26:35.360]  And, you know, unfortunately they didn't.
[26:35.520 --> 26:50.100]  But if you know anyone that works with the Immigration and Customs Enforcement ICE Division for the Department of Homeland Security, you might want to tell them that they have some, like, maybe smart interns working with some, maybe, smart agents.
[26:51.220 --> 26:53.960]  But that maybe I wouldn't trust them doing law enforcement.
[26:54.240 --> 27:04.100]  It seems kind of crazy to contact someone that you don't know over the Internet, and offer to send them evidence without using any crypto, and, like, beg for zero day.
[27:06.560 --> 27:11.380]  And it's just, I mean, it's unbelievable, unbelievable that they were doing that.
[27:11.540 --> 27:12.980]  And I felt like it was pretty ridiculous.
[27:13.180 --> 27:17.540]  Eventually they did say that they had a warrant to collect the computer.
[27:17.540 --> 27:25.700]  And I was really surprised because I guess that maybe they didn't read any of the cold boot stuff, and they'd only seen the vile fault stuff, but they had re-implemented the key finder.
[27:25.800 --> 27:34.180]  So I guess that they didn't try any of the other, like, thousand attacks against Mac OS X to get these passwords.
[27:34.420 --> 27:38.800]  But it's kind of sort of like an interesting tangent about vile fault.
[27:38.800 --> 27:41.340]  And I'm sure they're watching this video.
[27:41.740 --> 27:43.660]  So, hey, guys.
[27:50.060 --> 27:54.600]  Anyway, so I didn't really feel like there was anything unethical about any of this code being released.
[27:54.700 --> 28:00.320]  And I thought it was a good idea because I thought that it would definitely push forward this code in a good direction.
[28:00.320 --> 28:02.460]  And I also thought it would push forward countermeasures.
[28:02.920 --> 28:09.740]  I really think it's a good idea to not simply trust software crypto as the, like, sort of, like, perfect solution.
[28:10.000 --> 28:12.560]  I heard someone talking about database security in the other room.
[28:12.640 --> 28:13.600]  And they were saying, like, oh, it's great.
[28:13.740 --> 28:15.320]  We use, like, crypto for this part of it.
[28:15.420 --> 28:16.220]  And it's, like, unbreakable.
[28:18.980 --> 28:19.520]  I don't know.
[28:19.580 --> 28:20.320]  It's a process, right?
[28:21.280 --> 28:30.900]  So in our paper, we said that it would be great if someone wrote a BIOS because all of our tools do actually have some amount of destruction involved.
[28:30.900 --> 28:34.520]  And, you know, destruction isn't necessarily negative.
[28:34.580 --> 28:37.640]  You need to destroy to create, to paraphrase from a famous anarchist.
[28:38.700 --> 28:44.420]  But it was not what we wanted for anything that was, I guess, pristine copies.
[28:44.820 --> 28:48.480]  So we didn't ever implement any of the BIOS stuff.
[28:48.620 --> 28:53.380]  But we did mention that if someone wanted to implement the BIOS stuff, that it would be, you know, quite useful.
[28:53.380 --> 28:56.660]  And that all you would need is one motherboard per electrical type.
[28:57.300 --> 28:58.680]  And so someone did.
[28:59.120 --> 29:01.580]  And they contacted me three or four days ago.
[29:01.720 --> 29:02.680]  And they wrote this program.
[29:02.840 --> 29:03.800]  It's called Core Info.
[29:03.980 --> 29:07.540]  And it's a plug-in to the Core Boot project.
[29:07.900 --> 29:10.340]  And basically, it's a BSD-licensed library.
[29:10.540 --> 29:12.100]  And it's already pre-built.
[29:12.240 --> 29:14.300]  It comes in a QMU image.
[29:14.300 --> 29:17.940]  So you can just go to coreboot.org slash QMU.
[29:19.160 --> 29:24.860]  And there's a specific lib payload that you can't read, probably.
[29:26.260 --> 29:27.360]  Just add that in.
[29:27.560 --> 29:28.560]  Toss in QMU.
[29:29.080 --> 29:29.860]  Start it up.
[29:30.080 --> 29:34.020]  And it will walk you through all of the memory.
[29:34.160 --> 29:35.360]  It can dump NVRAM.
[29:35.440 --> 29:37.360]  It can do all sorts of useful stuff that a BIOS can do.
[29:37.820 --> 29:44.380]  And using this, it would be possible to do analysis on decay where you didn't trample on any of the bits of memory.
[29:44.380 --> 29:49.160]  So you could see if certain parts of bits stayed longer, for example.
[29:49.820 --> 30:04.740]  Things that are constantly overwritten by the BIOS and only contain BIOS information, you might see that even with unidirectional decay or bidirectional decay or whatever kind of decay that you're going to run into, you might see that those things have the phenomenon...
[30:04.740 --> 30:12.080]  Like, those particular bits will have the phenomenon that Peter Goodman talked about, where the memory specifically has been oxidized in a specific state.
[30:13.020 --> 30:15.180]  So you could do more analysis using this tool.
[30:15.320 --> 30:16.200]  And I thought that was pretty great.
[30:16.320 --> 30:23.980]  I suggested to him that it might be useful to have a motherboard and for each different electrical type, flash that motherboard with Core Boot.
[30:24.200 --> 30:27.300]  And then you could have a single memory module that Core Boot would use.
[30:27.400 --> 30:29.780]  So you don't even need to modify Core Boot beyond loading the library.
[30:30.260 --> 30:35.840]  And then you can simply take the memory you want to analyze and stick it in the second slot after cooling it.
[30:36.660 --> 30:38.820]  And then you wouldn't stomp on any of the bits.
[30:38.880 --> 30:41.960]  And you could repeat for each different memory chip.
[30:42.100 --> 30:50.260]  And you would be able to sew all of the memory images back together and have an exact memory image that was the last thing that the computer did before you pulled the power.
[30:52.620 --> 30:56.620]  So that's kind of one-upping Bill a little bit, but not by much.
[30:57.400 --> 30:58.500]  But it's really great.
[30:58.660 --> 31:04.000]  And the guy that wrote it, I guess his name is probably pronounced Ui Hermann, is a guy from the KS Computer Club, I think.
[31:04.980 --> 31:07.800]  So he's probably going to talk about this at the 25C3.
[31:07.960 --> 31:12.680]  And if you guys all like hope and you haven't been to Germany, I highly recommend you come to the Congress.
[31:13.460 --> 31:16.300]  It's definitely the best European event I've ever been to.
[31:18.240 --> 31:22.460]  So I spent a lot of time thinking about countermeasures against all of the tools that I just mentioned.
[31:22.880 --> 31:27.600]  Not so much against the previously hypothetical BIOS, but some.
[31:28.180 --> 31:35.020]  And I talked with a number of, I guess, pretty smart people, a lot smarter than I am, about different possible countermeasures.
[31:35.200 --> 31:39.460]  And one of the things that a lot of people really leaned on was the idea of case intrusion.
[31:39.620 --> 31:40.500]  And I think it's bunk.
[31:40.780 --> 31:43.540]  I don't think that case intrusion is really ever going to work.
[31:43.540 --> 31:57.000]  Because if they know what kind of case intrusion you have, you can simply raise the bar so they have to hack that before they get to the actual phenomenon that exists with this memory that you have in your machine.
[31:58.920 --> 32:00.900]  There's a paper that someone wrote.
[32:00.900 --> 32:03.860]  It was linked on a Metafilter post about our work.
[32:04.220 --> 32:09.900]  And basically, it's the idea that you have sort of like a token-based authentication.
[32:10.180 --> 32:11.740]  Like you have like a phone of some sort.
[32:12.040 --> 32:14.040]  And you are sitting next to your laptop.
[32:14.280 --> 32:16.480]  And when you walk away, you have a system daemon that's running.
[32:16.860 --> 32:25.980]  And when your device reaches a certain threshold of a proximity that you think is too far away, then all of the main system memory is encrypted to a key.
[32:26.240 --> 32:28.280]  And it's asymmetrically encrypted to another key.
[32:28.380 --> 32:30.700]  And it's sent to your phone that can then decrypt it.
[32:30.700 --> 32:36.980]  When it gets back in range, there's a very small program that can decrypt the memory that's sitting around.
[32:38.200 --> 32:41.960]  And the phone, of course, has some sort of conversation with the computer.
[32:42.240 --> 32:44.080]  And then, you know, it decrypts all the memory.
[32:44.260 --> 32:48.860]  And of course, the whole time that that's happening, everything you were doing on your laptop is like totally frozen.
[32:49.100 --> 32:53.120]  And that's completely awesome research for very specific use cases.
[32:53.120 --> 33:02.360]  But it is not so great for everyone else that doesn't have those specific set of not using the Internet, not running a server, like a mail server.
[33:02.520 --> 33:04.060]  That wouldn't work for a mail server at all.
[33:04.860 --> 33:10.540]  So it's a creative solution, but it doesn't really actually help, I don't think.
[33:11.380 --> 33:18.640]  And, you know, a lot of people would say that this requires physical access, but we live in an era where physical access is pretty much guaranteed to law enforcement.
[33:21.100 --> 33:30.060]  If you've recently read about any of the national security letters that have been handed out to ridiculous numbers of organizations, they include a gag clause.
[33:30.260 --> 33:34.160]  And it's pretty much the most undemocratic thing that I can think of at the moment.
[33:34.300 --> 33:38.620]  And that's saying a lot, considering what the Bush administration has done in the last eight years.
[33:39.020 --> 33:45.280]  But basically, it means that the police can come to your house in the middle of the night because your neighbor called them and said you're a terrorist.
[33:45.600 --> 33:50.000]  And they can analyze all of your computers and never tell you that they were there.
[33:50.960 --> 33:56.500]  And so it seems to me that probably physical access is something that you really can't stop.
[33:56.760 --> 34:00.660]  And these attacks, unfortunately, are sort of a problem.
[34:00.800 --> 34:09.800]  And these utilities hopefully will facilitate research in a direction that will make physical access less interesting when you have, say, you don't have a hardware token.
[34:11.340 --> 34:15.380]  So potentially there are some workarounds, but it's very difficult.
[34:15.380 --> 34:18.440]  So one thing that might be useful, though, is temperature sensors.
[34:19.540 --> 34:37.740]  And at CANSECk West this year, Theo De Raadt was talking with Bill and I about basically adding in some patches to OpenSSH that would allow you to have support for mAdvise being specifically patched for a kill first bit.
[34:37.880 --> 34:44.100]  So you could say, I want all of these bits of memory to be killed first when someone calls a specific panic function.
[34:44.100 --> 34:45.620]  And that's great.
[34:45.820 --> 34:54.520]  So you can change the threshold of the attack to, you know, something like one millisecond as opposed to just forever sitting there when an alert happens.
[34:54.780 --> 34:57.240]  But usually you get like a note like, oh, case has been opened.
[34:57.660 --> 34:58.380]  Not so useful.
[34:59.060 --> 35:12.360]  So it's possible that you could have something like that combined with the DDR3 chips that actually have an I2C bus that allows you to set an interrupt and say, like, if the temperature on the chip drops below a certain threshold, throw an interrupt.
[35:12.740 --> 35:13.940]  At least this is what Theo said.
[35:14.000 --> 35:15.220]  I haven't seen one of these chips yet.
[35:16.600 --> 35:21.980]  Throw an interrupt and then SensorsD can pick it up and say, oh, we have like a cooling event that should never occur.
[35:22.100 --> 35:23.440]  And if this has occurred, we're being attacked.
[35:23.900 --> 35:30.540]  And he put a bunch of time into clearing a bunch of arbitrary memory that's just sitting around because he realized you can get it for free.
[35:31.080 --> 35:36.780]  So OpenBSD did take some proactive measures and that's pretty useful, I think.
[35:37.060 --> 35:40.680]  And maybe someone else will pick them up in the other operating systems that they might use.
[35:41.500 --> 35:45.300]  But measuring different kinds of state change and graphing it over time would probably be useful.
[35:45.460 --> 35:52.960]  And then when you see something that's out of the ordinary, potentially you could do something with it, like react with the kill first bit.
[35:53.820 --> 35:58.080]  But basically nothing is going to be 100% in this type of attack.
[35:58.500 --> 36:00.880]  And you can combine it with other issues.
[36:01.240 --> 36:04.960]  And anyway, these are some of the other things I mentioned.
[36:05.300 --> 36:07.760]  The hardware crypto module is something that's kind of nice.
[36:08.440 --> 36:27.260]  I'm hopeful that someone can convince Hikari to work on a sort of poor man or poor woman's FPGA crypto co-processor because it would be nice to have a sort of generic PCMC card you could just slide into a laptop and all the crypto operations take place there.
[36:27.420 --> 36:29.020]  All the keying, everything takes place in that.
[36:29.200 --> 36:33.140]  Combine it with a smart card for some sort of authorization, possibly even key storage.
[36:33.880 --> 36:37.600]  And then you would definitely change the attack surface a great deal.
[36:38.020 --> 36:44.400]  The IBM crypto co-processors are like gigantic things and you probably can't afford one.
[36:44.500 --> 36:45.000]  I can't.
[36:45.760 --> 36:49.900]  And I went to IBM ZRL in Zurich to talk with them about it.
[36:49.900 --> 36:54.020]  And they said, you know, they thought they could defend pretty well against this.
[36:54.140 --> 37:03.120]  But basically the co-processor is something that's like very niche market and it isn't something that's probably going to work out very well for a lot of people.
[37:03.300 --> 37:08.440]  I mean, your software probably won't take advantage of the crypto co-processor, so it doesn't really matter if you have it.
[37:08.560 --> 37:10.720]  So it would require a substantial amount of work.
[37:12.000 --> 37:16.000]  And, of course, it just becomes slightly harder to analyze when you put it in hardware.
[37:16.000 --> 37:21.580]  And, I mean, as Karsten Nohl has shown, hardware is not something that is impossible.
[37:21.840 --> 37:31.140]  And, in fact, if anything, it will keep out a number of people that might see some things that in their particular domain of knowledge are like obvious bugs.
[37:31.280 --> 37:34.160]  The people that work on hardware might not notice them as obvious bugs.
[37:34.360 --> 37:45.020]  And so it changes, again, who the attacker is and who can pull off this type of thing, but it really isn't a magic solution of any sort.
[37:45.240 --> 37:47.700]  And, of course, FlyLogic can rip anything apart.
[37:47.960 --> 37:51.000]  And if there's a problem with hardware, it's done.
[37:51.320 --> 38:01.280]  So, anyway, what we'd really like to see, or at least what I'd like to see, is all of you downloading our tools and using them.
[38:01.760 --> 38:07.820]  And if you have time, catalog the memory chips that you're using and the retention times that you see.
[38:09.060 --> 38:11.440]  See if you're using ECC memory, non-ECC memory.
[38:11.660 --> 38:13.760]  There are a couple of other caveats that we mentioned in our paper.
[38:14.760 --> 38:16.500]  And make suggestions for countermeasures.
[38:16.780 --> 38:19.860]  So we can sort of, like, get on with the next iteration of this.
[38:20.460 --> 38:29.840]  Now that it's basically possible to read all this memory, even with the power out on a computer, it should be interesting what people come up with.
[38:30.160 --> 38:34.840]  Of course, if you can't afford liquid nitrogen or you don't have time, you can get a can of canned air.
[38:34.840 --> 38:38.460]  And canned air usually has the chemical tetraflora ethane in it.
[38:38.800 --> 38:42.020]  And basically, if you turn it upside down, it'll burn your finger.
[38:42.200 --> 38:43.300]  It's a cold burn.
[38:43.500 --> 38:48.440]  And if that happens, you can use that on memory, potentially, safely.
[38:49.260 --> 38:51.560]  And it should cool the memory significantly.
[38:51.900 --> 38:56.180]  At least enough for you to transport it to another machine with a core boot BIOS to do the analysis.
[38:56.500 --> 39:02.040]  Or enough to, you know, specifically set a timer before you set a WakeOnline packet and send it back to do measurements.
[39:04.780 --> 39:09.880]  So, if anyone has any questions, I'd like to take some...
[39:09.880 --> 39:11.880]  There's a microphone back there, I think.
[39:14.470 --> 39:16.570]  I'm kind of nervous it's Rob, you know.
[39:17.390 --> 39:18.450]  Don't worry about it.
[39:18.610 --> 39:19.030]  Hello?
[39:21.570 --> 39:26.330]  It would seem the adversary, if you look at...
[39:26.330 --> 39:32.030]  You seem to dismiss case switches and case intrusion things too quickly.
[39:32.930 --> 39:34.410]  The adversary is well-funded.
[39:34.590 --> 39:39.790]  The adversary needs to spend a lot of money if they built this generic case-locking solution that works for everybody.
[39:40.130 --> 39:42.410]  Because, of course, if you can study it, you can break it.
[39:43.270 --> 39:49.710]  Given that we are not well-funded, but that we all know how this stuff works, we can all build slightly different case intrusion things.
[39:49.890 --> 39:55.230]  And the thing is, if it's a one-off, the adversary doesn't have another case to study to see if they can break it.
[39:55.490 --> 40:01.550]  So, the sort of the maker movement approach to case intrusion is, I think in my mind, is actually quite powerful.
[40:01.690 --> 40:05.170]  The fact that it's a one-off is a unique feature.
[40:05.810 --> 40:06.230]  Absolutely.
[40:06.550 --> 40:07.070]  I think...
[40:07.070 --> 40:17.110]  I don't want to dismiss that if you have a lot of outside world inputs, and you know what you think that they should be, and you measure them, you might be able to find interesting things that are useful to you.
[40:17.510 --> 40:20.350]  But take, for example, I think it's about $250.
[40:20.770 --> 40:25.610]  There's a device that you can use that will sync up with the power of a server.
[40:26.210 --> 40:28.590]  And it also has a UPS built into it.
[40:28.730 --> 40:35.130]  You can also make a vampire tap for the Ethernet cable and basically hook the Ethernet cable into itself so you don't lose link.
[40:35.350 --> 40:43.750]  Chop the Ethernet cable and take that power, the UPS device, and roll the server out of the colo.
[40:44.390 --> 40:52.250]  And basically take that to a place where you have a large vat of liquid nitrogen and pull the power at the exact same second that you drop it into the liquid nitrogen.
[40:52.990 --> 40:56.330]  I don't know how you can defend against that with, like, one-off case designs.
[40:56.450 --> 40:59.890]  I think that you could defend against someone who is not going to do that.
[40:59.890 --> 41:04.850]  But that attack, for the cold boot attack specifically, I think is...
[41:04.850 --> 41:08.670]  I mean, that's really hard to defend against without having a secure co-processor.
[41:08.810 --> 41:15.910]  And even a secure co-processor is only as secure as some arbitrary number that has been pulled out, like a million dollars' worth of equipment secure.
[41:16.290 --> 41:21.210]  And so I definitely think for most people what you suggest is a good idea, but it's...
[41:21.210 --> 41:23.470]  A mercury switch, for instance.
[41:23.850 --> 41:25.610]  A mercury switch is a good idea.
[41:25.770 --> 41:26.630]  I like that.
[41:28.330 --> 41:29.150]  It's possible.
[41:29.370 --> 41:31.910]  Your one-off is probably going to be better than almost everyone else's ROP.
[41:34.030 --> 41:34.890]  Let's face it.
[41:37.930 --> 41:45.810]  What has been the single best either hardware or software implementation for resisting this attack that you've seen so far?
[41:46.990 --> 41:48.310]  Well, there really isn't any.
[41:51.750 --> 41:59.570]  I mean, to be more specific, you can set a BIOS password on your machine.
[41:59.830 --> 42:02.590]  And that way, when someone does your attack, they can also read your...
[42:02.590 --> 42:04.510]  Does the attack, they can also read your BIOS password.
[42:08.760 --> 42:09.380]  Yes, Paul.
[42:10.800 --> 42:11.500]  Hi, Jake.
[42:11.980 --> 42:18.280]  As you know, I work on some software that regularly reads RSA keys for many, many people probably here in the audience.
[42:18.500 --> 42:28.580]  So my first question is, what can programmers do to mitigate some of this attack, seeing the constraints of having to read these keys and having to use them?
[42:28.780 --> 42:37.020]  And my second question is, I hope my RSA key is sort of like an indistinguishable from like a random bit of memory.
[42:37.380 --> 42:38.660]  So how do you actually...
[42:38.660 --> 42:41.780]  How do your tools actually find RSA keys compared to /dev/random?
[42:43.520 --> 42:45.540]  Very carefully, is the short answer.
[42:46.520 --> 42:55.700]  So in the case of being a developer and needing to use RSA keys, I really think that since you're using main system memory that has this phenomenon, you're kind of in trouble.
[42:55.980 --> 43:04.520]  I mean, if the key is unencrypted in memory, everybody knows if you root a box and you have access to the kernel, you can read out all sorts of arbitrary memory.
[43:04.660 --> 43:05.280]  It's nothing special.
[43:05.480 --> 43:06.600]  There's nothing new about that.
[43:06.900 --> 43:10.540]  It's basically just the transformation of that into the off state.
[43:10.920 --> 43:14.340]  And so I don't know how you're going to really...
[43:15.660 --> 43:18.600]  I mean, so, okay, a couple of people have suggested obfuscating.
[43:19.580 --> 43:22.340]  Who here believes that security through obscurity works out?
[43:22.460 --> 43:22.980]  Raise your hand.
[43:23.920 --> 43:25.300]  Hey, we have one guy in the back.
[43:25.840 --> 43:26.280]  Excellent.
[43:33.220 --> 43:47.340]  If you wanted to, you could put your keys in a specific part of the lower boundary of memory that is constantly initialized by your particular proprietary bios.
[43:47.840 --> 43:49.780]  And I think that would be a possibility.
[43:49.960 --> 43:51.020]  But I don't think that...
[43:51.020 --> 43:53.540]  I guess I don't think that that's really...
[43:53.540 --> 44:03.560]  I don't think that that's a great solution, especially if you write free software and someone, like, realizes that they're attacking, say, a particular free software project that has that countermeasure enabled.
[44:03.860 --> 44:04.680]  I mean, it...
[44:04.680 --> 44:08.240]  If everybody's doing different countermeasures, it'll make it harder for the analyst.
[44:08.380 --> 44:10.240]  And I, you know, I support making it harder for the analyst.
[44:10.500 --> 44:11.940]  So, go for it.
[44:12.000 --> 44:15.820]  But I don't think that you should think that it'll be a good solution.
[44:16.040 --> 44:16.800]  Like, I mean, keeping...
[44:17.500 --> 44:23.520]  Keying information in a cache line on a CPU might be a better idea, but that's, like, a fixed amount of space.
[44:23.520 --> 44:25.660]  Putting it in registers could be a fixed amount of space.
[44:27.160 --> 44:27.560]  So...
[44:27.560 --> 44:28.900]  Can I take a question?
[44:29.020 --> 44:29.220]  Yeah.
[44:29.440 --> 44:33.000]  And the person that wrote the RSA key finder will tell you about how it works.
[44:33.940 --> 44:34.780]  This is Nadia.
[44:35.320 --> 44:35.860]  Hi, everybody.
[44:36.320 --> 44:37.000]  Can you hear me?
[44:37.340 --> 44:37.620]  Yes.
[44:37.740 --> 44:42.240]  Okay, so the way that we recognize keys in memory is by looking for the structure that the keys are stored.
[44:42.760 --> 44:49.000]  So, with AES keys, it happens that everybody stores a key schedule of all the round keys in the same order in the exact same way.
[44:49.440 --> 44:57.380]  So, if you want to hide your AES keys, break up the key schedule in some way, maybe it's still predictable, but it'll still be harder to do than we can do it already.
[44:57.860 --> 44:59.940]  And if you want to hide RSA keys...
[45:00.660 --> 45:07.420]  So, we looked at the way that Apache does it with OpenSSL, and it turns out that they store the bare-encoded sort of...
[45:07.420 --> 45:11.440]  the whole key bit without the rest of the package, just the bare-encoded key.
[45:11.660 --> 45:12.840]  And so we're looking for that.
[45:14.400 --> 45:17.220]  I don't know about other applications that use RSA keys.
[45:17.220 --> 45:17.920]  We haven't looked at it.
[45:18.000 --> 45:18.720]  You should look at it.
[45:19.400 --> 45:29.300]  But if you want to make sure that you're not susceptible to exactly what we're doing, just break up the information in some way that's harder than it already is.
[45:29.420 --> 45:30.960]  So, don't use that encoding.
[45:33.580 --> 45:34.720]  Yeah, break it up.
[45:35.040 --> 45:40.840]  I mean, security through obscurity isn't a good idea, but it's better than what you're already doing.
[45:49.480 --> 45:50.880]  Does that answer your question, Paul?
[45:51.580 --> 45:52.100]  Sort of.
[45:52.120 --> 45:52.900]  Sort of, okay.
[45:53.100 --> 45:54.980]  We can talk about it later, if you want.
[45:55.740 --> 45:56.680]  We have a couple of other people here.
[45:56.920 --> 45:57.260]  Hello.
[45:57.780 --> 46:02.660]  I confess I don't actually know a great deal about RAM hardware, but if I have to...
[46:03.280 --> 46:08.760]  What I understand about this is that the reason you have these cold wood attacks is basically that the caps in DRAM drain slowly.
[46:09.600 --> 46:16.560]  So, would it be possible to fix this, or at least help mitigate it in hardware, if you, during...
[46:16.560 --> 46:26.820]  when RAM was powered, you held open some transistors, and as soon as RAM lost power, you allowed those to close so that all of your capacitors were shorted together.
[46:27.060 --> 46:34.820]  So, basically, you try to pull all of RAM down to a common value that's the average of all of the bits in this huge sea of bits, right?
[46:35.060 --> 46:37.540]  512 megabytes worth per stick or something like that.
[46:38.180 --> 46:45.340]  So, there are a couple of memory vendors that have talked with other people, but not directly with me.
[46:45.760 --> 46:47.040]  I don't think...
[46:47.040 --> 46:48.640]  Not with the other people on our team, either.
[46:50.340 --> 46:53.020]  And they have a market for this.
[46:53.160 --> 46:54.560]  There are people that do care about this attack.
[46:54.700 --> 47:05.880]  And so, it is a possibility that some of the people that are involved with that particular area of hardware design will come up with a solution where they'll have a chip that costs, you know, n number of dollars more, and it has this particular physical,
[47:05.880 --> 47:10.600]  you know, memory retention phenomenon.
[47:10.900 --> 47:15.040]  I don't think, though, that we'll be able to do that off the bat.
[47:15.140 --> 47:20.600]  Someone suggested making sort of like a RAM condom, like a microcontroller and a slot.
[47:20.600 --> 47:26.880]  And basically, when the intrusion detection system on the case goes off, it sends both a software event and a hardware event.
[47:27.120 --> 47:31.680]  And the hardware event would basically write to memory.
[47:32.540 --> 47:34.100]  I think that might be a cool idea.
[47:34.220 --> 47:42.160]  And if someone that was pretty skilled with hardware wanted to build it, Phil Chiron, if he's here, probably be something useful.
[47:42.380 --> 47:43.540]  But I don't... I think it's limited.
[47:44.480 --> 47:48.500]  Again, it's... if you have a one-off, I think you could maybe pull it off.
[47:48.500 --> 47:52.620]  I think if you have, like, a standard solution, you just change the attack service.
[47:52.720 --> 47:54.740]  Just several steps you take before you do it.
[47:55.200 --> 48:02.720]  And, again, it would also require power and various other things that might be kind of hokey.
[48:02.900 --> 48:14.520]  So there was an interesting trick in the days of the VACs where if you lost power, the architecture definition required that you keep the disks and memory and everything, you know, up and running for 300 milliseconds.
[48:16.140 --> 48:22.480]  The way this was achieved was actually to turn the big spinning platters of disks into generators to power the machine.
[48:23.360 --> 48:23.840]  So...
[48:23.840 --> 48:24.580]  That's awesome.
[48:24.680 --> 48:28.780]  But the whole point here is that you have a bunch of ones stored in caps, right?
[48:28.840 --> 48:30.780]  You have power on the chip.
[48:30.980 --> 48:35.800]  So perhaps you could draw that off to help flatten the contents of the chip.
[48:36.840 --> 48:37.760]  It's possible.
[48:37.960 --> 48:40.320]  I think that's something that would be worth looking into.
[48:40.480 --> 48:47.920]  I mean, maybe you'd be interested in checking out the code and finding out if you can actually change the memory retention phenomenon.
[48:48.920 --> 48:49.620]  So, thank you.
[48:49.740 --> 48:49.980]  Thank you.
[48:53.100 --> 48:55.180]  So, first of all, thanks a lot for Tor.
[48:55.760 --> 48:56.900]  Really appreciate that.
[48:57.420 --> 48:58.540]  Glad you guys have...
[48:58.540 --> 49:00.600]  I have free Tor stickers too, by the way, if anybody wants them.
[49:00.820 --> 49:07.360]  I'm very glad when I'm in an airport and I have to buy something that I've got things like that to all those evil hackers out there.
[49:09.020 --> 49:15.700]  In addition to that fact, I was reading recently about a Tor live CD that claimed that when it shut down, it wiped the memory.
[49:16.080 --> 49:17.340]  What about something like that?
[49:17.420 --> 49:27.620]  I mean, I realize it doesn't remove all of the possibilities for memory remnants attack, but a lot of us are a little more concerned with we get off the plane, we have to go through customs, they're going to confiscate my laptop.
[49:28.020 --> 49:31.220]  It'd be nice if when I shut it down, it wiped the encryption key from memory.
[49:31.500 --> 49:32.760]  Is that practical?
[49:34.600 --> 49:36.780]  So, yes and no, I guess.
[49:38.100 --> 49:40.940]  I guess it depends what Tor live CD you're talking about.
[49:41.080 --> 49:42.000]  Do you know which one it is?
[49:43.360 --> 49:44.400]  It's been a little while.
[49:44.720 --> 49:44.940]  Okay.
[49:45.940 --> 49:48.440]  It's possible that there's a Tor live CD that does that correctly.
[49:48.640 --> 49:57.200]  I would say look at the source code, verify it, find out who produces it, whether or not they're trustworthy, whether or not they're good, I don't know which particular one.
[49:57.320 --> 49:58.680]  There's a lot of stuff that uses Tor.
[50:00.160 --> 50:01.740]  Would the ideas sound at least?
[50:01.900 --> 50:04.660]  It would help for those of us that have that particular problem?
[50:04.660 --> 50:08.080]  Well, so the interesting thing about this is that there's...
[50:08.520 --> 50:13.900]  In the particular case of Tor and in the case of a live CD, there are a couple of different issues that you really have to face.
[50:14.240 --> 50:17.700]  One of them is Peter Goodman's memory residue issue.
[50:17.940 --> 50:21.160]  Basically, you're oxidizing the DRAM cells in a particular way.
[50:21.160 --> 50:28.000]  So, I don't know if that particularly protects it, because you're not overwriting the memory a number of times.
[50:28.020 --> 50:31.760]  You're not like changing the pattern that's by default stored in that chip.
[50:33.640 --> 50:43.820]  For someone who's just trying to reboot the machine, like let's say you're in an Internet cafe and someone wrote a tool so that whenever someone logged off the computer, it automatically rebooted and like grabbed the memory.
[50:44.080 --> 50:46.400]  You know, I don't know, to detect memory faults or something.
[50:48.300 --> 50:54.920]  It seems to me that probably it would protect against that threat if it was allowed to get into the shutdown routine.
[50:55.620 --> 50:59.300]  Obviously, if you can't get to the shutdown routine, like if you're a server, that doesn't really help.
[50:59.920 --> 51:07.720]  So, it won't help against seizures, but it might help against a particular adversary of a person who is going to come to the machine when you're done and you've been able to take proactive measures.
[51:10.300 --> 51:12.520]  The other question I had for you...
[51:12.520 --> 51:13.440]  Yeah, I'm going to.
[51:14.340 --> 51:30.280]  I actually had a chance to try out the COM32 version that stomped over most of the low memory, but I did find that it was pretty cool, but while I was going through and testing it and trying to figure out how to make it work, I actually had the laptop I was using to test off for probably close to ten minutes.
[51:30.620 --> 51:37.560]  And while most of the memory came back as complete and utter garbage, I did pull a user agent string of IE7 out of it.
[51:37.800 --> 51:40.120]  Have you ever had something like that?
[51:40.260 --> 51:43.220]  I mean, that is a really long time to pull something valuable out.
[51:43.440 --> 51:44.400]  Yeah, yes.
[51:44.800 --> 51:45.640]  Basically, yeah.
[51:45.780 --> 51:52.520]  I mean, older ThinkPads have much longer data retention times than newer ThinkPads, which are almost non-existent.
[51:54.420 --> 51:57.640]  Yeah, I mean, you know, it's interesting.
[51:57.900 --> 52:05.440]  I'd like to see a full map of all of the different memory and whether or not, you know, by default in the board that it's in, how it behaves, I think that would be really useful.
[52:05.640 --> 52:11.440]  And it's a really big problem to try to map all of the memory that's in use by all of the people in the audience without their participation.
[52:11.960 --> 52:14.240]  So if people want to help with that, it would be really useful.
[52:14.620 --> 52:16.620]  It would be really hard to do it without their participation.
[52:17.060 --> 52:18.160]  So, thanks.
[52:18.920 --> 52:35.400]  Just briefly, I know most of the discussion so far is centered around the PC architecture and variance thereof, but has any discussion or any of the Scope of your research involved interaction of any embedded systems, specifically security related, like in the case of smart cards or in my case,
[52:35.520 --> 52:51.720]  like the USB crypto token involved, not necessarily with the storage of the private key, but any time that you have to deal with the session key being generated, that, you know, any dynamic refreshing has to be done on the, from the teeny little device here to the computer itself,
[52:52.440 --> 52:54.800]  to the computer itself and sniffing any of that.
[52:55.660 --> 52:57.160]  So we didn't particularly work on that.
[52:57.320 --> 52:59.680]  Although, so Bill's day job is working on VXWorks.
[52:59.960 --> 53:07.600]  So, I mean, one of the things that he talks about on a regular basis when it comes to DRAM revenants is that, you know, you have to scrub the memory, even on embedded systems.
[53:07.860 --> 53:12.840]  I mean, this phenomenon is something that is, I mean, it's an electrical phenomenon of memory.
[53:13.040 --> 53:15.720]  So it's not limited to x86.
[53:15.780 --> 53:17.800]  It's just that our tools are limited to x86.
[53:18.520 --> 53:27.280]  And as far as smart cards, I mean, a smart card is only as strong as, I guess, Chris from Flylogic, whether or not he's attacked it.
[53:27.820 --> 53:35.540]  I would, basically, I wouldn't, I wouldn't trust anything, like, that he has successfully attacked, because he beats everything, pretty much, that he tries.
[53:35.940 --> 53:40.400]  And most hardware also has weird debug pads and back doors, you know?
[53:40.400 --> 53:44.940]  So, like, can I talk about the SLE thing?
[53:46.820 --> 53:47.380]  Okay.
[53:48.000 --> 53:49.740]  So, do you guys remember the...
[53:49.740 --> 53:51.480]  Do you guys remember the Kinkos card?
[53:53.500 --> 53:54.780]  So there's a...
[53:55.800 --> 53:57.640]  I'm sorry to ruin this for anyone that cares.
[53:59.300 --> 54:01.840]  That chip is the best chip in the whole world.
[54:03.680 --> 54:13.860]  Basically, there's a specific debug pad that has a single gate preventing it from telling you the secret 24-bit code that prevents you from doing things to the card.
[54:14.280 --> 54:19.800]  And all you have to do is know where the debug pad is, and then you can get the 24-bit code when you power the card on.
[54:20.900 --> 54:21.780]  So, smart cards?
[54:22.140 --> 54:23.640]  Eh, not so smart, maybe.
[54:25.480 --> 54:26.560]  Just a last statement.
[54:26.760 --> 54:27.860]  Would it be safe to say that...
[54:28.540 --> 54:30.500]  Which, he can probably follow up on that even more.
[54:30.780 --> 54:36.540]  I wanted to add that, that unlike computers, most smart card readers do have secure key storage.
[54:36.540 --> 54:46.880]  So, the crypto co-processor is reality in most smart card applications, and relies on some secret, obscure algorithm to encrypt keys.
[54:47.080 --> 54:47.400]  Well...
[54:47.400 --> 54:50.740]  That would be a nice reverse-engineering target for future work.
[54:50.920 --> 54:53.820]  But those are so far believed to be very secure.
[54:54.260 --> 54:59.640]  Well, who could possibly reverse-engineer some proprietary secret hardware, Carson?
[55:00.660 --> 55:02.840]  Maybe you did that already.
[55:06.320 --> 55:17.780]  You mentioned earlier ECC memory, and you quickly went over it, saying that basically it was also vulnerable, but that some chipsets were actually wiping it, and all that.
[55:17.880 --> 55:22.780]  And I was wondering if you could elaborate on whether ECC memory is totally vulnerable, or whether or not be able.
[55:22.880 --> 55:23.380]  Well, okay.
[55:23.660 --> 55:27.540]  So, actually, I think ECC memory is a special case for a number of reasons.
[55:27.560 --> 55:30.220]  Because it makes people feel secure when they're not.
[55:30.380 --> 55:39.140]  And it does some things that, at certain times, will be useful to a user who cares about the confidentiality of their memory.
[55:39.780 --> 55:44.900]  But basically, when it comes down to it, ECC memory, if it applies...
[55:44.900 --> 55:46.200]  Like, the way that Intel has a...
[55:46.200 --> 55:49.300]  They have an embedded programming specification that I have on my shelf.
[55:49.300 --> 55:55.140]  And basically, what it says is that when you power on the chip, the first thing you should do is scrub the chips.
[55:55.680 --> 55:59.340]  Because there's going to be all sorts of bits in all sorts of different states.
[56:00.100 --> 56:01.060]  Mostly on and off.
[56:01.520 --> 56:10.540]  And essentially, if you are using ECC memory, what that means to you is if you have a controller that does that, then your controller is going to take care of that.
[56:10.660 --> 56:12.840]  Or perhaps your BIOS will take care of scrubbing that as well.
[56:14.420 --> 56:15.180]  But what's...
[56:16.280 --> 56:33.120]  What's really bad, in my opinion, though, is that it seems possible to me that you can use the error correcting of both the code that we've published and also the fact that it's ECC memory and can correct errors for you in hardware.
[56:33.600 --> 56:45.700]  So if you were to not scrub the controller and then apply that error correction that's in hardware, and then also you wanted to apply the AES fixing, it seems like you could get more bits.
[56:45.880 --> 56:52.280]  But since we are not really seeing a lot of data loss, it just means that you might feel a little bit secure at some time.
[56:52.840 --> 56:53.280]  So...
[56:53.280 --> 56:54.580]  Does that answer your question?
[56:54.920 --> 56:55.660]  All right, cool.
[56:56.840 --> 56:57.720]  Anybody else?
[57:00.140 --> 57:00.580]  Yeah?
[57:08.590 --> 57:12.570]  Is it possible to use any of these on, say, a PlayStation 3?
[57:13.290 --> 57:14.030]  A PlayStation...
[57:14.030 --> 57:15.970]  Because you can run Linux on it and...
[57:15.970 --> 57:19.470]  Like, so you want to analyze the memory of the game that you're writing?
[57:19.830 --> 57:27.910]  No, basically, like, I'm thinking about a different architecture because 128 bits versus 64 bits versus 32 bits RAM.
[57:28.210 --> 57:28.950]  I mean...
[57:28.950 --> 57:31.070]  And if they use something special, different...
[57:31.070 --> 57:39.830]  So if you have just memory chips in whatever game console you're looking at and it's electrically compatible with a particular BIOS, there's no reason that you shouldn't be able to swap it out.
[57:40.190 --> 57:45.050]  Whether or not that data will be meaningful to you, I guess, depends on if you understand what it's doing.
[57:45.730 --> 57:49.430]  But I think that you should probably be able to modify this so that you can...
[57:49.430 --> 57:51.750]  I mean, Linux, PlayStation, right?
[57:51.750 --> 57:56.010]  It should be possible to set it up to boot in some way over the network and you can see yourself.
[57:56.250 --> 58:00.470]  You can also just reboot a PlayStation running Linux and see if the memory persists.
[58:00.630 --> 58:03.810]  It's possible that they don't scrub the memory when they reboot.
[58:03.930 --> 58:06.050]  And if that's the case, let us know.
[58:06.130 --> 58:09.190]  It would be kind of cool to find out that there's a game system that has this phenomenon.
[58:10.530 --> 58:10.930]  So...
[58:10.930 --> 58:11.530]  Thank you.
[58:12.250 --> 58:14.070]  So, I think that's it.
[58:14.270 --> 58:15.190]  Thank you very much.