digital investigation 3 (2006) 211–226

available at www.sciencedirect.com

journal homepage: www.elsevier.com/locate/diin

Data hiding in the NTFS file system

Ewa Huebnera, Derek Bema,*, Cheong Kai Weeb

a
University of Western Sydney, Australia
b
Edith Cowan University, Perth, Western Australia, Australia

article info abstract

Article history: In this paper we examine the methods of hiding data in the NTFS file system. Further we
Received 15 May 2006 discuss the analysis techniques which can be applied to detect and recover data hidden
Revised 20 October 2006 using each of these methods. We focus on sophisticated data hiding where the goal is to
Accepted 23 October 2006 prevent detection by forensic analysis. Obvious data hiding techniques, for example setting
the hidden attribute of a file, will not be included. Hidden data can be further obfuscated by
Keywords: file system independent approaches like data encryption and steganography. This paper is
Data hiding only concerned with the methods which are made possible by the structure of the NTFS file
Analysis techniques system, and with the recovery of hidden data, not its interpretation.
NTFS ª 2006 Elsevier Ltd. All rights reserved.
ADS

1. Introduction
This paper discusses the file system dependent methods that
can be used to hide data in the NTFS file system, and the anal-
ysis techniques that can be applied to detect and recover this
hidden data. Target readers for this paper are computer foren-
sic analysts and examiners, but the content may also be useful
for system administrators and managers.
We restrict the discussion to those methods of data hiding
techniques in NTFS file system which meet the criteria of se-
curity and capacity as specified in Provos and Honeyman:
 Standard file system check with a utility such as chkdsk
should not return any errors.
 Hidden data will not be overwritten or the possibility of data
being overwritten is low.
 Hidden data will not be revealed when using standard GUI
file system interface.
 A reasonable amount of hidden data can be stored.
A method which fails to meet any one of the above criteria
is not effective in the long term. If data can be easily detected
with standard utilities by a normal user then it is not hidden
properly. And if the data can be overwritten by unrelated file
system activities, it can never be retrieved by the hiding party
or the forensic examiner.
To order our discussion, we classify the effective hiding
methods into two main categories:
 Specific methods based on unique NTFS data
structures.
 Generic slack space based methods in relation to NTFS.
We further explore how NTFS specific methods can exploit
the metadata structures and user data and directories in
NTFS. For the sake of completeness we will also briefly discuss
some methods which we would not under general circum-
stances consider effective according to the definition given
above.

* Corresponding author.
E-mail addresses: e.huebner@scm.uws.edu.au (E. Huebner), d.bem@scm.uws.edu.au (D. Bem), ckw214@yahoo.com (C.K. Wee).

1742-2876/$ – see front matter ª 2006 Elsevier Ltd. All rights reserved.
doi:10.1016/j.diin.2006.10.005
212 digital investigation 3 (2006) 211–226
2. Methodology and tools
We used a number of software tools to first hide data using
each of the discussed methods, and then recover these data
and restore its original format. Runtime’s DiskExplorer for
NTFS v2.31 (DiskExplorer) was used to manually create the
hidden data for testing purposes for all but one of the
methods. The only exception was hidden data for alternate
data streams (ADS) which was created by a standard DOS
command. The test data were created on a system with
Windows XP version 5.1.2600. Throughout this paper, ‘‘/case1/
image1’’ file will be used in examples as the acquired image of
the NTFS undergoing the analysis.
The following tools were used to detect and analyse hidden
data: Windows XP chkdsk and Fsutil, Windows OEM Sup-
port Tools Nfi (Microsoft OEM), Sleuth Kit 2.02 (Carrier), Fore-
most 0.69 (Foremost), comeforth 1.00, dd, hexedit and
strings. It should be noted that many other tools exist both
for creation and detection of hidden data. The software and
hardware tools used here serve to illustrate the topics
described, and it should not be implied that these tools are
best for the tasks described.
3. NTFS background
In the NTFS file system, every object is a file, and as such it in-
herits all the characteristics of a file. This includes file system
metadata which defines the structure of the file system itself.
NTFS organizes structures on a disk volume in four logical
blocks (How NTFS Works) as shown in Fig. 1.
The most important feature of NTFS is the Master File
Table (MFT), which is implemented as an array of records
(Russinovich and Solomon, 2005). Every file and every direc-
tory has at least one entry in MFT, including the MFT itself.
Each entry in MFT is called a file record and has a default fixed
size of 1024 B (Mikhailov). The first 42 bytes in a file record are
reserved for the MFT entry header, and the remaining bytes
are used to store the so called attributes as shown in Fig. 2.
An attribute is a small data structure with a specific purpose,
for example $STANDARD_INFORMATION, $FILE_NAME or
$DATA (How NTFS Works). Two attributes, $STANDARD_IN-
FORMATION and $FILE_NAME are present in every file record,
independently of the file type. Some attributes are specific to
file types, for example $DATA for data files and $INDEX_ROOT
for directory files. It is important to note that apart from the
attributes required by the system, a file may have any other
attribute, even if it is not used by the system.
The content of an attribute can be either resident or non-
resident. A resident attribute stores its content directly in
the MFT entry. A non-resident attribute stores its content in
NTFS Boot Sector MFT
Fig. 1 – NTFS volume structure. NTFS Boot Sector, layout of the volume, the file system structures and the boot code; MFT,
Master File Table; File System Data, storage for data that is not contained within the Master File Table; MFT Copy, Master
File Table copy.
the external clusters. In such case the list of clusters used is
stored as a cluster run in the attribute MFT entry.
A data unit in NTFS is called a cluster; it is the smallest disk
space allocation unit. Every cluster in NTFS has a Logical Clus-
ter Number (LCN), starting with 0 for the first cluster of the file
system (Svensson, 2005). Clusters which belong to a file are also
assigned a Virtual Cluster Number (VCN). For example, if a file
consists of six clusters, the first cluster of the file will have VCN
0 and the last cluster – VCN 5. The cluster runs present in non-
resident attributes provide mapping between VCNs and LCNs.
Metadata files are files that describe the structure of the file
system itself. Table 1 lists the NTFS metadata files and their de-
scription. Microsoft defined 16 standard MFT records (file num-
bers 0–15), some of them currently unused (reserved for future
use). Additional metadata files are stored in the extensions
metadata directory, as shown in the table. File numbers for ex-
tensions metadata files start with 24, and all following num-
bers are available for user files. The range of file numbers
from 16 to 23 is not allocated, and it is reasonable to assume
that Microsoft reserves these numbers for some future use.
The data hiding methods discussed in this paper, espe-
cially the NTFS structure based methods, rely on specific
features and structures of NTFS, and we will refer to the
names in the table throughout this paper without further
explanations.
4. NTFS specific data hiding methods
As stated before any object in NTFS is a file, and as such can
have any file attribute. Some attributes, for example $DATA,
$INDEX_ROOT or $INDEX_ALLOCATION may legitimately ap-
pear multiple times in a single file, and in such case they are
given unique names. Naturally depending on the file type, cer-
tain attributes are required and expected, but it appears that
NTFS is not sensitive to a file including attributes which are
unnecessary. This feature can be exploited for hiding data in
such way that correct functioning of the system is not af-
fected. It should be noted that each attribute in NTFS has its
unique numeric type identifier, and attributes are always
ordered according to these values.
Except for $DATA attribute, most of the other attributes
have specific formats so that they can serve their intended
purpose. Any manipulation of the content of these attributes
may affect the integrity of the system, so they are not suitable
for hiding data. There are certain exception, when an attribute
is provided purely for backward compatibility and no longer
used, for example $SECURITY_DESCRIPTOR or extended attri-
butes $EA and $EA_INFORMATION. In theory it could be possi-
ble to use such attributes for hiding data, assuming that
a software tool is available for adding these attributes to files.
In practice such approach does not appear effective, especially
File System Data MFT Copy
 digital investigation 3 (2006) 211–226 213

