Tag RFID 1K with 16 & 17 sectors #1010
Comments
|
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) [=] testing to read key B... [+] found keys: [+] -----+-----+--------------+---+--------------+---- [+] found keys: [+] -----+-----+--------------+---+--------------+---- [+] found keys: [+] -----+-----+--------------+---+--------------+---- |
|
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 [=] -----+-----+-------------------------------------------------+----------------- 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 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 [usb] pm3 --> hf mf acl -d 00F87F [=] # | Access rights "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 |
Thank you very much, Iceman, and thank you for your work. Best regards |
|
Edit: Fixed: It was a reading error ????? [=] -------+--------------------------------+--------------------------------- [usb] pm3 --> hf mfp rdsc -s 64 --key 00000000000000000000000000000000 |
|
Hi Iceman: [usb] pm3 --> hf mfp chk -d mfp_default_keys 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 1 sector 2 sector 3 sector 4 sector 5 sector 6 sector 7 sector 8 sector 9 sector 10 sector 11 sector 12 sector 13 sector 14 sector 15 sector 16 sector 17 sector |
|
Mifare Plus EV1 (Desfire) 2k ? |
|
@Luisdp67 I have the similar situation. Would you mind explain how you were able to clone your key? |
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
The text was updated successfully, but these errors were encountered: