2026盘古石杯初赛 介质&物联网汽车部分 WriteUp

其实本来有点懒得详细写最近比赛的复盘了，也不太有很多时间写一些简单题的过程。但是发现这两部分好像网上没人发，复现的时候正好复习一下数据分析和数据恢复的一些知识，索性就写一篇复现笔记吧。

介质取证

有关簇、扇区的基本概念和FAT文件系统的原理就不细说了，不过感觉MBR分区以及FAT32和GPT文件结构这些基本的数据恢复知识还是很有必要学的。详细知识点我这篇博客不做详细解释，大家可以在网上搜索一些资料学习。

呃呃，看电影的题就不做了。

X-ways如何打开？

首先想xways直接打开看这个img检材是不行的，会直接崩溃，010打开可以看见，这个0号扇区不太对

这个应该是DBR引导扇区，有MSDOS标志。但是很明显文件尾部的55AA没有了，很多地方和第六扇区的备份不一样。

最简单的，把6号扇区的备份恢复回去，然后就能看了。

shutil.copyfile(src, dst)

with dst.open("r+b") as f:
    f.seek(6 * 512)
    boot = f.read(512)
    f.seek(0)
    f.write(boot)

备注一个结构图帮助理解，这里没有MBR相当于整个镜像都是一个文件系统卷，就是常见于U盘、SD卡这种的。

当然，火眼还是十分强大，直接解析文件结构了，但是前面有关bpb参数的一些题目是没法用火眼做的。

题目部分

1. 分析方俊朗UDisk.img检材，第一个扇区前3字节的十六进制值是什么？（答案格式：AA-DD-WW）

   EB-3C-90

2. 分析方俊朗UDisk.img检材，每簇占多少个扇区？（答案格式：2）

8

正好复习一下DBR引导扇区BPB的参数解析，这里加粗的是重点

这里比赛给的标准答案是根据错误的扇区来的，我不是很认可。后面的题干里面有提到“真实的根目录起始簇”，所以我只能姑且理解成，如果题干没提到“真实的”之类的语义，那就都按照原始的错误的DBR引导扇区来。

0DH位置表示的就是一簇有多少扇区，原始镜像的参数是8，即1簇8个扇区

如果说是正确的DBR引导中的BPB参数，那么应该是0x10，16个扇区

后面的文件结构也是和这个相符的。
3. 分析方俊朗UDisk.img检材，FAT12/16兼容字段"根目录项数"是多少？（答案格式：100）

512

在11H位置开始，长度2字节，转端序后为0x200,512

4. 分析方俊朗UDisk.img检材，隐藏扇区数是多少？（答案格式：13）

63

这个是从1CH开始，长度4字节，转端序后为0x0000003F，63

5. 分析方俊朗UDisk.img检材，BPB中声明的总扇区数是多少？（答案格式：100000）

50000000

20H开始，四字节，转换后为50000000

6. 分析方俊朗UDisk.img检材，每张FAT表占多少个扇区？（答案格式：10000）

30000

24H开始，四字节，转换后为30000

7. 分析方俊朗UDisk.img检材，真实的根目录起始簇应为多少？（答案格式：3）

2

这里应该是要根据正确的DBR引导扇区回答。根据上面的表，起始簇的信息在2CH，长度两字节。所以这题答案是2

8. 分析方俊朗UDisk.img检材，FSInfo扇区号是多少？（答案格式：1）

3

一样的思路。

9. 分析方俊朗UDisk.img检材，备份扇区实际引导扇区号是？（答案格式：2）

   6

10. 分析方俊朗UDisk.img检材，卷序列号的十六进制值是多少？（答案格式：0x45463）

0x12345678

转一下端序，0x12345678

正确的序列号应该是这个，但是比赛的时候我交的这个答案是错了，那答案大概是上面那个0x12345678。。。。

11. 分析方俊朗UDisk.img检材中的视频，进入暗门的密码是多少？（答案格式：123）
12. 分析方俊朗UDisk.img检材中的视频，主角第一次带货去的国家是？（答案格式：泰国）
13. 分析方俊朗UDisk.img检材中的视频，阿成乘坐的奔驰车牌号是多少？（答案格式：京A-1234）
14. 分析方俊朗UDisk.img检材中的视频，男主角弟弟上司总共戴过几款领带？（答案格式：5）
15. 分析方俊朗UDisk.img检材中的表格，出现电话号码最多的后四位是？（答案格式：1234）

