Hiding Data from Forensic Imagers – Using the Service Area of a Hard Disk Drive

I. Summary

Kaspersky Labs® recently released their research regarding the compromise of hard disk drive firmware. This has confirmed our long standing suspicion that data hiding techniques using a hard disk drives Service Area could be used for malicious purposes.  Kaspersky Labs® identified a group of attackers, dubbed the Equation Group, reportedly having close ties to the groups responsible for
writing Stuxnet and Flame.  The “Equation Group” is reported to have run the most advanced hacking operation ever uncovered (Goodin 2015).  This group is reported to have used firmware update techniques to create a “secret storage vault” to store data in the firmware of the compromised hard drives. Thus allowing the storage of data including the malware itself allowing the ability to survive standard format and wiping operations.   Our previous paper, Forensic Imaging of Hard Disk Drives – What we thought we knew, describes the relatively unknown hard disk drive Service Area and its firmware modules. The firmware on a standard hard disk drive is located in two locations: 1) the ROM chip located on the PCB, and 2) a physical location on the platters of the hard disk as we describe.  What is not revealed, as of the initial reports from Kaspersky Labs® is the exact location of the firmware hack, the ROM or the Service Area modules.
In Goodin’s article he made the statement “While it’s simple for end users to re-flash their hard drives using executable files provided by manufacturers, it’s just about impossible for an outsider to reverse engineer a hard drive, read the existing firmware, and create malicious versions.”  We do not want to downplay the complexity of this attack, however, we would like to demonstrate in this paper the fact that there are multiple commercial tools available on the market that provide the functionality needed to easily read from and write to a hard drives Service Area.  The practice of manipulating firmware in both the ROM and the Service Area is a daily occurrence for professional data recovery companies.  In this paper, we will detail how data other than firmware can be added to a firmware module in the Service Area and hidden from traditional forensic imaging.

II. Background

As forensic examiners we have all known or heard about “Hiding” data in blocks marked “BAD” this is nothing new. But what if we could hide data in the “Reserved” area blocks? This area is not a user accessible area and is not imaged by the normal imaging tools. What about hiding data in the space reserved for the hard disk drive’s Service Area (also referred to as the System Area)? We have previously written about the Service Area in the white paper “Forensic Imaging of Hard Disk-What we thought we knew” (Shipley and Door 2012). The research in this paper has been ongoing for several years and is an outgrowth of work we did for the U.S. DOJ National Institute of Justice. What we are discussing here regarding the Service Area is fairly commonly known in the data recovery industry, but not in the digital forensics field.  What we hope to provide the digital forensics field is an understanding of a known vulnerability to our forensic processes that to date has been undocumented in the field.
The Service Area of a hard disk drive is used to store manufacturer data such as servo information, firmware, and the drive defects tables such as the P and G-Lists and translation table. The hard disk drive “SMART” data we are familiar with is also stored here.  The Service Area will contain many files referred to as “modules”.  With the knowledge that this space exists on a hard disk drive, and that we can access the space, the question is can we write something other than the manufacturer specific firmware modules to this space?
Well, the answer is “it’s possible”. In practice it’s not as simple as clicking “Save” in Windows. The Service Area modules often have checksums and pre-determined physical space limitations that need to be overcome. However, working within these limitations, data can be added to the Service Area.  The problem is that this data is unseen by the current forensic imaging tools and uncollected in any current form of basic computer forensic review. This data area of the hard disk drives has had no review from the digital forensics community. We hope that with this paper and our ongoing research, we will add new and revealing information to the digital forensics field.
This paper is only intended to be a proof of concept to provide the digital forensic community with the knowledge of certain tool’s ability to hide data in the Service Area of a hard disk drive. The technique described in this paper makes the data added to the Service Area of a hard disk drive invisible to the current forensic imaging tools.  This in no way diminishes what the imagers do in conjunction with imaging the Logical Block Address space of a hard disk drive. It only proves that there are areas on the hard drive that are not addressed by the traditional forensic process and this fact needs to be understood by the industry as a whole.
Some things to consider in the future are the potential for specific malicious abuse of this space by others. This space could not only be exploited by criminals seeking to hide data from law enforcement investigators, but it could also provide an avenue of compromise for hackers that none of the current virus or malware products consider. As we have already seen in articles (Goodin 2015 and Fisher) on the exploitation of hard drive firmware the reality of further abuse is probable.

III. Proposed Methodology