Standard File or Directory Data or Index Unused Space

Information Name

Fig. 2 – MFT entry with a resident record (How NTFS Works).

that there is no certainty that the backward compatibility will
be maintained in future versions of NTFS.
The most effective hiding methods are based on the $DATA
attribute of files. This attribute is the only one without an im-
plied format, so its content can be arbitrary, it can have any
size without raising suspicion, and it is reasonable to assume
that it will always remain a feature of NTFS.
4.1. Metadata files based methods
The complete structure of the NTFS file system is defined by
its metadata files as shown in Table 1. All attributes of these
files are well defined, and even the $DATA attribute, where
it is present, has a defined internal format to support the
NTFS operations. There is one metadata file where the content
of $DATA attribute is of no interest to the file system, namely
$BadClus file, which will be discussed separately.
Despite this there is potential for hiding some data in the
metadata files in such way that the functionality of the system
is not affected. The difficulty is that there is no guarantee that
NTFS will remain insensitive to the additions in its future ver-
sions, and that specialised software tools are required to ma-
nipulate the metadata files. The very presence of such tools in
the file system is an indication that the investigator should di-
rect some effort in this direction.
4.1.1. Hiding data in $BadClus file
Modern hard disk controllers handle bad sectors themselves
without any involvement of the operating system. Typically
Table 1 – Metadata files in NTFS (Russinovich and
Solomon, 2005)
File no. Metadata file Description
one of the following two ways is used (Schindler et al., 2002):
slipping (modifying Logical Block Number (LBN) to physical
mapping to skip the defective sector) or remapping (reallocat-
ing LBN from defective area to a spare sector). In addition the
volume managers included with Windows are capable of
remapping bad sectors, so called sector sparring, and even
recovering data on fault tolerant systems (Russinovich and
Solomon, 2005).
For older hard disks that do not have this capability, oper-
ating systems and file systems have to retain the ability to de-
tect and mark defective sectors and clusters as damaged. This
ability may be used to exclude undamaged clusters from the
normal file system activities, and use them to hide data in
any system.
In NTFS, bad clusters are marked in the metadata file $Bad-
Clus, which is the standard MFT entry 8. Initially, $BadClus is
a sparse file with the size set to the size of the entire file sys-
tem. When bad clusters are detected, they are allocated to
this file. The size of data that can be hidden with this tech-
nique is equal to the capacity of the entire file system. Any
number of clusters can be allocated to $BadClus and used to
store data.
To create the test data, clusters were added to the clus-
ter run list of the standard named $DATA $Bad attribute of
$BadClus file. The size of the $DATA $Bad attribute and the
size of its MFT file record were modified appropriately.
Then the allocation status of clusters used to hide data
was set to 1 in $Bitmap, and the hidden data were pasted
onto the clusters. The details of the manual procedure for
hiding data in faked bad clusters are shown in Appendix
A. Fig. 3 shows the flowchart for detection of hidden data
in faked bad clusters.

0 $MFT MFT record

