# A Digital Body Farm for Collecting Deleted File Decay Data

Omoche Cheche Agada, Ibifubara Iganibo, James Jones, Kevin Fairbanks

► To cite this version:

Omoche Cheche Agada, Ibifubara Iganibo, James Jones, Kevin Fairbanks. A Digital Body Farm for Collecting Deleted File Decay Data. 18th IFIP International Conference on Digital Forensics (DigitalForensics), Jan 2022, Virtual, United States. pp.3-20, 10.1007/978-3-031-10078-9_1 . hal-05315734

HAL Id: hal-05315734

https://inria.hal.science/hal-05315734v1

Submitted on 15 Oct 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
<figure><img src="image_2.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
# Chapter 1

## A DIGITAL BODY FARM FOR
COLLECTING DELETED FILE
DECAY DATA

Omoche Cheche Agada, Ibifubara Iganibo, James Jones and Kevin Fairbanks

**Abstract** Recovering deleted data can be a time-consuming task during digital forensic investigations. As tedious as the task is, it may not produce useful results. New files written to locations containing previously-deleted file data may render some or even all of the deleted file unrecoverable. Insights into the factors that influence deleted file decay are required to enable digital forensic professionals to determine if attempting file recovery is a wise use of time. Significant research efforts have focused on deleted file decay, but gaps in knowledge still exist. This chapter discusses an attempt at collecting data to help discover how deleted file content decays over time in computing systems running the Microsoft New Technology Filesystem (NTFS). In particular, it describes the implementation of a digital body farm that uses differential analysis to monitor and record patterns of decay as deleted data are erased or overwritten on secondary storage media attached to a live system. The collection of realistic file decay data and relevant system parameters can be used to create a model that provides useful insights into the deleted file decay process.

**Keywords:** File decay data, digital body farm, data persistence, decay patterns

### 1. Introduction

In forensic anthropology and related disciplines, a body farm is described as a facility that is dedicated to the study of the decomposition of human remains [28]. In a body farm, human remains are subjected to various conditions in a controlled environment in order to observe and understand the process of decay. Knowledge from such endeavors has been applied in several disciplines, including law enforcement inves-
tigations and forensic pathology. Experts in these disciplines are able to reason about human remains and paint an accurate or near-accurate picture about the circumstances surrounding the human remains, including body identification, time of death and cause of death. Numerous homicide cases have been solved by the diligent application of procedures developed after careful studies of the decay process of human remains.

During an investigation, a digital forensic professional may be tasked with unravelling the mystery surrounding data that may have been deleted deliberately to hide criminal activity. In such a situation, the professional attempts to recover the deleted files as evidence of wrongdoing. In other cases, data may have been deleted during the normal course of business or personal activities without malicious intent. In the two scenarios, attempts are made to recover deleted data to prosecute or exonerate an individual in civil or criminal proceedings. Depending on the circumstances surrounding the deletion process and the associated system, it may or may not be possible to recover deleted data. Deleted files decay just like human remains, but unlike the decay of human remains, deleted file decay is not a well-studied topic [7, 12]. This chapter describes the implementation of a digital body farm, a suite of applications that use differential analysis to monitor and record patterns of decay as file content is overwritten on secondary storage media.

## 2. Background

Estimating the rate at which deleted files decay in digital media has always been of interest in digital forensic investigations. Understanding how file contents decay and the factors that affect the process are useful in making decisions about artifact recovery. They are also important in determining if a file was deleted during the normal course of computing activities or deliberately with malicious intent [12]. This research has sought to identify patterns pertaining to deleted file decay in computing systems that use the Microsoft New Technology Filesystem (NTFS).

When a file is deleted, the associated clusters are deallocated by the filesystem, but the data content remains intact on storage media. The data is, therefore, recoverable until it is erased by internal mechanisms of the storage device or is overwritten by the allocation of newly-created or existing data to the same storage area by the filesystem [3, 4].

Erasing or overwriting the memory blocks associated with a deleted file is referred to as decay in this context. Contrary to conventional understanding, when a computer file is deleted, it does not automatically cease to exist in the storage device. Instead, it is marked as deleted and the space it occupies on the drive is freed up to hold new files [14].
Although the filesystem designates the space as “free space,” it still
holds the data content of the deleted file. The data content persists
until the space is allocated to a different file or the space is reclaimed
by drive housekeeping activities. After this occurs, the file is partially
or completely overwritten.