To provide a model for the proof of concept, we developed a process that could be repeated and validated by others in the field given the same tools and similar drives used in the process.
To accomplish the proof of concept, the design of the process included three phases.  The three phases were designed to be a repeatable process and designed to allow replication:

Phase 1	a)         Data will be hidden in the hard drive Service Area b)        Hard disk drive will be wiped.
	A sample file will be hashed and then stored in a module in the hard disk drive’s Service Area.  The hard drive will then be wiped.  The hard drive will then be imaged and hashed.

Phase 2	Attempt to find hidden data using traditional forensic methodology.
	The drive will be given to a non-involved digital forensic examiner to image, hash, and examine.  The examiner will attempt to find the Sample Evidence using any of the industry standard computer forensic tool(s).  After the non-involved digital forensic examiner verifies that the sample evidence cannot be found on the drive it will be provided to a third examiner to be extracted.

Phase 3

Data will be extracted by third examiner.

This third examiner will be in possession of tools to allow access to hard drive’s Firmware and the Service Area of the hard disk drive.  The hard disk drive will be imaged and hashed to verify that there have been no changes made to the hard disk drive.  The firmware modules will be extracted from the hard disk drive. The module containing the sample evidence will be reviewed and the sample evidence will be extracted and hashed.

Some might think that this is cumbersome to use three separate examiners to complete the process, but we wanted to show that independently the data could be added, reviewed for the data using normal digital forensic imaging and process and then examined by a third examiner who could then extract the hidden data. This is intended to show that the digital forensic process could be manipulated to send data between two users and not be found. The third examiner could be told the location of the data or not. Extraction of the Service Area data and then carving for the image would find it. Either way, access to the right tools can allow retrieval of the hidden data. Additional hiding techniques could include encrypting the data secreted in the Service Area that could prevent a general scan or carving from finding the data.

IV. Tools used during testing

The following tools were used to conduct the proof of concept outline in the paper. Each was selected for its purpose in the process to aid in the insertion of the data into the Service Area of the hard disk drives used in the examples. These tools are available on the general market and nothing used was proprietarily built for this project. We felt that it was necessary to use commercial off the shelf tools to demonstrate the fact this could be done with relative ease using these tools. The primary tools used in the project included, but others exist that could be used in this process, are:

