44、磁盘文件系统与数据获取全解析

磁盘文件系统与数据获取解析
于 2025-09-04 16:30:19 发布
阅读量37 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： 深入Kali安全测试精髓 文章标签： 磁盘文件系统 数据获取 ext4
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/nginx7reverse/article/details/151355246

磁盘文件系统与数据获取全解析

1. 文件系统基础

在创建分区后，需要额外的信息来组织文件，这就是文件系统。Linux 历史上常用 ext 系列文件系统，当前版本是 ext4，它基于原始的 Unix 文件系统，具有相同的通用结构。

文件系统的核心在于信息的组织。存储文件需要一定的开销，因为文件系统要知道数据的位置、文件名、所有者、权限以及日期/时间信息。大文件可能需要分散存储在磁盘的多个区域，这就要求文件系统知晓这些块的位置，并且能够关联不同的信息，比如文件所在的目录。格式化文件系统时，会为文件信息表和数据块分配空间，同时也会为所有重要的数据结构分配备份空间。

在基于 Unix 的文件系统中，文件信息存储在 inode 中。inode 是一种数据结构，包含了文件系统对象（如文件、特殊文件、设备和目录）的相关信息。每个 inode 包含以下内容：
- 文件所在设备的标识号
- 文件序列号
- 文件模式（即文件的权限集）
- 文件所有者的用户标识号
- 文件所属组的组标识号
- 文件大小
- 修改、访问和创建时间的时间戳
- 与文件关联的块数
- 指向该 inode 的文件名数量的链接计数

需要注意的是，inode 中没有文件名。这是因为在这些文件系统中，文件名和数据是分离的，多个文件名可以指向同一个 inode。每个指向 inode 的文件名都会增加链接计数，当链接计数为 0 时，文件不再被使用。要获取文件名，需要查看目录项。在类 Unix 操作系统中，所有操作都从根目录 / 开始，与 Windows 系统不同，Windows 可能有多个带有不同盘符的驱动器。

Windows 系统过去使用文件分配表（FAT）文件系统，这是一种非常基础的文件系统，本质上是一个逻辑块列表，用于指示块是否正在使用。当 Windows 和 Windows NT 在 Windows XP 下合并为一个单一的代码库后，Windows 安装使用了新技术文件系统（NTFS），桌面系统至今仍在使用，而服务器安装则使用弹性文件系统（ReFS）。NTFS 使用主文件表（MFT）来存储与文件相关的所有元数据，包括权限和磁盘上的位置。由于每个 MFT 条目较大，为 1024 字节，非常小的文件实际上可能存储在 MFT 条目中，而不是在引用的数据块中。

2. 无磁盘创建磁盘

可以使用常见的 Linux 实用程序从文件创建磁盘，这样可以创建一个占用空间小且无需单独磁盘的测试对象。具体步骤如下：
1. 使用 dd 命令创建一个空文件： 

dd if=/dev/urandom of=disk.img bs=1M count=100

这将创建一个 100 MB 的文件，其行为类似于磁盘。
2. 使用 fdisk 或 parted 创建分区。以下是使用 fdisk 在空文件中创建新分区的示例： 

┌──(kilroy@badmilo)-[~]
└─$ fdisk sparse.disk

Welcome to fdisk (util-linux 2.39.3).
Changes will remain in memory only, until you decide to write 
them.
Be careful before using the write command.

Command (m for help): n
Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1):
First sector (2048-204799, default 2048): 2048
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-204799, 
default 204799): 
204799

Created a new partition 1 of type 'Linux' and of size 99 MiB.

Command (m for help): w
The partition table has been altered.
Syncing disks.
  1. 分区创建完成后，需要对其进行格式化。由于没有创建设备文件，需要使用偏移量。 fdisk 提供了分区位置的偏移量，因此可以使用以下命令创建文件系统： 
mkfs.ext3 -E offset=2048 sparse.disk

这将在磁盘上从 2048 字节的偏移量处开始创建文件系统。
4. 如果要将文件复制到新的文件系统中，需要将分区挂载到挂载点（目录）。这需要管理员权限，因为使用文件需要回环挂载，这需要一个回环设备。使用偏移量进行回环挂载的命令如下： 

sudo mount -o loop,offset=2048 sparse.disk local

其中 local 是作为挂载点创建的目录。

3. 磁盘映像的获取

