企业官网建设流程全解析

Proxmark3（Iceman Fork）LF_NEXID 独立模式实战：Nexwatch 门禁卡被动嗅探与闪存收集

【免费下载链接】proxmark3Iceman Fork - Proxmark3项目地址: https://gitcode.com/GitHub_Trending/pr/proxmark3

本文基于 Proxmark3（Iceman Fork）仓库中的 LF_NEXID 模式文档 与其 固件源码实现，完整讲解 NexID 独立模式的工作原理、Nexwatch 协议的解码细节、RDV4 闪存日志机制与编译烧录流程。读完后，你将能够独立编译并部署该模式，理解 PSK 解调、前导码识别、扰码还原与校验和恢复的完整链路，并掌握从 SPI flash 中提取收集日志的客户端操作。

一、LF_NEXID 是什么

LF_NEXID 是 Proxmark3 的LF（125 kHz）独立（Standalone）模式，由 jrjgjk 与 Zolorah 编写。它被动嗅探并记录 Nexwatch / NexKey ID 凭证到设备闪存中，同时解码出每张被捕获卡片的magic bytes（标识字节）与 mode（模式位）信息。

为什么针对 Nexwatch：Nexwatch（Honeywell 出品）是商业楼宇门禁系统中常见的 125 kHz 卡格式。该收集器静默地在长时间运行中收割 Nexwatch 凭证——定位上类似多格式收集器 IceHID 模式，但专门针对 Nexwatch 协议，且保留完整的解码信息（magic、mode）。

关键元信息（来自 模式文档）：

由于该模式依赖 RDV4 的 SPI flash，构建系统在 Makefile.hal 中把它登记在STANDALONE_MODES_REQ_FLASH列表里，编译时会附加-DWITH_FLASH宏：

STANDALONE_MODES_REQ_FLASH := LF_HIDFCBRUTE LF_ICEHID LF_NEXID LF_THAREXDE HF_BOG ...

Makefile.inc 中则定义了源文件的选择逻辑：

# WITH_STANDALONE_LF_NEXID ifneq (,$(findstring WITH_STANDALONE_LF_NEXID,$(APP_CFLAGS))) SRC_STANDALONE = lf_nexid.c endif

二、编译与烧录

LF_NEXID 与所有独立模式一样，一次只能编译一种模式进固件（除非使用 DANKARMULTI 多模式加载器）。文档给出的标准编译流程为：

make clean make STANDALONE=LF_NEXID -j ./pm3-flash-fullimage

从 Standalone 开发指南 可知等价的平台化写法是：将Makefile.platform.sample复制为Makefile.platform，并设置：

PLATFORM=PM3RDV4 STANDALONE=LF_NEXID

然后执行make clean强制重编译、make -j编译，最后用仓库根目录的 pm3-flash-fullimage 脚本烧录。编译结束时会打印一段头部信息显示编译配置，请确认其中包含LF_NEXID字样。

烧录后连接设备，长按按钮触发 LED 显示并进入独立模式；若此时通过 USB 连接，还能在客户端看到该模式运行期间输出的调试字符串（Dbprintf），源码注释中特别建议：先到实验室连着 PM3 客户端试跑，再带进现场。

三、运行时工作流程（状态机）

进入独立模式后，RunMod() 执行以下初始化：

1. FpgaDownloadAndGo(FPGA_BITSTREAM_LF)—— 下载 LF 位流；
2. LFSetupFPGAForADC(LF_DIVISOR_125, true)—— 配置 FPGA 做 125 kHz 的 LF ADC 采集；
3. rdv40_spiffs_lazy_mount()—— 惰性挂载 SPIFFS 文件系统，并检查lf_nexcollect.log是否已存在（决定后续是"新建写入"还是"追加"）。

随后进入主循环，文档中给出的状态机如下（与源码逐条对应）：

主循环每一轮（对应 lf_nexid.c 第 319–343 行）：