FTK Imager, by Access Data (www.accessdata.com)	X-ways Forensic tool (www.xways.com)
PC3000 UDMA, by Ace Laboratory’s (www.acelabratory.com)	Free Hex Editor Neo (http://www.hhdsoftware.com)
Atola Insight, by Atola Technologies (www.atola.com)	EnCase, by Guidance Software (www.guidancesoftware.com)

V. Proof of Concept Methodology

We elected to design a method for the proof of concept that could be repeatable by anyone with the listed tools. This is not the only method of potential insertion of data into the Services Area of a hard disk drive, but is one that provides an easily documentable method that can be validated by others in the industry. In Table 1.0 we outline the methodology we used in the design of the project.

Table 1.0 Project Methodology
1.	Select hard disk drive that will allow for the Service Area to be manipulated into allowing data to be added to a module or track
2.	Wipe the LBA space of the hard drive using stand industry tools and hash drive.
3.	Select traceable data file to add to the Service Area and Hash.
4.	Back up Service Area of the selected hard drive.
5.	Examiner 1 using a data recovery tool adds selected data to a Service Area Module of the hard disk drive.
6.	Examiner 2, a non-involved digital forensic examiner, is given the hard drive with instructions to hash the drive and examine the drive for data.
7.	Examiner 2 will provide the hard disk drive to examiner 3 after reporting findings.
8.	Examiner 3 will Hash the hard drive to ensure the drive Hash matches the ones completed by Examiners 1 and 2.
9.	Examiner 3, in possession of applicable data recovery tools to allow access to hard drive firmware, will extract the data placed in the Service Area by Examiner 1 and hash the data file to ensure a match to examiner 1’s data.
10.	The drive can be Hashed again to prove no changes were made to the data area by the process.

VI. HOW WE DID IT, A STEP BY STEP LOOK AT THE PROCESS

Step 1-Hard Drive Used in Testing
As a proof of concept we used an older commonly found Western Digital WD400BB hard disk drive (As we note below this can be done with other hard disk drives).

Table 1. Western Digital Source Drive
Manufacturer	Western Digital
Model	WD400 (3.5 inch)
Firmware	HSCHNTJAH
Size	40 GB (LBA 78165360)
Serial number	WMAJ71426990

Step 2-Wipe the LBA Space of the test hard drive
The source hard disk drive used in the test was wiped using the PC3000 wiping functions.  The target hard disk drive was then Hashed using the “Verify Drive/Image” function of FTK Imager v 3 and a Wiebetech write blocker.  The MD5 Hash value of the hard disk drive was:

f9731af00046f8afcdfc29dab1c1f05e

  Step 3- Select traceable data file to add to Service Area and hash
The following image file was selected for its size to allow it to be added to the selected module. Experimentally the file size is small so that we could ensure the insertion into a single module in the Service area of the source hard disk drive:

Table 2. Inserted Image File
File Name	NFDRTC Logo.bmp
Size	35kb
MD5 Hash Value	4de173b217e46e1ae7eaf52e9c9b9485

Step 4- Examiner 1 -Back up Service Area of the selected hard disk drive.
Using the PC-3000, by Ace laboratories, we backed up the Service Area of the source hard disk drive. This is done through the software by connecting the hard disk drive to the PC3000 internal card. We started the PC3000 software, provided power to the hard disk drive through the PC3000 and ran the auto identify button. Once the hard disk drive was identified we entered the hard drive specific screen that will allow for the backing up of the Service Area of the hard disk drive.
Step 5- Examiner 1 using data recovery tools adds selected data to a Service Area Module of the hard disk drive.

Figure 1 – Screen shot of WD400BB modules view in PC3000
Once the Service Area was backed-up, we could then insert the data from the image file into the selected module. The module used in this proof of concept was called “60”. This module was identified for use in the project due to its size and relative insignificance to the operation of the hard disk drive.
Add data to selected module in the hard disk drive Service Area.
The saved module “60” was opened with the PC3000 Hex Editor. This allowed access to the hexadecimal view of the data module.

Figure 2 – Hex view of Module 60 with Image file inserted
The image file also opened in the hex editor and the data was copied and pasted into the selected module 60. The image data was added after the Modules header and the modules data area. The modified module was then saved.
Using the PC3000 PCI, the module existing module was opened in the “View” mode. The modified module was uploaded to the hard disk drive and was written to the hard disk drives Service Area (these are normal functions of the PC3000 usually intended for module repair of damaged hard disk drives). In the PC3000 module view the checksum was re-calculated for the new modified module, and was written to the hard disk drive. The rewriting of the checksum for the module identifies the module as working correctly.

Figure 3 – Module 60 Header
The hard disk drive was shut down and then removed from the PC3000.
Step 6- Examiner 2, a non-involved digital forensic examiner, was given the hard drive with instructions to hash the drive and examine the drive for data.
The hard disk drive was provided to an uninvolved computer forensic examiner. The instructions provided to the examiner were to image the hard disk drive using industry standard tools and process of their choice. They were to obtain a hash value for the hard disk drive and determine if any images existed on the hard disk drive. The examiner was provided with a digital copy of the concealed image file, along with its hash value, and told it was hidden on the hard disk drive.
The MD5 Hash value of the hard disk drive as identified by the examiner was:

f9731af00046f8afcdfc29dab1c1f05e

The results for Examiner 2 were that the Hash value Examiner 2 obtained for the hard disk drive matched the Hash value made after inserting the image file in the Service Area. The Examiner 2 found no data on the hard disk drive or an image matching the hash of the concealed image (Examiner 2 did note the hard disk drive was wiped). Examiner 2 used X-ways Forensics to examine the hard disk drive (Authors Note: Any of the conventional digital forensics tools would have had the same results).
Step 7 – Examiner 2 provided the hard disk drive to examiner 3 after reporting findings.
The drive was then turned over to the second author as the third examiner.
Step 8 – Examiner 3 Hashed the hard drive using EnCase Forensic Software to ensure the hard disk drive Hash matches the ones completed by Examiners 1 and 2.
The MD5 Hash value of the hard disk drive as identified by Examiner 3 as:

f9731af00046f8afcdfc29dab1c1f05e

Table 3. EnCase Forensic Image Information
Name	SA TEST 1
Examiner Name	Bryan Door
Label	WDC WD40
Model	0BB-22HEA1
Serial Number	WD-WMAJ71426990
File Integrity	Completely Verified, 0 Errors
Acquisition MD5	f9731af00046f8afcdfc29dab1c1f05e

This Hash calculated by EnCase matched the previous hash values obtained by Examiner 1 and Examiner 2 with other Hashing tools.
Step 9 – Examiner 3, in possession of applicable data recovery tools to allow access to hard drive firmware, will extract the data placed in the Service Area by Examiner 1 and hash the data file to ensure a match to examiner 1’s data.
Using the Atola Insight data recovery tool, the source hard disk drive’s Service Area Modules were backed up. The module containing the image file was extracted from the backed up modules folder. The concealed file was extracted from the module “60” using a Hex Editor and saved as an image file. Examiner 3 Hashed the image and matched his hash to the original file Hash obtained prior to insertion in the Service Area module.

Figure 4 – Atola Insight firmware backup and Module 60 content

The image file was extracted from firmware module 60 using a standard Hex Editor.  The data copied from module 60 was pasted into a new file within the Hex Editor program and named test.bmp.

Figure 5 – Hex Editor used to extract the image file from module 60

The newly created file named test.bmp was added to EnCase and hashed.  The MD5 Hash value of the inserted image file as identified by the Examiner 3 was:

4de173b217e46e1ae7eaf52e9c9b9485

Figure 6 – EnCase Forensic Tool identifying Image in Extracted Service Area Data

Step 10 – The drive was Hashed again to prove no changes were made to the data area by the process.
 The hard drive was Hashed using FTK Imager v 3.  The MD5 Hash value of hard disk drive was:

f9731af00046f8afcdfc29dab1c1f05e

VII. ADDITIONAL FUTURE RESEARCH

 Upon completion of the initial proof of concept, the authors did not want to leave this project to a single hard disk drive as the sole basis for the paper. We reviewed the service area of numerous hard disk drives and with a small amount of investigation into unnecessary modules we were able to add data (text and small image files) to a variety of hard drives. This ability to add data to individual hard disk drives Service Area ran across multiple manufacturers and drive models. Data was added to 2.5” and 3.5” drive’s, and PATA and SATA drives (Author Note: No attempt was made at this time to add data to SCSI or SAS drives but the principle is the same).
Future research needs include:  1) More examination of the Hard Disk Drive Service Area to determine the implications this area has on forensic investigations and it’s ability to store data normally unseen by digital forensic examiners 2) Detailed documentation of Hard Disk Drives Service Area modules needs to be conducted and 3) Exploration of the ability to store and retrieve data in the service area from a live operating system.