1 $MFTMirr
2 $LogFile
3 $Volume
4 $AttrDef
5 . (dot)
6 $Bitmap
7 $Boot
8 $BadClus
9 $Secure
10 $Upcase
11 $Extend
12–15 Unnamed
24 $Extend\$Quota
$Extend\$ObjId
$Extend\$Reparse
$Extend\$UsnJrnl
Partial backup of MFT
Transaction logging file check for cluster allocated to
Volume information such as label, $Bad atribute in $BadClus
identifier and version
Attribute definition
Root directory of file system clusters No no hidden data
allocated? in bad clusters
Allocation status of all clusters
Boot record Yes
List of bad clusters
Security and access control check the content of
clusters marked as bad
information
Converts lowercase characters to
matching Unicode uppercase
characters extract the clusters
Optional extensions directory
Reserved for future use
Quota file
analyse with data
Object identifier file
carving tools
Reparse point file
Change journal file
Fig. 3 – Detection of hidden data in faked bad clusters.
214 digital investigation 3 (2006) 211–226
To check for clusters allocated to the $DATA $Bad attribute
of the $BadClus file we use the Sleuth Kit istat command:
istat /case1/image1 –f ntfs 8
The very presence of clusters allocated to the $DATA $Bad
attribute is an indication of an unusual activity as it is rare for
the operating system to handle bad sectors. If the physical
hard disk used to store the file system is still available, a surface
scan should be performed to verify whether there are any dam-
aged sectors on the disk. Even if bad sectors are discovered on
a disk, all $DATA $Bad clusters must be inspected thoroughly.
The content of the clusters marked as bad can be analysed
using the technique described in Appendix B.
4.1.2. Hiding data in $DATA attribute
Most of the metadata files, except the directories and the ex-
tension metadata files already contain the $DATA attribute.
Except for $BadClus, already discussed, NTFS uses the content
of this data in its operation, so the format of the existing data
is defined and depends on the role the metadata file fulfils in
the file system. It is possible to append some hidden data to
these $DATA attributes without disturbing the data already
present. In most cases the $DATA attribute is both read and
written by NTFS, so the appended data could be overwritten
by the normal activity of the system, but some of the $DATA
attributes are static, for example in $AtrDef, $Bitmap, $Boot,
and $UpCase. The size of data that can be hidden in this man-
ner is only limited by the size of the file system as more clus-
ters can be allocated to the $DATA attribute of any of the listed
metadata files to hide data.
We applied this method to the $Boot file, but it is equally
applicable to all others. The following procedure was used to
create test data:
1. Cluster run list of the $DATA attribute of the $Boot file is
modified.
2. The last VCN value of the $DATA attribute of the $Boot file
is modified.
3. The real size, allocated size and compressed size of the
$DATA attribute of the $Boot file is modified.
4. The allocation status of the additional clusters allocated to
$Boot is set to 1.
5. Hidden data is pasted to the allocated clusters.
If the steps listed in creating the test data are not followed
exactly, the chkdsk command may return an error. For exam-
ple, if any of the first three steps is not completed, the error
message as shown in Fig. 4 will be displayed. If step 4 is not
Fig. 4 – File error message displayed by the chkdsk command.
performed, the error message as shown in Fig. 5 will be
displayed.
To discover whether there is any data hidden in this man-
ner the investigator should check the number of clusters allo-
cated to each $DATA attribute using NTFS File Sector
Information Utility Nfi (Microsoft OEM). If the number of clus-
ters in the cluster run is larger than expected or there is more
than one cluster run per attribute the data in allocated clusters
should be extracted and analysed, as described in Appendix B.
This method is obviously ineffective for those metadata
files where $DATA attribute is written by various utilities of
NTFS while the system is active, like $Mtf, $MtfMirr, $LogFile,
$Secure and all extension metadata files.
4.1.3. Hiding data in $Boot file
In NTFS the boot record is stored in a metadata file called
$Boot. This is the only file with a fixed location; it always starts
at the first cluster of the file system. Windows allocates 16 sec-
tors to this file but typically only half of these sectors contain
non-zero bits (Carrier).
According to the NTFS documentation at the Linux NTFS
project (Provos and Honeyman), there are certain unused
bytes in the boot sector. However, Windows will not mount
the file system if there are any non-zero values in these un-
used bytes (Carrier). As a result, this space cannot be used to
hide data.
However, the bytes allocated to boot code in the $Boot file
of NTFS file system can be used to hide data. Boot code is
only essential for a bootable file system to locate files required
to boot up Windows (Carrier). For a non-bootable file system, it
is used to store the error message that is displayed if an at-
tempt is made to boot from this partition. The size of data
that can be hidden in this manner is limited by the number
of non-zero bytes in the $Boot file. Fig. 6 shows the analysis
flowchart for detection of hidden data in the $Boot file and
the backup boot sector.
The analysis of hidden data in the $Boot file should start by
comparing the boot sector and the backup boot sector. Let’s as-
sume that there are 6,136,830 sectors in the partition. In such
case the following sequence of commands should be used,
the same as for checking the integrity of the backup boot sec-
tor in volume slack analysis, which will be discussed later:
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
 digital investigation 3 (2006) 211–226
Fig. 5 – File system error message displayed by the chkdsk command.
This consistency check would only give an indication of file
system manipulation if the checksums differ from each other.
If they are the same, there is still a possibility that the modi-
fied boot sector was copied to its backup to avoid detection.
For this reason the extracted content should still be analysed
with a hex editor, foremost and comeforth as shown in
Appendix B.
4.1.4. Summary
NTFS is a very complex system, and its full documentation is
not available from Microsoft, therefore, any manipulation of
the metadata files for hiding data always carries some risk
of breaking the file system structure. The only exception is
the $BadClus file where no interpretation of data is ever
attempted by the system. Some small amount of data can be
hidden in the $Boot file, but even that can be accidentally dis-
covered if anyone attempts to boot the system using this file.
Except for $DATA attribute, other attributes of metadata files
are resident, so they do not offer much in terms of capacity,
run chkdsk command
in Windows
perform consistency check
extract $Boot file and
the backup boot sector
check their content
analyse with data
carving tools
Fig. 6 – Analysis of hidden data in $Boot file and the backup
boot sector.
215
and it is not certain whether they can be made non-resident
for the sake of allocating additional clusters using the
methods applied to $DATA attribute.
It seems that hiding data in user data files or directories
carries with it a much lesser risk of accidental discovery,
and does not rely on current insensitivity of NTFS to manipu-
lation of its metadata. This does not mean that metadata files
should not be analysed carefully whenever an NTFS image is
subject to forensic examination. The NTFS File Sector Infor-
mation Utility Nfi (Microsoft OEM) is a good tool to start the ex-
amination, as it will provide the clues for all data hiding
techniques discussed above.
4.2. Data files based methods
As stated before each file and each directory in NTFS has at
least one entry (a file record) in Master File Table. A typical
GUI interface for the file system assumes that each data file
has a single unnamed $DATA attribute and each directory –
a single $INDEX_ROOT attribute. It is the $DATA attribute
which provides most scope for hiding data, both in terms
of capacity and longevity of hidden data. We will examine
three methods of data hiding in $DATA attribute: in alternate
data streams in data files, in alternate data streams in
directories and in extension of the existing unnamed
$DATA attribute.
4.2.1. Alternate Data Streams (ADSs)
Alternate Data Streams (ADSs) are a unique feature of NTFS
file systems introduced with Windows NT 3.1 in the early
1990s to provide compatibility between Windows NT servers
and Macintosh clients which use Hierarchical File System
(HFS). HFS uses streams named ‘‘resource fork’’ and ‘‘data
fork’’. Both streams (or forks) are linked to one name in the
Macintosh file system. Resource forks are used to store appli-
cation metadata (icons, sounds, fonts, etc.) (The Data Fork,
1996).
In NTFS an MFT file record may have more than one $DATA
attribute; the additional named $DATA attributes are alternate
data streams. NTFS ADSs can be used to provide additional de-
scriptions for folders or files (creator, keywords, thumbnail
preview, etc.), to attach independent named data streams to
216 digital investigation 3 (2006) 211–226
an NTFS file or folder, or to store the summary data and vol-
ume change tracking (Means, 2003). ADSs can also be used to
hide data in NTFS file system as most of the system utilities
only examine the first unnamed $DATA attribute.
Fig. 7 shows a main unnamed stream has2ads.txt with
two files cf.pdf and infoday.doc attached to the main file as
two Alternate Data Streams. The ADS does not show up in di-
rectory listing and the recorded file size of the original file
(here: has2ads.txt) does not change by adding ADSs (Bem
and Huebner, 2006).
The size of data that can be hidden in ADSs is only lim-
ited by the size of the NTFS media used. One major differ-
ence between this data hiding technique and others
discussed in this paper is that an ADS is relatively easy
to create (Zadjmool, 2004). Other data hiding techniques
we examined require specific programs or low level file sys-
tem manipulation tools such as a hex editor. ADSs can be
created easily with a DOS command as shown below. For
example, the type command can be used to hide the file
‘‘slacker.exe’’ in an ADS called ‘‘hahaha’’ of ‘‘abcd.txt’’ as
follows:
type slacker.exe > h:\abcd.txt:hahaha
For testing purposes all ADSs were created by issuing the
same DOS command as the one shown above.
Detecting data hidden with ADSs is relatively easy, as there
are many well developed tools that can be used to scan a drive
for ADS. Some examples of such tools are lads and streams, as
shown below:
lads /sv h:
streams –s h:
The following Sleuth Kit command can be used to get the
MFT address and attribute identifier of the ADS called
‘‘h:\abcd.txt:hahaha’’ which will be revealed by the lads or
streams command above:
fls –rf ntfs /case1/image1 j grep abcd.txt:hahaha
The commands above provide the MFT address, attribute
type and attribute identifier. Let’s assume that 59-128-4 is
returned. The following commands can be used to inspect
the content of ADSs:
icat –f ntfs /case1/image1 59-128-4 > /case1/ADS1
file /case1/ADS1
hexedit /case1/ADS1
Fig. 7 – ADS visibility in NTFS and non-NTFS environments.
Additionally, most commercial computer forensics soft-
ware tools also provide a facility to scan specifically for
ADSs, though only some of them allow this to be done in
a fast and elegant way (X-Ways). However, we need to keep
in mind that since there are legitimate applications of ADSs,
it cannot be assumed that every single ADS encountered is
used to hide data. No tools distinguish between ADSs used
for legitimate purpose and ADSs used to hide data, thus
each ADS should be examined to verify its purpose. It is rec-
ommended to investigate the content of each ADS since
a common ADS name used by a legitimate program may be
chosen to avoid detection. Due to the above limitation of
open source as well as commercial tools, examining ADSs in
a specific disk image may turn out to be a very time consum-
ing, possibly even impractical task.
4.2.2. $DATA attribute in a directory
The $DATA attribute is typically used to store the content of
a file or other specific information such as allocation status.
It is a common attribute for all data files and some metadata
files but not directories. Although the $DATA attribute is un-
necessary for a directory, validation checking with chkdsk
or any other standard utility does not return an error when
a directory contains a $DATA attribute. As a result, the
$DATA attribute in a directory can be used to hide data
(Carrier, 2005). In addition, alternate data streams (named
$DATA attributes) can also be created with directories, not
just data files, to hide data. The size of data that can be hidden
with this technique is only limited by the capacity of the file
system.
The following procedure was used to create the test data:
 A directory is created.
 The $DATA attribute is inserted in the directory. This attri-
