Momentum Firmware NFC 文件格式完全解析：从 UID 头到 Mifare 字典的逐字段详解

Momentum Firmware 将 NFC 卡片的完整数据以纯文本 key: value 形式存储在 SD 卡上，形成一套自洽、可编辑、可版本化的 "Flipper NFC device" 文件格式。本文基于 documentation/file_formats/NfcFileFormats.md 对这套格式的权威定义，逐类讲解通用头、ISO14443 各子协议、NTAG/Ultralight、Mifare Classic、Mifare DESFire 以及两类密钥字典的字段语义、版本演化与底层读写实现，读者可据此手写、修补或解析任意 .nfc 文件。

通用头（UID + Header）：所有格式的公共骨架

NFC 文件由文件头与"设备类型 + UID + 协议专属数据"三部分构成，示例：

Filetype: Flipper NFC device
Version: 4
# Device type can be ISO14443-3A, ISO14443-3B, ISO14443-4A, NTAG/Ultralight, Mifare Classic, Mifare DESFire
Device type: ISO14443-4A
# UID is common for all formats
UID: 04 48 6A 32 33 58 80
-------------------------
(Device-specific data)

• Filetype：固定为 Flipper NFC device，是文件有效性校验的第一道关卡，见 nfc_device.c。
• Version：文件格式版本号（注意与后面 Mifare 相关的 "Data format version" 无关）。它直接决定加载路径：
  • 版本 1：初始版本，已废弃；
  • 版本 2：ATQA 以 LSB 顺序存储（如 44 00 而非 00 44），仍被反向兼容支持，见 nfc_common.h 中 NFC_LSB_ATQA_FORMAT_VERSION = 2 与 NFC_MINIMUM_SUPPORTED_FORMAT_VERSION；
  • 版本 3：ATQA 改为 MSB 顺序（当前字节序）；
  • 版本 4：引入"统一加载流程"，即 NFC_UNIFIED_FORMAT_VERSION（见 nfc_common.h），UID 设备类型被并入 ISO14443-3A 处理。
• Device type：协议标识，取值严格限定为文档所列 6 种字符串。
• UID：所有格式共有。加载时长度上限为 10 字节（NFC_DEVICE_UID_MAX_LEN，见 nfc_device.c），实际合法长度由协议决定（4 或 7 字节）。

底层实现佐证：nfc_device_save() 先写固定头 Flipper NFC device（宏 NFC_FILE_HEADER），再写注释行枚举全部协议名，然后写 Device type 与 UID，最后调用协议专属的 save 回调；加载时 nfc_device_load() 校验头部与版本后，依据版本走 nfc_device_load_legacy()（旧版，逐个协议 verify 探测）或 nfc_device_load_unified()（新版，直接按 Device type 字段匹配协议），完整实现见 nfc_device.c。

ISO14443-3A：UID + ATQA + SAK 三元组

Filetype: Flipper NFC device
Version: 4
Device type: ISO14443-3A
UID: 34 19 6D 41 14 56 E6
# ISO14443-3A specific data
ATQA: 00 44
SAK: 00

该格式仅存储 NFC-A 层参数，不包含卡片内部数据：UID 必须为 4 或 7 字节，ATQA 为 2 字节，SAK 为 1 字节。ATQA（Answer To Request）与 SAK（Select Acknowledge）由 REQA/SEL 应答得到，用于让读卡器识别卡片类型。此格式目前无版本差异。

ISO14443-3B：UID + Application Data + Protocol Info

Filetype: Flipper NFC device
Version: 4
Device type: ISO14443-3B
UID: 30 1D B3 28
# ISO14443-3B specific data
Application data: 00 12 34 FF
Protocol info: 11 81 E1

Type B 卡片（如部分门禁、身份证件）使用与 Type A 不同的防冲突与属性字节：UID 固定 4 字节，Application data 4 字节，Protocol info 3 字节，均为 REQB/ATTRIB 阶段获取的卡片属性。目前无版本差异。

ISO14443-4A：在 3A 之上叠加 ATS

Filetype: Flipper NFC device
Version: 4
Device type: ISO14443-4A
UID: 04 48 6A 32 33 58 80
# ISO14443-3A specific data
ATQA: 03 44
SAK: 20
# ISO14443-4A specific data
ATS: 06 75 77 81 02 80

ISO14443-4A 完全继承 3A 字段（UID/ATQA/SAK），额外增加 ATS（Answer To Select，RATS 命令应答），规定 ATS 不得少于 5 字节。ATS 首字节为长度指示，其后依次为帧格式、TA/TB/TC 等参数，是 Type 4 标签（含银行卡片）进入 ISO 14443-4 传输层的关键数据。目前无版本差异。

NTAG / Ultralight：按页（Page）镜像的存储映像

