Would appreciate fe...
 
Notifications
Clear all

Would appreciate feedback on dissertation methodology

5 Posts
4 Users
0 Likes
679 Views
 nmch
(@nmch)
Posts: 2
New Member
Topic starter
 

I am a MSc Computer Forensics student at University of South Wales and am in the initial stages of my dissertation, an investigation into data recovery from SSD. I’m currently designing the methodology to follow for the seeding and deletion of data and would appreciate any feedback from the community, in the hopes that I can produce something that would be useful and interesting to many.

I have considered previous studies on this area and would like to build on these with my own research. Bell & Boddington (2010) used drives containing an NTFS partition and enough copies of a 196KB text file to fill the capacity. The drive was quick formatted and shutdown immediately following completion. This was a key study as it showed the speed Garbage Collection begins to wipe data. However, in formatting the data all blocks are marked as not in use making the GC process easy to run. King & Vidas (2011) simulated a high use drive with hundreds of binary files and a low use drive by installing a fresh OS and storing 2 reference files. This showed how different volumes of data can affect recovery, but with little variation in the files (size). A previous student at my university created 6 reference files of different sizes that were stored amongst various media files within an OS. They investigated whether different delete methods would affect data recovery of the reference files (deleting via Recycle Bin or Shift + Delete). This was well planned and followed a scientific methodology, but the data used was controlled.

I would like to try to produce a study that is closer to a real world scenario rather than the academic approach previously taken. I aim to do this by using an assortment of file types and sizes taken from an old backup, instead of repetitive test data. The below outlines my current intentions for what data will be stored on the drives and how this will be deleted.
I will be creating two data sets
• 90% of the drive storage capacity in use, to stress test Garbage Collection
• 40% of the drive storage capacity in use, to see how fast the process is when plenty of empty space is available.
These will be made up of
• Windows 10 (with TRIM enabled)
• Application software (email, web browser, media player, document editing)
• User data files (approximately 5% documents, 20% audio, 55% video, 15% images, 5% archives) that will be organised into folders similar to the defaults available on Windows.
Two delete scenarios will be considered for each data set
• All user data files will be sent to the Recycle Bin and emptied
• Half of each type of user data files will be deleted by sending to the Recycle Bin. This will then be emptied allowing all files to be marked for deletion at the same time.

Following the delete command, power will be removed from the machine and the drive will be imaged using 3 different methods, but always with a hardware write blocker. The power will be removed following 3 different time intervals 1 minute, 15 minutes and 1 hour. The timer for these scenarios will be begin when the empty Recycle Bin instruction is sent. In some cases this may mean that not all files will have been processed for deletion, but I would like to see if Garbage Collection begins as soon as any data is marked as no longer in use.

To interpret the results, I will record the number and type of files stored as user data and how many of each were deleted. This will be used for comparison with the recovered data. The tests will be repeated on different models of SSD to allow for firmware differences, which will be wiped between tests. A copy of both data sets will be created for re-use in each test.

I would appreciate any feedback regarding whether you think this would be an accurate representation of a real world scenario whilst remaining scientific, if there is anything I may have overlooked or any other comments. Thank you

 
Posted : 03/06/2018 1:07 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

I am not sure to understand several points. 😯

Two delete scenarios will be considered for each data set
• All user data files will be sent to the Recycle Bin and emptied
• Half of each type of user data files will be deleted by sending to the Recycle Bin. This will then be emptied allowing all files to be marked for deletion at the same time.

In first case all user data are sent to the Recycle Bin, and the Recycle Bin is then emptied, OK.

In second case, what happens to the "other half" of user data?

How these two scenarios relate to "real world usage"?

Following the delete command, power will be removed from the machine and the drive will be imaged using 3 different methods, but always with a hardware write blocker.

How were the "delay intervals" chosen?
I mean the 1 minute/15 minutes/60 minutes after the "Empty Recycle Bin" command, how do they relate to "real world usage"?

Either the three different methods (which ones?) are actually different in the sense that they output three different "images" (either three non-forensic grade-images or one forensic-grade-image and two non-forensic grade-images) or they will produce exactly the same image.

