Windows 和 Unix 系统上的内存转储和内核分析

信息技术数字 » 资源 » Windows 和 Unix 系统上的内存转储和内核分析

当操作系统发生恐慌或崩溃时，了解发生了什么的唯一方法是通过内核内存转储及其后续分析。这些转储文件捕获了系统在故障瞬间的内部状态，对于调试复杂错误、调查安全事件或进行取证检查至关重要。

虽然听起来很“底层”，但内存转储分析并非内核开发人员的专属领域。系统管理员、支持工程师甚至安全审计人员如果掌握了合适的工具、不同类型的转储文件以及基本的解读技巧，也能从中受益。我们将带您了解在 Windows、Unix/Linux 和 BSD 系统上使用 WinDbg、crash、kgdb 和 LiME 等工具进行内存转储分析的全过程。

什么是内核内存转储？为什么值得分析它？

内核内存转储（通常称为内核崩溃转储或简称崩溃转储）是一个文件，其中包含系统发生严重故障（例如Unix/Linux 中的内核崩溃或 Windows 中的蓝屏死机 (BSOD)）时内存的完整或部分副本。

实际上，这种类型的转储会保存内核内部结构、调用堆栈、进程上下文和已加载的驱动程序。因此，灾难发生后，可以进行类似于调试运行中系统的灾后分析，而无需承受在生产机器发生故障时进行操作的压力。

深入研究内核转储的原因多种多样：从调试看似随机的错误和间歇性崩溃，到调查系统是否被恶意篡改，或者崩溃是否可能在磁盘上留下敏感信息的痕迹。

除了完整的核心转储之外，还可以对单个进程进行转储（经典的核心转储），这在我们想要将问题限制在特定应用程序或检查对电子邮件或消息客户端等服务的机密性的影响时非常有用。

Windows 系统中内存转储的类型及其用途

在 Windows 系统中，当发生 STOP 错误时，操作系统本身会生成不同类型的转储文件。每种类型的转储文件包含的信息详细程度不同，因此根据问题和磁盘空间限制了解所需的转储文件类型至关重要。

用户环境和许多服务器中最常见的格式之一是 小型内存转储（minidump）它是占用空间最小的，通常位于 %SystemRoot%\Minidump，以及样式文件 MiniMMDDYY-01.dmp.

这个小型转储包含非常具体但重要的信息：STOP 错误代码及其参数、故障时加载的驱动程序列表、停止的处理器的上下文 (PRCB)、涉及的进程和线程的上下文 (EPROCESS 和 ETHREAD 结构) 以及该线程的内核模式调用堆栈。

由于这些基本结构，即使使用小型转储文件，通常也可以确定是哪个驱动程序或模块导致了崩溃，但如果问题源于崩溃时正在运行的线程之外，并且可用的上下文信息有限，则不一定能够追踪整个过程。

Windows 还可以生成内核内存转储和更大的完整转储，其中包含部分或全部物理内存。这些转储对于底层分析、取证调查以及驱动程序或系统本身的高级调试尤其有用。

使用 WinDbg 和 KD 在 Windows 中配置和打开内存转储

要在 Windows 系统中使用系统转储，第一步是正确配置启动和恢复选项。在控制面板的高级系统属性中，您可以选择在系统发生故障时要生成的转储类型，例如“小型内存转储 (256 KB)”以及转储的存储路径。

该系统还需要启动卷上至少几兆字节的页面文件来写入转储文件。在现代版本的 Windows 系统中，每次崩溃都会创建一个新文件，并在配置的文件夹中保留历史记录，以便轻松查看过去的事件。

生成转储文件后，有多种方法可以验证其正确性。Dumpchk.exe 是一个经典的实用程序，它允许您检查文件的基本完整性并打印摘要信息。对于更高级的分析，可以使用Windows 调试工具，包括 WinDbg（图形界面）和 KD（命令行版本）。

从微软网站安装调试包后，这些工具通常会位于类似C:\Program Files\Debugging Tools for Windows这样的文件夹中。从那里，您可以打开命令提示符，并使用 WinDbg 或 KD 加载转储文件，通过 -z 参数指定文件。

