 So my name is Wesley McGrew, and to give you a little bit of background on why I might be giving this talk, I'm going to tell you a little bit about the different hats that I wear. So my day job currently is at Mississippi State University, where I've been for some time now, where I teach at the National Forensics Training Center. We develop course material and provide free training to anyone affiliated with law enforcement. Also wounded veterans that are coming back from Iraq and Afghanistan to give them skills that are needed to join the workforce in processing digital evidence and computer crime and child pornography and things like that. So in that aspect of my job, I write about forensics. I teach forensics. We experiment with forensics in our lab. We have a very nice lab in Starkville, Mississippi for this. But then after hours, whenever I go home and I kick up my feet in the home office, I break things. So I operate McGrewSecurity.com. I'm at McGrewSecurity on Twitter. And one of my favorite things to do is to find vulnerabilities in things, break things, penetration testing, that sort of thing. So with this talk, I'm sort of being informed by both sides of those things and wanted to provide something for both the forensics geeks and the penetration testing geeks that are in here. So what inspired this talk was actually straight out of the DEF CON 19 call for papers. One of the first lines on the kind of talks that they were looking for is James Bond, Man From Uncle type spy stuff, which is right up my alley. I love any kind of spy movie. I love any kind of heist movie. Basically anything where somebody steals something, I'm completely cool with that. Very entertaining stuff. So that really called out to me. And I'm really happy to see that there's a really huge spy versus spy theme to this conference. It's a lot of fun. So with that, I figured okay, let's get sneaky with forensics and penetration testing. And that's what we're going to do right here in this talk. So to break it down, when we talk about covert post exploitation forensics, by covert we mean without the suspect's knowledge or the subject's knowledge. Whoever the target of this forensics is, we want them to be able to just go about their business as normal without really knowing that we're going after them. So as we'll talk about here in a little bit, the whole idea with traditional forensics is somebody comes and takes your stuff. They kick down your door, they haul you off and they take your stuff. With that, you're not going to continue your activities. You're not going to continue to steal things and SQL and Jake folks and stuff like that. So we want to be able to have the capability of performing forensics without the suspect knowing about it. So that brings up some interesting issues which I'll discuss. By post exploitation we mean that to accomplish this covert goal, we want to do this after we've compromised the system remotely or by some local back door. Any way we can get a interpreter's shell up and going works for this. And by forensics, for the folks who are not the forensics geeks in the audience, we're reconstructing data above and beyond what the subject anticipates. So the subject may be anybody from a standard, barely computer literate user who's downloading and trading child pornography over peer to peer sites all the way up to your elite hackers and stuff that take lots of operational security into account. But on the scale from that, from the lowest to the highest skill, there's essentially misunderstandings there as to how data is stored, what's recoverable, what's really deleted and what's really gone, and what can be reconstructed after the fact by a good examiner. And it's all about layers of abstraction. So most computer users see files on their desktop, files in their documents, files in their downloads. They know that when they put something in a recycling bin, they realize they can probably still go and get that back until they empty out their recycling bin. But that's the level of abstraction that they're looking at for their system. And they're not showing anything else underneath that to reveal how this all really works and how it's all really implemented and why it's so darn fast to delete a one gig file. So as you get more skilled with the stuff, and especially if you're an inter-forensics and follow it or practice it, you begin to realize that the way file systems are implemented is perhaps a bit different than how you see it and interact with it on a daily basis. So when you delete files, they may not necessarily be gone. When you format a file system, that data stale might be there. So basically, by taking advantage of the subject's lack of knowledge of how everything works underneath there, we can pull back things that they thought that they had already gotten rid of. So with that, we've got the peanut butter and jelly sandwich here of forensics and penetration testing. And this is supposed to be something for both sides. So for the forensic side, we're introducing the aspect of being able to do this remotely and covertly without having to be on scene or without having to make the subject aware. And for the penetration testing side of things, we want to make this a tactic or a post-exploitation skill that can be leveraged to gather more information out of every system. So we want to be able to, for every system that we break into at a company, we want to be able to extract more data out of it, more personally identifiable information that may have previously been deleted, more information, old emails and things like that that may get us into other systems. So on the forensics side of things, the implications of this is that we may run into a situation where it's no subject location, no problem. So for the guys that you see running around here with the Guy Fawkes masks on and things like that, they're like, good luck, I'm behind seven proxies. Well, perhaps if you might want to be very careful about the things that you run from here on out and anything because something like this may give you away. It may allow people to do forensics on your drives and anything without you knowing about it. This allows for a surreptitious acquisition and analysis. And so the obvious question here is of privacy concerns and the legal ability for government federal agents and local agents and state agents and things like that to perform this kind of analysis. The way it stands right now is there exists surreptitious entry warrants in some situations so that federal investigators can go in surreptitiously and examine things or place things. It's been used at least once that I know of to place key stroke recorders on a computer. I believe that was like a Scarfo or something that was a mafia organized crime case. So the legal framework may be there. I'm not a lawyer. I'm barely what you might even consider a federally funded. So I don't know all the details of how to do that but it's sort of a solution looking for the problem there. But the main thing for the forensics geeks for being able to perform forensics on these remote systems like this is that we can use these familiar tools. So people go to long training events for things like FTK and NCASE that either that or they're very familiar with Brian Carrier's work and they use Sleuth Kit and there's no point in having a new set of modules for doing post-exploitation forensics that doesn't work anything like the old ones. It's best if we can just leverage all that old training so we can use those familiar tools, Sleuth Kit, the commercial tools like FTK and NCASE. There's a really good free tool that access data who puts out a forensics toolkit it publishes called FTK imager and it's originally intended as just a way to have a license-free program on a USB drive that can image drives for you so that you can take it out in the field or use it on as many computers you want. You don't have to worry about having your USB dongle for FTK with you. Well, it's actually kind of grown in capability and grown in capability. It turns out you can do some pretty cool stuff with just FTK imager and it's available free from their website, accessdata.com. On the other side of things, if you're a penetration testing geek, if you like to break things, maybe even if you're a criminal, who knows? We'll call it penetration testing. For this side of things, you might get more value out of the systems that you break into. You may be able to get more important data out of every compromised system that you break into by using tactics like this if you suspect that that might be the case. There's always a situation for companies and organizations and individual systems that process sensitive data. They may need it for a short period of time to verify something or to log it and send it off to some other location to encrypt it and back it up and everything like that. But there's always the statement there that we don't keep that kind of data. We don't keep sensitive data on this particular system or we don't keep this part of the data. We throw it out and anything. We save the stuff that's not sensitive. Or we encrypt that and then back it up over here. What this will allow you to do is we can take advantage of weaknesses and how they go about that process in order to recover remnants of that sensitive data that didn't get deleted quite as well as they thought it would. We may be able to find multiple revisions of files, old data, that sort of thing. Any kind of remnants of old source code or anything like that. Say if you built a program on a system, installed it and then removed the source code from it, well, maybe we can go back and pull that back. A big thing that we cover in our Forensics Training Center classes is the concept of data carving. If all else is lost, if a file's been deleted and all the file system metadata that points to it is gone, there's still a good chance that there are portions or even whole files out there that aren't even pointed to by the operating system. So by doing signature analysis with the headers, basically, we know what sequence of bytes a JPEG header starts with, GIF images, word documents, things like that. If we know that, then we can set up a tool to go through every 512 bytes sector of that image file or disk and look for those old files that aren't being pointed to anymore. One nice thing about the tools that I'm going to discuss here is since we're developing tools that essentially we map the victims block devices to our local block devices, since we have the capability of doing that, in addition to running off-the-shelf commercial or open-source Forensics tools, we can also just write our own scripts to manage things. So if you have a script that will go through a file system looking for personally identifiable information with regular expressions for Social Security numbers or anything like that, then you can take those scripts that you would run on your local file system and just run it directly against the file system that you've mounted off of a victim's system. And all of this is relatively stealthy with some caveats that we'll discuss. But overall, unless the victim is sharp, then it's going to go by pretty smoothly. So the typical forensic examination scenarios that you have right now are hardware seizure. Basically. In commercial environments, in enterprise environments, you may have a situation where you have authorized software agents on the endpoint computer. So if I'm a forensic examiner, a forensic investigator for a large company that has hundreds of machines or thousands of machines, each of those machines may have an in-case agent or an f-response agent on it that allows me to connect to it remotely from my examiner workstation and do some of the same things that we're talking about here where we're able to look at the block devices directly, recover files, basically perform examinations remotely. The difference in this is that we don't have to have that agent anymore. So remote forensics without having to have the agent, without having to click through or sign on user agreement to get it at any point. Most forensic examinations, if they're not done by taking your stuff, then they're done on-site. There are tools for forensic previews. Drives can be quickly hooked up via write blockers and to allow for hooked up via write blockers to allow the examiner on-site to see if there's enough evidence there to warrant taking it with you at any point. Sometimes consent is given by the subject and law enforcement are really good about convincing people to give consent. So a lot of people consent to being searched on their digital evidence and it can quickly be looked at there. But in all of these cases, the suspect or the subject is aware that they're being investigated. So here we have a situation where you can take that as you will as being informed. So with the covert remote forensics we have an unaware subject as long as it's a vulnerability in Metasploit or something that you can write a Metasploit module for to exploit this system and it doesn't do crazy things to their desktop while it's doing it which is the case with most of this stuff. It all works just perfectly fine. You're in you get the interpreter shell. The interpreter shell itself has a very low footprint on the system. I'm not sure that it touches any files at all. It has a small memory footprint. It probably depends on the actual vulnerability being used as to the footprint. In this case if there's no known physical location it's not a deal killer anymore. Usually if you're going to get a warrant and you want to perform an investigation of search and seizure then you need to be able to say where that person is. But there may be situations where people are good at anonymizing themselves or coming in over or borrowed wireless and things like that where you may not necessarily know where they physically are. And if you can make the case that I know that they're at this IP address and we can get them with this then we can figure out their location once we get onto their system and start looking at their data in that case you may have some sort of remote exploits if you have an IP address or you may do some sort of client side thing and then whenever it phones home to you it's like oh, there's the IP address right now. Once it calls back to you so that gets all around all seven of those firewalls or proxies. We can have remote imaging so the capabilities that these tools will allow you to have now are broken up into a few different things. We have three different tools. One's just for enumerating drives. One of them is simply just a remote imaging solution. Just the same thing as you would have for a handheld imager or an imaging program like DD on a local computer that allows you to do essentially the DD process over the network through Metropeter. But what's really cool is we have remote device access. So remote physical drives and remote volumes on the victim Windows computers right now, right now just Windows. Remote devices on those computers we can map those to local devices that we can run any tool we want to on. So this is good for folks who are in intelligence and don't really have to worry about the whole warrant thing. If the NSA wants to talk to me later they can feel free. I hear they're here. Hiring. So if you're a penetration tester and you want to be able to branch out from your systems more or you want to be able to say in your report we pulled out more data than you normally pull out this can help you out here. As far as compliance goes it could be and I'm not very familiar with PCI and HIPAA and things like that. But if those standards and other compliance standards if those standards require the secure deletion of data then these techniques will help you verify that because if you're simply looking at the file system through the normal interpreter LS and getting files and things like that you're looking at that very high level of abstraction that keeps you from seeing whether or not something was securely deleted. So we can verify if things have been wiped or not. And finally criminals can use this much like anything that's presented here if crime is your thing then that's the case. If you don't want crime being done against you then this will inform you that maybe people might use it against you. So for the forensic side of things here for the penetration testers you know at Mississippi State University we have semester long classes for digital forensics. So we teach them all about file system forensic analysis. We use Brian Carrier's file system forensic analysis book as the textbook. And we cover them with all the technical details of forensics. We talk to them about imaging and some of the legal aspects and things. We get law professors from Ole Miss to come help out with that. And it's a semester long class. We take cases, mock cases based on a set of parameters we give them and midway through the class they swap up and investigate those cases. And then we usually have a mock trial at the end with real judges and attorneys and we put them on the stand through cross examination and all that. It's a lot of fun. That's forensics on the long scale of things. It's a semester long class. For law enforcement and veterans we have more intense long classes that try to get them up to speed for doing simple examinations and giving them some information so they can branch out from there. Or take some of our more advanced courses like the network forensics and some of the workshops that we're holding on commercial and open source tools. We break those up into the week long chunks. Now for here at DEF CON for penetration testers we have one hour, less than one hour actually. So to teach you all about forensics is a little bit different. Now I would say that most of our law enforcement and veterans are a little bit more motivated to learn than most of our undergraduate students. So I would like to think that the penetration testers who want to make more money off their penetration tests and want to have better results would be very attentive and willing to do some personal research to get caught up on this. So with file system forensic analysis we have a whole set of capabilities that are added on that aren't necessarily there with normal tools for looking at file systems like the LS and GET and things like that that are built into most exploitation tools. So of course we can get out of allocated files and really that's where it stops with most post exploitation tools. Where we can grab allocated files and we can do things like forensics on their cookies and their browser history and grab a copy of their documents that are older and things like that. But there's a lot more out there. There's deleted files. So if we delete a file on a file system then the typically either on NTFS that file record is simply marked as bad. All the information in the file record is still there. All the data that's out on the disk is still there. If we delete a file on the FAT 32 file systems nowadays mostly used on USB drives and things like that. If we do that then it simply changes the first character of the file name to market as being deleted. But all the information about where that is on the disk is still out there. There's a really interesting concept of slack space where we can essentially grab the bits and little bits and pieces of old files that are kind of sealed in time sort of like the mosquitoes and amber from Jurassic Park. We can grab out some data on that. I'm going to talk a little bit more detail about that on the next slide. There's completely unallocated space so eventually Windows may reuse one of those file records that was marked as deleted as it will tend to do after some time. Surprisingly long time usually. But once that file record is reused or the disk is reformatted or the or there's a partial wipe or something like that then the data of the file is perhaps still out there on the clusters in the sectors of the disk and simply nothing's pointing to it. So we're down to data carving. We look for it by signatures, frequency analysis, that sort of thing. And most people have a misunderstanding about the differences between deleting and formatting and wiping. Essentially if it didn't take very long for you to do it then it didn't do it very securely. So it takes time to wipe a file. It takes time to reformat a disk with full wiping and you'll take a better part of the day, actually. And most file systems don't do this by default. And they don't do it by default because one, it's very slow and it puts wear and tear on the drives and things like that. And Microsoft takes enough flack for Windows being slow already and they're not going to introduce more slowness by forcing the users sit there and wait while every file that's deleted is being wiped off the disk with overwritten zeros and ones and things. And finally, we can have the concept of imaging there. So getting a one-for-one copy of the target drive. So with the tools that we're going to show off here, we have the ability to image a remote drive and if we can do it while the system's relatively calm, if we can get the system in a fairly stable state, heck, we could just take that image and boot it back up in VMware and have our very own local copy of the system to work with. Cool. So for Slack space, typically when we have a file, it's allocated a set of clusters and the clusters are essentially the way the operating system divides up the sectors of the disk. Every normal hard drive has 512 bytes per sector and that's the smallest addressable unit of data that you can kind of pull off at a time. You request data sectors or groups of sectors at a time. The operating system will do one further on that and gather those sectors up into clusters. And it does that so that it can keep a bit map of which clusters are allocated and which clusters aren't and it can keep logical pointers to those clusters that it uses to say, okay, this file is in this series of clusters, this series of clusters and so on and so forth. Well with this type of system, there is some space wasted at the end of the files. If you have a file that does not end on a cluster boundary then the rest of that cluster is wasted essentially. It's sitting there. It can't be used by the operating system to give it to another file or anything like that. It's just simply out there. So we have what's called Slack Space there and that Slack Space will contain whatever data was in those sectors of that cluster before that file was allocated to it. So old files that have been deleted and then brought back files that have been resized. So you'll see this quite frequently with like Info2 files and recycling bins. Those Info2 files that mark what files have been deleted will grow and shrink and so you'll see the old contents of an Info2 in the Slack space of the current one. In this case we have two different kinds of Slack here. There's the RAM Slack which is the remainder up until the next sector boundary which is probably zeroed out. If you're looking at any Windows system past Windows 95B that's going to be zeroed out because that was historically containing data from RAM. So there would be a 512 byte buffer in RAM that would get written out to disk. And if you're only writing 20 bytes out, if you only put 20 bytes in there then who knows what's in that rest of that 512 byte buffer. So if you're looking at other programs in memory, that being a serious privacy concern, Microsoft and most other modern operating systems have it rigged up to zero that out. The remaining sectors in that cluster have the potential goodies. That's old contents of files that are in there. Either contents of another version of this file or contents from some other file that was on the disk before. Can't we do all this on exploited systems already? And it's true, you can. But it may require loading your forensics tools onto the victim system. Which would probably work, but there's a problem here. Anytime we mess with the file system, anytime we load our forensics tools onto these things, we impact it. We may be overwriting deleted data. We're not that stealthy at that point. We have a huge footprint on disk. It's a little less elegant than what I'm proposing here. With Meturpreter, the shell that you get whenever you use the Meturpreter payloads, the shell that you get. With Meturpreter, there's a function or some functionality built into Meturpreter called Railgun, which really makes this stuff very easy. Railgun's by a guy who goes by the name Patrick H.E.V. Trying to drop docs on him and anything. I can't find anything else about him. I don't know. I guess I could send him an e-mail and tell him thanks, but if any of you know Patrick H.V. and anybody here, Patrick H.V. Five hands, okay. So if you're out there, massive thanks for making this dead easy. Patrick H.V. has an extension from Meturpreter Ruby. Basically on your local attacker post exploitation scripts or post modules, you can make Windows API calls to the system's host and get your data right back in your, the return value is right back in your local Ruby script. So basically we can make all sorts of arbitrary Windows API calls locally and just have the results just piped right back to us. So it's awesome for this. If we can call the Windows API remotely, we can access the disk like Windows does. We can access physical and logical block devices directly, as long as we have permissions to do so, from that point on, that's all you need to do forensics. If we can say I want that sector, I want that sector, then we're good. We can start traversing out the master file tables and things like that and get at it. So why not make this really dead easy and map those remote block devices to local ones? So we have three tools for that. Enum Drives, which simply lists out the physical drives and volumes so you know what you're playing with. There's another that does byte for byte imaging, hashing, split images. All sorts of things that you would expect out of normal forensics tools for imaging, DD, image masters and talons and things like that, all of your handheld imagers. It can do all this sort of stuff. But the coolest part of this is nbdserver.rb. Now all of this stuff should be in the Metaspoid SVN right now. It was supposed to be in there a couple of years ago. I've been kind of avoiding the internet around here. So somebody else can verify this for me. But if you do an SVN update along with all the back doors that the guys here are injecting, you might get these tools as well. If not, then I'll make sure that they're available. With nbdserver, you can run your forensics tools locally on local block devices that are mapped to remote block devices. The way we do this is I'm not recommending my own block device drivers or anything like that, but there's a protocol in Linux called nbd, which is a really dead easy protocol to get programmatic block devices. So you can implement your own block device in code and just have it listening over TCP locally or remotely or whatever you want to do really. So with nbd, we can map these things to local block devices that we can then do reading with. And the way this code works, the there's only read on the, there's only read on the access. So essentially we're right blocking too, so we don't, we have a minimal impact on the host. So now we can have direct access with open source tools in Linux. So this is essentially a diagram of how it all works out. We have the disk, the interpreter talks to it through the WinAPI, metaspoit talks from interpreter, and actually we have Railgun making those Railgun calls through the Windows API. We map dev nbd zero through nbd to that disk on the target. And we run our forensics tools on it. This works good for Linux tools because as nbd is supported in Linux and everything, and so this is good for Sleuthkitten on, but for Windows I was a bit, I was kind of stumped. I was like, well I'm going to have to write a Windows block device driver or something like that to get this working in there. I was preparing my slides for this talk and I came up with a good stupid protocol trick to get this working in Windows very well. And that stupid protocol trick is to use iSCSI. iSCSI is a little bit more complex of a protocol for block devices, but as it turns out if I get an nbd block device in Linux, I can then map that as a iSCSI target in Linux and then have a Windows machine connect to that and treat it as a block device. So we have this stupid protocol trick over iSCSI, nbd, interpreter, Windows API and straight back from there to the disk. So the problems here you're going over a network so your mileage may vary. If it's around the world and over a phone line or something like that then it's going to be slow. And on the other hand if it's a very fast network that you're doing this over you may be able to get a lot of response out of it but you may not be so stealthy at that point because you're pushing gigs of traffic over this thing. You may actually want to modify the code of this to try to throttle it if that's a problem. On this it's possible there's a good cleaner cross-platform implementation to this. Maybe instead of using nbd directly in Ruby we make our own Ruby iSCSI target that we can use. How hard could it be? For the conclusions for this if you're a pen tester go out there and ring some more data out of the systems that you break into. If you're a criminal get caught. But from this we can build capability for forensic examiners and penetration testers and we can encourage people to use more secure wiping for their data. And from that now we're going to roll into our demos real quick like right here. We're going to see how much of this we can get through. We're going to see if all three of my VMs will behave if not then I'll just go back to here. You'll have to forgive me I have some notes here on exactly how my demo goes. To introduce you to the actors in this demo we have our victim over here running in unpatched Windows XP service pack 3. I'm not on the wireless network right now so don't even try. The thing is vulnerable to probably who knows how many things in Metasploit. We have our attacker here get out of my way forensics machine we have our attacker here running Metasploit. Which we're going to point at this thing. Metasploit here was updated 18 days ago. Metasploit 4 is out. I didn't want to update on here for fear of breaking my demo. And over here we have a forensics machine running Windows 7. We have access data FTKM and Geron. So the first thing I'm going to do is I'm going to make sure my victim didn't hop IP addresses on me. And we should be good. Yep still sitting right where I left it. Thankfully no loll suck images up on or anything that's good. Alright so we're going to use one of my favorite exploits of all time. You ever have a favorite exploit that just always works? MSO8067 that's the one right there. And we're going to set our payload. Let's zoom in a bit here. Windows interpreter bind TCP. The tab completion sometimes takes a little while. Alright so we set our payload up. We're going to set our remote host. Oops. 93.155 right where I left it. And we're going to hit it. And big surprise not quite zero day and we have success. Alright so we're in. Now any vulnerability would work for this. Any exploits you got some zero day to drop into a menace boy feel free. Substance is necessary. I'm keeping all my zero day. So for this we're going to run some of these post modules here. We're going to run the oops post windows gather gather enum drives. And that's going to list out the one physical drive that's on that 40 gig physical drive as well as the logical drives that are there. So if that drive is partitioned out into multiple drive letters then it tells us about it. It also tells us the disks that are inserted. That's actually I think the DEF CON CD that's in the DVD drive there. And now we map it to a block device. So we run the NBD server and we tell it we want the C drive. Now for this we have the backslashes windows style. You can do that in the interpreter shell but you have to escape them. The forward slashes work just as well and you don't have to escape them. So much easier to do that. So now we have an NBD server listening. And over here we can take a look at, we can connect to that NBD server. So we run NBD client local host running on port 1005 NBD 0. So we've got that mapped and now we can just take a look at it very quickly and verify that we are indeed looking at an NTFS disk here. So that's your partition boot record and for my next trick we're going to mount that device directly. So now we can mount, read only that device to a little mount point that I have here for my victim. And it takes it a moment to do that. So a lot of this stuff that you're doing with the remote forensics like this isn't the fastest stuff in the world. It's not nearly as responsive as working over a normal set of cable. Some things take longer than others. This mount command took a while and tried to embarrass me during my black cat talk. But with that we can go into our victim and go into his documents and settings. Victim is his user name even. He wasn't holding out very high hopes. We can go to his desktop folder and there is a document full of personally identifiable information. We can... How do I know that? There you go. And if you're wanting to take cell phone pictures and stuff, don't bother. It's all from fakedamegenerator.com. All right. So now we can run tools all on this device as well. We can unmount that now. We can run forensic tools like NTFS, delete, undelete which is... Normally you'd want to use something like SleuthKit for this but this is kind of built-in and quick and easy. So we can undelete any... Let's delete something first. See if it will work. Actually, let's just try undeleting CSVs. I did delete a CSV that was on here and we'll see if it finds it. If it doesn't, we'll just move on. So that's working because that's going to take a moment. We're going to start up a new tab here and start showing you the iSCSI capabilities here. So with iSCSI we have et cetera i-e-t-i-e-t-d .conf and we have a... Oops. Sudo make me a sandwich. So here we have this thing, this bog device that we're going to target. On the Windows side of things, it didn't find any deleted files there so that's fine, we'll move on. On the Windows side of things, we can load up the iSCSI initiator, which is a buggy piece of crap but it does work. I would hate to use this for anything other than lead hacks because relying on this for enterprise stuff would probably really suck. Let's see i3.163 is my attacker. So quick connect to that and cross your fingers, guys, and hope this works. Oh, I need to start the iSCSI service. That would help. I need .d, iSCSI start. Now we should be cooking with gas. 168.93. 163. Connection failed. Let's start that up again. We're going to have a chance here and then we'll call to wash. Make sure my IP address haven't popped over here. 164. Sneaky. Moving target there. So here we are, we're connected. So now we have a block device that we can use an FTK image or any of your favorite forensics tools at this point. Add evidence item. You can image these things, you can image virtual machines, that sort of stuff. So we'll do it as a physical drive. And point it to physical drive one, which is the virtual disk over iSCSI, moving over interpreter, moving over a million other protocols. And it takes this dandy time loading up, but it's a miracle it even works. And so speed improvements to this would be beneficial. We might implement some not chaining iSCSI and NBD would probably help matters. Oh good, FTK image are not responding now. Oh, here it comes back. Just had to take its time. So now we have the physical drive here. We can navigate around this thing, we can look at unallocated space, we can run various and sundry undelete tools and any kind of scripts you have and get all the nice emails that they deleted. With that, that basically concludes my talk. We're going to be moving over to the question and answer room 2, which is approximately 4 or 5 miles around this whole thing. And I'll answer any questions there. Thank you.