在日常的涉网类案件支持中,服务器的镜像分析,是比较高频的需求。一般来说更有效的方法,是把镜像在本地虚拟环境中运行起来,还原网站运行的过程,再通过模拟管理员的行为进行取证。
但是在镜像提取环节,情况往往比我们想象的要复杂------比如说事态紧急,必须要立刻断电来保全数据等等。我们都知道,正在进行读取写入动作的硬盘,突然断电会有较高概率发生数据损坏,所以,事后对此类镜像的修复工作就比较关键。本文就从一起损坏镜像的修复开始入手,和大家一起回顾一下整个过程。
从拿到镜像到仿真操作系统启动,一般要经过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`查看用户列表:根据用户名猜测服务
可能安装的服务有: 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
root@ubuntu:~
root@ubuntu:~
root@ubuntu:~
Installing 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. 解决问题方向的预判,信息的搜集源自知识的积累,看报错和转变思路是解决问题的重要方法。
硬盘驱动器的故障及更换
阿里云MongoDB数据库本地还原取证
原文始发于微信公众号(电子物证):【笔记】一起损坏镜像的修复
评论