Forensic Acquisition Of Solid State Drives With Open Source Tools

by Josué Ferreira

Abstract

From a judicial perspective, the integrity of volatile storage devices has always been a reason for great concern and therefore, it is important for a method to forensically acquire data from Solid State Drives (SSD) to be developed. The method in this paper presents a way to preserve potential volatile digital evidence, present on SSDs, and produce forensically sound bit-stream copies. Due to the volatile nature of SSDs, Digital Forensic Analysts are often faced with the challenge of preserving the integrity of digital evidence seized from a crime scene. This paper proposes a method to perform forensic data acquisition from SSDs, while preventing the TRIM function and/or garbage collection from operating without user input, therefore maintaining the integrity of potential digital evidence. The results show the method can and will prevent any unintentional changes, on the disk’s user generated data and unallocated data, from happening prior to and post the forensic acquisition stage.

1. Introduction

The field of computer forensics has been in need of a method to perform forensic data acquisition from Solid State Drives for a long time. For about a decade, due to the lack of standardised operating procedures on how to image SSDs and judicial scepticism over volatile data found on a suspect’s device [1], potential digital evidence has been either lost or dismissed as inadmissible in court. According to R. S. Ieong [2] “when the underlying technology of the target device changes, new procedures are required.” This paper, based on empirical research, presents a new procedure for digital forensic analysts to handle SSDs without risking compromising the integrity of the device, and to create forensically sound bit-stream copies of SSDs using open source tools.

1.1. Contribution

This work contributes to the field of digital forensic investigation by proving that it is possible to forensically acquire data from a Solid State Drive (SSD)*, while preserving the volatile data that would otherwise, using current data acquisition methods, be lost. Current forensic acquisition methods, such as verifying individual files, were developed to image non-volatile storage devices and as a result, when applied to SSDs, can lead to loss of potential digital evidence and inconsistencies during the verification stage. This paper provides a straightforward method to preserve and image SSDs in a forensically sound manner using a write-blocker, Forensic Live CDs and open source tools. Let’s hope that this paper will firstly bring new knowledge, secondly a new perspective on how to perform data acquisition on volatile devices such as SSDs, and lastly, bring hope to the fields of computer forensics and law enforcement.

1.2. Motivation

The idea that Solid State Drives would be the end of computer forensics [3] needed to be challenged. Prior works have focused on garbage collection and the TRIM function, while research on coming up with a solution is virtually non-existent. This paper was written to lay to rest any ideas or myths that — due to the aggressive TRIM function and garbage collection — it is not possible to create forensically sound bit-stream copies of SSDs. In this paper, it is shown that the proposed method allows digital forensic analysts to generate forensically sound bit-stream copies of SSDs. The results presented in this paper are reproducible and for as long as the digital forensic analysts follow the proposed guidelines, more than one identical forensic bit-stream copy of an SSD can be generated at any given time. This method has been extensively tested and verified using open source tools. There should not be a reason why, in the future, the authenticity of the integrity of an SSD, when properly handled, has to be brought into question.


Get The Latest DFIR News

Join the Forensic Focus newsletter for the best DFIR articles in your inbox every month.

Unsubscribe any time. We respect your privacy - read our privacy policy.


2. Method

This section will introduce the concepts required to understand and reproduce the results from the experiments described in this paper (see section 7). The different elements of the method are explained, based on empirical research, and will help digital forensic analysts to assess the authenticity of potential digital evidence present on an SSD.

2.1. Mounted v. Unmounted

A storage device, when connected to a computer, is at increased risk of data modification. The automatic process of mounting a device can lead to changes – such as file indexing or changes in timestamps – to occur on a storage device, especially in the unallocated sectors of a partition containing deleted files, which when mounted can lead to potential evidence being overwritten or destroyed [4]. On Solid State Drives, because of the aggressive TRIM function and garbage collection [3, 5, 6] these changes are more noticeable and the risks of losing potential digital evidence through self-contamination is higher. Figure 1 shows the difference between the state of a mounted and an unmounted SSD.

