Attack never gets past stage1 (tag reader : ACR122U-A9) #76
Comments
|
I am also having this issue. In some of my testing,
|
|
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
|
|
I'm confused by what the implications of this are supposed to be. Are you suggesting that the issue lies with |
|
@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 .. .. 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 .. |
|
@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: btw cropto1_bs64 for windows is available on my blog post here: other test with nested attack (duration : <5 seconds) I tried also reader only attack which works well and quickly
|
|
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:
At some point in the writing I sent the card to the trash and now I cannot rewrite it.
I've tried to format it to see if I could read it again, but nothing After formatting I repeat the command
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 edit and add information:
Apparently the original card is locked and I cannot use the uppercase 'W' of the following command
Having done the writing with the lowercase 'w', I have broken what you say about the ACs
Do you know how to regain control of the ACs in the block?
|
@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. EDIT: Being an original card, I cannot use capital A or B either (tolerate errors)
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. |
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
|
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 Speaking of which, I've finally started trying to attack MiFare cards with it. Trying to use
|
|
@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 :( |
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. |
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? |
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. |
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. |
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:
1. The tag fixation with ACR122 is not performing well if CPU is under high load (eg. Flash Movie playing in IE, etc.)
2. Either a bug in libnfc 1.2.1 or a bug in RATB card-types 0x88 consecutive authentication goes like - one fails, one ok, even though correct keys are used
2.a Maybe need to check AC bits?
2.b Maybe AC bits/0x88 cards need a read/write or failed operation in between for the "state" to be ok and next auth to be successful?
Does anyone has an idea to solve known issue 2.b ?
Originally posted by @xavave in #30 (comment)
The text was updated successfully, but these errors were encountered: