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 am 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 researcher at heart and I'm going to start with the
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.
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 we call Tom joke.
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.
Okay.
So 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 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 done.
It's 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 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, 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 flatters.
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 is 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 is slow
and inefficient to try to find that data.
So on the hard drive, the operating system a lot of times will try to realign the blocks
to defragment the drive.
That is something that the drive is not going to do.
It 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 this hard drive, just a Seagate 1, 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 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, 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 spinning platters.
It's more like a record player with metal and magnets instead of needle and scratchy noises.
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,
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 you have, the more you have.
There's a lot 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-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 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 trade-offs 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 1s.
For whatever reason, I think it would be 0s,
but in the case of flash memory, and the engineers among here can tell me why,
but it's all 1s.
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 overwritten on an individual block-by-block or bite-by-bite 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 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 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 wear.
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 they can be written or overwritten.
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.
There are things that are almost always
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 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 going to be constantly and constantly written
and wear 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 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 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 wear leveling features
that are part of the SSD
are going to be handled by that controller.
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 is invalid
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 the 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 SSD 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 wear
or to do garbage collection techniques
to free up flash so that you have good performance.
So as you can see these SSDs 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 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 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 a framework for understanding that?
And really the question that is facing a lot of forensics investigators
including a 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.
Data 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 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?
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 an SSD is doing 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.
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 write 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
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 security.
So obviously there are hopefully
not too many people using that.
You might see because there are
plenty of agencies that are still using
XP for different sorts of things.
Unfortunately and makes all 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 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? All those different
types of variables are 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 any 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 have these
handful 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.
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 Sanforce
one that's in the OCZ and
the Patriot. And then there
was 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 standards 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 want
to see how a modern
SSD versus a really old SSD
behaves and compare that to a normal
hard drive. So all 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 run with that, by all means
go ahead and look at that. It's definitely something
that needs to be explored.
I also looked to use open source
so the Kane Linux forensics distribution
was my choice
distribution for collecting and analyzing
all the data.
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
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 desks, I mounted the desk
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
and it would still be there.
So that I knew it was in the cache, in 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
you 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
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 a 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 control drive were pretty much recoverable
all the time.
There was a very significant
difference in SSD behavior
and I 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 behaved very very similar
to the control hard drive.
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
where you see the Seagate drive
basically matches
the Patriot SSD's behavior
and the SuperTalent SSD's
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
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
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 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.
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
as significant enough to wipe that data
proactively. So
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 playing field
where
yes your Intel and your Crucial
here were pretty similar
to what they were before
at the bottom and even your OCZ
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
non-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 trim being on or off
or anything like that.
You will see across
the board your Crucial
and the Intel in lesser degrees
your Samsung are lower recoverability
your Seagate and your Patriot
and your SuperTalent 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 quick formatted
on an SSD if you have a
Patriot you're good
on your SuperTalent 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
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
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 a 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
or 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 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.
Is there a way to tell whether
when you get the computer off
whether or not the trim state is on
or off?
Ok 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 is 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 a command like on a Windows
system. There's just a
either a PowerShell 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. 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 MSATA disk. It looks like a PCIe
slot but it is SATA. So that would be
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.
Yeah 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 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 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.
Yes I actually looked into some
of that research and I know
exactly what paper you're talking about. 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.
No 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?
Cause
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.
One more question.
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 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 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 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
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
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 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 rot
could happen in a period of time
it's just 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.