WDT_HIT(); // 喂看门狗 if (data_available()) break; // 收到 USB 数据 -> 退出 int button_pressed = BUTTON_HELD(280); if (button_pressed == BUTTON_HOLD) break; // 长按 280ms -> 退出 LED_A_ON(); // 开始采样/记录 DoAcquisition_config(false, size, true); // 采集约 16385 样本 res = demodNexWatch(); // 解调 + Nexwatch 解码

退出循环后：点亮 LED C、rdv40_spiffs_lazy_unmount()卸载（同步）flash、熄灭全部 LED，最后通过DownloadLogInstructions()打印取回日志的操作指引，并关闭 FPGA（FPGA_MAJOR_MODE_OFF）。

LED 与按键控制（原文档表格，与源码一致）：

四、解码链路深度剖析

demodNexWatch()是整个模式的解码核心，分为三个阶段。

4.1 PSK 解调

PSKDemod()先检查getSignalProperties()->isnoise过滤纯噪声，然后调用通用库 lfdemod.c 中的pskRawDemod_ext()做 PSK1 原始解调：

int errCnt = pskRawDemod_ext(dest, &size, &clk, &invert, startIdx); if (errCnt > 100) { BigBuf_free(); return PM3_ESOFT; // 错误位过多，判定为非目标信号 }

这里errCnt > 100是"是不是 Nexwatch"的第一道软门槛——普通 LF 信号（EM4100 的 ASK、HID 的 Manchester 等）解出的错误位数会远超该阈值，直接放弃本轮。

4.2 前导码识别与极性翻转

detectNexWatch()用固定的 28 bit 前导码在解调后的比特流中做preambleSearch：

uint8_t preamble[28] = {0,0,0,0, 0,1,0,1, 0,1,1,0, 0,0,0,0, 0,0,0,0, 0,0,0,0, 0,0,0,0};

若原始前导码未命中，会尝试整串取反的前导码，命中则置*invert = 1，后续把整个数据流异或 1 纠正极性。找不到时返回 -1（样本不足 96 bit）或 -4（无匹配），主循环随即回到采样态。找到后还要跳过 Nexwatch 前导识别的前 4 个 bit（idx += 4），即源码注释所说的"we use 4 extra zeros"。

4.3 帧结构、扰码还原与校验

跳过前导后，96 bit 有效数据按如下偏移解析（与 client/src/cmdlfnexwatch.c 中客户端demodNexWatch的解析完全同源）：

扰码还原：卡号在空口传输前经过位交织加扰。nexwatch_scamble()使用一张固定的 32 元素映射表把加扰位流还原为可读卡号（hex_2_id = {31, 27, 23, ..., 28, 24, ..., 0}，即每 4 位一组、组间交错的偏移）：

case DESCRAMBLE: { *id = 0; for (uint8_t idx = 0; idx < 32; idx++) { bool bit_state = (*scambled >> hex_2_id[idx]) & 1; *id |= (bit_state << (31 - idx)); } }

还原出的cn就是打印在卡片上的十进制卡号。

奇偶校验：nexwatch_parity()对 32 bit 加扰 ID + 4 bit mode（共 5 字节，低 4 位掩掉）做 nibble 级异或，再经nexwatch_parity_swap()（位序 1234→4231 交换）得到 4 bit 奇偶值，它参与校验和计算。

校验和与 magic 恢复：nexwatch_checksum()的计算方式是：从 ID 最高字节开始逐字节相减（注意是减法而非加法），再减去 magic 字节与交换后奇偶值的高 4 位，最后做reflect8（位序镜像）：

uint8_t a = ((id >> 24) & 0xFF); a -= ((id >> 16) & 0xFF); a -= ((id >> 8) & 0xFF); a -= (id & 0xFF); a -= magic; a -= (reflect8(parity) >> 4); return reflect8(a);

空口帧里并不携带 magic 字节本身，因此固件对 magic 做0..254 的暴力枚举：逐一代入校验和公式，与帧内chk相等者即为真实 magic 值。固件版暴力遍历全部 255 个候选值；而客户端命令路径则优先比对三组已知指纹再兜底暴力：

（见 client/src/cmdlfnexwatch.c 第 207–234 行。）

4.4 日志条目格式

每次成功解码，固件拼一条 81 字节上限的文本记录并追加到 flash：

sprintf((char *)entry, "Nexwatch ID: %"PRIu32", Magic bytes: 0x%X, Mode: %x\n", cn, magic, mode);

即日志中每行形如：

Nexwatch ID: 521512301, Magic bytes: 0x88, Mode: 1

同时通过Dbprintf把 raw id、magic、88bit id、mode、Raw 三个 32bit 块全部回显到 USB 调试通道，方便现场核对。

五、闪存日志：写入、取回与清理

5.1 写入策略

append()的写入策略是首次运行时调用rdv40_spiffs_write()新建文件，之后一律rdv40_spiffs_append()追加，安全级别为RDV4_SPIFFS_SAFETY_SAFE；写入期间点亮 LED B。log_exists标志在启动时通过exists_in_spiffs(LF_NEXCOLLECT_LOGFILE)探测一次，避免每轮重复 stat。

5.2 取回日志

收集结束后接回 PM3 客户端，执行（原文档给出的命令）：

mem spiffs dump -s lf_nexcollect.log -d lf_nexcollect.log

该命令把 flash 上的日志文件复制到客户端本地；退出 PM3 客户端后用cat/more查看内容。固件在退出时打印的指引（DownloadLogInstructions()）也是这三步：mem spiffs dump→ exit 客户端 →cat lf_nexcollect.log。

5.3 清理日志

源码注释中还给出了删除日志的命令，原文档未列出，补充如下：

mem spiffs remove -f lf_nexcollect.log

六、与客户端 lf nexwatch 命令的关系

LF_NEXID 独立模式是"无人值守收集"，而同一协议在主固件客户端上有完整的交互式命令族lf nexwatch（client/src/cmdlfnexwatch.c），二者共享同一套 scrambler/parity/checksum 算法：

典型闭环：LF_NEXID 在门口收集到Nexwatch ID: 521512301, Magic bytes: 0x88, Mode: 1后，回到实验室可用lf nexwatch clone --cn 521512301 -m 1 --nc复现凭证，再用lf nexwatch reader验证——收集、复现、验证形成完整链路。

七、现场部署要点与限制

• 硬件前提：必须为 RDV4（SPI flash + 电池）。普通 RDV3 无法使用，因为日志需要 flash 承载。
• 单模式限制：固件一次只能含一个独立模式；如需同时收集多种 LF 格式，考虑 DANKARMULTI 多模式加载器。
• 噪声过滤：errCnt > 100与噪声检测两级过滤意味着误捕获率很低，但 125 kHz 附近强干扰环境下也可能漏采；从源码结构看，采集长度固定为MIN(16385, BigBuf_max_traceLen())样本，无法在运行中调整。
• 调试输出常开：该模式运行期间会持续输出调试字符串（raw id、Raw 块等），源码注释明确提示先接客户端试跑再进现场。
• 退出方式：长按按钮 280ms 或发送任意 USB 命令；退出时 flash 会先卸载同步（LED C），切勿在 LED B/C 亮起时直接断电。
• 协议边界：解码只恢复 card ID、magic、mode 三个字段；帧内 4 bit parity 在固件版中用于校验和计算而非输出比对（客户端版会打印 parity ok/fail），因此日志不记录原始 96 bit 帧。

八、延伸阅读

• LF_NEXID 模式原始文档
• 固件实现源码
• Standalone 模式总览与开发指南
• IceHID 多格式收集器文档（HID/AWID/IO/EM 多协议对照参考）
• Tharexde EM4x50 收集器文档
• 客户端 lf nexwatch 命令实现
• PSK 解调与前导码搜索通用库
• 构建配置：Makefile.hal 与 Makefile.inc

【免费下载链接】proxmark3Iceman Fork - Proxmark3项目地址: https://gitcode.com/GitHub_Trending/pr/proxmark3