【笔记】一起损坏镜像的修复

admin 2024年10月11日11:24:05评论13 views字数 2433阅读8分6秒阅读模式
转自:网络安全与取证研究

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

【笔记】一起损坏镜像的修复

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

镜像读取

生成虚拟机文件

虚拟机快照

开机进入系统

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

【笔记】一起损坏镜像的修复

Part 1

镜像信息搜集

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

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

【笔记】一起损坏镜像的修复

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

【笔记】一起损坏镜像的修复

Part 2

系统信息搜集

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

【笔记】一起损坏镜像的修复

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

【笔记】一起损坏镜像的修复

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

【笔记】一起损坏镜像的修复

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

【笔记】一起损坏镜像的修复

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

【笔记】一起损坏镜像的修复

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

【笔记】一起损坏镜像的修复

【笔记】一起损坏镜像的修复

Part 3

开始尝试仿真

【笔记】一起损坏镜像的修复

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

【笔记】一起损坏镜像的修复

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

【笔记】一起损坏镜像的修复

【笔记】一起损坏镜像的修复

Part 4

尝试修引导

按照网上解决方案fsck并不能解决问题,所以考虑问题可能并不是简单的文件损坏 ,开始转变思路,考虑整个引导过程。
按照正常linux启动顺序都是grub引导到加载内核模块。在grub引导界面都会有菜单选择进入哪个版本的内核,这个镜像启动后啥都不显示直接就报错。由此猜测grub应该是坏的。下面开始尝试修grub引导。
```bashroot@ubuntu:~# mkdir bootroot@ubuntu:~# mount /dev/sda2 bootroot@ubuntu:~# 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. 解决问题方向的预判,信息的搜集源自知识的积累,看报错和转变思路是解决问题的重要方法。

【笔记】一起损坏镜像的修复

硬盘驱动器的故障及更换

阿里云MongoDB数据库本地还原取证

原文始发于微信公众号(电子物证):【笔记】一起损坏镜像的修复

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2024年10月11日11:24:05
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   【笔记】一起损坏镜像的修复https://cn-sec.com/archives/1914545.html

发表评论

匿名网友 填写信息