Proxmark3（Iceman Fork）Fedora 42 Docker 环境下完整构建与测试执行指南

Proxmark3Iceman ForkFedora 42 Docker 环境下完整构建与测试执行指南【免费下载链接】proxmark3Iceman Fork - Proxmark3项目地址: https://gitcode.com/GitHub_Trending/pr/proxmark3本篇指南以 docker/fedora-42/README.md 为骨架结合 Dockerfile、run_tests.sh 及 tools/release_tests.sh、tools/pm3_tests.sh 的真实实现讲解如何在 Proxmark3Iceman Fork仓库中使用 Fedora 42 容器化环境跑通多平台 make 构建 CMake 客户端构建 全量回归测试的完整流程并掌握单测模式下的手动验证方法。一、文档定位Fedora 42 容器内的测试入口docker/fedora-42/README.md 的核心内容可以概括为三点run_tests.sh脚本会组合make与cmake两套构建系统遍历 RDV4、GENERIC、BTADDON 等不同平台组合进行构建与测试若所有测试通过脚本最终以PASS结束该脚本必须在 Proxmark3 仓库根目录、且处于 Docker 环境内部执行。文档给出的标准调用方式如下在宿主机上进入仓库根目录后通过容器执行docker/fedora-42/run_tests.sh;如果需要只运行单组测试快速验证某一次构建README 给出的等价手动流程是sudo yum -y update make clean; make -j tools/pm3_tests.sh --long也就是说run_tests.sh本质上是一个一键发布前回归脚本而手动命令是它的最小化子集。下面逐层拆解其内部实现。二、Docker 镜像构成Fedora 42 上的构建依赖docker/fedora-42/Dockerfile 基于官方fedora:42镜像关键配置如下基础语言环境ENV LANGC.UTF-8与 tools/pm3_tests.sh 开头强制LANGC.UTF-8的意图一致——保证测试输出中的英文关键字匹配如Found Key:、Tests ( ok不随系统本地化语言漂移编译依赖一条dnf install安装了gcc、gcc-c、make、cmake、git、arm-none-eabi-gcc-cs、arm-none-eabi-newlibARM 交叉编译工具链用于armsrc固件以及客户端链接所需的readline-devel、bzip2-devel、lz4-devel、zlib-ng-compat-devel、openssl-devel、gd-devel、libatomic、python3-devel、bluetooth-libs-develBTADDON 蓝牙扩展等可选 Qt6通过构建参数SKIPQT控制。默认SKIPQTfalse安装qt6-qtbase-devel以支持 Qt 客户端界面构建时传SKIPQTtrue可跳过得到更小的镜像OpenCL 运行时mesa-libOpenCL与ocl-icd-devel供 tools/pm3_tests.sh 中--opencl类别的 Hitag2 测试使用该脚本注释中说明此类测试preferably a Nvidia GPU无 GPU 时对应测试会被标记 SKIPPEDuv通过多阶段COPY --fromghcr.io/astral-sh/uv:latest把uv/uvx拷入系统pm3_tests.sh检测到uv存在时会自动改用uv run --script执行 Python 测试可用SKIPUV1强制回退到python3用户与串口权限创建无密码用户rrgpasswd -d rrg并以USER rrg运行支持构建参数UART_GID当宿主机 dialout 组的 GID 与容器默认不一致时可用groupadd -g ${UART_GID} mydialout对齐从而让容器内进程能直接访问 Proxmark3 的串口设备sudorrg ALL(ALL) ALL写入 sudoers这是run_tests.sh首行sudo yum -y update以及release_tests.sh中sudo make install/uninstall能执行的前提。三、run_tests.sh 与 release_tests.sh完整测试流水线的两级结构docker/fedora-42/run_tests.sh 本体很短sudo yum -y update tools/release_tests.sh # beeps for ((i0; i10;i)) do echo -e \a;sleep 0.3; done它的职责是先刷新 Fedora 软件源再转交 tools/release_tests.sh 执行真正的构建矩阵末尾循环 10 次输出\a蜂鸣声作为测试跑完的人工提示长时间回归结束后即使不看终端也能察觉。tools/release_tests.sh 是发布回归的实际执行体其结构分为四段1. 前置检查Makefile.platform 冲突保护脚本开头检查仓库根目录是否存在Makefile.platform若其中包含SKIP_前缀的指令例如本地开发者用于跳过某目标的私有配置会直接报错退出——因为这类 SKIP 指令会使回归结果失真。2. make 构建矩阵firmware 侧三种组合make clean make -j PLATFORMPM3GENERIC PLATFORM_EXTRAS STANDALONELF_SAMYRUN tools/pm3_tests.sh --long make clean make -j PLATFORMPM3RDV4 PLATFORM_EXTRAS STANDALONEHF_ST25_TEAROFF make clean make -j PLATFORMPM3RDV4 PLATFORM_EXTRASBTADDON STANDALONEHF_REBLAY这正对应 README 所说的RDV4、GENERIC、BTADDON 的组合。注意第一组PM3GENERIC构建后立即带--long运行pm3_tests.sh全量测试慢速测试也包含在内后两组只验证构建产物存在性由后续pm3_tests.sh的CheckFileExist断言如bootrom.elf、armsrc/obj/fullimage.elf、recovery/recovery.bin把关STANDALONE指定了每次附带构建的独立运行固件Standalone 玩法如LF_SAMYRUN、HF_ST25_TEAROFF、HF_REBLAY其源码位于 armsrc/Standalone 目录。3. 安装与设备级冒烟测试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从源码结构看这里先探测sudo true是否可行可行则以sudo make install将客户端装入系统路径cd /tmp后在非仓库目录执行已安装的proxmark3用data loadlf search做一条不依赖硬件的真实解码链路FDX-B 识别最后make uninstall还原现场。INSTALLSUDO变量保证 install/uninstall 的权限一致。4. 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 ) ( cd client; rm -rf build; mkdir build; cd build; cmake .. make -j PLATFORMPM3RDV4 PLATFORM_EXTRAS STANDALONEHF_ST25_TEAROFF ) ( cd client; rm -rf build; mkdir build; cd build; cmake .. make -j PLATFORMPM3RDV4 PLATFORM_EXTRASBTADDON STANDALONEHF_REBLAY )第一组 CMake 构建完成后把仓库根的*scripts/*libsLua 脚本与库拷入构建目录再用--clientbin指向刚编出的proxmark3可执行文件仅运行client这一类测试对应 tools/pm3_tests.sh 中的client目标。后两组参数仅验证 cmake 构建可重复通过。5. Hitag2crack 独立回归与 PASS 判定make hitag2crack/clean make hitag2crack tools/pm3_tests.sh hitag2crack echo PASShitag2crack从工具集独立出来单测pm3_tests.sh中它并不属于--all默认集覆盖 crack2/3/4/5 及 OpenCL 版本。全部串行步骤均以|| exit 1或if ! ...; then break; fi保证任一失败即中止且不会打印PASS——这与 README 中若所有测试 OK脚本以 PASS 结束的约定完全对应。四、pm3_tests.sh 测试分类速览tools/pm3_tests.sh 是整个仓库的回归测试入口release_tests.sh中的每一轮构建最终都落到它。其参数见脚本内置--help为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测试按模块分区输出每区由CheckFileExist产物存在性与CheckExecute执行输出正则断言两类检查组成。CheckExecute支持slow~5s需--long才执行、opencl需--opencl、retry失败重试至多 3 次、ignore失败不致命四种修饰符未启用的 slow/opencl 项会打印SKIPPED。主要测试分区包括common资源/字典文件存在性hardnested 表、sim020.bin、各.dic字典如 client/dictionaries 中的iclass_default_keys.dic、mfc_default_keys.dic、mfdes_default_keys.dic、t55xx_default_pwds.dic、ht2_default.dic以及tools/xorcheck.py、tools/findbits.py、tools/mfc/pm3_eml_mfd_test.py、tools/recover_pk.py等 Python 工具的自测bootrom / armsrc / recovery / fpgacompress只校验各构建产物存在bootrom/obj/bootrom.elf、armsrc/obj/fullimage.elf、recovery/recovery.bin、tools/fpga_compress/fpga_compress——这就是 README 中make 与 cmake 多种组合构建的结果如何被断言的地方mfkey / staticnested / nonce2key / mf_nonce_brute / mfd_aes_brute / mfulc_des_brute / cryptorfMifare 密钥恢复类工具的已知答案测试KAT例如mfkey64用固定输入断言输出Found Key: [ffffffffffff]client对proxmark3二进制的无硬件测试——help 文本、-c多命令、stdin 脚本、script runcmd/lua/pyscript、wiegand encode/decode、nfc decodeNDEF、Apple Wallet、电子护照签名等多组十六进制语料、大量 LF 载波traces/*.pm3的lf search/demod识别断言、emv test、hf mf/hf mfdes/hf iclass loclass等协议自检Tests ( ok正则。因此 README 中单测模式的tools/pm3_tests.sh --long的实际语义是在你手动完成的一次make -j之后运行除 hitag2crack 之外的全部默认目标并包含慢速测试。五、手动单测流程与完整回归的差异README 给出的单测流程sudo yum -y update make clean; make -j tools/pm3_tests.sh --long与完整run_tests.sh相比存在三点差异使用时需心中有数平台组合手动流程不带PLATFORM变量构建的是 Makefile 默认平台而非 GENERIC/RDV4/BTADDON 三组矩阵PLATFORM_EXTRASBTADDON这类组合不会被覆盖客户端手动流程不触发client/下的 CMake 构建若要测试 CMake 编出的客户端需自行参照release_tests.sh中的 cmake 段落执行并以--clientbin指定其路径hitag2crack不在pm3_tests.sh默认集内必须显式以tools/pm3_tests.sh hitag2crack调用release_tests.sh即如此处理。六、容器的进入与清理docker_conf.inc、run.sh、rm.shdocker/fedora-42/docker_conf.inc 定义本目录专属的两项配置DOCKER_IMAGEpm3-fedora-42:1.0 #SKIPQT1镜像名pm3-fedora-42:1.0与其余发行版目录ubuntu、debian、archlinux 等互不冲突SKIPQT1取消注释可用于加速构建、跳过 Qt6 依赖。仓库级的 docker/run.sh 是通用进入脚本它要求必须在某个发行版子目录内运行检测docker_conf.inc是否存在然后用../../pm3 --list探测宿主机上的 Proxmark3 串口设备若发现则通过--device把/dev/tty0形态的串口挂载进容器以--volume$(pwd)/../..:/home/rrg/proxmark3把整个仓库挂载为容器内工作目录配合--nethost与--rm启动交互式容器。进入容器后即可按 README 说明执行docker/fedora-42/run_tests.sh;完成回归。退出并彻底清理时使用 docker/rm.sh先按ancestor$DOCKER_IMAGE找到并删除仍在的容器再删除镜像与构建缓存docker image rmdocker builder prune --force。由于DOCKER_IMAGE按目录区分rm.sh 只会清理当前目录对应的那一个镜像。七、小结标准全量回归在 Fedora 42 容器内、仓库根目录下执行 docker/fedora-42/run_tests.sh它等价于yum 更新 → 三组 make 平台矩阵构建GENERIC/RDV4/RDV4BTADDON各自附带不同 Standalone 固件→ 安装/卸载冒烟 → 三组 CMake 客户端构建 → hitag2crack 回归全部通过才打印PASS快速单测sudo yum -y update make clean make -j tools/pm3_tests.sh --long覆盖当前默认平台的产物断言与除 hitag2crack 外的全部默认测试含 slow可选项--opencl启用 GPU 依赖的 Hitag2 OpenCL 测试--clientbin指向待测的 CMake 客户端二进制SKIPQT/SKIPUV/UART_GID分别控制镜像构建与运行时的环境适配。【免费下载链接】proxmark3Iceman Fork - Proxmark3项目地址: https://gitcode.com/GitHub_Trending/pr/proxmark3创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考