Flipper Zero Unleashed 固件 RFID 功能测试用例全解析：从协议读取到 T5577 写入的完整验证指南

Flipper Zero Unleashed 固件 RFID 功能测试用例全解析：从协议读取到 T5577 写入的完整验证指南

【免费下载链接】unleashed-firmwareFlipper Zero Unleashed Firmware项目地址: https://gitcode.com/GitHub_Trending/un/unleashed-firmware

导读

本篇文章以 documentation/testing/rfid_test_cases.md 为核心，系统讲解 Flipper Zero Unleashed 固件中低频 RFID（125 kHz）功能模块的完整测试体系。文档围绕 EM-Marine 4100、Motorola Indala26、HID H10301 以及 Troyka/Podorozhnik 等常见卡型，定义了"读取 → 仿真 → 保存 → 写入 → 复读校验"五大共享操作步骤（Shared Steps）与九组测试用例。读完本文，你将掌握 RFID 应用的场景流转逻辑、各协议在固件源码中的实现原理、T5577 可写芯片的写入与清空操作方式，以及如何通过 CLI 命令对读取、写入、仿真和 RAW 数据采集进行交叉验证。

1. 测试文档定位与测试方法论

rfid_test_cases.md属于仓库 documentation/testing 目录下的功能测试用例集，与同目录的nfc_test_cases.md、subghz_test_cases.md等文档共同构成固件的回归测试体系。该文档的定位是黑盒手工测试用例：它不描述代码实现，而是以"操作步骤 + 预期结果"的形式，指导测试人员（或 QA 自动化脚本）逐项验证 RFID 应用在真实硬件上的行为。

整个文档建立在两个关键概念之上：

• 共享步骤（Shared Steps）：文档用[1]~[5]编号引用五组被反复复用的操作序列——Read、Emulation、Save、Write、Read the written。所有测试用例都由这些共享步骤的不同排列组合而成；
• 预期结果（Expected result）：每个步骤后都列出了明确的通过标准，例如"卡被成功读取""仿真出的 ID 与原始 ID 一致""保存后场景自动跳转到 Saved 目录"等。

理解这一点后，我们先把五个共享步骤背后的固件实现讲清楚，再逐条拆解九组用例。

2. RFID 应用入口与主菜单场景流转

所有测试用例的第一步都是"Go to RFID"（进入 RFID 应用）。在固件中，该应用由 applications/main/lfrfid 目录实现，主场景的菜单构建逻辑位于 lfrfid_scene_start.c：

submenu_add_item(submenu, "Read", LfRfidMenuIndexRead, ...); submenu_add_item(submenu, "Saved", LfRfidMenuIndexSaved, ...); submenu_add_item(submenu, "Add Manually", LfRfidMenuIndexAddManually, ...); submenu_add_item(submenu, "Extra Actions", LfRfidMenuIndexExtraActions, ...);

菜单索引定义在 lfrfid_i.h：

数据存储层面，所有读到的钥匙保存在 SD 卡的/ext/lfrfid目录下（见 lfrfid_i.h 中LFRFID_APP_FOLDER与LFRFID_APP_FILENAME_EXTENSION宏定义），普通钥匙文件扩展名为.rfid，RAW 原始波形文件使用.ask.raw与.psk.raw后缀。这解释了文档中"保存后场景跳转到 Saved 目录"的预期结果——保存操作会调用 lfrfid.c 中的lfrfid_save_key()，将file_name + ".rfid"拼接到LFRFID_APP_FOLDER路径下完成落盘。

3. 五大共享步骤（Shared Steps）逐项解析

文档定义的五个共享步骤构成了所有用例的操作骨架，下面结合源码说明每一步在固件内部的真实行为与判定标准。

3.1 Shared Step [1]：Read（读取）

操作：将卡贴近设备背部天线区域，Flipper 自动感应并读取。

预期结果：卡成功读取；读到的关键信息与原始卡片一致。

固件侧由LFRFIDWorker工作线程驱动读取流程，读到的数据进入ProtocolDict（协议字典）并按协议特征自动识别。主菜单 Read 场景对应LfRfidSceneRead，而Extra Actions中还提供了两种受限读取模式（见 lfrfid_scene_extra_actions.c）：

• Read ASK (FDX, Regular)：LFRFIDWorkerReadTypeASKOnly，仅按 ASK（幅度键控）解调；
• Read PSK (Indala)：LFRFIDWorkerReadTypePSKOnly，仅按 PSK（相移键控）解调，专门针对 Indala 类卡片。