2133

16. 分析方俊朗UDisk.img检材中的表格，平均资产最高的BIN码？（答案格式：123456）

    622446

df['BIN'] = df['银行卡号'].astype('str').str[:6]

binaverage = df.groupby(by = 'BIN')['资产（人民币）'].mean().sort_values(ascending=False)
binaverage

银行卡的BIN码就是卡号的前六位。这里思路和前面的差不多

17. 分析方俊朗UDisk.img检材中的表格，邮箱字段中出现几种不同的域名？（答案格式：4）

3

18. 分析方俊朗UDisk.img检材中的表格，男性比女性多出多少人？（答案格式：991）

354

19. 接上题，按“最后登录时间”的月份（2024-01~2024-12）计算每月近90天活跃率，并给出其变异系数CV=标准差/均值。（答案格式：2.234565）

0.261120

这个题干信息密度比较凝练，首先我们应该计算每个月的活跃率，也就是说要统计每个月登录过的用户和截止到当前时间的已注册用户数（不知道我的理解有没有错，比赛的时候这个题目做的不对），然后计算每个月活跃率的标准差和均值，最后得到变异系数CV

遛一下GPT，实际上这个手写也不复杂。

20. 接上题，做反事实模拟：每位客户信用评分统一+20分（上限900）。统计“由非目标迁入目标”的人数，目标定义为 信用>=700 且 资产>=全体中位数。（答案格式：12345）

    36636

没那么复杂，就是资产>=全体中位数并且680 <= 信用评分 < 700的总人数。

原理再探析

然后我们来对比一下前后两个DBR引导分区的字节数据，看看出题人到底修改了什么，让我们的xways直接崩溃

我这里圈了几个比较关键的数据

对比BPB参数表整理一下：

字段	偏移	0 号主 DBR	6 号备份 DBR
跳转指令	0x00	EB 3C 90	EB 58 90
每簇扇区数	0x0D	8	16
根目录项数	0x11	512	0
隐藏扇区数	0x1C	63	0
总扇区数	0x20	50000000	30233588
FAT 大小	0x24	30000	14747
根目录起始簇	0x2C	5	2
FSInfo 扇区号	0x30	3	1
备份引导扇区号	0x32	9	6
卷序列号	0x43	12345678	0C0F6F08
结束签名	0x1FE	0000	55AA

我推测的是，Xways采用磁盘方式去读取这个文件系统时，就是会根据0号扇区的BPB参数来进行解析。然而这个0号扇区的很多关键参数被改错了，比如很重要的根目录起始簇、总扇区数、每簇扇区数。使用错误的数据去解析，应该是导致崩溃的主要原因。

这类涉及到数据恢复的题目我觉得也是取证中很有意思的点，虽然不过是市面上的恢复工具还是现在ai都已经能够数据恢复做的很好，但是我依然觉得手工去修复仍然能让我对于整个文件系统原理、文件读写删除方式有更深入的理解。

物联网汽车取证

物联网汽车取证部分其实整体不难，个别几个题目要结合标准分析一下。只不过现在大家都有ai，没有什么人会用传统方法做这类题目。正好之前我做的车机取证题目不多，趁这个机会学习一下。

整个检材文件不多，先大致看看：

car.E01/分区1/dashcam，dashcam是行车记录仪的日志，能找到一个json文件metadata.json，应该是记录了一次碰撞：

事故时间是在2025-12-15T23:45:01Z ，UTC+8就是2025-12-16 07:45:01
然后在/data下面有大量的日志

1. adas 高级驾驶辅助系统
2. canbus 控制器局域网总线，车辆上的各种控制器通过总线通信
3. dlt 诊断日志与跟踪日志，主要记录软件模块运行状态
4. power 电源/电能/上下电相关日志
5. tbox 车联网终端 / 远程通信盒 / 车载通信模块，负责车辆和外部网络通信

先看看dlt文件夹下的这个日志：

ADAS记录了一个控制命令，-45deg，向左转向45度
然后网关记录了一个错误，Invalid CRC on msg 0x0A0
然后一条SAFE类型记录，发送了碰撞

然后在看看car.E01/分区1/system/var/log/syslog下面的两个系统日志，出题人也很好，只保留了入侵相关的日志

