分析在ntfs文件系统下的数据隐藏(一)

Analysis of hidden data in the NTFS file system

Page: 1/8

Cheong Kai Wee
Edith Cowan University
ckw214@yahoo.com

Abstract
Criminals with sensitive information such as crime records tend to hide/encrypt this information so that even if their computers are collected by police department, there is no evidence that can be used against them. There are many ways data can be hid. The most famous ways are data encryption and steganography. File system, in addition, can also be used to hide data. This paper discusses some of the possible ways to hide data in NTFS file system and analysis techniques that can be applied to detect and recover hidden data. This paper focuses on criminals as the users of data hiding techniques and the main targets that they want to hide data from are forensic analysts. Certain data hiding techniques that can only be used to hide data against normal users such as setting the hidden attribute of a file will not be included.. Keyword
Data hiding, analysis technique, NTFS

INTRODUCTION
This paper discusses some of the methods that can be used to hide data in NTFS and analysis techniques that can be used to detect and recover hidden data. Target readers for this paper are forensic analysts and examiners. Throughout this paper, the phrase "suspect" is used to refer to the owner of digital devices, where analysis is performed to retrieve digital evidence. RunTime's DiskExplorer for NTFS v2.31 is used to create the hidden data manually for testing purpose. The only exception is hidden data for alternate data stream which is created by normal DOS command. Tools that are used to analyse hidden data are Windows XP chkdsk, Sleuth Kit 2.02, Foremost 0.69, comeforth 1.00, dd, hexedit and strings. Test data is created on a machine with Windows XP version 5.1.2600.

BACKGROUND OF NTFS
In NTFS, everything is file. This includes file system metadata about the structure of the file system. MFT (Master File Table) is the heart of NTFS. Every file or directory has at least one entry in MFT (Master File Table). Microsoft calls each entry in MFT as file record and its default size is 1024 bytes (Mikhailov, n.d.). The first 42 bytes is fixed for MFT entry header and the rest of the entry stores attributes, which is small data structure with specific purpose. Example of attributes are $STANDARD_INFORMATION, $FILE_NAME and $DATA (Microsoft, n.d.). The content of an attribute can be either resident or non resident. A resident attribute stores its content in the MFT entry. A non resident attribute stores its content at external clusters. The list of clusters used is stored as cluster run in the run list of an attribute.
Data unit in NTFS is called cluster, which is the smallest disk space allocation unit. Every cluster in NTFS has a LCN (Logical Cluster Number). The cluster number starts with 0 at the first cluster of the file system (Svensson, 2005). Clusters belong to a file are also assigned a VCN (Virtual Cluster Number). For example, a file with 6 clusters will have cluster 1 of the file with VCN 0 and last cluster with VCN 5.



Figure 1: Structure of MFT entry (Carrier, 2005)
Metadata files are files that describe the file system. Example of metadata files are $MFT, $MFTMirr, $LogFile, $Volume, $AttrDef, ., $Bitmap, $Boot, $BadClus, $Secure, $Upcase and $Extend. Table 1 show the description of some of the metadata files.
Table 1: Description of metadata files in NTFS (Solomon & Russinovich, 2000)

Metadata file	Description
$MFT	Store MFT record
$MFTMirr	Contain partial backup of MFT
$LogFile	Transaction logging file
$Volume	Contain volume information such as label, identifier and version
$AttrDef	Attribute definition
.	Root directory of file system
$Bitmap	Contain the allocation status of all clusters
$Boot	Contain the boot record
$BadClus	Mark clusters as bad clusters
$Secure	Contain information about the security and access control information

FAKED BAD CLUSTERS
For old hard disks that do not have the capability to handle errors, operating systems detect and mark sectors/ clusters as damaged. Nowadays, modern hard disks handle bad sectors themselves by remapping bad sectors to spare sectors (storagereview, n.d.). It is unlikely that an operating system would detect bad sectors before hard disk does. Clusters marked as bad may be used to hide data.
In NFTS, bad clusters are marked in metadata file called $BadClus, which is in MFT entry 8. Originally, $BadClus is a sparse file which file size is set to the size of entire file system. When bad clusters are detected, they will be allocated to this file.
The size of data that can be hid with this technique is unlimited. Suspects can simply allocate more clusters to $BadClus and use it to hide data.
Procedure to create test data
1) Clusters are added to the run list of $Bad attribute of $BadClus file
2) The size of $Bad attribute and the size of this MFT file record are modified if necessary
3) Allocation status of clusters used to hide data is set to 1
4) Hidden data is pasted to the clusters
Process of how hidden data is created manually in faked bad clusters is shown in Appendix A.

Sleuth Kit is used to analyse the file system. Throughout this paper, /case1/image1 will be used in examples as the acquired image of NTFS that need to be analysed. Figure 2 shows the flow to analyse hidden data in faked bad sectors.



Figure 2: Flow to analyse hidden data in faked bad clusters
Check for clusters allocated to $Bad attribute of $BadClus.
istat /case1/image1 -f ntfs 8
If there is clusters allocated to $Bad, it must be inspected as modern hard disks usually handle bad sectors themselves. If you have the physical hard disk with you, you can also perform a surface scan to verify whether there are bad sectors on the disk.
Check the content of the clusters with dcat in Sleuth Kit. However, this only reveal hidden data if the data is stored in ASCII encoding. In this example, let's assume cluster 383624-383635 are marked as bad cluster and suspected to contain hidden data.
dcat /case1/image1 -f ntfs 383624 12
For further analysis, extract the clusters and use data craving tools such as foremost and comeforth to recover data.
dd if=/case1/image1 bs=4096 skip=383624 count=12 of=/case1/badclusters
foremost -c /etc/foremost.conf -v -o /forensic/recover /case1/badclusters

