thank you and we're going all right
excellent hi so I forgot the microphone
right let's try the game I'm Alex ass'n
I'm assistant professor at DePaul
University so me and several people from
my research lab are very excited to be
here thank you for having us and I want
to talk about forensic applications and
database carving for that purpose so the
lab has a lot of people and I don't have
some of the pictures but this is the
group who pretty much leaves the effort
and it's mostly Depot lab except
Jonathan Greer who's had the principle
of Greer forensics and he provides us
with some real-world motivation his
expertise is in data theft and and
similar work so why have we bothered
doing this so obviously forensics is
interesting but specifically we were
motivated by data access data theft data
tampering eventually and every day you
pretty much see something in the news
someone stole a bunch of accounts a
bunch of data and even more interesting
is that oftentimes it takes forever
until someone notices and even if you
notice the data data may have been
stolen you still have no good way of
proving it necessarily and this is one
of very important aspects it's not just
about detecting data theft it's also
often being able to verify somehow
especially if you're dealing with
internal hacking and there's also a lot
of interest from perspective of doing
mobile device analysis because it turns
out that every time you need to store
something on the mobile device you bring
much you sequel light which is a
lightweight relational database and it's
easier to do that than to invent the
wheel and so you may not think about
this but databases are in fact
everywhere so every phone android
iPhones browser bookmarks would often
live in civilized database and of this
Danny
website and you anything that has a
front end on the back end some runs back
and there's a database awesome
relational sometimes something else and
primarily focuses on the relational
databases but we plan to expand and so
the goals kind of bros they are to get
back things that are deleted because
once you delete something from database
perspective it stops existing but
there's obviously a lot of forensic
value and a lot of interest in seeing
things that were were in the system
before but were deleted to see who's
doing was on the system to detect was
being changed to detect those operations
are happening or what the prescient
almost happened and a lot of it you can
see we're also looking into data
tampering especially from the inside so
we have a paper that's that was just
accept it too dear for WS and there will
look at what happens if the tampering is
happening from the inside so it's very
easy for database administrator to make
changes that were not intended because
they have sufficient control and so the
whole idea of doing this kind of
analysis is that you don't trust anyone
you don't trust the system you don't
trust the logs you just look at the
storage and you see what's happening I'm
so first as a little detour the this is
all the possible components of a
database so logs either audit the right
ahead love Darfur transaction integrity
you may make care about what's happening
in RAM you may care about actual data
and then there's all the the unwary abul
stuff so for example indexes and I have
some pictures would be helpful and
accessing data faster they're not
technically data they're actually a very
data which is something you use to get
to the data you want but obviously there
are things you can see in them in fact
sometimes more than an actual raw data
and if you're thinking database recovery
or database access which is what a lot
of people were thinking especially when
we started this work then it
turns out that database recovery only
cares about the tangible stuff so if you
have something in a database table then
the recovery will try to make sure that
you can get it back but if you delete it
a record or if you cared about what was
in the cache well that's not really
something that's being guarded by any of
the systems so generally you can get it
back and this is actually done by design
so relational databases were
intentionally built to take control over
storage and that's part of reason as you
see why analysis is so much fun because
it's this own little world and you get
your logical interface and the database
handles everything internally and
oftentimes you can't tell and that is
intentional but sometimes you want to
and then there is one more kind of
interesting aspect of getting this data
so suppose that the database did give
you back what you asked for problem is
how would you actually verify that it's
accurate and hasn't actually changed it
in the time you asked for it and the
time I get back to you because obviously
database squaring is not really built to
guarantee a chain of custody the data
was not affected and you are annoy so
you also want a mechanism that gives you
exactly what's there and guarantees that
nothing quietly changed because again
you have no control over what happens in
the storage so you don't know what
actually will happen when you pulled it
out and so again as a little detour in
general I'm sure most of you are
familiar with us if you delete a file in
the file system anything at all nothing
actually gets wiped out for many reasons
partially because no one wants to do any
work so these are to say this is just
unallocated space and I'll get back to
you later if I need to write something
that I can use this location to actually
store something and then over time
deleted data would actually get over it
and and disappear with some unknown
duration and so then the process of file
carving which is a well-respected
technique in file systems
digital forensics is to look through the
disk storage ignoring the file system
because sometimes you're looking for
things that are gone or corrupted and
then look for magic sequence of
characters that indicate that this looks
like a JPEG or this looks like a PDF or
a word file and then you say well if I
were to assume that it starts here and
this is the header of the file then I
can scan through and pull it out and
this is how all of the file carving
tools work it gets a little more
interesting for example if you have an
image embedded in Microsoft Word
document you might still be able to get
it out it might look different that's
the basic idea and the viewer is a
little skewed but I think you get the
idea fragmentation right here so you
look further just you find the header of
the file if it's an image then you start
reading through multiple fragments you
put them together and voila you have the
file now again this gets somewhat more
interesting if the file happens to be
fragmented on disk so half of the file
is here as a file is there you get first
half of the image this is from one of
the papers that we're talking about
putting together back together the
puzzle that's effectively what you have
to do you put together different little
pieces and you try to assemble back into
a coherent file so this is what file
carving is this is something that's been
done for at least a decade it's not
longer it turns out that file carving
doesn't really help you with a database
specifically database files because
databases are their own little universe
database files do not have file headers
actually data relational database files
consists of a bunch of independent and
mostly self-contained pages so if you
look through you don't find the header
of a file and end of the file you just
find some sequence of pages that
constitute different structures in the
database and interpreting them is even
more complicated which is what I'd like
to argue so once you've found the page
or a content it's not that easy to tell
what you're looking at because the game
it wasn't really made for external
consumption it's pretty much internal
storage so again as a little detour so
from database perspective you look at
something and you have a table in this
case I have a table for columns six rows
that contains the user IDs names
positions and home downs so from logical
perspective if you were to query the
database you asked for some columns you
have some data and that's what you can
request it is by design that you have no
way of telling how it's being stored
typically in row based relational
databases which has a majority of
relational databases in reality of the
data is separated into pages so for
example first two rows might live on
page one and then tomorrow's might live
on page two and this is what it looks
like each page is a little
self-contained semi file and this is
what you find in storage but it gets
more interesting when you look at other
structures so in addition to the table
that we had before you might also have
an index an index is simply a value to
location pointer that helps you find
your data so in this case I have an
index on home down which tells you if
I'm looking for a particular town which
row do I find it in again this is
auxiliary structures because you don't
it's not part of the data it's a copy of
the data that's created to help you find
what you're looking for and if you think
I don't remember creating index as well
a lot of them get created automatically
which is also an interesting fact so
when you create the primary key when you
create a unique constraint database will
build an index to enforce things without
notifying the user of course and so each
one of the structures also are typically
stored in the pages indexes are a little
more complicated than on this picture
but ultimately it's a big structure
that's fragmented into individual pages
and somehow stored on disk and pages
would often try to align with file
system pages or it is similar
so a page at the very very high level of
view contains maybe fifteen twenty
percent various header data so each page
has its own header that among other
things might tell you where the space
belongs to so which data structure comes
from what's the data type the category
of a data structure then there's a row
directory which is just a bunch of
pointers to the actual rose and then
somewhere inside the page and the
payload component there are the actual
data rows with possibly some additional
metadata so the interesting part about
all of this is that a lot of the details
vary database database but every
relational database is tested of which
there is at least eight to ten they all
have the same general structure and the
first thing we've set out to do was to
come up with a set of descriptive
parameters that will tell you how
exactly are things set up so generally
it looks like this and then some details
as to what's on top what's on the bottom
how many metadata enters you have that
there is from system to system and so
once you step back and actually look at
the storage as a big collection of
database pages and then you can begin to
interpret what the storage contains and
try to understand what you can learn
from it and so we built this tool gb
Carver as a reference the file carving
process and it consists of two different
pieces the parameter detector and the
actual data parsing step and I'll talk
about each one separately so first
parameter detector again remember every
page looks similarly but the details
vary from system to system and wouldn't
it be nice to be able to learn what the
system actually does so what parameter
detector does you install database then
it automatically loads a bunch of
synthetic data that we know what it
looks like and then by capturing storage
it can deduce how the data lens in the
database storage so again
pretty much learn the layout of our
database and one of the reasons we
wanted this is to be able to check what
happens with a new version and typically
things don't change but for example at
least some time ago maybe 10 years ago
postgres had actually made a significant
switch where several of the parameters
were changed although normally wouldn't
really tweak it too much because it
requires significant changes in
processing so obviously there's a lot of
parameters I'll mention the couple for
example and this by the way is the list
of databases we primarily focus on a
couple more not mentioned here because
they happen to share the same storage so
for example mariadb uses the storage
engine of my sequel Greenbaum uses the
storage engine of progress so the pages
are more or less the same of course the
engine itself is a little different and
so for example the page might have a
structure identified that tells you what
kind of structure the page belongs to
sometimes it might not be on the page
similarly as I mentioned sometimes you
insert rows from the bottom to top
stacking them sometimes you start from
the top and down the bottom this is the
kind of thing that different database
choose different strategies now the more
interesting parameters are the row
identifying column count which
interacting in good ways and so row
identifier is this extra column that the
database may or may not choose to create
so normally let's say in this example I
have three columns number name and city
sometimes you'd actually see those three
values sometimes there is a fourth
column which is the internal row ID it's
called ctid in progress droid in oracle
so you can actually query for it and in
reality on the physical page there's
more pay more columns than you create
and then some databases choose to keep
track of how many columns there are by
just having the number of columns stored
on page and an interesting interaction
part is that the count sometimes does
include the fake pay a fake column and
sometimes does not
so you can have all sorts of combination
you might have a row ID you might have a
count of three you might have a count of
four you might have neither and all of
this is a possibility system to system
so then there is the value the
construction which is also kind of
database database thing so impose these
things are pretty obvious for example
for numbers you just have a 256 4 bytes
take storage and the numbers interpret
it this way and then there is Oracle I
firmly believe that Oracle chooses
designed simply to have something for us
to talk about so if you think about how
they represent the numbers one digit is
there to tell you how many digits number
contains so the first three numbers it
starts from three because there is only
three or rather than four by it's being
used then the second one refers to how
many zeros there are at end so 192 means
no zeros 193 means two zeros and so on
and then the final number in the first
example is the value itself minus plus 1
so 4 is represented as three for three
numbers 192 no zeros 544 then 40 is
represented as three 192 and 41 and then
400 is represented a 3 1 93 for two
zeros and then five for the four in the
beginning and then finally I have so
this is 4 bytes then 1 93 4 20 and 5 4
400 and then 41 4 40 those are the
action four bytes with you see in the
storage and I have a couple more
examples and I have no idea how my PhD
student figure it out still not sure but
somehow he learned it and it works so
clearly it is actually how thing goes
toward so one more interesting example
that's still kind of something working
on we have some heuristics but it's the
work in progress so if you have a string
the typical mechanism is to have a
length of a string followed by the
actual
data now if you happen to have a three
character string then it might be
difficult to tell which one you're
looking at because both are valid
interpretations one says this is the
three and this is a three-character
j-a-y the other possibility is to
interpret that as a number of 4 bytes
and it's not necessarily obvious because
at least individual pages don't
explicitly store that information you
might find it somewhere else of course
so then there's parsing also give a
couple examples just to give you a quick
example of getting stuff out of progress
and some more very curious algebraic
decisions so some more parameters the
orange raw data delimiter is where the
individual row begins on a page
somewhere about there the header this is
just a piece of a page a byte by byte
starting where the rows are and the two
columns you seeing here this is the
ascii character manifestation and this
is the decimal value and obviously some
are not visible ascii characters so the
three bytes and orange indicate that the
data begins here then there's another
parameter that tells you how far you go
where the row actually start and then
you have a 4-byte number and the four
byte number and told chris is stored in
at least relatively obvious way then you
have a string length but it would be too
simple to store the actual string length
so what in fact happens you have 39 that
represents a team and how do you learn
that well there are two parameters one
of which you subtract another one of
which you divide by 4 4 postgis and
particulars minus 3/2 which gives you
the actual length of the string that the
database means so when it says 39 it's
an 18 byte string again not quite sure
how he figured it out but there you have
it I'm so again this
back to our example of what the value
might contain so 65,000 is 4 4 4 bytes
195 407 for the six in the beginning and
then 51 for the 50 in 65,000 and there's
a lot of other interesting issues so we
kind of have a handle on internal arrow
IDs but databases might also have binary
like large objects which could be once
again images or some other data types
some databases use compression some
sometimes compression kicks and
automatically like in Postgres obviously
there's encryption issues and so the
construction of values is still somewhat
of a work in progress and then I wanted
to show some examples of the kind of
things you can learn from various
operations so again because when you
issued delete or an update or any sort
of command things do not immediately
happen the change is very indirect so
for example if I say delete a row then
they're always mark is deleted but
remains there and when the curious
result is that the attacker someone
using our tool then has more access to
the data because as the user with
legitimate access you can't really have
a deleted rope because it's been deleted
but it's still there it's simply
marketing deleted and then if you have
an update especially if you have an
update to a larger value so in that case
changing Smith don't not Smith you can
set the original value where they're all
values to be so you have to delete the
old one like you do normally and then
reinsert the new one so pretty much
everything stays around for an
indefinite amount of time and here's an
example of an actual data so this is
from sequel light from an Android device
that came of ebay and one of our
collaborators got us and this is a
single page that happens to contain SMS
messages so this page address tells you
where the data lived on a disk a record
count at least in this case tells you
how many active records there is
actually 21 records 20 active one
deleted so this is 20 but analogy
there's 21
those are the 21 records and then on the
bottom you have a deleted one which has
been a little bit nailed out but it's
still there and obviously recoverable
and in this particular case you also
have a row ID which is a column that was
never created by the user this is
something that sequel I'd keeps for its
own purposes and so that's actual data
from an actual phone and one more thing
I wanted to briefly give you some
background on so this is the stochastic
forensics back in forensics mechanism is
actually something that was proposed by
our collaborator Jonathan gear and he
had this idea and published the paper a
few years ago also in dfw yes that it's
possible to look at the side effects
created by the system not things related
to security but actions performed by the
system for some other purpose to learn
what is happening and that's the exact
same iteration we're going for here in
terms of applications to look at the
storage or to look at the system
behavior and to learn what is happening
not because there is a security
mechanism that tells us that log things
but because this is what happens when
you do X when you do X Y happen so the
storage reflected it's actually much
harder to avoid them the security
logging because within our privileges
you can change that and to give you an
idea of how the how the motivated
approach works so what he did back back
then was to look at windows file system
time steps so every time you access a
file in windows there is a time stamp
that was it being changed so if you look
at the folder and his specific task was
to prove that an employee had absconded
with some data before departing so if
you look at the folder and you look at
the time stamps on the bottom and green
is the typical distribution of the time
steps where some things were changed
recently some things will change longer
ago some were chased a while ago and
some dates go all the way back to zero
or something unsaid so if you happen to
copy a folder
point then you recursively go for the
whole folder and you touch every file
that's how folder copy works so that
tends to create a cut-off right here
which is a very likely proof and there
are some more analysis in the paper that
tells how likely it is which is the
proof that at this moment where you see
the red spike a cut off someone had
copied the whole folder and that it
doesn't have the normal pattern
distribution of time steps and of course
an interesting thing about it is that
this is not a security mechanism this is
just something that the system does
anyway for some other reasons so to give
some more idea of the kind of stuff you
can see in storage again a member table
on the right index on the left so if you
update something the old value is
deleted the new values inserted and then
of course index and other structures
would keep their own copy so the old
value is there and the new values there
and nothing changes and one more thing
about cashing in case to remind you how
it means database caching works so if
you have data on disk on left you access
a couple of pages or change a couple of
pages the copy is loaded into memory
change the memory and for a while it
actually differs from what's on disk
then as you access more stuff like for
example another query accesses page d
that goes into memory and then the old
stuff has to be flushed out and
synchronized back to disk so now just to
go through the same steps in a database
and those are all different moments and
time you can capture if you look at the
storage depending on when you look at
the system or where you are in this
process of an update so again I start
with the data I issue an update first
thing that has to happen is data goes
into memory second it gets modified in
memory and same applies to an index by
the way index also gets loaded into
memory because you can alter things in
this
and then at this point you can see the
difference and you can essentially see
anything in progress because cash
doesn't match to disk then at some point
the data might be written back to disk
and remain a memory and then eventually
it would be flushed out I'm so I'll skip
over most of it because of our setup
issues I'll just show your quick summary
office so this is Oracle buffer cache
50,000 pages each page is a pixel and so
this is 50 thousand pixels and what
we're simply showing is you start with
the preloaded cache of some unrelated
data and then you start running queries
and then all contents of memory start
being over it and step-by-step so first
there's some red stuff on the bottom
then there's more green things more
green things coming from line order and
another synthetic table and it's kind of
first-in first-out sequential over right
and you can also don't know if you can
see it here but I can show you the
bigger version you can also see aspects
of the old stuff so it's not necessarily
completely over written that least not
until multiple passes know all the
things you can see in in storage alright
so the delete example is definitely one
of my favorites because it again shows
the difference between the command you
issue and what actually happens in the
system and then things that you can't
necessarily see as the user or
understand so let's say you decide to
delete a row in the database and this
particular role is in a table and there
is an index and there is the materialist
view that stores us information as well
phone number social-security number
doesn't matter and as I mentioned
indexes could come into existence for
many reasons so it's sufficient to have
a unique constraint that automatically
creates an index so you might think that
you should delete and data gets deleted
or at least that maybe you
delete command and data gets marked and
then later purged however that's not
what actually happens so we're tracking
multiple steps in a timeline initially
you load the data then you should delete
at time one at time to you refresh the
materialist view at time three you flush
out the contents of the memory and a
time for you run enough query to
overwrite the memory and then at time
five you issue a bunch of other rebuilds
they're building the entire structure so
let me talk about what actually happens
when you should delete so here we are we
start with three different values this
is the value in table this is value in
index this is the materials you when you
should delete first thing that happens
two more values get created nothing
nothing when this gets touched at all
the index page gets loaded as part of
finding the value because you need to
find it to believe it and then the table
page gets loaded into memory and then in
memory gets marked is deleted so you've
gone up to five one of which is mark is
deleted instead of three that's the
immediate reaction then you perform a
refresh that brings you up to six
because the material as you gets a copy
of a page that has a value mark to
delete it still different from disk
you've now double the number of values
by issuing the delete there is now six
instances instead of three then you
issue the flash command which doesn't
actually move anything from memory it
simply forces the memory to synchronize
the disk so at t3 those two values also
get markers deleted to match the memory
the values of memories still there
they're simply considered free space and
you still have six values and there's
all sorts of colorful markup some
deleted some not so it takes a very very
very long time for a value to actually
go away so you would need to rebuild you
would need to run enough queries to free
out memory which is time for and then
you would need to build the structures
one way or another because otherwise it
will pretty much stay for sometimes
alright so a couple more examples and
then we'll have some time for questions
so this is more recent work again the
idea is you look at the storage you look
at the log and you say something doesn't
match you don't know why necessarily but
you know that either a particularly
clever database administrator or a
hacker with too much axis has managed to
do something that has not been reflected
to log right the system has been
compromised and once the systems
compromised if the database hasn't
logged it then there's really no chance
that it's going to protect you from this
attack because it doesn't even know that
something's wrong so in this particular
example we have a log file with to
delete one says delete entries for
Chicago once as believe in Jesus start
from Chris and then what you can do is
and we have some algorithms in the paper
what you can do is to match it to say
this delete the throw that I see can
match this delete action so for example
Christine record record one could have
been deleted by delete Chicago could
have been deleted by this you don't
necessarily know and then then prefer
Christopher could have been deleted only
by this by this matches and then record
number four there is no explaining how
it got deleted so Randy's only
explanation is someone did something
without logging by accident or on
purpose but the point is something does
match and the audit wouldn't help you
because the log has no recollection as
to who actually deleted row four and you
might think if you database
administrator is clever enough they
could find a way to override the data
right so obviously the deleted data
doesn't favor there forever it is marked
as free space and as new stuff comes in
subject to different rules and some
depending on the system it will
eventually get over it and buy something
new so here's another example to deal
specifically to deal with the
particularly clever dba's so let's say
in delete records and you had a record
that said lamp and the furniture table
and then you said well if I just leave
it there then someone's going to find it
and I'll be found out that there is no
log record for it so you insert the new
record with the value of dog right here
and depending on database but in many
cases the value can get overwritten
however two problems with that first of
all you have to match the value to be
exact size if you insert dog over lamp
there is still the letter P right there
which you can still see in the storage
because again nothing goes away the
first three characters got overwritten
but the old value is still hanging out
there and you can at least see that
something used to be here and you can
see a part of the value remaining on
disk and this thing definitely won't go
away for a while because there's nothing
you can insert over a little fragment of
data and then more interestingly the
index pretty much keeps things forever
so most of database indexes would never
let go of value at all until it built
I'm so in addition to this for dog you
have the record with index of 0 and then
for record 3 that you which used to be
here you still have an entry on index as
well that point there and then somewhere
else database determines that the values
been deleted and for this first of all
it almost never goes away that this has
to do with how to inductions work and
how the indexing structures operate and
more interestingly you can't actually
override it you can issue direct command
against memory and you can say insert
something into an index here that's not
you can kind of time it for a table but
you can't really do this for an index so
if you look at everything then it's
really hard to find your way around and
what the storage could reveal about the
database
alright great that leaves us some time
for questions so in general we've been
working on this database carving
solutions for a while we're pretty much
want to in a long run we want to build
something that lets you ask meta queries
ask you something about the database
even if you don't trust the database or
its database doesn't provide this kind
of interface if you want to know
something that's happening on the inside
you want to be able to ask the question
and to say what is this doing does this
match to this what's remembering what's
being changed figure out anything that
might be off and no assumptions because
most of the forensic and security
approach is the TBC say well you have to
configure your logs just so you have to
make sure that the database has the
security extension and then you can be
relatively secure but of course in
reality you run on the system's with
whoever settings you have and we want to
just be able to come in and say what is
happening here right now so we're
definitely looking for collaborations
and use cases because databases are
everywhere and we're looking for more
exciting applications and that we could
do and we also happen to have a job
opening in the lab except that it's not
directly on this topic but more on
reproducibility however still if you're
interested to talk to me or to anyone
from our group and with that I think we
still have a few minutes for questions
questions what's left here yeah that's
fine
right well so so the question was how do
you prevent evidence contamination when
you collect the data mostly that
duration is that if you trust the system
itself to answer about what's in the
database then there is ZERO ways of
knowing if it's reliable now as far as
collecting it so our best approach at
the moment is to there is still the
chain physical chain of custody right
you need to take an image of the drive
and you need to carry it over and no one
can tamper with the storage and you know
the physical controls is really outside
of the realm of digital forensics
however what we can do to avoid
contamination is exactly looking at the
storage in the read-only mode so that's
kind of the big motivation right even if
the database could answer things and
even if you trusted it sensors you would
have to start a database and once it
turns who knows what it does so what we
want to do is to be able to query over
storage that's mounted and read only you
could physically disabled the ability to
write and we would just answer things
about storage because we're just looking
from the outside independently right so
this way as long as you can tell me that
no one changed the drive and as long as
you can physically flip the switch to
not let it be modified and then we can
we know it hasn't changed
I see so the question is how practical
is it to stop everything to be able to
collect evidence so obviously yeah I'm
not really an actual investigator so
obviously you need to come in and
capture the images and the ideal world
someone comes and stops the servers and
images them and the worst case scenario
they come in and take the computers but
can the physical capture part I agree
it's inconvenient but you in order to do
any sort of forensic analysis you would
have to capture them as your photo
relevant storage and I would say it's
more of a physical custody issue I think
you can shut down things and image them
on the separate read only thing and then
presumably you can then leave but yeah
so this is this is a good question but
somewhat orthogonal to the problem of
performing analysis and the same
question I'm surprised it's not a
tertiary question is what happens with
encryption and I would say the same
answer where you need to physically get
to the data and decrypting it is also a
problem and then interpreting what's in
the database and coming up with evidence
is a separate problem and I agree we're
not really solving the total drive
encryption the only thing we have going
for us is that at least at the moment
except for most dedicated Hardware even
if you have total encryption at the disc
level any time you access something and
move it into memory that gets decrypted
to be processed so if even if your whole
drive is encrypted you can see
everything that shows up in memory
used for what I see yes excellent
question the question is is there a CRC
checking so that interesting or not
depends on the database in some system
they've pretty much like in my sequel as
far as i know you change the number of
rows on the page with try playing with
storage then bring a little bit you
change the number of rows on the page
and it just leads to you a rose and
nothing happens in commercial systems
you do have a checksum meaning that if a
page is changed it realizes that fact
and in the distance equal server and in
oracle there are some tools that can let
you fix it but fix it to the point of
ejecting the page is not actually fixing
it one of our goals of course would be
also to look at can you recover fix the
data if something went wrong best-case
scenario you would be able to cut off in
an existing tools you can cut off the
pages were to check some doesn't match
its storage ships then it's actually
surprisingly easy to bring a database to
its knees if you change the value you
can kind of find the checksum if you
shift their dresses that says it's know
something is wrong but the checksum is
the wrong place and that's that you just
get panic messages about can start can
find something so you're definitely a
tempering storage is definitely
effective all right thank you thank you
very much
fight them on like tuesday all right
well is the 19 I think it's pretty fun
but Mike is ok I think as long as you
hold it okay Wow yeah I try to drive the
plane and then I forgot about it and I
walked away
[Music]