Sentient Storage: Do SSDs Have a Mind of Their Own?
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 93 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/36296 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
DEF CON 2416 / 93
4
6
7
11
15
20
26
33
34
35
36
39
40
46
49
53
58
62
63
66
68
72
79
90
92
93
00:00
Data storage devicePresentation of a groupMereologyRoundness (object)BitInheritance (object-oriented programming)Type theoryNormal (geometry)Hard disk driveOnline chatRight anglePhysical systemState of matterSolid geometryOcean currentCASE <Informatik>Data managementDifferent (Kate Ryan album)InternetworkingInformationContext awarenessLecture/Conference
02:47
NP-hardBit rateWeb pageHard disk driveComputer fileProcess (computing)CASE <Informatik>
03:40
Graphical user interfacePure Data <Programmiersprache>Large eddy simulationOrder (biology)File formatBlock (periodic table)Hard disk driveBranch (computer science)Roundness (object)Quicksort
04:47
Revision controlDigitizingMathematical optimizationPosition operatorLaptopQuicksortBitBlock (periodic table)Multiplication signOperating systemHard disk driveMiniDiscSolid geometryPhysical systemState of matterLecture/Conference
05:38
Solid geometryState of matterMathematicsFlash memoryTranslation (relic)Channel capacityOrder (biology)Equivalence relationTheory of everythingFlash memorySolid geometryState of matterHard disk driveChannel capacityNumberGame controllerTranslation (relic)Different (Kate Ryan album)Operating systemCovering spaceNP-hardOperator (mathematics)
07:12
Type theoryLarge eddy simulationCellular automatonArchitectureFlash memoryLevel (video gaming)MultiplicationType theoryCASE <Informatik>Cellular automatonFlash memoryHard disk driveSolid geometryGame controllerRight angle1 (number)Level (video gaming)Different (Kate Ryan album)Term (mathematics)BitData structureState of matterComputer architectureNoise (electronics)Single-precision floating-point formatMereology
08:56
Flash memoryArchitectureWeb pageSpeicherzelleBlock (periodic table)Execution unitBlock (periodic table)Web pageAddress spaceInsertion lossMultiplication signFlash memoryNeuroinformatikCellular automatonTerm (mathematics)Data structureBasis <Mathematik>Entire function
09:40
Block (periodic table)Read-only memoryTerm (mathematics)Flash memoryBlock (periodic table)Order (biology)Flash memorySemiconductor memoryFreewareMultiplication signOperating systemGame controllerSpacetimePoint (geometry)Term (mathematics)
10:32
InfinityComputer fileGame controllerLarge eddy simulationMereologyDirectory serviceBlock (periodic table)MathematicsCellular automatonGame controllerSheaf (mathematics)Video gameMultiplication signFlash memoryCASE <Informatik>Level (video gaming)NumberData loggerFluid staticsOperating systemCycle (graph theory)Order (biology)Patch (Unix)Limit (category theory)Computer fileState of matterSolid geometryMiniDiscLogin
11:53
Capability Maturity ModelGame controllerRevision controlBlock (periodic table)Flash memoryIdeal (ethics)Operations researchMultiplication signMathematicsType theoryPatch (Unix)Data managementCellular automatonReading (process)Computer fileFlash memoryData storage deviceState of matterNeuroinformatikGame controllerKey (cryptography)Term (mathematics)Revision controlSpeech synthesisScaling (geometry)SpeicherbereinigungCASE <Informatik>Solid geometryOperating systemProcess (computing)AnalogyPerspective (visual)MereologyLevel (video gaming)Different (Kate Ryan album)FirmwareBus (computing)Mathematical optimizationLaptopSpacetimeBlock (periodic table)Web 2.0Operator (mathematics)
15:43
Type theoryMereologyComputer fileSerializabilityMedical imagingVariable (mathematics)Different (Kate Ryan album)Normal (geometry)1 (number)Observational studyLaptopSoftware testingTerm (mathematics)Game controllerMathematicsLevel (video gaming)State of matterData recoveryString (computer science)Process (computing)Ocean currentMultiplication signCASE <Informatik>Computer configurationSolid geometryBlock (periodic table)Enterprise architectureSoftware frameworkNumberQuicksortSingle-precision floating-point formatHard disk driveFile formatOperating systemFlash memoryWindowData acquisitionWritingSinc functionBus (computing)RAIDThermodynamisches SystemData storage deviceInformation securityFile system
22:53
Physical systemSoftware testingGame theoryOpen sourceVariable (mathematics)MiniDiscComputer-generated imageryData recoverySample (statistics)MereologyFile formatControl flowSoftware testingComputer fileRight angleTask (computing)Type theoryArithmetic meanCache (computing)File formatVirtual machineHard disk driveFile systemData recovery1 (number)WhiteboardMedical imagingPerspective (visual)TrailGame controllerSerializabilityCore dumpRead-only memoryOperating systemCASE <Informatik>Mathematical analysisOrder (biology)Multiplication signFirmwareConnectivity (graph theory)ResultantSoftwareDistribution (mathematics)Axiom of choiceDifferent (Kate Ryan album)Level (video gaming)Open sourceFlash memoryPoint (geometry)Semiconductor memoryParallel portTerm (mathematics)Bridging (networking)ImplementationRevision controlDivisorFrequencySampling (statistics)State of matterGroup actionNumberVariable (mathematics)Standard deviationPattern languageInheritance (object-oriented programming)MiniDisc
30:03
Control flowSerializabilityFirmwareComputer fileGame controllerState of matterData recoveryResultantNumberDifferent (Kate Ryan album)Point (geometry)Hard disk drivePresentation of a groupScaling (geometry)SerializabilityGraph (mathematics)Game controllerSoftware testingGreatest elementState of matterInheritance (object-oriented programming)DivisorDiagram
31:48
SerializabilityState of matterInformationMedical imagingCASE <Informatik>Flash memoryMereologyGreatest elementComputer fileOperating systemHard disk driveSpeicherbereinigungFile formatSerializabilityLevel (video gaming)Single-precision floating-point formatEvent horizonField (computer science)Term (mathematics)1 (number)Boss CorporationState of matterGame controllerType theoryDivisorResultantRight angleCombinational logicBus (computing)Diagram
33:56
Computer fileSerializabilityHard disk driveSoftware testingFile formatWhiteboardInheritance (object-oriented programming)Different (Kate Ryan album)Degree (graph theory)Social classComputer fileSerializabilityNormal (geometry)
34:36
SerializabilityFile formatFile formatHard disk driveSerializabilityMathematics1 (number)Data recoveryGoodness of fitInheritance (object-oriented programming)State observer
35:09
Solid geometrySerializabilityGauge theoryData recoverySimilarity (geometry)Endliche ModelltheorieSoftware testingNegative numberMathematicsState observerHard disk driveState of matterSolid geometryType theoryLevel (video gaming)DivisorLikelihood functionSerializabilityComputer fileSoftware frameworkSoftware testingMultiplication signRange (statistics)Game controllerOrder (biology)Different (Kate Ryan album)Flash memoryScaling (geometry)Perspective (visual)Operating systemFile formatJSON
37:16
Operating systemData storage deviceDifferent (Kate Ryan album)Game controllerFlash memoryPresentation of a group
38:07
InformationGame controllerMultiplication signRAIDCellular automatonBitBus (computing)Type theoryMedical imagingFrequencyChannel capacityProduct (business)Source codeUniform resource locatorFlash memoryPower (physics)CASE <Informatik>Computer fileData storage deviceQuicksortContent (media)Bit ratePerspective (visual)PCI ExpressObservational studyHelmholtz decompositionRight angleSoftware testingMiniDiscHard disk driveOperating systemTerm (mathematics)MereologyDependent and independent variablesString (computer science)Boss CorporationPrice indexEnterprise architecture1 (number)Hidden Markov modelLine (geometry)Physical systemStorage area networkResultantGastropod shellState of matterNeuroinformatikOrder (biology)WindowWindows RegistryGradientProcess capability indexCausalityLecture/Conference
Transcript: English(auto-generated)
00:00
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.
00:25
I'm Tom Kupchak, and I am the director of whatever at Hurricane Labs, where I'm pretty much responsible for taking the customer's 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.
00:45
And this solid-state drive forensics 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.
01:04
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
01:20
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. Uh, that's what the hashtag TomJoke is for. Internally in our chat system at Hurricane,
01:43
we have something that you type in bang TomJoke 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 that hashtag TomJoke and, uh, we'll make it a thing. It's the dad jokes of IT.
02:03
So, without further ado, why we are here. Uh, 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 forensics investigator and you got one of these,
02:22
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, bearing solid
02:41
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 all on the same page. This should be review for a lot of you in the audience and definitely something that we all pretty much
03:01
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
03:20
really has become a cornerstone of a lot of the basic forensics practices. Someone has something they shouldn't on a 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. Well, it's not good, but you know how that works. Now,
03:40
if you were to be like, I want to delete this data and you quick format that hard drive, the data's still there. Uh, 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. Uh, I have not been able to locate any published documentation that says on a
04:01
modern hard drive, you can recover data that has been truly overridden once. That isn't saying that is not impossible. It is 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
04:21
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
04:43
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
05:04
the hard drive, the operating system a lot of times will 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. Solid state 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
05:22
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
05:42
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
06:01
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 this 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 chapp- chips have a number of capacities. They have different
06:22
amounts of data that can be stored on them, and they're, 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 8 of those chips that are all together. And the way that those chips work together in an SSD is by using the
06:43
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, solid state drive or
07:02
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. Uh your hard drive has the splinting pla- spinning platters, it's more like a record player with uh metal and
07:21
magnets instead of needle and scratchy noises. Um on the solid state drive, you have the controller and 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
07:41
of flash chips, and there are different types of technologies for this. There's triple cell. And they're actually even expanding to make this more in depth where you have a third level. Um most of the ones that you see on the market right now, more ex- least
08:01
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 1 or a 0, in the MLC you have varying levels of charge. So if it's a 0 it's a 0 0 it's a certain level of charge, if it's a 0 1 it's a different level of charge, if it's a 1 0 and a 1 1 different
08:23
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 on and 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
08:43
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. Um, just in case you have SSD trivia that comes up any day. Um, in terms of how a flash structure is actually
09:01
architected, uh, 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 basis. The entire page has to be refreshed. Um, 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
09:25
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. Uh, so only entire blocks are erased at a time. And then when the data is erased or deleted, uh, the
09:44
blocks containing these data is actually just marked as invalid. So that, 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
10:05
does take a lot of effort and time, computationally speaking. Uh, 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. Uh, and in order to do that, the
10:25
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 wear. So unlike your traditional magnetic drives where you're dealing with just magnet on metal,
10:46
flash cells actually have a life cycle. And there's a limited number of times that can be, they can be written or overridden. And the wear can be uneven across the drive depending on how that data is used. So you think about how an operating system works.
11:01
There are things that are almost never gonna change. Like your static operating system files, for example, are pretty much gonna be written when the OS is installed, maybe updated as part of a patch or something like that. But very very rarely are you gonna see those files change. Whereas your log files, for example, might be something that are continuously being written to, continuously changing and continuously being
11:23
modified. And that's gonna be a high level of wear 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 gonna be constantly and constantly written and wear out sooner. Whereas your OS section is gonna just be chilling there like, what's up? I
11:42
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 wear is even. And that's the concept of wear 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 wanna
12:02
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. Uh and all of the managing, reading, writing flash cells is
12:23
something that the OS doesn't worry about. And also all of the more advanced wear 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
12:43
controllers and different controllers. And even individual firmware revisions inside of an SSD can really depend on how the drive behaves. Uh 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
13:02
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 uh deduplication where if you're writing the same thing to the flash memory, it's only gonna actually write it to flash once and
13:23
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
13:41
perspective of the controller, it's a smaller amount of data. So this reduces flash wear more than anything. Um that's something that's pretty much transparent to the user and a lot of your SSDs. And then drives also do garbage collection proactively uh to recycle flash blocks and this is really more of a performance thing than anything. Um and
14:00
really that comes down to like the drive needs to know when the data is invalid and when it can recycle the flash blocks. Uh 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, at a computational scale it's very very infrequent. So it
14:20
might seem to us humans that computers always doing something. But really it's like okay the person hits a key, now I'm gonna 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
14:44
drive to have a layer or level level wear. Uh 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
15:01
time. So uh your laptop you better watch out. This SSD is plotting against you. So um where we actually come down to how the drive actually knows what to do a lot of times though is the trim command. Uh 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
15:22
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. Uh and that really frequently accelerates the garbage collection process and that's definitely something I'm gonna demonstrate as part of this forensics demonstration. But really the
15:43
thing to keep in mind here is in general your SSDs are going to behave more and more like your enterprise SAN controller or RAID array 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
16:04
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? Uh I had a lot of questions along the lines of like if we delete a file from an SSD, uh people are saying that it might be different but what are those cases
16:25
that cause that? Uh and when can I say yes that data is gonna be there or no it's not? Uh how do we standardize that? How do we come up with a 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
16:41
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, uh 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
17:04
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
17:22
destroyed. Uh 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 delete it, 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?
17:42
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 uh we're gonna go through and eleven different two part tests that really built
18:05
on each other to trigger subtle differences in SSDs to really understand when data is deleted, when it can be recovered, and why. Uh and really it's primarily focusing on deleted file recoverability because that's what at the basic a lot of the law enforcement
18:22
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 and investigation processes and really look at it from and if I'm doing
18:42
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. Um all of my experiments for this research were designed to build on- build on
19:03
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
19:24
test uh was two parts. One was a deleted file test where I would have some type of file on an SSD that was deleted. Um 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
19:42
something is to put a file on a whole bunch of SSDs, make sure it's written on that drive for sure, delete it, image the drive, try to recover it, see what happens. And it's really simple uh 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
20:04
drives and try the same recovery including file covering techniques because that's typically necessary when the file system's gone. Uh and fundamentally that really demonstrated even further differences. Uh 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
20:22
boring and annoying. So when you're dealing with hundreds of gigabytes of drive imaging over a USB 2.0 write blocker it's really slow. So um so all of these tests they were designed to isolate different variables. Uh some of the variables that I wanted to test were trim state. So this could be done in a number of different ways. Uh since trim is
20:47
something that's an ATA command that is only passed over the SATA bus uh 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 gonna pass the trim command just because that's
21:00
basically gonna block that from happening. Operating systems you can turn trim on and off. Uh 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. Uh 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
21:24
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. Um there are other types of things that I was looking to isolate for this. Uh the number of files present. So is a single text file for example gonna behave differently than an image file because it's
21:42
a larger type of file. So would we see the text file still be there and the image file gone or vice versa? Uh would having more than one image file on 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? Uh all those different types of variables are what I was looking to try to
22:04
isolate. So let's get to the drives that I was using for this testing. I ended up using seven different drives uh six SSDs and one control drive and all these drives are really picked for specific reasons to try to understand uh different controller types or
22:21
different manufacturers to understand how they behave. Uh 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 gonna behave pretty much the same way either way. This any control is pretty much as good as any other for that. Uh then in terms of the other SSDs, I have
22:43
these uh handful of ones. So I had a Crucial SSD. Uh this one has firmware that's written by Crucial on a Marvel chipset. Uh so they under- they handle all the software in house for this drive and it's not based on a third party controller. Uh likewise the
23:02
same for Intel who also has their own controller. Uh and both the Crucial and Intel controllers are different so I was looking to see if those would result in any different behavior. Uh then we had the OCZ and the Patriot which actually both have the same
23:20
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 pet testing. So after it stopped working it didn't behave the same way. Uh then there was the Samsung which Samsung has their own
23:46
controller which is actually a 3 core uh controller and I could find zero documentation with what any of those 3 cores would actually do. But it is their own firmware and their own implementation so it is different than Crucial and Intel and all
24:02
that and it doesn't use a generic controller, the Sanforce 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. Uh and inside of this Descript case that uh shows nothing is actually a 1.8 inch SSD with a parallel to SATA
24:25
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. Um but this was interesting for me because of having a
24:45
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 you know a modern SSD versus a really old SSD behaves and compare that to a normal hard drive. So all of these
25:01
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
25:24
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. Uh I never ran an operating system or anything like that on the test SSDs because I wanted to eliminate the
25:45
variables as much as possible. So the only data that was written or read from these SSDs were the files I was working with. Uh 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
26:02
to run with that, by all means go ahead and look at that. It's definitely something that needs to be explored. Uh and I also looked to use open source. So the Kane Linux forensics distribution uh 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
26:24
been demonstrated to modify data in some cases. Uh 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
26:42
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. Uh so I took a picture, I wrote it to all of these
27:02
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. Uh so that I knew it was in the cache, in the memory and written to flash. Um and then remount the drive, I would delete it and then
27:24
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, you delete a file off a drive, you don't do anything special, it should be there, right?
27:41
Yeah, I'm getting some nods, that's good. Now, across the tests that I did on SSDs, it was not always recoverable. Um so that begs the question of why. So different variables, and I'm gonna 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
28:03
instantly once it was deleted. And a lot of times that was a component of the trim state, a lot of times um there were different factors, but that was probably the biggest one. Um that would result in the data being basically completely recover- uh completely unrecoverable in that period of time. Um the second test for every test run was a
28:25
quick format. Uh 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 file recovery. And this was a lot of times done with file carving because the op- or the
28:40
file system was gone at that point. Uh most of the time on, I'd say all the time on your normal hard drive, that data is more or less recoverable. Uh 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. Uh which is probably a good thing,
29:01
that would be really weird. Um 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 a result of just you working with an SSD. Uh but it's not always the case. So as I was doing these tests, I
29:24
started to notice some patterns. So all the files on the control drive were pretty much recoverable all the time. Uh 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
29:45
number of SSDs that behaved 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. Uh so without further ado I want to dig into the results of the research and
30:07
scare you with some bar charts which uh aren't going to be too scary because uh 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. Uh if there are questions about
30:20
this we can definitely talk later after this presentation as well. Uh 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 where you see the the Seagate drive basically matches the
30:44
Patriot SSDs behavior and the Super Talon SSDs exactly across all the tests. The thing you'll notice here is let me make that go away. The OCZ SSD it's very close here to the Patriot one. Uh this was the point where the Patriot failed. So it was behaving
31:05
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 had 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
31:27
bottom in 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
31:44
need to go into some more detail to really paint the picture of what was happening and 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
32:06
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. Uh
32:21
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 as significant enough to wipe that data proactively. So you know pretty much any case with a large enough file on those
32:45
type of SSDs with trim enabled that data is gone upon deletion immediately. Um 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
33:06
unavailable because the operating system or the bus that I was using for testing the drive. Um it was pretty much a case where a lot more of a level playing field where yes your your Intel and your Crucial here were pretty similar to what they were before at
33:24
the bottom and even your OCZ I guess that is kind of an anomaly because of how it was behaving. It shh ended up would match just like the Patriot. Uh but a lot of these drives with trim off behave a lot closer to a normal hard drive. So not quite the same
33:41
there's still gonna be cases where data goes away. Uh but it's definitely a case where you see lower recoverability significantly lower recoverability with trim turned on as opposed to off. Um this does combine quick format and non quick format so uh wanted to look at file deletion first and then we'll look at formatting. So this takes away
34:05
all of the formatting tests and just looks at I had a file and I deleted it regardless of trim being on or off or anything like that. So you will see across the board your Crucial and the Intel and lesser degree your Samsung are lower recoverability. Your
34:22
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. Now we know on a normal hard drive you can pretty much recover data if it's
34:42
quick formatted. Uh on an SSD uh if you have a Patriot you're good. Uh 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. Uh so if you're dealing with a drive that's been quick formatted and it's
35:03
one of these ones that offers very low recoverability your chance of getting evidence from that is gonna be pretty low. So really general observations for here is that uh solid state drives they can't be considered to behave the same or identically to traditional hard drives from a forensics perspective. Um deleted file
35:23
recoverability it does vary 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, uh what types of files are being deleted, is there a quick format in play. Those really impact the likelihood of recovering data. So
35:44
that kind of leads to my contributions for this research. I really think that this would be something that can be referenced uh when attempting to recover deleted files from an SSD and really to help understand uh what situations lead to successful recover, recoverability. So if you're someone who needs to face a solid state drive in a
36:03
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. Um and really the impact of trim it's been something that's been published on a lot lesser
36:21
scale. Uh this is really the biggest demonstration that I could find of trim actually having an impact on forensics recoverability. Uh 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. Um as a forensics investigator you really need to be
36:42
acutely aware of the drive differences. You need to understand yes first and foremost you're dealing with an SSD. Uh 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
37:04
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. Uh 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. Uh so definitely when we're looking at the
37:22
future work here uh 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. Uh 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
37:43
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. Uh three professors at RIT uh 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
38:02
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
38:33
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. Uh so you would have to look at the
38:46
computer. The computer of course has forensics implications as well. Uh 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. Uh that way if
39:00
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 a command uh like on a Windows system. Uh there's just uh 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. Next. Um I was wondering uh do you have any indication of how other
39:29
buses like M2 or PCI express or SAS would respond? Yes so M2 and PCI-E for SATA type drives uh basically function the same way. So it's it is passing a SATA type bus like an
39:46
MSATA disk. It looks like a PCI-E 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 gonna be behind a RAID controller and the RAID controller often does not pass the
40:01
trim through although some of the newer RAID controllers will actually do that. Uh so that would be a little bit of a different behavior. Now there was one other bus you mentioned. SAS uh PCI-E. Okay so we covered everything. Um one more quick question. Yeah sure. What what about enterprise grade drives that have over capacity? So every
40:21
SSD in some way has some kind of over capacity. So you look at your 120 gig SSD typically has 128 gigs of flash. Uh the enterprise ones could be you know 100 gig disk that has 128 gigs of flash. So the behavior should be very similar because the over provisioned flash is still gonna be there. Alright and one of the tests that I did
40:43
actually simulated over provisioning the flash by partitioning the drive a lot smaller. Which is the same fundamental idea. And uh basically I observed the same behavior that I expected. Thank you. Yeah you're welcome. We have uh another line over here. Yeah sure. Um so you mentioned uh bypassing the uh the FTL. Um some studies have already
41:04
been done on that by UC San Diego. And the results were published in I believe 2011. Um so. Yeah so I actually looked into some of that research. And I I know exactly what paper you're talking about. Yeah. Yeah using the the custom FPGA controller to bypass the the behavior of the FTL. Um so yeah just wanted to make sure that everybody else was
41:25
aware of that as well. No yeah that research is definitely interesting and I think there's you that a lot of that was looking at the contents of the flash shell itself. And trying to assemble that would be really interesting. Like how do we pull actual files off of that. Cause uh definitely if you're looking for a string of text that's a great way
41:44
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. Yeah. No I I get one more question. Okay so you guys we can talk afterwards but uh I will take one from this
42:04
way. Hey boss how's it going today? Uh so I actually work for a storage manufacturing company and I was wondering if you've given any consideration or if you can talk to the impact of bit rot on SSDs uh 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
42:22
bit rot 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 cell 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 gonna
42:43
be not necessarily identified through the controller because the controller it's gonna either see that and it's gonna be there or it's not. Now the controller might proactively move that to somewhere else or refresh the contents of flash to basically reenergize the cells. But from a forensics perspective I don't know if that's
43:01
gonna be something that's necessarily gonna be available through the controller. Well the concern is is that uh in the past we've actually been approached by some people who are trying to forensically analyze some of the SSDs in some of our products and the problem is is that you uh 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
43:21
to scrub the SSDs so you if that stuff is sitting in a forensics lab before you know 2, 3, 4 months before it's analyzed by the time you get to analyzing it 3, 4 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 the cleaning of the data happened almost instantly. So in
43:43
terms of deleting data I think it's gonna be pretty much gone regardless. Now in terms of actual stored data on there uh I didn't see any cases where I if I left these drives sit for you know months on end that the data would be gone or anything like that. Uh now I guess it's possible where that bit rot could happen in a period of time. It's just
44:04
not something that I saw as part of this research. Thank you very much. I will be outside for any other questions that you guys might have. Thank you very much. You've been a great audience. I really appreciate it.