企业官网建设流程全解析

1. 前言

Proxmark3 是一款开源的 RFID/NFC 协议研究设备，支持高频（HF）和低频（LF）射频技术，可用于卡片识别、协议分析、通信监听、射频信号采样及授权安全测试。

本文使用 Proxmark3 RDV4.01，原设备使用较旧的 Iceman 固件，导致 Windows 11 上最新版客户端无法正常连接。

通过搭建 ProxSpace 开发环境，重新编译 RRG/Iceman 固件，并分别升级 BootROM 和 Fullimage，最终完成固件更新。

本次实测结果：

注意：本文的刷写步骤针对上述设备，其他 Proxmark3 硬件版本不能直接套用。固件刷写存在风险，请先确认硬件型号和镜像兼容性，并仅在授权的设备和卡片上开展测试。

2. Proxmark3 RDV4.01 硬件介绍

RDV4.01 是面向 RFID 协议分析和安全研究的 Proxmark3 硬件版本。

主要硬件组成包括：

• ARM7 微控制器 AT91SAM7S512；

• Xilinx Spartan-2 FPGA；

• 高频 13.56 MHz 射频收发电路；

• 低频 125/134.2 kHz 射频电路；

• USB 通信接口；

• 外部 SPI Flash；

• ISO7816 接触式智能卡扩展模块；

• BootROM 模式按钮及 LED 指示灯。

本次设备还识别到了外部 Flash 与智能卡模块。

它与普通 USB NFC 读卡器最大的区别，是能够在射频协议层进行监听、采样和分析，而不仅是调用应用层接口读取卡片。

3. 软件准备和下载

3.1 下载 ProxSpace

Windows 下推荐使用 ProxSpace 运行 RRG/Iceman 的编译工具链。

下载地址：

https://github.com/Gator96100/ProxSpace

进入 Releases 页面，下载适合 Windows 的版本。

将文件解压，例如：

D:\ProxSpace-3.12\

建议安装路径不要包含空格或中文字符。

3.2 启动 ProxSpace

进入解压目录，找到：

runme64.bat

双击启动。

首次启动时，ProxSpace 会下载并安装所需依赖，包括：

• Git

• Make

• GCC

• ARM GCC 交叉编译器

• MSYS2 / MinGW

• 各种依赖库

第一次启动可能需要较长时间。下载和安装完成后，会进入 Bash 命令行界面，出现类似提示符：

pm3 /d/ProxSpace-3.12$

注意：ProxSpace 使用 Bash 命令，与 Windows CMD 不完全相同。

3.3 下载 RRG/Iceman 源码

官方 GitHub：

https://github.com/RfidResearchGroup/proxmark3

在 ProxSpace 中执行：

cd /d/ProxSpace-3.12 git clone https://github.com/RfidResearchGroup/proxmark3.git cd proxmark3

检查源码：

git status git rev-parse HEAD

建议记录当前 Git 提交版本，便于后期复现构建。

4. 编译 Proxmark3 RDV4 固件

4.1 指定硬件平台

对于 RDV4.01，使用：

make -j4 PLATFORM=PM3RDV4

其中：

• make：调用构建系统；

• -j4：最多使用四个并行任务；

• PLATFORM=PM3RDV4：指定 RDV4 硬件平台。

如果此前修改过硬件平台参数，需要先清理旧构建产物，再重新编译。

4.2 编译生成的主要文件

编译成功后，主要文件包括：

proxmark3/ ├── bootrom/ │ └── obj/ │ └── bootrom.elf ├── armsrc/ │ └── obj/ │ └── fullimage.elf ├── client/ │ └── proxmark3.exe ├── pm3 ├── pm3-flash-bootrom └── pm3-flash-fullimage

各文件用途：

4.3 本次遇到的编译错误

第一次编译时，出现：

make[2]: cc: No such file or directory

原因是主机端 C 编译器不存在或未正确配置到 PATH。

需要区分两种编译器：

• arm-none-eabi-gcc：编译 ARM 固件；

• gcc/cc：编译 Windows 主机端工具。

在本次 MINGW64 环境中，安装 GCC：

pacman -S --needed mingw-w64-x86_64-gcc

注意：如果使用 UCRT64，应该安装对应的 UCRT64 软件包，不要混用。

验证：

gcc --version cc --version which cc

随后重新执行：

make -j4 PLATFORM=PM3RDV4

检查退出码：

echo $?

本次实测返回：

0

代表构建命令成功。

本次固件构建日志中还显示：

Firmware size: 496525 bytes (484kb) = 94% of 512kb