自动模式（LFRFIDWorkerReadTypeAuto）会同时尝试两种解调方式。判定"信息与原始一致"的依据是：读取结果会渲染出FC（工厂码）与Card（卡号）等可读字段（见下文协议渲染函数），测试时需与卡面或读卡器读到的原始编号比对。

3.2 Shared Step [2]：Emulation（仿真）

操作：读取成功后选择 Emulate，用另一台 Flipper（或其他固件的读卡设备）读取仿真信号。

预期结果：第二台设备能读到同样的 ID；仿真出的信息与原始完全一致。

固件通过lfrfid_worker_emulate_start()启动仿真，将协议编码后的信号经 125 kHz 天线持续发射。文档用例 9 特别强调"用第二台 Flipper、且运行另一套固件"来验证，目的是排除两台设备同固件可能存在的相同解码缺陷，确保 ID 是"真读出来"的而不是两台设备互相自洽。

3.3 Shared Step [3]：Save（保存）

操作：为钥匙命名并保存。

预期结果：钥匙以指定名称保存成功；保存后界面自动切换到 "Saved" 目录。

保存路径与文件名规则见 lfrfid.c：文件名长度上限由LFRFID_KEY_NAME_SIZE（22 字节）约束，保存成功后场景管理器切换到LfRfidSceneSavedKeyMenu，即文档所说的 "Saved" 目录视图。

3.4 Shared Step [4]：Write（写入）

操作：将已保存的钥匙通过 "write" 功能写入另一张空白/可写载体（典型目标为 T5577 芯片）。

预期结果：写入成功，出现成功提示场景。

写入动作由lfrfid_worker_write_start()驱动，最终调用各协议的write_data()回调把数据编码成 T5577（或 EM4305、Hitag micro 魔术卡）的配置块。写入失败时固件会区分三类错误（见 lfrfid_cli.c 中对应的 CLI 输出）：协议本身不可写（ProtocolCannotBeWritten）、载体芯片不可写（FobCannotBeWritten）。这一错误区分同样体现在 GUI 场景的LfRfidEventWriteProtocolCannotBeWritten/LfRfidEventWriteFobCannotBeWritten事件上（见 lfrfid_i.h）。

3.5 Shared Step [5]：Read the written（复读校验）

操作：用读卡器（或 Flipper 自身）读取刚才写入的载体。

预期结果：载体信息被成功读出；数据与写入前保存的钥匙完全一致。

这是闭环校验的关键一步，验证"保存的钥匙 → 写入载体 → 载体可读"整条链路的数据一致性，防止出现"能写不能读"或"写入后数据损坏"的假成功。

4. 九组测试用例逐一拆解

4.1 用例 1：EM Marine 4100 全流程

覆盖 Read → Emulate → Save → Write → Read the written 完整链路。EM4100 是文档测试矩阵中唯一走完全部五个共享步骤的协议，适合作为回归测试的"基准卡型"。

4.2 用例 2：Motorola Indala26（写入优先路径）

与用例 1 的区别在于操作顺序：先用共享步骤 [4] 写入已保存钥匙，再执行 Emulate → Save → Write → Read the written。该用例验证两件事：

1. Indala26 卡能否被写入 T5577 载体；
2. 写入后的仿真与二次复读是否一致。

从源码看，Indala26 的 T5577 写入配置为 PSK1 调制、RF/32 位速率（见 protocol_indala26.c），这是它与 EM4100（Manchester 调制）在写入层面最本质的区别。

4.3 用例 3：HID H10301（Picopass）

文档将 HID H10301 标注为 "(Picopass)"。该用例同样走标准五步流程。H10301 协议在固件中的名称为H10301、厂商标识为HID，特征为 ASK 解调（见 protocol_h10301.c），采用 FSK 双频振荡器生成 50 kHz 位速率载波，T5577 写入使用LFRFID_T5577_MODULATION_FSK2a调制（protocol_h10301.c）。

4.4 用例 4：Indala26（读取优先路径）

与用例 2 同一协议、但按标准顺序 Read → Emulate → Save → Write → Read the written 执行，与用例 2 形成"同一协议两种操作顺序"的对照，用于排查读写顺序是否影响结果。

4.5 用例 5：Troyka/Podorozhnik 与 Troika 解析器专项

该用例在标准读取流程中插入了一个专项验证点：

Check the work of the troika parser——读取卡片时，应加载此类卡片特有的附加信息列表。

Troyka/Podorozhnik 是俄罗斯交通卡体系（Troika）的常见卡型，读取后界面会额外渲染卡片特有信息。测试时需确认读取场景除了基础 ID 外，还正确加载了附加信息，而不能只校验 ID 本身。