2.2. Scenario 1 — Mounted SSD

The amount of data that can be recovered from a storage device depends on the file system and will vary from operating system to operating system. In Figure 2 we have two lists with the same files, some of these files have been deleted, but are still present on the Solid State Drive at the crime scene a). Consider the following scenario:

A few days later, at the forensic laboratory b), the SSD seized from the crime scene is connected to a forensic workstation for imaging. Current data acquisition procedures do not take into consideration if a device should be mounted or not. When connected to the forensic workstation with auto-mount enabled, the TRIM function is issued and file 37, which contains the inculpating or exculpating evidence, is removed and evidence is no longer recoverable.

2.3. Scenario 2 — Unmounted SSD

Now, consider the same scenario (See Figure 3), but this time the Solid State Drive is connected to a forensic workstation with auto-mount disabled. Because the device was not mounted, the TRIM function cannot be issued and file 37 remains recoverable.

2.4. Hashing Solid State Drives

The nature of digital evidence is by default fragile, prone to changes [7]. This is especially true in investigations involving digital evidence found on Solid State Drives (SSD). To determine the validity of digital evidence, hashing algorithms are used to attest, by comparing consistency between images [8, 9], the integrity of data and its legal validity in court [7, 10]. When verifying a hash value of a device it is important to take into consideration the state of the device. A device, depending on its state, will produce two different hash values: the hash values generated from a mounted device will differ from the hash values generated from the same device when unmounted (see Figure 4). This change in the hash values has to do with the state of the device and should not be seen as potential data spoliation.

2.5. Cabling and Adapters

The experiments, based on empirical research, show that different SATA cables and/or SATA adapters can lead to unexpected changes in the hash values generated from the same disk’s volume. The reason behind this change is unknown and requires further research (see section 10). The results also show that the hash value of a bit-stream copy will match the hash value produced by the adapter used to verify and/or image the SSD (see Figure 6). It is important to note that despite the change in the hash values generated from the disk’s volume, the hash value generated from the disk’s partition will always match regardless of the adapter used.

As shown in Figure 5 it is possible for adapters to generate false negative results; to assure consistency, the cable/adapter used at the crime scene should also be used at the Forensic Laboratory (see Figure 6).

2.6. Data Acquisition of Solid State Drives

Digital evidence requires appropriate methods of securing and preserving digital evidence [9]. The appropriate method must ensure that the integrity and trustworthiness of the digital evidence presented in court cannot be argued [11, 12].

In the field of computer forensics, the only way to determine if the integrity of digital evidence has been compromised is by comparing the hash values of a bit-stream copy with the original evidence. If the generated bit-stream copy and subsequent copies are identical to the original evidence then its authenticity and reliability is attested.

To preserve the integrity of digital evidence stored on SSDs, an appropriate method to successfully preserve the integrity of volatile data needs to be developed.

The method proposed in this paper will enable digital forensic analysts to create multiple and identical forensic bitstream copies of Solid State Drives.

3. The Proposed Method

To perform forensic data acquisition on SSDs, the automount should be disabled. It is essential that the device when connected to the computer be recognised, but not mounted. Disabling auto-mount will render the TRIM function and garbage collection ineffective, stabilising the volatile nature of SSDs, allowing for more than one identical bit-stream copy to be generated from the same device (see Figure 7).

  1. Disable the auto-mount or boot from a Forensic Live CD†.
  2. Perform all the verification and acquisition steps with the device unmounted.
  3. Decide on what adapter and/or cable to use and take note of brand and model. The same and only adapter should be used to verify and image an SSD.
  4. Connect the SSD to the forensic workstation using writeblocker.
  5. Verify the integrity of the device, using the hashing algorithm SHA-1, and take note of the generated hash value.
  6. Create a bit-stream copy.
  7. Verify the integrity of the bit-stream copy against the original hash value.