如今的磁盘容量很大，但大部分可能是空闲空间。这主要有两个原因：一是可能没有足够的数据来填满数 TB 的磁盘空间；二是存在松弛空间（slack space）。例如，文件系统以 8K 为单位分配空间，一个 1584 字节的文件会被分配超过其实际所需五倍的空间，这些未使用的空间就是松弛空间。当文件增长到超过 8K 时，会再分配一个 8K 的空间，从而留下更多的松弛空间。

从取证的角度来看，松弛空间非常重要。当文件被删除或移动时，磁盘上的字节不会被擦除或更改，除非使用专门的文件粉碎应用程序。新文件会占用这些磁盘空间并覆盖这些块，如果块没有被完全使用，之前文件的数据会保留在松弛空间中，这些数据可以被恢复。

在获取磁盘映像进行调查或分析时，需要获取磁盘上的所有数据，因为数据可能存在于传统文件之外。使用操作系统内置的复制命令复制磁盘不会复制所有数据，它只会复制文件数据，并且可能导致目标驱动器上的分配和位置不同。因此，需要进行按位复制。可以使用 dd 命令来完成这个任务，以下是示例： 

┌──(kilroy@badmilo)-[~]
└─$ sudo dd if=/dev/sdb of=extdisk.img bs=1M
102+0 records in
102+0 records out
106954752 bytes (107 MB, 102 MiB) copied, 0.0985419 s, 1.1 GB/s

┌──(kilroy@badmilo)-[~]
└─$ sudo dd if=/dev/sdb1 of=extpart.img
206848+0 records in
206848+0 records out
105906176 bytes (106 MB, 101 MiB) copied, 0.246812 s, 429 MB/s

第一个示例复制了整个磁盘，第二个示例复制了单个分区。默认情况下， dd 每次抓取 512 字节，使用较大的读取大小可以减少读写次数，提高复制效率。

为了验证源磁盘和复制的磁盘映像是否相同，可以使用加密哈希。虽然 MD5 哈希可能会产生碰撞，但对于我们的目的来说，足以判断它们是否相同。不过，具有更大哈希空间的哈希算法更可取，而且生成速度也不慢。以下是使用 md5sum 和 sha1sum 获取磁盘和磁盘映像加密哈希的示例： 

┌──(kilroy@badmilo)-[~]
└─$ sudo md5sum /dev/sdb
aa70cf471954396111045c842c5a47c7  /dev/sdb

┌──(kilroy@badmilo)-[~]
└─$ md5sum extdisk.img
aa70cf471954396111045c842c5a47c7  extdisk.img

┌──(kilroy@badmilo)-[~]
└─$ sudo sha1sum /dev/sdb
4fae147cd3c9d5c792da976bb1cdfa4dab31e995  /dev/sdb

┌──(kilroy@badmilo)-[~]
└─$ sha1sum extdisk.img
4fae147cd3c9d5c792da976bb1cdfa4dab31e995  extdisk.img

为了避免分两步操作（获取磁盘映像和获取加密哈希），可以使用 dcfldd ，它是 dd 实用程序的扩展，能够在复制过程中生成加密哈希。以下是使用 dcfldd 的示例： 

┌──(kilroy@badmilo)-[~]
└─$ sudo dcfldd if=/dev/sdb of=extdisk.img bs=1M hash=sha256

Total (sha256): 
186c35799b70a58c5984c311bd7ff8b9e59fd6e57648f307ef1c406f4b9011a1

102+0 records in
102+0 records out

┌──(kilroy@badmilo)-[~]
└─$ sha256sum extdisk.img
186c35799b70a58c5984c311bd7ff8b9e59fd6e57648f307ef1c406f4b9011a1  
extdisk.img

另一个与 dcfldd 功能类似的工具是 dc3dd 。 dc3dd 适用于处理具有特定模式的文件集合，例如 Linux 日志文件，通常会通过在文件名后附加数字来进行轮转。使用 dc3dd 可以指定输入源的模式，将这些文件合并为一个输出文件，同时获取结果文件的加密哈希，确保日志文件不被篡改。以下是使用 dc3dd 聚合文件的示例： 

┌──(kilroy@badmilo)-[~]
└─$ sudo dc3dd ifs=/var/log/boot.log.1 of=boot.log hash=sha256

dc3dd 7.2.646 started at 2024-02-14 13:23:08 -0500
compiled options:
command line dc3dd ifs=/var/log/boot.log.1 of=boot.log hash=sha256
sector size: 512 bytes (assumed) 37462 bytes ( 37 K ) copied ( 100% 
),   0 s, 353 K/s

input results for files `/var/log/boot.log.1':
   73 sectors + 86 bytes in

   bc47a998cb34d70888d602aa36eab599f5033b2ab94b8b6172cf2badf56e654e 
(sha256)

output results for file `boot.log':
   73 sectors + 86 bytes out