syslog：

Dec 15 23:10:01 systemd[1]: Started Bluetooth Service.

Dec 15 23:20:05 systemd[1]: Starting Network Manager...

Dec 15 23:25:00 sshd[1020]: Accepted publickey for root from 45.33.22.11 port 52312 ssh2

Dec 15 23:25:05 root[1022]: Executed command: systemctl stop sec_monitor

Dec 15 23:30:10 sshd[1150]: Accepted publickey for root from 45.33.22.11 port 52314 ssh2

Dec 15 23:35:00 can_router[445]: CRITICAL - Injection packet queue overridden by root UID 0

Dec 15 23:45:00 crash_reporter[890]: G-Sensor trigger: severity=HIGH, recording core dump.

kern.log

kernel: [    0.000000] Linux version 5.15.32-staros

kernel: [    1.020300] random: crng init done

kernel: [   25.105423] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

kernel: [ 3605.123512] usb 1-1.2: new high-speed USB device number 4 using xhci-hcd

kernel: [ 3605.234123] input: HID Keyboard Device as 

/devices/pci0000:00/0000:00:14.0/usb1/.../input/input8

kernel: [ 3612.999888] staros_sec: WARNING - Load module /data/local/tmp/k_hook.ko without 

correct signature!

kernel: [ 3613.001000] k_hook: init successful. Syscall table hooked.

kernel: [ 4200.555555] CAN: bus-off on can0

题目部分

1. 分析黄志远car.E01检材，事故发生前车辆发生了非驾驶员意图的左转，找出控制车辆异常转向的恶意指令 ID。（答案格式：3B4）

   0A0

根据前面的分析已经基本可以确定恶意ID是0x0A0，因为CRC错误，这个指令校验可能是被注入的。

adas CAN 总线日志中也确实有大量的0A0异常记录，这个0A0后面的签名全部都是0000

2. 分析黄志远car.E01检材，分析动力总成总线日志，判定驾驶员在碰撞发生前的最后 5 秒内，是否真正尝试了手动踩下制动踏板？若有，请说明判定依据；若无，请提交其加速踏板的百分比数值（答案格式：10%）

   100%

powertrain_can.asc是动力总成总线日志，翻到最后，发现出现大量ID为050的日志，最后一条不是050的日志是大量的1F4，对应的data字段是0x64=100。因此猜测这个是加速踏板的百分比。

这几个总线日志的时间好像不是特别对得上，挺奇怪的，这个相对时间在120s，根据总线日志的header推算时间大概为11:47:00.000 pm，和事故时间不太对得上。

3. 分析黄志远car.E01检材，攻击者通过同频注入压制了原车 ADAS 信号。请在日志中找出证明这是“人为注入攻击”而非“ECU原生故障”的报文频率特征描述。（答案格式：111msg）

没太懂，应该是要分析0A0这个命令出现的频率特征，但是这个特征描述具体指什么不太清楚。

4. 分析黄志远car.E01检材，分析动力总成总线日志，确定车辆由于碰撞导致轮速传感器信号彻底消失（归零）的确切时间点（秒）。（答案格式：1.1）

   120.0

第二题分析可知，日志结尾第一个050出现的时间为120.000139，此时应该是事故发生的时间

5. 分析黄志远car.E01检材，基于安全通讯协议，部分关键报文需带有 MAC 认证。请找出恶意转向报文中，证明其为非法注入的最直接协议层安全缺陷项。（答案格式：1234）

0000

我们知道恶意的指令是0x0A0，adas总线日志在118时间左右出现异常（前面也有提到）
后面的签名都为0000，前面也有报错CRC错误，这些都是强制注入的证据。

118.433811 1  0A0             Rx   d 8 01 FF FF 00 00 00 00 00

6. 分析黄志远car.E01检材，逆向分析 ADAS 固件，指出其中隐藏的恶意控制代码被触发所需的最低车速阈值（单位：km/h）（答案格式：100）

   120

car.E01/分区1/system/lib/firmware/ecu/adas_ecu.bin


TRIGGER=SPEED>120，最低车速阈值为120

7. 分析黄志远car.E01检材，事故车辆的发动机控制系统已被黑客篡改。请指出其为了获得超高速动力，在固件中非法解除了哪个速度限制相关的标志？（答案格式：LIVE_TEACH）

   VMAX_LIMIT