表示固件已接近目标 Flash 容量上限，但构建系统检查通过。

5. Windows 11 驱动安装与 COM 端口检查

5.1 连接 Proxmark3

使用支持数据传输的 USB 线，将 RDV4.01 连接到电脑。

Windows 11 通常可以通过内置 USB CDC 驱动识别设备。

打开：

设备管理器 └── 端口（COM 和 LPT）

本次设备显示：

USB 串行设备 (COM9)

5.2 使用 PowerShell 查看 USB 设备信息

打开 Windows PowerShell，而不是 CMD。

运行：

Get-CimInstance Win32_PnPEntity | Where-Object { $_.Name -match 'COM9' } | Format-List Name,Manufacturer,DeviceID

本次实测结果：

Name : USB 串行设备 (COM9) Manufacturer : Microsoft DeviceID : USB\VID_9AC4&PID_4B8F\ICEMAN

说明 Windows 已为设备分配 COM9。

其中Manufacturer: Microsoft通常表示当前使用微软提供的驱动，并不代表设备由微软制造。

5.3 使用客户端自动检测串口

在 ProxSpace 中：

./pm3 --list

可以列出检测到的 Proxmark3 端口。

如果重新刷写 BootROM 或改变 USB 连接方式，Windows 可能重新分配 COM 端口。因此不要始终假设设备是 COM9。

6. 首次连接 Iceman 客户端

在源码根目录执行：

./client/proxmark3.exe COM9

也可以通过：

./pm3

自动检测串口。

本次首次连接出现：

[+] Using UART port COM9 unknown command:: 0x61334d50 [!!] ERROR: cannot communicate with the Proxmark3

当时原因主要指向原设备固件较旧，与新客户端通信协议不兼容。

注意，这类错误不一定意味着设备损坏。

应先检查：

1. USB 驱动和 COM 端口；

2. 客户端是否正常运行；

3. 客户端和固件版本是否一致；

4. 是否使用正确的平台构建；

5. BootROM 是否需要单独升级。

7. RDV4.01 BootROM 升级

7.1 什么是 BootROM？

BootROM 是设备启动和固件恢复的重要引导程序。

正常情况下，Proxmark3 通电后由 BootROM 启动主固件。

当主固件损坏或者无法正常运行时，可以尝试通过 BootROM 模式重新刷写主固件。

BootROM 本身也可以升级，但风险高于普通主固件升级。

如果 BootROM 损坏，可能需要 JTAG 编程器才能恢复。

7.2 判断是否为旧版 BootROM

本次升级前观察到：

• 按住 RDV4.01 按钮插入 USB：A/C 灯亮；

• 松开按钮：A/C 熄灭，D 灯亮；

• Windows 仍识别 COM9。

这种表现符合较旧 BootROM 的典型特征。

RRG 官方说明：部分旧版 BootROM 无法直接处理较大的新版主固件镜像，需要先升级 BootROM，再升级 Fullimage。

7.3 升级前检查与备份

首先确认：

ls -lh bootrom/obj/bootrom.elf ls -lh armsrc/obj/fullimage.elf

本次实测：

bootrom.elf 16K fullimage.elf 470K

然后保存镜像、源码版本和校验值：

mkdir -p /d/rdv4-backup cp bootrom/obj/bootrom.elf /d/rdv4-backup/ cp armsrc/obj/fullimage.elf /d/rdv4-backup/ git rev-parse HEAD > /d/rdv4-backup/commit.txt sha256sum bootrom/obj/bootrom.elf \ armsrc/obj/fullimage.elf \ > /d/rdv4-backup/checksums.txt

必须说明：这些是新固件镜像的备份，并非设备原厂固件备份。

如果需要恢复原厂系统，必须另外取得匹配的原厂镜像。即使取得完整镜像，BootROM 损坏时仍可能需要 JTAG。

7.4 进入 BootROM 模式

操作：

1. 拔下 USB；

2. 按住 Proxmark3 按钮；

3. 保持按住，插入 USB；

4. 确认 A/C 指示灯亮；

5. 检查 Windows 是否识别 COM 端口。

如果是旧版 BootROM，可能需要在整个刷写过程中持续按住按钮。

7.5 刷写 BootROM

以下命令会实际修改引导程序，仅适用于已经确认兼容、具备恢复方案的 RDV4 设备：

cd /d/ProxSpace-3.12/proxmark3 ./client/proxmark3.exe -p COM9 \ --flash --unlock-bootloader \ --image bootrom/obj/bootrom.elf

本次日志出现：

