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

Analysis techniques
Figure 12 shows the flow to analyse hidden data in $DATA attribute of directory.



Figure 12: Flow to analyse hidden data in $DATA attribute of directory
List directory entries information of all directories
./fls -rDf ntfs /case1/image1 | grep 128
Examine the result for $DATA attributes. For example, the "r/r 40-128-3" is a $DATA attribute which might contain hidden data.



Figure 13: Result of running fls command to check for $Data attributes in directories

Check the content of the $DATA attribute
./icat -f ntfs /case1/image1 40-128-3 > /case1/dataindirectory1
file /case1/dataindirectory1
hexedit /case1/dataindirectory1
Analysis techniques used to detect ADS in files also detect ADS in directory at the same time. The process has been explained in the previous section and is not repeated here.

HIDDEN DATA IN $BOOT FILE OR BOOT RECORD
Everything in NTFS is a file includes boot record, which is stored in a metadata file called $Boot. In NTFS, this is the only file with fix location, which always starts at the first cluster of the file system. Windows allocates 16 sectors to this file but in usual only half of these sectors contain non zero bit (Carrier, 2005).
According to the documentation about NTFS at Linux NTFS project (Sourceforge, n.d.), there are certain unused bytes in the boot sector. However, Windows would not mount the file system if there is any none 0 values in these unused bytes (Carrier, 2005). As a result, this cannot be used to hide data.
In $Boot file of NTFS file system, data usually is hid at the bytes allocated for boot code. Boot code is essential for bootable file system to locate needed files to boot up Windows (Carrier, 2005). For non bootable file system, it usually used to store the error message that is displayed if users try to boot from this partition.
The size of data that can be hidden in the boot code is unlimited as suspects can simply allocated more clusters to $DATA attribute of $Boot file to hide data.
Procedure to create test data
1) Run list of $Data attribute of $Boot is modified
2) Last VCN value of $Data attribute of $Boot is modified
3) Real size, allocated size and compressed size of $Data attribute of $Boot is modified
4) Allocation status of the additional clusters allocated to $Boot is set to 1
5) Hidden data is pasted to the selected clusters.

Analysis techniques
Figure 14 show the flow to analyse hidden data in $Boot file and backup boot sector.



Figure 14: Flow to analyse hidden data in $Boot file and backup boot sector
Chkdsk might return error if suspects forget to complete one of the needed step. For example, if any of the first 3 steps is not completed, error message as show in figure 15 will occur. If suspects forget to perform step 4, error message as shown in figure 16 will occur.



Figure 15: Error message displayed when running chkdsk command



Figure 16: Error message displayed when running chkdsk command
Analysis of hidden data in $Boot file should start by comparing boot sector and backup boot sector. Let's assume there are 6136830 sectors in the partition.
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
However, this consistency check would only give indication of file system manipulation if the checksums differ from each other. If they are the same, the possibilities are that suspects copy the modified boot sector to its backup to avoid detection or the file system does not contain hidden data. The extracted content is then analysed with hex editor, foremost and comeforth similar to analysis of hidden data in faked bad clusters. Keyword search can also be performed.

UNCOMMON/ INEFFECTIVE DATA HIDING TECHNIQUES
From the perspective of suspects, a good data hiding techniques in NTFS file system should meet the goals of security and capacity as following (Provos & Honeyman, n.d.).
1) Normal system check with utility such as chkdsk does not return any error
2) Hidden data would not be overwritten or the possibility of data being overwritten is low
3) Normal user would not notice the hidden data
4) The technique can store reasonable amount of hidden data
Table 3 shows some uncommon and ineffective techniques which does not satisfy characteristic discussed above.
Table 3: Description of certain uncommon and ineffective data hiding techniques

Data hiding techniques	Weaknesses
Set the allocation bit of certain unallocated clusters to 1 and hide data in these clusters	Simple chkdsk validation would detect this
Hide data in unallocated clusters	High possibility of hidden data being erased unless certain countermeasures are implemented such as set the hard disk to read only access
Hide data in unallocated MFT entries	High possibility of hidden data being erased unless certain countermeasures are implemented such as set the hard disk to read only access
Unused space in a MFT file record	Hidden data is erased if more attributes is added to the MFT file record or the size of an attribute increases.

