2026FIC初赛服务器浅析:容器桌面和RAID磁盘结构

2026FIC初赛的全篇WP我就不发了，网上很多师傅都有写，就不班门弄斧了，可以看玫姐姐的 https://mp.weixin.qq.com/s/4vG795_CqE26Gx_YjtAvXg

这次比赛的服务器挺有意思，vmware仿真之后直接进入了一个容器图形化界面。比赛的时候没有时间仔细研究，赛后让我来研究下。

服务器仿真与配置

先简单回顾下如何完成这个服务器检材从仿真到能够正常取证的流程，这里我就一笔带过了，详细的操作可以看佬们的完整wp

首先火眼可以直接仿真的，如果仿真不了，就是版本低了。仿真的之后同时添加两块盘，稍微等一下，进去之后发现ps -p 1不是systemd，说明可能在容器里面。

确定是在容器中

ctrl+alt+f2退出容器，然后在宿主机上安装好ssh，修改/etc/ssh/sshd_config。如果ssh端口有占用，是容器占用了22，kill掉进程或者改宿主机ssh端口都行

我直接写公钥进去：

echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDqGKhvtr2I7DqCgIoQD7n0ovhsp1eUsy9WrhRAJSq7N7/zkDVL8Wbw5Rd/dbPfnKulJT0uE2uN6zb/+/jU245k3/BhMsHfM2JHH2at5xdzfT1JF62bODgdNbXL+60oSZochRktiP/YGDEU3xBwGce/goT14UM34IrJ96KMtpJiJCKFOFbYs/jcRDmaZlodv+xtcFGRUsNYbMDAt/L991YCQ998BPaAFUQi9LEFZMMUowmmbmohW/AyRPjrNW/MgpjK6LMreOX5qPKUvxHaUwRjYyjg645f3ARlYvEEZlGRdpHz7QJ8TtV5aScd0t0f49ccbJu3zT/q0me2cgDf/57xe41YHWYzl4h7jLtwOJwpbdG9D8jmuGM/zN0LnNoWFJqRGJ3936RM8bmi+SVgaC85pU2JrN2Scv348DoHbbbMFHYoTQ2Ynm2ATPxOtset8vlfpVGGjdH0iWTc/5xw/A4qQJrE1ZmKEcxt/Hr2FX9VvlySXao2id6VfiramC+702a4o6y0NBXrrqpQgY0Qed5ybpYSeADqqEk9y65SHvaG4AckLGisKlM76UiB7ansODml+Lipk0UXB6Y6VD5Xh5H2NJPdDSjp8RFCsV0EYP9F/oLoLvKN+ij/KrPgNDozvJkN5NCtVDZhfGYuY0xtxa7m2eApn5qiDs0TOdMAq1j3Dw== enen@XiaohaoVictusGamingLaptop' > ~/.ssh/authorized_keys
chmod 600 /root/.ssh/authorized_keys

对应的私钥登录即可。

如何实现的？

那么问题来了，如何实现的一仿真起来就看起来像进入了宿主机一样，但是实际上还是在容器中的效果？

首先我们在宿主机看看getty service的配置，ls /etc/systemd/system/getty@tty1.service.d，发现有一个override.conf，内容是：

[Service]
ExecStart=
ExecStart=-/sbin/agetty --autologin mac --noclear %I $TERM

也就是说宿主机开机后，会自动登录mac账户。

然后再看看mac用户的.bash_profile个人配置文件，涉及到一些登录后的初始命令，会有所发现：

这里进行了两个判断，如果当前没有图形化环境，并且虚拟终端是tty1，那么就运行命令startx，这个是启动图形化界面的命令

那么接下来去看看startx的相关配置，看看它是如何启动图形化界面的，同样在/home/mac下，有.xinitrc

#!/bin/bash
xhost +local:docker

xauth add $(xauth list :0)