strings看engine_ecu.bin可以看到VMAX_LIMIT:OFFMAP_PERF_TUNING_END

8. 分析黄志远car.E01检材，固件中存储了用于安全通讯的 Master Key Seed。请通过分析网关固件，提取该 16 位十六进制种子值。（答案格式：1234567890ABCDEF）

   A9B8C7D6E5F40123ALGO

9. 分析黄志远car.E01检材，通过分析 BCM 模块导出数据中的 Crash Dump 碎片，还原碰撞发生瞬间，车辆大灯处于什么照明模式？（答案格式：LIVE_LIVE）

   HIGH_BEAM

10. 分析黄志远car.E01检材，取证人员在车机浏览器数据库中发现黑客曾访问一个特定的 GitHub 代码仓库地址。请提交该仓库的名称部分。（答案格式：cache_asdf_efg）

    staros_root_poc

car.E01/分区1/data/data/com.starway.browser/databases/history.db

11. 分析黄志远car.E01检材，T-BOX 系统配置文件已转换，需解密出被黑客覆写的关键远程代理地址的 IP 地址。（答案格式：1.1.1.1）

    45.33.22.11

这里要解密加密的配置文件car.E01/分区1/tbox/config/system.conf.enc

xor加密，异或5A的时候看见明显的http头

C2_PROXY=45.33.22.11:8080，这个ip在前面分析过程中也有出现

12. 分析黄志远car.E01检材，查看系统升级日志。黑客在强制刷入恶意固件时，使用了哪个完整的“强制忽略签名”参数标志？（答案格式：+d devicesid）

    -f force

系统升级日志是在car.E01/分区1/tbox/ota/update.log，很明显用到了-f force参数

13. 分析黄志远car.E01检材，分析蓝牙连接历史，找出在碰撞前几分钟连接成功的可疑设备名称。（答案格式：Forensc_Live_KKK）

    Diagnostic_Dongle_BLE

下面这个时间戳1702654800比较像，但你难绷的是这个时间戳是2023-12-15 23:40:00 +08:00，和事故年份对不上的，UTC也对不太上。。。但是答案是这个没问题，出题时间小细节没对齐

下面一张表可以看见对应的设备名为Diagnostic_Dongle_BLE

14. 分析黄志远car.E01检材，系统的后门程序伪装成系统组件以此维持权限。请填入该 ELF 攻击脚本在 T-BOX 上的完整绝对路径。（答案格式：/home/abc/adc.raw_adc）

    /data/local/tmp/syslogd_update

在前面好像看见过/data/local/tmp相关，去看一下
找到这个car.E01/分区1/data/local/tmp/syslogd_update
有回连字符串，这个应该就是后门

15. 分析黄志远car.E01检材，从 EDR 采样记录中提取出车辆在碰撞瞬间（采样点 0）记录的纵向车速数值（单位：km/h）。（答案格式：100）

180（异议）

有关EDR的采样记录在car.E01/分区1/edr/events，和事故相关的应该是event_00042_c.bin，因为文件开头有：

EDR_STARWAY_V2
LSGXE53W7PS012345

对于EDR，应该采用9字节一组，基本结构为

[车速] [加速踏板] [制动状态] [横/纵向相关值] [RPM低字节] [RPM高字节] [保留/状态]

从0x48开始

55 14 00 00 00 F6 09 00 00
55 14 00 00 00 F6 09 00 00
55 14 00 00 00 F6 09 00 00
64 64 00 00 00 B8 0B 00 00
73 64 00 00 00 7A 0D 00 00
82 64 00 00 00 3C 0F 00 00
91 64 01 FB FF FE 10 00 00
A0 64 01 F1 FF C0 12 00 00
AF 64 01 D3 FF 82 14 00 00
B9 64 01 A6 FF AE 15 00 00
B4 64 01 88 FF 18 15 00 00

每0.5s记录一次，所以最后一条是碰撞瞬间的数据，第一条就是碰撞前5s的数据。

对于最后一条数据，0xB4对应的车速是180。（我觉得这样分析是没错的，就是不知道为什么比赛时提交的这个答案不正确。。）

16. 分析黄志远car.E01检材，从碰撞前5秒采样点中恢复出的纵向车速是多少？（答案格式：100）

    85