VIII. CONCLUSION

This proof of concept was intended to provide the digital forensic examiner with information not previously written about or discussed elsewhere.  We hope that this proof of concept brings to light more information regarding an area of hard disk drives that is not well understood by the general digital forensic community and requires further research. It was also intended to prove the limitations of current Forensic Imaging tools and how we as digital forensic examiners need to consider potential new areas of examination when dealing with hard disk drives.
The reader also needs to be aware that the current breed of Forensic Imagers was never designed to address the data in the Service Area of a hard disk drive. Accessing the firmware and modules of a hard disk drive, which contain programs and configuration settings needed by the drive to operate, can only be done currently by a very small number of tools. None of these tools are standard tools for the digital forensic field.
The take away from this paper is the knowledge that what we thought about forensic imaging is different from the actual mechanical operation of the hard disk drives. Forensic examiners need to be aware of the potential for data to be hidden in these generally inaccessible areas of the hard disk drive.

Source   https://articles.forensicfocus.com/2016/07/22/hiding-data-from-forensic-imagers-using-the-service-area-of-a-hard-disk-drive/

IX. REFERENCES

Shipley, T. & Door, B. (2012) Forensic Imaging of Hard Disk Drives – What we thought we knew, https://articles.forensicfocus.com/2012/01/27/forensic-imaging-of-hard-disk-drives-what-we-thought-we-knew-2/
Fisher, Dennis  (2015) The recent articles Massive, Decades-Long Cyberespionage Framework Uncovered,http://threatpost.com/massive-decades-long-cyberespionage-framework-uncovered/111080
Goodin, Dan (2015) How “omnipotent” hackers tied to NSA hid for 14 years—and were found at last, http://arstechnica.com/security/2015/02/how-omnipotent-hackers-tied-to-the-nsa-hid-for-14-years-and-were-found-at-last/
www.bit-chasers.com   and  www.cadatarecovery.com, California Data Recovery
www.greatbasindatarecovery.com, Great Basin Data Recovery
www.nfdrtc.net, The National Forensic Data Recovery Training Center