Your bootloader is outdated, but this operation will update it Bootloader does not support CMD_CHIP_TYPE, assuming AT91 platform Flashing... Writing segments for file: bootrom/obj/bootrom.elf All done

说明刷写工具识别到旧版 BootROM，并报告新镜像写入完成。

注意：All done是刷写程序完成的标志，仍需要重新启动设备验证。

7.6 验证新版 BootROM

拔掉 USB，重新按住按钮插入。

本次升级后：

• A/C 灯亮；

• 松开按钮后 A/C 仍然保持亮起；

• Windows 仍然识别 COM9。

符合新版 BootROM 保持引导模式的典型行为。

8. Fullimage 主固件升级

8.1 第一种方式：指定 COM 端口

进入 BootROM 模式后：

./client/proxmark3.exe -p COM9 \ --flash \ --image armsrc/obj/fullimage.elf

本次第一次尝试出现：

ERROR: invalid serial port COM9 Could not find Proxmark3 on COM9 Aborted on error

原因是在刷写工具尝试连接时，Windows 端口尚未处于可用状态。

8.2 第二种方式：自动检测端口

重新进入 BootROM，确认 A/C 灯持续亮起后：

./pm3 --list

确认设备端口。

然后执行：

./pm3-flash-fullimage

该脚本会执行主固件刷写。

本次实测出现：

[+] All done [=] Have a nice day!

表明主固件刷写程序成功完成。

8.3 刷写注意事项

• 不要在刷写期间拔掉 USB；

• 避免使用供电不稳定的 USB Hub；

• 确认 BootROM 与 Fullimage 针对同一个平台；

• 不应随意添加--force；

• 不要反复刷写已经成功的 BootROM；

• BootROM 已经升级成功时，通常只需要更新 Fullimage。

9. 验证升级结果

刷写完成后，拔掉 USB，正常插入设备，不要按 BootROM 按钮。

在 ProxSpace 中：

./pm3

本次成功显示：

Communicating with PM3 over USB-CDC MCU....... AT91SAM7S512 Rev A Memory.... 512 KB Target.... RDV4 Client.... Iceman/master/v4.23346-108 Bootrom... Iceman/master/v4.23346-108 OS........ Iceman/master/v4.23346-108

说明客户端、BootROM 和主固件已经可以正常通信。

9.1 查看版本

hw version

能够查看：

• Client 版本；

• BootROM 版本；

• ARM 固件版本；

• FPGA 镜像；

• 硬件型号；

• MCU 和 Flash 信息；

• 是否存在智能卡模块。

9.2 查看硬件状态

hw status

本次实测：

BigBuf_size............. 32748 Emulator memory......... 8192 Tracing................. yes Flash Init.............. ok

还显示外部 Flash、智能卡模块及其他状态。

其中智能卡模块报告：

version........ v3.10 (Outdated)

表示接触式智能卡扩展模块固件较旧，不代表 Proxmark3 主固件升级失败。

9.3 测试天线

运行：

hw tune

本次设备结果：

LF: 125.00 kHz .......... 56.98 V 134.83 kHz .......... 37.44 V LF antenna .......... ok HF: 13.56 MHz ........... 47.43 V HF antenna .......... ok

这些结果表示设备报告天线基本工作正常。

注意：

• hw tune不会自动调整匹配电路；

• 测量应尽量避免卡片靠近天线；

• 显示电压不代表读卡距离；

• 不能用它代替 VNA 或示波器测量天线阻抗、谐振和信号质量。

10. Iceman 客户端基础操作

10.1 启动客户端

cd /d/ProxSpace-3.12/proxmark3 ./pm3

或者指定串口：

./client/proxmark3.exe -p COM9

成功连接后：

[usb] pm3 -->

10.2 查看帮助

help hw help hf help lf help trace help script help

子命令还可以通过-h查询参数。

例如：

hf 14b sniff -h

10.3 退出客户端

quit

或：

exit

具体以当前客户端命令帮助为准。

11. 高频 RFID 功能（13.56 MHz）

Proxmark3 RDV4 支持多种高频协议。

11.1 常见协议

具体卡片是否可读取、模拟或写入，取决于型号、访问权限和安全机制。

11.2 自动检测高频卡片

hf search

用于识别常见高频标签。

11.3 ISO14443A

hf 14a help hf 14a info

查看 ISO14443A 标签信息。

11.4 ISO14443B

hf 14b help hf 14b info

查看 Type B 标签相关信息，包括发现与协议参数。

11.5 ISO15693

hf 15 help hf 15 info

适用于 ISO15693 标签识别和协议分析。