bute is inserted before $INDEX_ROOT, $INDEX_ALLOCA
TION and $BITMAP because the type identifier of $DATA is
smaller than these attributes.
 The allocated size of MFT entry is modified to appropriate
size.
 The attribute identifier of the other attributes might need to
be changed to avoid the newly created $DATA attribute hav-
ing the same identifier as existing attributes.
 The allocation status of clusters for the $DATA attribute is
set to 1.
 The file content is pasted to the clusters allocated to the
$DATA attribute.
Fig. 8 shows the analysis flowchart to detect hidden data in
the $DATA attribute of a directory.
 digital investigation 3 (2006) 211–226
retrieve the first directory
check whether there is $DATA
attribute in the directory
No
$DATA found?
Yes
check the contents of
$DATA attribute
Fig. 8 – Analysis of hidden data in $DATA attribute of directory.
The first step in the analysis is to list the directory entry in-
formation of all directories, as follows:
fls –rDf ntfs /case1/image1 j grep 128
Fig. 9 shows that the ‘‘r/r 40-128-3’’ is a $DATA attribute
which might contain hidden data.
If any $DATA attributes were discovered, their content can
be checked with the following commands:
icat –f ntfs /case1/image1 40-128-3 > /case1/
dataindirectory1
file /case1/dataindirectory1
hexedit /case1/dataindirectory1
Analysis techniques used to detect ADSs in files detect
ADSs in directories at the same time. The process has been
explained in the previous section and is not repeated here.
4.2.3. Data hiding in added clusters
This hiding technique is based on the ability to allocate addi-
tional clusters to an NTFS file. If there is an existing file with
some clusters already allocated by NTFS, more clusters can
be allocated to this file manually, and data can be hidden in
these clusters.
With this method, the size of hidden data is only limited by
the capacity of the file system as owners are free to allocate as
many additional clusters as they wish. One disadvantage of
this hiding technique is that whenever the original file in-
creases in size, the hidden data could be overwritten and
lost. For this reason stable files are preferable targets of this
technique. This is not a real hindrance, as the original file is
owned by the hiding party, and other users can be denied
write access to this file.
We used the following procedure to create the test data:
 Cluster run list information of the file is modified to allocate
more clusters.
 Last VCN of the file is modified to the appropriate value.
Fig. 9 – Output of the fls command checking for $DATA attributes in directories.
217
retrieve next directory
No
Yes
all directories analysis completed
checked?
 Allocated size of the file is modified to the appropriate value.
 Allocation status of the added clusters is set to 1 in $Bitmap.
Fig. 10 shows the flowchart for the analysis of hidden data
in additional clusters allocated to a file.
If any of the steps listed above were omitted when adding
clusters, then a standard disk analysis tool like chkdsk will de-
tect errors in the file system. Fig. 11 shows errors which will
occur if any of the first three steps were not performed, i.e.
modification of the cluster run list, modification of the last
VCN or modification of the file size. The error message shown
in Fig. 12 will be displayed if the first three steps were per-
formed correctly, but the added clusters were not marked as
allocated. Errors of this nature are an indication of file system
manipulation, and warrant further investigation.
The data hidden in additional clusters can still be discov-
ered even if the procedure was followed without any omis-
sions, and no errors were reported by chkdsk. In such case
a recursive directory listing of the file system has to be per-
formed to identify all files:
fls –rFf ntfs /case1/image1
The analysis is based on retrieving the files one by one and
comparing the allocated size and the real size for each file.
These values are stored in the header of $DATA attribute of
the file, and it would be most efficient to obtain them directly.
When using existing tools, the real size of the file can be
obtained by running the istat command of Sleuth Kit but
not the allocated size. To obtain the allocated size the MFT
file record can be processed manually to retrieve the value
(which is time consuming). Other tools, for example Dis-
kExplorer, can be used, or the allocated size can be calculated
by multiplying the cluster size and total clusters allocated to
the file.
The number of allocated clusters and the real size of the file
can be retrieved with the Sleuth Kit istat command:
istat /case1/image1 29
218 digital investigation 3 (2006) 211–226