dc3dd completed at 2024-02-14 13:23:08 -0500

┌──(kilroy@badmilo)-[~]
└─$ sudo sha256sum /var/log/boot.log.1
0a68ad45c41e64e13f80600d6e77cf9dfe6287517fb3bd5c77be9f447f036b1b  ↩
/var/log/boot.log.1
4. 磁盘映像内容查看工具

在获取磁盘映像并验证输出后，对于法医证据来说，保持数据完整性非常重要，这就是使用加密哈希的原因。一种简单的访问磁盘映像中文件的方法是挂载映像，但这样做会改变映像文件，因为操作系统会更改访问时间，从而改变文件系统中的元数据，即使是单个位的更改也会导致不同的加密哈希。为了避免这种情况，可以将磁盘映像以只读方式挂载，但这并不能完全保证数据不变。以下是示例： 

┌──(kilroy@badmilo)-[~]
└─$ sha256sum sparse.disk
763f84016cca9f829de5f980e98d16b2328c48fd3cec78b96cb23d0c87e9d2d0  
sparse.disk

┌──(kilroy@badmilo)-[~]
└─$ sudo mount -o loop,offset=2048 sparse.disk local

┌──(kilroy@badmilo)-[~]
└─$ sudo umount local

┌──(kilroy@badmilo)-[~]
└─$ sha256sum sparse.disk
fe431e67967c9d237259885ea220a07e188c1b0bf1e34dba2149be1915e865d5  
sparse.disk

┌──(kilroy@badmilo)-[~]
└─$ sudo mount -o ro,loop,offset=2048 sparse.disk local

┌──(kilroy@badmilo)-[~]
└─$ sudo umount local

┌──(kilroy@badmilo)-[~]
└─$ sha256sum sparse.disk
fe431e67967c9d237259885ea220a07e188c1b0bf1e34dba2149be1915e865d5  
sparse.disk

另一种查看磁盘映像内容的方法是使用 The Sleuth Kit（TSK）工具集。以一个包含两个分区的磁盘映像为例，由于这是一个完整的磁盘映像且引导记录完好，需要知道分区的偏移量才能使用 TSK 中的其他工具。可以使用 fdisk 或 mmls （TSK 的一部分）来获取这些信息。以下是 fdisk 和 mmls 的输出示例： 

┌──(kilroy@badmilo)-[~]
└─$ fdisk -l mydisk.img
Disk mydisk.img: 128 MiB, 134217728 bytes, 262144 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x1ecaf971

Device      Boot  Start    End Sectors  Size Id Type
mydisk.img1        2048 130000  127953 62.5M 83 Linux
mydisk.img2      131072 262143  131072   64M  b W95 FAT32

┌──(kilroy@badmilo)-[~]
└─$ mmls mydisk.img
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

      Slot      Start        End          Length       Description
