harelsegev/INDXRipper

# INDXRipper INDXRipper 是一个用于从 NTFS $I30 索引中提取（carving）文件元数据的工具。它的速度（相对）很快，而且输出结果很容易整合到时间线中！  这是使用 mactime、INDXRipper 和 fls 创建的时间线的一个片段。用于创建此时间线的镜像包含在 [INDXRipper 发布版](https://github.com/harelsegev/INDXRipper/releases)中。下载它并尝试[自己创建时间线吧！](#using-the-sleuth-kit) ## 动机 在 NTFS 中，$INDEX_ALLOCATION 属性用于跟踪哪些文件位于哪些文件夹中。目录的 $INDEX_ALLOCATION 属性为该目录中的每个文件包含一个条目。这些条目被称为索引条目，它们包含了一些文件元数据： * 文件名 * 文件大小 * 文件的分配大小（磁盘上的大小） * 一组 MACB 时间戳 $INDEX_ALLOCATION 属性通常包含大量空闲空间（slack space），这些空间中可能包含已删除文件的索引条目。一个文件的索引条目在其 MFT 记录丢失后可能还会保留很长时间。在空闲空间中寻找索引条目可能有助于你证明系统中曾经存在过某个文件。 有关此痕迹（artifact）更详细的解释，请观看这期 13Cubed 视频： https://www.youtube.com/watch?v=x-M-wyq3BXA ## 安装 使用 Windows 的[打包发布版](https://github.com/harelsegev/INDXRipper/releases)是最简单的入门方式。 ### 创建开发环境 需要 Python 3.9 或更高版本。INDXRipper 应该可以同时兼容 CPython 和 PyPy 实现。PyPy 能实现更好的性能，但它不允许在 Windows 上对已挂载的 NTFS 卷执行操作。 克隆仓库： ``` git clone https://github.com/harelsegev/INDXRipper.git ``` 创建一个 virtualenv 并使用 [pip](https://pip.pypa.io/en/stable/) 安装 construct： ``` cd INDXRipper python3.9 -m pip install virtualenv python3.9 -m virtualenv venv source venv/bin/activate pip install construct==2.10.69 ``` 在虚拟环境中执行 INDXRipper： ``` # 应打印版本信息 venv/bin/python INDXRipper.py -V # 在以 root 用户身份执行时应同样有效 sudo venv/bin/python INDXRipper.py -V ``` ## 使用示例 ``` # 处理挂载并映射为 J: 驱动器的镜像（Windows 打包版本） INDXRipper.exe \\.\J: outfile.csv # 处理完整磁盘镜像，指定 NTFS 分区的偏移量（以扇区为单位） python INDXRipper.py -o 1026048 raw_disk.dd output.csv # 处理分区镜像。无需指定偏移量 python INDXRipper.py ntfs.001 output.csv # 处理活动系统上的 D: 驱动器，--no-active-files 模式，bodyfile 输出，在所有路径前添加 "D:" python INDXRipper.py -m D: -f bodyfile --no-active-files \\.\D: output.bodyfile ``` ### 创建超级时间线 INDXRipper 最好与其他工具结合使用来创建超级时间线。如果你使用 fls 或 MFT 解析器，**--no-active-files** 开关应该会过滤掉时间线中可能不需要的数据。你也可以使用 **--dedup** 开关以及 bodyfile 输出选项。 #### 使用 The Sleuth Kit ``` # 来自 sleuth kit 的 fls fls -o 128 -m C: -r image.raw > temp.bodyfile # INDXRipper 会将其输出追加到 temp.bodyfile 的末尾 INDXRipper -o 128 -m C: -f bodyfile --no-active-files --dedup image.raw temp.bodyfile mactime -z UTC -b temp.bodyfile > image.timeline ``` #### 使用 Plaso ``` # 输出到新文件 INDXRipper.py -o 128 -f bodyfile --no-active-files --dedup image.raw temp.bodyfile # 将输出添加到现有的 plaso 存储文件 log2timeline.py --parsers mactime --storage-file storage.plaso temp.bodyfile ``` 请注意，bodyfile 格式是 sleuthkit 特有的，并且没有完整的文档说明。INDXRipper 的 bodyfile 输出与其并不完全兼容。 ## 功能与细节 ### 基本功能 * 对索引记录和 MFT 记录应用修复（fixup） * 处理扩展记录中的属性 * 根据 MFT 中的数据解析完整文件路径 * 使用设备路径，可在运行中的 Windows NTFS 驱动器上工作 * 所有输出的时间戳均为 UTC ### --no-active-files 开关 在此模式下，INDXRipper 将过滤掉活动文件的已分配条目和空闲空间条目。 空闲空间中的许多条目都是活动文件的旧条目。这些旧条目包含了文件在早期时间点的元数据“快照”。尽管这些信息在某些情况下可能有用，但大多数时候我感兴趣的是已删除的文件。 在 --no-active-files 模式下，这些空闲条目中的**一部分**（并非全部！）会被过滤掉，以防止时间线中的信息过载。过滤规则如下： 对于空闲空间中的每一个条目，INDXRipper 都会扫描目录，查找具有相同文件名的已分配条目。如果找到这样的条目，INDXRipper 会比较这两个条目中的文件引用。如果它们匹配，则不输出该空闲条目。 不过，这只针对活动目录执行。当解析已删除目录的 $INDEX_ALLOCATION 属性时，INDXRipper 会输出它找到的所有条目——包括那些处于“已分配”空间的条目。 ### --skip-deleted-dirs 开关 在此模式下，INDXRipper 将只解析活动目录的 $INDEX_ALLOCATION 属性。 一个已删除的目录可能有一部分簇被覆盖了——可能是被文件覆盖，或者是被另一个目录覆盖。这意味着已删除目录中的索引记录可能被部分覆盖，或者实际上可能属于另一个目录。 在解析已删除目录的 $INDEX_ALLOCATION 属性时，INDXRipper 会根据记录中第一个条目的父文件引用字段，分别为每个索引记录中的文件解析完整路径。这意味着文件应该总是能被放置在它们正确的路径下。 #### 部分路径 某些文件和文件夹可能会被列在 **/$Orphan** 下。这意味着它们已被删除，它们的父文件夹也已被删除，并且无法解析其完整路径。 另一方面，列在 **\** 下的文件——则不一定已被删除。它意味着这些条目是在解析已删除目录中的索引记录时发现的，而 INDXRipper 无法确定这些文件的父目录。 ## 限制 * 该工具可能会给出错误的结果。虽然误报很少见，但[它们是有可能发生的](https://harelsegev.github.io/posts/i30-parsers-output-false-entries.-heres-why/)。 * 部分被覆盖的条目可能无法找到。然而，如果它们被找到了，工具可能会给你提供虚假信息。 * 该工具仅支持 NTFS 版本 3.1 ### 该工具不做的事情 * 该工具不解析 $INDEX_ROOT 属性。 * 该工具不会从未分配空间中提取（carve）Indx 记录。 ## 许可证 [MIT](https://choosealicense.com/licenses/mit/)

标签：NTFS, Python, 数字取证, 数据恢复, 数据雕刻, 无后门, 自动化脚本, 逆向工具