This analysis technique works if a suspect stores the files sequentially in the clusters. However, suspects can segment a file and store it in non sequential way or even randomly in clusters (Carvey, 2004b). For example, if a suspect stores a Microsoft Word file with 383629 as starting cluster, moving backward and store the last portion of file in cluster 383624, foremost is unable to recover the file correctly. This technique does not prevent suspects from retrieving the files as they can record the order of clusters when hiding them.
In addition, a suspect may also remove the signature of a file to avoid detection of data craving tools (Carvey, 2004a). Data carving tools such as foremost recover files based on their data structure such as header and footer (sourceforge, n.d.).Without these structures, it is impossible to recover the file. During this research, testing has been carried out to recover files hidden using these techniques in faked bad clusters and results are shown in table 2.
Table 2: Result of hidden data detection/recovery attempts for different hiding techniques

Hidden file	Technique	Result of foremost
A Microsoft document file	Normal, follow the sequence	Success in detect and recover
A Microsoft document file and a html file	Normal, follow the sequence	Success in detect and recover
A Microsoft document file and a html file	Reversed order of clusters	Success in detecting the files but unable to open them or files opened with meaningless data displayed
A Microsoft document file and a jpg file	Header removed	Fail to detect the files

Comeforth, an add-on of Sleuth Kit is more useful in recovering data if a file is not stored in sequence. Comeforth is similar to lazarus, where it divides file into block and run file command on every block (sleuth kit.org, n.d.). Users can then view each block and select blocks to be recovered as a file.
Keyword search can also be performed with hexedit, strings or other tools if part of the content of the hidden file is known.
strings /case1/image1 | grep keyword

VOLUME SLACK AND FILE SYSTEM SLACK
Volume slack is the unused space between the end of file system and end of the partition where the file system resides. File system slack is the unused space in the end of a file system that is not allocated to any cluster. This happens due to the partition size may not be the multiple of the cluster size (Carrier, 2005). For example, there is 10001 sectors in the partition, there first 10000 sectors are allocated to 2500 clusters with the cluster size of 4 sectors and the last sector left becomes file system slack.
The size of hidden data in volume slack is unlimited as suspects can simply change the size of volume slack to hide more data. The data that can be hid in file system slack, however, is depends on size of cluster. For example, for a file system with cluster size of 8 sectors, the maximum size of file system slack is 7 sectors.
Procedure to create test data
1) Sectors allocated to file system is modified in the $Boot file
2) Bits used for setting the allocation status of clusters in $Bitmap is reduced
3) Data is pasted to the volume slack and file system slack

Figure 3 shows the flow to analyse hidden data in volume slack.



Figure 3: Flow to analyse hidden data in volume slack
Analysis should start with chkdsk command in Windows to check the file system. If suspects manipulate the file system manually and forget any of the needed steps, errors might be generated by chkdsk and give some indication about hidden data. For example, it is discovered that if suspects simply change the number of sectors allocated to the file system in the $Boot file without appropriate change in the $Bitmap file, message "Correcting errors in the Volume Bitmap" would appear by chkdsk command.
Check the number of sectors allocated to the partition with mmls command. In this example, mmls command returns 6136830 as total sectors in /case1/wholeimage.
./mmls /case1/wholeimage -t dos
Check the number of sectors allocated to NTFS file system in that partition with fsstat command. In this example, fsstat shows 6136782 sectors are allocated to the file system.
./fsstat /case1/image1 -f ntfs
Create md5 checksum of boot sector and backup boot sector
dd if=/case1/image1 bs=512 count=1 skip=6136829 of=/case1/backupbootsector
dd if=/case1/image1 bs=512 count=1 of=/case1/bootsector
md5sum /case1/backupbootsector
md5sum /case1/bootsector

For Windows NT 4.0, 2000 and XP, if there are A sectors in the partition, A-1 sectors is allocated to NTFS and the last sector is used to store the backup boot sector (Carrier, 2005). As a result, it is uncommon to have more than 1 sector of volume slack or the boot sector is not identical with the backup boot sector. If any of these situations happen, further analysis must be carried out on the volume slack.
Due to volume slack has no cluster number, dcat cannot be used to view its content. Dd can be used to extract volume slack and hex editor used to view it content. The volume slack is then analysed with foremost and comeforth similar to analysis of faked bad sector. Keyword search can also be performed.
dd if=/case1/image1 bs=512 count=48 skip=6136782 of=/case1/volumeslack
hexedit /case1/volumeslack
foremost -c /etc/foremost.conf -v -o /forensic/recover2 /case1/volumeslack
Figure 4 shows the flow to analyse hidden data in file system slack



Figure 4: Flow to analyse hidden data in file system slack
Check the number of sectors allocated to the NTFS file system (A) and number of sectors per cluster (B)
./fsstat /case1/image1 -f ntfs
Calculate A/B. if the remainder is 0, there is no file system slack. Else, analyse the file system slack in the similar way to analysis of volume slack.