run chkdsk command

in Windows

retrieve the first file

check the real size of the file in the retrieve next file
$DATA header of the file

check the allocated size of the file in the

No
$DATA header of the file

No Yes
sizes: alloc-real> all files analysis completed
cluster size? checked?

Yes

extract the clusters detected

check the contents of

these clusters

analyse with data

carving tools

Fig. 10 – Analysis of hidden data in additional clusters allocated to a file.

The cluster size of the file system can be obtained by run- clusters should be extracted and analysed as described in
ning the Sleuth Kit fsstat command: Appendix B.
To detect and retrieve hidden data in additional clusters
fsstat –f ntfs /case1/image1 each file has to be analysed individually, and this process is
time consuming if performed manually. However, to the
Then the additional space of the file can be calculated as best of our knowledge there is no specific tool available that
follows: automates this process.

Allocated size ¼ number of clusters  cluster size

Additional space ¼ allocated size  real size
If the additional space is larger than the cluster size, un-
necessary clusters have been allocated to that file. This is
uncommon and should be considered as an indication
that the file may contain hidden data. The additional
5. Slack space based hiding methods
in NTFS
Slack space relates to all the areas on disk surface which can-
not be utilised by the file system because of discrete nature of
space allocation. Existence of slack space is characteristic of

Fig. 11 – File error message displayed by chkdsk command.

 digital investigation 3 (2006) 211–226
Fig. 12 – File system error message displayed by chkdsk command.
all file systems, not just NTFS. The discussion of data hiding
methods in NTFS would not be complete without discussing
slack space, and we will highlight those aspects of the
methods which are specific to NTFS.
5.1. Volume slack
Volume slack is the unused space between the end of the file
system and the end of the partition where the file system re-
sides. The size of the hidden data in volume slack is only lim-
ited by the space on the hard disk available for a partition as
the size of partition can be changed in relation to the size of
volume to hide more data, or the size of volume can be
changed in relation to the size of partition. The procedure
for creating test data was as follows:
 The $Boot file is modified to reduce the number of sectors
allocated to file system.
 The $Bitmap file is reduced to remove the bits used for set-
ting the allocation status of clusters no longer in the file
system.
 Data to be hidden is pasted to the volume slack and file sys-
tem slack.
Fig. 13 shows the analysis flowchart for detection of hidden
data in volume slack.
The forensic analysis in Windows should always start with
chkdsk command to check the integrity of the file system.
With manual modification of the file system it is easy to
miss some of the needed steps, and errors may be generated
by chkdsk giving some indication of the possibility of hidden
data. For example, if the number of sectors allocated to the file
system is changed in the $Boot file without an appropriate
change in the $Bitmap file, a message ‘‘Correcting errors in
the Volume Bitmap’’ would appear when running the chkdsk
command.
The next step is to check the number of sectors allocated to
the partition using the Sleuth Kit mmls command. In this ex-
ample, the mmls command returns 6,136,830 as total sectors
in /case1/wholeimage:
mmls /case1/wholeimage –t dos
Then the number of sectors allocated to the NTFS file sys-
tem in that partition has to be checked with the fsstat
219
command or with Windows utility fsutil. In this example,
fsstat shows that 6,136,782 sectors are allocated to the file
system:
fsstat /case1/image1 –f ntfs
For Windows NT 4.0, 2000 and XP, if there are N sectors in
the partition, N-1 sectors are 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 one sector of
volume slack, and if more sectors are discovered all of the vol-
ume slack space should be investigated.
Even if only one sector of volume slack is present, it should
be extracted and compared with the boot sector to check that it
contains the backup boot sector, as discussed in Section 4.1.3.
Because the volume slack has no cluster numbers, the
Sleuth Kit dcat command cannot be used to view its content.
The dd command can be used to extract volume slack, and
a hex editor can be used to view the content. The volume slack
can then be analysed as described in Appendix B.
5.2. File system slack
File system slack is the unused space at the end of the file sys-
tem that is not allocated to any cluster. This happens because
the partition size may not be the multiple of the cluster size
(Carrier, 2005). For example, if there are 10,001 sectors in the
partition, the first 10,000 sectors are allocated to 2500 clusters
with the cluster size of 4 sectors and the last sector becomes
file system slack. The size of data that can be hidden in file sys-
tem slack depends on the size of a cluster. For example, for
a standard NTFS cluster size of 8 sectors, the maximum size
of the file system slack is 7 sectors. For testing purposes the
data to be hidden was simply pasted over the file system slack.
Fig. 14 shows the analysis flowchart for the detection of
hidden data in file system slack.
The number of sectors allocated to the NTFS file system (A)
and the number of sectors per cluster (B) can be obtained by
running the fsstat command or Windows utility Fsutil:
fsstat /case1/image1 –f ntfs
If the remainder of the division A/B is 0, then there is no file
system slack. Otherwise, the file system slack has to be ana-
lysed in a similar way to the volume slack.
220 digital investigation 3 (2006) 211–226

run chkdsk command

in Windows

check number of sectors allocated

to the partition (A)

check number of sectors allocated

to the NTFS file system (B)

compare backup copy of boot sector

with the boot sector

Yes no hidden data

A=B+1 and bootsector
copies match? in volume slack

No

extract the sectors found in

the volume slack

Fig. 13 – Analysis of hidden data in volume slack.

5.3. File slack
File slack is the unused space between the end of a file and
the end of the last allocated cluster. The file slack appears
because a cluster is the smallest unit of disk space alloca-
tion in NTFS and a whole cluster has to be used even if
the file does not fill the whole cluster (Mallery, 2001).
This unused space can be used to hide data (Chuvakin,
2002).
There are two types of file slack, the RAM slack and the
drive slack. The RAM slack is the space from the end of a file
to the end of the last partially used sector in the last allocated
cluster. The drive slack spans the space from the start of the
next sector to the end of the last allocated cluster (NTI). For

