 So welcome. Thank you very much for coming. It's always awesome to see a room full of people and it's humbling for me as a speaker to really have such a great audience showing up and listening to me say things. I'm always shocked. So give yourself a round of applause. Thank you very much. So without further ado, I'm going to talk a little bit about myself and then we'll get to the actual cool part of this presentation. I'm Tom Kupchak and I am the director of whatever at Hurricane Labs where I'm pretty much responsible for taking the customers problems and giving them to the engineers to solve them. So I don't actually do any work, but I'm a manager but I'm still an engineer and a researcher at heart and this solid state drive forensic research has absolutely nothing to do with what I do professionally. But it's still interesting and I think this is one of those topics that we really are lacking a lot of information on and I had some fundamental questions when I was looking at the research that was done on this topic that I really wanted to find out the answers to. And over the course of the next 40 minutes or so, I'm going to go through those questions. We're going to talk about how solid state drives operate and the technologies behind them. And we're going to talk about what you need to consider if you're trying to do a forensics investigation on a solid state drive and want to see if the data is still around. To determine if it's actually worthwhile to get that data back or if there's going to be something that's going to make it virtually impossible. Also during the course of this presentation, you might notice that I make some jokes that are quite bad. That's what the hashtag Tom joke is for. Internally in our chat system at Hurricane, we have something that you type in, bang Tom joke and it returns 404 humor not found. So I'm sure you guys all have access to things that can post things on the internet. Either in your pocket or in your lap or something like that. So if I say something like that, go ahead and use the hashtag Tom joke and we'll make it a thing. It's the dad jokes of IT. So without further ado, why we are here, current forensics technologies and practices for working with hard drives they're well defined. When you get a hard drive, one right here. Normal laptop hard drive, if you're a forensic investigator and you got one of these, you would know what to do with it. It's well defined. Now solid state drives, they do behave differently in a lot of cases and they present a whole lot of new challenges. And really, this presentation is going to look to explore those differences in detail, what challenges you need to be aware of and considerations when working with an evidence bearing solid state drive. But first, I want to make sure that we get everyone up to speed on hard drive forensics. So I'm going to do a quick overview of traditional hard drive forensics and what that means to you, just to make sure we're on the same page. This should be a review for a lot of you in the audience and definitely something that we all pretty much have standardized and understood. But really what we know is if you have a hard drive, one of these, you delete a file off of it, it is often, if not never truly deleted. It's very easy to recover that in a lot of cases and that data is not truly gone. And this really has become a cornerstone of a lot of the basic forensic practices. Someone has something they shouldn't have hard drive, they delete it, the feds undelete it through not all that complicated processes, files come back, they throw you in jail for 47,000 years and then everything's good. But you know how that works. Now if you were to be like, I want to delete this data and you quick format that hard drive, the data is still there. It's not truly deleted, it's not overridden. And in order for data to be deleted from a hard drive, it has to be completely overridden at least once. I have not been able to locate any published documentation that says on a modern hard drive, you can recover data that has been truly overridden once. That isn't saying that is not impossible. It's not saying that there hasn't been some branch of the government that has done this sort of thing. It is just not something that people are talking about as being practical. Also, a traditional hard drive fundamentally is a rather stupid piece of equipment. In the fact that it is not doing anything intelligent under the hood to move data around, manipulate the data, optimize it, it gets the data, it writes it onto the platters, and that data is there on the drive. The drive is not going to go out on its own and say, hey, I want to move this block from this block because I feel like it. Your normal hard drive is not going to do that. And that's something that forensic investigators recognize. And they aren't going to move blocks independently of the operating system. So any sort of optimization of the position of data on the platter, because this is a big spinning disk of metal with magnetic bits scattered all around, sometimes it's slow and inefficient to try to find that data. So on the hard drive, the operating system, a lot of times we'll try to realign the blocks to defragment the drive. That's something that the drive is not going to go out and do because it feels like it. So let's say drive, on the other hand, does things differently sometimes. The other thing that we know is that, you know, this hard drive, it's just a Seagate one. If I had a Western digital or a Hitachi or another brand, it would behave the same way. So if we're a forensics investigator, we get a laptop with a hard drive in it or a desktop with a hard drive in it, we can pretty much use the same universal truths when dealing with this data. Surprise, surprise though, solid state drives change all of these fundamental theories and beliefs that we have. So in order to talk and understand about solid state drives, I want to talk about how these drives are constructed and talk about flash memory. So flash memory is really the replacement and the equivalent of the magnetic platters in a hard drive. So I have an example SSD that doesn't have a cover here and over the sticker of course there are a bunch of chips that are flash chips. That's where the data is actually stored on a solid state drive. And basically these chips have a number of capacities. They have different amounts of data that can be stored on them and the drive is composed of different amounts of these chips in order to reach the capacity. So if you have a 32 gig chip and you need to have a 256 gig SSD, you'll have eight of those chips that are all together. And the way that those chips work together in an SSD is by using the controller. And the controller is basically the heart and the brain of the SSD that makes the flash memory actually receive data from the operating system and it makes the SSD look like a normal drive to the operating system because the operating system doesn't really care what it's writing to as long as it looks like a hard drive, a solid state drive or otherwise. So that gap between the controller here on the back of the drive and the flash memory that's often referred to as the flash translation layer or FTL. Obviously physically these drives look very, very different. Your hard drive has the splitting platters, it's more like a record player with metal and magnets instead of needle and scratching noises. On the solid state drive you have the controller on the flash chips, no moving parts, completely solid state as the name implies. In terms of flash memory itself, the architecture is divided into different types of flash chips and there are different types of technologies for this. There's technologies called single level cell, SLC and MLC, multi level cell. And they're actually even expanding to make this more in depth where you have a third level. Most of the ones that you see on the market right now, the least expensive ones are the MLC but as we go to the triple level costs are going down because the more data you can store in a flash chip. Now on SLC it's just a one or a zero. In the MLC you have varying levels of charge. So if it's a zero, zero it's a certain level of charge, if it's a zero one it's a different level of charge, if it's a one zero and one one different levels of charge. Obviously this is a little bit slower because you have to have a more precise level of charge as opposed to an odd and an off. So there's performance tradeoffs with this but the cost does go down because you're basically doubling or even tripling the amount of data you can store on the same amount of flash. And one thing that always gets me is that a blank cell is represented as all by ones. For whatever reason I think it would be zeros but in the case of flash memory and the engineers among here can tell me why but it's all ones. Just in case you have SSD trivia that comes up any day. In terms of how a flash structure is actually architected the page is the smallest unit of addressable flash in a flash memory cell. And pages they cannot be overridden on an individual block by block or byte by byte basis. The entire page has to be refreshed. So you can write data into a page that has free space but if you need to return that page to the pool of available pages that has to be done separately because there's risk that by doing that it's electrically complicated and time intensive in terms of computing time that you're basically running into a situation where you might modify or lose data and that's bad. So only entire blocks are erased at a time. And then when the data is erased or deleted the blocks containing these data is actually just marked as invalid. So the operating system is like hey we don't need this anymore or the drive is saying these blocks are no longer needed I'm going to mark that as invalid. And they cannot be reused until they're completely erased because of the risk of manipulating data. And it does take a lot of effort and time computationally speaking. So this is all fast in terms of human time but the slowest thing that an SSD can do is erase data at this point. And that's why this is done. So the speed of an SSD is really determined on having available blank memory that can be written to. And in order to do that the controller has to ensure that there's as much of a pool of free flash space at any given point in time. The other thing that we need to be aware of is flash ware. So unlike your traditional magnetic drives where you're dealing with just magnet on metal flash cells actually have a life cycle. And there's a limited number of times that can be, they can be written or over written. And the ware can be uneven across the drive depending on how that data is used. So you think about how an operating system works. There are things that are almost never going to change. Like your static operating system files for example. Are pretty much going to be written when the OS is installed. Maybe updated as part of a patch or something like that. But very very rarely are you going to see those files change. Whereas your log files for example might be something that are continuously being written to. Continuously changing and continuously being modified. And that's going to be a high level of ware on the disk. And if the drive didn't do anything to deal with that you might run into a case where that part of the flash that has your log directory is going to be constantly and constantly written and ware out sooner. Whereas your OS section is going to just be chilling there. Like what's up? I don't know what's going on here. So the way that the solid state drive controller handles that a lot of times is it's going to move data between those blocks in order to make sure that that ware is even. And that's the concept of ware leveling. So when we go back to the solid state drive controller that is really the heart and the soul and the brain and whatever other human analogy you want to come up with of an SSD. And from the perspective of the operating system that's what makes the SSD look just like a drive. And it doesn't have to worry about how to speak flash memory or anything like that. That's all hidden to the user. And in turn to the forensics investigator. And all of the managing reading writing flash cells is something that the OS doesn't worry about. And also all of the more advanced ware leveling features that are part of the SSD are going to be handled by that controller as well. So controllers are really an interesting aspect of the whole solid state drive composition because there are so many different types of manufacturers that create controllers and different controllers. And even individual firmware revisions inside of an SSD can really depend on how the drive behaves. There are cases where a solid state drive behaved very differently or had a flaw that was actually fixed because the vendor produced a new firmware patch and that modified how the drive behaved without having to make any changes. So it's almost like the Tesla of storage where they just push out a patch and all of a sudden your car drives backwards. So some controllers they include additional optimizations including deduplication where if you're writing the same thing to the flash memory it's only going to actually write it to flash once and reference it through the controller as these two files hit the same spot of flash. Now this isn't like traditional deduplication inside an operating system where it gives you more space. In terms of what you can actually see as the user it's the same size solid state drive. But in terms of the flash that's actually being consumed from the perspective of the controller it's a smaller amount of data. So this reduces flash wear more than anything. That's something that's pretty much transparent to the user in a lot of your SSDs. And then drives also do garbage collection proactively to recycle flash blocks. And this is really more of a performance thing than anything. And really that comes down to like the drive needs to know when the data isn't valid and when it can recycle the flash blocks. So how does it do that? Well think about computing time again compared to human time. Now in terms of when a drive is actually doing something reading or writing on a computational scale it's very very infrequent. So it might seem to us humans that computer is always doing something. But really it's like okay the person hits a key. Now I'm going to wait for a really really long time. They hit the next key. Okay I'm bored. So when the solid state drive is bored it does other things. So the idle time is really good for performing garbage collection type techniques. Optimizing the drive behavior, relocating flash cells to other sides of the drive to level layer or level level wear. Or to do garbage collection techniques to free up flash so that you have good performance. So as you can see these solid state drives are sentient. They are going to be taking over the world one computer at a time. So your laptop you better watch out. This SSD is plotting against you. So where we actually come down to how the drive actually knows what to do a lot of times though is the trim command. So this is an ATA command that's implemented through the SATA bus and it basically is the way for the operating system to tell the drive controller when data is deleted. So basically instead of the SSD trying to figure out when the data can be deleted and when that data is invalid the OS proactively notifies the controller and the controller is like okay I can just wipe these. And that really frequently accelerates the garbage collection process. And that's definitely something I'm going to demonstrate as part of this forensics demonstration. But really the thing to keep in mind here is in general your SSDs are going to behave more and more like your enterprise sand controller or a radaray than simply a simple dumb hard drive. So this is one of those things where an SSD is fundamentally different from your normal storage. And that definitely has forensics implications. And really the questions that I have when I started looking into SSD storage years ago was how do we determine if solid state drives impact the forensics process? And really what are those actual impacts? I had a lot of questions along the lines of like if we delete a file from an SSD people are saying that it might be different but what are those cases that cause that? And when can I say yes that data is going to be there or no it's not? How do we standardize that? How do we come up with the framework for understanding that? And really the question that is facing a lot of forensics investigators including the number of them that I've interviewed is they're treating SSDs like normal hard drives when they're doing investigations. And really if you're looking into this data as someone who's an investigator and not understanding the implications you have a high chance of not getting what you expect from one of these drives without knowing what you're looking for. And you could be wasting a lot of time while trying to do this. So there has been some previous research that has been done on solid state drives and the forensics implications. A lot of this research has looked at the fact of filling an entire SSD with the same string of text and trying to see when that part of the flash is manipulated. And fundamentally there have been a lot of studies that have shown yes there are some changes that happen. That is destroyed. But none of the research that I could find was really looking at this across a wide pool of solid state drives in a very painstaking here's a file I deleted what happens. Which in my mind that was the simplest brain dead question that I had for when I was trying to look at this research. So if I delete a file is it gone or no. Which really I think is a good question to really start out with. So my research represents really from what I could find one of the most comprehensive studies of the recoverability of deleted files from solid state drives to date. So I had a pool of SSDs that we're going to go through. And 11 different two-part tests that really built on each other to trigger subtle differences in SSDs to really understand when data is deleted, when it can be recovered and why. And really it's primarily focusing on deleted file recoverability because that's what at the basic a lot of the law enforcement forensics at the lowest possible level really ties into. So without understanding the basics we really can't go further. So the purpose of my research was really to comprehensively study the impact of solid state drives on the forensics data acquisition investigation processes and really look at it from and if I'm doing current forensics practices against these drives are they valid. And can they be used all the time? Can they be used none of the time or some of the time? What cases are they okay? And really to determine if the traditional forensics approaches are sufficient. All of my experiments for this research were designed to build on each other. So every possible change that I could do for this were intended to be the smallest possible difference. Really trying to minimize all my variables as much as possible. And really incrementally try to trigger certain differences that I've seen or read about as options for causing an SSD to behave in a certain way. And really every test was two parts. One was a deleted file test where I would have some type of file on an SSD that was deleted. And as we know on your normal hard drive deleting a file doesn't make it go away. So really a simple way for me to tell if a SSD is doing something is to put a file on a whole bunch of SSDs. Make sure it's written on that file or on that drive for sure. Delete it, image the drive, try to recover it, see what happens. And it's really simple but it is a very blatant way of demonstrating the difference. The next part for every test was a quick format test where I would quick format all of the drives and try the same recovery including file covering techniques because that's typically necessary when the file system is gone. And fundamentally that really demonstrated even further differences. So the other thing that I learned as part of this research is trying to image a whole bunch of SSDs for a bunch of tests is really really boring and annoying. So when you're dealing with hundreds of gigabytes of drive imaging over a USB 2.0 right blocker it's really slow. So all of these tests they were designed to isolate different variables. Some of the variables that I wanted to test were trim state. So this could be done in a number of different ways. Since trim is something that's an ATA command that is only passed over the SATA bus it's something that you can basically control the state of by having a SATA bus or not. So if you connect a drive via USB it's not going to pass the trim command just because that's basically going to block that from happening. Operating systems you can turn trim on and off. In Windows 7 for example there's a command line parameter for doing that. There's also operating systems that just natively don't support trim. Windows XP is great but it natively doesn't support a whole lot of other things like you know security. So obviously there are hopefully not too many people using that but it's something that you might see because there are plenty of agencies that are still using XP for different sorts of things unfortunately and makes all of the security people cry. There are other types of things that I was looking to isolate for this. The number of files present. So is a single text file for example going to behave differently than an image file because it's a larger type of file. So would we see the text file still be there and the image file gone or vice versa? Would having more than one image file in the drive make a difference? Or if I deleted a file every minute over the course of an hour would some of the files be there and some of them be gone or would they all be gone or would they all be there? All those different types of variables for what I was looking to try to isolate. So let's get to the drives that I was using for this testing. I ended up using seven different drives, six SSDs and one control drive and all these drives are really picked for specific reasons to try to understand different controller types or different manufacturers to understand how they behave. So my control drive was just the Seagate normal hard drive that you would find in a laptop. Since laptop drives or normal hard drives are going to behave pretty much the same way either way. Any control is pretty much as good as any other for that. Then in terms of the other SSDs, I had these handful of ones so I had a crucial SSD. This one has firmware that's written by Crucial on a Marvel chipset. So they handle all the software in house for this drive and it's not based on a third party controller. Likewise the same for Intel who also has their own controller. And both the Crucial and the Intel controllers are different. So I was looking to see if those would result in any different behavior. Then we had the OCZ and the Patriot which actually both have the same controller and they're just different manufacturers. So I wanted to see if having the same controller and the same firmware revision just with different manufacturers would result in different behavior. And a lot of times it turned out to be very much the same except the OCZ one died partially through the testing. So after it stopped working it didn't behave the same way. Then there was the Samsung which Samsung has their own controller which is actually a three core controller and I could find zero documentation with what any of those three cores would actually do. But it is their own firmware and their own implementation so it is different than Crucial and Intel and all that and it doesn't use a generic controller the Sandforce one that's in the OCZ and the Patriot. And then there's also this super talent one which was interesting because it's one of the first SSDs that I was able to locate and inside of this descript case that shows nothing is actually a 1.8 inch SSD with a parallel to SATA bridge chip. So this is like ancient SSD technology from like 2009. So in terms of ancient it's not really ancient by human standards but by technology standard it should be just probably really old. But this was interesting for me because of having a SATA to parallel ATA bridge chip that shouldn't allow any SATA commands like trim or anything to even get to the SSD controller. So I wanted to see how a modern SSD versus a really old SSD behaved and compare that to a normal hard drive. So all of these were selected for different factors and I really wanted to try to look at this from a picture of the SSD landscape. Obviously I couldn't go out and buy every single SSD that existed because I don't have millions of dollars laying around. But this should be a good picture of what we should expect to see. And these tests can be used across new SSDs and new manufacturers to understand. So if you run into something you've never seen before, I've never seen before, you can do similar tests and really get a basic understanding of what to expect. Now my forensics lab for this consisted of a dedication, evidence creation and evidence collection machine. I never ran an operating system or anything like that on the test SSDs because I wanted to eliminate the variables as much as possible. So the only data that was written or read from these SSDs were the files I was working with. It would definitely be interesting to look at this from an operating system perspective but tracking that in an efficient and sane way just was not something that I really felt for this type of research. Someone wants to roam with that by all means go ahead and look at that. It's definitely something that needs to be explored. And I also look to use open source. So the Cain Linux forensics distribution was my choice distribution for collecting and analyzing all the data. And all the evidence was collected using a forensics write blocker. Now there has been research that has shown that an SSD on a write blocker has been demonstrated to modify data in some cases. I wanted to look at this from the perspective of someone who was analyzing the drive without doing any chip by chip analysis or bypassing the controller. So I was looking at this as a traditional forensics investigator using the tools that would be accepted in court to in order to analyze data. So for one of our sample tests and I will just start with really what was one of the fundamental and most basic tests was the idea of writing a single image to a file. And by image I just mean picture. So I took a picture I wrote it to all of these disks. I mounted the disk and that's important because caching is something that can happen on an SSD where it would just be in read-only memory. And I wanted to make sure that the drive had that data truly committed to flash so that I would look at it in another machine it would still be there. So that I knew it was in the cache, the memory and written to flash. And then remount the drive I would delete it and then make sure that I would image the drive and see if it was recoverable. Now that seems simple and if you're knowing how forensics are working which is everyone here, delete a file off a drive you don't do anything special it should be there right? Yeah, I'm getting some nods that's good. Now across the tests that I did on SSDs it was not always recoverable. So that begs the question of why. So different variables and I'm going to get into this in the results but the drives did fundamentally behave very differently. So some of these drives would go ahead and almost purge the data instantly once it was deleted. And a lot of times that was a component of the trim state. A lot of times there were different factors but that was probably the biggest one. That would result in the data being basically completely recoverable or completely unrecoverable in that period of time. The second test for every test run was a quick format. So it would take the same drive same that I imaged I'd go ahead and quick format the drive, take an image of the drive after I unmounted it and try to do file recovery. And this was a lot of times done with file carving because the file system was gone at that point. Most of the time on I would say all the time on your normal hard drive that data is more or less recoverable. On your SSDs a lot of times it was completely gone. Obviously any SSD where it was gone in the test beforehand, the first test it didn't come back. Which is probably a good thing. That would be really weird. But for a lot of the drives where it was originally still there, the quick format would make that go away as well. So our understanding of data sanitization on an SSD level fundamentally does change as result of just you working with an SSD. But it's not always the case. So as I was doing these tests I started to notice some patterns. So all the files on the controlled drive were pretty much recoverable all the time. There was a very significant difference in SSD behavior and they started to see them break into two different groups where there were some that were resulting in a very low recoverability in a lot of cases. But there were also a number of SSDs that prehaved very very similar to the control hard drive. And the ones that had very low recoverability were pretty consistent across the board in those tests and the ones that had reasonably high recoverability in a lot of tests were pretty common as well. So without further ado I want to dig into the results of the research and scare you with some bar charts which aren't going to be too scary because I don't want to freak people out with numbers and stuff like that. I tried to break this down in a bunch of different ways to really illustrate the points. If there are questions about this we can definitely talk later after this presentation as well. But really this is just an overall scale of everything that I saw across the test. You'll see all the way in the left is the Seagate hard drive recoverability and I apparently don't know how to use this. But right here we see that the Seagate drive basically matches the Patriot SSDs behavior and the Super Talent SSDs exactly across all the tests. The thing you'll notice here is let me make that go away. The OCC SSD is very close to the Patriot one. This was the point where the Patriot failed. So it was behaving exactly identical and based on everything I had seen the same controller I would expect I guess I could make that yellow but I would expect that bar to be exactly the same how the drive continued working throughout the test. Just based on extrapolating the results that I was seeing. But we also look at these there's some drives here near the bottom the crucial your Intel and your Samsung that are a lot lower recoverable than your normal SSD or your normal hard drive. And that was definitely interesting. But really this graph by itself is kind of misleading just like every other graph. So I need to go into some more detail to really paint the picture of what was happening and to make this clear. So like I said the trim state was really the biggest factor impacting recoverability. So here on the left is my results of recovering data when trim was on. And then on the right is when trim was off. So you look at this from just obviously you have trim it's going to make your chances of recovering data a lot lower. Now these ones right here at the bottom your crucial and your Intel were a single text file on the drive saying this is a text file because I'm really creative. That single text file was not something that when it was deleted was enough to trigger garbage collection or a trim event where it actually overwrote that part of flash. Every other case for the crucial and the Intel it was an image file that was large enough that was something the drive controller saw significant enough to wipe that data proactively. So in pretty much any case with a large enough file on those type of SSDs with trim enabled that data is gone upon deletion immediately. The Samsung was pretty darn close and then if we just clear this out we look at the other ones are all pretty much near the top there. If we look at when trim was either turned off unavailable because the operating system or the bus that I was using for testing the drive it was pretty much a case where a lot more of a level of playing field where yes your Intel and your crucial here were pretty similar to what they were before at the bottom and even your OCC I guess that is kind of an anomaly because of how it was behaving it ended up would match just like the Patriot. But a lot of these drives with trim off behave a lot closer to a normal hard drive. So not quite the same there's still going to be cases where data goes away but it's definitely a case where you see lower recoverability significantly lower recoverability with trim turned on as opposed to off. This does combine quick format and not quick format so wanted to look at file deletion first and then we'll look at formatting. So this takes away all of the formatting test and just looks at I had a file and I deleted it regardless of trimming on or off or anything like that. So you will see across the board your crucially Intel and lesser degree your Samsung are lower recoverability your Seagate and your Patriot and your Super Talent basically act like normal hard drives. So we basically have two different classes of drives where something that behaves very close to a normal hard drive and something that behaves very different. But what really looks more blatant and more obvious is the quick format recoverability. And we know on a normal hard drive you can pretty much recover data if it's quick formatted on an SSD. If you have a Patriot you're good and your Super Talent you're good. But if you have one of the other drives you quick format the drive it's pretty much gone. And that's really a fundamental change for how we view forensics. So if you're dealing with a drive that's been quick formatted and it's one of these ones that offers very low recoverability your chance of getting evidence from that is going to be pretty low. So really general observations for here is that solid-state drives they can't be considered to behave the same or identically to traditional hard drives from a forensics perspective. Deleted file recoverability it does very significantly and it really depends on the type of the drive and the controller. And as we saw different factors you know if trim is on or off, how the drive is connected, what operating system, what types of files are being deleted, is there a quick format in play. Those really impact the likelihood of recovering data. So that kind of leads to my contributions for this research. I really think that this would be something that can be referenced when attempting to recover deleted files from an SSD and really to help understand what situations lead to successful recoverability. So if you're someone who needs to face the solid-state drive in a forensics investigation, this framework for some of the testing that I did can really be used to understand what you need to do to see before you spend a lot of time trying to recover data off of that drive if it's something that's worthwhile or not. And really the impact of trim has been something that's been published on a lot lesser scale. This is really the biggest demonstration that I could find of trim actually having an impact on forensics recoverability across a large range of drives whether or not it's turned on or off. So really to look at the conclusions that I have for this, as a forensics investigator you really need to be acutely aware of the drive differences. You need to understand yes first and foremost you're dealing with an SSD. You need to understand that the drives are going to behave differently and how to recover data from them. And that SSDs do negatively impact the recoverability. And then we also have to look at modifying our forensics practices to recognize these drives and understand what they can be done. Well what can be done with them in order to get data back. Or if there's any way that we have to look at this at a more deeper level. If we look at the flash bypassing the controller is that something that might be forensically practical. It's one of the things that I think is a great opportunity for some future work. So definitely when we're looking at the future work here bypassing the flash controller is something that is definitely interesting and way beyond my technical capabilities to understand how that electron stuff works. So some of you I know are smart enough to do that. Definitely something to look at. Looking at how an operating system makes a difference. If the operating system is running, looking at it more forensics data that could definitely be something that is an opportunity to look at as well. So I'd like to acknowledge a couple of people who helped make this presentation possible. Three professors at RIT dealt with me for way too long for getting this research done. It took years. I'd like to thank them, Dr. Pan, Dr. Mishra and Professor Stackpole and then Bill Matthews at Hurricane Labs for supporting me through this research. With that I'd like to open the floor for any questions and I will leave my contact info up here if anyone wants to stop by. Thank you very much. Yes, over there. Okay, so the question was, is there a way to tell when you get the computer whether the trim state is on or off? So that is something that's configured in the operating system. So you would have to look at the operating system first in order to do that. Which of course has forensics implications as well. So one of the ways that I would suggest maybe doing this is to image the drive first and then you can actually use the image copy as a way to interrogate what's going on. That way if you modify it you're not causing any problems with the original evidence. Is it in like registry? It is something that you can run just to command like on a window system. There's just either a power shell or a command line it'll just print the value of that whether it's on or off. I believe it's stored in the registry as well and you make that change. The next. I was wondering do you have any indication of how other buses like M2 or PCI express or SAS would respond? Yes so M2 and PCIE for SATA type drives basically function the same way. So it is passing a SATA type bus like an M SATA desk. It looks like a PCIe slot but it is SATA. So that would behave the same way as what I was seeing. M2 is the same idea where it's a SATA bus. Now on SAS a lot of times that's going to be behind a raid controller and the raid controller often does not pass the trim through although some of the newer raid controllers will actually do that. So that would be a little bit of a different behavior. Now there was one other bus you mentioned. SAS PCIe. So we covered everything. One more quick question. Yes sure. What about enterprise grade drives that have over capacity? So every SSD in some way has some kind of over capacity. So you look at your 120 gig SSD typically has 128 gigs of flash. The enterprise ones could be a 100 gig disk that has 128 gigs of flash. So the behavior should be very similar because the over provisioned flash is still going to be there. And one of the tests that I did actually simulated over provisioning the flash by partitioning the drive a lot smaller. Which is the same fundamental idea. And basically I observed the same behavior that I expected. Thank you. Yeah you're welcome. We have another line over here. Yeah sure. So you mentioned bypassing the FTL. Some studies have already been done on that by UC San Diego. And the results were published in I believe 2011. I actually looked into some of that research. And I know exactly what paper you're talking about. Yeah yeah using the custom FPGA controller to bypass the behavior of the FTL. So yeah just wanted to make sure that everybody else was aware of that as well. Yeah that research is definitely interesting. And I think there's a lot of that was looking at the contents of the flash cell itself. And trying to assemble that would be really interesting. Like how do we pull actual files off of that? Because definitely if you're looking for a string of text that's a great way to find that data. If you're looking for images or larger files trying to piece all that together. Definitely something that is more work can be done on. Yeah. No I get one more question. Okay so you guys we can talk afterwards but I will take one from this way. Hey boss how's it going today? So I actually work for a storage manufacturing company. I was wondering if you've given any consideration or if you can talk to the impact of bit rot on SSDs for forensic investigations especially since bit rot on SSDs will occur so much faster than on a powered off hard drive. Yeah so in terms of bit rot in terms of bit rot what he's referring to is the fact that the flash actually degrades over time. So a normal hard drive there's some magnetic decomposition as time goes on on a flash shell it's quicker just to make sure. Yeah no exactly right. Yeah so that sort of thing from a forensics case a lot of that is going to be not necessarily identified through the controller because the controller it's going to either see that and it's going to be there or it's not. Now the controller might proactively move that to somewhere else or refresh the contents of flash to basically re-energize the cells but from a forensics perspective I don't know if that's going to be something that's necessarily going to be available through the controller. Well the concern is is that in the past we've actually been approached by some people who are trying to forensically analyze some of the SSDs and some of our products and the problem is is that you achieve a warrant or similar you take this equipment out of its source location as soon as you power it down the controllers no longer have the ability to scrub the SSDs so if that stuff is sitting in a forensics lab before you know two, three, four months before it's analyzed by time you get to analyzing it three, four months some SSDs will already start to lose data. So one of the things that I noticed as part of this research is pretty much all of the cleaning of the data happened almost instantly so in terms of deleting data I think it's going to be pretty much gone regardless now in terms of actual stored data on there I didn't see any cases where if I left these drives sit for months on end that the data would be gone or anything like that now I guess it's possible where that bit rock could happen in a period of time just not something that I saw as part of this research. Thank you very much. I will be outside and for any other questions that you guys might have thank you very much you've been a great audience I really appreciate