Same goes for the write blocker, of course you are perfectly free to use a hardware one but it is not like it is "strictly needed" (there are reliable OS's that can do the imaging without needing the hardware blocker).

There are IMHO several other things to be considered/thought upon, it seems to me that you are assuming a few things that may (or may not) represent in themselves some AFAIK unanswered yet questions
1) is there some form of relationship between file types and either deletion or garbage collection?
2) or is there some form of relationship only with average file type size?
3) does (besides the make/model of the actual SSD) a relationship among the SSD size and the "data fill" ratio? (i mean does a same make/model SSD 128 Gb in size behaves the same as a 256 GB one when the whole data on them is 64 GB?)
4) how (exactly) does the "empty recycle bin" work? (I mean, will aardvark.bin be deleted before zyzzyva.zip?)
5) if you are deleting (actually emptying the Recycle Bin) a huge number of files, it will take some time, is it (will it be) connected to the number of files or to the size of the files?

jaclaz

re 1) and 2) above what I mean is (part of) the scope of the experiment to actually recover files after the deletion or only verifying that some sectors "belonging" to the files were still readable?
I believe that there is no connection whatever with "contents" of the files, so, if I were you I would use the "old backup" only to get the directory structure and names, extensions, sizes and timestamps of the files, then I would use a script to fill each file with some easily parsable data, such as (example only) fields
1 - 256 bytes field filename (00 padded)
2 - 16 bytes field absolute sector number on disk
3 - 16 bytes field sector number within the file
4 - 16 bytes field extent number (in case of fragmented file)
5 - 16 bytes field $MFT record # of the file

 
Posted : 03/06/2018 2:44 pm
(@thefuf)
Posts: 262
Reputable Member
 

Hello.

There are many low-quality papers about SSD data integrity and recovery, so the primary goal is to do it better.

There are several reasons why data recovery on an SSD is complicated or impossible
1. Filesystem-aware garbage collection.
2. TRIM and similar commands.

Bell and Boddington demonstrated that the solid-state drive used in the tests had the filesystem-aware garbage collection (while they didn't directly state this, the firmware of the drive contains a partition table parser and an NTFS parser, both implemented as a part of the "self-delete" feature, see this picture). Several papers deny the existence of such a type of garbage collection (for example "Note that the data destruction process is only triggered by the TRIM command" © Belkasoft, 2014), but you can't fool IDA Pro.

And in one paper authors did tests with (at least) one drive with the filesystem-unaware garbage collection, but got results similar to the case with the filesystem-aware garbage collection (Evidence Verification Complications with Solid-State Drives (PDF)). I suspect they were running the tests against the drive with a filesystem mounted in the r/w mode (as stated in description of the tests, this is hilarious).

So, first of all, you need to decide whether an SSD you are going to use has the filesystem-aware garbage collection or not. If it has, document this, because you are going to see less recoverable data (even when no TRIM commands were issued).

Next, an SSD can return deterministic data (null bytes or something else, but not the original data) after the TRIM command is issued. If this is the case, then sending a TRIM command for a specific LBA range will likely "wipe" that range, so no data recovery is possible after typical acquisition methods (the only options to recover the data are the "chip-off" and the "techno mode").

When an SSD doesn't support the deterministic read after TRIM, you are likely to recover some deleted data after the TRIM command had been issued. However, a drive may occasionally replace "trimmed" data with null bytes (so recoverable data isn't stable as on an HDD), some drives replace "trimmed" data only when writing to a drive (to a different LBA), so a write blocker can prevent the so-called "self-corrosion".

In any case, you should determine if an SSD used in your test supports the "Deterministic Read After TRIM (DRAT)" feature or the "Deterministic Zeros After TRIM (DZAT)" feature. If it does, then you are likely to see less recoverable data if an operating system was issuing TRIM commands when deleting files.

Also, limit the usage of hardware write blockers in your tests. If you need to do so, use a simple hardware write blocker (which acts as a command translator). The reason is that some hardware write blockers (which act as a block device sharing box) may cache the data read from a connected drive in the internal RAM, so, if something is modified by a drive itself (for example, when "trimmed" data is replaced by null bytes after an hour since the TRIM command had been issued), you won't be able to see the modified data without rebooting the write blocker. And this may spoil the results.

 
Posted : 03/06/2018 3:40 pm
(@athulin)
Posts: 1156
Noble Member
 

I would like to try to produce a study that is closer to a real world scenario rather than the academic approach previously taken.

And what question or hypothesis are you investigating more exactly?

I aim to do this by using an assortment of file types and sizes taken from an old backup, instead of repetitive test data.

Why? Without knowing your research question/hypothesis it seems difficult to evaluate, but it suggests that you are addressing the question of data content affects recovery.