If followed as suggested, the results should always be consistent (see Figure 8).

4. Validation and Verification

“Validation is the confirmation by examination and the provision of objective evidence that a tool, technique or procedure functions correctly and as intended [14].”

According to the International Organization for Standardization’s requirements for digital evidence handling[15], repeatability is essential to determine if the same results can be reproduced by:

  • Using the same measurement procedure and methods.
  • Using the same instructions and under the same conditions.
  • Asking whether the experiment can be repeated at any time after the original test.

5. Limitations

The proposed method still presents some limitations:

  • Only ensures the recoverability of the deleted files still present on the computer’s last session.
  • The recoverability of deleted files will depend on the file system and operating system.
  • Some of the recoverable deleted data may be corrupted or incomplete.
  • Removing a Solid State Drive from a computer may not be easily accomplished.
  • Connecting the Solid State Drive to a forensic workstation with auto-mount enabled will result in losing potential digital evidence stored on the suspect’s storage device (see section 3).
  • This method has only been tested and verified using Linux operating systems.

6. Experiments

6.1. Scenario

Consider the following scenario where an SSD is seized from a crime scene to be imaged at a later stage. At the lab, after the exhibit has been hashed and imaged, it is then stored. Some time later, the defence requests access to the original evidence and the device is connected to a different workstation to be imaged. Will the newly generated hash match the original hash value?

6.2. Experimental Framework

To simulate an environment where a Solid State Drive is seized from a crime scene, two different methods were used for these experiments:

6.2.1. First Method:

  1. Disable auto-mount‡.
  2. Full-formatted with different partitions§.
  3. Filled with 4.1 GB of the same data.
  4. 2.4 GB of same data were deleted.
  5. Manually unmounted and then verified using the SHA256 and SHA1 algorithms.

6.2.2. Second Method:

  1. Full-formatted, different operating systems were installed in each SSD.
  2. Filled with random amounts of data.
  3. Randomly deleted data.
  4. Switch computer off.
  5. Booted Forensic Live CD‖.
  6. Verified using the SHA256 and SHA1 algorithms.

6.3. Time Period

The duration of the experiments conducted for this research paper spanned 30 days. During the 30 days, except for SSDs 6 and 7 which were imaged four times, all the other ones were imaged three times, at three different time periods: the SSDs were hashed on day one, after 15 days and, lastly, 30 days after being seized.

6.4. Hardware

Below is a list of the equipment used for the experiments.

6.5. Experiment 1: Disabling Auto-Mount

6.5.1. Purpose of Experiment:

To determine if disabling auto-mount will render the TRIM function and garbage collection ineffective, preventing changes from happening when connecting an SSD to a workstation. The experiment will be repeated twice, first by disabling the automount and secondly, using a Forensic Live CD.

6.6. Experiment 2 — Verifying the Integrity of Each SSD within the Set Time Period.

6.6.1. Purpose of Experiment:

Determine if connecting a Solid State Drive to a computer with the auto-mount disabled will, over a period of 30 days, prevent the TRIM function, when issued, from removing any traces of volatile data.

6.7. Experiment 3: Testing Different SATA to USB Cables and mSATA to USB/SATA Adapters

6.7.1. Method of Experiment

For this experiment, one Hard Disk Drive (HDD), seven SSDs, an internal SATA connector and six different types of cables/adapters were used (see section 6.4).

6.7.2. Purpose of Experiment

To determine if the adapters used to image Hard Disk Drives and Solid State Drives will generate the same hash values. The HDD and SSDs will firstly be hashed and imaged firstly using the internal SATA connector. The USB-to-SATA adapters will then be used to verify the integrity of the device.

6.8. Experiment 4: Imaging Sold State Drives: Do All the Generated Bit-Stream Copies Match the Original Evidence?

6.8.1. Purpose of Experiment

