技术分享 | 一起损坏镜像的修复笔记
2023-6-9 17:1:49 Author: 网络安全与取证研究(查看原文) 阅读量:10 收藏
在日常的涉网类案件支持中，服务器的镜像分析，是比较高频的需求。一般来说更有效的方法，是把镜像在本地虚拟环境中运行起来，还原网站运行的过程，再通过模拟管理员的行为进行取证。
但是在镜像提取环节，情况往往比我们想象的要复杂------比如说事态紧急，必须要立刻断电来保全数据等等。我们都知道，正在进行读取写入动作的硬盘，突然断电会有较高概率发生数据损坏，所以，事后对此类镜像的修复工作就比较关键。本文就从一起损坏镜像的修复开始入手，和大家一起回顾一下整个过程。

从拿到镜像到仿真操作系统启动，一般要经过4个步骤：

镜像读取

生成虚拟机文件

虚拟机快照

开机进入系统

到目前为止，火眼仿真已经可以支持了大部分镜像的仿真，并且会在仿真过程中自动修复常见问题。但是从严格意义上来说，在上述4个步骤中，镜像读取和系统启动这两个环节出的问题千奇百怪，每个展开说都可以成为一个盛大的话题。
修复其存在的问题并且成功仿真，其中知识点会涉及到文件系统、操作系统基础、计算机通信和网络、elf数据结构等。

Part 1

镜像信息搜集

古话说：知己知彼百战百胜。动态仿真既然出现问题，思路就可以转向使用静态分析工具对镜像信息做尽可能多的搜集。静态分析的工具很多：FTK、火眼证据分析、xway等等。那么使用静态分析需要关注哪些点呢？

FTK直接加载镜像分析，得到如下图

从上图可以搜集到如下信息：
1 从图片左下角基本信息可以看出该镜像是一个无损坏的vmware虚拟磁盘。该镜像原始磁盘总大小为：73400320*512=37580963840bytes=35GiB。
2 从图片右侧十六进制可以看出，MBR分区表中只有一个分区表项，分区类型为0xEE且紧接着MBR项的为`EFI PART`头部标志。初步判断：该镜像是GPT分区表类型，且分区表完整。不属于单分区镜像。因为`EFI PART`是紧接着MBR分区表项的，所以扇区大小是512字节，不是4096字节。
3 从图片左上角可以看到：有1G的分区，文件系统为ext4(猜测是/boot分区)和包含lvm2，lvm2种包含了20G的lv分区，文件系统是ext4文件系统(猜测是根分区)。

Part 2

系统信息搜集

静态分析查看关键文件项，搜集系统信息。

1 `/etc/lsb-release`系统信息：可以看出操作系统是Ubuntu20.10

2 `/etc/fstab`查看依赖磁盘：没有外置磁盘依赖，swap分区落盘成根分区一个文件。
3 `/etc/localtime`查看时区信息: 时区是0时区，并不是常见的北京时区。

4 `/etc/passwd`查看用户列表：根据用户名猜测服务

从上图看，可能的登录用户名是：root和bob。
可能安装的服务有: ssh,mysql,dnsmasq,lxd容器，ftp服务(可能是vsftpd或者PureFTPd)
5 linux内核版本:原始版本是5.8.0.25，后来升级为5.8.0.28

6 bash文件的十六进制：原始操作系统运行在64位小端cpu上面

Part 3

开始尝试仿真

火眼仿真加载镜像并点击创建虚拟机，在这个过程中将自动识别引导模式是BIOS还是UEFI，自动修改挂载信息，并清除或者重置密码为123456，以确保第一次可以成功进入系统。
仿真提示成功创建虚拟机并重置密码为123456，但是打开虚拟机尝试进入系统时却得到如下报错：

看报错是 No working init found.
首先以这个报错作为关键词搜索，出现最多的解决方案是使用fsck检查文件系统是否有损坏。
fsck显示该镜像里的文件系统没有问题，输出见下图：

Part 4

尝试修引导

按照网上解决方案fsck并不能解决问题，所以考虑问题可能并不是简单的文件损坏 ，开始转变思路，考虑整个引导过程。
按照正常linux启动顺序都是grub引导到加载内核模块。在grub引导界面都会有菜单选择进入哪个版本的内核，这个镜像启动后啥都不显示直接就报错。由此猜测grub应该是坏的。下面开始尝试修grub引导。
```bash[email protected]:~# mkdir boot[email protected]:~# mount /dev/sda2 boot[email protected]:~# grub-install --boot-directory=boot /dev/sdaInstalling for i386-pc platform.Installation finished. No error reported.```
经过以上命令修复grub引导后重启虚拟机，看到了grub引导菜单。

Part 5

准备修内核

看到grub引导菜单，选择了grub菜单Ubuntu选项进入后依然报上面相同的错误。
重新审视上面的报错，从call trace看异常是ret_from_fork调用kernel_init过程中出现了致命的异常导致系统不能继续启动，下面开始尝试重装系统内核。
重装内核，第一件事执行`apt update`，得到如下报错：

从报错看，是网络问题。开始排查网络问题：

从上图可以看出来，网络连接是没问题的，有问题的是dns配置。修改`/etc/resolve.conf`重启网络终于可以顺利`apt update`。
最后证明重装系统内核解决了问题。

Part 6

成果展示

bobslinux,上次登录时间是2020年11月28日23:18:01（UTC时间）
修复完成以后，操作系统正常启动，接着通过本地仿真应用环境并进行取证，最终使案件有了实质性的进展。

——————

1. 这篇文章的目的是修复问题使镜像中系统正确能启动。但是碰到类似故障时，一定要具体情况具体分析，结合实际情形的差异性，从快速解决问题的的角度出发思考；

2. 解决问题方向的预判，信息的搜集源自知识的积累，看报错和转变思路是解决问题的重要方法。


文章来源: http://mp.weixin.qq.com/s?__biz=Mzg3NTU3NTY0Nw==&mid=2247487169&idx=1&sn=1a4793113f09ac7ff1ac52db755db51c&chksm=cf3e2ef1f849a7e7f13d802ebf33ef50951a2004c859b33bb0e0579ef993d961a2e26b7e048c#rd
如有侵权请联系:admin#unsafe.sh