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

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

当操作系统发生恐慌或崩溃时，了解发生了什么的唯一方法是…… 内核内存转储及后续分析这些转储文件记录了系统发生故障时的内部状态，是调试复杂错误、调查安全事件或进行取证检查的原始资料。

虽然听起来很“底层”，但分析内存转储并非内核开发人员的专属领域。系统管理员、支持工程师甚至安全审计人员如果掌握基本知识，也能从中受益。 合适的工具、数据转储类型和基本解读技巧我们将使用 WinDbg、crash、kgdb 和 LiME 等工具，在 Windows、Unix/Linux 和 BSD 上完成整个路径。

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

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

实际上，这种类型的转储可以节省…… 内核内部结构、调用堆栈、进程上下文和已加载的驱动程序正因如此，灾难发生后可以进行“事后”分析，这与调试运行中的系统非常相似，但无需承受在生产机器发生故障时进行操作的压力。

深入分析内核转储文件的原因多种多样：从 调试看似随机出现的错误和间歇性崩溃甚至还要调查系统是否遭到恶意篡改，或者崩溃是否在磁盘上留下了敏感信息的痕迹。

除了完整的内核转储之外，还可以提取单个进程的转储（经典方法）。 核心转储），这在我们想要的是……时非常有用 将问题限定在特定应用程序中，或审查对服务保密性的影响 例如电子邮件或即时通讯客户端。

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

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

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

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

由于这些基本结构，即使使用小型转储文件，通常也可以确定是哪个驱动程序或模块导致了崩溃，但如果问题源自距离崩溃时正在运行的线程很远的地方，则不一定能够追踪到整个问题。 可获取的背景信息有限。.

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

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

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

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

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

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

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

符号路径可以指向一个 带有本地缓存​​的符号服务器，例如：

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

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

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

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

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

为了补充该分析，命令 .bugcheck 它会重新打印错误代码和相关参数，然后可以将其与……进行比较。 错误检查代码参考 从微软了解每个值的确切含义和典型原因。

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

如果需要，我们可以通过创建以下方式简化转储加载过程： 批处理文件 它应该接收转储文件的路径，并使用相应的参数启动 KD 或 WinDbg。这样，您只需编写一个包含文件位置的简短命令，脚本就会处理其余的一切。

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

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

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

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

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

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

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

在 Unix 和 GNU/Linux 系统中，理念相似，但工具生态系统却大相径庭。大多数类 Unix 内核都提供了以下可能性： 当发生灾难性事件时，保存一份内存副本。我们所知道的 核心转储 或内核崩溃转储。

尽管这些转储文件的主要用途仍然是内核和驱动程序开发，但它们也具有明显的安全性。崩溃可能是由以下原因造成的： 程序错误，以及恶意行为 操纵系统组件或笨拙地利用竞态条件的失败尝试。

在配置良好的 Unix 系统中，日常崩溃并不常见，但当崩溃发生时，最好事先制定备份计划。 转储基础设施，例如 Kdump、LKCD 或其他解决方案 这允许捕获系统内存。但是，必须权衡转储文件的诊断价值及其包含高度敏感数据的风险。

Linux 系统中用于此类分析的最完整、最广泛使用的工具之一是 紧急该工具最初由 Red Hat 开发，现已成为检查内核转储和分析运行系统的实际标准。

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

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

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

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

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

虽然可以手动解压缩 vmlinuz，但这个过程并不总是那么简单，而且在实践中，通常使用其他方法会方便得多。 重新编译内核，即可同时获得 vmlinux 和 vmlinuz。 同时进行。在重要的管理环境中，最佳实践是为每个部署的内核版本维护一个与之对应的 vmlinux 实例。

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

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

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

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

从安全角度来看，这种保护措施完全合理，但它也迫使我们去寻找…… 获取可靠完整转储文件的其他方法 无需完全依赖那些已不如以往那样容易获得的通用设备。

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

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

在法医学领域，一种非常有效的替代方案是 LiME（Linux内存提取器）LiME 是一个内核模块，专门用于以可控方式捕获易失性内存，且不受 /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

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

进程转储和数据泄露风险

完整的内核转储信息非常丰富，但如果我们只对特定进程感兴趣，它就显得过于冗杂了。在这种情况下，采用……就显得非常合理了。 单个进程转储 使用类似的工具 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 确保二进制文件中没有发生任何意外更改。

使用符号安装内核后，我们现在可以检查转储文件了。 数据库 如官方文档所述。并非所有符号都完整，某些函数可能缺少行号或参数信息，但在大多数情况下，细节足以追踪问题所在。

虽然不能绝对保证分析能够解决所有问题，但在实践中， 这种策略在绝大多数情况下都行之有效。尤其是当崩溃转储文件与对近期系统变更的详细审查相结合时。

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

无论操作系统如何，内核转储分析通常最终都会导致以下结果： 技术文档、知识库、专业论坛，甚至内核源代码本身。 解读信息、错误代码和陌生符号。

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

在 Windows 系统中，微软的文档、知识库 (KB) 和技术论坛都提供了详细的解释。 错误检查代码、解决方案建议和已知错误模式将该信息与 !analyze -v 报告结合起来，就可以制定合理的缓解计划。

崩溃转储的真正价值在于将所有这些信息与……进行交叉比对。 对操作系统和发生故障的具体环境有扎实的了解只有这样才能提出持久的解决方案，更重要的是，才能防止将来再次出现同样的问题，造成更严重的后果。

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