However, there are certain environments where these hiding techniques might be effective. Let's take data hiding in unallocated clusters as example. If there is hard disk write protector that protects the hard disk or rootkit installed in the system that will never write to these unallocated location, the hidden data would not be erased. As a result, a through check on the system and the physical environment are important and might give some clue about the data hiding techniques used.

CONSISTENCY CHECK ON NTFS
Certain consistency check should be performed on NTFS before any analysis starts. Chkdsk should be performed and if it returns any error, there might be file system manipulation on it that causes the file system in an unstable state.
Default cluster size of NTFS is depends on the size of file system (Svensson, 2005). Usually a normal user would not modify the default cluster size. However, suspects might modify it so that more hidden data can be stored. For example, the larger the cluster size, the more hidden data can be stored in the file slack of a file. A NTFS with cluster size that does not match its file system size is suspicious.
System should be searched for data hiding tools. Attention should also be paid on both digital and physical files that contain some weird numbers that might be the clusters address where hidden data is stored.

CONCLUSION
In general, analysis of hidden data in NTFS file system is divided into 2 phases. The first phase is to identify whether there is hidden data by searching for anomaly. For example, in the analysis of hidden data in faked bad clusters, it is abnormal to have an operating system to detect bad sectors before a hard disk does. This is suspicious and worth further analysis.
The second phase is to recover the hidden file. Due to hidden data is usually stored in the file system without any structure or metadata, it is hard to recover them. Recovery is particularly challenging if suspects store data in random order and remove the file signature.
There is no specific forensic analysis tool that checks for hidden data in NTFS file system except tools that check for alternate data stream. While the analysis techniques that already discussed might be able to detect/recover the hidden data, it is time consuming without automated tools.
The data hiding techniques that have been discussed in this paper are just a fraction of possible way to hide data. There are always new techniques to hide data and the art of data hiding is depends on suspects' creativity. One of the difficulties of analysing NTFS file system for hidden data is that it is so flexible and can support many options (Carrier, 2005). As a result, there are many possible ways to hide data. In addition, without a published specification, which value combinations are valid and which are not is unknown (Carrier, 2005).

REFERENCE
Carrier B. (2005, March 17). File System Forensic Analysis. Addison Wesley Professional.
Carvey H. (2004a, July 21). Windows Forensics and Incident Recovery. Addison Wesley.
Carvey H. (2004b). Data Hiding on a Live System. Retrieved September 23, 2005 from http://www.blackhat.com/presentations/win-usa-04/bh-win-04-carvey.ppt
Cook R. (2005, September 16). Alternate Data Streams: Threat or Menace? Retrieved September 20, 2005 from http://www.informit.com/articles/printerfriendly.asp?p=413685
Chuvakin A. (2002, March 10). Linux Data Hiding and Recovery. Retrieved September 23, 2005 from http://www.linuxsecurity.com/content/view/117638/49/

Microsoft (n.d.). The NTFS File System. Retrieved September 13, 2005 from Microsoft.com: http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/core/fncc_fil_khzt.asp
Kruse W. G. & Heiser J. G. (2001, September 26). Computer Forensics : Incident Response Essentials. Addison-Wesley Professional
Li K. (2003). A Guide to Programming Intel IA32 PC Architecture. Retrieved September 16, 2005 from http://www.cs.princeton.edu/courses/archive/fall04/cos318/docs/pc-arch.html
Mallery J. R. (2001, July 16). Secure File Deletion, Fact or Fiction? Retrieved September 20, 2004 from http://www.sans.org/rr/papers/27/631.pdf
Means R. L. (2003). Alternate Data Streams: Out of the Shadows and into the Light. Retrieved September 20, 2005 from http://www.giac.com/practical/GCWN/Ryan_Means_GCWN.pdf
Mikhailov D. (n.d.). NTFS file system. Retrieved September 13, 2005 from http://www.digit-life.com/articles/ntfs/
NTI (2004, January 6). File Slack Defined. Retrieved September 20, 2005 from http://www.forensics-intl.com/def6.html
Paladion Network (2004). Incident handling/ Forensic FAQs. Retrieved September 23, 2005 from http://www.paladion.net/papers/ihfaq.htm#hidden_data
Provos N. & Honeyman P. (n.d.). Detecting Steganographic Content on the Internet. Retrieved October 4, 2005 from http://niels.xtdnet.nl/papers/detecting.pdf
sleuth kit.org (n.d.). README. Retrieved September 23, 2005 from http://www.sleuthkit.org/sleuthkit/download.php
Solomon D. A. & Russinovich M. E. (2000, September 1). Inside Microsoft Windows 2000, Third Edition. Microsoft Press
Sourceforge (n.d.). Foremost. Retrieved September 16, 2005 from http://foremost.sourceforge.net/
Sourceforge (n.d.). File - $Boot (7). Retrieved September 22, 2005 from http://linux-ntfs.sourceforge.net/ntfs/files/boot.html
Storagereview (n.d.). Reference Guide - Hard Disk Drives: Reference Guide - Hard Disk Drives. Retrieved September 13, 2005 from http://www.storagereview.com/guide2000/ref/hdd/geom/formatDefect.html
Svensson A (2005, April). Computer Forensics Applied to Windows NTFS Computers. Retrieved September 23, 2005 from http://www.dsv.su.se/research/seclab/pages/pdf-files/2005-x-268.pdf
Zadjmool R. (2004, March 24). Hidden Threat: Alternate Data Streams. Retrieved September 20, 2005 from http://www.windowsecurity.com/articles/Alternate_Data_Streams.html

