nfc type4a read
nfc type4a write
I recently bricked a 7byte DesFire EV2 Compatible badge by setting a 4byte UID and thereby messing up the BCC (at least I think that this is the issue). I've looked through some of the documentations out there but I haven't found a way to fix my mistake.
The badge will still react to the WUPA/ANTICOLL/SELECT_UID sequence but does not reply to the RATS.
I know that it is unlikely, but does anybody know of a way to fix the badge?
thanks!
]]>I have found some great info from another user on github:
https://gist.github.com/darconeous/2cd2 … 158bddf933
I have been reading the documentation https://www.nxp.com/docs/en/data-sheet/MF1S70YYX_V1.pdf and I don't get any a conclusion. I only get specific characteristic about the mifare desfire tag.
2) Okay, I willl post in the correct topic
]]>in the end of your last post...
42ABCE2F162645DC971B1BCB89ED6342 - 16bytes. Might be a key for the desfire card?
it could very well be. but I've yet to get this proxmark working on my computer. This is the proxmark I bought (hacker warehouse):
]]>I'm working on a project with a DESFire EV1 card and trying to read the card:
[usb] pm3 --> hf mfdes info
[=] --- Tag Information ---------------------------
[=] -------------------------------------------------------------
[+] UID: 04 21 47 02 5D 5F 80
[+] Batch number: B9 0C 19 55 00
[+] Production date: week 50 / 2019
[=] --- Hardware Information
[=] raw: 04010101001605
[=] Vendor Id: NXP Semiconductors Germany
[=] Type: 0x01
[=] Subtype: 0x01
[=] Version: 1.0 ( DESFire EV1 )
[=] Storage size: 0x16 ( 2048 bytes )
[=] Protocol: 0x05 ( ISO 14443-2, 14443-3 )
[=] --- Software Information
[=] raw: 04010101041605
[=] Vendor Id: NXP Semiconductors Germany
[=] Type: 0x01
[=] Subtype: 0x01
[=] Version: 1.4
[=] Storage size: 0x16 ( 2048 bytes )
[=] Protocol: 0x05 ( ISO 14443-3, 14443-4 )
[=] --- Card capabilities
[=] 1.4 - DESFire Ev1 MF3ICD21/41/81, EAL4+
[+] Number of Masterkeys : 1
[+] Operation of PICC master key : (3)DES
[+] PICC Master key Version : 0 (0x00)
[=] ----------------------------------------------------------
[+] [0xAA] Authenticate AES : YES
[=] -------------------------------------------------------------
[=] Key setting: 0x0F [1111]
[+] [1...] CMK Configuration changeable : YES
[+] [.1..] CMK required for create/delete : NO
[+] [..1.] Directory list access with CMK : NO
[+] [...1] CMK is changeable : YES
[=] --- Free memory
[+] Available free memory on card : 992 bytes
[=] -------------------------------------------------------------
[usb] pm3 -->
Running enum results in failing to get the settings or file ids:
[usb] pm3 --> hf mfdes enum
[=] -- MIFARE DESFire Enumerate applications --------------------
[=] -------------------------------------------------------------
[+] Tag report 2 applications
[+] --- AMK - Application Master Key settings
[+] AID : F07A30
[+] AID mapped to MIFARE Classic AID (MAD): 7A3
[+] MAD AID Cluster 0x07 : miscellaneous applications
[=] MAD AID Function 0x07A3 : (unknown)
[!] Can't read Application Master key settings
[#] Warning: HF field is off, ignoring TransmitFor14443a command
[!!] APDU: No APDU response
[!] Can't read AID master key version. Trying all keys
[!] Can't get file ids -> Current authentication status does not allow the requested command
[+] --- AMK - Application Master Key settings
[+] AID : F07A31
[+] AID mapped to MIFARE Classic AID (MAD): 7A3
[+] MAD AID Cluster 0x07 : miscellaneous applications
[=] MAD AID Function 0x07A3 : (unknown)
[!] Can't read Application Master key settings
[#] Warning: HF field is off, ignoring TransmitFor14443a command
[!!] APDU: No APDU response
[!] Can't read AID master key version. Trying all keys
[!] Can't get file ids -> Current authentication status does not allow the requested command
[=] -------------------------------------------------------------
I figure I will probably have to authenticate before the card will provide any further data. I have been provided two keys "Application Read SAM AV1" and "Application Read SAM AV2" but have not been able to get the card to authenticate. When I pass in the keys I get " Can't get file ids -> Current authentication status does not allow the requested command".
Any assistance would be appreciated.
Thanks!
]]>hf mfdes enum
Regarding brute-force,
If you get hold of the datasheets from NXP about DESFire, I believe you can find the best practice for it.
[usb] pm3 --> hf mfp wrbl
Usage: hf mfp wrbl [-h|-H|--help] [-v|-V|--verbose] [-b|-B|--keyb] <Block Num (0..255)> <Data (HEX 16 bytes)> [<Key (HEX 16 bytes)>]
Writes one block to Mifare Plus card.
-h, -H, --help This help
-v, -V, --verbose show internal data.
-b, -B, --keyb use key B (by default keyA).
Usage:
hf mfp wrbl 1 ff0000000000000000000000000000ff 000102030405060708090a0b0c0d0e0f -> writes block 1 data
hf mfp wrbl 2 ff0000000000000000000000000000ff -v -> writes block 2 data with default key 0xFF..0xFF and some additional data
The Application has two keys. What does Version 0 mean? Does it indicate a "default"/ empty key?
The key version is a user defined value. It's intended use is key management.
Les say: Someone had stolen your application key or reverse engeneered it, so you need to switch to another key. You can do this in two different ways:
1) You can use a new key and just probe all your keys until you can enter
2) You read the key version, so you directly know the required (new) key
So most of the times the key version is 0, but you can program this to any value (in allowed range). Some implementations do use this value to store some kind of user information, completely unrelated to the keys.
This came somehow from the old DES encryption where the upper bit is not in use (56 bit keys, but 8 byte of key-data). These 8 bits got a long history of side-use over the time. The first DESfire implementation defined it as "key version", so it's still there...
But over all: The general use is key management, also to easily disable insecure keys by just programming clients with the info "key version must be > X".
]]>