While the mechanisms that cause deleted file content decay are well known, the actual file decay behavior and patterns are not well understood, and it is difficult to predict with certainty if a deleted file can be recovered. Indeed, deleted file content recovery remains a hit or miss activity. No generalizable theory or even empirical data exist that can fully explain how and why deleted data may or may not persist [7, 12]. The rate at which data decays after deletion has not been quantified and, therefore, the expected success of recovery efforts is largely unknown. A methodology is needed for collecting and analyzing data in order to identify digital artifact decay patterns upon file deletion. The goal of this research is to develop a methodology and a validated tool for collecting data as deleted file content is erased or overwritten in digital storage devices.

3. Related Work

Artifact decay and artifact persistence are closely related concepts
in the digital forensics literature. The concepts are, in fact, mutually
exclusive, like the outcome of a coin toss where the presence of one
outcome necessarily implies the absence of the other. Researchers tend
to use the terms somewhat interchangeably because they are determined
by the same underlying factors. For example, some authors focus on
decay [8, 11, 14] whereas others consider persistence [7, 12]. Depending
on the artifact in question, the presence or absence of certain factors in
a computing system determine if and how the artifact decays or persists.

Fairbanks and Garfinkel [8] were the first to articulate the factors
that determine decay – allocation status, reuse policy, media type, data
type, media degradation and media errors. Other factors include filesystem
design, fragmentation, pre-allocation strategies, filesystem size/utilization/age,
drive usage patterns and implementation errors. Jones et al. [14] established that the sizes of deleted and newly-created files,
overwriting frequency and sector/cluster sizes are significant to decay or
persistence. Fairbanks [7] defines persistence as a property that depends
on many factors, including the allocation status of the data in question.

Garfinkel et al. [9] formalized the concept of differential forensic analysis and demonstrated its application in multiple forensic analysis contexts. Differential forensic analysis considers the differences between a
pair of forensic artifacts. Jones [10] describes differential analysis as a data science tool that can be applied to a variety of cyber security and digital forensics problems. Laamanen and Nelson [15] have used it to create a record of system states called diskprints. Jones et al. [13] have used it to construct forensic artifact catalogs. Nelson [23] has employed differential analysis to extract software signatures from the Windows Registry. In contrast, the research described in this chapter uses differential analysis to monitor changes in individual drive sectors associated with a deleted file, indicating that the sectors have been erased or overwritten.

Jones and Khan [12] studied deleted file persistence by applying differential analysis to multiple drive images from a single computer. Each drive image represented a snapshot of the disk drive after a predetermined set of activities took place. The research described in this chapter monitors the decay process in running systems instead of drive images. Measuring data decay in running systems provides an opportunity to observe the effects of variation in computing environments and the factors that affect the decay process. This also ensures that the activities that result in data deletion and subsequent data decay are not predetermined. The goal is to study a process that is as close as possible to real-world situations.

The introduction of solid-state drives (SSDs) as an alternative to hard disk drives (HDDs) has changed how digital forensic professionals and researchers view data decay and data recovery. Solid-state drives have overtaken hard disk drives as the storage media of choice in personal computers, although server and storage farms still make heavy use of hard disk drives primarily due to their lower cost [6]. While the two types of media are alike in many respects and serve the same basic purpose, their internal mechanisms and capabilities are very different. As a result, the factors articulated in [8] as data decay catalysts may affect file decay differently for solid-state drives as opposed to hard disk drives. The important, albeit controversial, features related to data decay on solid-state drives are garbage collection, TRIM commands and wear leveling. While some researchers opine that these features have no significant impact on digital forensic data recovery procedures [27], others believe their combined effects have changed the practice forever [24]. The issue of whether solid-state drives have changed the practice of digital forensics recovery procedures is an ongoing conversation. This work is intended to help advance the conversation.
<figure><img src="image_3.png" /><figcaption>Figure 1. Minifilters managed by the filter manager [29].</figcaption></figure>