APPENDIX A: DETAIL PROCESS OF HOW DATA IS HID IN FAKED BAD CLUSTERS
Tool used in this example is Runtime's DiskExplorer for NTFS v2.31. While using this tool to edit the NTFS might seem awkward and too complicated for script kiddies level suspects, it is just a matter of time for a tool that can automate this task to occur. This tool is used here to just to show how NTFS file system can be manipulated to hide data and prepare a test file system for analysis
1) Locate where $DATA of $Bitmap is stored. As shown in Figure 17, it is stored from x0005DA54C and it is allocated 24 clusters. 2) Inspect the clusters that are allocated to $Bitmap.



Figure 17: $DATA attribute of $Bitmap
3) Any cluster that is unallocated can be used. In this example, 12 clusters (from 383624 to 383635) would be marked as bad clusters to store hidden data as shown in figure 18. Calculation of the cluster number represented by a bit in $Bitmap is shown below:
Cluster number = ((A - B) * C * D) + (E * F * D) + (G * D) + H - 1
A = sector address of current sector
B = starting sector for $Data attribute of $Bitmap
C = number of bytes in a sector
D = number of bits per byte
E = number of rows before the targeted bit
F = number of bytes per row
G = number of bytes before the byte for that bit
H = location of the bit in that particular byte. For example, H=1 for 01 and H=4 for 08
For example, calculation of the bit that represents cluster address 383524 in $Bitmap is shown below:
Starting sector for $DATA attribute of $Bitmap: 029FE8D6
This sector: 029FE933
Cluster number = ((029FE933 - 029FE8D6) * 512 * 8) + (21 * 16 * 8) + (1 * 8) + 1 - 1
= 380928 + 2688 + 8
= 383624
4) Set cluster 383624-383635 as bad clusters in the run list of $BAD attribute as shown in figure 19. Note that this is an Intel PC and it uses little-endian-ordering, which put the least significant byte of a number in the first storage byte (Li, 2003). For example, 383624 (05dA88) is stored as 88DA05
5) Modify the size of the $Bad attribute to 0x58
6) Modify the size of the MFT to 0x180



Figure 18: Allocation status of faked bad clusters is set to 1
7) Hide data into that cluster 383624 using the "paste from file command" in DiskExplorer
8) Run chkdsk in Windows XP to ensure there is no structure error happen after modification.
9) The result is tested using Sleuth Kit before and after data is hidden. Before data is hide in the faked bad cluster, run dstat to ensure the target clusters are unallocated and istat to ensure no cluster is assigned to $BadClus. Example:
dstat /dev/sda2 -f ntfs 383624, repeat this for all targeted clusters
istat /dev/sda2 -f ntfs 8
10) After the data is hidden, perform the same commands again to ensure the clusters are allocated to $BadClus properly. Besides dstat and istat command, dcat command is run to check to content of hidden data. It is also recommended to try to extract the hidden clusters with dd command in Linux and try to open the file. Example:
dstat /dev/sda2 -f ntfs 383624, repeat this for all targeted clusters
istat /dev/sda2 -f ntfs 8
dcat /dev/sda2 -af ntfs 383624, repeat this for other clusters
dd if=/dev/sda2 bs=4096 skip=383624 count=12 of=/mnt/usb/recoverfile



Figure 19: Modification on the $Bad attribute of $BadClus file to create faked bad clusters