4.6 用例 6：RFID 多标准批量读取

进入 RFID → Reading，依次测试indala、em-marine、HID三类标准卡都能被识别，然后将所有读到的卡全部保存。此用例是"多协议自动识别"能力测试——固件自动模式下会遍历协议字典中的解码器（decoder），从源码看 lfrfid_protocols.h 中注册了 24 种协议（EM4100、Electra、H10301、Idteck、Indala26/224、IOProxXSF、AWID、FDX-A/B、HID 系列、Pyramid、Viking、Jablotron、Paradox、PAC/Stanley、Keri、Gallagher、Nexwatch、Securakey、GProxII、Noralsy 等），自动识别即遍历这些解码器逐个匹配。

4.7 用例 7：RFID 写入 T5577

操作路径为：读取（或选择已保存）→ Extra Actions/More → Write，将选中卡写入 T5577；随后连续写入 3 种不同类型卡片并逐一验证读取结果。

预期结果：读卡器正确识别全部 3 种卡，数据完全匹配。

这一用例对应 lfrfid_scene_write.c 及 lfrfid_scene_write_success.c 等场景。T5577 是 125 kHz 可编程芯片，支持多种调制/速率组合，因此可以承载 EM4100（Manchester）、Indala（PSK）、H10301（FSK）等不同协议的帧。测试中还会涉及密码问题：固件内置了一份 T5577 默认密码表default_passwords[]（共 128 个常用密码，见 lfrfid.c），供写入/清除时暴力尝试访问受密码保护的芯片。

4.8 用例 8：RFID Add Manually（手动创建）

进入 RFID → Add Manually，手动创建三种卡：EM4100、H10301、I40134，然后用另一台 Flipper 或读卡台读取。

预期结果：三张手动创建的卡都能被正常读取出数据。

手动创建走LfRfidSceneSaveType→LfRfidSceneSaveData场景链（见 lfrfid_scene_start.c），通过 ByteInput 输入协议数据后保存。该用例验证的是"手工输入数据 → 编码 → 发射可读"链路，可用于无实体卡时构造测试样本。

4.9 用例 9：RFID 仿真跨固件验证

在 Saved 目录中依次选择Indala → Emulate、EM-Marine → Emulate、HID → Emulate，分别用"第二台 Flipper + 另一套固件"读取。

预期结果：读卡方显示的 ID 与仿真方完全一致。

该用例的三条子步骤结构相同，核心目的是对三类主流协议逐一做跨设备、跨固件的仿真一致性验证，排除单设备自读自写的假阳性。

5. 被测协议源码级原理

测试要"知其所以然"，这里补充三个核心协议在 lib/lfrfid/protocols 中的实现要点。

5.1 EM4100（EM-Marine）

protocol_em4100.c 是典型代表：

• 数据帧：9 位全 1 引导头 + 10 行 × 5 位数据（4 位数据 + 1 位行校验）+ 4 位列校验 + 停止位，总计 64 位编码帧；
• 调制：Manchester 编码，解码器通过manchester_advance()状态机解析短/长电平（源码中EM_READ_SHORT_TIME_BASE/EM_READ_LONG_TIME_BASE定义在 256/512 时间基数，protocol_em4100.c）；
• 支持三种时钟：RF/64、RF/32、RF/16，分别注册为EM4100、EM4100/32、EM4100/16三个协议条目；
• T5577 写入：配置块 0 使用 Manchester 调制 + 对应位速率，数据写入块 1、块 2（protocol_em4100.c）；
• 渲染输出：FC: %03u / Card: %05hu / DEZ 8 / DEZ 10等字段（protocol_em4100.c），这是测试中"信息与原始一致"的人工比对依据。

5.2 Indala26（Motorola）

protocol_indala26.c 的关键特征：

• 特征：LFRFIDFeaturePSK，即只能通过 PSK 方式读取（protocol_indala26.c），这也解释了为什么 Extra Actions 里单独提供 "Read PSK (Indala)" 入口；
• 帧结构：33 位前导码 + 64 位编码数据，解码时同时维护正/负极性、以及相位错位（corrupted）四条数据通道以提高容错率（protocol_indala26.c）；
• T5577 写入：PSK1 调制 + RF/32 位速率，数据写入块 1、块 2（protocol_indala26.c）；
• 渲染输出：FC、Card、Wiegand 校验（Parity）与 Indala 校验和（Checksum）状态（protocol_indala26.c）。

5.3 H10301（HID）

protocol_h10301.c 的特征：