# 4. Digital Body Farm Methodology

The digital body farm developed in this research is essentially a data collection and monitoring tool. It comprises multiple components, a filesystem filter driver, a Windows service application, a database and a script.

## 4.1 Digital Body Farm Components

At the heart of the digital body farm is a filesystem filter driver (minifilter or minifilter driver). The minifilter driver is a kernel mode application that intercepts and handles input/output requests targeted at the filesystem. The minifilter attaches to a legacy filter driver called the filter manager [21]. The filter manager is provided by default with a Windows installation and becomes active when it detects an attached minifilter driver.

The filter manager is designed to manage multiple minifilter drivers concurrently (Figure 1). An input/output request could be a request from an application to create, read, write or delete a file. When an input/output request is made by a user mode application, the request passes through a series of application programming interfaces (APIs) before arriving at the input/output manager in kernel space. The input/output manager creates an input/output request packet (IRP) and passes it to the filter manager. The filter manager calls an attached minifilter to deal with the request as appropriate. A filesystem filter driver does not handle system calls; instead, it intercepts system calls that trigger the execution of specific functions. It is the responsibility of the filesystem to see that the call is eventually executed. However, minifilters can manipulate or terminate calls before they reach the filesystem and prevent them from being executed [2, 16, 25].
To reduce the burden on filter driver developers, Microsoft provides driver samples that help speed up the development process [20]. The filesystem filter driver used in this work is called the delete filesystem minifilter driver. The original design, as provided by Microsoft, intercepts delete calls and extracts basic information such as the complete file path, file size and system call time. Several modifications were made to the delete filesystem minifilter driver obtained from Microsoft to augment its functions, which are very basic and insufficient for this research effort.

Another component of the digital body farm is the Windows service application, also known as a Windows service. A Windows service provides additional capability to an executable application. It enables the application to become a long-running executable that can run in its own Windows session [19]. The application runs in the background and does not require user input. Once started, it runs continuously and restarts automatically after a system reboot. Since the application does not display an interface, it does not directly interfere with the user's ability to use the system for other purposes. The application can be paused, stopped or restarted as needed. Unlike the minifilter, the Windows service runs in the user mode. It also runs in the listening mode, receiving and processing data from the minifilter. As such, it services the minifilter as well as the database component of the digital body farm.

The file data extracted by the minifilter is passed to the service application and stored in the database after processing. The database also holds important system information.

The script is the decay detection component of the digital body farm. It uses information from the database to check the data content of the deleted files on the drive. It updates the database whenever there are changes to the sector content of a deleted file.

## 4.2 Digital Body Farm Process

Figure 2 shows a graphical representation of the digital body farm process. When a file is deleted, the minifilter intercepts the delete system call in kernel space and extracts data about the file to be deleted before the delete call proceeds. It is important to intercept the delete system call before it is executed. This is because, once execution completes, it becomes difficult if not impossible to obtain file information. The extracted data, which includes the logical addresses (offsets) of the sectors occupied by the file on the drive, is passed on to the Windows service in user space along with the name and complete file path. Using the sector offsets received from the minifilter, the service application
<figure><img src="image_4.png" /><figcaption>Figure 2. Digital body farm process.</figcaption></figure>

computes the cryptographic hash values of the contents of the sectors associated with the deleted file. The hash values are stored in a database along with sector addresses and other data extracted from the file by the minifilter.

Although the file is deleted at the operating system and filesystem levels and the clusters are deallocated, the data content is still intact in the physical layer (on the drive). The content remains intact until it is partially or completely erased or overwritten. The script that checks if the sector content has changed is scheduled to run at a specified time each day. It applies differential analysis to record sector-level changes to the content of a previously-deleted file. Whenever the script executes, it uses sector addresses in the database to determine the locations of the file content on the drive. New hash values are computed for the current content of the sectors on the drive and are compared against the hash values of the corresponding sectors stored in the database. A match indicates that a sector is intact whereas a mismatch indicates that the sector has been erased or overwritten. This is used to measure the decay of the file content. The process continues until all the sectors associated with the file are completely overwritten or until a specified time has
elapsed. Data about the decay – which has no actual file content – is
collected and analyzed.

