00:00:00.200-->00:00:04.171 >> So uh welcome, thank you very much for coming. It's always awesome to see a room full of 00:00:04.171-->00:00:09.676 people, and it's humbling for me as a speaker to really have such a great audience showing up and 00:00:09.676-->00:00:14.014 listening to me say things. I'm always shocked. [clapping] >> Give your all self a round of 00:00:14.014-->00:00:20.521 applause. [ Applause ] >>Thank you very much. So without further ado, I'm gonna talk a 00:00:20.521-->00:00:24.992 little about myself and we'll get to the actual cool part of this presentation. I'm Tom 00:00:24.992-->00:00:30.931 Kopchak and I am the director of whatever at Hurricane Labs. Where I am pretty much 00:00:30.931-->00:00:37.004 responsible for taking the customer's problems and giving them to the Engineers to solve 00:00:37.004-->00:00:43.110 them. So I don't actually do any work, but I'm a manager. But I'm still an engineer, and uh 00:00:43.110-->00:00:48.515 researcher at heart; and this solid state drive forensics research has absolutely nothing 00:00:48.515-->00:00:52.286 to do with what I do professionally. But it's still interesting and I think this is 00:00:52.286-->00:00:57.357 one of those topics that we really are lacking a lot of information on and I had some 00:00:57.357-->00:01:01.695 fundamental questions when I was looking at the research that was done on this topic that I really 00:01:01.695-->00:01:07.200 wanted to find out the answers to. And over the course of the next forty minutes or so, I'm 00:01:07.200-->00:01:11.305 going to go through those questions. We're going to talk about how Solid State Drives 00:01:11.305-->00:01:16.076 operate and the technologies behind them. And we're going to talk about what you need to 00:01:16.076-->00:01:21.014 consider if you're trying to do a forensics investigation on a solid state drive and want to 00:01:21.014-->00:01:25.719 see if the data is still around. To determine if it's actually worthwhile to get that data 00:01:25.719-->00:01:32.259 back, or if there's gonna be something that's gonna make it virtually impossible. Also 00:01:32.259-->00:01:35.896 during the course of this presentation, you might notice that I make some jokes that are 00:01:35.896-->00:01:41.868 quite bad. That's what the hashtag Tom Joke is for. Internally in our uh chat system 00:01:41.868-->00:01:47.908 at Hurricane, we have something that you type in bang Tom Joke and it returns 4 0 4 humor not 00:01:47.908-->00:01:52.346 found. So I'm sure you guys all have access to things that can post things on to the internet. 00:01:52.346-->00:01:56.216 Either in your pocket, or in your lap, or something like that. So if I say something like 00:01:56.216-->00:02:01.288 that, go ahead and use the hashtag Tom Joke, and uh we'll make it a thing. It's the Dad 00:02:01.288-->00:02:08.061 jokes of IT. So without further ado. Why we are here. Uh, current forensics technologies 00:02:08.061-->00:02:13.300 and practices for working with hard drives, they're well-defined. When you get a 00:02:13.300-->00:02:19.473 hard drive, we've got, conveniently enough, one right here. Normal laptop hard drive. 00:02:19.473-->00:02:22.809 If you're a forensic investigator and you've got one of these, you would know what to 00:02:22.809-->00:02:29.049 do with it. It's well-defined. Now solid state drives, they do behave differently in a lot of 00:02:29.049-->00:02:33.587 cases and they present a whole lot of new challenges. And really this presentation is 00:02:33.587-->00:02:37.591 going to look to explore those differences in detail. What challenges you need to be aware 00:02:37.591-->00:02:41.728 of, and considerations when working with an evidence bérance... bearing solid state 00:02:41.728-->00:02:48.035 drive. But first, I want to make sure that we get everyone up to speed on hard drive forensics. 00:02:48.035-->00:02:52.506 So I am going to do a quick overview of Traditional Hard Drive Forensics and what that 00:02:52.506-->00:02:56.209 means to you. Just to make sure we're all on the same page. It should be review for a lot of 00:02:56.209-->00:03:01.681 you in the audience and definitely something that we all pretty much have standardized 00:03:01.681-->00:03:08.555 and understood. But really what we know is if you have a hard drive, one of these, you delete 00:03:08.555-->00:03:13.560 a file off of it, it is often, if not never truly deleted. It's very easy to recover that in a 00:03:16.363-->00:03:22.102 lot of cases, and that data is not truly gone. And this has really become a cornerstone of a 00:03:22.102-->00:03:27.107 lot of the basic forensics practices. Someone has something they shouldn't on a hard drive, 00:03:27.107-->00:03:32.546 they delete it, the Feds undelete it, through not all that uncomplicated processes. 00:03:32.546-->00:03:36.650 Fellas come back, throw you in jail for forty-seven thousands years, and then everything's 00:03:36.650-->00:03:42.389 good. Well, it's not good but you know how that works. Now if you were to be like I wanna 00:03:42.389-->00:03:46.827 delete this data and you quick format that hard drive, the data's still there. Uh, it's not 00:03:46.827-->00:03:52.265 truly deleted, it's not overwritten. And In order for data to be deleted from a hard 00:03:52.265-->00:03:58.839 drive, it has to be completely overwritten at least once. Uh, I have not been able to locate any 00:03:58.839-->00:04:03.743 published documentation that says on a modern hard drive, you can recover data that has been 00:04:03.743-->00:04:09.282 truly overwritten once. That isn't saying that it is not impossible. That's not saying 00:04:09.282-->00:04:13.019 that there hasn't been some branch of the government that has one this sort of thing. It 00:04:13.019-->00:04:18.225 is just not something that people are talking about as being practical. Also a 00:04:18.225-->00:04:23.630 traditional hard drive, fundamentally is a rather stupid piece of equipment. In the fact 00:04:23.630-->00:04:28.335 that it is not doing anything intelligent under the hood, to move data around, manipulate the 00:04:28.335-->00:04:33.673 data, optimize it, it gets the data, it writes it on to the platter and that data is there 00:04:33.673-->00:04:37.811 on the drive. The drive is not gonna go out on its own and say Hey, I wanna move this block 00:04:37.811-->00:04:42.349 from this block because I feel like it. Your normal hard drive is not going to do that. And 00:04:42.349-->00:04:47.354 that's something that forensic investigators recognize. And they aren't gonna move blocks 00:04:49.823-->00:04:54.227 independently of the operating system. So any sort of optimization of the position of 00:04:54.227-->00:04:59.166 data on the platter; because this is a big spinning desk of metal, with magnetic bits 00:04:59.166-->00:05:03.970 scattered all around, sometimes its slow and inefficient to try and find that data. So on the 00:05:03.970-->00:05:08.208 hard drive the operating system a lot of times will try to realign the data... the blocks 00:05:08.208-->00:05:12.679 to defragment the drive. That's something that the drive is not going to go out and do because 00:05:12.679-->00:05:18.418 it feels like it. Solid State Drive on the other hand, does things differently sometimes. 00:05:18.418-->00:05:23.023 The other thing that we know is that you know this hard drive, just a Seagate One, if I had a 00:05:23.023-->00:05:28.628 Western Digital or an Hitachi or another brand, it would behave the same way. So if we're a 00:05:28.628-->00:05:32.599 Forensics Investigator, we get a laptop with a hard drive in it or a desktop with a hard drive 00:05:32.599-->00:05:39.206 in it. We can pretty much use the same universal truths with dealing with this data. Surprise 00:05:39.206-->00:05:44.611 surprise though. Solid state drives change all of these fundamental theories and beliefs 00:05:44.611-->00:05:49.616 that we have. So in order to talk uh and understand about Solid State Drives, I wanna talk 00:05:51.618-->00:05:56.623 about how these drives are constructed and talk about Flash Memory. So Flash Memory is 00:05:59.226-->00:06:05.565 really the replacement and the equivalent of the magnetic platters in a hard drive. So I 00:06:05.565-->00:06:10.804 have an example SSD that doesn't have a cover here, and over the sticker of course, there are a 00:06:10.804-->00:06:16.243 bunch of chips that are flash chips. That's where the data is actually stored on a Solid State 00:06:16.243-->00:06:22.415 Drive. And basically these chap, chips have a number of capacities. They have different 00:06:22.415-->00:06:26.586 amounts of data that can be stored on them and they're, the drive is composed of different 00:06:26.586-->00:06:31.658 amounts of these chips in order to reach the capacity. So if you have a 32 gig chip and you need 00:06:31.658-->00:06:36.663 to have a 256 gig SSD, you'll have eight of those chips that are all together. And the way 00:06:39.199-->00:06:44.638 that those chips work together is an SSD is by using the controller. And the controller 00:06:44.638-->00:06:50.110 is basically the heart and the brain of the SSD that makes the flash memory actually receive 00:06:50.110-->00:06:55.081 data from the operating system and it makes the SSD look like a normal drive to the operating 00:06:55.081-->00:06:59.419 system because the operating system doesn't really care what it's writing to as long as it 00:06:59.419-->00:07:04.858 oohs like a hard drive. Solid State drive or otherwise. So that gap between the controller 00:07:04.858-->00:07:08.995 here on the back of the drive and the flash memory, that's often referred to as the Flash 00:07:08.995-->00:07:15.669 Translation Layer or FTL. Obviously physically, these drives look very very different. 00:07:15.669-->00:07:19.839 Uh your hard drive has the splinning, spinning platters, it's more like a record player 00:07:19.839-->00:07:26.780 with uh metal and magnets instead of needle and scratchy noises. Uh, on the solid state 00:07:26.780-->00:07:31.985 drive, you have the control on flash chips no moving parts completely solid state as the 00:07:31.985-->00:07:36.990 name implies. In terms of Flash Memory itself, the architecture is divided into different types 00:07:40.794-->00:07:46.199 of flash chips and there are different types of technologies for this. There's technologies 00:07:46.199-->00:07:51.204 called F uh, Single Level Cell, SLC and MLC, Multi Level Cell. And they're actually even 00:07:53.306-->00:07:58.678 expanding to make this more in depth where you have a third level. Um most of the ones that 00:07:58.678-->00:08:03.416 you see on the market right now, more expense... least expensive ones of the MLC but as we go to 00:08:03.416-->00:08:08.355 the triple level, the costs are going down because the more you can store on a flash chip. Now 00:08:08.355-->00:08:14.361 on SLC, it's just a one or a zero, in the MLC you have varying levels of charge. So if 00:08:14.361-->00:08:20.033 it's a, zero, it's a, zero zero it's a certain level charge. If it's a zero one, it's a 00:08:20.033-->00:08:24.237 different level charge, if it's a one zero, and a one one, different levels of charge. 00:08:24.237-->00:08:28.641 Obviously this is a little bit slower because you have to have a more precise level of charge 00:08:28.641-->00:08:32.979 as opposed to turning it on and off. So there's performing tradeoffs with this but the cost 00:08:32.979-->00:08:36.182 does go down because you're basically doubling or if you're tripling the amount of data that 00:08:36.182-->00:08:41.054 you can store on the same amount of flash. And one thing that always gets me is that a blank 00:08:41.054-->00:08:45.492 cell is represented is all by ones for whatever reason I think it would be zeros but in the 00:08:45.492-->00:08:52.198 case of flash memory and the engineers among here can tell me why but it's all ones. Um. Just 00:08:52.198-->00:08:57.203 incase any of you have SSD trivia that comes up any day. Uh, in terms of how a flash 00:08:59.539-->00:09:04.744 structure is actually architected, uh the page is the smallest unit of addressable 00:09:04.744-->00:09:10.750 flash in a flash memory cell. And pages, they cannot be overwritten on individual block 00:09:10.750-->00:09:15.755 by block or byte by byte basis. The entire page has to be refreshed. Um, so you can write 00:09:18.024-->00:09:22.796 data into a page that has free space but if you need to return that page to the pool of 00:09:22.796-->00:09:28.201 available pages that has to be done separately because theres risks that by doing that, it's 00:09:28.201-->00:09:32.739 electrically complicated and time intensive in terms of computing time. That you're 00:09:32.739-->00:09:37.677 basically running into situation where you might modify or lose data and that's bad. Uh so only 00:09:37.677-->00:09:44.551 entire blocks are erased at a time. And then when the data is erased or deleted, uh the blocks 00:09:44.551-->00:09:49.823 containing these data is actually just marked as invalid. So that the operating is just 00:09:49.823-->00:09:54.594 like hey, we don't need this anymore. Or the drive is saying these drives.. blocks are no 00:09:54.594-->00:10:00.033 longer needed, I'm gonna mark those as invalid. And they can not be reused until they are 00:10:00.033-->00:10:05.939 completely erased because of the risk manipulating data and it does take a lot of effort and 00:10:05.939-->00:10:11.711 time computationally speaking. Uh so this is all fast in terms of human time, but the slowest 00:10:11.711-->00:10:17.550 thing the an SD can do is erase data at this point and that's why this is done. So the speed 00:10:17.550-->00:10:23.556 of an SSD is really determined on having available blank memory that can be written to. Uh and 00:10:23.556-->00:10:28.328 in order to do that, the controller has to ensure that there's as much of a pool of 00:10:28.328-->00:10:33.333 free flash space at any given point in time. The other thing that we need to be aware of is 00:10:36.135-->00:10:41.141 Flash Wear. So unlike your traditional magnetic drives, where you're dealing with just 00:10:44.177-->00:10:49.482 magnet on metal, flash cells actually have a life cycle. And there's a limited number of 00:10:49.482-->00:10:55.588 times, that can be, they can be written or overwritten. And the wear can be uneven across the 00:10:55.588-->00:11:01.294 drive depending on how that data is used. So you think about how an operating system works. There 00:11:01.294-->00:11:06.499 are things that are almost never gonna change. Like your static operation system files for 00:11:06.499-->00:11:12.005 example are pretty much gonna be written when the OS is installed. Maybe updated as part 00:11:12.005-->00:11:15.341 of a patch or something like that but very very rarely are you gonna see those files 00:11:15.341-->00:11:20.780 change. Whereas your log files for example might be something that are continuously being 00:11:20.780-->00:11:24.717 written to, continuously changing and continuously being modified. And that's gonna be a 00:11:24.717-->00:11:30.156 high level of wear on the disk. And if the drive didn't do anything to deal with that you 00:11:30.156-->00:11:34.627 might run into a case where that part of the flash that has your log directory is gonna be 00:11:34.627-->00:11:39.465 constantly and constantly written and wear out sooner. Whereas your OS section is gonna 00:11:39.465-->00:11:43.670 just be chillin' there like what's up I don't know what's going on here. So the way that 00:11:43.670-->00:11:48.441 the solid state drive controller handles that a lot of times is it's going to move data between 00:11:48.441-->00:11:54.847 those blocks in order to make sure that wears even. And that's the concept of wear leveling. So 00:11:54.847-->00:11:59.419 when we go back to the solid state drive controller, that is really the heart and the soul 00:11:59.419-->00:12:05.491 and the brain and whatever other human analogy you want to come up with of an SSD. And from the 00:12:05.491-->00:12:11.064 perspective of the operating system, that's what makes the SSD look just like a drive and 00:12:11.064-->00:12:15.001 it doesn't have to worry about how to speak flash memory or anything like that. That's all 00:12:15.001-->00:12:21.341 hidden to the user and in turn to the forensics investigator. Uh and all of the managing, 00:12:21.341-->00:12:26.512 reading, writing, flash cells is something that the OS doesn't worry about. And also, all of 00:12:26.512-->00:12:32.318 the more advanced wear leveling features that are part of the SSD are going to be handled by 00:12:32.318-->00:12:37.724 that controller as well. So controllers are really an interesting aspect of the whole 00:12:37.724-->00:12:42.128 solid state drive composition, because there are so many different types of manufacturers 00:12:42.128-->00:12:46.666 that create controllers and different controllers and even individual firmware revisions 00:12:46.666-->00:12:53.039 inside of an SSD can really depend on how the drive behaves. Uh there are cases where a solid 00:12:53.039-->00:12:58.111 state drive behave very differently or had a flaw that was fixed because the vendor 00:12:58.111-->00:13:02.582 produced a new firmware patch and that modified how the drive behaved without having to make 00:13:02.582-->00:13:07.420 any changes. So it's almost like the Tesla of storage where they just push out a patch and all 00:13:07.420-->00:13:12.258 the sudden your car just drives backwards. [Chuckles] So... some controllers they include 00:13:12.258-->00:13:18.998 additional optimizations, including um deduplication where if you're writing the same thing 00:13:18.998-->00:13:24.003 to the flash memory it's only gonna actually write it to flash once and reference it through 00:13:24.003-->00:13:28.775 the controller as these two files hit the same spot of flash. Now this isn't like 00:13:28.775-->00:13:34.013 traditional deduplication inside an operating system where it gives you more space. In terms 00:13:34.013-->00:13:38.418 of what you can actually see as the user, it's the same size solid state drive, but in terms 00:13:38.418-->00:13:42.121 of the flash that's actually being consumed from the perspective of the controller, 00:13:42.121-->00:13:46.626 it's a smaller amount of data. So this reduces flash wear more than anything. Um, that's 00:13:46.626-->00:13:52.398 something that's pretty much transparent to the user in a lot of your SSDs. And then drives 00:13:52.398-->00:13:57.603 also do garbage collection proactively uh to recycle flash box and this is really more of a 00:13:57.603-->00:14:02.875 performance thing than anything. And really that comes down to like the drive needs to know 00:14:02.875-->00:14:08.081 when the data is invalid and when it can recycle the flash box. And so how does it do that? 00:14:08.081-->00:14:14.187 Well think about computing time again compared to human time. Now in terms on when a drive is 00:14:14.187-->00:14:18.591 actually doing something, reading or writing, on a computational scale, it's very 00:14:18.591-->00:14:22.428 very infrequent. So it might seem to us humans that can computers always doing 00:14:22.428-->00:14:26.899 something. But really it's like okay the person hits a key, now I'm gonna wait for a really 00:14:26.899-->00:14:31.704 really long time, they hit the next key. Okay, I'm bored. So when the solid state drive is 00:14:31.704-->00:14:37.810 bored it does other things. So the idle time is really good for performing garbage collection 00:14:37.810-->00:14:43.449 type techniques. Optimize the drive behavior, relocating flash cells to other sides of the 00:14:43.449-->00:14:48.454 drive, to wevel layer, oh wevel... level wear uh or to do garbage collection techniques to 00:14:50.923-->00:14:56.562 free up flash so that you have good performance. So as you can see, these solid state drives 00:14:56.562-->00:15:02.435 are sentient, they are going to be taking over the world one computer at a time. So uh, your 00:15:02.435-->00:15:07.440 laptop you better watch out. This SSD is plotting against you. [Chuckle] So um where we 00:15:09.876-->00:15:14.247 actually come down to how the drive actually knows what to do a lot of times though is the 00:15:14.247-->00:15:19.585 trim command. Uh so this is a ATA command that's implemented through the sata bus and it 00:15:19.585-->00:15:23.656 basically is the way for the operating system to tell the drive controller when data is 00:15:23.656-->00:15:28.995 deleted. So basically instead of the SSD trying to figure out when the data can be deleted and 00:15:28.995-->00:15:33.399 when that data's invalid. The OS proactively notifies the controller and the controller is 00:15:33.399-->00:15:37.603 like okay, I can just wipe these. Uh and that really frequently accelerates the 00:15:37.603-->00:15:40.840 garbage collection process and that's definitely something that I am going to demonstrate as 00:15:40.840-->00:15:45.077 part of this forensics demonstration. But really the thing to keep in mind here is in 00:15:45.077-->00:15:50.883 general your SSDs are gonna behave more and more like your Enterprise SAN controller or 00:15:50.883-->00:15:56.889 RAID array than simply a simple dumb hard drive. So this is one of those things where an SSD is 00:15:56.889-->00:16:01.260 fundamentally different from your normal storage and that definitely has forensics 00:16:01.260-->00:16:07.500 implications and really the questions that I have when I started looking into SSD storage 00:16:07.500-->00:16:13.172 years ago, was how do we determine if solid state drives impact the forensics process? 00:16:13.172-->00:16:19.145 And really what are those actual impacts? Uh I had a lot of questions along the lines of if 00:16:19.145-->00:16:24.317 we delete a file from an SSD uh people are saying that it might be different but what are those 00:16:24.317-->00:16:29.589 cases that cause that uh and when can I say yes that data's gonna be there or no it's not. 00:16:29.589-->00:16:32.725 Uh how do we standardize that, how do we come up with the framework for understanding 00:16:32.725-->00:16:37.864 that? And really the question that is facing a lot of forensic investigators, including a 00:16:37.864-->00:16:42.201 number of them that I've interviewed is they're treating SSDs like normal hard drives 00:16:42.201-->00:16:46.272 when they're doing investigations and really if you're looking into to this data 00:16:46.272-->00:16:51.377 as someone who's an investigator and not understanding the implications uh you have a high 00:16:51.377-->00:16:55.214 chance of not getting what you expect from one of these drives without knowing what you're 00:16:55.214-->00:17:01.721 looking for. And you could be wasting a lot of time while trying to do this. So there has 00:17:01.721-->00:17:05.825 been some previous research that has been done on Solid State Drives and the forensic 00:17:05.825-->00:17:10.963 implications. A lot of this research has looked at the fact of filling an entire SSD with 00:17:10.963-->00:17:16.068 the same string of text and trying to see when that part of the flash is manipulated. And 00:17:16.068-->00:17:20.406 fundamentally there have been a lot of studies that have shown yes, there are some changes that 00:17:20.406-->00:17:24.777 have happened. Data is destroyed. Uh but none of the research that I could find was 00:17:24.777-->00:17:30.549 really looking at this across a wide pool of solid state drives in a very pain staking, here's a 00:17:30.549-->00:17:36.522 file, I delete it, what happens? Which in my mind, that was the simplest brain dead question 00:17:36.522-->00:17:41.160 that I had for when I was trying to look at this research. So if i deleted a file, is it gone, or 00:17:41.160-->00:17:46.165 no? Which really,I think is a good question to really start out with. So, my research 00:17:49.602-->00:17:54.006 represents really from what I could find one of the most comprehensive studies of the 00:17:54.006-->00:18:00.279 recoverability of deleted files from solid state drives to date. So I had a pool of SSDs that uh 00:18:00.279-->00:18:05.251 we're gonna go through and eleven different two-part tests that really built on each other 00:18:05.251-->00:18:11.557 to trigger subtle difference in SSDs to really understand when data is deleted, when it can be 00:18:11.557-->00:18:17.897 recovered, and why. And really it's primarily focusing on deleted file recoverability 00:18:17.897-->00:18:23.369 because that's what at the basic a lot of the law enforcement forensics at uh the lowest 00:18:23.369-->00:18:27.907 possible level really ties into. So without understanding the basics, we can't really go 00:18:27.907-->00:18:34.413 further. So the purpose of my research was really to comprehensibly study the impact 00:18:34.413-->00:18:39.218 of solid state drives on a forensics data acquisition investigation processes. And 00:18:39.218-->00:18:44.523 really look at it from and if I'm doing current forensics practices against these drives, 00:18:44.523-->00:18:50.062 are they valid? And can they be used all of the time? Can they be used none of the time, or 00:18:50.062-->00:18:54.667 some of the time? What cases are they okay? And really to determine if the traditional 00:18:54.667-->00:19:01.407 forensics approaches are sufficient. Um, all of my experiments for this research 00:19:01.407-->00:19:07.046 were designed to built on... build on each other. So every possible change that I could do 00:19:07.046-->00:19:11.984 for this were intended to be the smallest possible difference. Really trying to minimize all my 00:19:11.984-->00:19:17.890 variables as much as possible. And really incrementally try to trigger certain difference that 00:19:17.890-->00:19:23.629 I have seen or read about as options for causing an SSD to behave in a certain way. And 00:19:23.629-->00:19:30.302 really every test uh was two parts. One was a deleted file test where I would have some 00:19:30.302-->00:19:36.609 type of file on an SSD that was deleted and as we know on your normal hard drive, deleting a 00:19:36.609-->00:19:42.715 file doesn't make it go away. So really a simple way for me to tell if a SSD is doing something 00:19:42.715-->00:19:47.486 is to put a file on a whole bunch of SSDs, make sure it's written on that file or on that 00:19:47.486-->00:19:52.224 drive for sure, delete it. Image the drive, try to recover it, see what happens. And it's 00:19:52.224-->00:19:57.229 really simple but it is a very blatant way of demonstrating the difference. The next part for 00:19:59.765-->00:20:04.970 every test was a quick format test. Where I would quick format all the drives and try the same 00:20:04.970-->00:20:09.241 recovery including file recovering techniques because that's typically when the file 00:20:09.241-->00:20:13.779 systems gone. And uh fundamentally that really demonstrated even further 00:20:13.779-->00:20:19.285 differences. Uh so, the other thing that I learned as part of this research is trying to image 00:20:19.285-->00:20:24.056 a whole bunch of SSDs for a bunch of tests is really really boring and annoying. So when 00:20:24.056-->00:20:28.627 you're dealing with hundreds of gigabytes of drive imaging over a usb two point oh write 00:20:28.627-->00:20:33.632 blocker, it's really slow. So um, so all these tests, they were designed to isolate 00:20:36.469-->00:20:41.907 different variables. Some of the variable that I wanted to test were trim state. So this could 00:20:41.907-->00:20:48.481 be done in a number of different ways. Uh since trim is something that's an ATA command that is 00:20:48.481-->00:20:54.353 only passed over the sata bus uh it's something that you can basically control the state of 00:20:54.353-->00:20:59.391 by having a sata bus or not. So if you connect to drive via USB it's not gonna pass the trim 00:20:59.391-->00:21:03.996 command because it's basically going block that from happening. Operating systems you can turn 00:21:03.996-->00:21:09.902 trim on and off. Uh in Windows 7 for example, there's a command line perimeter for doing that. 00:21:09.902-->00:21:14.340 There's also operating systems that natively don't support trim. Uh Windows XP is great, 00:21:14.340-->00:21:19.178 but it natively doesn't support a whole lot of other things like you know, security. So... 00:21:19.178-->00:21:23.249 [Laughter] Obviously there are hopefully not too many people using that, but it's something 00:21:23.249-->00:21:27.887 that you might see because there are plenty of agencies that are still using XP for different 00:21:27.887-->00:21:33.692 sorts of things unfortunately and makes all the security people cry. Um, there are other 00:21:33.692-->00:21:38.564 types of things that I was looking to isolate for this. Uh the number of files present. So 00:21:38.564-->00:21:42.434 is a single text file for example gonna behave differently than an image file because it's 00:21:42.434-->00:21:47.373 a larger type of file. So would we see the text file still be there and the image file gone or 00:21:47.373-->00:21:53.012 vice versa? Would having more than one image file on the drive make a difference? Or if I 00:21:53.012-->00:21:57.249 deleted a file every minute over the course of an hour, would some of the files be there and 00:21:57.249-->00:22:00.853 some of them be gone or would they all be gone or would they all be there? Uh, all those 00:22:00.853-->00:22:07.159 different types of variables for what I was looking to try to isolate. So let's get to the 00:22:07.159-->00:22:12.932 drives that I was using for this testing. I ended up using seven different drives. Six SSDs and 00:22:12.932-->00:22:17.770 one controlled drive. And all of these drives are really picked for specific reasons to try to 00:22:17.770-->00:22:22.608 understanding different controller types or different manufacturers to understand 00:22:22.608-->00:22:29.081 they'd behave. Uh so my control drive was jus the Seagate normal hard drive that you find in any 00:22:29.081-->00:22:33.886 laptop. Since laptop drives, or normal hard drives are gonna behave pretty much the same way 00:22:33.886-->00:22:39.325 either way, this any control is pretty much as good as ay other for that. Then in terms of the 00:22:39.325-->00:22:44.330 other SSDs. Have these handful ones. So I had a Crucial SSD, uh this one has firmware thats 00:22:47.366-->00:22:52.371 written by Crucial on a MArvel chip set. Um so they under, they handle all the software in house 00:22:55.708-->00:23:02.281 for this drive and it's not based on a third party controller. Likewise the same 00:23:02.281-->00:23:07.286 for Intel who also has their own controller. Uh and both the Crucial and Intel controllers 00:23:09.755-->00:23:15.361 are different. So I was looking to see if those would result in any different behavior. Uh then 00:23:15.361-->00:23:21.300 we had the OZC and the Patriot which actually both have the same controller and they're just 00:23:21.300-->00:23:25.638 different manufacturers. So I wanted to see if having the same controller and the same firmware 00:23:25.638-->00:23:30.576 revision just with different manufacturers would result in different behavior. And a lot of 00:23:30.576-->00:23:35.214 times, it turned out to be very much the same except the OCZ one died partially through the 00:23:35.214-->00:23:40.219 testing. SO after it stopped working, it didn't behave in the same way. [Laughter] Uh then 00:23:42.988-->00:23:48.160 there was the Samsung. Which Samsung has their own controller which is actually a three core 00:23:48.160-->00:23:54.333 uh controller and I could find zero documentation of any of those three cores would actually 00:23:54.333-->00:23:59.338 do. But it is their own firmware and their own implementation. So it is different than Crucial and 00:24:01.707-->00:24:05.611 Intel and all that. And it doesn't use a generic controller, the SandForce one 00:24:05.611-->00:24:11.717 that's in the OCZ and the Patriot. And then there was also this super talent one which was 00:24:11.717-->00:24:16.822 interesting because it was one of the first SSDs that I was able to locate. Uh and inside of 00:24:16.822-->00:24:23.729 this, this stripped case that shows nothing, is actually a one point eight inch SSD with a 00:24:23.729-->00:24:28.734 parallel to sata bridge chip. So this is like ancient SSD technology from 2009. So... 00:24:31.704-->00:24:37.443 [Laughter] In terms of ancient, it's not really ancient by human standards but by technology 00:24:37.443-->00:24:43.215 standards it should be just probably really old. Um, but this was interesting for me 00:24:43.215-->00:24:48.754 because of having a sata to parallel to bridge chip. That shouldn't allow any sata 00:24:48.754-->00:24:54.460 commands like trim or anything to even get the SSD controller. So I wanted to see how you know 00:24:54.460-->00:25:01.033 a modern SSD versus a really old SSD behaved and compared that to a normal hard drive. So all of 00:25:01.033-->00:25:05.070 these were selected for different factors and I really wanted to try to look at this 00:25:05.070-->00:25:10.642 from a picture of the SSD landscape. Obviously I couldn't go out and buy everything SSD 00:25:10.642-->00:25:14.913 that existed because uh I don't have millions of dollars laying around. But this should be a 00:25:14.913-->00:25:20.786 good picture of what we should expect to see and these tests can be used across new SSDs and 00:25:20.786-->00:25:24.690 new manufacturers to understand so if you run into something you've never seen before, I've 00:25:24.690-->00:25:28.627 never seen before, you can do similar tests and really get a basic understanding of what to 00:25:28.627-->00:25:35.534 expect. Now my Forensics Lab for this consisted of a dedication evidence creation and evidence 00:25:35.534-->00:25:42.341 collection machine. Uh I never ran an operating system or anything like that on the test 00:25:42.341-->00:25:47.246 SSDs because I wanted to eliminate the variables as much as possible. So the only data 00:25:47.246-->00:25:52.017 that was written or read for these SSDs were the files I was working with. I.. it would 00:25:52.017-->00:25:55.654 definitely be interesting to look at this from an operating system perspective but tracking 00:25:55.654-->00:26:00.459 that in an efficient and sane way just was not something that I really felt for this type of 00:26:00.459-->00:26:04.396 research. Someone wants to run with that, by all means go ahead and look at that. It's 00:26:04.396-->00:26:09.268 definitely something that needs to be explored. Uh and I also look to use Open Source. So the 00:26:09.268-->00:26:14.606 Caine Linux Forensics distribution uh was my choice distribution for collecting and 00:26:14.606-->00:26:20.212 analyzing all the data. And all the evidence was collected using a forensics writeblocker. Now 00:26:20.212-->00:26:23.782 there has been research hat has shown that an SSD on a writeblocker has been 00:26:23.782-->00:26:28.821 demonstrated to modify data in some cases. Uh I wanted to look at this from the perspective 00:26:28.821-->00:26:34.660 from someone who was analyzing the drive without doing any chip by chip analysis or bypassing 00:26:34.660-->00:26:39.097 the controller. So I was looking at this as a traditional forensics investigator using the 00:26:39.097-->00:26:44.102 tools that would be accepted in court to in order to analyze data. So for one of our sample 00:26:47.406-->00:26:51.710 tests and we'll just start with what really was one of the fundamental and most basic 00:26:51.710-->00:26:56.715 tests. Was the idea of writing a single image to a file. And by image I just mean picture. Uh so 00:26:59.651-->00:27:03.789 I took a picture, I wrote it to all of these disks. And I mounted the disks, and that's 00:27:03.789-->00:27:08.927 important because caching is something that could happen on an SSD where it would just be in 00:27:08.927-->00:27:13.065 ready only memory. And what I wanted to make sure the drive had that data truly committed to 00:27:13.065-->00:27:17.069 flash. So that I would look at it in another machine and it would still be there. Uh so that 00:27:17.069-->00:27:23.375 I knew it was in the cache, in the memory and written to flash. Uh and then remount the drive, I 00:27:23.375-->00:27:28.046 would delete it and then make sure that I would image the drive and see if it was 00:27:28.046-->00:27:34.186 recoverable. Now that seems simple, and if you're knowing how forensics are working. Which 00:27:34.186-->00:27:38.957 is everyone here. You delete a file off the drive, you don't do anything special. It should be 00:27:38.957-->00:27:45.497 there, right? Yeah. I'm getting some nods, that's good. Now across the tests that I did on 00:27:45.497-->00:27:50.502 SSDs, it was not always recoverable. Now that begs the question, why. So different 00:27:53.772-->00:27:58.877 variables, and I'm gonna get into this in the results, but the drives did fundamentally 00:27:58.877-->00:28:02.814 behave very differently. So some of these drives would go ahead and almost purge the data 00:28:02.814-->00:28:07.819 instantly once it was deleted. And a lot of times, that was the component of the trim state. A 00:28:07.819-->00:28:13.292 lot of times, there were different factors but that was probably the biggest one. Um 00:28:13.292-->00:28:17.296 that would result in the data being basically completely recover... un or uh completely 00:28:17.296-->00:28:22.301 unrecoverable in that period of time. Um, the second test for every test run was a quick 00:28:24.803-->00:28:29.808 format. Uh so I would take the same drive, same data I imaged. I'd go ahead and quick format 00:28:31.944-->00:28:37.316 the drive, take an image of the drive after I unmounted it and try to do file recovery. And 00:28:37.316-->00:28:40.652 this was a lot of time done to be done with file carving because the op or the file 00:28:40.652-->00:28:46.158 system was gone at that point. Uh most of the time, on uh I would say all of the time on 00:28:46.158-->00:28:51.830 your normal hard drive, that data is more or less recoverable. Uh on your SSDs a 00:28:51.830-->00:28:57.502 lot of times it was completely gone obviously any SSD where it was gone in the test beforehand, 00:28:57.502-->00:29:01.974 the first test, it didn't come back. Uh, which is probably a good thing. That would be really 00:29:01.974-->00:29:08.347 weird. But for a lot of the drives where it was originally still there, the quick format 00:29:08.347-->00:29:13.352 would make that go away as well. So our understanding of data sanitization on an SSD level 00:29:15.554-->00:29:21.994 fundamentally does change as a result of just you working with an SSD. Uh but it's not always 00:29:21.994-->00:29:27.366 the case. So as I was doing these tests, I started to noticed some patterns. So all 00:29:27.366-->00:29:30.836 the files in the controlled drive were pretty much recoverable all the time. Uh 00:29:30.836-->00:29:37.542 there was a very significant difference in SSD behavior and I started to see them break into 00:29:37.542-->00:29:40.846 two different groups. Where there were some that were resulting in a very low 00:29:40.846-->00:29:46.785 recoverability in a lot of cases. But there were also a number of SSDs behaved very very 00:29:46.785-->00:29:52.324 similar to the control hard drive and the ones that have very low recoverability were 00:29:52.324-->00:29:56.461 pretty consistent across the board in those tests and the ones that had reasonably high 00:29:56.461-->00:30:01.466 recoverability in a lot of tests were pretty common as well. Uh so without further ado, I wanna 00:30:04.269-->00:30:09.941 dig into the results of the research and scare you with you some bar charts which uh aren't 00:30:09.941-->00:30:14.546 gonna be too scary because I don't wanna freak people out with numbers and stuff like 00:30:14.546-->00:30:19.418 that. I tire to break this down in a bunch of different ways to really illustrate the points. Um 00:30:19.418-->00:30:22.921 if there are questions about this, we can definitely talk later after this presentation as 00:30:22.921-->00:30:28.994 well. Uh but really this is just an overall scale of everything that I saw across the test. 00:30:28.994-->00:30:35.701 You'll see all the way in the left is the Seagate hard drive recoverability. And I apparently 00:30:35.701-->00:30:40.706 don't know how to use this but right here, we see the Seagate drive basically matches the 00:30:43.809-->00:30:50.215 Patriot SSD's behavior and the Super Talent SSD's exactly across all of the tests. The 00:30:50.215-->00:30:55.220 thing that you'll notice here, is, let me make that go away. The OCZ SSD it's very close here 00:30:59.291-->00:31:04.896 to the Patriot one. Um this was the point where the Patriot failed. So it was behaving 00:31:04.896-->00:31:10.936 exactly identical and based on everything I had seen. The same controller, I would expect, I 00:31:10.936-->00:31:15.307 guess I could make that yellow, but I would expect that bar to be exactly the same had the 00:31:15.307-->00:31:20.078 drive continued working throughout the test. Just based on extrapolating the result that 00:31:20.078-->00:31:25.083 I was seeing. But we also look at these, there are some drives here at the bottom. The Crucial, 00:31:28.253-->00:31:34.826 your Intel and your Samsung that are a lot lower recoverable than your normal SSD or your normal 00:31:34.826-->00:31:40.532 hard drive. And that was definitely interesting. But really this graph by itself is 00:31:40.532-->00:31:45.103 kind of misleading just like every other graph. So I need to go into some more detail to 00:31:45.103-->00:31:50.575 really paint the picture of what was happening and really make this clear. So like I said, the 00:31:50.575-->00:31:55.680 trim state was really the biggest factor impacting recoverability. So here on the 00:31:55.680-->00:32:00.619 left is my result of recovering data when trim was on. And then on the right is when trim was 00:32:03.188-->00:32:09.161 off. So you look at this from just obviously you have trim, it's going to make your chances 00:32:09.161-->00:32:14.399 of recovering data a lot lower. Now these ones right here at the bottom, your Crucial and your 00:32:14.399-->00:32:19.571 Intel were a single text file on the drive saying, This is a text file, because I'm really 00:32:19.571-->00:32:25.644 creative. Uh that single text file was not something that when it was deleted was enough to 00:32:25.644-->00:32:29.748 trigger garbage collection or trim event where it actually overwrote that part of flash. 00:32:29.748-->00:32:35.754 Every other case for the Crucial and the Intel it was an image file that was large enough that 00:32:35.754-->00:32:39.391 was something the drive controller saw significant enough to wipe that data 00:32:39.391-->00:32:44.763 proactively. So in a, pretty much any case with a large enough file on those type of 00:32:44.763-->00:32:49.768 SSDs with trim enabled, that data's gone upon deletion. Immediately. Um, the Samsung was 00:32:52.170-->00:32:57.175 pretty darn close and then if we just clear this out we look at the other ones are all pretty 00:33:00.212-->00:33:05.217 much near the top there. If we look at when Trim was either turned off, unavailable because 00:33:07.552-->00:33:13.258 operating system or the bus that I was using for testing the drive. Uh, it was pretty much 00:33:13.258-->00:33:19.564 the case where a lot more of a level of playing field where yes, your Intel and your Crucial 00:33:19.564-->00:33:26.338 here were pretty similar to what they were before at the bottom. And even your OCZ I guess that 00:33:26.338-->00:33:32.844 is kind of an anomaly, because of how it was behaving and sh... it ended up would match just 00:33:32.844-->00:33:38.450 like the Patriot. But a lot of these drives with Trim off behave a lot closer to a normal 00:33:38.450-->00:33:43.488 hard drive. So not quite the same. There's still gonna be cases where data goes away but 00:33:43.488-->00:33:49.127 it's definitely a case where you see lower recoverability significantly lower 00:33:49.127-->00:33:55.700 recoverability with trim turned on an opposed to off. This does combine quick format and non 00:33:55.700-->00:34:00.639 quick format. So uh... Wanted to look at file deletion first and then we'll look at formatting. 00:34:04.242-->00:34:09.881 So this takes away all of the formatting tests and just looks at I had a file and I deleted it 00:34:09.881-->00:34:14.886 regardless of trim being on or off or anything like that. So you will see across the board 00:34:16.955-->00:34:22.794 your Crucial, Intel, and lesser degree your Samsung are lower recoverability. Your Seagate and 00:34:22.794-->00:34:27.032 your Patriot and your Super Talent basically act like normal hard drives. So we basically 00:34:27.032-->00:34:31.036 have two different classes of drives where something that behaves very close to normal 00:34:31.036-->00:34:36.474 hard drive and something that behaves very different. But really looks more blatant and 00:34:36.474-->00:34:41.179 more obvious is the quick format recoverability. And we know on a normal hard drive you can pretty 00:34:41.179-->00:34:46.351 much recover data if its quick formatted. Uh on an SSD, uh if you have a Patriot, you're good. 00:34:46.351-->00:34:51.856 Uh and your Super Talent, your good. But if you have one of the other drives, if you quick 00:34:51.856-->00:34:57.162 format the drive, it's pretty much gone. And that's a really a fundamental change for how we 00:34:57.162-->00:35:02.467 view forensics and so... if you're dealing with a drive that's been quick formatted and 00:35:02.467-->00:35:06.104 it's one of these ones that offers very low recoverability, your chance of getting evidence 00:35:06.104-->00:35:11.109 from that is gonna be pretty low. So really, general observations for here is that 00:35:13.611-->00:35:18.450 the solid state drives, they cant be considered to behave the same or identically to 00:35:18.450-->00:35:24.289 traditional hard drives from a forensics perspective. Deleted file recoverability does vary 00:35:24.289-->00:35:30.729 significantly and it really depends on the type of drive and the controller. And as we saw 00:35:30.729-->00:35:34.866 different factors, you know, if trim is on or off, how the drive is connected, what operating 00:35:34.866-->00:35:39.804 system. Uh, what types of files are being deleted? Is there a quick format in play? Those 00:35:39.804-->00:35:45.777 really impact the likelihood of recovering data. So that kind of leads to my contributions to my 00:35:45.777-->00:35:50.849 research. I really think that this would be something that can be referenced. Uh when 00:35:50.849-->00:35:55.687 attempting to recover deleted files from an SSD and really to help understand uh what 00:35:55.687-->00:36:01.860 situations lead to successful recovery. Recoverability. So if you're someone who needs to face 00:36:01.860-->00:36:05.597 a solid state drive in a forensics investigation this framework for some of the 00:36:05.597-->00:36:10.769 testing can really be used to understand what you need to do to see before you spend a lot of 00:36:10.769-->00:36:15.106 time trying to recover data off of that drive, if it's something that's worth while or not. And 00:36:15.106-->00:36:20.111 really the impact of trim, has been something that's bee published on a lot lesser scale. 00:36:22.280-->00:36:26.384 Uh this is really the biggest demonstration that I could find of trim actually having an 00:36:26.384-->00:36:32.357 impact on forensics recoverability uh across a large range of drives whether or not 00:36:32.357-->00:36:37.362 it's turned on or off. So really to look at the conclusions that I have for this. Uh as a 00:36:39.497-->00:36:43.735 forensics investigator, you really need to be acutely aware of the drive differences. You 00:36:43.735-->00:36:48.039 need to understand, yes, first and foremost that you're dealing with an SSD. Uh you need to 00:36:48.039-->00:36:53.445 understand that the drives are gonna behave differently and how to recover data from them. And 00:36:53.445-->00:36:59.017 that SSDs do negatively impact the recoverability. And then we also have to look at modifying 00:36:59.017-->00:37:03.088 our forensics practices to recognize these drives and understand what they can be 00:37:03.088-->00:37:07.459 done. Well what can be done with them in order to get data back. Or if there's any way that we we 00:37:07.459-->00:37:12.097 have to look at this at a more deeper level. Uh if we look at the flash, bypassing the 00:37:12.097-->00:37:16.034 controller. Is that something that might be forensically practical? It's... one of the 00:37:16.034-->00:37:21.072 things that I think is a great opportunity for some future work. Uh so definitely if when 00:37:21.072-->00:37:26.177 we're looking at the future work here. Uh bypassing the flash controller is something that is 00:37:26.177-->00:37:31.216 definitely interesting and way beyond my technical capabilities to understand how that electrons 00:37:31.216-->00:37:34.752 works. So some of you I know are smart enough to do that. Definitely something to look 00:37:34.752-->00:37:38.823 at.uh looking at how an operating system makes a difference. If the operating 00:37:38.823-->00:37:43.228 system's running looking at more forensics data. That could definitely be something that is 00:37:43.228-->00:37:48.800 an opportunity to look at as well. So I'd like to acknowledge a couple of people who helped 00:37:48.800-->00:37:55.406 make this presentation possible. Uh, three professors at RIT uh dealt with me for way too long, 00:37:55.406-->00:37:59.844 for getting this research done. It took years. Uh I'd like to thank them, Dr. Pan, Dr. Mishra 00:37:59.844-->00:38:03.314 and Professor Stackpole. And then Bill Mathews at Hurricane Labs for supporting me through 00:38:03.314-->00:38:07.418 this research. With that I'd like to open the floor for any questions. And I will leave my 00:38:07.418-->00:38:12.423 contact info up here if anyone wants to stop by. Thank you very much. [Applause] So, yes over 00:38:14.559-->00:38:19.564 there. [Inaudible question from audience] Okay so the question was, is there a way to tell when 00:38:24.569-->00:38:29.574 you get the computer whether the trim state is on or off. So that is something thats configured in 00:38:38.783-->00:38:43.588 the operating system. Uh so you would have to look at the operating system first in order 00:38:43.588-->00:38:50.528 to do that. Uh which of course has forensics implications as well. Uh so one of the ways that 00:38:50.528-->00:38:55.934 I would suggest maybe doing this is to image the drive first and then you can actually use the 00:38:55.934-->00:39:00.805 image copy as a way to interrogate what's going on. Uh that way if you modify it, 00:39:00.805-->00:39:06.678 you're not causing any problems with the original evidence. >> Is it in like registry..? >> Is 00:39:06.678-->00:39:11.449 it something that you can run just a command on like a Windows system. Uh there's just uh 00:39:11.449-->00:39:17.455 either a PowerShell or a Command Line. It'll just print the value of that whether it's on or off. 00:39:17.455-->00:39:22.460 I believe it's stored in the emergency as well when you make that change. Next. >> Um, I was 00:39:25.430-->00:39:32.170 wondering uh do you have any indication of how other busses like M2 or PCI Express or Stats 00:39:32.170-->00:39:37.175 would respond? >> Yes, so M2 and PCIE for sata type drives uh basically function the same way. 00:39:42.213-->00:39:48.353 So it it is passing a sata type bus like an M sata disk. It looks like a PCIE slot but it is 00:39:48.353-->00:39:53.558 sata. So that would behave the same way as I was saying. M2 is the same idea or it's the sata 00:39:53.558-->00:39:59.697 bus. Now on SAS a lot of times that's gonna be behind a raid controller. And the raid 00:39:59.697-->00:40:04.068 controller often does not pass the trim through. Although some of the new raid controllers will 00:40:04.068-->00:40:09.440 actually do that. Uh so that would be a little bit of a different behavior. Now there 00:40:09.440-->00:40:14.045 was one other bus that you mentioned? >> SAS, uh PCIE and... >> Okay, so we covered 00:40:14.045-->00:40:17.181 everything. >> Um, one more quick question. >> Yeah, sure. >> What, what about Enterprise 00:40:17.181-->00:40:22.954 grade drives that have over capacity? >> So, every SSD in some way has some kind of over 00:40:22.954-->00:40:28.226 capacity. >> Okay. >> So you look at your hundred twenty gig SSD typically has 128 gigs of 00:40:28.226-->00:40:34.332 flash. Uh the Enterprise ones could be you know a hundred gig disk that has hundred twenty 00:40:34.332-->00:40:39.370 eight gigs of flash. So the behavior should be very similar because the over provision flash 00:40:39.370-->00:40:44.342 is still gonna be there. Alright. And one of the tests that I did actually simulated 00:40:44.342-->00:40:48.546 over provisioning the flash by partitioning the drive a lot smaller which is the same 00:40:48.546-->00:40:54.786 fundamental idea. And basically I observed the same behavior that I expected. >> Thank you. 00:40:54.786-->00:41:01.059 >> Uh we have another line over here. >> Yeah, sure. >> Um so you mentioned uh bypassing the 00:41:01.059-->00:41:07.165 uh, the FTL. Um some studies have already been done on that by UC San Diego and the results 00:41:07.165-->00:41:11.536 were published in I believe in 2011. Um so... >> Yes, I uh actually looked into some of 00:41:11.536-->00:41:15.306 that research and I, I know exactly what paper you're talking about. Yeah. >> Yeah, 00:41:15.306-->00:41:20.311 using the, the custom FPGA controller to bypass the behavior of the FTL. Um.. So 00:41:23.014-->00:41:26.317 yeah, just wanted to make sure that everybody else is aware of that as well. >> No, yeah, that 00:41:26.317-->00:41:30.722 research is definitely interesting and I think there's you, that a lot of that was 00:41:30.722-->00:41:36.494 looking at the contents of the flash cell itself and trying to assemble that would be really 00:41:36.494-->00:41:42.467 interesting. Like how do we pull actual files off of that because uh definitely if you're looking 00:41:42.467-->00:41:47.538 for a string of attacks that's a great way to find that data. If you're looking for images or 00:41:47.538-->00:41:52.944 larger files, trying to piece all that together. Definitely something that is more work can 00:41:52.944-->00:41:57.949 be done. >> One more question. >> Yeah, no I get one more question, okay. So you guys we 00:42:00.585-->00:42:06.791 can talk afterwards but uh I will take one from this way. >> Hey boss, how's it going today? 00:42:06.791-->00:42:11.262 >> It's pretty good. >> So I actually work for a storage manufacturing company and I was 00:42:11.262-->00:42:13.464 wondering if you've given any consideration or if you can talk to the impact of Bit rot on SSDs 00:42:13.464-->00:42:18.569 uh for forensics investigations especially since bit rot on SSDs will occur so much faster than 00:42:18.569-->00:42:23.574 on a hard... hard drive. So in terms of bit rot, bit.. in terms of bit rot, what he's referring 00:42:25.743-->00:42:30.848 to is the fact the flash actually degrades over time. So a normal hard drive, there's 00:42:30.848-->00:42:36.320 some magnetic decomposition as times goes on. On a flash cell it's quicker. Just to make sure. 00:42:36.320-->00:42:42.460 >> yeah, no, exactly right. >. yeah so that sort of thing, from a forensics case, a lot of that 00:42:42.460-->00:42:47.298 is gonna be not necessarily identified through the controller because the 00:42:47.298-->00:42:51.469 controller it's gonna either see that and it's gonna be there or it's not. Now the controller 00:42:51.469-->00:42:56.040 might proactively move that just somewhere else, or refresh the contents of flash to basically 00:42:56.040-->00:43:01.179 reenergize the cells. But from a forensics perspective, I don't know if that's gonna be 00:43:01.179-->00:43:05.450 something that's necessarily gonna be available throughout eh controller. >> Well the concern 00:43:05.450-->00:43:09.087 is is that uh in the past, that we've actually been approached by some people that we're trying 00:43:09.087-->00:43:13.291 to forensically analyze some of the SSDs in some of our products. And the problem is 00:43:13.291-->00:43:17.829 that you uh achieve a warrant or similar you take this equipment out of it's source location. As 00:43:17.829-->00:43:22.467 soon as you power it down, the controllers no longer have the ability to scrub the SSDs. So 00:43:22.467-->00:43:27.271 you, if that stuff is sitting in a forensics labs, you know two, three months before it's 00:43:27.271-->00:43:32.009 analyzed, by the time you get to analyzing it, three, four months some SSDs will already start to 00:43:32.009-->00:43:37.648 lose data. >> Yeah, so one of the things that I noticed as part of this research is pretty 00:43:37.648-->00:43:44.422 much all of the cleaning of the data happened almost instantly. So in terms of deleting data I 00:43:44.422-->00:43:50.127 think it's gonna be pretty much gone regardless. Now in terms of actual stored data on there, uh 00:43:50.127-->00:43:54.932 I didn't see any cases where if I left these drives sit for you know months on end that the data 00:43:54.932-->00:44:01.739 would be gone or anything like that. Uh now, it's I guess it's possible where that bit rot 00:44:01.739-->00:44:06.077 could happen in a period of time. I, it's just not something I saw happen as part of this 00:44:06.077-->00:44:10.214 research. >> Alright. Beautiful. [Applause] >> yeah. Alright thank you very much. I will be 00:44:10.214-->00:44:14.652 outside uh for any other questions you guys might have. Thank you very much, you've been 00:44:14.652-->00:44:16.554 a great audience, I really appreciate it.