windbg -y <RutaSimbolos> -i <RutaBinarios> -z <RutaDump>

符号路径可以指向具有本地缓存​​功能的符号服务器，例如：

srv*C:\Symbols*https://msdl.microsoft.com/download/symbols

二进制路径通常是这样的 C:\Windows\I386 或者，也可以是我们将生成转储文件的版本对应的系统可执行文件复制到的文件夹。这一点很重要，因为 小型转储文件并不包含所有二进制文件。只有对它们的引用，因此调试器需要能够找到它们。

Windows内核崩溃转储的基本分析

使用 WinDbg 或 KD 加载内核崩溃转储文件后，分析内核崩溃转储文件的过程与事后调试非常相似。几乎所有人运行的第一个命令都是`!analyze`，它会启动自动分析并生成初始报告。

命令 !analyze -show 显示 错误检查代码及其参数而 !analyze -v 它能生成更详细的输出：可疑模块、调用堆栈、上下文信息，以及在很多情况下，关于可能原因或诊断步骤的建议。

为了补充该分析，.bugcheck命令会再次打印错误代码和相关参数，可以将其与Microsoft 的错误检查代码参考进行比较，以找出每个值的确切含义和典型原因。

命令 lm N T （列出模块）允许您查看 已加载模块列表，包括其路径、地址和状态这有助于确认自动分析识别出的驱动程序是否实际存在于内存中，以及其版本。当我们怀疑存在与内核交互的第三方驱动程序或安全组件时，此列表尤其有用。

如果需要，我们可以创建一个批处理文件来简化转储文件的加载。该文件接收转储文件的路径，并使用相应的参数启动 KD 或 WinDbg。这样，我们只需要编写一个包含文件位置的简短命令，脚本就会处理其他所有事情。

使用 WinDbg 获取深度内核转储。

对于内核模式内存转储，WinDbg 还支持处理多个文件和会话。可以通过命令行使用-z 参数打开转储文件，也可以通过图形界面使用“文件”>“打开内存转储”菜单或快捷键Ctrl+D打开。

如果 WinDbg 已在被动模式下打开，只需在“打开崩溃转储”对话框中选择文件，指定路径或浏览磁盘即可。加载完成后，在某些情况下，您可以使用“g”（运行）命令启动会话，或者直接运行初始分析命令。

除了经典 !analyze建议熟悉以下内容： 调试器命令参考部分本文档介绍了所有可用于读取内部结构、检查内存、解释堆栈等的命令。其中许多技术既适用于实时会话，也适用于离线转储。

WinDbg 还允许您使用 多个并行转储我们可以在命令行中添加多个 -z 参数，每个参数后跟不同的文件名，或者使用命令添加新目标。 .opendump调试多个目标有助于比较重复出现的故障或连锁事件。

在某些环境下，内存转储会被打包成 CAB 文件，以节省空间或方便传输。WinDbg 可以直接打开 CAB 文件。 .cab 内部包含转储文件，既可以使用 -z 选项，也可以使用其他方式。 .opendump虽然他会读 它只会提取转储文件中的一个，而不会提取其他文件。 它们可以放在同一个包裹里。

Unix 和 Linux 中的崩溃转储：实用程序、工具和要求

在Unix和GNU/Linux系统中，理念相似，但工具生态系统却大相径庭。大多数类Unix内核都提供了在发生灾难性事件时保存内存副本的功能，这种副本被称为核心转储或内核崩溃转储。

尽管这些转储文件的主要用途仍然是内核和驱动程序开发，但它们也具有明显的安全性意义。崩溃可能是由编程错误引起的，但也可能是由恶意操作失败、试图操纵系统组件或拙劣地利用竞争条件造成的。

在配置良好的 Unix 系统中，日常崩溃并不常见，但一旦发生，建议部署转储基础设施，例如 Kdump、LKCD 或其他可以捕获系统内存的解决方案。然而，必须权衡转储的诊断价值和其中包含高度敏感数据的风险。

在 Linux 系统中，用于此类分析的最全面、最广泛使用的工具之一是crash，它最初由 Red Hat 开发。该实用程序实际上已成为检查内核转储以及分析运行系统的实际标准。