000:  Meta      0000000000   0000000000   0000000001   Primary Table 
(#0)
001:  -------   0000000000   0000002047   0000002048   Unallocated
002:  000:000   0000002048   0000130000   0000127953   Linux (0x83)
003:  -------   0000130001   0000131071   0000001071   Unallocated
004:  000:001   0000131072   0000262143   0000131072   Win95 FAT32 
(0x0b)

fdisk 的输出可能更易于阅读，但 mmls 显示了分区之间的未分配空间。

可以使用 fls 工具获取分区的基本文件列表。以下是示例： 

┌──(kilroy@badmilo)-[~]
└─$ fls -o 2048 mydisk.img
d/d 11: lost+found
r/r 12: 8572.c
r/r 13: elfbowling
r/r 14: procdump64.exe
r/r 16: payload.exe
r/r 17: ls
r/r 18: oreilly.png
r/r 15: plugins.txt
V/V 32513:      $OrphanFiles

┌──(kilroy@badmilo)-[~]
└─$ fls -o 131072 mydisk.img
r/r 6:  lsass.exe_230809_145713.dmp
r/r 8:  elfbowling
r/r * 10:       life.swift
r/r 12: oreilly.png
r/r 14: .zshrc
r/r 17: zip-password.txt
r/r 19: 8572.c
r/r 22: procdump64.exe
r/r * 25:       .life.swift.swp
r/r * 28:       .life.swift.swx
v/v 2092995:    $MBR
v/v 2092996:    $FAT1
v/v 2092997:    $FAT2
V/V 2092998:    $OrphanFiles

从输出可以看出， lost+found 文件表明是某种 Unix 导向的文件系统，而 $FAT1 和 $FAT2 是基于 FAT 的文件系统的两个文件分配表。

与 Linux 中的 ls 命令类似，在 fls 中添加 -l 选项可以获取包含文件时间的详细列表，显示修改、访问和创建（MAC）时间。以下是示例： 

┌──(kilroy@badmilo)-[~]
└─$ fls -l -o 2048 mydisk.img
d/d 11: lost+found      2023-09-17 10:32:38 (EDT)       2023-09-20 
19:13:51 (EDT)  ↩
2023-09-17 10:40:04 (EDT)       2023-09-17 10:32:38 (EDT)       
122880       1000
r/r 12: 8572.c  2023-09-17 10:40:15 (EDT)       2023-09-17 10:40:15 
(EDT)   ↩
2023-09-17 10:40:15 (EDT)        2023-09-17 10:40:15 (EDT)       2757  
↩
10001000
r/r 13: elfbowling      2023-09-17 10:40:29 (EDT)       2023-09-17 
10:40:29 (EDT)  ↩
2023-09-17 10:40:29 (EDT)       2023-09-17 10:40:29 (EDT)       
152921000    1000
r/r 14: procdump64.exe  2023-09-17 10:40:38 (EDT)       2023-09-17 
10:40:38 (EDT)  ↩
2023-09-17 10:40:38 (EDT)       2023-09-17 10:40:38 (EDT)       
424856       1000  ↩
1000
r/r 16: payload.exe     2023-09-17 10:41:11 (EDT)       2023-09-17 
10:41:11 (EDT)  ↩
2023-09-17 10:41:11 (EDT)       2023-09-17 10:41:11 (EDT)       
166912       1000  ↩
1000
r/r 17: ls      2023-09-17 10:41:31 (EDT)       2023-09-17 10:41:31 
(EDT)   ↩
2023-09-17 10:41:31 (EDT)        2023-09-17 10:41:31 (EDT)       
200440  ↩
10001000
r/r 18: oreilly.png     2023-09-17 10:42:07 (EDT)       2023-09-17 
10:42:07 (EDT)  ↩
2023-09-17 10:42:07 (EDT)       2023-09-17 10:42:07 (EDT)       
1371613      1000  ↩
1000
r/r 15: plugins.txt     2023-09-20 19:09:49 (EDT)       2023-09-20 
19:09:49 (EDT)  ↩
2023-09-20 19:09:49 (EDT)       2023-09-20 19:09:49 (EDT)       
11401000     1000
V/V 32513:      $OrphanFiles    0000-00-00 00:00:00 (UTC)       ↩
0000-00-00 00:00:00 (UTC)    0000-00-00 00:00:00 (UTC)       ↩
0000-00-00 00:00:00 (UTC)   00       0

如果想了解文件系统在磁盘上的结构，可以使用 fsstat 工具。以下是示例： 

┌──(kilroy@badmilo)-[~]
└─$ fsstat -o 2048 mydisk.img
FILE SYSTEM INFORMATION
 --------------------------------------------
File System Type: Ext4
Volume Name:
Volume ID: e2f84ed42055e9883248f29e578ed928

Last Written at: 2023-09-20 19:14:40 (EDT)
Last Checked at: 2023-09-17 10:32:38 (EDT)

Last Mounted at: 2023-09-20 19:13:51 (EDT)
Unmounted properly
Last mounted on: /home/kilroy/mnt

Source OS: Linux
Dynamic Structure
Compat Features: Journal, Ext Attributes, Resize Inode, Dir Index
InCompat Features: Filetype, Extents, 64bit, Flexible Block Groups,
Read Only Compat Features: Sparse Super, Large File, Huge File, Extra 
Inode Size

Journal ID: 00
Journal Inode: 8

METADATA INFORMATION
 --------------------------------------------
Inode Range: 1 - 32513
Root Directory: 2
Free Inodes: 32494

从输出可以看到分区的文件系统类型、最后写入和挂载的时间戳、最后使用的挂载点，以及文件系统内部结构的更多详细信息，包括块组的数量和位置。

综上所述，通过了解文件系统的基本原理、掌握无磁盘创建磁盘的方法、学会获取和验证磁盘映像，以及使用 TSK 工具集查看磁盘映像内容，我们可以更深入地了解磁盘上的数据存储和组织方式，为磁盘数据的调查和分析提供有力支持。

磁盘文件系统与数据获取全解析

5. 文件系统操作流程总结

为了更清晰地展示从创建磁盘到查看磁盘映像内容的整个过程，下面通过一个 mermaid 流程图来呈现： 

graph LR
    A[创建空文件] --> B[创建分区]
    B --> C[格式化分区]
    C --> D[挂载分区]
    D --> E[获取磁盘映像]
    E --> F[验证磁盘映像]
    F --> G[查看磁盘映像内容]

整个流程可以概括为以下几个关键步骤：
1. 创建空文件 ：使用 dd 命令创建一个指定大小的空文件，使其可以模拟磁盘。
2. 创建分区 ：使用 fdisk 或 parted 工具在空文件中创建分区。
3. 格式化分区 ：使用 mkfs 命令对分区进行格式化，需要指定偏移量。
4. 挂载分区 ：使用 mount 命令将分区挂载到挂载点，需要管理员权限。
5. 获取磁盘映像 ：使用 dd 、 dcfldd 或 dc3dd 等工具获取磁盘映像。
6. 验证磁盘映像 ：使用加密哈希工具（如 md5sum 、 sha1sum 等）验证磁盘映像的完整性。
7. 查看磁盘映像内容 ：使用 The Sleuth Kit（TSK）工具集（如 fls 、 fsstat 等）查看磁盘映像中的文件信息。

6. 不同文件系统和工具对比

下面通过表格的形式对比不同文件系统和工具的特点：
| 文件系统/工具 | 特点 | 适用场景 |
| — | — | — |
| ext4 | 基于 Unix 文件系统，具有通用结构，使用 inode 存储文件信息 | Linux 系统，对数据组织和管理有较高要求 |
| FAT | 非常基础的文件系统，使用文件分配表指示块是否使用 | 早期 Windows 系统，简单文件存储场景 |
| NTFS | Windows 桌面系统常用，使用主文件表存储元数据 | Windows 桌面系统，需要存储大量文件和复杂元数据 |
| ReFS | Windows 服务器系统使用，具有弹性和容错能力 | Windows 服务器系统，对数据可靠性要求高 |
| dd | 基本的磁盘复制工具，可按位复制磁盘 | 简单的磁盘复制场景 |
| dcfldd | dd 的扩展，可在复制过程中生成加密哈希 | 需要同时获取磁盘映像和验证完整性的场景 |
| dc3dd | 可处理具有特定模式的文件集合，合并文件并生成哈希 | 处理日志文件等具有规律的文件集合 |
| TSK（fls、fsstat 等） | 专门用于调查磁盘映像和文件的工具集 | 磁盘数据调查和分析，需要保持数据完整性 |

7. 特殊情况处理

在实际操作中，可能会遇到一些特殊情况，下面进行简要说明：
- 松弛空间的利用 ：松弛空间中可能包含已删除或移动文件的数据，对于取证和数据恢复有重要意义。可以使用专门的工具（如数据恢复软件）来尝试恢复松弛空间中的数据。
- 磁盘映像的损坏 ：如果磁盘映像在获取或传输过程中损坏，可能会导致无法正常查看内容。可以使用校验和工具（如加密哈希）来验证磁盘映像的完整性，如果发现损坏，可以尝试重新获取磁盘映像。
- 文件系统的兼容性 ：不同的文件系统在结构和功能上可能存在差异，在跨系统操作时可能会遇到兼容性问题。例如，在 Windows 系统中可能无法直接访问 ext4 文件系统的磁盘映像。可以使用专门的文件系统驱动程序或工具来解决兼容性问题。

8. 总结与展望

通过本文的介绍，我们全面了解了磁盘文件系统的基础知识、无磁盘创建磁盘的方法、磁盘映像的获取和验证，以及使用 The Sleuth Kit（TSK）工具集查看磁盘映像内容的操作。这些知识和技能对于磁盘数据的调查、分析和恢复具有重要意义。

随着信息技术的不断发展，磁盘容量越来越大，文件系统也越来越复杂。未来，我们需要不断学习和掌握新的技术和工具，以应对日益复杂的磁盘数据处理需求。例如，随着固态硬盘（SSD）的广泛应用，需要研究和掌握针对 SSD 的文件系统和数据处理方法；随着云计算和大数据的发展，需要探索如何在分布式环境中进行磁盘数据的调查和分析。

同时，数据安全和隐私保护也越来越受到关注。在进行磁盘数据处理时，需要严格遵守相关法律法规和道德准则，确保数据的安全和隐私。例如，在进行取证和数据恢复时，需要获得合法授权，并采取适当的措施保护数据的隐私。

总之，磁盘文件系统和数据处理是一个不断发展和变化的领域，我们需要持续学习和探索，以适应不断变化的技术和需求。

评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值