A combination of experiments 1, 2 and 3. To determine if, over time, the hash values of each bit-stream copy will match the original hash value of their respective SSDs.

7. Results and Evaluation

7.1. Results of Experiment 1: Disabling Auto-Mount

After the SSDs were connected to a machine with the autmount disabled, the integrity of volatile digital evidence was verified using a SHA1 and SHA256 algorithm and the generated hash values from each SSD matched their respective original hash values. When the experiment was repeated using a Forensic Live CD, the generated hash values also matched the original hash value.

7.2. Results of Experiment 2 — Verifying the Integrity of Each SSD within the Set Time Period.

7.2.1. Results

After the SSDs were connected, the integrity of the devices was verified and the generated hashes matched the original hash values.

7.3. Results of Experiment 3: Testing Different SATA to USB Cables and mSATA to USB/SATA Adapters

The adapters used to image the HDD and SSDs generated three different hash values (See tables 7.3 and 7.3.1). These differences in hash values are a result of the adapter used and not a sign of self-contamination. The hash value of the partition remains the same regardless of the adapter used to verify and image the storage devices.

7.3.1. Note on Experiment 3:

The experiment looked at different cables and adapters and how these can lead digital forensic analysts to believe the integrity of volatile digital evidence has been compromised when, in fact, it has not. The difference in the hash values has to do with the cable and/or adapter used to verify the integrity of the device and is not a result of data spoliation. The hash values of each SSD at the partition level remained the same regardless of the adapter/cable used to perform data acquisition of the disk’s volume: adapter 3 and 4 shared the same mismatching hash value of the disk’s volume, while adapter 6 did not match the hash values of any of the other adapters (see Table 6.4.3).

7.4. Results of Experiment 4: Imaging Sold State Drives: Do All the Generated Bit-Stream Copies Match the Original Evidence?

The hash values generated from each bit-stream copy matched the SSD’s original hash values, revealing and confirming that it is indeed possible to image Solid State Drives without compromising the integrity of the device.

7.5. Summary

The results of the experiments show that hash values of an SSD, connected to a computer with auto-mount disabled, will remain unaltered regardless of how many times the device is connected to a forensic workstation. The results also show that it is possible to generate, from an unmounted SSD, more than one identical working image.

8. Recommendations

It is recommended that:

  1. The proposed method should be adopted and amended, as needed, to comply with the current guidelines and/or Standard Operating Procedures implemented by the forensic laboratories.
  2. To ensure the integrity of digital evidence and avoid unexpected results, the cables and adapters used at the forensic laboratory should be verified and validated, prior to the imaging process, to ensure that all the cables produce the same hash values.
  3. Forensic Live CDs with auto-mount disabled by default (e.g. DEFT Zero 2017.1, CAINE 8.0, ParrotSec 3.6) should be used to hash and/or image a Solid State Drive.
  4. The Solid State Drive should be hashed at the crime scene; it would be ideal for the device to be imaged to an external storage device at the scene.
  5. Once at the crime scene, the suspect’s computer should be turned off and the Solid State Drive removed; if unable to remove the Solid State Drive, the computer should be shut down and booted from Forensic Live CD, without mounting the SSD, to perform data acquisition to an external storage device.
  6. First Response Teams (FRTs) should carry laptops with write-blockers for hashing and/or imaging seized Solid State Drives. The generated hash value will serve as a baseline to later determine if data spoliation occurred.
  7. The SATA adapter used at the crime scene to image or hash the Solid State Drive should be the same adapter used at the forensic laboratory for hashing and imaging the SSD. This helps to determine if any changes to the device occurred.
  8. Forensic analysts should avoid performing data acquisition using any imaging tools that require a storage device to be mounted.

9. Conclusion

The method of performing forensic data acquisition from Solid State Drives (SSDs) using open source tools proposed in this paper may not provide a foolproof solution to the problem faced by law enforcement and computer forensic laboratories worldwide, due to the different operating systems (OS) and imaging tools used in both public and private sector laboratories, but it does provide a verified and forensically tested solution that was long needed and that can be used by any digital forensic analyst to produce identical forensic bit-stream copies of an SSD seized from a crime scene.