**5. Digital Body Farm Implementation**

This section describes the implementation of the principal components
of the digital body farm and discusses the limitations of the implemen-
tation.

**5.1 Delete Filesystem Filter Driver**

The delete minifilter (`delete.sys`) is implemented in C++. It registers itself with the filter manager as a filesystem filter driver upon installation. When the minifilter detects a delete system call targeted at a file, it intercepts the call, creates a hard link to the file, queries the filesystem for the file sector layout and notifies the Windows service about the deletion. The notification message includes the file path, hard link path and sector map.

The Windows service uses the information to compute the crypto-
graphic hashes of the file sectors. MD5 was employed in this work, but
any hashing algorithm (SHA-1, SHA-256, etc.) could be used. Comput-
ing sector hashes for a file requires time, which becomes more significant
as the file size grows. The filesystem could erase or overwrite file data
before the hash computations are complete, leading to data corruption.
To prevent this from occurring, a hard link [18] is attached to the file,
which gives the filesystem the impression that the file contents are still
active. This ensures that the file data is not freed for deletion until the
sector hashing is complete.

The hard link is deleted after the hash computations are complete or
if it is determined that the file is not of interest and the hash compu-
tations are not necessary. The hard link, which is created in the same
directory as the deleted file, appears as a file with the naming convention
XXX.YYY.XXX is the driver initialization timestamp, which is unique to
each session that begins when the driver is loaded and ends when the
driver is unloaded. YYY is an incremental counter of hard links created
by the driver in a given session.

Figure 3 shows the hard links created in a folder after files have been
deleted. The delete minifilter implementation is available at GitHub [5].
The original version of the delete minifilter provided by Microsoft is also
available at GitHub [17].

Microsoft does not permit the installation of unsigned third-party
drivers on 64-bit versions of the Windows operating system. This is
intended to prevent the installation of rogue or malicious drivers. How-
<figure><img src="image_5.png" /><figcaption>Figure 3. Hard links created after file deletion.</figcaption></figure>

ever, a signed driver neither guarantees bug-free driver code nor prevents system crashes; it only gives some confidence in the driver because it is published by Microsoft. Additionally, it gives no assurance that the code has not been changed since its release [29]. Different procedures apply to signing drivers during development and testing as opposed to signing them for public release [22]. During the development and testing efforts, driver signing was disabled or the system was placed in the test mode.

## 5.2 Windows Service

The Windows service (`bodyfarm.exe`) is a user mode application implemented in C++. It is bundled with and installed with the delete minifilter. The service also creates the database for storing information about deleted files. Once it is installed, the service runs continuously, sending and receiving messages to and from the minifilter using a bidirectional message queue.

The service waits in a queue to obtain notifications about deleted files. A notification includes the file path, hard link path, sector map and other file information. When the notification arrives, the service checks that the file is a user file instead of a system file. It also checks that the file size is within the allowable limits.

If the file type and size meet the criteria, the notification data is placed in the hash computation thread queue. A hash computation thread reads notification data from its queue. For every notification, it starts the hash computation loop in which it directly reads the device block from which the file was deleted using the sector map in the notification. An MD5 hash value is computed and inserted in the database for each file sector. Once this is done, the service notifies the driver so that all the resources allocated to the file can be released and the hard link removed. The service also notifies the driver if a file does not meet the type and size
<table><caption>Table 1. Database tables.</caption><thead><tr><td>Table Name</td><td>Description</td></tr></thead><tbody><tr><td>Decay</td><td>This table records the percentage of each file that remains intact as the file is overwritten. The data is only recorded after the checker script executes and there has been some decay in one or more files (i.e., at least one file sector has been overwritten).</td></tr><tr><td>Disk</td><td>This table holds data about the drives from which a file has been deleted. It does not contain data about every drive in the system. A drive is listed in the table if at least one file on the drive has been deleted.</td></tr><tr><td>Extent</td><td>This table holds data about the cluster runs occupied by a file. It also shows the file fragmentation data.</td></tr><tr><td>File</td><td>This table contains basic file data and the hash computation times for all the sectors of a deleted file.</td></tr><tr><td>PC</td><td>This table contains identifying information about the computing system that executed the program.</td></tr><tr><td>Sector</td><td>This table contains data about all the sectors associated with a file. Also, it contains the sector hash values.</td></tr></tbody></table>

