Open Luisdp67 opened 1 year ago
I forgot to mention that I am the administrator of a system that uses these types of cards, so I have blank cards that I can activate and deactivate at will and snort the corresponding traffic.
However, I do not have access to the locks in which the cards will be used as they are outside my location.
Good morning.
Since no one says anything, I continue.
From what I have been able to find out, it is a Mifare 2K Plus card that is at security level SL1.
These types of cards have 32 sectors (although they only show 18) and have AES encryption whose keys are not shown in the memory map. They are tree 16-byte keys (CardConfigKey, CardMasterKey and L3SwitchKey).
Originally, these cards must be activated and are at security level SL0. That is when you can write block 0, enter the AES keys and have access to all 32 sectors.
Then the card is sent a command that passes it to security level SL1 or SL3 and the security level can no longer be lowered. At these levels, the card behaves like a Mifare Classic 1K except for the fact that it can show sector 17 and evidence the existence of sector 16.
The new cards that I have already come at SL1 level and I have not found any place that sells them blank at SL0 level. If someone knows him and wants to tell me, I will do many more tests.
All the best.
I am also having the exact same problem. I have a card labeled "G+D Mifare Classic EV1 1k" and I have successfully obtained all of the keys with Autopwn, but I only get a partial dump. It also has sectors 16 and 17, and based on the above comments, it seems like my sectors 16 and 17 have the exact same keys for both a and b. Another peculiar problem I have had is reading sectors with the keys after the autopwn. If I use chk with my a or b keys for all sectors 0-17, it works fine:
`[usb] pm3 --> hf mf chk -b -k (WORKING KEY B) [=] [ 0] key (WORKING KEY B) [=] Start check for keys... [=] ................................. [=] time in checkkeys 9 seconds
[=] testing to read key B...
[+] found keys:
[+] -----+-----+--------------+---+--------------+---- [+] Sec | Blk | key A |res| key B |res [+] -----+-----+--------------+---+--------------+---- [+] 000 | 003 | ------------ | 0 | (WORKING KEY B) | 1 [+] 001 | 007 | ------------ | 0 | (WORKING KEY B) | 1 [+] 002 | 011 | ------------ | 0 | (WORKING KEY B) | 1 [+] 003 | 015 | ------------ | 0 | (WORKING KEY B) | 1 [+] 004 | 019 | ------------ | 0 | (WORKING KEY B) | 1 [+] 005 | 023 | ------------ | 0 | (WORKING KEY B) | 1 [+] 006 | 027 | ------------ | 0 | (WORKING KEY B) | 1 [+] 007 | 031 | ------------ | 0 | (WORKING KEY B) | 1 [+] 008 | 035 | ------------ | 0 | (WORKING KEY B) | 1 [+] 009 | 039 | ------------ | 0 | (WORKING KEY B) | 1 [+] 010 | 043 | ------------ | 0 | (WORKING KEY B) | 1 [+] 011 | 047 | ------------ | 0 | (WORKING KEY B) | 1 [+] 012 | 051 | ------------ | 0 | (WORKING KEY B) | 1 [+] 013 | 055 | ------------ | 0 | (WORKING KEY B) | 1 [+] 014 | 059 | ------------ | 0 | (WORKING KEY B) | 1 [+] 015 | 063 | ------------ | 0 | (WORKING KEY B) | 1 [+] -----+-----+--------------+---+--------------+---- [+] ( 0:Failed / 1:Success )` The key works for sectors 0-15 (although it doesn't check for 16 and 17 since usually there is no 16/17). If I use the same command, but I target only for block 3, it also shows it being a valid key: '[usb] pm3 --> hf mf chk -b --1k --tblk 3 -k (WORKING KEY B) [=] [ 0] key (WORKING KEY B) [=] Start check for keys... [=] .. [=] time in checkkeys 0 seconds
[+] found keys:
[+] -----+-----+--------------+---+--------------+---- [+] Sec | Blk | key A |res| key B |res [+] -----+-----+--------------+---+--------------+---- [+] 000 | 003 | ------------ | 0 | (WORKING KEY B) | 1 [+] -----+-----+--------------+---+--------------+---- [+] ( 0:Failed / 1:Success )' So that works too. Here's where the weird part is, if I try targeting any other blocks with this command (other than 0-3), even ones that supposedly worked when I ran "chk" on the whole card, it doesn't see it as a valid key: '[usb] pm3 --> hf mf chk -b --1k --tblk 7 -k (WORKING KEY B) [=] [ 0] key (WORKING KEY B) [=] Start check for keys... [=] .. [=] time in checkkeys 0 seconds
[+] found keys:
[+] -----+-----+--------------+---+--------------+---- [+] Sec | Blk | key A |res| key B |res [+] -----+-----+--------------+---+--------------+---- [+] 001 | 007 | ------------ | 0 | ------------ | 0 [+] -----+-----+--------------+---+--------------+---- [+] ( 0:Failed / 1:Success )' Here I used block 7, but ANY other blocks fail the chk, even ones that supposedly worked when I ran the full-card chk. I have a few other weird things with this card specifically, but I don't want to overwhelm anyone with more of the info I've gathered regarding this specific card. Please let me know if more of that info would help.
Hi.
Indeed these are Mifare Plus 2K cards. I guess yours will be at SL1 security level (hf mfp info). In this state the card behaves like a Mifare Classic 1K but has little to do with it in reality.
"So that works too. Here's where the weird part is, if I try targeting any other blocks with this command (other than 0-3), even ones that supposedly worked when I ran "chk" on the whole card, it doesn't see it as a valid key:"
Have you tried reading blocks with the rdbl command?
Mifare Plus cards use AES encryption using any keys that are stored in a special memory area (4000, 9000, 9001, 9002 and 9003). In my opinion the only way to copy these cards would be to have a Mifare Plus in SL0 state, but it would still be necessary to know how to extract the AES keys.
This is the official repo but not that many uses it.
You can test https://github.com/rfidresearchgroup/proxmark3 and see if you find it to work better with your MF Plus cards.
@Luisdp67 Hello, Thanks for the response. That is odd that it seems to be a 2k card despite "1k" being written on the physical card itself, but with the two extra sectors I guess it makes sense. When I use "hf mf autopwn --2k" It goes through the normal autopwn for sectors 0-17, and then I keep getting "[#] AcquireEncryptedNonces: Auth2 error len=1" errors when it tries to hardnested attack outside of sectors 0-17.
Regarding your comment on using the rdbl command, I have another weird quirk to share. When I open the partial dump file created by autopwn, it shows this:
`[usb] pm3 --> hf mf view -f hf-mf-key-dump-006.json [+] loaded from JSON file D:\OneDrive\Desktop\ProxSpace\ProxSpace\pm3/hf-mf-Key-dump-006.json
[=] -----+-----+-------------------------------------------------+----------------- [=] sec | blk | data | ascii [=] -----+-----+-------------------------------------------------+----------------- [=] 0 | 0 | E6 84 87 F3 16 88 04 00 46 8E 45 55 4D 70 41 04 | ........F.EUMpA. [=] | 1 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 2 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 3 | 6E 9D FC 47 9F A1 04 00 46 8E 6F B5 41 34 83 4C | n..G....F.o.A4.L [=] 1 | 4 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 5 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 6 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 7 | 6E 9D FC 47 9F A1 00 00 00 00 6F B5 41 34 83 4C | n..G......o.A4.L [=] 2 | 8 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 9 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 10 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 11 | 6E 9D FC 47 9F A1 00 00 00 00 6F B5 41 34 83 4C | n..G......o.A4.L [=] 3 | 12 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 13 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 14 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 15 | 6E 9D FC 47 9F A1 04 00 46 8E 6F B5 41 34 83 4C | n..G....F.o.A4.L [=] 4 | 16 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 17 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 18 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 19 | 6E 9D FC 47 9F A1 00 00 00 00 6F B5 41 34 83 4C | n..G......o.A4.L [=] 5 | 20 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 21 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 22 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 23 | 6E 9D FC 47 9F A1 00 00 00 00 6F B5 41 34 83 4C | n..G......o.A4.L [=] 6 | 24 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 25 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 26 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 27 | 6E 9D FC 47 9F A1 00 00 00 00 6F B5 41 34 83 4C | n..G......o.A4.L [=] 7 | 28 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 29 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 30 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 31 | 6E 9D FC 47 9F A1 00 00 00 00 6F B5 41 34 83 4C | n..G......o.A4.L [=] 8 | 32 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 33 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 34 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 35 | 6E 9D FC 47 9F A1 00 00 00 00 6F B5 41 34 83 4C | n..G......o.A4.L [=] 9 | 36 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 37 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 38 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 39 | 6E 9D FC 47 9F A1 00 00 00 00 6F B5 41 34 83 4C | n..G......o.A4.L [=] 10 | 40 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 41 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 42 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 43 | 6E 9D FC 47 9F A1 00 00 00 00 6F B5 41 34 83 4C | n..G......o.A4.L [=] 11 | 44 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 45 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 46 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 47 | 6E 9D FC 47 9F A1 00 00 00 00 6F B5 41 34 83 4C | n..G......o.A4.L [=] 12 | 48 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 49 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 50 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 51 | 6E 9D FC 47 9F A1 00 00 00 00 6F B5 41 34 83 4C | n..G......o.A4.L [=] 13 | 52 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 53 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 54 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 55 | 6E 9D FC 47 9F A1 00 00 00 00 6F B5 41 34 83 4C | n..G......o.A4.L [=] 14 | 56 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 57 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 58 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 59 | 6E 9D FC 47 9F A1 00 00 00 00 6F B5 41 34 83 4C | n..G......o.A4.L [=] 15 | 60 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 61 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 62 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ [=] | 63 | 6E 9D FC 47 9F A1 04 00 46 8E 6F B5 41 34 83 4C | n..G....F.o.A4.L [=] -----+-----+-------------------------------------------------+----------------- [?] cyan = value block with decoded value`
And yet when I try and use rdbl on block 3, I get a completely different set of data compared to the autopwn data:
`[usb] pm3 --> hf mf rdbl --blk 3 -k (WORKING KEY A)
[=] # | sector 00 / 0x00 | ascii [=] ----+-------------------------------------------------+----------------- [=] 3 | 00 00 00 00 00 00 00 F8 7F 00 00 00 00 00 00 00 | ................`
It also refuses to read block 0 even with the key that is supposed to be able to read block 0.
When I run "hf mfp info" I find that it indeed looks like a 2k card:
[=] --- Fingerprint [=] SIZE: 2K (7 UID) [=] SAK: 2K 7b UID [=] --- Security Level (SL) [+] SL mode: SL1
It also talks about optional AES encryption. From the place my card is from, I wouldn't be surprised it it has the AES encryption turned on. Is there any way to possibly break that encryption with the normal Proxmark3 fork that @iceman1001 suggested? (BTW, thanks for what you do Iceman!)
Hi, Sullyboy12177.
"Hello, Thanks for the response. That is odd that it seems to be a 2k card despite "1k" being written on the physical card itself, but with the two extra sectors I guess it makes sense. When I use "hf mf autopwn --2k" It goes through the normal autopwn for sectors 0-17, and then I keep getting "[#] AcquireEncryptedNonces: Auth2 error len=1" errors when it tries to hardnested attack outside of sectors 0-17."
TRUE; That's right, but that doesn't mean there aren't 32 sectors.
"And yet when I try and use rdbl on block 3, I get a completely different set of data compared to the autopwn data:"
That doesn't happen on my cards. It is normal for rdbl to hide the keys that are in sector 3 (trailer), maybe it's an autopwn error, or not, but you can test which access conditions are met:
usb] pm3 --> hf mf acl -d 040046
[!!] Invalid Access Conditions, NEVER write these on a card!
[=] # | Access rights [=] ----+----------------------------------------------------------------- [=] 0 | read AB; write AB; increment AB; decrement transfer restore AB [=] 1 | read AB [=] 2 | read B; write B [=] 3 | read A by A; read ACCESS by A; read/write B by A
[usb] pm3 --> hf mf acl -d 00F87F
[=] # | Access rights [=] ----+----------------------------------------------------------------- [=] 0 | none [=] 1 | none [=] 2 | none [=] 3 | read ACCESS by AB
"It also talks about optional AES encryption. From the place my card is from, I wouldn't be surprised it it has the AES encryption turned on. Is there any way to possibly break that encryption with the normal Proxmark3 fork that @iceman1001 suggested? (BTW, thanks for what you do Iceman!)"
I don't know. We will have to investigate to see ...
Regards
This is the official repo but not that many uses it.
You can test https://github.com/rfidresearchgroup/proxmark3 and see if you find it to work better with your MF Plus cards.
Thank you very much, Iceman, and thank you for your work.
Best regards
Edit: Fixed: It was a reading error
????? [usb] pm3 --> hf mfp chk -d mfp_default_keys -s0 -e64 [+] loaded 1024 keys from dictionary file C:\ProxSpace\pm3\proxmark3-master\client\dictionaries/mfp_default_keys.dic [=] Loaded 26 keys [=] Search keys .RRRREd.RRRREd.RRRREd.RRRREd.RRRREd.RRRREd.RRRREd.RRRREd.RRRREd.RRRREd.RRRREd.RRRREd.RRRREd.RRRREd.RRRREd.RRRRE
[=] -------+--------------------------------+--------------------------------- [=] |sector| key A | key B | [=] |------+--------------------------------+--------------------------------| [=] | 64 | ------ |00000000000000000000000000000000| [=] '------+--------------------------------+--------------------------------'
[usb] pm3 --> hf mfp rdsc -s 64 --key 00000000000000000000000000000000
[!!]
Hi Iceman:
[usb] pm3 --> hf mfp chk -d mfp_default_keys [+] loaded 1024 keys from dictionary file C:\ProxSpace\pm3\proxmark3\client\dictionaries/mfp_default_keys.dic [=] Loaded 26 keys [=] Search keys .RRRREd.RRRREd.RRRREd.RRRREd.RRRREd.RRRREd.RRRREd.RRRREd.RRRREd.RRRREd.RRRREd.RRRREd.RRRREd.RRRREd.RRRREd.RRRRE [=] No keys found(
Any other possibilities?
Thanks,
Regards
Hi again.
I have finally been able to clone a card and it works perfectly. Apparently this system does not make use of AES encryption and does not verify the signature.
I would still like to know how you can get to "read" AES keys stored in 4000 and 900x, please.
Regards
0 sector 0block 46 9C 48 34 A6 88 04 00 C8 52 00 20 00 00 00 18 1block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3block FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF
1 sector 0block F7 32 41 2D 99 1A 73 CE 68 E2 E6 90 B2 3E DF 3B 1block F6 CF 44 D7 7D A0 C7 D6 9D 31 B1 66 A3 9F 89 97 2block 1C C4 1E 05 E2 DA C7 0E 77 16 9B E1 1B 8A 27 D8 3block 05 CE D3 A5 F1 B2 7F 07 88 00 E7 31 68 53 E7 31
2 sector 0block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3block FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF
3 sector 0block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3block FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF
4 sector 0block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3block FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF
5 sector 0block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3block FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF
6 sector 0block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3block FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF
7 sector 0block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3block FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF
8 sector 0block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3block FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF
9 sector 0block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3block FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF
10 sector 0block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3block FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF
11 sector 0block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3block FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF
12 sector 0block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3block FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF
13 sector 0block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3block FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF
14 sector 0block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3block FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF
15 sector 0block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3block FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF
16 sector 0block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2block 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3block 5C 8F F9 99 0D A2 FF 07 80 69 D0 1A FE EB 89 0A
17 sector 0block 41 53 4C 36 34 33 0F 52 18 EF 9A 04 00 00 00 00 1block EC E3 8B 9F 14 6C B6 D6 49 72 90 D7 2D DA 37 61 2block 85 3D C5 43 90 CC A9 89 65 D3 14 D9 D1 AD 5C 7B 3block 75 CC B5 9C 9B ED 70 F0 F8 69 4B 79 1B EA 7B CC
Mifare Plus EV1 (Desfire) 2k ?
@Luisdp67 I have the similar situation. Would you mind explain how you were able to clone your key?
@Luisdp67 Hi hi I too face the similar tag with extra sectors....may I know how did you succeed in copying it?
Thank you!
Hi Luisdp67,
Having the exact same issue here!! I used proxmark3 (Easy) to do an autopwn....it gave me 18 keys with keys 16 and 17 mentioned as (for signature)....however when I use hf mf cload -f (filename), it only copies 16 sectors (0 to 15)...and the cloned card doesn't open the door....I also tried using an Aliexpress type copier, which has its own decryption program...it took an hour to decrypt it and then copied only 16 sectors....that fob also couldn't open the door.
I was wondering how you successfully cloned the fob ? What commands did you use on proxmark ? Would really appreciate your advice,
Here's the output of proxmark at the end of the decryption if you need it...(fyi, the json file only shows 16 sectors)
[+] -----+-----+--------------+---+--------------+----
[+] Sec | Blk | key A |res| key B |res
[+] -----+-----+--------------+---+--------------+----
[+] 000 | 003 | A0A1A2A3A4A5 | D | FBBDC7E05D51 | H
[+] 001 | 007 | FFFFFFFFFFFF | D | FFFFFFFFFFFF | D
[+] 002 | 011 | FFFFFFFFFFFF | D | FFFFFFFFFFFF | D
[+] 003 | 015 | FFFFFFFFFFFF | D | FFFFFFFFFFFF | D
[+] 004 | 019 | FFFFFFFFFFFF | D | FFFFFFFFFFFF | D
[+] 005 | 023 | FFFFFFFFFFFF | D | FFFFFFFFFFFF | D
[+] 006 | 027 | FFFFFFFFFFFF | D | FFFFFFFFFFFF | D
[+] 007 | 031 | FFFFFFFFFFFF | D | FFFFFFFFFFFF | D
[+] 008 | 035 | FFFFFFFFFFFF | D | FFFFFFFFFFFF | D
[+] 009 | 039 | FFFFFFFFFFFF | D | FFFFFFFFFFFF | D
[+] 010 | 043 | FFFFFFFFFFFF | D | FFFFFFFFFFFF | D
[+] 011 | 047 | FFFFFFFFFFFF | D | FFFFFFFFFFFF | D
[+] 012 | 051 | DDB5260BE312 | H | 6ED369105E13 | H
[+] 013 | 055 | C8B617A84FC3 | H | 8808EA0C2DDB | H
[+] 014 | 059 | A1F05F8A24B3 | H | F45A9375716E | H
[+] 015 | 063 | FFFFFFFFFFFF | D | FFFFFFFFFFFF | D
[+] 016 | 067 | 5C8FF9990DA2 | D | D01AFEEB890A | D ( )
[+] 017 | 071 | 75CCB59C9BED | D | 4B791BEA7BCC | D ( )
[+] -----+-----+--------------+---+--------------+----
[=] ( D:Dictionary / S:darkSide / U:User / R:Reused / N:Nested / H:Hardnested / C:statiCnested / A:keyA )
[=] ( * ) These sectors used for signature. Lays outside of user memory
[?] MAD key detected. Try hf mf mad
for more details
[+] Generating binary key file
[+] Found keys have been dumped to C:\Proxmark3\client\/hf-mf-54E2A47D-key-003.bin
[=] --[ FFFFFFFFFFFF ]-- has been inserted for unknown keys where res is 0
[=] transferring keys to simulator memory ( ok )
[=] dumping card content to emulator memory (Cmd Error: 04 can occur)
[=] downloading card content from emulator memory
[+] Saved 1024 bytes to binary file C:\Proxmark3\client\/hf-mf-54E2A47D-dump-003.bin
[+] Saved to json file C:\Proxmark3\client\/hf-mf-54E2A47D-dump-003.json
[=] autopwn execution time: 514 seconds
Thank you, Nooman
Hi again.
I have finally been able to clone a card and it works perfectly. Apparently this system does not make use of AES encryption and does not verify the signature.
I would still like to know how you can get to "read" AES keys stored in 4000 and 900x, please.
Regards
Hi.
I have an RFID card that has the particularity of having 2 more sectors than the normal 16 (0 to 15) that a Mifare Classic 1K has. It's probably a Vigik
With proxmark3 I have been able to extract all the keys from the 18 sectors.
The last sector 17 is fully readable with the B key although it is not writable as it has access rights on the trailer sector set to 70F0F8:
[=] # | Access rights [=] ----+----------------------------------------------------------------- [=] 0 | read B [=] 1 | read B [=] 2 | read B [=] 3 | read ACCESS by AB
This sector 17 contains the TAG IC Signature in the second and third blocks. In the first block there are bytes written that I don't know what they correspond to, but they seem to be an identifier.
Sector 16 exists but cannot be read or written to. Any attempt to read with the correct key returns error 04:
[usb] pm3 --> hf mf rdbl --blk 67 -a -k 5C8FF9990DA2 Cmd Error 04 Read block error [usb] pm3 --> hf mf rdbl --blk 67 -b -k D01AFEEB890A Cmd Error 04 Read block error [usb] pm3 --> hf mf rdsc --sec 16 -b -k D01AFEEB890A Cmd Error 04 Read sector 16 block 0 error [usb] pm3 --> hf mf rdsc --sec 16 -a -k 5C8FF9990DA2 Cmd Error 04 Read sector 16 block 0 error
It is probably a physical protection; a deliberately bad sector by hardware as part of copy protection (in the style of old game CDs). And I say by hardware because even wanting to simulate it in the trailer block by setting the access rights to FFFFFF, it should be possible to read the last block of the sector and that doesn't happen then:
[usb] pm3 --> hf mf acl -d ffffff
[!!] Invalid Access Conditions, NEVER write these on a card!
[=] # | Access rights [=] ----+----------------------------------------------------------------- [=] 0 | none [=] 1 | none [=] 2 | none [=] 3 | read ACCESS by AB
So the main protection must be precisely in that sector 16 that must deliberately throw that error 04 before any attempt to read and write.
Conclusions about its possible (or impossible) cloning:
At this point I would appreciate any ideas or contributions.
Regards