Proxmark3 Tracelog 实战指南:trace 命令逐列解读、tracelog 二进制格式与 Wireshark 联合分析
发布时间:2026/9/17 21:39:28 作者:尧图编辑部 阅读量:1,286

Proxmark3 Tracelog 实战指南trace 命令逐列解读、tracelog 二进制格式与 Wireshark 联合分析【免费下载链接】proxmark3Iceman Fork - Proxmark3项目地址: https://gitcode.com/GitHub_Trending/pr/proxmark3本篇围绕 Proxmark3 的 tracelog射频通信追踪日志体系展开trace命令族如何将设备捕获的空中帧以人类可读形式呈现、每列数据时间戳、方向、原始字节、CRC、注释的确切含义以及 tracelog 的二线制存储格式。读完后你可以熟练用trace list逐协议解读通信、用trace save/trace load离线回放抓包并把 ISO14443-A 抓包转成 pcapng 交给 Wireshark 做深度协议解析。1. trace 命令族从设备到客户端的抓包数据流Proxmark3 在执行射频操作读、写、仿真、嗅探等时FPGA 会把每一帧空中数据连同时间戳写入设备端的追踪缓冲区。客户端的trace命令族负责把这份数据下载并解释。在 client/src/cmdtrace.c 的命令表中trace共注册了 6 个子命令子命令功能trace list按选定协议解释并列出追踪缓冲区内容核心命令trace extract从追踪中提取认证质询authentication challengestrace save -f fn下载并保存追踪到.trace二进制文件加-1则保存客户端缓冲区trace load -f fn从.trace文件加载到客户端缓冲区trace clear清空客户端侧缓冲区设备侧需另用data cleartrace help帮助信息这里有两个容易混淆的缓冲区概念源码中区分得很清楚设备端追踪缓冲区需要download_trace()拉取与客户端全局缓冲区gs_trace。trace list -1、trace save -1、trace extract -1的-1参数都表示直接使用客户端缓冲区即离线分析场景先trace load再-1系列操作不加-1时则默认从设备端下载最新数据。trace list的提示文案也明确给出了离线用法提示Hint: Try trace list -1 -t ... to view trace见 client/src/cmdtrace.c。典型工作流# 在线让设备抓一段交互后直接查看 trace list -t 14a # 离线保存 → 事后加载 → 逐条分析 trace save -f mycapture trace load -f mycapture trace list -1 -t mf -f mfc_default_keys.dic2. trace list 输出表逐列解读trace list输出一个表格逐行展示设备与标签/读写器之间的数据交换。表头client/src/cmdtrace.c为Start | End | Src | Data (! denotes parity error) | CRC | Annotation -----------------------------------------------------------------------------------------------示例一行19072 | 29536 | Rdr |93 70 88 04 cf ff bc 7f bb | ok | SELECT_UID2.1 TimingStart 与 End 的时间单位随协议而变Start 列是首个 bit 发出的时刻End 列是最后一次调制结束的时刻。时间单位取决于所选协议这是理解整个表格的关键。文档doc/trace_notes.md给出的单位约定与当前源码中的提示文案一致协议时间单位说明ISO14443A、Thinfilm载波周期1 个单位 1/13.56 MHzLEGICReader Modeticks1 µs 1.5 ticksLEGICTag Mode子载波周期1/212 kHz ≈ 4.7 µsHitag1 / Hitag2 / HitagS / Hitag µETU1 ETU 8 µs值得注意的是原文档写成iCLASS、ISO15693、ISO18092 和 FeliCa 目前没有精确计时而从当前源码结构看client/src/cmdtrace.c实现已经演进这些协议现在也会显示载波周期1/13.56 MHz计时的时间列并且trace list新增-u选项可把时间统一换算成微秒显示。此外 ISO14443B/CryptoRF 按载波周期计ISO7816-4/智能卡按 ticks1/1.5 MHz 0.67 µs计Calypso 与 FMCOS 2.0 则标注 Timings n/a。因此阅读旧文档结论时应以当前版本实际输出为准。帧延时显示原文档说用-f选项显示帧间延时frame delay times。在当前实现中这一功能由--frame或-r提供-f已让位给字典文件参数两者不可同时使用见 client/src/cmdtrace.ctrace list -t 14a --frame # 显示各帧相对上一帧的延时 trace list -t 14a -r # 相对上一传输的帧延时会打印一条 Frame Delay Time 说明行这样就不需要自己拿 End 与下一个 Start 做减法了。2.2 Sources方向判定Src列只有两种取值被判定为响应帧的标记为Tag其余一律标记为RdrReader。该标记来自 tracelog 头部的isResponse位而非客户端推断。2.3 Data空中原始字节与奇偶校验Data 列显示空中传输的原始字节。加!标记表示检测到奇偶校验parity错误带-r时短字节还会用标记。加c选项可把 CRC 字节用方括号标出方便与 CRC 列对照。2.4 CRC校验结果该列标记传输的 CRC 与计算出的 CRC 是否匹配ok或失败提示。一个有趣的实现细节Hitag 系列协议本身没有 CRC此列被复用为该帧的 bit 数因此表头会从CRC变成Bitclient/src/cmdtrace.c。2.5 Annotation粗略解码与协议深度注释Annotation 列提供数据的粗略解码如示例中的SELECT_UID。不同协议的注释深度差异很大ISO14443A 的深度解析建议交给 Wireshark见第 5 节MIFARE Classic-t mf则可以直接在客户端解密 Crypto1 数据流并支持-f指定字典文件如 client/dictionaries/mfc_default_keys.dic来匹配密钥Hitag2 会自动加载默认 Hitag 字典见 client/src/cmdtrace.c。当前trace list -t支持的协议别名源自 client/src/cmdtrace.c参数协议参数协议raw仅原始数据、无注释ht1/ht2/hts/htuHitag 1/2/S/µ14a/14bISO14443-A / -BiclassiCLASS15ISO15693legicLEGIC7816ISO7816-4ltoLTO-CMcalypsoCalypsomfMIFARE Classic解密 Crypto1 流cryptorfCryptoRFseosSEOSdesMIFARE DESFirethinfilmThinfilmfelicaISO18092 / FeliCatopazTopazmfpMIFARE Plusfmcos20FMCOS 2.0每个协议还有对应的快捷别名命令如mf list --frame等价于trace list -t mf --frame由 client/src/cmdtrace.c 中的CmdTraceListAlias统一实现。3. tracelog 二进制格式一条记录 8 字节头 数据 奇偶校验设备端动态 tracelog 的存储格式在 doc/trace_notes.md 中有完整定义且与公共头文件中的结构体逐字段对应include/pm3_cmd.h/* Traceformat: 32 bits timestamp (little endian) 16 bits duration (little endian) 15 bits data length (little endian) (0x7FFF) 1 bit isResponse (0reader to tag, 1tag to reader) data length Bytes data x Bytes parity, where x ceil(data length/8) */ typedef struct { uint32_t timestamp; uint16_t duration; uint16_t data_len : 15; bool isResponse : 1; uint8_t frame[]; // data_len bytes of data // ceil(data_len/8) bytes of parity } PACKED tracelog_hdr_t; #define TRACELOG_HDR_LEN sizeof(tracelog_hdr_t) #define TRACELOG_PARITY_LEN(x) (((x)-data_len - 1) / 8 1)格式要点定长头部 8 字节32 位时间戳 16 位持续时长后 16 位中低 15 位是数据长度上限 0x7FFF 字节最高位是isResponse方向标志。客户端所有解析逻辑都是靠TRACELOG_HDR_LEN data_len TRACELOG_PARITY_LEN(hdr)这条步进公式遍历记录例如 client/src/cmdtrace.c 中的SKIP_TO_NEXT宏。数据 奇偶校验字节每条记录在data_len字节数据后跟随ceil(data_len/8)字节的奇偶校验信息TRACELOG_PARITY_LEN宏即((data_len - 1) / 8 1)的整数除法形式。Data 列中的!奇偶校验错误标记正是拿这部分字节逐 bit 比对得出的。边界自检解析前会先验证TRACELOG_HDR_LEN data_len parity_len traceLen越界即停止见 client/src/cmdtrace.c 的printHexLine这保证了截断/损坏的.trace文件不会导致越界读取。理解这个格式后你可以直接对trace save导出的.trace文件做离线二进制分析而无需连接设备——这也是trace loadtrace list -1离线工作流的底层基础。4. 离线工作流save / load / extract结合第 3 节的格式.trace文件的存取闭环为trace save -f mytrace默认从设备端下载并写入文件注意它不会污染客户端缓冲区源码专门下载到独立缓冲再落盘见 client/src/cmdtrace.ctrace load -f mytrace把文件读入客户端缓冲区随后所有-1参数命令都在其上运行trace extract遍历追踪记录提取 MIFARE 认证质询challenge——例如 client/src/cmdtrace.c 中专门处理 ev2 认证帧21 字节挑战帧与后续附加帧的逻辑配合mf注释可辅助密钥恢复工作流。5. 将 ISO14443-A 追踪导入 Wireshark 深度解析trace list的 Annotation 对 ISO14443A 只有粗略解码更细的解析BCC、CRC 状态、字段含义可以借助 Wireshark 的 ISO 14443 解析器完成。完整流程执行trace list -t 14a -x它会输出专为 pcap 转换准备的 hexdump把从时间戳行开始的全部输出复制进一个文本文件运行text2pcap -t %S. -l 264 -n 输入文本文件 输出pcapng文件用 Wireshark 打开 pcapng或用命令行tshark -r foo.pcapng -V -x阅读。-x输出的每一行都严格对应 Wireshark 的 ISO 14443 伪头格式timestamp000000偏移 伪头 4 字节 数据。伪头定义为 version0x00、eventPCD→PICC 为0xfePICC→PCD 为0xff正好取自isResponse位、长度2 字节。这一逻辑就写在 client/src/cmdtrace.c 的printHexLine中——这也解释了为什么text2pcap的长度参数是 264 以及为什么目前只有 14a 支持-x输出default分支打印 Currently only 14a supported。对比同一帧在两侧的呈现。trace list -t 14a的一行19072 | 29536 | Rdr |93 70 88 04 cf ff bc 7f bb | ok | SELECT_UID同一数据在tshark -r foo.pcapng -V -x下的解析结果Frame 5: 13 bytes on wire (104 bits), 13 bytes captured (104 bits) on interface 0 Interface id: 0 (unknown) Interface name: unknown Encapsulation type: ISO 14443 contactless smartcard standards (177) Arrival Time: Aug 17, 2019 23:17:00.000002606 CEST ... ISO 14443 Pseudo header Version: 0x00 Event: Data transfer PCD - PICC (0xfe) Length field: 9 Message: Select SEL: 0x93 NVB: 0x70 CT: 0x88 UID_CLn: 04cfff BCC: 0xbc CRC: 0xbb7f [correct] [CRC Status: Good] 0000 00 fe 00 09 93 70 88 04 cf ff bc 7f bb .....p.......可以看到 Proxmark3 表中的93 70 88 04 cf ff bc 7f bb加上伪头00 fe 00 09后正好是 13 字节帧tshark 将其还原为 ISO14443A 的 Select 消息并给出 BCC/CRC 校验结论——这就是从人眼可读表格升级到字段级协议解析的完整链路。若 Wireshark 的 ISO14443A 解析器缺少某些命令或解析有误原文档建议直接向 Wireshark 上游提交 bug此处不再给出外部链接。6. 小结与源码索引看交互trace list -t proto配--frame/-r看帧延时、c标 CRC、u切微秒、-f dic挂字典-1走离线缓冲区存离线trace save/trace load.trace文件格式见第 3 节trace extract抓认证质询深解析trace list -t 14a -x→text2pcap -t %S. -l 264 -n→ Wireshark/tshark。关键源码位置内容位置tracelog_hdr_t结构与TRACELOG_*宏include/pm3_cmd.htrace list主逻辑与协议/单位提示client/src/cmdtrace.cpcap 伪头 hexdump 生成-xclient/src/cmdtrace.csave / load / clear / extract 子命令client/src/cmdtrace.c原始文档doc/trace_notes.md【免费下载链接】proxmark3Iceman Fork - Proxmark3项目地址: https://gitcode.com/GitHub_Trending/pr/proxmark3创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考