Attack never gets past stage 1

[GoogleCodeExporter]

Hi,

I'm running r94. I've been trying with two different readers now (ACL122U and 
SCL3711) and three different series of cards. The basic symptom is that the 
random generator in the card is still weak, but the attack doesn't progress 
nevertheless; it seems MFCUK never gets to the point where it gets the 1/256 
guess right and gets the NACK back. Example:

-----------------------------------------------------
Let me entertain you!
    uid: <removed>
   type: 08
    key: 000000000000
  block: 03
diff Nt: 144
  auths: 92264
-----------------------------------------------------

With 92k auths and only 144 different Nts, every Nt should have _at least_ 638 
attempts on it (in reality probably much more, as some Nt values are much more 
common than others), which is above 256, and the attack should have succeeded 
long ago as I understand it.

MFOC succeeds for the card where I have a known key, so the basics of my NFC 
setup appears to be okay.

Has anyone seen this before?

Original issue reported on code.google.com by sgunder...@bigfoot.com on 5 Jun 2014 at 8:31

[micolous]

If you were looking for more information once Google Code is shut down, "mfcuk revision 65" in many of these blog posts is commit 1b6d022. The commit date is Sun Sep 23 10:29:36 2012 +0000, the message is:

Convert all remaining dos files to unix format.

I have still not had luck in getting libnfc 1.5.1 and mfcuk r65 working with a unknown card working. However, the issue with the pn532->uart not being detected was resolved by these libnfc configure options:

./configure --prefix=$HOME/nfc/prefix --with-drivers=pn532_uart,pn53x_usb --enable-serial-autoprobe

If you have at least one known key on the card, use mfoc instead of mfcuk. This is reliable even with recent libnfc (1.7.0).

[micolous]

I've now made this operational with a pn532 chip. I used nfc-tools/libnfc@6752951, and 1b6d022, and installed these into a different prefix (like the instructions in the comment above mine) with a different LD_LIBRARY_PATH so as not to use my (newer) system libnfc.

It takes 45 - 90 minutes to dump a "behaving" card with the software. You should use -v 3 and have a look at the values it returns, the "Let me entertain you" string. When the debugging information is printed, you want the "diff Nt" value to stay below about 300, and the "auths" value to keep incrementing higher. If they stay the same for a long time, you might have a card which mfcuk does not behave on, and you should try a different card.

There may be a way to modify mfcuk to fix misbehaving cards but I have not explored this.

My strategy has been to tell mfcuk to break only a single sector (this is quicker), then using the keys it acquired to seed mfoc, which is much faster but only works if at least one key is known. You can specify this with the -k option to mfoc, for as many keys as you like, eg:

./mfoc -O mycard.mfc -k 112233445566 -k 665544332211

If you have at least one of each of the A and B keys, you can recover all keys on the card.

mfoc also works fine with current libnfc, so you only need to do funky LD_LIBRARY_PATH and multiple prefix tricks with mfcuk. I have not attempted to fix the software with current libnfc, as unfortunately each attempt at breaking a card takes about an hour.

[micolous]

"Misbehaving cards" where "diff Nt" continues to increment with "auths" above 300 can indicate a couple of different issues:

1. Your card reader is not operating very well. With cheap readers, you may have to add sleep options (eg: -s 250 -S 250) in order to increase the stability of the crack. You should see diff Nt stay below 300, and auths continue to increment above that. This is particularly an issue with the acr122u and pn532 chipsets.
2. You have the wrong version of libnfc/mfcuk. Make sure that mfcuk is loading the correct library (use ldd and LD_LIBRARY_PATH to check and fix).
3. You have a Mifare Plus card with Classic emulation mode. This fixes the exploit vector used by mfcuk and mfoc. Unfortunately, there's not much you can do about this, apart from wallowing in sadness. Edit: Mifare Plus cards are vulnerable to the Hardnested attack, which can replace mfoc (which implements Nested attack), but you still need to extract one key from a "genuine" reader.

If your cards are part of a system, it's probable that the key is generated by a function of the card's UID and sector number. If you have enough older cards (not MF Plus) which are vulnerable, you should be able to figure out the key derivation function once you have a mathematically significant number of samples.

[neomilium]

Interesting read. Thank you :)

[limbenjamin]

@micolous I have followed your instructions in using nfc-tools/libnfc@6752951, and 1b6d022. However, while doing make on mfcuk, I encountered the following error.

/home/benjamin/mfcuk/src/mfcuk.c:908: undefined reference tonfc_configure'
/home/benjamin/mfcuk/src/mfcuk.c:914: undefined reference to nfc_configure' /home/benjamin/mfcuk/src/mfcuk.c:921: undefined reference tonfc_configure'
/home/benjamin/mfcuk/src/mfcuk.c:931: undefined reference to nfc_initiator_sele ct_passive_target'

According to [https://github.com/nfc-tools/libnfc/issues/182](issue 182), it is a linkage problem. I followed the prefix used here, http://barisguvercin.com/mifare-1k-cracking/. Any ideas on how to solve it? Possible to upload your binaries?

Edit: For anyone who is facing similar problems in future, I recommend you download Kali 2.0. All the libraries and binaries are compatible and working nicely. Plug and play. Live USB. MFCUK, MFOC and libnfc all working.

[axiomatico]

Thanks Benjamin.

2016-06-10 14:55 GMT+02:00 Benjamin Lim notifications@github.com:

For anyone who is facing similar problems in future, I recommend you
download Kali 2.0. All the libraries and binaries are compatible and
working nicely. Plug and play. Live USB. MFCUK, MFOC and libnfc all working.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#30 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ASwS5v7RkLg0rRMzDqABgkjIn8vAkJ6uks5qKV7OgaJpZM4Fm0Tq
.

[GMXX]

Anyone found a solution? I'm having the same problem. 56k auths and only 200 Nts.

I'm using Kali Linux and a PN532.

[bigmangos]

Try ./mfcuk -C -R 3 -S 250 - s 250 -v 3

[U17A]

Has anyone got the solution?

[neomilium]

Too old issue.

[xavave]

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)

nfc_initiator_transceive_bits(pnd, abtArEnc, 64, abtArEncPar, abtRx, sizeof(abtRx), abtRxPar);

https://github.com/nfc-tools/mfcuk/blob/master/src/mfcuk.c line 600

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?