run chkdsk command

in Windows

check number of sectors allocated

to the NTFS file system (A)

calculate the remainder of

A / (number of sectors per cluster)

Yes
the reminder = 0? no file system slack

No

extract the sectors of the

file system slack

Fig. 14 – Analysis of hidden data in file system slack.

 digital investigation 3 (2006) 211–226 221

Fig. 15 – Slack space of a 600 B file with 2048-B cluster (Carrier, 2005).

example, let’s consider a 600 B file is stored in NTFS with
a 2048-B cluster and a 512-B sector as shown in Fig. 15. RAM
slack stretches from the end of file to the end of sector 2,
and drive slack is composed of sectors 3 and 4.
The analysis of hidden data in slack space depends on the
operating system as it is the operating system that decides
how to handle file slack, and not the file system. For example,
Microsoft Windows fills the RAM slack with zeros, and ignores
the drive slack when storing a file (Carrier, 2005). For this rea-
son any non-zero bit in the RAM slack of a file is suspicious
and worth further analysis.
The size of data that can be hidden in the slack space of
a single file depends on the cluster size (Incident Handling).
The amount of data hidden in a single file is always less
than the size of the cluster. The potential size of hidden data
in file slack is actually very large as data can be hidden in slack
space of multiple files, not just a single file.
The procedure to create test cases for hidden data in RAM
slack, drive slack and both is as follows:
 locate the suitable file or files with sufficient slack space to
hide data,
 paste the data to slack space of the files.
Fig. 16 shows the analysis flowchart for the detection of
hidden data in the file slack. The analysis begins by checking
the RAM slack space for each file. If there are any non-zero bit
in the RAM slack, both RAM slack and drive slack of the file are
extracted for further analysis. Otherwise, only the drive slack
space is extracted.
In the example below we extract the slack space of a file
with the MFT number 28. To obtain the file size we run the
Sleuth Kit istat command:
istat –f ntfs /case1/image1 28
The size of the RAM slack and drive slack in bytes is calcu-
lated as follows:
file slack ¼ allocated size  real size
drive slack ¼ int(file slack/512)  512
RAM slack ¼ file slack  drive slack
To extract the entire file with MFT number 28 including its
file slack we run the Sleuth Kit icat command:
icat –sf ntfs /case1/image1 28 > /case1/file28
Let’s assume that the file size is 119,875 B and the RAM
slack is 445 B. To extract the RAM slack we run the dd com-
mand with the following parameters:
dd if¼/case1/file28 of¼/case1/file28RAMslack bs¼1
skip¼119875 count¼445
The dd command is also used to extract the drive slack as
follows:
dd if¼/case1/file28 of¼/case1/file28driveslack
bs¼512 skip¼235 count¼1

check the RAM slack

non zero bit No

in RAM slack

Yes

extract both RAM slack and

extract drive slack of all files
drive slack of all files

check their content

Fig. 16 – Analysis of hidden data in file slack.

222 digital investigation 3 (2006) 211–226
This process should be repeated to extract the slack space
of each file for analysis. The extracted data is then analysed as
described in Appendix B.
A command line tool, Slacker (Metasploit, 2006), has been
made available recently, which allows reading and writing
data in file slack space automatically. Slacker provides differ-
ent hiding strategies based on using slack space in a mix of
consecutive and randomly selected files. The manual
methods of detection and extraction described above can be
used against data hidden with Slacker.
6. Ineffective data hiding methods
As stated in the introduction, effective data hiding techniques
in a file system should meet the goals of security and capacity
(Provos and Honeyman). Below we list some uncommon and
ineffective techniques possible with NTFS which do not sat-
isfy all of these goals.
 Set the allocation bit of certain unallocated clusters to 1 and
hide data in these clusters: a simple chkdsk validation
would detect this.
 Hide data in unallocated clusters: there is a high possibility
of the hidden data being erased unless certain countermea-
sures are implemented such as setting the hard disk to read
only access.
 Hide data in unallocated MFT entries: as above, hidden data
are likely to be erased.
 Hide data in unused space in an MFT file record: hidden data
is erased if more attributes are added to the MFT file record
or the size of an attribute increases.
There are certain environments where these hiding tech-
niques may be effective. Let’s consider data hiding in unallo-
cated clusters as an example. If the hard disk is write
protected or a rootkit installed (Carvey, 2004) in the system
that will never write to certain unallocated location, the hid-
den data would not be erased. Another possibility is the
scheme proposed by Eckstein and Jahnke (2005) for journaling
file systems like Ext3, where traditional consistency checks on
restart are not performed. As a result, a thorough investiga-
tion of the system and the physical environment is important
and may give some clues about the likely data hiding tech-
niques used.
7. NTFS integrity
A check of general integrity should be performed on NTFS be-
fore any analysis starts. The chkdsk command should be run,
and if it returns any error, this is an indication that the file sys-
tem could have been manipulated and left in an unstable
state. Next the standard Windows utility Fsutil or the Sleuth
Kit command fsstat should be run to obtain general infor-
mation about NTFS system under investigation.
The cluster size of the system should be checked against
the default size matching the file system size. The default
cluster size in NTFS depends on the size of file system (Svensson,
2005). It is uncommon for a normal user to modify the default
cluster size. However, it may be modified in such a way that
more hidden data can be stored. For example, with a larger
cluster size, more hidden data can be stored in the file slack
of a file. An NTFS system with a cluster size that does not
match its file system size is suspicious.
The next step is to examine metadata files with Microsoft
OEM tool Nfi with a view of detecting any abnormalities in
terms of the length of cluster runs in $DATA attributes, pres-
ence of names $DATA attributes, or any other sign that the
metadata files are different than expected.
Next the system should be searched for the presence of
data hiding tools. Attention should also be paid to both digital
and physical files that contain a record of numbers that might
be the cluster addresses where hidden data is stored. All such
files could themselves be hidden using manual methods.
Depending on the result of the steps above, any combina-
tion of places for hidden data should be thoroughly examined,
potential hidden data extracted and investigated further.
8. Conclusion
In general, the analysis of hidden data in NTFS file system is
divided into three phases. The first phase is to determine
whether any data is hidden. This process can either system-
atically check for all hiding methods discussed in this paper,
or search the system for anomalies. For example, it is abnor-
mal for an operating system to detect bad sectors before
a hard disk does, so the very presence of any bad clusters
is suspicious and worth further analysis. Similarly, if the in-
tegrity of the system is under suspicion because the default
cluster size is changed, the file slack is likely to contain hid-
den data.
There are no specific forensic analysis tools that check for
hidden data in NTFS file system except small collection of lim-
ited tools that check for alternate data streams. While the
analysis techniques that we discussed may be helpful in de-
tection and recovery of the hidden data, the process is time
consuming without automated tools, and requires in depth
knowledge of NTFS structures.
The second phase is to extract the hidden data, and the
third phase is to recover the hidden files. This may be difficult
because hidden information may be stored in the file system
without any structure or metadata. The recovery is particu-
larly challenging if data are stored in a random order and
the file signature is removed. Additionally, there may be cryp-
tographic or steganographic techniques used which will pre-
vent complete data recovery.
One of the difficulties of analysing NTFS file system for hid-
den data is that it is very flexible and supports many options,
some not commonly used, some only partially documented.
As a result, there are many possible ways to hide data, espe-
cially when NTFS specific data structures are used for this
purpose. The additional difficulty is that the complete docu-
mentation for the NTFS system is not published, and it is
not always possible to determine which value combinations
in system data structures are valid and which are not (Carrier,
2005). A good example is the ability to add a $DATA attribute to
a directory, which is ignored by system utilities although it
does not fit the logical structure of the file system. Other
 digital investigation 3 (2006) 211–226 223