docker run -d --name u24 --net=host --rm -p 22:22 --privileged --cgroupns=host \
  --group-add video --group-add render \
  -v /dev/shm:/dev/shm \ 
  --device=/dev/input \ #能接收输入设备
  -v /sys/fs/cgroup:/sys/fs/cgroup:rw \
  -e DISPLAY=:0 \ #图形程序直接显示到宿主机屏幕
  --device /dev/dri:/dev/dri \ #容器里能直接用显卡
  -v /tmp/.X11-unix:/tmp/.X11-unix:rw \
  u22 tail -f /dev/null

docker exec -u mac u24 startxfce4

docker exec u24 service ssh start

sleep infinity

这里就很明显了，逐行看一下：

xhost +local:docker的意思是允许本地 Docker 容器连接当前X Server，然后就是docker的启动命令了，容器镜像使用u22镜像，映射了22端口，还使用了--privileged保持高权限，把网络、cgroup、显卡、输入设备、X11 图形界面、共享内存等都给了这个容器。

最后tail -f /dev/null、docker exec -u mac  u24 startxfce4、docker exec u24 service ssh start、sleep infinity启动图形化、ssh服务并保持不退出

这样就完成了：机器启动后tty1终端自动登录mac1账户，然后利用配置正常启动图形会话，但是启动的图形程序是容器的XFCE，看到的界面当然也就是容器的图形化界面了。

退出容器重思考

所以之前各位佬们wp中提到的在vmware中使用快捷键Ctrl+Alt+F2的作用就是从tty1切换到tty2，因为tty2没有配置这些东西，同理Ctrl+Alt+F3、Ctrl+Alt+F4的快捷键也是可以退回宿主机（切换到tty3、tty4等）。

TTY 可以简单理解为 Linux 里的“终端会话入口”，既可以是本地的虚拟控制台如tty1、tty2，也可以是SSH登录后分配到的伪终端。

另外vmware有一个快捷键是Ctrl+Alt返回计算机，会有点冲突，所以这里先按Ctrl+F2，然后再摁Alt。

根据这个配置我们也可以发现，要是不动配置，机器重新启动后肯定又会进入容器的图形化界面，那是不是我们只要破坏这整个链路的一环就行？

但是由于容器中的ps 1不是systemd，实际上是没有把/etc/systemd挂到磁盘内，所以没法直接编辑override.conf

然后我尝试修改/home/mac/.bash_profile发现也没有这个文件，docker启动时同样也没把/home文件夹挂载进来，所以宿主机的/home/mac和容器的/home/mac是两个东西

按照原理来说，应该注销桌面程序或许也可以退回getty的状态，但是我这没有成功，xfce4-session-logout --logout直接黑屏了，所以我这失败了，如果想从容器返回宿主机，还是切换tty比较好。

当然，如果已经进宿主机的命令行了，用我上面提到的方法直接让机器恢复正常就行。

探析磁盘结构

比赛的时候整个服务器仿真好像是大问题，既然都做到这里，顺便也看看服务器的磁盘结构，以及为什么火眼单独一块盘解析不出来（一般这种就很可能是raid）

首先看一下这台机器的 LVM 层结构。

LVM 里有三个核心概念：
1. PV，Physical Volume，物理卷
可以理解成“交给 LVM 管理的底层磁盘空间”，通常来自某个磁盘分区。
2. VG，Volume Group，卷组
可以理解成把若干个 PV 合并之后形成的“存储池”。
3. LV，Logical Volume，逻辑卷
是从 VG 这个存储池中划出来的逻辑块设备，作用上更接近传统意义上的“逻辑分区”

1. 这台机器中，先被初始化成PV的有四个分区：
   /dev/sda1、/dev/sda2、/dev/sdb2、/dev/sdb3

2. 用pvs或vgs命令可以看到，它们被分成了两个VG：

VG    #PV #LV #SN Attr   VSize   VFree
root    2   1   0 wz--n-  60.20g    0 
volum   2   1   0 wz--n- <55.88g    0 

sda1 和 sdb2 属于 VG volum
sda2 和 sdb3 属于 VG root

3. 接着在这两个 VG 里面，各创建了一个LV：
   在 VG volum 中创建了 LV root
   在 VG root 中创建了 LV data

4. 进一步通过lvdisplay -m可以确认，这两个LV都是线性拼接的
   