11.6 MIFARE

hf mf help hf mfu help

其中hf mf主要面向 MIFARE Classic，hf mfu面向 Ultralight/NTAG 等相关类型。

实际操作前应确认目标标签类型和授权范围。

12. 低频 RFID 功能（125 / 134.2 kHz）

RDV4 可以用于低频标签检测、采样和协议分析。

支持的技术包括部分 EM4x、HID Prox、T55xx、Hitag 等。

常用命令：

lf help lf search lf read

自动检测低频标签

lf search

采集低频信号

lf read

查看图形工具

data help

图形和解调命令可以帮助分析低频信号编码和数据结构。

在开始低频实验前，应使用合适的 LF 天线，并确认需要测试的工作频率。

13. ISO14443B 射频抓包实战

这是本次设备升级后已经实际验证过的功能。

13.1 工作原理

Proxmark3 可以被动监听 Type B 卡片与读卡器之间的射频交互。

简化流程：

读卡器 卡片 | | |------ REQB ------------>| |<----- ATQB -------------| | | |------ ATTRIB ---------->| |<----- ATTRIB响应 -------| | | |------ APDU ------------>| |<----- APDU响应 ---------|

REQB 用于 Type B 卡片发现。

ATQB 返回卡片标识和协议能力信息。

ATTRIB 用于卡片激活和协议参数设置。

后续 APDU 用于应用选择、认证或数据交换，具体由卡片应用和安全机制决定。

13.2 开始抓包

首先：

hf 14b sniff -h

查看参数。

然后：

hf 14b sniff

将 Proxmark3 高频监听天线置于授权测试卡片和读卡器附近的有效耦合区域。

使用读卡器完成一次正常操作。

按照客户端提示结束监听。本次版本提供设备按钮停止监听的方式。

13.3 查看捕获报文

hf 14b list

输出示例：

Start | End | Src | Data | CRC | Annotation Rdr | 05 00 00 71 FF | ok | REQB Tag | 50 00 ... | ok | Rdr | 1D 00 ... | ok | ATTRIB Tag | 08 30 7C | ok |

字段解释：

对于 ISO14443B，时间单位通常是 13.56 MHz 载波周期。

13.4 识别 APDU

例如：

00 A4 00 00 02 60 02

是 ISO7816 风格的应用/文件选择命令。

再如：

80 B0 00 00 20

属于读取数据相关的 APDU 形式。

卡片返回：

90 00

通常表示该条 APDU 成功完成。

但注意：一条 APDU 成功不代表整个身份证读取流程成功。

13.5 CRC 错误说明

如果出现：

CRC !!

表示 Proxmark3 对捕获帧的 CRC 检查失败。

可能原因：

• 监听天线位置不佳；

• 信号过弱；

• 场强或耦合不稳定；

• 数据帧被截断；

• 被动监听设备出现漏帧；

• 实际射频通信存在错误。

被动监听检测到 CRC 错误，不代表真实读卡器也一定接收到了错误数据。

在实际分析中，应该把 Proxmark3 的抓包与读卡器固件返回码结合起来判断。

14. 保存和分析抓包数据

14.1 保存 TXT 日志

Iceman 会自动记录会话日志。

本次 Windows 环境中的日志目录：

D:\Cadence\SPB_Data\.proxmark3\logs\

文件示例：

log_20261010092143.txt

可以使用 VS Code 或记事本查看。

运行：

hf 14b list

后，相关文本输出通常会记录在会话日志里。

注意：日志可能包含多个命令或多次抓包内容，要确认实际分析的是哪一次采集。

14.2 保存原始 Trace

在 Iceman 中运行：

trace save -h

查看保存参数。

常见用法：

trace save -f test_14b

原始 Trace 可以在之后重新加载分析。

14.3 加载 Trace

trace load -h

根据当前客户端版本提供的参数指定保存的文件。

随后使用：

hf 14b list

重新解析捕获记录。

14.4 推荐的实验文件结构

RFID_Research/ ├── card_A/ │ ├── test1.txt │ ├── test2.txt │ ├── test3.txt │ └── trace/ ├── card_B/ │ ├── test1.txt │ ├── test2.txt │ ├── test3.txt │ └── trace/ ├── reader_A/ ├── reader_B/ └── comparison/

建议同时记录：

• 读卡器型号；

• 测试卡片编号（使用匿名编号）；

• 天线位置和距离；

• 读卡结果；

• 错误码；

• 固件版本；

• 抓包时间。

涉及身份证等敏感证件时，应限制日志访问权限，并对个人信息进行脱敏处理。

