Proxmark3Iceman ForkFedora 41 Docker 测试环境实战构建矩阵、release_tests.sh 与 pm3_tests.sh 详解【免费下载链接】proxmark3Iceman Fork - Proxmark3项目地址: https://gitcode.com/GitHub_Trending/pr/proxmark3本文以 docker/fedora-41/README.md 为核心围绕 Proxmark3 Iceman Fork 仓库内置的 Fedora 41 Docker 测试环境展开讲清该目录四个文件Dockerfile、docker_conf.inc、run_tests.sh、README.md各自的职责逐行剖析 run_tests.sh 背后的“RDV4 / GENERIC / BTADDON 三组合 × make / cmake 双构建系统”测试矩阵并结合 tools/release_tests.sh 与 tools/pm3_tests.sh 的源码说明每个构建参数、每项自检的判定依据以及如何在容器内手动跑单次构建加测试。读完后你可以独立完成镜像构建、进入测试容器、执行全量发布测试并解读 PASS/FAIL 结果、按测试目标单独验证某一功能域。1. 测试环境在仓库中的位置与整体分工仓库在 docker/ 目录下为 17 个发行版各准备了一套同构的测试环境子目录fedora-41、ubuntu-24.04、debian-13-trixie、archlinux 等每个子目录包含四个文件文件作用docker/fedora-41/Dockerfile定义基于fedora:41的基础镜像与全部编译依赖docker/fedora-41/docker_conf.inc声明镜像标签DOCKER_IMAGEpm3-fedora-41:1.0供 run.sh / rm.sh 点源加载docker/fedora-41/run_tests.sh容器内的测试入口更新系统包 → 跑发布测试矩阵 → 蜂鸣提示完成docker/fedora-41/README.md说明脚本用途、运行位置与单测命令进入容器和清理容器则复用 docker/ 目录下的通用脚本docker/run.sh点源当前子目录的docker_conf.inc取得镜像名自动探测主机串口设备并挂载仓库源码交互式进入容器docker/rm.sh删除对应容器、删除镜像并清理构建缓存。README 中给出的运行方式在仓库根目录执行docker/fedora-41/run_tests.sh对应的实际操作是先用 docker/run.sh 进入容器工作目录被设为/home/rrg/proxmark3即仓库源码挂载点再在容器内执行该脚本。2. Dockerfile编译依赖与测试用户是怎么准备的Fedora 41 的 Dockerfile 只有一条基础镜像声明FROM fedora:41随后按功能分批安装依赖逐层可以对应到仓库构建系统的不同需求RUN dnf install -y passwd sudo git make cmake gcc gcc-c \ arm-none-eabi-gcc-cs arm-none-eabi-newlib readline-devel \ bzip2-devel lz4-devel zlib-ng-compat-devel bluez-libs-devel \ python3-devel openssl-devel gd-devel libatomic findutils各依赖的用途可以结合仓库结构印证arm-none-eabi-gcc-csarm-none-eabi-newlib交叉编译 armsrc/ARM 固件、bootrom/ 与 recovery/ 固件所必需的 ARM 交叉工具链make与cmake对应 tools/release_tests.sh 中“make 与 cmake 两种构建系统分别验证”的设计README 中“runs a bunch of different builds with make and cmake together”指的就是这一点readline-devel命令行客户端 client/ 的交互式输入支持lz4-devel、bzip2-devel、zlib-ng-compat-devel压缩与资源相关依赖如 hardnested 表文件以.bin.lz4形式存放于client/resources/hardnested_tables/测试脚本会检查其存在bluez-libs-develBTADDON蓝牙扩展板组合构建所需的 BlueZ 库对应PLATFORM_EXTRASBTADDONgd-devel、python3-devel、openssl-devel图像处理、Python 脚本支持与密码学相关依赖。其余几个 RUN 层各有专门目的ARG SKIPQTfalse RUN if [ ${SKIPQT} false ]; then \ dnf install -y qt6-qtbase-devel; \ fiQt6 开发库用于构建带图形界面的客户端SKIPQT构建参数允许跳过以减小镜像体积。docker_conf.inc 中正好留了一行注释掉的#SKIPQT1表明该配置与 Dockerfile 参数联动。RUN yum -y install mesa-libOpenCL ocl-icd-develOpenCL 运行时是 Hitag2 破解工具 OpenCL 版本的测试前提tools/pm3_tests.sh 中对ht2crack5opencl的测试被标记为opencl类型只有传入--opencl参数才会真正执行否则显示SKIPPED ( opencl )。COPY --fromghcr.io/astral-sh/uv:latest /uv /uvx /bin/uv是 Python 包运行器。pm3_tests.sh 开头的逻辑是若系统存在uv则所有 Python 测试脚本xorcheck、findbits、recover_pk 等都通过uv run --script执行否则回退到系统python3设置SKIPUV1可强制忽略 uv。最后三组指令解决权限问题RUN useradd -ms /bin/bash rrg RUN passwd -d rrg ARG UART_GID RUN if [ -n ${UART_GID} ]; then \ groupadd -g ${UART_GID} mydialout || true; \ usermod -aG ${UART_GID} rrg; \ fi RUN printf rrg ALL(ALL) ALL\n | tee -a /etc/sudoers创建无密码的普通用户rrg并切换为容器运行用户避免以 root 运行构建UART_GID是一个构建期参数不同 Linux 发行版上dialout组串口设备属组的数字 ID 不一致注入该参数可让容器内的rrg用户获得与主机一致的串口访问组使容器内能直接读写 Proxmark 设备的串口rrg被授予完整 sudo 权限——这是 release_tests.sh 第 14 行中make install/make uninstall系统级安装测试能够执行的前提。3. 用 run.sh / rm.sh 进入与清理容器docker/run.sh 的完整流程约 14 行. docker_conf.inc UART_PORT$(../../pm3 --list|grep dev|head -n1|cut -d -f2) if [ -n $UART_PORT ]; then DEV--device/dev/tty0 --device$UART_PORT else DEV fi docker run $DEV $DOCKER_PLATFORM --volume$(pwd)/../..:/home/rrg/proxmark3 \ -w /home/rrg/proxmark3 --nethost --rm -it $DOCKER_IMAGE要点脚本必须在某个发行版子目录内运行找不到docker_conf.inc会直接报错退出先调用仓库自带的pm3 --list探测主机上 Proxmark 设备所在的串口节点如/dev/ttyACM0若存在则通过--device映射进容器仓库根目录整体挂载为容器内/home/rrg/proxmark3并设为工作目录——因此 README 强调“脚本要在容器内 proxmark 根目录下运行”--nethost保证容器内可直达主机的串口与调试端口--rm保证退出后不留容器。docker/rm.sh 则按镜像标签过滤出同族容器执行docker rm再删除pm3-fedora-41:1.0镜像并执行docker builder prune --force清理构建层缓存。镜像本身可用标准的docker build命令构建标签与docker_conf.inc中声明的DOCKER_IMAGE保持一致例如docker build -t pm3-fedora-41:1.0 docker/fedora-41如需跳过 Qt 依赖可追加--build-arg SKIPQTtrue。4. run_tests.sh一次更新、一次全量矩阵、一声蜂鸣docker/fedora-41/run_tests.sh 本体极短#!/usr/bin/env bash # Iceman 2022 # # This script is to be run from proxmark root folder inside the docker env # docker/fedora-41/run_tests.sh; sudo yum -y update tools/release_tests.sh # beeps for ((i0; i10;i)) do echo -e \a;sleep 0.3; done它做三件事sudo yum -y update——Fedora 41 的yum实际是 dnf 前端与 README 单测流程中的sudo yum -y update是同一动作保证测试基于最新系统包委托 tools/release_tests.sh 执行真正的测试矩阵下一节展开无论测试通过与否连续 10 次、每次间隔 0.3 秒发出终端响铃\a作为“跑完了”的人工提示——这是无头 CI 环境里一种很实用的完成信号。5. release_tests.sh真正的构建矩阵tools/release_tests.sh 共 21 行是 README 所说“make 与 cmake 对 RDV4、GENERIC、BTADDON 各种组合的构建”的完整实现。5.1 前置保护拒绝 SKIP 指令干扰if [ -f Makefile.platform ]; then if grep -q ^SKIP_ Makefile.platform; then echo ERROR: SKIP instructions in your Makefile.platform will interfere with this script, aborting... exit 1; fi fi若本地存在Makefile.platform且包含SKIP_开头的行用于跳过部分构建目标以节省时间脚本直接中止退出——因为发布测试要求全量构建任何跳过都会造成验证缺口。这也是“在 Docker 容器内跑测试”优于“在开发机上直接跑”的原因之一容器里挂载的源码树是干净的不会有本地Makefile.platform残留。5.2 make 构建三种硬件/功能组合make clean make -j PLATFORMPM3GENERIC PLATFORM_EXTRAS STANDALONELF_SAMYRUN tools/pm3_tests.sh --long || exit 1 make clean make -j PLATFORMPM3RDV4 PLATFORM_EXTRAS STANDALONEHF_ST25_TEAROFF || exit 1 make clean make -j PLATFORMPM3RDV4 PLATFORM_EXTRASBTADDON STANDALONEHF_REBLAY || exit 1 make -j PLATFORMPM3RDV4 PLATFORM_EXTRASBTADDON STANDALONEHF_REBLAY \ if sudo true; then \ INSTALLSUDOsudo make install PLATFORMPM3RDV4 PLATFORM_EXTRASBTADDON STANDALONEHF_REBLAY \ ( cd /tmp; proxmark3 -c data load -f lf_EM4x05.pm3;lf search -1 | grep Valid FDX-B ID found ) \ INSTALLSUDOsudo make uninstall || exit 1; fi四个参数是构建矩阵的维度参数取值含义PLATFORMPM3GENERIC/PM3RDV4目标硬件平台。PM3RDV4是根 Makefile help 中声明的默认平台“default is PM3RDV4”PM3GENERIC面向 RDV1/2/3 easy、iCopy-X 等通用平台构建产物需适配不同的 FPGA 与 GPIO 布局PLATFORM_EXTRAS空 /BTADDON是否编译蓝牙扩展板支持。选BTADDON时依赖 Dockerfile 中的bluez-libs-develSTANDALONELF_SAMYRUN/HF_ST25_TEAROFF/HF_REBLAY嵌入固件的 standalone 模式。三个目标分别对应 armsrc/Standalone/lf_samyrun.c、hf_st25_tearoff.c、hf_reblay.c每种模式都会改变 ARM 固件的体积与入口行为因此需要逐一验证链接与烧录布局make -j—全核并行编译值得注意的三点每个组合之间都执行make clean确保上一组合的PLATFORM缓存不会污染下一组合仓库根 Makefile 中有.Makefile.options.cache机制记录CACHED_PLATFORM_EXTRAS等缓存选项clean 正是为了重置这类缓存只有第一个组合PM3GENERIC编译完成后会紧接着运行tools/pm3_tests.sh --long即带--long启用慢速测试的完整自检失败立即exit 1第四行是“安装—真机回归—卸载”闭环先以 sudo 执行make install然后在/tmp下用刚安装的proxmark3加载仓库自带的 traces/lf_EM4x05.pm3 离线信号文件并执行lf search -1断言输出包含Valid FDX-B ID foundif sudo true守卫表示该步骤依赖 sudo 权限Docker 里已满足失败同样触发make uninstall前的exit 1。这条命令同时验证了make install的产物路径正确性与data load/lf search两条核心命令链。5.3 cmake 构建客户端三组合( cd client; rm -rf build; mkdir build;cd build;cmake .. make -j \ PLATFORMPM3GENERIC PLATFORM_EXTRAS STANDALONELF_SAMYRUN \ cp -a ../*scripts ../*libs . \ ../../tools/pm3_tests.sh --clientbin $(pwd)/proxmark3 client ) || exit 1 ( cd client; rm -rf build; mkdir build;cd build;cmake .. make -j \ PLATFORMPM3RDV4 PLATFORM_EXTRAS STANDALONEHF_ST25_TEAROFF ) || exit 1 ( cd client; rm -rf build; mkdir build;cd build;cmake .. make -j \ PLATFORMPM3RDV4 PLATFORM_EXTRASBTADDON STANDALONEHF_REBLAY ) || exit 1三组 cmake 构建与上面的 make 矩阵一一对应但只构建 client/ 主机端程序。第一组额外做了两件事cp -a ../*scripts ../*libs .把client/cmdscripts/、client/luascripts/、client/lualibs/、client/pyscripts/等脚本目录复制到构建目录——pm3_tests.sh 中的脚本类测试script run example.cmd、script run data_hex_crc、script run parity.py需要这些资源就位通过--clientbin $(pwd)/proxmark3 client告诉测试工具“只测 client 目标且被测二进制就是这个 cmake 产物”从而验证 cmake 路径构建出的客户端行为与 make 路径一致。5.4 hitag2crack 与 PASS 判定# Hitag2crack, optionally with --long and --opencl... make hitag2crack/clean make hitag2crack tools/pm3_tests.sh hitag2crack || exit 1 echo PASSHitag2 破解工具套件tools/hitag2crack/刻意没有并入根 Makefile 的all目标源文件注释明确写着“not yet integrated in all, it must be called explicitly: make hitag2crack”因此作为独立一项构建并测试。全部步骤按顺序、失败即停地执行完毕后脚本输出PASS——这正是 README 所说的判定标准“If all tests OK, the script will finish with PASS.”。任何一步非零退出都会因|| exit 1中断整个矩阵不会打印 PASS。6. pm3_tests.sh自检引擎的参数与判定机制tools/pm3_tests.sh约 670 行是整个测试体系的核心引擎run_tests.sh 矩阵与 README 的单测流程最终都汇到这里。6.1 命令行接口Usage: pm3_tests.sh [--long] [--opencl] [--clientbin /path/to/proxmark3] [mfkey|nonce2key|mf_nonce_brute|staticnested|mfd_aes_brute|mfulc_des_brute|cryptorf|fpga_compress|bootrom|armsrc|client|recovery|common] --long: Enable slow tests --opencl: Enable tests requiring OpenCL (preferably a Nvidia GPU) --clientbin ...: Specify path to proxmark3 binary to test If no target given, all targets will be tested不传目标时TESTALLtrue覆盖全部测试域传目标如hitag2crack、client、common则只跑对应域--long开启SLOWTESTS放行标记为slow运行超过约 5 秒的测试README 单测命令tools/pm3_tests.sh --long即全量慢速模式--opencl开启OPENCLTESTS放行opencl类测试需要 OpenCL 设备帮助文本建议 Nvidia GPU--clientbin指定被测客户端二进制见 5.3 节 cmake 流程未指定时默认./client/proxmark3即 make 路径的产物。脚本开头还强制LANGC.UTF-8保证所有被测程序的帮助文本与错误输出是英文——因为断言全部基于英文输出做正则匹配与容器 Dockerfile 中的ENV LANGC.UTF-8形成双保险。6.2 两个判定原语CheckFileExist检查产物文件可带opencl标记无 OpenCL 时显示 SKIPPED 但不判失败CheckExecute执行命令并用正则匹配输出支持四个修饰位修饰位行为slow未开--long时跳过opencl未开--opencl时跳过retry失败最多重试 3 次ignore失败不致命如 Python 支持检测缺失时后续 py 脚本测试自动跳过执行超过 2 秒会打印耗时失败会打印完整Execution trace便于定位。所有检查失败即break出主循环打印红色Tests [ FAIL ]并以退出码 1 结束全部通过打印Tests [ OK ]。6.3 典型测试域举例common检查client/resources/与client/dictionaries/下的资源文件hardnested 状态表 lz4、sim020.bin、iclass/mfc/mfdes 默认密钥字典、t55xx 密码字典等是否存在并运行tools/xorcheck.py、tools/findbits.py、tools/recover_pk.py selftests、tools/mkversion.sh --short等 Python/Shell 工具bootrom / armsrc / recovery / fpgacompress分别断言bootrom/obj/bootrom.elf、armsrc/obj/fullimage.elf、recovery/recovery.bin、tools/fpga_compress/fpga_compress四个构建产物存在——这解释了 release_tests.sh 里每一轮make必须成功的原因产物缺失即 FAILmfkey / staticnested / nonce2key / mf_nonce_brute / mfd_aes_brute / mfulc_des_brute / cryptorf针对 tools/mfc/、tools/cryptorf/ 等密码学工具做“给定已知明文/nonce 输入断言能解出预定密钥”的黄金向量测试例如mfkey32v2输入固定八组参数后断言输出Found Key: [a0a1a2a3a4a5]hitag2crack验证 crack2 表构建/搜索工具、crack3/4/5 的生成—破解闭环crack5 的破解耗时约十几秒标记为slow以及 crack5opencl 的 OpenCL 版本标记slow opencl需要--opencl才跑client对客户端二进制做纯离线回归——帮助文本、多命令执行-c分号串联与 stdin 管道、cmdscript/luascript/pyscript 执行、data qrcode参数校验、data modulation自相关、trace load/listISO14443-A 与 ISO7816 两种解析、nfc decode各类 NDEF 负载vCard、WiFi WSC、Apple Wallet、PILet 签名等、wiegand encode/decode多种格式回环、二十余种 LF 制式 demodHID、AWID、Indala、NexWatch、Securakey 等与 T5577 模拟信号的lf search识别以及hf mf、hf mfdes、hf gst、emv test等 HF 域自检。断言全部针对仓库自带的 traces/ 离线文件无需真实射频信号只有 5.2 节那条make install后的真机测试需要设备在位。7. 手动执行单次构建加测试README 单测流程README 给出的精简流程是在容器内的仓库根目录执行sudo yum -y update make clean; make -j tools/pm3_tests.sh --long逐条说明sudo yum -y update刷新系统包保证工具链与库为最新稳定版make clean; make -j以默认平台PM3RDV4根 Makefile help 文本中声明做一轮全量并行构建产出 bootrom、armsrc 固件、recovery 镜像、客户端与 tools 二进制tools/pm3_tests.sh --long不带目标参数即测试全部域且放行所有慢速测试。注意该命令本身不校验--long之外的硬件状态除真机相关断言外可完全离线完成。相比 run_tests.sh 的完整矩阵这套单测流程等价于矩阵中“PM3RDV4 make 全量 pm3_tests”的组合适合在修改某一模块后快速自证若要复现 CI 级覆盖仍应回到tools/release_tests.sh全矩阵。8. 相关文件索引路径说明docker/fedora-41/README.md本文核心文档脚本用途、运行位置、单测命令docker/fedora-41/Dockerfile依赖清单、SKIPQT/UART_GID 构建参数、rrg 测试用户docker/fedora-41/docker_conf.inc镜像标签pm3-fedora-41:1.0docker/fedora-41/run_tests.sh容器内测试入口docker/run.sh / docker/rm.sh通用容器进入/清理脚本tools/release_tests.shmakecmake 双系统、三平台组合测试矩阵tools/pm3_tests.sh自检引擎参数解析、CheckExecute/CheckFileExist、各测试域Makefile根构建入口默认平台 PM3RDV4hitag2crack独立目标armsrc/Standalone/readme.mdSTANDALONE 参数对应模式的开发说明9. 小结Proxmark3 Iceman Fork 的 Fedora 41 Docker 目录看起来只有四个小文件实际串起了一条完整的“干净环境验证链”Dockerfile 精确复刻了交叉工具链、BlueZ、OpenCL、Qt、uv 等全部构建依赖并准备无密码的 sudo 测试用户run.sh 负责串口直通与源码挂载run_tests.sh 委托 release_tests.sh 跑完“3 种硬件/功能组合 × make/cmake 两套构建系统 安装真机回归 hitag2crack”的全矩阵最后以 PASS 收束而所有断言最终落在 pm3_tests.sh 的 CheckExecute/CheckFileExist 黄金向量体系上全部离线可复现。理解这条链之后无论是复现 CI 失败、新增 standalone 模式、还是验证一次密码学工具的改动都可以按同一套路径在容器内完成。【免费下载链接】proxmark3Iceman Fork - Proxmark3项目地址: https://gitcode.com/GitHub_Trending/pr/proxmark3创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Proxmark3（Iceman Fork）Fedora 41 Docker 测试环境实战：构建矩阵、release_tests.sh 与 pm3_tests.sh 详解
Proxmark3Iceman ForkFedora 41 Docker 测试环境实战构建矩阵、release_tests.sh 与 pm3_tests.sh 详解【免费下载链接】proxmark3Iceman Fork - Proxmark3项目地址: https://gitcode.com/GitHub_Trending/pr/proxmark3本文以 docker/fedora-41/README.md 为核心围绕 Proxmark3 Iceman Fork 仓库内置的 Fedora 41 Docker 测试环境展开讲清该目录四个文件Dockerfile、docker_conf.inc、run_tests.sh、README.md各自的职责逐行剖析 run_tests.sh 背后的“RDV4 / GENERIC / BTADDON 三组合 × make / cmake 双构建系统”测试矩阵并结合 tools/release_tests.sh 与 tools/pm3_tests.sh 的源码说明每个构建参数、每项自检的判定依据以及如何在容器内手动跑单次构建加测试。读完后你可以独立完成镜像构建、进入测试容器、执行全量发布测试并解读 PASS/FAIL 结果、按测试目标单独验证某一功能域。1. 测试环境在仓库中的位置与整体分工仓库在 docker/ 目录下为 17 个发行版各准备了一套同构的测试环境子目录fedora-41、ubuntu-24.04、debian-13-trixie、archlinux 等每个子目录包含四个文件文件作用docker/fedora-41/Dockerfile定义基于fedora:41的基础镜像与全部编译依赖docker/fedora-41/docker_conf.inc声明镜像标签DOCKER_IMAGEpm3-fedora-41:1.0供 run.sh / rm.sh 点源加载docker/fedora-41/run_tests.sh容器内的测试入口更新系统包 → 跑发布测试矩阵 → 蜂鸣提示完成docker/fedora-41/README.md说明脚本用途、运行位置与单测命令进入容器和清理容器则复用 docker/ 目录下的通用脚本docker/run.sh点源当前子目录的docker_conf.inc取得镜像名自动探测主机串口设备并挂载仓库源码交互式进入容器docker/rm.sh删除对应容器、删除镜像并清理构建缓存。README 中给出的运行方式在仓库根目录执行docker/fedora-41/run_tests.sh对应的实际操作是先用 docker/run.sh 进入容器工作目录被设为/home/rrg/proxmark3即仓库源码挂载点再在容器内执行该脚本。2. Dockerfile编译依赖与测试用户是怎么准备的Fedora 41 的 Dockerfile 只有一条基础镜像声明FROM fedora:41随后按功能分批安装依赖逐层可以对应到仓库构建系统的不同需求RUN dnf install -y passwd sudo git make cmake gcc gcc-c \ arm-none-eabi-gcc-cs arm-none-eabi-newlib readline-devel \ bzip2-devel lz4-devel zlib-ng-compat-devel bluez-libs-devel \ python3-devel openssl-devel gd-devel libatomic findutils各依赖的用途可以结合仓库结构印证arm-none-eabi-gcc-csarm-none-eabi-newlib交叉编译 armsrc/ARM 固件、bootrom/ 与 recovery/ 固件所必需的 ARM 交叉工具链make与cmake对应 tools/release_tests.sh 中“make 与 cmake 两种构建系统分别验证”的设计README 中“runs a bunch of different builds with make and cmake together”指的就是这一点readline-devel命令行客户端 client/ 的交互式输入支持lz4-devel、bzip2-devel、zlib-ng-compat-devel压缩与资源相关依赖如 hardnested 表文件以.bin.lz4形式存放于client/resources/hardnested_tables/测试脚本会检查其存在bluez-libs-develBTADDON蓝牙扩展板组合构建所需的 BlueZ 库对应PLATFORM_EXTRASBTADDONgd-devel、python3-devel、openssl-devel图像处理、Python 脚本支持与密码学相关依赖。其余几个 RUN 层各有专门目的ARG SKIPQTfalse RUN if [ ${SKIPQT} false ]; then \ dnf install -y qt6-qtbase-devel; \ fiQt6 开发库用于构建带图形界面的客户端SKIPQT构建参数允许跳过以减小镜像体积。docker_conf.inc 中正好留了一行注释掉的#SKIPQT1表明该配置与 Dockerfile 参数联动。RUN yum -y install mesa-libOpenCL ocl-icd-develOpenCL 运行时是 Hitag2 破解工具 OpenCL 版本的测试前提tools/pm3_tests.sh 中对ht2crack5opencl的测试被标记为opencl类型只有传入--opencl参数才会真正执行否则显示SKIPPED ( opencl )。COPY --fromghcr.io/astral-sh/uv:latest /uv /uvx /bin/uv是 Python 包运行器。pm3_tests.sh 开头的逻辑是若系统存在uv则所有 Python 测试脚本xorcheck、findbits、recover_pk 等都通过uv run --script执行否则回退到系统python3设置SKIPUV1可强制忽略 uv。最后三组指令解决权限问题RUN useradd -ms /bin/bash rrg RUN passwd -d rrg ARG UART_GID RUN if [ -n ${UART_GID} ]; then \ groupadd -g ${UART_GID} mydialout || true; \ usermod -aG ${UART_GID} rrg; \ fi RUN printf rrg ALL(ALL) ALL\n | tee -a /etc/sudoers创建无密码的普通用户rrg并切换为容器运行用户避免以 root 运行构建UART_GID是一个构建期参数不同 Linux 发行版上dialout组串口设备属组的数字 ID 不一致注入该参数可让容器内的rrg用户获得与主机一致的串口访问组使容器内能直接读写 Proxmark 设备的串口rrg被授予完整 sudo 权限——这是 release_tests.sh 第 14 行中make install/make uninstall系统级安装测试能够执行的前提。3. 用 run.sh / rm.sh 进入与清理容器docker/run.sh 的完整流程约 14 行. docker_conf.inc UART_PORT$(../../pm3 --list|grep dev|head -n1|cut -d -f2) if [ -n $UART_PORT ]; then DEV--device/dev/tty0 --device$UART_PORT else DEV fi docker run $DEV $DOCKER_PLATFORM --volume$(pwd)/../..:/home/rrg/proxmark3 \ -w /home/rrg/proxmark3 --nethost --rm -it $DOCKER_IMAGE要点脚本必须在某个发行版子目录内运行找不到docker_conf.inc会直接报错退出先调用仓库自带的pm3 --list探测主机上 Proxmark 设备所在的串口节点如/dev/ttyACM0若存在则通过--device映射进容器仓库根目录整体挂载为容器内/home/rrg/proxmark3并设为工作目录——因此 README 强调“脚本要在容器内 proxmark 根目录下运行”--nethost保证容器内可直达主机的串口与调试端口--rm保证退出后不留容器。docker/rm.sh 则按镜像标签过滤出同族容器执行docker rm再删除pm3-fedora-41:1.0镜像并执行docker builder prune --force清理构建层缓存。镜像本身可用标准的docker build命令构建标签与docker_conf.inc中声明的DOCKER_IMAGE保持一致例如docker build -t pm3-fedora-41:1.0 docker/fedora-41如需跳过 Qt 依赖可追加--build-arg SKIPQTtrue。4. run_tests.sh一次更新、一次全量矩阵、一声蜂鸣docker/fedora-41/run_tests.sh 本体极短#!/usr/bin/env bash # Iceman 2022 # # This script is to be run from proxmark root folder inside the docker env # docker/fedora-41/run_tests.sh; sudo yum -y update tools/release_tests.sh # beeps for ((i0; i10;i)) do echo -e \a;sleep 0.3; done它做三件事sudo yum -y update——Fedora 41 的yum实际是 dnf 前端与 README 单测流程中的sudo yum -y update是同一动作保证测试基于最新系统包委托 tools/release_tests.sh 执行真正的测试矩阵下一节展开无论测试通过与否连续 10 次、每次间隔 0.3 秒发出终端响铃\a作为“跑完了”的人工提示——这是无头 CI 环境里一种很实用的完成信号。5. release_tests.sh真正的构建矩阵tools/release_tests.sh 共 21 行是 README 所说“make 与 cmake 对 RDV4、GENERIC、BTADDON 各种组合的构建”的完整实现。5.1 前置保护拒绝 SKIP 指令干扰if [ -f Makefile.platform ]; then if grep -q ^SKIP_ Makefile.platform; then echo ERROR: SKIP instructions in your Makefile.platform will interfere with this script, aborting... exit 1; fi fi若本地存在Makefile.platform且包含SKIP_开头的行用于跳过部分构建目标以节省时间脚本直接中止退出——因为发布测试要求全量构建任何跳过都会造成验证缺口。这也是“在 Docker 容器内跑测试”优于“在开发机上直接跑”的原因之一容器里挂载的源码树是干净的不会有本地Makefile.platform残留。5.2 make 构建三种硬件/功能组合make clean make -j PLATFORMPM3GENERIC PLATFORM_EXTRAS STANDALONELF_SAMYRUN tools/pm3_tests.sh --long || exit 1 make clean make -j PLATFORMPM3RDV4 PLATFORM_EXTRAS STANDALONEHF_ST25_TEAROFF || exit 1 make clean make -j PLATFORMPM3RDV4 PLATFORM_EXTRASBTADDON STANDALONEHF_REBLAY || exit 1 make -j PLATFORMPM3RDV4 PLATFORM_EXTRASBTADDON STANDALONEHF_REBLAY \ if sudo true; then \ INSTALLSUDOsudo make install PLATFORMPM3RDV4 PLATFORM_EXTRASBTADDON STANDALONEHF_REBLAY \ ( cd /tmp; proxmark3 -c data load -f lf_EM4x05.pm3;lf search -1 | grep Valid FDX-B ID found ) \ INSTALLSUDOsudo make uninstall || exit 1; fi四个参数是构建矩阵的维度参数取值含义PLATFORMPM3GENERIC/PM3RDV4目标硬件平台。PM3RDV4是根 Makefile help 中声明的默认平台“default is PM3RDV4”PM3GENERIC面向 RDV1/2/3 easy、iCopy-X 等通用平台构建产物需适配不同的 FPGA 与 GPIO 布局PLATFORM_EXTRAS空 /BTADDON是否编译蓝牙扩展板支持。选BTADDON时依赖 Dockerfile 中的bluez-libs-develSTANDALONELF_SAMYRUN/HF_ST25_TEAROFF/HF_REBLAY嵌入固件的 standalone 模式。三个目标分别对应 armsrc/Standalone/lf_samyrun.c、hf_st25_tearoff.c、hf_reblay.c每种模式都会改变 ARM 固件的体积与入口行为因此需要逐一验证链接与烧录布局make -j—全核并行编译值得注意的三点每个组合之间都执行make clean确保上一组合的PLATFORM缓存不会污染下一组合仓库根 Makefile 中有.Makefile.options.cache机制记录CACHED_PLATFORM_EXTRAS等缓存选项clean 正是为了重置这类缓存只有第一个组合PM3GENERIC编译完成后会紧接着运行tools/pm3_tests.sh --long即带--long启用慢速测试的完整自检失败立即exit 1第四行是“安装—真机回归—卸载”闭环先以 sudo 执行make install然后在/tmp下用刚安装的proxmark3加载仓库自带的 traces/lf_EM4x05.pm3 离线信号文件并执行lf search -1断言输出包含Valid FDX-B ID foundif sudo true守卫表示该步骤依赖 sudo 权限Docker 里已满足失败同样触发make uninstall前的exit 1。这条命令同时验证了make install的产物路径正确性与data load/lf search两条核心命令链。5.3 cmake 构建客户端三组合( cd client; rm -rf build; mkdir build;cd build;cmake .. make -j \ PLATFORMPM3GENERIC PLATFORM_EXTRAS STANDALONELF_SAMYRUN \ cp -a ../*scripts ../*libs . \ ../../tools/pm3_tests.sh --clientbin $(pwd)/proxmark3 client ) || exit 1 ( cd client; rm -rf build; mkdir build;cd build;cmake .. make -j \ PLATFORMPM3RDV4 PLATFORM_EXTRAS STANDALONEHF_ST25_TEAROFF ) || exit 1 ( cd client; rm -rf build; mkdir build;cd build;cmake .. make -j \ PLATFORMPM3RDV4 PLATFORM_EXTRASBTADDON STANDALONEHF_REBLAY ) || exit 1三组 cmake 构建与上面的 make 矩阵一一对应但只构建 client/ 主机端程序。第一组额外做了两件事cp -a ../*scripts ../*libs .把client/cmdscripts/、client/luascripts/、client/lualibs/、client/pyscripts/等脚本目录复制到构建目录——pm3_tests.sh 中的脚本类测试script run example.cmd、script run data_hex_crc、script run parity.py需要这些资源就位通过--clientbin $(pwd)/proxmark3 client告诉测试工具“只测 client 目标且被测二进制就是这个 cmake 产物”从而验证 cmake 路径构建出的客户端行为与 make 路径一致。5.4 hitag2crack 与 PASS 判定# Hitag2crack, optionally with --long and --opencl... make hitag2crack/clean make hitag2crack tools/pm3_tests.sh hitag2crack || exit 1 echo PASSHitag2 破解工具套件tools/hitag2crack/刻意没有并入根 Makefile 的all目标源文件注释明确写着“not yet integrated in all, it must be called explicitly: make hitag2crack”因此作为独立一项构建并测试。全部步骤按顺序、失败即停地执行完毕后脚本输出PASS——这正是 README 所说的判定标准“If all tests OK, the script will finish with PASS.”。任何一步非零退出都会因|| exit 1中断整个矩阵不会打印 PASS。6. pm3_tests.sh自检引擎的参数与判定机制tools/pm3_tests.sh约 670 行是整个测试体系的核心引擎run_tests.sh 矩阵与 README 的单测流程最终都汇到这里。6.1 命令行接口Usage: pm3_tests.sh [--long] [--opencl] [--clientbin /path/to/proxmark3] [mfkey|nonce2key|mf_nonce_brute|staticnested|mfd_aes_brute|mfulc_des_brute|cryptorf|fpga_compress|bootrom|armsrc|client|recovery|common] --long: Enable slow tests --opencl: Enable tests requiring OpenCL (preferably a Nvidia GPU) --clientbin ...: Specify path to proxmark3 binary to test If no target given, all targets will be tested不传目标时TESTALLtrue覆盖全部测试域传目标如hitag2crack、client、common则只跑对应域--long开启SLOWTESTS放行标记为slow运行超过约 5 秒的测试README 单测命令tools/pm3_tests.sh --long即全量慢速模式--opencl开启OPENCLTESTS放行opencl类测试需要 OpenCL 设备帮助文本建议 Nvidia GPU--clientbin指定被测客户端二进制见 5.3 节 cmake 流程未指定时默认./client/proxmark3即 make 路径的产物。脚本开头还强制LANGC.UTF-8保证所有被测程序的帮助文本与错误输出是英文——因为断言全部基于英文输出做正则匹配与容器 Dockerfile 中的ENV LANGC.UTF-8形成双保险。6.2 两个判定原语CheckFileExist检查产物文件可带opencl标记无 OpenCL 时显示 SKIPPED 但不判失败CheckExecute执行命令并用正则匹配输出支持四个修饰位修饰位行为slow未开--long时跳过opencl未开--opencl时跳过retry失败最多重试 3 次ignore失败不致命如 Python 支持检测缺失时后续 py 脚本测试自动跳过执行超过 2 秒会打印耗时失败会打印完整Execution trace便于定位。所有检查失败即break出主循环打印红色Tests [ FAIL ]并以退出码 1 结束全部通过打印Tests [ OK ]。6.3 典型测试域举例common检查client/resources/与client/dictionaries/下的资源文件hardnested 状态表 lz4、sim020.bin、iclass/mfc/mfdes 默认密钥字典、t55xx 密码字典等是否存在并运行tools/xorcheck.py、tools/findbits.py、tools/recover_pk.py selftests、tools/mkversion.sh --short等 Python/Shell 工具bootrom / armsrc / recovery / fpgacompress分别断言bootrom/obj/bootrom.elf、armsrc/obj/fullimage.elf、recovery/recovery.bin、tools/fpga_compress/fpga_compress四个构建产物存在——这解释了 release_tests.sh 里每一轮make必须成功的原因产物缺失即 FAILmfkey / staticnested / nonce2key / mf_nonce_brute / mfd_aes_brute / mfulc_des_brute / cryptorf针对 tools/mfc/、tools/cryptorf/ 等密码学工具做“给定已知明文/nonce 输入断言能解出预定密钥”的黄金向量测试例如mfkey32v2输入固定八组参数后断言输出Found Key: [a0a1a2a3a4a5]hitag2crack验证 crack2 表构建/搜索工具、crack3/4/5 的生成—破解闭环crack5 的破解耗时约十几秒标记为slow以及 crack5opencl 的 OpenCL 版本标记slow opencl需要--opencl才跑client对客户端二进制做纯离线回归——帮助文本、多命令执行-c分号串联与 stdin 管道、cmdscript/luascript/pyscript 执行、data qrcode参数校验、data modulation自相关、trace load/listISO14443-A 与 ISO7816 两种解析、nfc decode各类 NDEF 负载vCard、WiFi WSC、Apple Wallet、PILet 签名等、wiegand encode/decode多种格式回环、二十余种 LF 制式 demodHID、AWID、Indala、NexWatch、Securakey 等与 T5577 模拟信号的lf search识别以及hf mf、hf mfdes、hf gst、emv test等 HF 域自检。断言全部针对仓库自带的 traces/ 离线文件无需真实射频信号只有 5.2 节那条make install后的真机测试需要设备在位。7. 手动执行单次构建加测试README 单测流程README 给出的精简流程是在容器内的仓库根目录执行sudo yum -y update make clean; make -j tools/pm3_tests.sh --long逐条说明sudo yum -y update刷新系统包保证工具链与库为最新稳定版make clean; make -j以默认平台PM3RDV4根 Makefile help 文本中声明做一轮全量并行构建产出 bootrom、armsrc 固件、recovery 镜像、客户端与 tools 二进制tools/pm3_tests.sh --long不带目标参数即测试全部域且放行所有慢速测试。注意该命令本身不校验--long之外的硬件状态除真机相关断言外可完全离线完成。相比 run_tests.sh 的完整矩阵这套单测流程等价于矩阵中“PM3RDV4 make 全量 pm3_tests”的组合适合在修改某一模块后快速自证若要复现 CI 级覆盖仍应回到tools/release_tests.sh全矩阵。8. 相关文件索引路径说明docker/fedora-41/README.md本文核心文档脚本用途、运行位置、单测命令docker/fedora-41/Dockerfile依赖清单、SKIPQT/UART_GID 构建参数、rrg 测试用户docker/fedora-41/docker_conf.inc镜像标签pm3-fedora-41:1.0docker/fedora-41/run_tests.sh容器内测试入口docker/run.sh / docker/rm.sh通用容器进入/清理脚本tools/release_tests.shmakecmake 双系统、三平台组合测试矩阵tools/pm3_tests.sh自检引擎参数解析、CheckExecute/CheckFileExist、各测试域Makefile根构建入口默认平台 PM3RDV4hitag2crack独立目标armsrc/Standalone/readme.mdSTANDALONE 参数对应模式的开发说明9. 小结Proxmark3 Iceman Fork 的 Fedora 41 Docker 目录看起来只有四个小文件实际串起了一条完整的“干净环境验证链”Dockerfile 精确复刻了交叉工具链、BlueZ、OpenCL、Qt、uv 等全部构建依赖并准备无密码的 sudo 测试用户run.sh 负责串口直通与源码挂载run_tests.sh 委托 release_tests.sh 跑完“3 种硬件/功能组合 × make/cmake 两套构建系统 安装真机回归 hitag2crack”的全矩阵最后以 PASS 收束而所有断言最终落在 pm3_tests.sh 的 CheckExecute/CheckFileExist 黄金向量体系上全部离线可复现。理解这条链之后无论是复现 CI 失败、新增 standalone 模式、还是验证一次密码学工具的改动都可以按同一套路径在容器内完成。【免费下载链接】proxmark3Iceman Fork - Proxmark3项目地址: https://gitcode.com/GitHub_Trending/pr/proxmark3创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考