These will be made up of
• Windows 10 (with TRIM enabled)

I assume you're referring to a test environment. But how are you going to verify that TRIM commands really are issued? If they aren't for some reason, your test will not clearly be useful.

To interpret the results, I will record the number and type of files stored as user data and how many of each were deleted. This will be used for comparison with the recovered data. The tests will be repeated on different models of SSD to allow for firmware differences, which will be wiped between tests. A copy of both data sets will be created for re-use in each test.

You're skipping over the problem of recovery how do you know that successful recovery depends only on GC behaviour? If it doesn't, you have an error source that will skew your results.

Seem to me you want to consider a null test, i.e. a series of test performed with a non-SSD. As GC cannot be a factor here, you may be able to get a measure of how well your recovery mechanism works – unless, of course, you already have a plan for determining this.

I see no or little value in using 'real life data' unless you have the question 'is TRIM or GC behaviour dependent on affected data? ' somewhere in your research program. But … I would expect that question requiring a very different test setup. So … ?

If your test data sectors are synthetic and unique, you can identify recovered sectors by inspection, and you can even identify incorrectly recovered data, something you don't seem to be able to do with your current setup. Let's say you recover a sector that's all zero. However, you probably have several dozen of them in your test data – so which of them did you recover? Or did you recover an irrelevant sector that wasn't even part of your experiment?

Or is recovery relevant only on file basis?, not on sector/cluster/whatever basis?

Until you know what the risk for bad recovery is (probability + confidence), it's not entirely clear that you have control of error sources in your test.

Such as … what does Windows 10 do all by itself? Are the tests you propose the only source of TRIM commands in the system? Or does Win10 keep temp files around that it will delete on its own accord? If it does, how does that affect your test – it seems you may recover Win10 files along with test files. Can you distinguish between them?

 
Posted : 04/06/2018 3:10 pm
 nmch
(@nmch)
Posts: 2
New Member
Topic starter
 

Thanks for your replies, I've considered some of the points made.

In saying I would like to create a real world scenario, this is referring to the data sets that will be created and the deletion of some of this by using the Recycle Bin. I'm aware some users may use advanced wiping software to hide any incriminating data, but I feel the circumstance of simultaneously wiping all data has already been thoroughly covered by previous research. The use of synthetic data has also been greatly used in past studies.

What happens to the other half of the data and how do these scenarios relate to real world?
When only half the user data is deleted, the other half will remain on the drive. Should data need to be moved around by the SSD controller so whole blocks are available for erasing, leaving data on the drive will make this more difficult than if all files were marked as not in use. I would like to see if there is a notable difference in the time it takes for data to be wiped between these two circumstances.
My rationale behind this is that if someone has data to hide, they may only attempt to remove the incriminating files from the drive. In leaving behind non-suspicious data the drive still appears to have been used and appears unsuspicious.

Previous research used multiple copies of the same few files to fill a drive. By using different files of different sizes, I think this may decrease the likelihood of all data being in whole blocks that can be wiped immediately by GC, meaning that it will be necessary for some data to be moved around. The requirement of moving data around to create whole blocks for deletion may be affected by how full the drive is, meaning some data may not be wiped in the time allowed.

Regarding how data deletion is performed by Recycle Bin or if there is any relationship between file types/size and how they are selected for GC. I will be recording these details of all files that are used in the tests and look to see if anything can be determined in regards to this from my results.

How were delay intervals chosen?
Based on previous research seen, the process tends to begin immediately and acts fast. I'm not decided on whether I should begin the interval following the start or completion of the delete. My initial thinking was that should someone arrive at a scene and find files in the middle of deletion they would want to stop this.

What is the hypothesis or research question?
The purpose of the research is to determine if GC acts as aggressively in certain scenarios as it does when a full drive is marked as ready for wiping. The majority of previous research I have seen fills a drive with data and formats it, making the process easy for GC. Should the drive be almost full and the majority of data is marked for deletion, there should be no issue finding whole blocks for wiping. If only part of the data is marked for deletion, there may not be enough whole blocks available for deletion or empty blocks available to create whole blocks for deletion. Does this noticeably increase the time taken for all files marked for deletion to be unrecoverable verses when the drive is only partially filled.

I will look into a software write blocker instead of using a hardware blocker. The article covering TRIM exceptions was very useful and I will consider if any part of my process will be affected by any of the circumstances highlighted in this and the follow up article.

 
Posted : 17/06/2018 12:06 pm
Share: