当我在 Windows 8 Consumer Preview 卷上运行 CheckDisk 时,我得到:
> chkdsk /v S:
The type of the file system is NTFS.
Volume label is Windows 8.
WARNING! F parameter not specified.
Running CHKDSK in read-only mode.
CHKDSK is verifying files (stage 1 of 3)...
91392 file records processed.
File verification completed.
28 large file records processed.
0 bad file records processed.
20224 EA records processed. <------------------ huh??
为什么卷上有这么多扩展属性?我以为没人再使用 EA 了……
编辑:
例如,该文件\Windows\CSC\v2.0.6
有一个扩展属性,包含字符串
Ԡ 1X C8A05BC0-3FA8-49E9-8148-61EE14A67687.CSC.DATABASE P X Չ: Չ: ˌΦ]cᑡPcďŠ 4 C8A05BC0-3FA8-49E9-8148-61EE14A67687.CSC.DATABASEEX1 P X _, N0t 08 C8A05BC0-3FA8-49E9-8148-61EE14A67687.CSC.EPOCHEA 8 ͌Φ]cᑡPcďŠ }
这(感谢下面的答案)似乎与客户端离线文件的缓存有关。
然而,似乎大多数其他 EA 都不同——例如文件
\Program Files\WindowsApps
\Microsoft.BingFinance_1.0.1022.0_x64__8wekyb3d8bbwe\pages\ETF\js\ETF.js
并且大多数其他文件(大部分)包含字符串$KERNEL.PURGE.APPXFICACHE
,这似乎不相关。这可能是什么?
答案1
扩展属性在 Windows 中确实有使用,包括内核,它使用它们来跟踪各种安全限制并强制执行这些限制。
看https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/kernel-extended-attributes
值得注意的是,NTFS 的 USN 日志将能够安全地跟踪对文件所做的更改,以便在意外残酷关机(由断电、过热或 BSOD 和重启引起)后可靠的文件系统快照或文件系统恢复。这些是添加到小 EA 流中的短安全记录(通常将其自身存储在 MFT 记录中而不分配任何额外的范围,除非 MFT 记录太小而无法容纳所有流,在这种情况下,它们将插入到分配给“非驻留”属性的单独 NTFS 范围中,这些范围不适合固定大小的 MFT 记录,该记录通常很小,大约 1KB,但某些文件属性将始终适合,包括基本属性和包含超出容量的流的分配范围图的特殊属性,例如常规文件内容的默认“$DATA”流或目录的索引;哪个流适合 MFT 记录取决于 MFT 记录的大小,可以在格式化 MFT 卷时进行调整,但通常为 1KB,即小于用于为范围分配空间的常规“集群”)
内核管理的一些扩展属性是:
“$KERNEL.PURGE.ESBCACHE”:显然这是由“Branch Cache”使用的,以促进远程管理主机上的部署和系统更新,允许域执行自己的策略(而不是默认的本地策略或微软在 Windows 中默认定义的策略)。
“$KERNEL.PURGE.SEC.FILEHASH”:它包含文件内容的强文件哈希(以及使用的哈希算法):这允许文件系统恢复检测内容损坏。
“$KERNEL.PURGE.SEC.CODEINTEGRITY”:这个小 EA 包含代码完整性策略标志
“$KERNEL.SMARTLOCKER.ORIGINCLAIM”:它安全地跟踪创建该文件的应用程序(即其安装程序或包含参考签名的 MSI 包的路径)
“$CI.CATALOGHINT”:它包含 Windows 目录中包含该文件源的软件包的安全 *.cat 文件的名称。诸如“SFC /SCANNOW”或“DISM /Online Cleanup-Image ScanHealth”之类的工具可以检查它们,并且在先前 EA 的帮助下,它将能够安全地识别包含安装文件的原始软件包(如有必要,Windows Update 将能够找到、下载并重新安装这些软件包的副本)。
请不要将最后两个 EA 与 IE(或 Windows 的其他 Web 浏览器)添加到您从 Web 下载的文件上的“Zone.Identifier”相混淆,或者将非归档程序添加到您从下载的 ZIP 或 Cabinet 文件(或其他归档格式)中提取的文件上的“Zone.Identifier”相混淆,方法是从归档/Cabinet 文件本身的“Zone-Identifier”复制它:这些不是 EA,它们存储为“备用数据流”(ADS),是“$DATA”类型的属性(类似于文件的常规内容,只是这个 $DATA 具有非空名称,而文件的常规内容具有空名称);同样,这些 ADS 仅在存储在 NTFS 或兼容文件系统中时才存在,并且它们不是由内核检查,而是由用户界面(主要是在文件资源管理器中)检查,并且在复制到其他地方时并不总是保留(例如,将此类标记文件移动到 ZIP 文件中时)。这些 ADS 非常弱,它们不如 EA 或其他签名系统(如外部安全目录、可执行文件内的 Authenticode 签名或允许在文件常规内容内使用类似签名的某些媒体格式)那么强;为了保护系统,内核不需要并使用这些旧式 ADS,它使用 Authenticode 和其他安全目录,例如在驱动程序数据库或 WinSxS 等 Windows 目录中)。备用数据流已被弃用,但仍在 Web 浏览器中用于此目的,只是作为对用户的提示,但它们不会阻止用户仍可能执行的基本操作,包括绕过 Explorer 向他们显示的警报(但并非总是如此,因为它们经常不被保留)。同样,如果下载的文件使用更强大的签名机制,或者它们是由后台的专门服务下载的(例如使用安全签名目录的 Windows Update 本身),Web 浏览器可能不一定会附加这些“Zone.identifier”ADS。
根据您使用的工具和操作系统功能,或者某些驱动程序,您可能定义了其他 EA。许多安全工具和反恶意软件会将自己的 EA 添加到各种文件或目录中(也有助于这些工具更有效地扫描更改)。
如果您使用 Microsoft Store 或 Windows 上的 AppX 部署工具,还会有额外的 EA 用于设置它们将在其上运行的虚拟环境(例如,每台机器、每个域、每个用户或每个在线“身份”的全局设置,具体取决于您将使用的远程服务或您将与哪个第三方进行通信、写时复制或完全复制、延迟写入或同步写入、共享选项或策略、授予的许可和使用权、在线服务订阅/付款选项的跟踪器;某些应用程序也使用它们,就像在网页上跟踪 cookie 一样,然后会存储特定于某些文件内容或应用程序的个人标识符或偏好,并能够将它们与在线个人资料同步,以便您可以离线使用这些应用程序,至少在给定的一段时间内...)。
如果你使用某些云服务(不仅仅是微软的云服务),它们还可以同步您在本地最常使用的文件的本地副本,同时允许文件在线存档或同步到其他设备)。
通常,EA 非常小(大多数约为 100 字节左右)。NTFS/ReFS(和其他受支持的文件系统)中的任何文件都可以为许多不同的应用程序附加许多 EA。这些 EA 的单独编码方式取决于应用程序。EA 有自己的名称(如可见目录中的常规文件和 ADS 流),但这些名称不打算供人类阅读;因此这些名称是“技术性的”,不使用 Unicode。一些 EA 名称前缀由 Microsoft 在 Windows 文件系统上保留。
这些 EA 是否驻留在 MFT(NTFS 或 ReFS 文件系统)中取决于给定文件中存在的数量。如果它们不适合 MFT 记录,NTFS 将分配一些范围以将它们定位在卷上的其他地方。为文件定义的 EA 列表是它的一个流,就像标准属性、安全属性 (ACL) 或常规内容或附加流(例如,跟踪文件从网络下载并且可能不安全的流,它可能会跟踪其 Web 域或来源 IP,以及如果该域是使用 HTTPS 等安全协议访问的:这允许 Windows 为用户显示授权弹出窗口,或要求用户提升权限;ZIP/CAB 文件具有由 Web 浏览器和安全下载程序添加的此类流;并且如果文件可能是可执行的或具有副作用,则 zip 提取工具还会在每个提取的文件上传播该流,包括 HTML 文件、字体、Javascript、媒体文件或办公文档,使用它们的应用程序将默认以安全模式打开它们,并会提醒用户某些嵌入式组件(如脚本或字体)可能不安全)确实,一些 EA 旨在提供与 OS/2 或 MacOS 的兼容性(只有这些 EA 已被弃用),但仍有其他系统添加并使用它们。而且新的安全系统(包括Windows本身、其内核还是其服务和功能中)不断添加新的安全功能。
EA 是 NTFS(和 ReFS)的一个关键特性。它们也存在于其他非 Windows 文件系统中(包括 Linux 上的 Ext4);对于某些没有原生支持它们的文件系统,它们可能存储在单独的子目录中或具有特殊名称的文件中。EA 通常不会显示在目录内容中(对于实现它们的文件系统),也不计入常规文件大小,因此可以轻松添加/删除它们而不改变常规内容;它们还允许不同的应用程序、服务或操作系统通过安全地关联它们自己的元数据来与相同的文件进行互操作。因此,它们是现有文件系统的安全扩展(大多数时候应用程序不必关心它们,操作系统或其服务将管理它们,通常是出于安全原因和检查)
EA 绝对没有被弃用。事实上,如今它们的使用频率要高得多,而且随着安全解决方案的不断发展,它们也衍生出许多变体(Windows 11 使用了更多的 EA;如果您使用 Azure 服务或加入 AD 域,就会有额外的 EA;如果您使用各种安全工具(而不仅仅是 Microsoft 的安全工具),它们会添加自己的安全工具,一些应用程序还会使用它们在您购买的媒体上存储 DRM 权限跟踪器以及解密密钥(如果需要),以及获得授权的设备的安全签名计数器,您需要登录服务来更新这些签名或删除设备及其授权;EA 有很多可能的用途,不仅仅是为了安全,还可以通过包含特定于给定用途的处理提示和跟踪或统计信息来优化性能;它们还可以用于跟踪备份和复制/镜像,比单个传统“ARCHIVE”位更好;EA 有自己独特的名称,正在创建一种“并行”文件系统,只不过它们通常是可选的,只有需要它们的适当文件或目录才会获得这些将 EA 放置在核心 NTFS/ReFS 文件系统结构中(即驻留在 MFT 记录中,或将其扩展到非驻留特殊属性中,用作容纳更多不适合 MFT 记录的属性的容器)的好处在于,它们的位置是理想的,而不是在卷的其他位置使用单独的存储(这会更慢,特别是在使用网络文件系统或硬盘和磁盘阵列时,因为访问时间:可以在加载基本文件属性的同时非常快速地检索 EA;并且它们更容易动态添加/删除)
答案2
根据 EA 名称“CSC.DATABASE”,人们可能会猜测它与客户端缓存。这也可以解释为什么它们有这么多,因为每个缓存文件可能都有它们来与服务器进行识别。
另外,我认为 EA 的使用并不特别少。我确信它们被 IE 用来识别文件是否“从网络下载”(这使得 Windows 资源管理器在运行文件之前进行询问等)。
答案3
该站点指出 CodeIntegrity 又名 Windows Defender 应用程序控制是 ESBCache 和 CatalogHint 属性的来源。https://www.exploit-db.com/exploits/43162
我认为这比 Branchcache 和 SFC /SCANNOW 的参考更准确。它们可能也使用这些数据,尽管我还没有确凿的证据。
这篇文章解释了大多数 EA 是什么。TL;DR ESBCache 和 CatalogHint 构成了最大的数据量。 https://posts.specterops.io/host-based-threat-modeling-indicator-design-a9dbbb53d5ea