15. 射频诊断和协议分析功能

15.1 检测外部读卡器

hw detectreader

用于检测附近是否存在外部读卡器射频场。

15.2 高频信号采样与绘图

hf help data help

当前固件还提供部分 HF 绘图和波形处理功能。

15.3 低频波形分析

lf read data plot

可以对支持的低频信号进行采样和可视化。

15.4 分析时序

hf 14b list的时间戳可以用于分析：

• REQB 重试间隔；

• 卡片响应延迟；

• ATTRIB 建立过程；

• APDU 命令发送间隔；

• 读卡器重新寻卡；

• 通信中断或重启。

对于 CLRC663 驱动开发，可以将 Proxmark3 抓包与 MCU 中的寄存器状态、IRQ 和错误码对应起来。

不过，Proxmark3 的被动抓包结果不是绝对无误的射频记录，不能替代射频示波器、VNA 或读卡器内部日志。

16. 卡片模拟功能

RDV4 支持多个协议下的卡片模拟功能。

例如：

hf 14a sim -h hf 14b sim -h hf 15 sim -h

这些功能可用于：

• 自有测试标签；

• 协议兼容性测试；

• 实验室读卡器调试；

• 测试协议状态机；

• 模拟符合相应功能范围的测试响应。

模拟功能不等于能够完整复制受密码学保护的卡片。

对于居民身份证等受保护证件，无法仅凭一般 UID、ATQB 或公开协议帧重现完整身份认证与安全数据读取流程。

17. 接触式智能卡与扩展功能

当前 RDV4 检测到 ISO7816 智能卡模块。

查看功能：

smart help smart info

可用于支持的接触式智能卡识别与协议分析。

但本次设备报告模块固件：

v3.10 (Outdated)

因此，具体高级功能需检查模块固件兼容性。

其他功能包括：

Lua 脚本

script help script list

用于组织重复性测试。

Python 支持

本次 Windows 客户端已经编译 Python 脚本支持，可用于自动化分析和数据处理。

外部 Flash

设备具备外部 SPI Flash，可支持部分字典、数据文件及独立运行模式所需的存储功能。

Standalone 模式

设备可以在特定固件配置下执行无需持续连接电脑的独立程序。

本次固件配置中已安装的是 LF HID26 SamyRun 模式，不代表所有抓包功能都可以脱机运行。

18. 常见故障与解决方法

恢复主固件

如果主固件损坏，但 BootROM 仍然正常：

1. 按住按钮插入 USB；

2. 确认引导模式 LED；

3. 使用./pm3 --list检查端口；

4. 使用官方pm3-flash-fullimage流程恢复。

如果 BootROM 已损坏且不能进入引导模式，则可能需要通过 JTAG 恢复。

19. 推荐的日常使用流程

不需要每次启动都重新编译或刷写。

日常操作：

第一步：连接 USB。

第二步：启动 ProxSpace。

双击：

runme64.bat

第三步：进入源码目录。

cd /d/ProxSpace-3.12/proxmark3

第四步：启动客户端。

./pm3

第五步：执行功能命令。

例如：

hw version hw status hf search hf 14b help

第六步：根据测试目标采集数据。

例如，在授权的 ISO14443B 测试环境中：

hf 14b sniff hf 14b list

第七步：保存日志和 Trace。

使用客户端日志及trace save。

20. 总结

本次 Proxmark3 RDV4.01 从旧版原厂固件升级到 RRG/Iceman 的完整过程，可以归纳为：

1. 配置 Windows 11 ProxSpace；

2. 下载 RRG/Iceman 源码；

3. 修复缺少 GCC 的编译环境问题；

4. 通过PLATFORM=PM3RDV4编译；

5. 确认 USB CDC 驱动和 COM 端口；

6. 发现旧固件与新版客户端不兼容；

7. 手动进入旧版 BootROM；

8. 单独升级 BootROM；

9. 重新进入新版 BootROM；

10. 刷写 Fullimage；

11. 验证客户端、BootROM、ARM 固件和 FPGA；

12. 检查 HF/LF 天线；

13. 验证 ISO14443B 抓包；

14. 保存和分析通信记录。

最终设备能够正常连接新版 Iceman 客户端，完成硬件状态检测和 ISO14443B 双向通信监听。

对于 RFID 开发，特别是 CLRC663 相关系统，Proxmark3 的价值在于提供独立的协议观测能力，帮助分析读卡器和标签之间的真实交互。

它既是一套 RFID 协议实验平台，也是一款非常实用的嵌入式射频调试辅助工具。