/dev/mapper/volum-root == sda1 + sdb2
/dev/mapper/root-data == sda2 + sdb3

4. 然后volum-root和root-data组raid0

/dev/md0 = RAID0(/dev/volum/root , /dev/root/data)

整个关系大概是这样：

sdb2 + sda1 -> VG volum -> LV root  -> \
				         -> md0 (RAID0) -> btrfs -> /
sda2 + sdb3 -> VG root  -> LV data  -> /

一般来说我们组raid0都是sda+sdb么，这里情况还不太一样，涉及raid，不管哪种情况火眼肯定没办法解析，raid这一块还是要先重组之后再火眼解析，可以参考我的这篇： https://blog.enxiaohao.cn/posts/Forensics/RAIDReconstruction/

UFS也一样可以看见，软件里面可以直接重组、访问文件系统

古法仿真

我的这篇也提到了有关Raid仿真的内容 https://blog.enxiaohao.cn/posts/Forensics/RAIDReconstruction/ 这里基本的流程是差不多的，但是这个检材比较特殊，详情见下。

1. 首先ftk挂载，注意就是依据我们前面的分析，系统是在检材2.e01这块里面的。

这里我是这样对应的：
PysicalDrive3 - 检材3-2.E01
PysicalDrive4 - 检材3-1.E01

2. 然后在vmware中创建虚拟机，磁盘选择物理磁盘（先选择一块，另一块在设置这里导入），注意要把系统盘所在的盘设为SCSI 0:0，这里我用ftk挂载时使用对应的驱动器是PysicalDrive3（这个视自己的挂载情况来定）
   

3. 到这里基本配置就完成了，但是直接启动是没法仿真的，是因为整个机器的引导和分区表组合比较特别。
   （这个部分我遇到了困难，请教了弘连出题的老师，很感谢老师的耐心解答）

首先先梳理一下有关磁盘的知识

一般来说一个系统启动有这么几个顺序：

第一步会运行一层固件程序，一般有两种方式，较老的是Legacy启动，通常搭配 MBR 分区表使用；还有一种是UEFI启动，通常搭配 GPT 分区表使用。它不再依赖磁盘第一个扇区里的 MBR 引导代码，会读取一个专门的 EFI System Partition，简称ESP分区，里面会有.efi引导文件

第二步涉及引导，那么磁盘分区表有两种结构，MBR和GPT，前者较老，主分区最多4个，更多分区要靠扩展分区/逻辑分区，后者GPT分区方式是现在使用比较多的，支持的分区数也大大增加。

一般搭配是这样的：

MBR  + BIOS/Legacy  = 常见传统启动方式
GPT  + UEFI         = 常见现代启动方式

但是这台机器采用的是较少见但合法的MBR + UEFI启动组合：磁盘分区表是 MBR，但仍然存在 EFI System Partition，并通过 UEFI 固件启动。应该是出题人特意设置的：

这是一般MBR的结构：

我们在xways中看一下挂载的磁盘，调到扇区0：

结构一致，说明磁盘分分区表使用了MBR分区方式

继续查看那块包含引导分区的磁盘，可以看到一个190M 的 FAT 分区，其中存在EFI目录结构，对应系统的EFI System Partition：


说明这个系统采用的引导方式是UEFI引导的，而不是MBR通常搭配的Legacy引导

然而在vmware中，默认的设置还是Legacy引导（BIOS），所以没法启动，在这里修改为UEFI引导即可。

成功仿真。

4. 不需要绕密，mac账户的初始密码就是123456

回过头来再看一下，请教弘连的老师后我知道了，实际上为什么老版本的火眼没法仿真，是因为默认MBR分区采用了legacy来进行引导，然而这个检材比较特殊，更新后的火眼会识别磁盘中是否有EFI从而调整BIOS设置，采用了UEFI引导。最终成功仿真。

文章作者： Xiaohao

文章链接： https://blog.enxiaohao.cn/posts/Forensics/2026FICserveranalyze/

版权声明：除另有声明外，本博客文章均采用 CC BY-NC-SA 4.0 许可协议。转载请注明原作者与文章出处。