崩溃可能会对系统的实时内存造成损害。 /dev/mem 或者，在 Red Hat 及其衍生发行版中，使用特定设备 /dev/crash即便如此，通常的做法是向该工具提供由诸如此类机制生成的转储文件。 Kdump, 转储文件, 磁盘转储 或者像架构特定的转储文件那样 s390/s390x 或 xendump 在虚拟化环境中。

崩溃的作用以及VMlinux在Linux中的重要性

创建崩溃实用程序的部分原因是为了克服使用方面的局限性。 直接在 gdb 上运行 /proc/kcore除此之外，对该内存伪映像的访问可能受到限制，此外，某些内核编译选项使得如果我们只有压缩的可执行二进制文件，就很难正确解释内部结构。

要使 crash 工具正常工作，需要两个关键要素：一个包含调试符号（通常使用类似 -g 的标志）的已编译 vmlinux 文件，以及内核转储文件本身。这两个要素结合起来，使得该工具能够将内存地址映射到函数、结构体和代码行。

区分很重要 vmlinux 和 vmlinuz在大多数系统中，只有 vmlinux 可见，它是内核的压缩可引导版本。崩溃需要符号解压缩后的 vmlinux；如果没有它，尝试加载转储文件时就会出错。 /dev/mem 我们将遇到以下类型的错误 找不到已启动的内核——请输入名称列表参数.

虽然可以手动提取 vmlinuz，但这个过程并非总是简单直接。实际上，重新编译内核以同时获得 vmlinux 和 vmlinuz 通常更为便捷。在管理环境较为复杂的场景下，为每个已部署的内核版本维护一个单独的 vmlinuz 软件包是最佳实践，尤其适用于这种情况。

一旦满足要求，对转储文件运行 crash 工具就相对简单：只需指定相应的 vmlinux 和转储文件，该工具就会打开一个交互式会话，您可以在其中探索内核结构、列出进程、查看调用堆栈并提取取证信息。如果想要深入了解，可以查阅专门的文档，例如著名的 crash 技术白皮书。

/dev/mem 的局限性及 Linux 中的初步方法

在使用特定工具之前，许多管理员历来都尝试过获取内存转储。 直接从设备读取数据 /dev/mem这种方法看似简单：使用类似这样的工具 内存转储 （这会将该设备的输出输出到标准输出）或从中拉取 dd if=/dev/mem of=volcado.mem.

然而，现代内核提供了诸如以下编译选项： CONFIG_STRICT_DEVMEM这严重限制了从用户空间到目标空间的访问。 /dev/mem通常情况下，读取操作会在读取到一小块数据（例如 1 MB）后被截断；或者，在最坏的情况下，该交互过程中的错误可能导致…… 内核恐慌 立即重启机器。

从安全角度来看，这种保护措施完全合理，但这迫使我们寻找其他方法来获取可靠且完整的转储，而不能完全依赖那些不再像以前那样容易获得的通用设备。

因此，目前的趋势是依赖特定的模块或集成的崩溃转储基础设施，而不是简单地尝试使用用户空间工具“抓取内存”，因为这些工具并非设计用于与现代内核保护策略共存。

LiME取证：Linux和Android中的内存提取

在取证领域， LiME（Linux Memory Extractor，Linux内存提取器）是一个非常强大的替代方案。它是一个内核模块，专门用于以可控的方式捕获易失性内存，并且不受/dev/mem的限制。LiME运行在内核空间，因此可以更直接地访问RAM。

LiME 随其源代码一起分发，并针对以下目标进行编译： 正在使用的内核头文件编译过程会生成一个模块 .ko 这取决于它将被加载到的内核版本。编译完成后，我们可以使用诸如以下工具进行验证。 file 确保已正确生成与我们的架构对应的 ELF 模块。

要使用 LiME，只需加载该模块即可。 insmod 从根目录并传递适当的选项，例如通过指定一个 使用 TCP 和原始格式的网络转储目标:

insmod lime-3.x.y.ko "path=tcp:4444 format=raw"

同时，在接收转储文件的机器上，我们使用类似这样的工具监听已配置的端口。 nc将输出重定向到文件：

nc <IP_origen> 4444 > volcado.mem