criteria, in which case the allocated resources are also released and the hard link is removed.

The service stores the MD5 hash values of file names in the database instead of the file names themselves. This is done to prevent the release of a file name that may provide personally-identifiable information. After the file names are hashed, only the file extensions remain visible. The service also creates a log of all the deleted files, including system files. The logs, which are intended for troubleshooting, are only maintained locally on the system under study and may contain sensitive information, including personally-identifiable information.

## 5.3 Database

The database (`sector.db`) is a SQLite3 database. It is also bundled with the service and created upon installation of the service and minifilter. The database holds information about all the deleted files and also contains system parameters that provide context for the decay data. The database maintains six tables (`Decay`, `Disk`, `Extent`, `File`, `PC` and `Sector`). Table 1 describes the tables in `sector.db`.
## 5.4 Script

The script (`Body_Farm_Checker.exe`) is implemented in Python 3. It uses the sector addresses stored in the database to check if the file sectors on the drive are intact. The checking process begins upon obtaining all the sectors associated with a file in the database that have not been marked as overwritten. The sectors on the drive are hashed using MD5 and the hash values are compared against the hash values in the database. A match indicates that the data content in the sector is intact whereas a mismatch indicates sector content has been erased or overwritten. The database is updated after it is determined that the sector content has changed; subsequent checks are not performed on such sectors.

The script is compiled using `pyinstaller` version 4.5.1 [26] to produce a Python executable. Creating the executable eliminates the need to install Python on the system before running the script. It also facilitates running the script on a schedule.

The script requires administrative privileges because it accesses sensitive system resources. Not all task schedulers are able to run programs that require elevated privileges; Z-Cron version 5.8 [30], available as freeware for non-commercial use, was employed for this purpose.

## 5.5 Limitations

User files are the focus of forensic investigations. The current study is limited to user files with sizes between 1 KB and 10 MB. The file types and sizes can be adjusted as necessary.

# 6. Validation Tests and Results

This section describes the validation tests and results.

## 6.1 Validation Tests

The goal of the validation tests is to confirm that the data processed and stored by the digital body farm is a true representation of deleted file content on the storage media. The file sector hashes of allocated files were computed using the `C++Validator.exe` program, which was written for this work. The computed hash values were stored in the `SQLite3` database `C++Validator.db` along with sector addresses and file names. The files were subsequently deleted and processed by the digital body farm. The resulting sector hash values were stored in a second database (`sector.db`). The two databases were compared using the `CompareSectors.py` Python script.
<figure><img src="image_6.png" /><figcaption>Figure 4. Comparison of file sector hash values before and after file deletion.</figcaption></figure>

Figure 4 shows the two database files. The C++Validator.db database on the left was created before files were deleted. The sector.db database on the right was created after files were deleted. Twenty random files were used in the validation tests, each with a different size and, therefore, a different number of sectors.

<figure><img src="image_7.png" /><figcaption>Figure 5. Comparison of file sector hash values using compareSector.py.</figcaption></figure>

Figure 5 shows the comparison of 61,645 file sector hash values. Upon executing the compareSector.py script on the two database files, every corresponding sector pair was found to match, indicating that all the sectors were still intact after deletion.

## 6.2 Results

The digital body farm was tested using the four computing systems described in Table 2. A total of 20 files were deleted and monitored
<table><caption>Table 2. Computing systems used in the validation tests.</caption><thead><tr><th>Parameter</th><th>PC 1</th><th>PC 2</th><th>PC 3</th><th>PC 4</th></tr></thead><tbody><tr><td>Make</td><td>HP Laptop</td><td>HP Laptop</td><td>Dell Laptop</td><td>Microsoft Tablet/PC</td></tr><tr><td>Model</td><td>HP 15 Notebook PC</td><td>17t-cn000</td><td>Inspiron 3593</td><td>Surface Pro 4</td></tr><tr><td>Processor</td><td>3rd Gen Intel Core i5 @ 2.60 GHz</td><td>11th Gen Intel Core i5 @ 2.40 GHz</td><td>10th Gen Intel Core i7 @ 1.30 GHz</td><td>6th Gen Intel Core i5 @ 2.40 GHz</td></tr><tr><td>Disk</td><td>1 TB (5,400 rpm SATA) HDD (Seagate/ Samsung)</td><td>1 TB (5,400 rpm SATA) HDD (Western Digital)</td><td>512 GB (M.2 PCIe NVMe) SSD (Kioxia/ Toshiba)</td><td>256 GB (NVMe PCIe Gen3 x4) SSD (Samsung)</td></tr><tr><td>Disk Usage</td><td>4%</td><td>10.6%</td><td>49.4%</td><td>81.9%</td></tr></tbody></table>