The ability to generate identical forensic bit-stream copies has been problematic due to the lack of standardised operating procedures and the volatile nature of SSDs; this volatility brings the soundness of the integrity of digital evidence, and the case itself, into question. In the past decade, SSDs have increased not just in capacity but also in popularity among consumers and with it, increased chances of a digital forensic analyst coming across an SSD during an investigation. The volatile nature of an SSD invalidates current forensic imaging techniques and as a result, these cannot be used to perform data acquisition of SSDs, and for that reason a different approach is needed. The results of the experiments conducted show that, for as long as the auto-mount is set to false, the hash values of an unmounted SSD will remain unaltered regardless of how many times the device is connected to a forensic workstation, allowing for more than one identical forensic copy of an SSD to be produced.

10. Further Research

The results show that it is possible, for an unknown reason, for two different mSATA-to-SATA adapters and/or SATA-toUSB cables, at the hardware level, to generate different hash values of the same device. These differences in the hash values, as shown in section 7, do not suggest data spoliation. Further research is required to determine the cause. The research and results present in this paper do not cover data acquisition of embedded MultiMediaCard (eMMC) SSDs and how data can be preserved and acquired, in a forensically sound manner, from such devices.

Footnotes

* This paper is focused on Solid State Drives, but theoretically the method can be applied to any other type of volatile storage devices.
† Forensic Live CDs have write-protection rules [13] to prevent changes from occurring to connected devices, but a hardware write-blocker must be used when performing data acquisition.
‡ These experiments were conducted and verified using Fedora 25 & 26, Ubuntu 16.04 LTS & 17.04 LTS/x64 and Forensic Live CDs.
§ The SSDs were formatted with GPT or MBR partition types.
‖ Tested and verified with DEFT Zero 2017.1, CAINE 8.0, ParrotSec 3.6.

References

[1] M. Reith, C. Carr, G. Gunsch, An examination of digital forensic models, International Journal of Digital Evidence 1 (2002) 1–12.
[2] R. S. Ieong, Forza–digital forensics investigation framework that incorporate legal issues, Digital Investigation 3 (2006) 29–36.
[3] G. B. Bell, R. Boddington, Solid state drives: the beginning of the end for current practice in year forensic recovery?, The journal of Digital Forensics, Security and Law: JDFSL 5 (2010) 5.
[4] B. Nikkel, Practical forensic imaging, No Starch Press, 2016.
[5] A. Nisbet, S. Lawrence, M. Ruff, A forensic analysis and comparison of solid state drive data retention with trim enabled file systems, digital investigation (2013).
[6] C. King, T. Vidas, Empirical analysis of solid state disk data retention when used with contemporary operating systems, year investigation 8 (2011) S111–S117.
[7] J. Kornblum, Preservation of fragile digital evidence by first responders, in: Digital Forensics Research Workshop (DFRWS), 2002, pp. 1–11.
[8] L. Chen, G. Wang, An efficient piecewise hashing method for computer forensics, in: Knowledge Discovery and Data Mining, 2008. WKDD 2008. First International Workshop on, IEEE, 2008, pp. 635–638.
[9] L. Johnson, Computer incident response and forensics team management: Conducting a successful incident response, Newnes, 2013.
[10] S.-J. Wang, Measures of retaining digital evidence to prosecute computerbased cyber-crimes, Computer Standards & Interfaces 29 (2007) 216–223.
[11] J. Richter, N. Kuntze, C. Rudolph, Security digital evidence, in: Systematic Approaches to Digital Forensic Engineering (SADFE), 2010 Fifth IEEE International Workshop on, IEEE, 2010, pp. 119–130.
[12] R. Leigland, A. W. Krings, A formalization of digital forensics, International Journal of Digital Evidence 3 (2004) 1–32.
[13] P. Polstra, Linux Forensics with Python and shell scripting, Pentester Academy, 2015.
[14] Y. Guo, J. Slay, J. Beckett, Validation and verification of computer forensic software toolssearching function, digital investigation 6 (2009) S12–S22.
[15] ISO 27037:2016(E), ISO/IEC 27037:2016 – Information technology – Security techniques – Guidelines for identification, collection, acquisition and preservation of year evidence, Standard, International Organization for Standardization, 2016.