Fig. 17 – $DATA attribute of $Bitmap.

similar options of adding hidden data may already exist, or
may yet be created by new versions of NTFS.
Probably the best and most comprehensive documentation
of NTFS comes not from Microsoft, but from the Linux com-
munity projects which work on providing NTFS drivers for
Linux operating systems. This documentation is the result of
years of back-engineering and many experiments (Russon
and Fledel). This means that the number of methods for hid-
ing data will inevitably grow in the future, and to match this
growth new forensic analysis tools and methodology will be
created.
Appendix A.
Detailed process of hiding data in faked bad
clusters
automate this task to become available. This tool is used
here to demonstrate how NTFS file system can be manipu-
lated to hide data.
To prepare a test file system for analysis we used the fol-
lowing procedure:
(1) Identify the clusters where $DATA of $Bitmap file is
stored. As shown in Fig. 17, it starts at x0005DA4C and it
is allocated 24 clusters.
(2) Inspect the clusters that are allocated to $Bitmap.
(3) Identify unallocated clusters. In this example, 12 clusters
(from 383,624 to 383,635) would be marked as bad clusters
to store hidden data as shown in Fig. 18. Calculation of
the cluster number represented by a bit in $Bitmap is
shown below:
Cluster number ¼ ððA  BÞCDÞ þ ðEFDÞ þ ðGDÞ þ H  1

The tool used in this example is Runtime’s DiskExplorer for

NTFS v2.31. While using this tool to edit the NTFS might A ¼ sector address of current sector;
seem awkward and too complicated for ‘‘script kiddies’’ level B ¼ starting sector for $Data attribute of $Bitmap;
suspects, it may just be a matter of time for a tool that can C ¼ number of bytes in a sector;

Fig. 18 – Allocation status of faked bad clusters is set to 1.

224 digital investigation 3 (2006) 211–226

Fig. 19 – Modification of the $Bad attribute of $BadClus file to create faked bad clusters.

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, the calculation for the bit that represents clus-
ter address 383,524 in $Bitmap is shown below:
Starting sector for $DATA attribute of $Bitmap: 029FE8D6
Current sector: 029FE933
Cluster number ¼ ðð029FE933  029FE8D6Þ512  8Þ
þ ð21  16  8Þ þ ð1  8Þ þ 1  1
¼ 380; 928 þ 2688 þ 8
¼ 383; 624
(4) Add clusters 383,624–383,635 to the run list of $BAD attri-
bute as shown in Fig. 19. Note that we are using an Intel
processor with little-endian ordering, so the least signifi-
cant byte of a number is in the first storage byte (Li, 1999).
For example, 383,624 (05dA88) is stored as 88DA05.
(5) Modify the size of the $Bad attribute to 0  58.
(6) Modify the size of the MFT to 0  180.
(7) Hide data into cluster 383,624 using the ‘‘paste from file
command’’ in DiskExplorer.
(8) Run chkdsk in Windows XP to ensure there were no
structure error introduced.
(9) The system is tested using Sleuth Kit before data are hid-
den. The dstat command is run to ensure the target clus-
ters are unallocated and the istat command to ensure
that no cluster is assigned to $BadClus. For example:
dstat /dev/sda2 –f ntfs 383624, repeat this for all
targeted clusters
istat /dev/sda2 –f ntfs 8
(10) After the data are hidden, the same commands are used to
ensure the clusters are allocated to $BadClus properly. Be-
sides the dstat and istat commands, the dcat com-
mand is run to check the content of hidden data. It is
also recommended to extract the hidden clusters with

Table 2 – Result of hidden data detection/recovery attempts for cluster-based hiding techniques
Hidden file Hiding technique Result of foremost

A Microsoft document file Sequential Successful detection and recovery

and an html file
A Microsoft document file Reversed order Successful detection of the files but unable
and an html file of clusters to open or meaningless data displayed
A Microsoft document file Header removed Failed to detect the files
and a jpg file
 digital investigation 3 (2006) 211–226 225

first sector of second sector of third sector of

hidden file hidden file hidden file
sic
Foren

drive slack of first file drive slack of second file drive slack of third file

sector that contains

hidden file

sector that does not

contain hidden file

Fig. 20 – Separation of a word across sectors.

the dd command under Linux and to open the extracted impossible to recover the file. During this research, we carried
file. For example: out tests to recover files hidden using the above techniques in
dstat /dev/sda2 –f ntfs 383624 (repeat this for all tar- faked bad clusters; the results are shown in Table 2.
geted clusters) Comeforth, an add-on of Sleuth Kit, is more useful in recov-
istat /dev/sda2 –f ntfs 8 ering data if a file is not stored in sequence. Comeforth is sim-
dcat /dev/sda2 –af ntfs 383624 ilar to lazarus (Farmer and Venema, 2005); it divides file into
dd if¼/dev/sda2 bs¼4096 skip¼383624 count¼12 of¼/ blocks and runs the file command on every block (Carrier).
mnt/usb/recoverfile Users can then view each block separately and select blocks
to be recovered as a file.
A keyword search can also be performed with hexedit,
Appendix B.
strings or other tools if part of the content of the hidden file
Analysis of extracted data
is known, for example:

