文件系统取证分析(第11章:NTFS概念)
⽂件系统取证分析（第11章：NTFS概念）
/*
Skogkatt 开始翻译于2015-01-24，仅作为学习研究之⽤，谢绝转载。
2015-01-31更新MFT entry 属性概念。
2015-02-01翻译完成。
译注：我翻译这本书的这三章虽然蓄谋已久，但并不是⼀个计划好的⼯作。因为之前和vczh、mili、darkfall曾讨论过everything这个软件，也曾想过要写⼀个开源的everything，于是就出来⼀个坑。everything这个软件其实是从底层直接parse了NTFS MFT，然后parse类每⼀个FILE entry，从⾥⾯拆出来了每⼀个⽂件的信息，这个操作速度远快于Win32 FindFirstFile和FindNextFile。道理虽然简单，但是实现起来代码不会很少。
⼜，我从2013年起因⼯作原因开始研究和分析NTFS⽂件系统，并且看过数遍《File System Forensic Analysis》这本书的NTFS三章。这三章的信息已经略显过时并且存在⼀些技术细节谬误，翻译出来仅仅是给英语不好的朋友们做为拓展知识所⽤。如果想认真研究NTFS实现细节，建议看看泄露的Windows源代码、开源的NTFS3g库并使⽤磁盘编辑⼯具实际看看磁盘的布局。
另外，NTFS3g⽬前公开的代码坑很多，在⾼负荷压⼒测试中会出现严重的数据丢失损坏甚⾄⽂件系统挂掉，，不建议作为⼀个严谨的NTFS实现来使⽤。
*/
新技术⽂件系统（NTFS）是由Microsoft设计的并作为Micrtosoft Windows NT、Windows 2000、 Windows XP和Windows Server 的缺省⽂件系统。在写作本书的时候，Microsoft已经停⽌了Windows 98 和 ME 产品线的销售，Windows XP家庭版成为新的消费系统。FAT仍将会存在于移动和⼩型存储设备之中，但NTFS将会成为Windows研究中最为常见的⽂件系统。NTFS是⽐FAT更为复杂的⽂件系统，这是由于它具有众多的功能特性和伸缩性。由于NTFS的复杂性，我们需要三章来讨论它。本章将会讨论NTFS的核⼼概念，覆盖到我们模型中的五个分类。第12章，“NTFS分析”讨论了NTFS分析和使⽤五分类模型来展⽰我们从哪⾥获取证据。第13章，“NTFS数据结构”介绍了NTFS相关的数据结构。
简介
NTFS被设计为具有可靠性、安全性和⽀持⼤型存储设备。伸缩性是由通⽤的数据结构所封装的具有特定内容的数据来实现的。这之所以是⼀个可伸缩的设计，是由于内部的数据结构可以根据⽂件系统新增的需求⽽变化，⼆外部的封装可以保持不变。⼀个通⽤封装的例⼦
是，NTFS⽂件系统的每⼀个字节都被分配到⽂件之中。我们稍后在本章中将会讨论NTFS⽂件的概念。
NTFS是⼀个复杂的⽂件系统，不幸的是，并没有⼀个从Microsoft公开的规范来描述其在磁盘上的布局。⽂件系统⾼层组件的描述已经公开了，但是底层细节信息仍然⾮常匮乏。幸运的是，其他组织已经公开了他们所认为的磁盘布局结构信息，这些信息包含在本书之中，并且我们将会⽤它们来⼿⼯深⼊到磁盘之中。尽管这听起来很有难度，然⽽，我们仍然⽆法确保这⾥所描述的数据结构和磁盘上⾯的完全⼀致。
NTFS是⼤量Windows系统的标准，并且在免费的Unix发⾏版中也越发常见（译注：Linux）。没有官⽅规范和单⼀⽀配应⽤来创建⽂件系统两个因素合并在⼀起，使得难以区分应⽤指定的功能和⽂件系统通⽤的功能。例如，存在着Microsoft所不使⽤的初始化⽂件系统的⽅法，然⽽这种⽅法的结果是否被认为是⼀个“合法的NTFS”⽂件系统还难以定论。Microsoft在每⼀次新发布Windows系统的时候都会更改⽂件系统内部，我将会在这⾥指出这些改变。
⼀切都是⽂件
为了了解NTFS的设计，⼀个最重要的概念是⼀切重要的数据都被分配为⽂件。这包括其他⽂件系统通常隐藏起来的基本的⽂件系统管理数据。事实上，包含管理数据的⽂件可以存在放卷的任何位置，和
普通⽂件⼀样。也就是说，NTFS⽂件系统并不像其他⽂件系统那样有⼀个特定的布局。整个⽂件系统被认为是⼀个数据区，每⼀个扇区都可以分配给⼀个⽂件。唯⼀不变的布局是每⼀个卷开始的⼏个扇区，包含有引导扇区和引导代码。
MFT概念
主⽂件表（MFT）是NTFS的⼼脏，这是因为它包含所有⽂件和⽬录的信息。每⼀个⽂件和⽬录在表中⾄少有⼀个⼊⼝（Entry），entry本⾝很简单。每⼀个entry都是1KB⼤，但是只有前42字节有定义的⽤途。剩余的空间⽤来存储属性（Attributes），属性是很⼩的具有特性⽤途的数据结构。例如，有⼀个属性⽤来保存⽂件的名称，另⼀个属性⽤来保存⽂件的内容。图11.1⼀个MFT entry的基本布局，包括头信息和三个属性。
图11.1 ⼀个MFT entry，有⼀个⼩头部，剩余的部分⽤来存储不同的属性。这个entry有三个属性。
Microsoft称每⼀个表中的entry为⼀个⽂件记录，但是我想把每⼀个entry简称为MFT entry，这样更便于记忆。每⼀个entry都基于其在表中的位置有⼀个地址，从0开始。所有的entry的⼤⼩都是1024字节，不过实际的⼤⼩定义在引导扇区中。
如NTFS中的所有⼀切⼀样，MFT也是⼀个⽂件。导致这个令⼈困惑的是MFT有⼀个它⾃⼰的entry。
表中第⼀个entry名字叫做$MFT，它描述了MFT在磁盘上的位置。实际上，这是唯⼀描述MFT在磁盘上的位置的地⽅；也就是说，你需要处理这个entry才能得知MFT的布局和⼤⼩。MFT的起始位置在引导扇区给出，引导扇区始终是⽂件系统的第⼀个扇区。我们可以在图11.2看到这个，如何使⽤引导扇区到第⼀个MFT entry，它显⽰出MFT被分为碎⽚，有32到34和56到58的簇组成。类似于FAT，NTFS使⽤簇，簇由连续的扇区组成。
图11.2 引导扇区和$MFT的关系，⽤来确定MFT的布局。
在Microsoft实现的NTFS中，MFT开始保持尽量⼩的尺⼨，当需要更多的entry时扩展MFT。理论上说，操作系统可以在创建⽂件系统的时候创建固定数量的entry，但是Microsoft实现的动态特性允许很⽅便的通过分卷扩展⽂件系统容量。Microsoft在MFT entry创建后不删除它们。
MFT entry内容
每⼀个MFT entry的⼤⼩定义在引导扇区之中，但是Microsoft使⽤的所有版本都使⽤1024字节⼤⼩。数据结构开始的42个字节包含12个域，剩余的982字节没有特定的结构，可以⽤属性填充。你可以把⼀个MFT entry想想为⼀个⽤来存放你物品的⼤盒⼦。盒⼦外⾯是你的基本信息，⽐如你的名字和地址。基本信息等价于MFT entry的固定域。盒⼦⾥⾯⼀开始是空的，但是它可以⽤来保存任何⽐它⼩的容器。这⾮常像MFT entry没有内部结构并且它含有⼀些包含特定信息的属性。
每⼀个MFT entry的第⼀个域是签名，⼀个标准的entry是ASCII字符串“FILE”，如果⼀个entry⾥⾯发现了错误，它可能含有字符
串“BAAD”，还有⼀个标志域⽤来标识这个entry是否使⽤、这个entry是否是⼀个⽬录。⼀个MFT entry的分配状态也可以通过$MFT⽂件的$BITMAP属性来检查，详见第13章。
如果⼀个⽂件⽆法把它的所有属性放进⼀个entry，它可以使⽤多个entry。当这种情况发⽣的时候买第⼀个entry被称为基本⽂件记录，或者基本MFT entry，后续的每⼀个entry都在它的固定域保存有基本entry的地址。
第13章显⽰了⼀个MFT entry的数据结构，并分解了我们的⽰例⽂件系统镜像。
MFT entry 地址
每⼀个MFT entry都使⽤⼀个48位的顺序地址，第⼀个entry地址是0。MFT最⼤地址随着MFT的增长⽽增⼤，它的值由$MFT的⼤⼩除以每⼀个entry的⼤⼩来计算。Microsoft称这个顺序地址为⽂件编号（File number）。
每⼀个MFT entry还有⼀个16位的顺序号，当entry分配的时候这个顺序号增长。例如，想象⼀下MFT entry313的顺序号是1.entry313的⽂件删除了，然后这个entry被分配给⼀个新的⽂件。当这个entry被
重新分配，它得到了⼀个新的顺序号2。MFT entry和顺序号组合起来，顺序号放在⾼16位，组成了⼀个64位的⽂件参考地址，见图11.3。
图11.3 MFT地址和顺序号组成⼀个⽂件参考地址的例⼦。
NTFS使⽤⽂件参考地址来引⽤MFT entry，这是由于顺序号使得检查⽂件系统是否处于⼀种损坏状态变得容易。例如，如果系统在⼀个⽂件的数据结构被分配的时候崩溃了，顺序号可以⽤来判断⼀个数据结构是否包含MFT entry，是因为上⼀个⽂件使⽤了它还是它是新⽂件的⼀部分。我们也可以⽤它来恢复被删除的内容。例如，如果我们有⼀个未分配的数据结构，⾥⾯有⽂件参考号，我们可以判断这个数据结构被使⽤以来MFT entry是否被重新分配过。顺序号在信息挖掘中有很⼤的作⽤，但是在本章为简单起见，我将主要讨论⽂件号，或者MFT entry地址。
⽂件系统元⽂件
由于卷的每⼀个字节都被分配给了⽂件，必定有⽂件保存了⽂件系统的管理数据。Microsoft称它们为元⽂件，但这样会导致困惑，因为我们还要讨论⽂件元数据。我将会称这些特殊⽂件为⽂件系统元⽂件。
Microsoft保留了前16个MFT entry作为⽂件系统元⽂件（Microsoft⽂档声称只保留了前16个entry，但
是实际上第⼀个⽤户⽂件或者⽬录从entry24开始。entry17到23作为缓冲entry防⽌预留的不够⽤导致溢出），这些保留并且未⽤的entry被置为分配状态并且只有基本的信息。每个⽂件系统元⽂件都列在根⽬录，尽管通常情况下普通⽤户是看不到它们的。每⼀个⽂件系统元⽂件的名字都由“$”开始，并且第⼀个字母⼤写。我们将在第12章讨论每⼀个⽂件系统元⽂件，但是我们现在把它们列在表11.1作为⼀个⽅便参考。
表11.1标准的NTFS⽂件系统元⽂件
Entry File Name Description
0$MFT MFT⾃⾝的entry
1$MFTMirr含有MFT起始的⼏个entry的备份
2$LogFile含有元数据事务的⽇志
3$Volume含有卷信息
4$AttrDef含有属性信息
5.⽂件系统根⽬录
6$Bitmap⽂件系统簇的分配状态
7$Boot引导扇区和⽂件系统引导代码
8$BadClus含有坏扇区的簇
9$Secure还有安全和访问控制相关信息
10$Upcase含有每⼀个Unicode字符的⼤写形式
11$Extend含有可选扩展⽂件的⽬录。
MFT entry属性概念
⼀个MFT entry只有很少的内部结构，它的⼤部分空间都被⽤来存储属性，属性是⽤来存储特定类型数据的数据结构。有许多类型的属性，每种都有其独特的内部结构。例如有⽤于⽂件名、⽇期和时间乃⾄其内容的属性。这是NTFS相较于其它⽂件系统的不同之处之⼀。⼤部分⽂件系统仅⽤来读写⽂件内容，⽽NTFS读写属性，属性的⼀种包含有⽂件内容。
想象⼀下我们之前把MFT entry⽐喻成⼀个开始是空的⼤盒⼦，⽽属性则是在这个⼤盒⼦之中的⼩盒⼦，
这些⼩盒⼦有任意的形状以最有效的存放物品。例如，⼀顶帽⼦可以存储在⼀个短圆盒中，⼀张海报可以存储在⼀个长圆筒中。
尽管每种属性都保存着不同类型的数据，所有的属性都有两个部分：头部和内容。图11.4显⽰了⼀个MFTentry有四个头部和内容对（译注：应该是三个，怀疑作者笔误）。头部是所有属性通⽤的。内容和属性类型相关，并且可以是任意⼤⼩。如果我们从盒⼦来类⽐，每⼀个⼩盒⼦外⾯都有相同的基本信息，但是每个盒⼦形状都不⼀样。
图11.4 ⽰例MFT entry，标记了头部和内容的位置。
属性头部
属性头部标识了属性的类型、⼤⼩和名称。头部还有是否压缩和加密的标识。属性类型是⼀个数值的标识⽤来标识数据的类型，我们将会在“标准属性类型”⼀节讨论缺省的属性类型。⼀个MFT entry可以有多个相同类型的属性。
有些属性可以被赋予⼀个名字，以UTF-16的Unicode字符串的形式存储在属性头部。属性同时还有⼀个在此MFT entry中唯⼀的标识值。如果⼀个entry有多个同⼀类型的属性，这个标识值可以⽤来区分它们。属性头数据结构将会在第13章“属性头”中给出。
属性内容
属性的内容可以是任意格式任意⼤⼩。例如，⼀种属性被⽤来存储⽂件的内容，所以其⼤⼩可能是⼏个MB乃⾄数个GB。将这么多数据存储在仅有1024字节⼤⼩的MFT entry中是不切实际的。
为了解决这个问题，NTFS提供了两种存储属性内容的位置。常驻属性将它的内容和头部⼀同存储在MFT entry之内。这仅适⽤于⼩属性。⾮常驻属性将其内容存储在⽂件系统的簇中。属性的头部中标识了这个属性是常驻的还是⾮常驻的。如果⼀个属性是常驻的，则其内容紧跟头部。如果⼀个属性是⾮常驻的，头部将会给出簇地址。图11.5我们看到之前给出的MFT entry例⼦，不过这次它的第三个属性太⼤了⽆法放⼊MFT，所以被放到了829号簇中。
图11.5 MFT entry例⼦，第三个属性变得太⼤所以变成了⾮常驻。
⾮常驻属保存在cluster runs（译注：run在这⾥很难到⼀个恰当的中⽂词汇，姑且不翻译了）中，由连续的簇构成，⽽每⼀个run由起始簇地址和run长度来描述。例如，如果⼀个属性分配了48、49、50、51和52这⼏个簇，则它有⼀个run，这个run开始于簇48，长度为5.如果这个属性还分配了簇80和81，则它有第⼆个run，起始于80长度为2。第三个run可能起始于簇56长度为4.可以看图11.6。
图11.6 ⽰例runlist，有三个描述分配簇的run。
在本书中，我们区分了不同类型的地址。例如，我们定义了⽂件系统逻辑地址是⽂件系统数据单元的地址，⼆⽂件逻辑地址是相对于⽂件起始的地址。NTFS对这些地址使⽤了不同的术语。逻辑簇编号（Logical Cluster Number，LCN）等价于⽂件系统逻辑地址，虚拟簇编号（Virtual Cluster Number，VCN）等价于⽂件逻辑地址。
NTFS使⽤VCN到LCN的映射来描述⾮常驻属性的run。回到刚才的例⼦，这个属性的run显⽰了VCN地址0到4映射到了LCN地址48到52，VCN地址5到6映射到了LCN地址80到81，VCN地址7到10映射到了LCN地址56到59。runlist的数据结构将会在第13章“属性头”中给出。
标准属性类型
到⽬前为⽌我们已经讨论了属性类型的⼀般术语。现在我们要看看⼀些标准属性的基础知识。它们之中的⼤部分将会在第12章中详细讨论。
之前我们已经提及，每⼀种属性类型都被定义了⼀个编号，微软使⽤这个编号对⼀个entry中的属性进⾏排序。标准属性被赋予了缺省的类型值，但我们稍后将会看到这可以在$AttrDef⽂件系统元⽂件中重定义。除了编号之外，每⼀个属性类型有⼀个名字，都是⼤写并且
以“$”开头。部分缺省属性类型和它们的标识在表11.2中给出。不是所有的属性类型和标识都会出现在每⼀个⽂件之中。更详细的描述请看第12章，数据结构详见第13章。
表11.2 缺省的MFT entry属性类型。
（译注：Live Writer太，粘贴表格蛋都碎了，暂且略过）
⼏乎每⼀个被分配的MFT entry都有$FILE_NAME和$STANDARD_INFORMATION类型的属性。⼀个例外是⾮基础MFT entry（译注：base MFT entry），稍后将会讨论。$FILE_NAME属性包含有⽂件的名字、⼤⼩和时间信息。$STANDARD_INFORMATION属性含有时间、所有关系和安全信息。后者（译注：$STANDARD_INFORMATION）存在于每⼀个⽂件和⽬录的原因是由于其含有⽤于确保数据安全和配额的数据。在抽象的意义上，在此属性中并⽆必要的数据，但⽂件系统的应⽤程序层功能要求这些数据。这两个属性都是常驻的。
每⼀个⽂件都有⼀个$DATA 属性，其包含有⽂件的内容。如果内容尺⼨超过⼤约700字节，它就会变成⼀个⾮常驻属性，保存到外⾯的簇中。当⼀个⽂件含有多于⼀个$DATA 属性时，这些多出的属性有时被称为附加数据流（alternate data streams，ADS）。当创建⽂件时创建的缺省$DATA并没有名字，但是多出的$DATA属性必须有。注意属性名字和类型名字是不同的。例如，$DATA是属性类型名，属性的名字可能是“fred”。有些⼯具，包括The Sleuth Kit (TSK)，会给缺省的$DATA属性指定⼀个叫做“$DATA”的名字。
每⼀个⽬录都有⼀个$INDEX_ROOT属性，这个属性含有其包含的⽂件和⽬录的信息。如果这个⽬录
很⼤，$INDEX_ALLOCATION和$BITMAP属性也⽤于存储信息。令事情更复杂的是，⼀个⽬录也可以在$INDEX_ROOT之外还含有额外的$DATA属性。也就是说，⽬录可以同时存储⽂件内容和其所包含的⽂件和⼦⽬录的列表。$DATA属性可以存储应⽤程序或者⽤户想存储的任何数据。⼀个⽬录的$INDEX_ROOT和$INDEX_ALLOCATION属性通常其名字是“$I30”。
图11.7 显⽰了我们之前演⽰的⼀个MFT entry，它的属性被赋予了类型和名字。它有三个标准⽂件属性。在这个例⼦中，所有的属性都是常驻的。
图11.7 我们的MFT entry例⼦，属性被加上了名字和标识。
其他属性概念
上⼀节我们讨论了适⽤于所有NTFS属性的基本概念。不过不是所有的属性都是基本的，本节我们将会看到更⾼级的概念。特别的，我们将会看到当⼀个⽂件有太多的属性时将会发⽣什么，我们也会看到⽂件的属性内容被压缩和加密地⽅法。
基础 MFT entry（base MFT entry）
⼀个⽂件最多可以有65536个属性（由于标识符是16位的），所以其可能需要多于⼀个MFT entry来保存它的所有的属性的头部（即便是⾮常驻属性也需要它们的头部保存在MFT entry内部）。当附加的M
FT entry被分配给⼀个⽂件的时候，原来的MFT entry被称为基础MFT entry。⾮基础entry会在它们的MFT entry域中保存有基础MFT entry的地址。
基础MFT entry有⼀个$ATTRIBUTE_LIST类型的属性，这个属性含有⽂件的每⼀个属性和MFT地址，以便于查到它们。⾮基础MFT entry没有$FILE_NAME和$STANDARD_INFORMATION属性。我们将会在第12章“元数据分类”中详细讨论$ATTRIBUTE_LIST属性。
稀疏属性
NTFS可以降低⽂件的空间需求，这是通过将某些⾮常驻$DATA属性的数据保存为稀疏来实现的。稀疏属性是那些全为零的簇没有写⼊磁盘的属性。作为替代，⼀个特殊的run⽤来保存零簇（译注：含有全零数据的簇）。⼀般来说，⼀个run含有起始簇位置和长度，但是⼀个稀疏run只含有长度没有起始位置。有⼀个标志指出⼀个属性是稀疏的。
例如，假设⼀个⽂件占⽤了12个簇。起始的五个簇⾮零，接下来的三个簇都是零，最后的四个簇⾮零。当它保存为⼀个普通的属性，⼀个长度为12的run将会被创建出来以保存这个⽂件，如图11.8A所⽰。当保存为稀疏属性，将会有三个run被创建出来，并且只有9个簇被实际分配，如图11.8B所⽰。
图11.8 ⼀个12簇长的⽂件被保存为（A）普通布局或，（B）稀疏布局，有三个簇在稀疏run中。
压缩属性
NTFS允许属性被保存为压缩格式，尽管实际的算法并没有公开给出。注意这是⼀个⽂件系统级别的压缩，并不是⼀个通过诸如zip或者gzip 等外部应⽤程序实现的应⽤级压缩。微软表⽰只有⾮常驻的$DATA属性会被压缩。NTFS通过稀疏run和压缩数据来减少磁盘空间需求。属性头有⼀个标识来确定其是否压缩，$STANDARD_INFORMATION和$FILE_NAME属性内的标识也显⽰了这个⽂件是否含有压缩属性。
属性内容压缩之前，数据被划分成等⼤的块，称为压缩单元。压缩单元的⼤⼩在属性头中给出。有三种情形会发⽣在每个压缩单元中：
1. 所有的簇都是零，在这种情况下，稀疏run被创建出来⽤来保存这个压缩单元⼤⼩的数据，不需要磁盘空间。
2. 压缩过后，压缩结果需要同样数量的簇来保存（也就是说，数据压缩率很低）。在这种情况下，压缩单元没有压缩，⼀个run被⽤来保
存原始数据。
3. 压缩过后，压缩结果使⽤较少数量的簇。在这种情况下，数据被压缩并被保存在⼀个run中。⼀个稀
疏run紧跟这个压缩run以确保整
个run的长度等于压缩单元的簇数量。
让我们以⼀个简单的例⼦来检验每⼀种场景。假设压缩单元⼤⼩事16个簇，并且我们有⼀个长度为64个簇的$DATA属性，见图11.9。我们把数据切分为四个压缩单元并检查每⼀个。第⼀个单元压缩为16个簇，所以它没有压缩。第⼆个单元全为零，所以创建了⼀个16簇的稀疏run，没有分配实际的簇。，第三个单元压缩成了10个簇，所以压缩后的数据以10个簇的run写⼊到磁盘，并且添加了⼀个6个簇的稀疏run。最后⼀个单元压缩为16个簇，所以他没有压缩，创建了⼀个16簇的run来保存它。
图11.9 ⼀个属性有两个压缩单元没有被压缩，⼀个单元稀疏，⼀个单元压缩为10个簇。
当操作系统，或者取证⼯具读取这个属性，它们会发现压缩标志，并且run被组织成压缩单元⼤⼩的块，第⼀个run的⼤⼩和压缩单元⼀样，所以我们知道它没有被压缩。第⼆个run的⼤⼩和压缩单元⼀样，并且是稀疏的，所以我们知道它们是16个簇的零。第三个和第四个run组成了⼀个压缩单元，我们发现它只需要10个簇也就是需要解压缩，最后⼀个run⼤⼩和压缩单元⼀样，也就是没有压缩。
最后⼀个例⼦太简单了，所以我将会演⽰⼀个更具挑战性的⽂件，见图11.10，之所以更复杂是由于初始的布局并不是按照压缩单元来分配的。为了处理这个⽂件，我们⾸先需要重新组织这6个run中的数
据并将数据分配为16个簇的压缩单元中。在合并了碎⽚化的run之后，我们看到有⼀个含有内容的run，⼀个稀疏run，⼀个内容run，另⼀个稀疏run。合并的数据被组织为压缩单元，我们将会看到，前两个单元没有稀疏run，也没有被压缩。第三个和第五个单元有稀疏run，被压缩了。第四个单元是稀疏的，相应的数据全为零。
图11.10 ⼀个将要被压缩的属性，它的run碎⽚化并且没有符合压缩单元边界。
加密属性
NTFS提供属性内容被加密的能⼒。这⼀节将给出⼀个其实现和保存磁盘上形式的概要。理论上说，任意属性都可以加密，但是Windows仅允许$DATA属性被加密。当⼀个属性被加密，只有其内容被加密，属性头没有加密。会创建⼀个$LOGGED_UTILITY_STREAM属性给⽂件，其含有解密数据所需要的密钥。
在Windows中，⽤户可以选择加密特定的⽂件或者⽬录。⼀个加密的⽬录没有任何加密数据，但是在这个⽬录中创建的⽂件或者⽬录将会被加密。⼀个被加密的⽂件或者⽬录将会在$STANDARD_INFORMATION属性中设置⼀个特殊的标志，每⼀个被加密的属性都会在其属性头设置⼀个特殊的标志位。
密码学常识
在我们讨论NTFS的加密实现之前，我将会简单介绍⼀下密码学的基本概念。加密过程是使⽤加密算法和密钥将明⽂变换为密⽂。解密过程是使⽤解密算法和密钥将密⽂变换为明⽂。如果有⼈拿出密⽂，那么在没有密钥的情况下应该是⽆法获知明⽂内容的。
>无法复制文件

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。