About The Author

Josué Ferreira comes from an IT background and holds a BSc (Hons) first class in Computer Forensics from Middlesex University, UK. After graduation, he focused his attention and research interests in finding or improving ways to acquire, preserve and analyse digital evidence. He can be contacted by email: josue.ferreira@live.co.uk.

5 thoughts on “Forensic Acquisition Of Solid State Drives With Open Source Tools”

  1. A few comments on the article,

    – Garbage collection and Trim are different things. Garbage collection can happen in the background, even if the drive isn’t mounted. Typically while the drive is idle. So any test method needs to be very precise about the scenario. e.g. how long in time was it since the drive was used, before the drive was removed. This isn’t clear from the article. Usually trim is quick, meaning it might have already occurred before the drive was removed.

    – Trim commands are sent when a delete occurs in the file system. If you are doing forensics then you aren’t doing deletions and thus Trim is never sent. You seem to have never done the baseline experiment, so we don’t really know if the whole not mounting thing has any effect at all.

    – Only old SSDs were used in the test. They seems to be all low capacity models from around 5 years ago. Which is a long time in terms of SSDs. No M2 drive were used either.

    – No mention of the file systems being used was included. i.e. some of the results might be explained by the fact that Linux doesn’t support the NTFS files systems. i.e. The O/S can’t write to a file system it doesn’t support. Does the file system in use effect the result? Not including any detail about the partitioning setup, the file system(s) in use and the data used makes the whole study unreproducible.

    – Hashing is a very poor method of detecting *what* changed on a hard drive. As you observed different hash values, you should have done a byte for byte comparison to see where the changes occurred. Maybe the changes were in the EXT4 superblock, which include the last mount time & mount count.

    • David Wren, thank you for your comments.

      This was my first research project on my own.

      I understand and agree with your comments on the garbage collection and the trim function.

      After the files were deleted from the drive, I unmounted the drives manually and hashed the SSDs.
      I used the first hash as a baseline. Imaged each SSD with DD and hashed the image and the hash produced matched the original hash.

      With the amount always off, I plugged and unplugges the SSDs quickly several times, with automount on this is enough to cause changes on the drive, and the hash values always matched the original hash value of each SSD.

      I left some of the SSDs connected for days and no changes were verified.

      Each experiment was repeated using 2 laptops and two desktops.

      In regards to the SSDs used for the experiments, those were the only SSDs I managed to get.

      The experience were conducted using FAT, NTFS and Ext4 file systems and the results were consistent.

      I conducted the experiments for 3 months and the experimental framework is described in the paper.

      The experiments using different operating systems Windows 7 and 10 and ubuntu 14 and 16 and fedora 25 to 27 were also conducted and the results were also consistent.

      The baseline experiment would only demonstrate the obvious, plugging or booting a mounted SSD would cause changes to the drive and that we all know.

      I hope the readers will conduct their own experiments and draw their own conclusions.

      I really appreciate you taking the time to write your comments on the article and I will use them to improve my next research projects. Thank you 🙂

      • David Wren brings up some great points. I did similar research 5 years ago. Your work should be updated to reflect current technology ideally. I am guessing your University project budget didn’t allow for this to happen. Shame. Good for you on doing the work and sharing the results all the same. SSD’s we have found provide more deleted file recovery opportunities being imaged backwards. Strange, but true in our study…

Leave a Comment