Open xavave opened 4 years ago
I am also having this issue. In some of my testing, mfcuk
starts throwing errors as shown below.
after hours of debugging code in visual studio, with libnfc in debug log mode, I still can't solve it, but I saw there is a time out in pn53x.c even if I set the timeout value to infinity (0)
this error happens in mfcuk.c in function mfcuk_key_recovery_block and the error is ALWAYS the same (-20) , so I never get some hits4 incremented (NACK error 0x05 is never hit)
I'm confused by what the implications of this are supposed to be. Are you suggesting that the issue lies with pn53x
?
@DavidBerdik maybe there is an issue in pn53x.c but my knowledge is too limited to understand why for now .. I tried to contact mfcuk and libnfc authors (@neomilium ) to get some info, but no answer .. mfcuk is supposed to hit NACK authentifcation error 0x5 sometimes(hit4 number) , but it doesn't
.. so I don't know which condition can break the loop on mfcuk_key_recovery_block function
Moreover in acr122_usb.c if I raise the usb timeout per pass (which is hardcoded with 200) to 500
I can then hit this error in acr122_usb_send (acr122_usb.c): Command Code verification failed with last_error = NFC_EIO (Invalid argument(s))
@xavave Thank you for putting so much effort in to this. I have tried doing this as well, but just like you, I am not knowledgeable enough to get it working. 😢
@DavidBerdik unfortunaltely, I don't know how to go further now, and libnfc project team (@neomilium , @doegox , @darconeous ) doesn't seem to be available .. I've posted this issue on https://groups.google.com/forum/#!forum/nfc-tools-devel
@xavave I understand. Once your proxmark arrives and you have had time to test, please let me know of the results.
@DavidBerdik Hi , I tried to use darkside attack with proxmark 3 on tag with your hotel tag dump but :
@xavave What happens when you try to do the hardnested attack? The card uses several default keys and that one does work with the ACR122U.
@DavidBerdik mfoc hardnested (windows version) works well (as some keys are default keys) and quickly finds all keys on acr-122u (- 30 seconds)
with proxmark3 it works well too but, I have to specify at least one known key :
hardnested method on proxmark 3 as same input parameters than cropto1_bs.exe for ACR122U: on proxmark 3 key solving is much faster (29 seconds on pm3 and 173 seconds on acr122U with same parameters: cropto1_bs_x64.exe 48925475AAE0 0 A 4 A) cropto1_bs.exe with ACR122U, but results are the same:
btw cropto1_bs64 for windows is available on my blog post here: http://legacy.averbouch.biz/libnfc-and-nfc-utils-binaries-on-windows-10/#alltools
other test with nested attack (duration : <5 seconds)
I tried also reader only attack which works well and quickly following this post (in french):https://connect.ed-diamond.com/MISC/MISCHS-016/Proxmark-3-le-couteau-suisse-RFID
Not solution found? @xavave
@Cazs03 unfortunately, no, and libnfc team doesn't seem to work on this project these days...
@xavave Thank you for the details. Unfortunately, I cannot share my other test card on here for security reasons, so I guess I will be buying a proxmark as well.
@xavave I ordered a proxmark last week, but, between the fact that it's coming from China and COVID-19 drama, I'm not expecting it to be here for a while.
@DavidBerdik it took also weeks for me to receive it from AliExpress China
Hi @xavave
With the next command:
.\mfoc_hardnested.exe -O chinese.mfd
I was able to perform a dump and see the keys A, B
.\nfc-mfclassic.exe w b u .\original.mfd
At some point in the writing I sent the card to the trash and now I cannot rewrite it.
Repeating the command:
.\nfc-mfclassic.exe w b u .\original.mfd
ERROR: No sector encrypted with the default key has been found, exiting..
I've tried to format it to see if I could read it again, but nothing
.\nfc-mfsetuid.exe -f
After formatting I repeat the command
.\nfc-mfclassic.exe w B u .\original.mfd
Guessing size: seems to be a 1024-byte card Writing 64 blocks |nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed xxfailed to write trailer block 3...
Maybe someone can help you or have the solution
@Cazs03 when you write your dump to the card, if your dump changes ACs (Access conditions) you can "brick" some sectors of the card: depending on the ACs values, you can sometimes have no way to recover them --> more info here https://www.mifare.net/support/forum/topic/what-is-mifare-classic-1k-access-bits-means-how-to-calculate-and-use-it/
everytime you write something on the card, you should then re-read the card and use the new re-read dump to write onto this card again. Maybe my tool could help you next time (even if it won't recover your bricked card) https://github.com/xavave/Mifare-Windows-Tool
@xavave I didn't know that, thank you very much for the information I keep using your tools, what a great job I am trying to work on the same original card, I have a new one, I hope not to break it. Too bad that hexadecimal information is illegible, many rare characters come out and I can't transform it to ASCII
I edit and add information:
.\nfc-mfsetuid.exe -q NFC reader: ACS / ACR122U PICC Interface opened
Found tag with UID: XXXXX ATQA: 0004 SAK: 08
Warning: Unlock command [1/2]: failed / not acknowledged.
Apparently the original card is locked and I cannot use the uppercase 'W' of the following command
.\nfc-mfclassic.exe W b .\destination.mfd .\backup.mfd
Having done the writing with the lowercase 'w', I have broken what you say about the ACs
.\nfc-mfclassic.exe w b .\destination.mfd .\backup.mfd
Do you know how to regain control of the ACs in the block?
RATS support: no Guessing size: seems to be a 1024-byte card Writing 64 blocks |nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed ! Error: authentication failed for block 00
.\nfc-mfclassic.exe W b .\destination.mfd .\backup.mfd
@Cazs03 did you also try with key A? .\nfc-mfclassic.exe W a .\destination.mfd .\backup.mfd
@xavave I have two new original cards, they are not Chinese cards and I cannot use the capital W.
I will try again to see ... I am studying why the card is blocked by dumping the original content of one card to another
.\nfc-mfclassic.exe w a .\destination.mfd .\backup.mfd
EDIT:
Being an original card, I cannot use capital A or B either (tolerate errors)
Guessing size: seems to be a 1024-byte card Writing 64 blocks |nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed ! Error: authentication failed for block 00
Does the original card have a different writing method? (If I use W, (A or B) the card will be useless)
Proxmark finally arrived! I should have time to play with it this weekend.
@xavave I have two new original cards, they are not Chinese cards and I cannot use the capital W. I will try again to see ... I am studying why the card is blocked by dumping the original content of one card to another
.\nfc-mfclassic.exe w a .\destination.mfd .\backup.mfd
EDIT:
Being an original card, I cannot use capital A or B either (tolerate errors)
Guessing size: seems to be a 1024-byte card Writing 64 blocks |nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed nfc_initiator_transceive_bytes: Mifare Authentication Failed ! Error: authentication failed for block 00
Does the original card have a different writing method? (If I use W, (A or B) the card will be useless)
Im' sorry but I don't have the original cards to test, and not enough information to help you there
@xavave Could you point me in the right direction for testing with a proxmark? I cannot even get the hf
command to work in my ProxSpace environment.
@xavave Could you point me in the right direction for testing with a proxmark? I cannot even get the
hf
command to work in my ProxSpace environment.I use it on windows environnement. I can send you my windows proxmark folder in pm if you want , but the first thing to do is to connect the proxmark on the right com port e.g. on windows : proxmark3.exe com4 (you can check on device manager which port is used by your proxmark 3) I didn’t try it on Linux more info for proxmark3 linux here: https://github.com/Proxmark/proxmark3/wiki/Ubuntu-Linux#Running_the_proxmark3_client
compile proxmark3 on windows : https://github.com/Proxmark/proxmark3/wiki/Windows
@xavave Thanks! It turns out that I was actually doing it right. I just didn't know where to find proxmark3.exe
.
Speaking of which, I've finally started trying to attack MiFare cards with it. Trying to use hf mf mifare
on the hotel room key that I gave you does not seem to work (it throws an error saying that the card is not vulnerable), but it seems to be doing something with my other card.
@xavave It seems to me that the issue may be on a card-by-card basis, as I have several MiFare Classic cards that are all from the same source, and the attack works for some of them but not on all of them. All of these cards use the same encryption keys so I am able to dump all of them and write them to a magic card. When I do that and try attacking the copied card, the results seem to vary depending on which magic card I use.
I apologize if this behavior is known and expected, as I am still not extensively familiar with the structure of these cards, but as I understood, all MiFare Classic cards should be equally vulnerable.
@xavave I've got just the same problem but I have different reader. My reader is DYI PN532 model connected via UART to Raspberry Pi 4. So basically I think it is not the reader problem. The Darkside attack exploits the issue that the card sometimes answers for the invalid authentication attemp. This happens in average once for 256 retries for the same nonce.
My guess that this vulnerability was fixed in new cards - they simpy answer only on valid authentication attemp :(
My guess that this vulnerability was fixed in new cards - they simpy answer only on valid authentication attemp :(
Try getting a Proxmark. My success with the ACR122U is very inconsistent across cards, but I've never had any issues with my Proxmark cracking a card. It's more expensive than the ACR122U and the DYI PN532, but well worth it if you're interested in playing with NFC stuff.
My guess that this vulnerability was fixed in new cards - they simpy answer only on valid authentication attemp :(
Try getting a Proxmark. My success with the ACR122U is very inconsistent across cards, but I've never had any issues with my Proxmark cracking a card. It's more expensive than the ACR122U and the DYI PN532, but well worth it if you're interested in playing with NFC stuff.
Well, I've just tried to research this stuff for fun. I'm not going to invest more money into these pro-tools. Still I don't understand the issue if it is the issue linked with the reader. I've traced the exchange up to PN532 frames, read the manual, parsed with my eyes the protocol units exchanged with the reader - everything seems to be fine and according to the docs. But the card doesn't respond. I've got a response from reader that it is card's timeout - so it is not the case when the reader doesn't understand the host's intentions. I think if it is the NFC library or the mfcuk issue - it could be fixed as it is open source.
I would try to investigate the issue more. I have patched the mfcuk so it tries to use the key which is 100% correct for this card and it still doesn't respond. May be if I understand why then I find out the way to get replies from the card during the attack.
My guess that this vulnerability was fixed in new cards - they simpy answer only on valid authentication attemp :(
Try getting a Proxmark. My success with the ACR122U is very inconsistent across cards, but I've never had any issues with my Proxmark cracking a card. It's more expensive than the ACR122U and the DYI PN532, but well worth it if you're interested in playing with NFC stuff.
By the way - have managed to recover keys with Proxmark with Darkside attack on the cards with which you have had troubles in the start of this thread?
Hi @dmitrmax , I've compiled mfcuk for windows with libnfc 1.8, it's in attachment, please give a try and tell me if it works or if some dll are missing mfcuk.zip
Hi @dmitrmax , I've compiled mfcuk for windows with libnfc 1.8, it's in attachment, please give a try and tell me if it works or if some dll are missing mfcuk.zip
I don't have Windows. I'm running this stuff on the Raspberry Pi 4 in Linux. Anyway I use the latest versions of the library and mfcuk with no luck. Does your version has any custom patches?
Okay. I compiled it a few months ago , I don't remember if it was patched. Is the patch you mentioned above available on github ?
I think if it is the NFC library or the mfcuk issue - it could be fixed as it is open source.
The proxmark firmware is open source as well. I wonder if it would be possible to try comparing the implementation of the attack used in the firmware against mfcuk to determine if it is indeed an mfcuk issue.
Any updates on that?
@csskevin I haven't bothered to look in to it since migrating to using a Proxmark was sufficient for my needs.
Is it possible to crack a card when all keys are custom and unknown?
@AzonInc that depends pretty much on the card itself. Nowadays many cards have countermeasures against hardnested and darkside attack. The proxmark firmware has a modified hardnested attack which is called hardnested-static which might help. But I haven't seen it implemented in PC software.
Is it possible to crack a card when all keys are custom and unknown?
Depending on the origin of the card that you're trying to crack, it is possible that the "custom and unknown" keys of the card are actually known and can be easily identified with a dictionary attack. The RFID Research Group's fork of the Proxmark firmware has a set of dictionaries here. If you are working with MiFare Classic cards, you probably want to use mfc_default_keys.dic.
Hi, This issue is still here ...After adding more printf to debug code I saw that ACR122U fails transceive bits with always the same error NFC_ERFTRANS -20 (RF Transmission Error)
res = nfc_initiator_transceive_bits(pnd, abtArEnc, 64, abtArEncPar, abtRx, sizeof(abtRx), abtRxPar))
and res always= -20 -->NFC_ERFTRANS
error thrown here : https://github.com/nfc-tools/mfcuk/blob/master/src/mfcuk.c#L605
maybe this is related to Known Issues:
Does anyone has an idea to solve known issue 2.b ?
Originally posted by @xavave in https://github.com/nfc-tools/mfcuk/issues/30#issuecomment-582488122