Once the hidden data are located in the file system, its content
strings /case1/image1 j grep keyword
should be analysed. One way to check the content of the clus-
ters is to use the Sleuth Kit dcat command. However, this will
However, if a keyword is separated across two non-consec-
only reveal hidden data stored in ASCII encoding. For exam-
utive clusters, the keyword search will fail. For example, if
ple, if we assume that 12 clusters of the image 383,624–
data are hidden only in the first sector but extraction is done
383,635 are suspected to contain hidden data, the command
on the cluster, a word might be separated as shown in
format is as follows:
Fig. 20, and the keyword search fails.
The most challenging step in detecting and recovering hid-
dcat /case1/image1 –f ntfs 383624 12
den data is to guess how data are stored. For example, data
can be hidden only in the first sector of the drive slack of
For further analysis, we can extract the clusters and use
each file. Or data can be hidden only in the drive slack of the
data carving tools such as foremost and comeforth to recover
first file in each of the five directories created for this purpose.
data with the following commands:
Any number of combinations is possible. Detection and recov-
ery is hard, if not impossible, without knowing the method of
dd if¼/case1/image1 bs¼4096 skip¼383624 count¼12
storage. On the other hand it is unlikely that the storage algo-
of¼/case1/badclusters
rithm has been applied manually, and it is recommended to
foremost –c /etc/foremost.conf –v –o /forensic/
search for data hiding tools in the system (Kruse and Heiser,
recover/case1/badclusters
2002). The algorithm used to hide data can then be analysed
to decide on appropriate ways to extract file slack.
This analysis technique works if the files are stored se-
The hidden files can be scrambled and obfuscated using
quentially in the extracted clusters. However, a file can be seg-
many techniques including steganography and cryptography.
mented and stored in a non-sequential way or even randomly
It is unlikely that such process was conducted manually, so it
(Carvey, 2004). For example, if a Microsoft Word file is stored
is likely that software tools exist in the analysed file system
with 383,629 as the starting cluster, moving backward and
which were used to modify the hidden file. These software
storing the last portion of file in cluster 383,624, foremost is
tools may either be present as an executable image in the
unable to recover the file correctly. This technique does not
file system, or they may themselves be hidden.
prevent the owner from retrieving the files as they can record
the correct order of clusters used to hide the file.
To make the forensic analysis even harder, the owner may references
also remove the signature of a file to avoid detection by data
carving tools (Carvey, 2004). Data carving tools such as foremost
recover files based on their data structures such as the header Bem D, Huebner EZ. Alternate data streams in forensic investi-
and the footer (Foremost), and without these structures, it is gations of file systems backups. Athens, Greece: ATINER.
226 digital investigation 3 (2006) 211–226
Available from: http://www.cit.uws.edu.au/compsci/
computerforensics/Technical%20Reports/index.php; 2006.
Carrier B. File system forensic analysis. Upper Saddle River, NJ:
Addison-Wesley; 2005.
Carrier B. The Sleuth Kit. Available from: http://www.sleuthkit.
org/sleuthkit/desc.php.
Carvey H. Data hiding on a live system. Seattle, WA, USA: Black-
Hat Windows Security. Available from: http://www.blackhat.
com/html/win-usa-04/bh-win-04-speakers.html; 2004.
Carvey H. Windows forensics and incident recovery. Boston, MA:
Addison-Wesley; 2004.
Chuvakin A. LinuxSecurity.com. Abailable from: http://www.
linuxsecurity.com/content/view/117638/49/; 2002.
Eckstein K, Jahnke M. Data hiding in journaling file systems. In:
5th annual digital forensic research workshop. New Orleans:
Louisiana. Available from: http://www.dfrws.org/2005/
proceedings/; 2005.
Farmer D, Venema W. Forensic discovery. Upper Sadle River, NJ:
Addison-Wesley; 2005.
Foremost, <http://foremost.sourceforge.net/>.
How NTFS Works, Windows Server 2003 Technical Reference.
Available from: http://www.microsoft.com/technet/prodtech
nol/windowsserver2003/library/TechRef/8cc5891d-bf8e-4164-
862d-dac5418c5948.mspx.
Incident handling/forensics FAQs. <http://www.paladion.net/
papers/ihfaq.htm#hidden_data>.
Kruse II WG, Heiser JG. Computer forensics: incident response
essentials. Addison Wesley Professional; 2002.
Li K. A guide to programming Intel IA32 PC architecture. Available
from: http://www.cs.princeton.edu/courses/archive/fall04/
cos318/docs/pc-arch.html; 1999.
Mallery JR. Secure file deletion, fact or fiction? Available from:
http://www.sans.org/; 2001.
Means RL. Alternate data streams: out of the shadows and into
the light, http://www.giac.com/; 2003. p. 45.
Metasploit Anti-forensics Project Slacker; 2006. Available from:
http://www.metasploit.com/projects/antiforensics/.
Microsoft OEM support tools. <http://support/microsoft/com/
support/kb/articles>.
Mikhailov D. NTFS file system. Available from: http://www.digit-
life.com/articles/ntfs/.
NTI. File slack defined. <http://www.forensics-intl.com/def6.html>.
Provos N, Honeyman P. Detecting steganographic content on the
internet. p. 13.
Runtime’s DiskExplorer for NTFS. <http://www.runtime.org/dis
kexpl.htm>.
Russinovich ME, Solomon DA. Microsoft Windows internals.
Redmond: Microsoft Press; 2005.
Russon R, Fledel Y. NTFS documentation. Available from: http://
www.linux-ntfs.org/content/view/103/42/. p. 138.
Schindler J, Griffin JL, Lumb CR, Ganger GR. Track-aligned extents:
matching access patterns to disk drive characteristics. In:
Conference on file and storage technologies (FAST). Monterey,
CA, USA; 2002. p. 16.
Svensson A. Computer forensics applied to Windows NTFS
computers, Information and communication system security.
Stockholm’s University/Royal Institute of Technology, http://
www.dsv.su.se/research/seclab/; 2005. p. 64.
The data fork and the resource fork, inside macintosh: more
macintosh toolbox; 1996. Available from: http://developer.
apple.com/documentation/mac/MoreToolbox/MoreToolbox-
11.html.
X-Ways Forensics. <http://www.x-ways.net/forensics/>.
Zadjmool R. Hidden threat: alternate data streams, WindowSe
curity.com. Available from: http://www.windowsecurity.com/
articles/Alternate_Data_Streams.html; 2004.
 ID Title Pages

458270 Data hiding in the NTFS file system 16

http://fulltext.study/journal/491

http://FullText.Study