|
法庭现场分析存留的Linux 系统
|
|
来源：hack01@live.cn 作者：Czy 发布时间：2010-01-08
|
|
1
法庭现场分析存留的Linux 系统
Author: Czy Invicta
E-Mail: hack01@live.cn
Weblog: http://blog.sina.com.cn/streethacker
2
1. 前言
在事件响应过程中，为了能够获得许多宝贵资料且被感染的系统暂时不关闭，如果断电后，资料将立
即丢失且无法挽回。我所指的资料是：正在运行的进程、打开的TCP/UDP 端口、删除的文件和映像等，但
仍然存留在内存中、缓冲区的内容、连接请求队列、建立的连接、虚拟Linux内核加载模块等等。所有这些
数据可以进行调查分析和法庭取证。此外，当事件仍然是相对较新的，我们可以恢复入侵者活动中所使用
的数据（几乎所有）。
在主内存映像中来查找入侵的迹象，这种行为不值得信任，因为它们可能是由我们的工具创建的。因
此，采取任何行动之前，我们必须确保系统或数据不被干扰。在收集这些资料时，这是非常值得注意的。
在主存储器中，我们可以找到密码或解密文件。使用/proc文件系统而且我们还可以恢复已经被删除的但仍
然存留在内存中的程序。
在理想的世界里，可以想象一个基于英特尔硬件的计算机，这将使我们能够转储系统内存到外部存储
设备。我们可以使用OpenBoot 对整个内存进行转储。不幸的是，在基于英特尔或AMD 芯片的计算机中没
有类似的解决方案。
尽管存在上述问题，基于软件的方法也有法庭分析的优势，我会在此文章中尽力详述。本文的主要目
的是介绍收集证据的方法。所有收集到的数据可用于执行脱机法庭分析。
2. 法庭分析
本文分为7个部分：
· 2.1拟合环境
· 2.2法庭分析准备
· 2.3从现场系统采取数据－逐步行动
· 2.4文件系统映像
· 2.5基本数据分析
· 2.6关键字搜寻
· 2.7高级法庭分析
2.1拟合环境
在收集数据之前，我们要处理自己所处于的环境。首先，我们要运行网络嗅探器，它必须“看到”被
感染系统所流动的信息。这种情况是强制性的。我们可以通过记录和分析进行实时检测。我建议你记录原
始格式的数据包，否则，它可能会被破坏或修改。
在收集系统数据之前，我们必须为数据收集程序文件在任何活动中都要创建一个副本。这样做有助于
我们避免在事件响应分析中发生的任何错误。每完成一步，我们必须作出详细的说明，以及出现的错误。
记住，文件是非常重要的，因为以后我们会把它提交给法庭进行审判。
下一步，我们记录数据收集阶段所运行命令的结果。从那里，我们目标主机将连接到同一个局域网，
我们将被感染的主机信息发送出去。请记住，我们不能在感染的主机中写入任何数据。为了避免受到感染
主机的影响，我们把所有的数据发送到远程目标主机上。这是法庭分析过程中最重要的规则之一。再次，
如前所述，这种情形并不总是很容易实现的。
2.2法庭分析准备
注意，在收集数据过程中，我们必须符合下列条件：
3
· 尽量不要使用受害系统的程序。为什么？入侵者可能已经修改了系统命令（如netstat）或系统库（如
libproc），输出的结果不可靠。为了实现这一标准，我们必须准备静态编译工具。
· 尽量不要运行程序，它可以修改元数据文件和目录。
· 调查的所有结果必须写入到远程主机。为了实现这一标准，我们将使用我们的远程主机。该netcat 工具
将被用来传输数字数据。
· 你必须使用工具来计算数字数据的哈希值。这是一个保护措施，保证数字数据没有被篡改。一个最佳的
做法是，我们比较源和目标计算出的哈希值是否相同。有时是无法计算上述的散列值，一个很好的例子
就是主内存。当我们尝试对/dev/mem 使用两次md5sum，每次散列值会有所不同。这是因为我们每次
加载到内存的程序进程，我们改变了内存状态。
· 防止数据写入到受损系统的内存，甚至交换空间。记住，我们的工具在一些步骤中不能满足所要求的标
准。
2.3从现场系统采取数据－逐步行动
接下来的事情是非常重要的，我们将要开始收集数据。
第1步：拍摄一个受损系统的屏幕照片
这是一种屏幕截图，当然，我们必须使用数码相机做这项工作。这是一个很简单的步骤。
我们必须对感染系统安置一个外部设备。我们必须使用不受信任的mount 命令来执行此任务。使用系
统命令，这将可能是唯一的一个不受信任的情况。
我们还必须检查mount 命令对系统的影响。我已经在计算机上做了一些研究，下面的表格中列出了有
关被修改的文件和目录。
# strace /bin/mount /mnt/cdrom
文件 mount 命令修改的元数据
/etc/ld.so.cache atime
/lib/tls/libc.so.6 atime
/usr/lib/locale/locale-archive atime
/etc/fstab atime
/etc/mtab* atime, mtime, ctime
/dev/cdrom atime
/bin/mount atime
我们使用“-n”可避免访问这些文件。
正如我们想象的，入侵者修改了mount 命令。当有人试图运行此命令也许是特殊的进程，删除所有被
感染系统的证据。但是我们假设情形并非如此，那么现在就回到数据收集的过程中来。
我建议，对每一个命令进行验证，因为后来将用于收集证据。
我们还必须停止一下，对安装过程中所遇到的潜在问题进行思考：
· 放入驱动器设备之后，卷管理器进程将自动安装。哪些文件和目录将被修改呢？在上面的表格中列出的
这些文件？
· 假设一个未知的设备正在安装在已感染的系统中。然后，第一个任务是要卸载设备。我们应该如何安全
地卸载它呢？我可以提出两个解决方案，我们可以使用命令卸载，我们可以把信任的卸载命令放入静态
4
链接的移动设备上。下一步，我们使用不受信任的mount命令装入设备，然后运行受信任的卸载命令。
这有一点复杂，但很有效。我们仍然只使用一个不信任的命令。
· 管理员已注销或更糟糕的是管理员密码已被入侵者修改。当管理员注销后，我们必须先登录系统。什么
文件将在访问或登录过程中可以修改呢？多少额外的进程会产生呢？如果管理员密码被更改，那么系统
上的其他帐户呢？收集什么数据可以有权获得一个Shell？开启TCP/UDP端口，当前的连接又是什么？
· 是否有其他不可预知的问题？
第2步：装载设备
让我们继续前进并且安装我们的设备，在这种情况下，我们的工具包存储在CD-ROM内。
# mount -n /mnt/cdrom
如果安装过程是成功的，我们就可以进入最重要的数据收集阶段。记住，值得信赖的命令所输出的结
果都要发送到远程主机。我使用的是netcat。为了更好地区分任务是在哪台主机上执行的，对于被感染的主
机上执行的所有命令将统一用括号“()”括起来，括号内将标记为“compromised”字符。运行在远程主机
的命令将括号内的字符标为“remote”。看看下面的例子。
发送关于一个系统的最新数据到远程主机（远程主机的IP在这里为192.168.0.100），我们必须打开远程
主机上的TCP端口，如下：
(remote host)# nc -l -p 8888 > date_compromised
接着，在被感染的主机中，我们执行下列操作：
(compromised host)# /mnt/cdrom/date | /mnt/cdrom/nc 192.168.1.100 8888 -w 3
为了确保我们收集数据的完整性，要清晰地记录每一个文件副本并计算它的哈希值。
(remote host)# md5sum date_compromised > date_compromised.md5
有时候，我们可以生产受损系统校验的结果并发送到远程主机。
(compromised host)# /mnt/cdrom/md5sum /etc/fstab | /mnt/cdrom/nc 192.168.1.100 8888 -w 3
第3步：当前日期
其结果展现的是CUT格式（Coordinated Universal Time）。
(remote)# nc -l -p port > date_compromised
(compromised)# /mnt/cdrom/date -u | /mnt/cdrom/nc (remote) port
(remote)# md5sum date_compromised > date_compromised.md5
第4步：缓存表
首先，我们必须从缓存表中收集信息，这是因为放置在表内的数据的生命周期非常短。我会收集ARP
和路由表中的数据。
MAC地址缓存表：
(remote)# nc -l -p port > arp_compromised
(compromised)# /mnt/cdrom/arp -an | /mnt/cdrom/nc (remote) port
(remote)# md5sum arp_compromised > arp_compromised.md5
核心路由缓存表：
(remote)# nc -l -p port > route_compromised
(compromised)# /mnt/cdrom/route -Cn | /mnt/cdrom/nc (remote) port
5
(remote)# md5sum route_compromised > route_compromised.md5
第5步：等待连接打开的TCP/UDP端口
现在，我们开始收集关于当前连接开放的TCP/UDP端口的信息。关于收集原始套接字的所有活动信息，
请看步骤8。
(remote)# nc -l -p port > connections_compromised
(compromised)# /mnt/cdrom/netstat -an | /mnt/cdrom/nc (remote) port
(remote)# md5sum connections_compromised > connections_compromised.md5
我们可以使用cat 命令，开放的端口信息保存在/proc 文件系统（(/proc/net/tcp 和/proc/net/udp）内。
当前连接的信息被放置在/proc/net/netstat 文件内。这些文件的所有数据都以十六进制格式表示，例如：
0100007F:0401 十进制是 127.0.0.1:1025。
如前所述，可以对当前连接的流量进行检测和分析。
第6步：物理内存映像
在数据收集过程中，对整个系统内存创建一个副本。我们可以直接访问物理内存复制的/dev/mem 或
kcore 文件。该kcore 文件代表了Linux 操作系统的内存。它可以找到虚拟文件系统，它位于/proc 目录。此
文件的大小等于所提出的物理内存。使用kcore的好处就是，它是在ELF提出内核的格式，因此它可以通过
gdb 调试。gdb 是一个非常实用的工具，我们可以使用它进行跟踪或分析代码和内存模块。在第2.7 中我将
演示如何使用这个工具进行更先进的脱机分析。但对于分析来说，我们将使用如grep，字符串和十六进制
编辑器的通用工具。
另外，还要正确分析整个物理内存，我们必须知道一些页表信息——数据结构映射虚拟（线性）地址
到物理地址。
如前所述，我们必须记住，我们所使用的工具都会修改掉内存中的内容。更糟糕的是，可能覆盖掉我
们所需的证据。
在下面的例子中，我用/proc复制了一个内存映像。
(remote)# nc -l -p port > kcore_compromised
(compromised)# /mnt/cdrom/dd < /proc/kcore | /mnt/cdrom/nc (remote) port
(remote)# md5sum kcore_compromised > kcore_compromised.md5
我们将复制整个系统的内存分配和未分配的数据。在第9 步，我们将尝试使用/proc复制一个特定的进
程。我必须指出，通过使用/proc还可以修改交换空间。我们将迫使一些主内存页面从交换空间中读取出来，
并写入到其他页面。另一个重要部分必须记住，我们只复制内存分配的过程数据。
第7步：加载系统核心内存模块列表
我们必须确保所收集的数据是完整的，而且netstat 或lsof 命令的结果不能在内核级别修改。因此，我
们必须检查一下，看看当前有哪些模块加载到内存里。
(remote)# nc -l -p port > lkms_compromised
(compromised)# /mnt/cdrom/cat /proc/modules | /mnt/cdrom/nc (remote) port
(remote)# nc -l -p port > lkms_compromised.md5
(compromised)# /mnt/cdrom/md5sum /proc/modules | /mnt/cdrom/nc (remote) port
不幸的是，一些恶意模块可能根本无法被列出。为了核实有关的/proc/modules 信息，检查hunter.o 内
核加载模块。
6
(compromised)# /mnt/cdrom/insmod -f /mnt/cdrom/hunter.o
我使用了“-f”选项，在这种情况下，是因为hunter.o模块与内核版本不匹配。受损系统的内核版本与
其中hunter.o模块编制系统内核的版本有所不同。最好的解决方法是重新编译每一个内核版本的模块代码。
如果我们知道被感染的机器上所使用的内核版本，那么我们可以从“The Linux Kernel Archives”（http://
www.kernel.org）站点获取正确的源代码，并附上hunter.o模块内核的头文件。
(remote)# nc -l -p port > modules_hunter_compromised
(compromised)# /mnt/cdrom/cat /proc/showmodules && /mnt/cdrom/dmesg | /mnt/cdrom/nc (remote) port
(remote)# md5sum modules_hunter_compromised > modules_hunter_compromised.md5
现在我们可以比较结果了，我们还要注意模块的大小。
最后一点就是，我们需要复制内核模块出口符号。有时，基于LKM的rootkit 可以利用这个特征。通过
分析ksyms文件，我们可以发现系统中存在的入侵者。
(remote)# nc -l -p port > ksyms_compromised
(compromised)# /mnt/cdrom/cat /proc/ksyms | /mnt/cdrom/nc (remote) port
(remote)# nc -l -p port > ksyms_compromised.md5
(compromised)# /mnt/cdrom/md5sum /proc/ksyms | /mnt/cdrom/nc (remote) port
我们也可以使用其他工具进行检测恶意模块（如kstat 或kern_check），但不幸的是，它们都使用
System.map 文件。此文件负责编译内核。如果管理员不复制这个文件并没有设置校验，我们应该对系统调
用地址。即使在系统调用的地址是有效的，入侵者仍可以使用其他隐藏的恶意内核模块，如adore-ng rootkit。
第8步：活动进程列表
对所有进程来说，可使用lsof工具收集开放的端口和文件资料。当然，这要确保我们没有任何基于LKM
内存的rootkit。另外，在下一步，我们将复制恶意数据。你会记得，在第6 步中我们收集的是整个内存（kcore
或/dev/mem）。
(remote)# nc -l -p port > lsof_compromised
(compromised)# /mnt/cdrom/lsof -n -P -l | /mnt/cdrom/nc (remote) port
(remote)# md5sum lsof_compromised > lsof_compromised.md5
现在，我们必须从lsof 工具输出的结果进行分析。如果没有任何可疑的活动进程，现在是复制这些数
据的最佳时间。另外，如果我们看到的lsof 结果，可能有些进程被入侵者删除，但我们仍然有机会恢复。
我将告诉你如何进行。
我已列出了以下可疑进程的例子：
· 一个进程正在侦听一个非典型的TCP/UDP端口或打开原始套接字；
· 一个进程有一个与远程主机活动的连接；
· 一个程序在运行之前已被删除；
· 一个文件，由活动进程打开，之后被删除（如，一个日志文件）；
· 一个奇怪的进程名；
· 一个不存在或未经授权的用户启动了一个进程。
第9 步：收集可疑进程
我将使用pcat 工具来复制内存分配的整个进程。
(remote)# nc -l -p port > proc_id_compromised
(compromised)# /mnt/cdrom/pcat proc_id | /mnt/cdrom/nc (remote) port
(remote)# md5 proc_ip_compromised > proc_ip_compromised.md5
7
另外，我们可以从某些数据复制一个进程。更多信息可在下面找到。
第10步：受损系统的可用信息
我们下一步的工作是从被感染系统积攒可用的信息。所说的信息是，对整个事件的描述和正确执行的
所有系统文件副本。请记住，所有结果都会发送到远程主机。在下面的表格中，我列出了在被感染系统上
所执行的命令。
命令 描述
/mnt/cdrom/cat /proc/version 操作系统版本
/mnt/cdrom/cat /proc/sys/kernel/name 主机名
/mnt/cdrom/cat /proc/sys/kernel/domainame 域名
/mnt/cdrom/cat /proc/cpuinfo 硬件信息
/mnt/cdrom/cat /proc/swaps 所有交换分区
/mnt/cdrom/cat /proc/partitions 所有本地文件系统
/mnt/cdrom/cat /proc/self/mounts Mount 文件系统
/mnt/cdrom/cat /proc/uptime Uptime
第11步：当前时间
最后一步是对当前时间信息的收集。
(remote)# nc -l -p port > end_time
(compromised)# /mnt/cdrom/date | /mnt/cdrom/nc (remote) port
现在，我们的任务已经告一段落了，我可以关掉这台受损的系统了。切记，不要使用任何shutdown 或
init 命令。我们一定要使用系统或UPS设备的电源线进行关机。
2.4文件系统映像
在关闭受损系统之前，我们就已经创建了所有系统文件和交换分区的副本。我建议任务执行后，该系
统立即关闭此任务。这样，我们可以确保文件内容不再被修改。我再次提醒，交换空间内的证据会被我们
所执行任务的过程中修改和覆盖。
下一步，将启动设备驱动器，我们可以使用任何Linux发行版，不会安装在默认的本地文件系统。现在，
从这个角度，我们可以创建所有本地分区或整个硬盘的副本。
2.5基本数据分析
暂时停下来让我们重新思考在第8 步中我们使用的lsof 工具。让我们来看看这个更深入的情形，并思
考两个例子：
示例1：一个文件，打开了一个进程，之后被删除。
在这方面，Linux文件发起了进程，仍然分片内存。要恢复文件，我们必须知道创建ID进程的程序。在
/proc 目录中，我们可以找到可执行文件。该文件是一个删除的一个副本。我们必须将此文件发送到远程主
机。
当我们恢复已删除的文件，我们可以从中提取信息。我们可以选择两个选项的其中之一：静态拆解分
8
析，或者通过运行这个严密控制环境中的未知的文件进行动态分析。
示例2：一个文件，由活动进程打开，之后被删除（如日志文件）
一个lsof 输出的片段，如下所示：
smbd 3137 root rtd DIR 8,1 4096 2 /
smbd 3137 root txt REG 8,1 672527 92030 /usr/bin/smbd -D
smbd 3137 root mem REG 8,1 485171 44656 /lib/ld-2.2.4.so
...
smbd 3137 root 16u IPv4 976 TCP *:https (LISTEN)
smbd 3137 root 17u IPv4 977 TCP *:http (LISTEN)
...
smbd 3137 root 20w REG 8,1 253 46934 /var/log/httpd/access_log (deleted)
...
要恢复这个文件，我们列出了来自/proc/3137/fd目录（文件描述）。
(remote)# nc -l -p port > ls_from_proc_3137
(compromised)# /mnt/cdrom/ls -la /proc/3137/fd/ | /mnt/cdrom/nc (remote) port
(remote)# more ls_from_proc_3137
l-wx------ 1 root root 64 Aug 10 21:03 12 -> /var/log/httpd/access_log (deleted)
...
我们可以看到，第一个文件描述符被删除。我们使用netcat复制这个文件并发送给远程主机。
(remote)# nc -l -p port > deleted_access_log
(compromised)# /mnt/cdrom/cat /proc/3137/fd/1 | /mnt/cdrom/nc (remote) port
这不是恢复这个文件的唯一方法。我们还可以在脱机状态下恢复文件，我们正在寻找未分配的节点和
数据块。
2.6关键字搜寻
在本文章中，我想提出一个存储过程和映像分析方法。记住，这一步已经完成了远程主机操作，映像
也已完成。这种方法的最大优点是，我们不需要知道低级语言的使用。我将使用下面的工具来查找入侵的
迹象：
· strings
· less
· grep
我们将收集到的映像文件通过strings工具输出字符。默认配置，让我们查看可输出的字符序列，这至少
4 字符。我们将使用“-t”选项从文件的开头添加一个偏移。
$ strings -t d kcore > kcore_strings
$ md5sum kcore_strings > kcore_strings.md5
下面是关键字搜寻的一些例子。我们利用这些查找kcore_strings 入侵的证据。
· 主机名或受损系统前缀
$ grep "root@3945a0" kcore_strings
$ grep "]#" kcore_strings
9
11921096 [root@3945a0]#
16643784 [root@3945a0 root]#
30692969 ]#]#
在上面的结果中，我们已列出了一些字符串的偏移量。下一步使用文本编辑器打开文件，它是接近偏
移地址的位置。如果我们有一点运气，我们会发现在之前运行着其他命令。但我们要记住，虚拟内存在物
理内存和交换空间的页面中没有组织编写方式，因此，我们的结论也完全无效。
$ less kcore_strings
/11921096
11921096 [root@3945a0]#
11921192 /usr/bin/perl
11921288 perl apache_mod_exploit.pl
…
上面的例子介绍了对受损系统所输入的一些命令。
· 文件和目录名
$ grep -e "\/proc\/" -e "\/bin\/" -e "\/bin\/.*?sh" kcore_strings
$ grep -e "ftp" -e "root" kcore_strings
$ grep -e "rm -" kcore_strings
$ grep -e ".tgz" kcore_strings
· IP地址和域名
$ grep -e "[0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+" kcore_strings
$ grep -e "\.pl" kcore_strings
2.7高级法庭分析
在文章的最后部分，我将展示如何通过gdb 对复制过来的kcore文件进行分析。一开始，我描述了如何
检查系统调用的地址是否为正确的系统调用表。改变系统调用地址，安装基于LKM的rootkit是最简单的方
法。在接下来的例子中，我来描述如何列出被感染系统上运行的所有进程。从这个例子中可以得出步骤7
和步骤8的结果。
首先，我们需要分析以下信息：
· ELF内核格式的内存映像
· 已编译的内核映像
· 出口符号列表
· 一个被攻破的计算机上使用的内核源代码
下一步，运行gdb工具，如下所示：
# gdb vmlinux kcore
GNU gdb Red Hat Linux (7.0.1)
Copyright 2009 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
10
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i586-redhat-linux"...
warning: core file may not match specified executable file.
Core was generated by `ro root=/dev/sda2 hdc=ide-scsi'.
#0 0x00000000 in ?? ()
(gdb)
现在我们准备开始分析。
示例1：系统调用的地址验证
第一步是找到系统调用表的地址（sys_call_table）。几乎每一个Linux 操作系统都可以在Symbol.map 文
件中找到。
# cat Symbol.map | grep sys_call_table
c02c209c D sys_call_table
现在，我们可以列出sys_call_table 的项目，每个条目都是系统调用的地址。要正确理解它，我建议看
看受损系统的内核源代码entry.S文件，该文件包含了系统调用正确的顺序。
ENTRY(sys_call_table)
.long SYMBOL_NAME(sys_ni_syscall) /* 0 - old "setup()" system call*/
.long SYMBOL_NAME(sys_exit)
.long SYMBOL_NAME(sys_fork)
.long SYMBOL_NAME(sys_read)
.long SYMBOL_NAME(sys_write)
.long SYMBOL_NAME(sys_open) /* 5 */
.long SYMBOL_NAME(sys_close)
...
这个sys_call_table 的顺序相同。要列出前10 个系统调用地址，操作如下：
(gdb) x/10x 0xc02c209c
0xc02c209c <sys_call_table>: 0xc01217c0 0xc011ac50 0xc0107510 0xc0138d50
0xc02c20ac <sys_call_table+16>: 0xc0138e50 0xc0138880 0xc01389b0 0xc011b010
0xc02c20bc <sys_call_table+32>: 0xc0138930 0xc01445c0
该地址0xc01217c0 是sys_ni_call 的系统调用，地址0xc0011ac50是sys_exit的系统调用等等。
如果我们确信ksyms 文件来自于System.map，我们可以比较几乎所有的地址。当然，入侵者不会改变
每一个系统调用的地址，有几个比较受欢迎，如sys_read、sys_getdents或sys_write。
示例2：活动进程的列表
要建立运行进程的整个列表，我们必须找到init_task_union 结构。
# cat Symbol.map | grep init_task_union
c02da000 D init_task_union
下一步将如何找出这个结构。init_task 结构在受损系统内核代码的头文件sched.h 中。在结构task_struct
11
也可以在这个头文件中找到。
#define INIT_TASK(tsk)
{
state: 0,
flags: 0,
sigpending: 0,
addr_limit: KERNEL_DS,
exec_domain: &default_exec_domain,
...
run_list: LIST_HEAD_INIT(tsk.run_list),
time_slice: HZ,
next_task: &tsk,
prev_task: &tsk,
p_opptr: &tsk,
...
对我们来说，最重要的地方是prev_task 和每个进程的描述next_task（即task_struck 类型）。它们帮助
我们建立了进程列表。next_task 字段指向下一个进程的进程描述，prev_task 进程描述将插入到列表的尾部。
在下面的例子中，我列出了进程描述的一些片段（即task_struct），它被发现的地址为0xc514c000。
(gdb) x/180x 0xc514c000
...
0xc514c040: 0x00000000 0xffffffff 0x00000004 0xc1be0000
0xc514c050: 0xc4dac000 0xc5ea8e40 0xc5ea8e40 0xc02c56d4
...
0xc514c070: 0x00000001 0x00001ace 0x00001ace 0x00000000
...
0xc514c230: 0xffffffff 0xffffffff 0x61620000 0x00006873
0xc514c240: 0x00007974 0x00000000 0x00000000 0x00000000
...
其中：
0xc1be0000 是 next_task
0xc4dac000 是 prev_task
0x00001ace 是进程PID=6268十六进制格式
0x61620000 和 0x00006873 是进程的名称=“bash”这是一个特殊的例子
要输出一下个进程的进出描述符（即task_struct 类型），如下所示：
(gdb) x/180x 0xc1be0000
依照每一个进程描述符，我就可以构建完整的活动进程列表信息。
3. 尾声
法庭分析是非常难以执行的，我们必须小心谨慎地完成所有步骤，并确保所有收集的证据文件没有丢
失或更改。我们还看到了法庭分析的一些优势和软件操作的劣势。最后，尽管我已经展示了如何收集Linux
系统证据文件，但我们几乎可以在其他操作系统上执行相同的步骤。
Czy Invicta
|
| |
|
[ 推荐]
[ 评论(0条)]
[返回顶部] [打印本页]
[关闭窗口] |
|
|
| |
|
|
 |
|
推荐广告 |
|
|
|
|
|