Filetype: Flipper NFC device
Version: 4
Device type: NTAG/Ultralight
UID: 04 85 90 54 12 98 23
# ISO14443-3A specific data
ATQA: 00 44
SAK: 00
# NTAG/Ultralight specific data
Data format version: 2
NTAG/Ultralight type: NTAG216
Signature: 1B 84 EB 70 BD 4C BD 1B 1D E4 98 0B 18 58 BD 7C 72 85 B4 E4 7B 38 8E 96 CF 88 6B EE A3 43 AD 90
Mifare version: 00 04 04 02 01 00 13 03
Counter 0: 0
Tearing 0: 00
Counter 1: 0
Tearing 1: 00
Counter 2: 0
Tearing 2: 00
Pages total: 231
Pages read: 231
Page 0: 04 85 92 9B
Page 1: 8A A0 61 81
Page 2: CA 48 0F 00
...
Page 228: 00 05 00 00
Page 229: 00 00 00 00
Page 230: 00 00 00 00
Failed authentication attempts: 0

• Data format version：NTAG/Ultralight 子格式版本。版本 1 将 Ultralight 型号直接放在 Device type 字段；版本 2（当前）改为独立的 NTAG/Ultralight type 字段。
• NTAG/Ultralight type：具体型号，枚举包括 Mifare Ultralight、Mifare Ultralight 11、Mifare Ultralight 21、NTAG203、NTAG213、NTAG215、NTAG216、NTAG I2C 1K、NTAG I2C 2K、NTAG I2C Plus 1K、NTAG I2C Plus 2K。不同型号页数不同（如 NTAG216 为 231 页，Pages total: 231）。
• Signature：标签对 READ_SIG 命令的 32 字节应答（见 NXP MF0ULX1 数据手册第 31 页），用于防伪验证。
• Mifare version：标签对 GET_VERSION 命令的应答（数据手册第 21 页），8 字节，描述芯片型号、工艺与批次信息——注意它代表"Ultralight 芯片版本"，与文件格式 Version 无关。
• Counter 0/1/2 与 Tearing 0/1/2：三个一次性计数器及其撕纸（tearing）标志，反映卡片内部不可逆计数状态。
• Page N：卡片存储页的直接逐页镜像，Pages total 与 Pages read 分别记录总页数与本次读取到的页数；读取不完整时 Pages read 会小于 Pages total。
• Failed authentication attempts：若标签启用密码保护（如 Ultralight C 或 NTAG 加锁区），记录认证失败次数。

该字段集合与仓库内置示例 RickRoll.nfc 完全一致（同为 NTAG216、231 页，页 0/页 226-228 的 CC/配置区内容可对照研究），可作为手写或校验文件时的基准样例。

Mifare Classic：按块（Block）存储 + 未知数据 ?? 标记

Filetype: Flipper NFC device
Version: 4
Device type: Mifare Classic
UID: BA E2 7C 9D
# ISO14443-3A specific data
ATQA: 00 02
SAK: 18
# Mifare Classic specific data
Mifare Classic type: 4K
Data format version: 2
# Mifare Classic blocks, '??' means unknown data
Block 0: BA E2 7C 9D B9 18 02 00 46 44 53 37 30 56 30 31
Block 1: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...
Block 3: FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF
...
Block 255: FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF

• Mifare Classic type：1K 或 4K，决定块数（1K 为 64 块，4K 为 256 块）与扇区布局。
• Data format version：Mifare Classic 子格式版本。版本 1（旧）不用 ??，而是用 Key A map / Key B map 两个十六进制位掩码标记每个扇区是否已知 Key A / Key B（每个扇区占 1 位，1K 卡 16 位、4K 卡 40 位，示例中 000000000000FFFF 表示后 4 个扇区的 Key A/B 已知）；版本 2（当前）改为用 ?? 直接表示未知块数据。
• Block N：每块 16 字节十六进制；无法读取（缺少密钥）的块写作 ??。数据按块平铺存储，不区分扇区分组——扇区边界由 Mifare Classic type 隐含。每个扇区的尾部块（如 Block 3、7、255）为扇区 trailer，前 6 字节 Key A、后 6 字节 Key B，示例中 FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF 是典型的出厂默认 Key A/B + 访问位结构。

底层实现佐证：读写逻辑见 mf_classic.c，保存时写入 Mifare Classic type、Data format version 后按 Block %d 逐块写出；加载时先读 Mifare Classic type 再按 Data format version 分支解析（旧版读 Key A/B map，新版处理 ?? 占位）。

Mifare DESFire：按应用（Application）与文件（File）组织

Filetype: Flipper NFC device
Version: 4
Device type: Mifare DESFire
UID: 04 2F 19 0A CD 66 80
# ISO14443-3A specific data
ATQA: 03 44
SAK: 20
# ISO14443-4A specific data
ATS: 06 75 77 81 02 80
# Mifare DESFire specific data
PICC Version: 04 01 01 12 00 1A 05 04 01 01 02 01 1A 05 04 2F 19 0A CD 66 80 CE ED D4 51 80 31 19
PICC Free Memory: 7520
PICC Change Key ID: 00
PICC Config Changeable: true
PICC Free Create Delete: true
PICC Free Directory List: true
PICC Key Changeable: true
PICC Max Keys: 01
PICC Key 0 Version: 00
Application Count: 1
Application IDs: 56 34 12
Application 563412 Change Key ID: 00
Application 563412 Config Changeable: true
...
Application 563412 Key 0 Version: 00
...
Application 563412 File IDs: 01
Application 563412 File 1 Type: 00
Application 563412 File 1 Communication Settings: 00
Application 563412 File 1 Access Rights: EE EE
Application 563412 File 1 Size: 256
Application 563412 File 1: 13 37 00 00 ...

