Research, development and trades concerning the powerful Proxmark3 device.
Remember; sharing is caring. Bring something back to the community.
"Learn the tools of the trade the hard way." +Fravia
You are not logged in.
Time changes and with it the technology
Proxmark3 @ discord
Users of this forum, please be aware that information stored on this site is not private.
I'm currently working on these cards used for payment in a variety of applications, branded "FlashCash". `lf search` and `hf search` do not detect any known cards, although occasionally CC and CSN data will appear mixed into the output. The readers had absolutely no response when I presented a variety of different LF and HF cards. The HF tuning voltage dropped by around 10V when the card was placed on my PM3.
The cards have a 9 digit decimal number printed on them, and store a cash balance (some readers were offline but still displayed balance and card number). Reading occurs almost instantly, but I don't know if that's evidence for no encryption being used.
Does anyone know what my next steps should be, or has encountered these before?
Offline
cc/csn.. Sounds like a iClass based card.
Offline
Very rarely I'll get this output:
[usb] pm3 --> hf search
[=] Checking for known tags...
[/] Searching for iClass / PicoPass tag... CSN: 22 AF EA 05 09 00 12 E0
CC: 22 01 FC FE FF FF FF FF
[-] No known/supported 13.56 MHz tags found
Most of the time I get this:
[usb] pm3 --> hf search
[=] Checking for known tags...
[-] Searching for ThinFilm tag...[!] timeout while waiting for reply.
[\] Searching for ISO14443-B tag...UART:: write time-out
UART:: write time-out
UART:: write time-out
[|] Searching for iClass / PicoPass tag...UART:: write time-out
[=] You can cancel this operation by pressing the pm3 button
[-] No known/supported 13.56 MHz tags found
[usb] pm3 --> UART:: write time-out
The iclass commands don't appear to return anything.
[usb] pm3 --> hf iclass info
[usb] pm3 --> hf iclass list
UART:: write time-out
Waiting for a response from the Proxmark3...
You can cancel this operation by pressing the pm3 button
[-] Timed out while trying to download data from device
[!] timeout while waiting for reply.
[usb] pm3 --> hf iclass rdbl b 0A k 0 v
[+] Using key[0] AE A6 84 A6 DA B2 32 78
[!] command execute timeout
[-] selecting tag failed
#db# Trigger kicked! Value: 111, Dumping Samples Hispeed now.
#db# HF Sniffing end
[+] CSN | 01 00 48 46 20 53 6E 69
[+] CCNR | 64 20 56 61 6C 75 65 3A
[+] authing with diversified key: 0A 4D 59 9E 21 A4 37 82
[-] authentication error
[!] command execute timeout
[-] selecting tag failed
[!] command execute timeout
[-] selecting tag failed
[!] command execute timeout
[-] selecting tag failed
Are there any lower-level debugging commands I could use to try and confirm that it is an IClass?
Last edited by chocol4te (2019-09-20 12:44:52)
Offline
I updated to the latest master branch and now
hf search
has some new output.
[usb] pm3 --> hf search
[=] Checking for known tags...
[\] Searching for iClass / PicoPass tag... CSN: 22 AF EA 05 09 00 12 E0
CC: 22 01 FC FE FF FF FF FF
Mode: Application [Locked]
Coding: ISO 14443-2 B/ISO 15693
[+] Crypt: Secured page, keys not locked
[!] RA: Read access not enabled
Mem: 2 KBits/2 App Areas (31 * 8 bytes) [1F]
AA1: blocks 06-1A
AA2: blocks 1B-1F
OTP: 0xFFFF
KeyAccess:
Read A - Kd or Kc
Read B - Kd or Kc
Write A - Kc
Write B - Kc
Debit - Kd or Kc
Credit - Kc
App IA: 47 49 46 4C 41 53 48 31
[!] : Possible iClass (NOT legacy tag)
[-] No known/supported 13.56 MHz tags found
hf iclass reader
shows the following repeatedly, with the read status varying on occasion.
[=] Readstatus:1e
CSN: 22 AF EA 05 09 00 12 E0
CC: 22 01 FC FE FF FF FF FF
Mode: Application [Locked]
Coding: ISO 14443-2 B/ISO 15693
[+] Crypt: Secured page, keys not locked
[!] RA: Read access not enabled
Mem: 2 KBits/2 App Areas (31 * 8 bytes) [1F]
AA1: blocks 06-1A
AA2: blocks 1B-1F
OTP: 0xFFFF
KeyAccess:
Read A - Kd or Kc
Read B - Kd or Kc
Write A - Kc
Write B - Kc
Debit - Kd or Kc
Credit - Kc
App IA: 47 49 46 4C 41 53 48 31
[!] : Possible iClass (NOT legacy tag)
Offline
Sorry for all the messages, I've made more progress.
[usb] pm3 --> hf iclass chk f ./client/dictionaries/iclass_default_keys.dic
[+] loaded 7 keys from dictionary file ./client/dictionaries/iclass_default_keys.dic
[+] Reading tag CSN
[!] one more try
[!] one more try
[+] Generating diversified keys
[+] Searching for DEBIT key
[+] Tag info
[+] CSN | 22 AF EA 05 09 00 12 E0
[+] CCNR | 22 01 FC FE FF FF FF FF 00 00 00 00
[-] Chunk [0/7] : 0.9s [debit]
[+] Time in iclass checkkeys: 3 seconds
[usb] pm3 --> hf iclass chk c f ./client/dictionaries/iclass_default_keys.dic
[+] loaded 7 keys from dictionary file ./client/dictionaries/iclass_default_keys.dic
[+] Reading tag CSN
[+] Generating diversified keys
[+] Searching for CREDIT key
[+] Tag info
[+] CSN | 22 AF EA 05 09 00 12 E0
[+] CCNR | 22 01 FC FE FF FF FF FF 00 00 00 00
[-] Chunk [0/7] : 0.9s [credit]
[+] Time in iclass checkkeys: 2 seconds
So if the key is not in the dictionary, can I sniff it? If so, is it just "hf iclass sniff", then press the button after the transaction?
Offline
Your "FlashCash" card is definitely an iclass credential based on the CSN value you captured (22 AF EA 05 09 00 12 E0).
However, it appears that your card uses a non-standard set of AA1 and AA2 authentication keys.
Typically when HID iclass credentials are used in cashless vending applications the vendor loads a unique AA2 authentication key into Block 4 and overrides the default HID AA2 key. This is used to secure the contents of the e-purse (Blk 2).
According to your University's website, your "FlashCash" card is also used for physical access control in addition to cashless vending. Based on the information you provided above it appears that the access control information (stored in AA1) does not use the HID master Authentication key.
I would guess that your university is participating in the HID Elite program whereby AA1 is assigned to use a high security authentication key.
If so, you may be able to utilize the PM3 "sim 2" and "loclass" functions to obtain the required key.
It is also interesting to note that the Application Issuer data stored in Block 5 contains the following:
47 49 46 4C 41 53 48 31 (ASCII "GIFLASH1")
I have never seen custom data programmed in this data block.
I don't believe that the HID CP1000 programmer allows this data block to be custom programmed which would indicate that your cards are very unique and likely have been programmed at the HID factory for a very special (or secure) purpose. This may mean that your credentials may not be vulnerable to any type of attack that the PM3 currently supports.
Last edited by carl55 (2019-09-20 19:25:06)
Offline
Thank you for your help!
I ran "hf iclass sim 2" several times against a reader, resulting in a few 216 byte files, none of which work when input into "hf iclass loclass". I'm noticing they are different to the provided (and working) "iclass_dump.bin" in that the 8 byte CC is "FEFFFFFF FFFFFFFF" whereas in "iclass_dump.bin" it is "00000000 00000000". Is this significant?
The output at the end of "hf iclass loclass" is the same for all the dump files:
[!] Failed to recover 3 bytes using the following CSN
[!] CSN = 01 0A 0F FF F7 FF 12 E0
I have 5 dump files now, from the same reader attached to the machine that adds value. Is collecting more a good idea? Does finding different readers (subtracting value) help?
Thanks again!
Last edited by chocol4te (2019-09-20 21:59:45)
Offline
A card challenge value of "000000000 00000000" is not a valid value. The CC (aka e-purse, aka Block 2) starts out with "FEFFFFFF FFFFFFFF" as the default factory value and gets modified each time the reader authenticates with the credential. This Block 2 update was never enforced in the older (Rev A,B,C) readers but is strictly enforced by the newer SE readers.
The CC (Blk2) value shown in your earlier posts (22 01 FC FE FF FF FF FF)appears to have been read correctly then since that looks like a valid value for a credential that has been authenticated a significant number of times.
The CC value is very important to the authentication sequence since its value is an important parameter in the cipher algorithm used to calculate the MAC response. A CC value of all 0's in the iclass_dump.bin file appears to be incorrect.
Offline
[moved]
I got curious on this tag.
When you run the reader attack, would you mind posting the trace list you get?
hf iclass sim 2
hf iclass list
Offline
Apologies for the delay:
[usb] pm3 --> hf iclass sim 2
[=] Starting iCLASS sim 2 attack (elite mode)
[=] press Enter to cancel
#db# [+] going into attack mode, 9 CSNS sent
#db# [+] CSN: 01 .... e0 OK
#db# [+] CSN: 0c .... e0 OK
#db# [+] CSN: 10 .... e0 OK
#db# [+] CSN: 13 .... e0 OK
#db# [+] CSN: 07 .... e0 OK
#db# [+] CSN: 14 .... e0 OK
#db# [+] CSN: 17 .... e0 OK
#db# [+] CSN: ce .... e0 OK
#db# [+] CSN: d2 .... e0 OK
[+] 9 out of 9 MAC obtained [OK]
[+] saved 216 bytes to binary file iclass_mac_attack.bin
[usb] pm3 --> hf iclass list
[+] Recorded Activity (TraceLen = 1284 bytes)
[=]
Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer
iClass - Timings are not as accurate
Start | End | Src | Data (! denotes parity error) | CRC | Annotation
------------+------------+-----+-------------------------------------------------------------------------+-----+--------------------
0 | 10736 | Rdr |0a | | ACTALL
77277616 | 77333024 | Tag |0f | |
77278080 | 77279376 | Rdr |0c | | IDENTIFY
77290448 | 77335760 | Tag |40 e1 e1 ff fe 5f 02 3c 43 01 | ok |
77293648 | 77332960 | Rdr |8e | | ACT
77359728 | 77366720 | Rdr |0a | | ACTALL
78508016 | 78512688 | Tag |0f | |
78508496 | 78524432 | Rdr |0c | | IDENTIFY
78520736 | 78580880 | Tag |40 e1 e1 ff fe 5f 02 3c 43 01 | ok |
78523872 | 78556000 | Rdr |81 40 e1 e1 ff fe 5f 02 3c | | SELECT
78567680 | 78580848 | Tag |01 0a 0f ff f7 ff 12 e0 62 75 | ok |
78570784 | 78590784 | Rdr |88 02 | | READCHECK[Kd](2)
78649392 | 78711392 | Tag |fe ff ff ff ff ff ff ff | ok |
78651968 | 78690016 | Rdr |05 24 26 01 1c 61 79 ec 77 | | CHECK
128 | 13152 | Rdr |0a | | ACTALL
209824 | 262688 | Tag |0f | |
210288 | 274448 | Rdr |0c | | IDENTIFY
222544 | 265344 | Tag |c1 80 c1 ff fe 5f 02 9c 24 50 | ok |
225664 | 240480 | Rdr |81 c1 80 c1 ff fe 5f 02 9c | | SELECT
269472 | 330848 | Tag |0c 06 0c fe f7 ff 12 e0 1c 79 | ok |
272560 | 275136 | Rdr |88 02 | | READCHECK[Kd](2)
351040 | 395936 | Tag |fe ff ff ff ff ff ff ff | ok |
353680 | 374512 | Rdr |05 3f bc f5 65 a0 6a af 47 | | CHECK
128 | 11120 | Rdr |0a | | ACTALL
207776 | 262688 | Tag |0f | |
208240 | 208912 | Rdr |0c | | IDENTIFY
220480 | 265360 | Tag |e2 72 70 ef fe 5f 02 1c ff 3a | ok |
223616 | 240480 | Rdr |81 e2 72 70 ef fe 5f 02 1c | | SELECT
267424 | 330848 | Tag |10 97 83 7b f7 ff 12 e0 2d 21 | ok |
270512 | 275280 | Rdr |88 02 | | READCHECK[Kd](2)
349120 | 395888 | Tag |fe ff ff ff ff ff ff ff | ok |
351712 | 374512 | Rdr |05 76 8f 21 99 31 e6 65 ef | | CHECK
128 | 11744 | Rdr |0a | | ACTALL
208416 | 262688 | Tag |0f | |
208880 | 209040 | Rdr |0c | | IDENTIFY
221248 | 265424 | Tag |e2 52 50 ef fe 5f 02 7c 1a bf | ok |
224448 | 240496 | Rdr |81 e2 52 50 ef fe 5f 02 7c | | SELECT
268272 | 330848 | Tag |13 97 82 7a f7 ff 12 e0 92 a4 | ok |
271360 | 275120 | Rdr |88 02 | | READCHECK[Kd](2)
349824 | 395952 | Tag |fe ff ff ff ff ff ff ff | ok |
352480 | 374512 | Rdr |05 dd 1f 86 d0 58 92 2e 1f | | CHECK
128 | 11104 | Rdr |0a | | ACTALL
207776 | 262736 | Tag |0f | |
208288 | 208912 | Rdr |0c | | IDENTIFY
220528 | 265360 | Tag |c0 a1 21 ff fe 5f 02 fc d8 cc | ok |
223664 | 240512 | Rdr |81 c0 a1 21 ff fe 5f 02 fc | | SELECT
267504 | 330832 | Tag |07 0e 0d f9 f7 ff 12 e0 6b 34 | ok |
270576 | 275024 | Rdr |88 02 | | READCHECK[Kd](2)
348928 | 395872 | Tag |fe ff ff ff ff ff ff ff | ok |
351504 | 374384 | Rdr |05 59 f5 20 47 a2 e3 a6 96 | | CHECK
128 | 12000 | Rdr |0a | | ACTALL
208672 | 262624 | Tag |0f | |
209072 | 274560 | Rdr |0c | | IDENTIFY
221424 | 265424 | Tag |c2 92 d0 ee fe 5f 02 9c 19 a1 | ok |
224624 | 240496 | Rdr |81 c2 92 d0 ee fe 5f 02 9c | | SELECT
268448 | 330848 | Tag |14 96 84 76 f7 ff 12 e0 83 c8 | ok |
271536 | 275376 | Rdr |88 02 | | READCHECK[Kd](2)
350256 | 395968 | Tag |fe ff ff ff ff ff ff ff | ok |
352928 | 374368 | Rdr |05 ab e6 9d 2e 88 8e 6d 29 | | CHECK
128 | 11376 | Rdr |0a | | ACTALL
208048 | 262608 | Tag |0f | |
208432 | 209040 | Rdr |0c | | IDENTIFY
220800 | 265424 | Tag |c2 b2 30 ee fe 5f 02 fc 8f 23 | ok |
224000 | 240480 | Rdr |81 c2 b2 30 ee fe 5f 02 fc | | SELECT
267824 | 330816 | Tag |17 96 85 71 f7 ff 12 e0 a4 76 | ok |
270880 | 275008 | Rdr |88 02 | | READCHECK[Kd](2)
349232 | 395856 | Tag |fe ff ff ff ff ff ff ff | ok |
351792 | 374384 | Rdr |05 85 df 28 66 9e 48 e2 55 | | CHECK
128 | 11488 | Rdr |0a | | ACTALL
208160 | 262624 | Tag |0f | |
208560 | 209024 | Rdr |0c | | IDENTIFY
220928 | 265408 | Tag |b9 f8 e1 ee fe 5f 02 dc 21 42 | ok |
224112 | 240624 | Rdr |81 b9 f8 e1 ee fe 5f 02 dc | | SELECT
268064 | 330912 | Tag |ce c5 0f 77 f7 ff 12 e0 59 e2 | ok |
271216 | 275392 | Rdr |88 02 | | READCHECK[Kd](2)
349952 | 395952 | Tag |fe ff ff ff ff ff ff ff | ok |
352608 | 374384 | Rdr |05 85 c7 aa 24 20 8d 73 59 | | CHECK
128 | 12000 | Rdr |0a | | ACTALL
208672 | 262688 | Tag |0f | |
209136 | 274448 | Rdr |0c | | IDENTIFY
221376 | 265360 | Tag |5a 4b 10 ff fe 5f 02 5c af d7 | ok |
224512 | 240624 | Rdr |81 5a 4b 10 ff fe 5f 02 5c | | SELECT
268464 | 330912 | Tag |d2 5a 82 f8 f7 ff 12 e0 b7 78 | ok |
271616 | 275120 | Rdr |88 02 | | READCHECK[Kd](2)
350064 | 395968 | Tag |fe ff ff ff ff ff ff ff | ok |
352736 | 374368 | Rdr |05 1a 4b 6d 16 16 dc 96 27 | | CHECK
[usb] pm3 -->
Offline
No luck with lookup either
[usb] pm3 --> hf iclass lookup u 010A0FFFF7FF12E0 p FEFFFFFFFFFFFFFF m 2426011C6179EC77 f client/dictionaries/iclass_default_keys.dic
[+] CSN | 01 0A 0F FF F7 FF 12 E0
[+] Epurse | FE FF FF FF FF FF FF FF
[+] MACS | 24 26 01 1C 61 79 EC 77
[+] CCNR | FE FF FF FF FF FF FF FF 24 26 01 1C
[+] MAC_TAG | 61 79 EC 77
[+] loaded 7 keys from dictionary file client/dictionaries/iclass_default_keys.dic
[=] Generating diversified keys
[=] Sorting
[=] Searching
Time in iclass : 0 seconds
[usb] pm3 -->
Offline
Should my next step be to sniff an interaction between the reader and my card? Or is this a dead end
Thanks so much for you help by the way, I know it can be annoying to deal with noobs...
Offline
Small update, it doesn't look like the reader is modifying CC, so that means it's an older/vulnerable model?
Last edited by chocol4te (2019-09-24 16:29:59)
Offline
Tried sniffing but got this:
#db# [-] bad ED at 0:0
#db# [-] bad BB at 0:0
#db# [-] bad BD at 0:0
#db# [-] bad 97 at 0:2
#db# [-] bad E7 at 0:0
#db# [-] bad E6 at 0:0
#db# [-] bad 6F at 0:0
#db# [-] bad 7B at 0:0
#db# [-] bad F3 at 0:0
#db# [-] bad 7B at 0:0
#db# [-] bad 97 at 0:0
#db# [-] bad 6F at 0:0
#db# [-] bad B9 at 0:0
#db# [-] bad 37 at 0:0
#db# [-] bad 37 at 0:0
#db# [-] bad 2F at 0:0
#db# [-] bad 73 at 0:0
#db# [-] bad 7E at 0:0
#db# [-] bad 79 at 0:0
#db# [-] bad 7B at 0:0
#db# [-] bad F3 at 0:0
#db# [-] bad FF at 0:0
#db# [-] bad F3 at 0:0
#db# [-] bad FF at 0:0
Offline
Disappointing development, I topped up, then paid twice, and now I'm getting a very different CC value.
Before:
CSN: 22 AF EA 05 09 00 12 E0
CC: 22 01 FC FE FF FF FF FF
After:
CSN: 22 AF EA 05 09 00 12 E0
CC: FF FF FF FF DC 00 FB FE
Offline
That CC value looks normal to me.
Don't forget that the e-purse value is really only a 32-bit number. The picopass chipset toggles the value between the upper and lower 32-bits each time it is decremented.
That feature is by design in order to ensure that the contents never get corrupted during an update. The unused half gets the new (updated) value and then the older half gets deleted but only after the new value has been successfully written into memory.
In your specific case, the amount that your FlashCash card e-purse was decremented is determined by the amount of your purchase.
Offline
Ahh, okay, that makes sense then
Is there anything else I can try to get AA1?
Offline