for seven days. The methodology does not determine precisely when the sector contents of a deleted file were erased or overwritten, but the frequency with which checks are conducted determines a time range. For example, if the checker script is executed every hour, then a change would have occurred in a 60-minute window. The checks were executed once a day based on a common use case where a forensic investigation is initiated several days after an incident. The tests were conducted multiple times and the results were consistent.

Table 3 provides details of the test results. Figure 6 shows graphical representations of file decay in the four computing systems over the test period. Files monitored on PC 4 were completely overwritten shortly after deletion, typically within minutes. The system incorporated a solid-state drive with very aggressive garbage collection, TRIM commands and wear leveling mechanisms. At 80% capacity utilization, it is no surprise that deleted data was erased almost immediately.

In contrast, PC 3 was slower at erasing files after deletion, although it was only 50% full. Future work will investigate how these drives would behave if their utilizations are reversed. PC 1 and PC 2 are typical hard disk drives, but PC 2 displayed decay behavior similar to a solid-state drive, possibly because its logical to physical address mapping was different from that of PC 1. PC 2 was recognized as a hard disk drive
<table><caption>Table 3. Validation test results.</caption><thead><tr><th rowspan="2">Day</th><th rowspan="2">Parameter</th><th colspan="4">Validation Test Data</th></tr><tr><th>PC 1</th><th>PC 2</th><th>PC 3</th><th>PC 4</th></tr></thead><tbody><tr><td rowspan="7">Day 1</td><td>Computing System</td><td></td><td></td><td></td><td></td></tr><tr><td>Number of Files</td><td>20</td><td>20</td><td>20</td><td>16</td></tr><tr><td>Files with Complete Decay</td><td>2</td><td>19</td><td>10</td><td>16</td></tr><tr><td>Files with Partial Decay</td><td>6</td><td>0</td><td>5</td><td>0</td></tr><tr><td>Files Intact</td><td>12</td><td>1</td><td>5</td><td>0</td></tr><tr><td>% Files with Decay</td><td>40</td><td>95</td><td>75</td><td>100</td></tr><tr><td>% Files with Complete Decay</td><td>10</td><td>95</td><td>50</td><td>100</td></tr><tr><td></td><td>% Files Intact</td><td>60</td><td>5</td><td>25</td><td>0</td></tr><tr><td>Day 2</td><td>% Files Intact</td><td>15</td><td>5</td><td>0</td><td>0</td></tr><tr><td>Day 3</td><td>% Files Intact</td><td>15</td><td>5</td><td>0</td><td>0</td></tr><tr><td>Day 4</td><td>% Files Intact</td><td>10</td><td>5</td><td>0</td><td>0</td></tr><tr><td>Day 5</td><td>% Files Intact</td><td>10</td><td>0</td><td>0</td><td>0</td></tr><tr><td>Day 6</td><td>% Files Intact</td><td>10</td><td>0</td><td>0</td><td>0</td></tr><tr><td>Day 7</td><td>% Files Intact</td><td>10</td><td>0</td><td>0</td><td>0</td></tr></tbody></table>

<figure><img src="image_8.png" /><figcaption>(a) File decay in PC 1 (left) and PC 2 (right).</figcaption></figure>

<figure><img src="image_9.png" /><figcaption>(b) File decay in PC 3 (left) and PC 4 (right).</figcaption></figure>

<caption>Figure 6. Percentages of entire files remaining on the test systems per day.</caption>
by the Windows operating system, but its features appear to be more
like a hybrid drive or solid-state drive.