对应的这一条记录，0x55=85，因此从碰撞前5秒采样点中恢复出的纵向车速为85km/h

55 14 00 00 00 F6 09 00 00

17. 分析黄志远car.E01检材，分析 OBD 诊断历史，提取出碰撞瞬时车辆自动记录的冻结帧（Freeze Frame）中的引擎 RPM 数值。（答案格式：100）

    2000（异议）

车载obd诊断日志在car.E01/分区1/obd/history

dtc_records.log中看到Crash detected对应frame为B0070

对应的bin为

只有几个16进制数值，不太看得懂，要去查一下OBD的标准 https://suphy2009.github.io/vehicle/obd_ii_pids.html

前面的B007的意思应该是对应前面的那个故障码，然后后面的0C才是PID对应的模式编码，后面的02意思是后面跟两字节的数据，这个和后面的公式也是对应的。

标准给出了计算rpm的公式，这里的A=0x1F，B=0x40，可以计算得出rpm =2000

我觉得没什么问题，很好奇官方的答案是什么

18. 分析黄志远car.E01检材，分析 PKE 系统的 RF 日志，找出那把非法克隆生成的 NFC 卡片钥匙所对应的 ID，该 ID 在事发当晚被用于非法侵入。（答案格式：0xAB12）

    0x9F8E

rf日志在 car.E01/分区1/security/pke/rf_logs.txt

晚上出现的ID为0x9F8E，对应也有Unlock Success日志。

19. 分析黄志远car.E01检材，在行车记录仪元数据中记录了碰撞瞬间的加速度。请指出该元数据完整性校验的状态。（答案格式：TRUE）

    FAILED

提到行车记录仪元数据，那么就是car.E01/分区1/dashcam/metadata.json

对应的”integrity_check”: “FAILED”

20. 分析黄志远car.E01检材，综合分析所有证据，黑客最终通过哪种方式实现了对车辆 ADAS 固件的非法篡改？（答案格式：加油ABC）

    诊断服务强制刷写ADAS（不知道官方标准答案是什么）

tbox/ota/update.log

DEBUG_MODE: Local firmware push detected.
WARNING: Signature bypass flag is active (-f force).
Flashed partition 'adas' via diagnostic service.

21. 分析黄志远car.E01检材，在遥感数据包流量中，黑客在回传 C2 服务器的数据中实时记录了车速。请找出 JSON 载荷中 speed 键对应的值。（答案格式：100）

    180

流量包中的第一条记录，speed字段为180

22. 分析黄志远car.E01检材，为躲避 IDS 的监控，恶意流量通过 HTTP GET 请求伪装成媒体流请求。请找出该恶意回连所请求的伪装域名（Host）。（答案格式：bing.com）

    streaming.starway.com

流量包中可以看见，跟题目描述的HTTP GET 请求相符


23. 分析黄志远car.E01检材，黑客建立 Reverse Shell 后，执行了哪条指令来强行停止车机底层的安全监护进程？（答案格式：abc.def）

systemctl stop sec_monitor

一样，也在流量包中

24. 分析黄志远car.E01检材，黑客通过发送包含固件包地址的 API 请求来下载恶意代码。提交 JSON 载荷中 pkg 键对应的完整 URL。（答案格式：http://www.baidu.com/login.html）

http://45.33.22.11/malicious.bin

25. 分析黄志远car.E01检材，黑客为了提权并获取 Root 用户身份，在 Shell 中执行的初始探测指令是什么？（答案格式：kk）

id

很明显，第一个命令是id

26. 分析黄志远car.E01检材，反向 Shell 成功建立后，返回的权限对应的 UID 数值是多少？\n（答案格式：100）

0

跟上题一样的位置，id返回的是root用户，UID为0
27. 分析黄志远car.E01检材，黑客在其利用漏洞上传的 ELF 脚本中，使用了哪个特定的进程名称来伪装成系统日志服务？（答案格式：deadlive_solodata）

syslogd_update

前面提到的tmp下面的后门文件，其文件名为syslogd_update，即伪装的系统日志服务。

这次复现仅仅是根据赛后的答案反馈进行复现的，可能有个别答案和标准答案有出入。结合ai，我个人对部分的题目答案也有异议，欢迎各路大佬指点。

文章作者： Xiaohao

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

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