【固件分析】记一次DJI无人机DAT文件取证分析过程

结论

从我这次的结论来说，除非是IOT安全出身，否则遇到大疆无人机机身DAT文件，走调证几乎是唯一的路径。

提取

大疆无人机的机身日志数据提取非常简单，只需要使用一根typec-USB或typec-typec的连接线一头连接到机身一头连接到电脑，使用DJI Assistant 2 （注意根据机型选择相应版本）在日志导出中勾选相应的时间导出即可。

DAT文件解析

导出的文件，根据机身不同文件名称也会随之变化——DJI Air 3S导出名称格式为DJI_Air_3S_YYYY-MM-DD_HH-MM-SS.DAT,DJI MINI 4k导出格式为EXPORT_FILE_YYYY-MM-DD_HH-MM-SS.DAT 。

本文以MINI 4k导出的格式为例进行分析，使用010 Editor打开后文件头为典型的zlib789C。

使用AI生成一个zlib解压脚本

# -*- coding: utf-8 -*-from __future__ import annotations
import argparseimport zlibfrom pathlib import Path

def main() -> None:    ap = argparse.ArgumentParser(description="Decompress DJI Assistant zlib DAT export")    ap.add_argument("-d", required=True, type=Path, help="input DAT path")    ap.add_argument("-o", required=True, type=Path, help="output decompressed path")    args = ap.parse_args()
    raw = args.d.read_bytes()    plain = zlib.decompress(raw)    args.o.parent.mkdir(parents=True, exist_ok=True)    args.o.write_bytes(plain)    print(f"in={args.d} ({len(raw)}) out={args.o} ({len(plain)})")

if __name__ == "__main__":    main()

使用010 Editor打开解压后的文件，其十六进制如下，不难发现，DAT文件其实是一个复合文件，每个文件的分割以A6为头，下图中可以看出有/flyctrl/latest、/flyctrl/FLY013.DAT。

将全部文件分解后发现文件大致为FLY*.DAT、tag_info.json、PARM.LOG、latest共四种，除文件头都存在加密，文件头大致格式为

a6 | 20 00 00 00 | fa 71 | 2f 66 6c 79 63 74 72 6c 2f 6c 61 74 65 73 74 ...

│ │ │ └── 路径 "/flyctrl/latest"

│ │ └── 未知 2 字节

│ └── 长度 = 0x20 = 32

└── 魔数

DJI Air 3S的导出文件具体格式与MINI不同，但也为高熵密文，其文件头有LOGH标记。D3VL DJI-DAT-Decrypto是一个开源的大疆DAT文件解密工具，目前仅支持Avata 、 Goggles2 、 O3三类机型，其解密算法核心如下。

session = AES-CMAC(master, 0x01||"LOG"||0x00||LOGH[0x18:0x5C]||0x80)plain   = AES-128-CBC(session, IV=0)(cipher)

该算法与DJI Air 3S的导出文件通用，但master key无法获得，经过分析，加密大概率在机身内完成，软件导出的是已经加密后的密文。

固件包

既然无法从文件本身分析，那就试试从固件升级包入手，DJI Assistant 2支持对无人机进行刷机，下载的固件包默认缓存在\DJI Assistant 2 \DJIEngine\DJIData\firm_cache\下，将固件包导出后使用如下算法可以对固件升级包（UFIE）进行解密，具体密钥需要具体查询。

scram_key_plain = AES-ECB(UFIE).decrypt(scram_key_enc)payload_plain   = AES-CTR(scram_key_plain, IV=16×0x00).decrypt(payload)

对外层解密后，其内部为

模块	解开后看到什么	和日志的关系
0100 CAM	加载器 + 嵌套加密镜像 + 疑似 SquashFS	有镜像钥字符串，无日志 master key
0306 FC	`xV4` 容器，仍有二层	日志相关，但进不去
0905 NFZ	结构化禁飞数据	无关
1100/1200	电池/电调固件	无关

对CAM块进行分析，其大致结构为

偏移	内容	熵	状态
0	短文件头	低	可读
152	LDR1加载器区	7.0	部分可读
~94.7KiB	IMAGE ENC KEY WM160	8	仅部分字符串
153333	IM*H + PRAKTBIE + rtos	8	加密
13216886	IM*H + PRAKTKIE + linux	8	加密
17469843	SquashFS 4.0 gzip，143 inodes	8	无法挂载
18940567	SquashFS 4.0 xz，676 inodes	8	无法挂载

总的来说就是外层可解密，内层无法解密，一切加解密操作都在机身内完成。

总结

还记得是22年的美亚杯，当时给了一个FLY.DAT的检材，那个时候的解密非常简单只需zlib+xor即可对轨迹进行还原。IOT设备的安全防护也是做的越来越好了，除了一切加解密都在机身完成，很多设备甚至做了熔断机制，这对固件提取分析也极其困难（成本也极高）。但另一方也为取证分析带来了更大的难度，比起纯技术分析，调证更是个艺术活。