The results aggregate multiple files from each system, although the
methodology preserves detailed sector-level and file-level decay data for
subsequent analysis. As discussed earlier, data decay is not based only
on drive type. The research did not account for user and non-user ac-
tivities occurring on the computing systems throughout the observation
period. PC 1 preserves more files than the other computing systems, but
the rate of data decay is higher than expected for a 1 TB hard disk drive
with 4% utilization. The rapid data decay could be due to other factors
that were not considered, including the observer effect [1], because, in
the test setup, the application wrote to two log files and a database file
that were resident on the drive. Also, beyond the first day, data de-
cay was measured in terms of the percentage of entire files remaining,
but several partially-decayed files persisted for several days. Such resid-
ual fragments are often critical to investigations and future work will
examine persistent fragments more thoroughly.

7. Conclusions

The digital body farm described in this chapter is designed to help
study the deleted file decay process on storage media in a live computing
system with NTFS. The methodology was validated by conducting tests
on four computing systems. The results demonstrate some consistency
with previous research on the mechanics of deleted file decay.

The next phase of the research is to collect the decay patterns exhib-
ited by individual files as opposed to groups of files. The digital body
farm will also be deployed in non-laboratory environments to ensure that
the data collected is representative of real-world situations. In addition
to deleted file decay data, file ecosystem data such as system config-
uration and usage profile data will be collected to provide context for
the observed decay process. The dataset obtained will be employed to
create a statistical/machine learning model that predicts (in terms of a
confidence interval) the time it would take for a file on digital storage
media to decay completely given the prevailing circumstances.