几分钟后，具体时间取决于内存容量和网络性能，我们将得到一个大小与源系统物理内存相匹配的文件。这是一个完整的内存转储文件，我们可以使用取证工具，甚至可以使用 strings 或其他实用程序对其进行分析，作为查找有用字符串的第一步。

进程转储和数据泄露风险

完整的内核转储信息非常丰富，但如果我们只对特定进程感兴趣，它就显得过于冗杂了。在这种情况下，采用……就显得非常合理了。 单个进程转储 使用类似的工具 gcore 在 Unix/Linux 系统中。

这些按进程转储的文件要小得多，也更容易管理，并且允许您将分析重点放在特定应用程序上，例如消息客户端（例如 Skype）或电子邮件客户端（例如 Thunderbird），通过探索内存字符串，可以相对容易地找到明文密码、会话令牌或联系人数据。

从开发角度来看，这些核心转储文件有助于定位程序错误、内存泄漏或服务中的不一致状态。然而，从安全角度来看，当这些转储文件被定期生成并存储在其他用户可以访问的位置（无论是在系统本身还是在共享网络资源上）时，问题就出现了。

例如，如果用户安排了一项任务 cron 攻击者通过定期捕获敏感进程的转储文件并将其保存在全局可读目录中，为泄露关键信息打开了一扇巨大的大门。在许多审计场景中，分析这些文件可以让攻击者恢复信息。 凭证、联系人列表、通信记录和其他私人数据 以相对较低的努力。

因此，在对 Unix 系统进行任何严肃的审计时，建议花几分钟时间检查是否生成了转储（完整或部分），它们存储在哪里，它们具有什么权限，以及是否有任何自动化进程将内存副本留在未经授权的用户可访问的范围内。

使用 kgdb 对 FreeBSD 中的转储文件进行事后分析

在 BSD 世界中，尤其是在 FreeBSD 中，事后分析的方法包括 启用系统崩溃转储功能，并使用调试符号编译内核。这是通过内核配置目录控制的，通常位于 /usr/src/sys/<arq>/conf.

在相应的配置文件中，可以通过类似这样的行启用符号生成：

makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols

修改配置后，必须重新编译内核。某些对象将被重新生成（例如： trap.o由于构建文件的更改，目标是获得一个内核。 与出现问题的代码相同，但添加了必要的调试信息建议使用以下命令比较新旧尺寸。 size 确保二进制文件中没有发生任何意外更改。

安装完包含符号表的内核后，我们可以按照官方文档中的说明，使用kgdb检查转储文件。并非所有符号表都完整，某些函数可能缺少行号或参数信息，但在大多数情况下，这些信息足以帮助我们追踪问题。

虽然不能绝对保证分析能够解决所有事件，但在实践中，这种策略在很大一部分情况下都相当有效，尤其是在将崩溃转储与对系统最近更改的良好审查相结合时。

分析和记录内核错误的最佳实践

无论操作系统是什么，内核转储分析通常最终都需要参考技术文档、知识库、专业论坛，甚至内核源代码本身来解释消息、错误代码和不熟悉的符号。

在 Linux 系统中，依赖官方源代码树、内置文档和社区资源非常有帮助。许多内核错误信息都可以追溯到它们所在的具体文件，这有助于理解特定 BUG() 或 WARN() 错误触发的上下文。

在 Windows 系统中，微软的文档、知识库 (KB) 和技术论坛提供了错误检查代码的详细解释、故障排除建议和已知错误模式。将这些信息与 `!analyze -v` 命令生成的报告相结合，可以制定合理的缓解方案。

只有将所有崩溃转储信息与对操作系统和故障发生的具体环境的透彻理解进行交叉比对，才能真正体现其价值。唯有如此，才能制定出持久有效的解决方案，更重要的是，才能防止同样的问题在未来再次发生，避免造成更严重的后果。

内核转储分析归根结底是一门科学与技巧的结合：它需要合适的工具、预先配置（符号表、转储选项、安全存储）以及丰富的堆栈、结构和错误代码解读经验。掌握这些技术不仅能帮助我们调试复杂的故障，还能显著提升我们所管理系统的安全性和弹性。