DESFire 采用 PICC → Application → File 三级结构：

• PICC Version：28 字节的 GetVersion 应答，含厂商、硬件/软件版本、UID 等，用于校验卡片真伪。
• PICC Free Memory：剩余可用字节数（示例 7520）。
• PICC Change Key ID / PICC Config Changeable / PICC Free Create Delete / PICC Free Directory List / PICC Key Changeable：PICC 级权限设置与主密钥索引。
• PICC Max Keys 与 PICC Key N Version：PICC 级密钥槽数量及各密钥版本（DES 密钥用版本号参与加解密）。
• Application Count 与 Application IDs：应用数量及 3 字节应用 ID（AID）列表，十六进制展示顺序即 AID 字节序（示例 56 34 12 对应 AID 123456）。
• Application <AID> ...：以 AID 命名的应用级属性，包括密钥槽配置、权限标志与各密钥版本。
• Application <AID> File IDs 与 Application <AID> File N ...：文件 ID 列表及每个文件元数据——Type（标准数据文件/备份文件/值文件等）、Communication Settings（明文/MAC/加密通信）、Access Rights（读写访问权限位，示例 EE EE 表示由密钥 14 控制）、Size、以及文件内容十六进制（示例 256 字节数据，首字节 13 37）。

文档特别给出该卡片的写入来源（proxmark3 命令），可反向理解字段含义：

hf mfdes createapp --aid 123456 --fid 2345 --dfname astra
hf mfdes createfile --aid 123456 --fid 01 --isofid 0001 --size 000100
hf mfdes write --aid 123456 --fid 01 -d 1337

即创建 AID 123456 的应用、在其中创建大小 0x000100（256 字节）的文件、再写入数据 1337。目前无版本差异。

Mifare Classic 字典与 Ultralight C 字典

这两类文件不是设备转储，而是密钥列表，供字典攻击使用：

# Key dictionary from https://github.com/ikarus23/MifareClassicTool.git
# More well known keys!
# Standard keys
FFFFFFFFFF
A0A1A2A3A4A5
D3F7D3F7D3F7
000000000000
# Keys from mfoc
B0B1B2B3B4B5
...

规则：每行一个密钥，表示为十六进制字符串；以 # 开头的行为注释，空行忽略。Mifare Classic 密钥为 6 字节（12 个十六进制字符），常见的出厂与工具默认密钥（FFFFFFFFFFFF、A0A1A2A3A4A5、D3F7D3F7D3F7、全零等）通常排在最前。Ultralight C 字典规则相同，但密钥为 16 字节（32 个十六进制字符），且示例展示了同一口令的多种编码变体（十六进制反转、字节反转、原始 ASCII、Semnox 变体等），说明这类字典常需按厂商口令派生规则准备。

在固件中，这两类字典分别支撑 Mifare Classic 字典攻击（nfc_scene_mf_classic_dict_attack.c）与 Ultralight C 字典攻击（nfc_scene_mf_ultralight_c_dict_attack.c）场景，用户可在 scenes 对应流程中管理、增删密钥。

EMV 资源文件：货币代码 / 国家代码 / AID 名称映射

Filetype: Flipper EMV resources
Version: 1
# EMV currency code: currency name
0997: USN
0994: XSU
0990: CLF
0986: BRL
0985: PLN
0984: BOV
...

用于存储 EMV 相关的货币代码、国家代码或应用标识符（AID）与其名称的映射表：每行一个 十六进制值: 名称 条目，冒号后跟一个空格。Version: 1 为初始版本。固件侧由 nfc_emv_parser.c 负责解析，在读取银行卡片后将其转换为可读的货币/国家名称展示在界面上。

附：文件格式版本速查

文件类型	格式版本	关键演化点
通用头	1 → 4	v1 废弃；v2 ATQA 为 LSB；v3 改 MSB；v4 统一加载、UID 归入 3A
ISO14443-3A / 3B / 4A	无	字段稳定，无版本差异
NTAG/Ultralight	1 → 2	v1 型号写在 Device type；v2 独立 NTAG/Ultralight type 字段
Mifare Classic	1 → 2	v1 用 Key A/B map 位掩码；v2 用 ?? 标记未知块
Mifare DESFire	无	字段稳定，无版本差异
EMV 资源	1	初始版本

上述版本常量在 nfc_common.h 中有精确对应：NFC_LSB_ATQA_FORMAT_VERSION = 2、NFC_MINIMUM_SUPPORTED_FORMAT_VERSION = 2、NFC_UNIFIED_FORMAT_VERSION = 4、NFC_CURRENT_FORMAT_VERSION = 4。实际阅读 .nfc 文件时，先看 Version 与 Data format version 两个数字，即可确定解析规则分支，这是手工解析本套格式最关键的第一步。