• 特征：LFRFIDFeatureASK（protocol_h10301.c），通过fsk_demod（FSK 解调器）识别；
• 帧结构：0x1D 前导 + 14 位编码的公司/OEM 码与格式码（01=0、10=1 双位编码）+ 24 位数据 + 前后 Wiegand 奇偶校验位；
• T5577 写入：FSK2a 调制 + RF/50 位速率，数据横跨块 1~3（protocol_h10301.c）；
• 渲染输出：FC: %hhu / Card: %hu（protocol_h10301.c）。

6. T5577 附加操作与扩展能力

在 "Extra Actions"（文档用例 7 提到的 "More"）菜单中，固件还提供了 T5577 芯片的维护操作（lfrfid_scene_extra_actions.c）：

其中 Clear/Wipe 操作同样依赖 lfrfid.c 中的 128 个默认密码表（包含0x00000000、0xFFFFFFFF、0x12345678、0xDEADC0DE、0xFEEDBEEF等常见弱密码），用于尝试解锁未知密码的 T5577。RAW 采集/仿真入口受FuriHalRtcFlagDebug调试标志门控，RAW 文件用于协议开发与波形级调试。

7. 用 CLI 命令补充交叉验证

GUI 之外的自动化验证手段是rfidCLI 命令，注册于 lfrfid_cli.c。该文件开头的用法说明（lfrfid_cli.c）完整覆盖了文档中的全部核心操作：

rfid read <optional: normal | indala> - read in ASK/PSK mode rfid <write | emulate> <key_type> <key_data> - write or emulate a card rfid raw_read <ask | psk> <filename> - read and save raw data to a file rfid raw_emulate <filename> - emulate raw data (helps debug protocols) rfid raw_analyze <filename> - outputs raw data to cli and tries to decode it

各子命令与测试用例的对应关系：

• rfid read：对应 Shared Step [1]，normal/ask等价于 GUI 的 ASK 模式，indala/psk等价于 PSK 模式，不传参数则自动模式（lfrfid_cli.c）；读取成功后输出协议名、十六进制数据和渲染信息；
• rfid write <key_type> <key_data>：对应 Shared Step [4]，key_data为协议数据长度的十六进制串（如 EM4100 为 5 字节），写入结果分Written!/This protocol cannot be written./Seems this fob cannot be written.三种输出（lfrfid_cli.c）；
• rfid emulate <key_type> <key_data>：对应 Shared Step [2]，持续发射直至 Ctrl+C；
• rfid raw_analyze <filename>：对 RAW 文件逐脉冲输出[pulse duration]对并尝试自动识别协议（lfrfid_cli.c），是排查"读取失败/误识别"问题的重要诊断工具。

例如，手动构造并仿真一张 EM4100 卡（数据 5 字节）的完整命令为：

rfid emulate EM4100 0102030405

这些 CLI 通道让测试人员无需进入 GUI 即可验证同一张卡在两种入口下的读取/写入一致性，与文档用例形成互补。

8. 测试执行要点与通过标准汇总

综合全文，执行rfid_test_cases.md时建议遵循以下要点：

1. 测试前置：准备两类硬件——被测 Flipper（安装 Unleashed 固件）、第二台 Flipper 或独立读卡器（建议运行不同固件以增强仿真验证可信度）；准备空白 T5577 空白卡与各协议的原厂卡各一张；
2. 数据一致性是核心判定：所有用例的通过标准最终都归结为"读取信息 / 仿真 ID / 写入后复读数据 / 手动创建数据"四方一致；比对字段以协议渲染出的 FC、Card 等字段为准；
3. 按序覆盖三协议：EM-Marine 4100（Manchester/ASK）、Indala26（PSK）、HID H10301（FSK/ASK）覆盖了三种主流调制方式，是固件解码/编码/写入能力的基本盘；
4. T5577 多协议混写验证：同一张 T5577 上连续写入 3 种不同类型卡片并全部可读，可有效暴露调制配置或块布局错误；
5. 失败定位手段：GUI 复现失败时，用rfid raw_read采集 RAW 波形，再用rfid raw_analyze检查解调器能否识别，可快速区分"天线/硬件问题"与"协议解码问题"。

上述测试体系与 documentation/testing 目录下其他模块的测试用例（如subghz_test_cases.md、nfc_test_cases.md）保持相同的"共享步骤 + 预期结果"方法论，可作为 Flipper Zero 固件回归测试的标准化模板。

【免费下载链接】unleashed-firmwareFlipper Zero Unleashed Firmware项目地址: https://gitcode.com/GitHub_Trending/un/unleashed-firmware