This is an ongoing study and future work will focus on ensuring data
integrity. To obtain accurate results, it will be necessary to identify and
isolate changes induced by the experimental setup used for observation
and data collection, followed by deep analysis of the collected data. It is
hoped that this research will provide insights into the intent underlying
deletion events that would better inform digital forensic investigations.
The views expressed in this chapter are those of the authors, and do not reflect the official policy or position of MITRE Corporation or U.S. Government. This document has been approved for public release, distribution unlimited (Case #21-4005).

## Acknowledgement

The authors wish to thank Vishal Ghadge, Vladimir Fedorov and John Matthew Thompson for their contributions and insights in developing the programs used in this research.

## References

[1] K. Baclawski, The observer effect, *Proceedings of the IEEE Conference on Cognitive and Computational Aspects of Situation Management*, pp. 83–89, 2018.

[2] H. Balinsky, D. Subiros Perez and S. Simske, System call interception framework for data leak prevention, *Proceedings of the Fifteenth IEEE International Conference on Enterprise Distributed Object Computing*, pp. 139–148, 2011.

[3] S. Bunting, *EnCase Computer Forensics: The Official EnCase Certified Examiner Study Guide*, John Wiley and Sons, Indianapolis, Indiana, 2012.

[4] E. Casey, *Handbook of Digital Forensics and Investigation*, Elsevier, Burlington, Massachusetts, 2010.

[5] chex2chex, Digital-Body-Farm (DBF), GitHub (*www.github.com/chex2chex/Digital-Body-Farm*), 2021.

[6] Datarecovery.com, Will magnetic storage ever become completely obsolete? Edwardsville, Illinois (*www.datarecovery.com/2020/07/will-magnetic-storage-ever-become-completely-obsolete*), July 17, 2020.

[7] K. Fairbanks, A technique for measuring data persistence using the Ext4 filesystem journal, *Proceedings of the Thirty-Ninth Annual IEEE Computer Software and Applications Conference*, vol. 3, pp. 18–23, 2015.

[8] K. Fairbanks and S. Garfinkel, Column: Factors affecting data decay, *Journal of Digital Forensics, Security and Law*, vol. 7(2), article no. 1, 2012.

[9] S. Garfinkel, A. Nelson and J. Young, A general strategy for differential forensic analysis, *Digital Investigation*, vol. 9(S), pp. S50–S59, 2012.
[10] J. Jones, Differential analysis as a data science tool for cyber security, *Proceedings of the International Conference on Advances and Applications of Data Science and Engineering*, pp. 29–32, 2016.

[11] J. Jones, Deleted audio file decay on a digital voice recorder, *Proceedings of the AES International Conference on Audio Forensics*, 2017.

[12] J. Jones and T. Khan, A method and implementation for the empirical study of deleted file persistence in digital devices and media, *Proceedings of the Seventh Annual IEEE Computing and Communication Workshop and Conference*, 2017.

[13] J. Jones, T. Khan, K. Laskey, A. Nelson, M. Laamanen and D. White, Inferring previously uninstalled applications from digital traces, *Proceedings of the Eleventh Annual Conference on Digital Forensics, Security and Law*, pp. 113-130, 2016.

[14] J. Jones, A. Srivastava, J. Mosier, C. Anderson and S. Buenafe, Understanding deleted file decay on removable media using differential analysis, *Proceedings of the Twelfth Annual Conference on Digital Forensics, Security and Law*, pp. 153–165, 2017.

[15] M. Laamanen and A. Nelson, NSRL Next Generation – Diskprinting, presented at *Forensics@NIST 2014* (www.nsrl.nist.gov/Documents/Diskprints.pdf), 2014.

[16] M. Liu, Z. Xue, X. Xu, C. Zhong and J. Chen, Host-based intrusion detection system with system calls: Review and future trends, *ACM Computing Surveys*, vol. 51(5), article no. 98, 2018.

[17] Microsoft, Delete File System Minifilter Driver, GitHub (www.github.com/microsoft/Windows-driver-samples/tree/master/filesys/miniFilter/delete), 2021.

[18] Microsoft, Hard Links and Junctions, Microsoft Technical Documentation, Redmond, Washington (www/docs.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions), January 7, 2021.

[19] Microsoft, Introduction to Windows Service Applications, Microsoft Technical Documentation, Redmond, Washington (www/docs.microsoft.com/en-us/dotnet框架/windows-services/intr oduction-to-windows-service-applications), September 15, 2021.

[20] Microsoft, File System Driver Samples, Microsoft Technical Documentation, Redmond, Washington (www/docs.microsoft.com/en-us/windows-hardware/drivers/samples/file-system-driv er-samples), December 14, 2021.
[21] Microsoft, Filter Manager Concepts, Microsoft Technical Documentation, Redmond, Washington (www/docs.microsoft.com/en-us/windows-hardware/drivers/ifs/filter-manager-concepts), December 14, 2021.

[22] Microsoft, Signing a Driver, Microsoft Technical Documentation, Redmond, Washington (www/docs.microsoft.com/en-us/windows-hardware/drivers/develop/signing-a-driver), December 14, 2021.

[23] A. Nelson, Software Signature Derivation from Sequential Digital Forensic Analysis, Ph.D. Dissertation, Department of Computer Science, University of California Santa Cruz, Santa Cruz, California, 2016.

[24] A. Nisbet and R. Jacob, TRIM, wear leveling and garbage collection on solid state drives: A prediction model for forensic investigators, *Proceedings of the Eighteenth IEEE International Conference on Trust, Security and Privacy in Computing and Communications and Thirteenth IEEE International Conference on Big Data Science and Engineering*, pp. 419-426, 2019.

[25] Open Systems Resources, An Introduction to Standard and Isolation Minifilters, Manchester, New Hampshire (www.osr.com/nt-insider/2017-issue2/introduction-standard-isolation-minifilters), 2020.

[26] Python Software Foundation, pyinstaller 4.10, Fredericksburg, Virginia (www.pypi.org/project/pyinstaller), March 5, 2022.

[27] J. Vieyra, M. Scanlon and N. Le-Khac, Solid state drive forensics: Where do we stand? *Proceedings of the International Conference on Digital Forensics and Cyber Crime*, pp. 149-164, 2018.

[28] Wikipedia Contributors, Body farm, Wikipedia (en.wikipedia.org/wiki/Body_farm), 2022.

[29] P. Yosifovich, *Windows Kernel Programming*, Lean Publishing, Victoria, Canada, 2019.

[30] Z-DBackup Professional Backup Software, Z-Cron Windows Task and Backup Scheduler, Berlin, Germany (www.z-cron.com), 2022.