Wrong recovered keys

[GoogleCodeExporter]

(originally reported by thefkboss on issue 19)

the last 2 bytes of the keys are always good, but the first 4 bytes are always 
wrong (sometimes random, sometimes the same).

the problem is here i think

#if !defined __i386__ || !defined __GNUC__
        x ^= x >> 16;
        x ^= x >> 8;
        x ^= x >> 4;
        return BIT(0x6996, x & 0xf);

i think this is not correct, i have to look more deep

lot of people have problems with this issue

http://www.libnfc.org/community/topic/98/mifare-classic-key-recovery-tool-dark-s
ide-attack/page/3/

Original issue reported on code.google.com by romu...@libnfc.org on 18 Feb 2013 at 8:20

[GoogleCodeExporter]

by thefkboss:

i had tried on x64 debian 6.06 and happend this error

Original comment by romu...@libnfc.org on 18 Feb 2013 at 8:22

[GoogleCodeExporter]

confirmed by marcioalma:

I just tryed it and the result is the same... the first 4 bytes are incorrect 
and the last 2 bytes are correct.

Original comment by romu...@libnfc.org on 18 Feb 2013 at 8:23

[GoogleCodeExporter]

Hello Folks,

Any solution for this issue? anyone have some patch or workaround for this? 

Thanks.

Original comment by marcioa...@gmail.com on 22 Feb 2013 at 4:50

[GoogleCodeExporter]

Also looking for a solution. Thanks

Original comment by benny.j....@gmail.com on 26 Feb 2013 at 5:19

[GoogleCodeExporter]

hello, i have the same problem.
using backtrack 5 and windows 7 x64
reader is acr122u

Original comment by DarkAutism@gmail.com on 30 Mar 2013 at 7:27

[GoogleCodeExporter]

Hello, I have the same problem.
Linux x64
Libnfc 1.7.0-rc7 and mfcuk 0.3.8

Reader: NFC reader: pn532_uart:/dev/ttyUSB0 opened

Thanks.

Original comment by devil.dr...@gmail.com on 9 Jul 2013 at 2:06

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Confirmed same issue here, I can't verify with the correct tag as I'm playing 
with a card a friend of mine gave me but the lats 4 bytes are always the same 
so i assume they are correct. (Results over 10 attempts, also s/S flags don't 
seem to influence the result).

Card Reader: ACR122U_A9

Original comment by ru.boo...@gmail.com on 21 Jul 2013 at 5:32

[GoogleCodeExporter]

I have the same problem. With old version the keys are correct. With the latest 
version the first 4 digits are wrong.

Card Reader : acr122U
mfcuk-0.3.8
libfnc 1.7

Original comment by adrian.s...@gmail.com on 13 Aug 2013 at 9:15

[GoogleCodeExporter]

Hey Adrian,

Out of curiosity, what version of mfcuk and libnfc did work for you?

Original comment by ru.boo...@gmail.com on 14 Aug 2013 at 12:36

[GoogleCodeExporter]

same here. @adrian: what is the latest version that worked for you?

Original comment by nelu.tarna on 22 Aug 2013 at 8:46

[GoogleCodeExporter]

I case with ACR122 reader.

libnfc-1.7.0
mfcuk-0.3.8

Original comment by jorge.ba...@gmail.com on 12 Sep 2013 at 7:38

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi, 

I've got exactly the same issue.
Everything look good, but the recoveded keys are never the same except the 
lasts 2 bytes...
Libnfc 1.7.0 Mfcuk-0.3.8

Original comment by remi.rou...@gmail.com on 18 Nov 2013 at 12:19

[GoogleCodeExporter]

i have the same problem, mfuck recovered the wrong keys :( ¿do you have any 
idea for solution this?

Original comment by david.ba...@gmail.com on 5 Dec 2013 at 1:28

[GoogleCodeExporter]

same problem here, my environment:
libnfc-1.7.0
mfcuk-0.3.8
mac osx 10.9 x64

I really don´t know if the last 2 bytes are correct, but it is always the same 
ones. I tried even with a newer gcc version (4.9) because i thought that the 
error was related to __builtin_bswapXX() functions of gcc >= 4.3 (lastest xcode 
version comes with gcc 4.2.1, so it compiles with warning "No bswap function 
found! Using untested alternatives...")

Original comment by gonzaloc...@gmail.com on 6 Dec 2013 at 3:34

[GoogleCodeExporter]

Ok, we know there is a problem, nobody can submit a patch for this ? Or any 
idea about what happens ?

At least, do anyone know which latest libnfc+mfuck couple works ?

Original comment by romu...@libnfc.org on 6 Dec 2013 at 4:00

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I can confirm the problem but am only getting started and would need some help 
identifying the cause.
will look at some older versions and see how they behave

----------
libnfc-1.7.0
mfcuk-0.3.8
osx 10.7.5

Original comment by wwi...@gmail.com on 8 Dec 2013 at 5:06

[GoogleCodeExporter]

ok romu, there is no need to be rude. it takes really some time to test a 
configuration, you have to wait to mfcuk finish after around 3 hours (or 
more)... of course i know that develop it takes even much more time, but, as i 
said, testing takes time, and i just wanted to share my experience.

Anyway, few minutes ago, after a lot of tries, I have lucky with a couple of 
libnfc+mfcuk:
libnfc-1.5.1
mfcuk-0.3.3 (revision 60)

The steps to make the environment:
for libnfc, just download the sources from this link:
https://code.google.com/p/libnfc/downloads/detail?name=libnfc-1.5.1.tar.gz

for mfcuk, just checkout the 60's revision:
svn checkout http://mfcuk.googlecode.com/svn/trunk/@60 mfcuk-read-only

then i compiled both libnfc and mfcuk sources as usual.

On the other hand, i want to share the unsuccessfully combinations:
libnfc-1.7.0 + mfcuk-0.3.8 --> wrong recovered key
libnfc-1.7.0rc7 + mfcuk-0.3.8 --> wrong recovered key
libnfc-1.7.0rc1 + mfcuk-0.3.7 --> no recovered key after 17000 auths, mfcuk 
finished by itself
libnfc-1.7.0rc1 + mfcuk-0.3.5 --> no recovered key after 17000 auths, mfcuk 
finished by itself

hope it helps, let me know if i can help you guys with some other tests. I will 
try to debug last mfcuk version more deeply to try to detect why it makes the 
wrong first 4 bytes, but im newbie with rfid.

Original comment by gonzaloc...@gmail.com on 9 Dec 2013 at 12:46

[GoogleCodeExporter]

i was just trying to verify but i've got an error compiling mfcuk 60's version:

[...]
mfcuk.c:147:2: warning: #warning is a GCC extension [enabled by default]
mfcuk.c:147:2: warning: #warning "NO byteswap.h found! Using untested 
alternatives..." [-Wcpp]
mfcuk.c: In function ‘mfcuk_verify_key_block’:
mfcuk.c:296:5: warning: dereferencing type-punned pointer will break 
strict-aliasing rules [-Wstrict-aliasing]
mfcuk.c: In function ‘mfcuk_key_recovery_block’:
mfcuk.c:451:5: warning: dereferencing type-punned pointer will break 
strict-aliasing rules [-Wstrict-aliasing]
mfcuk.c: In function ‘main’:
mfcuk.c:1046:5: warning: implicit declaration of function ‘getopt’ 
[-Wimplicit-function-declaration]
mfcuk.c:1052:17: error: ‘optarg’ undeclared (first use in this function)
mfcuk.c:1052:17: note: each undeclared identifier is reported only once for 
each function it appears in
mfcuk.c:1146:21: warning: dereferencing type-punned pointer will break 
strict-aliasing rules [-Wstrict-aliasing]
mfcuk.c:1364:61: warning: comparison between signed and unsigned integer 
expressions [-Wsign-compare]
mfcuk.c:1428:33: warning: comparison is always true due to limited range of 
data type [-Wtype-limits]
mfcuk.c:1428:33: warning: comparison is always true due to limited range of 
data type [-Wtype-limits]
mfcuk.c:1573:13: warning: dereferencing type-punned pointer will break 
strict-aliasing rules [-Wstrict-aliasing]
mfcuk.c:1624:5: warning: dereferencing type-punned pointer will break 
strict-aliasing rules [-Wstrict-aliasing]
mfcuk.c:1630:9: warning: dereferencing type-punned pointer will break 
strict-aliasing rules [-Wstrict-aliasing]
make[2]: *** [mfcuk.o] Error 1
[...]

could this be an error on my system or with the mfcuk version?

Original comment by wwi...@gmail.com on 11 Dec 2013 at 11:04

[GoogleCodeExporter]

is probably an error on your system, it sounds like you have missing headers

Original comment by gonzaloc...@gmail.com on 12 Dec 2013 at 12:51

[GoogleCodeExporter]

i am debugging the code for search the error that generate the incorrect 4 
bytes of key.
¿run older versions correctly?

libnfc-1.7.0
mfcuk-0.3.8 

Original comment by david.ba...@gmail.com on 12 Dec 2013 at 5:28

[GoogleCodeExporter]

i'm still getting compile or runtime errors with older version.

it seems like it doesn't find the header but i don't know how to tell it to use 
the one under /usr/include

----------------------
libusb-0.1.12
libnfc-1.7.0
mfcuk-0.3.8

Original comment by wwi...@gmail.com on 12 Dec 2013 at 10:36

[GoogleCodeExporter]

@wwirfi for the implicit declaration of 'getopt', adding #include <getopt.h> 
should help (had the same problem)

I'm trying to build mfcuk-0.3.3 with libnfc-1.5.1. 
I give include and lib folders to ./configure, runs ok. 
But when running make, I end up with "undefined reference to" nfc functions.
How to make sure the header file is properly used ?

Original comment by algar...@gmail.com on 16 Dec 2013 at 11:50

[GoogleCodeExporter]

thanks for the info.

I can confirm that older version do work, as stated earlier 
I've got it to compile and run with r65 of mfcuk and 1.5.1 of libnfc.

The results look good so far but I wanna try it with some more different cards.

So it seems that something has been broken between r65 and the current version.
I'll probably won't have time this year but maybe someone can scan the 
changelog for some indication.

Original comment by wwi...@gmail.com on 17 Dec 2013 at 7:08

[GoogleCodeExporter]

Hi all,

Nice work! You find some working releases and that's really helpful.
Could you try to find the latest working combo ?

r65 is confirmed to work fine; do r66 work too ?

Thanks!

Original comment by romu...@libnfc.org on 17 Dec 2013 at 8:16

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I confirm that this version run correctly :)  

i search the change in new version...

Original comment by david.ba...@gmail.com on 18 Dec 2013 at 1:27

[GoogleCodeExporter]

I've tried some other versions and in fact the key given varies depending which 
version you run.

My original tag has key : ca09f6dd7fea

 - r65 w/ 1.5.1 : ca09f6dd7fea
 - r73 w/ 1.6.0-rc1 (git rev. 310d7eba0743e661cf93fa092ed967d8ac37d058) : 5d9f993b7fea
 - r80 w/ 1.6.0-rc1 (git rev. 310d7eba0743e661cf93fa092ed967d8ac37d058) : 5d9f993b7fea
 - r81 w/ 1.7.0-rc2 : 5d9f993b7fea
 - r85 w/ 1.7.0-rc6 (git rev. a262be563374f92d29e3b976a51da91762d08307) : segfault
 - r93 w/ 1.7.0 : 59403bc07fea

I tried to run other revisions, moslty had trouble building them. I'll try some 
earlier revisions (between r65 and r73) next week.

Original comment by algar...@gmail.com on 20 Dec 2013 at 5:51

[GoogleCodeExporter]

It seems no revision between r65 and r73 can be built. So I applied patch from 
r73 to r66 to build it.

- r66 (patched by r73) w/ 1.6.0-rc1 (git rev. 
310d7eba0743e661cf93fa092ed967d8ac37d058): 59403bc07fea

So it seems the problem is either in r66 or r73. Or it's from libnfc after 
1.5.1.

Original comment by algar...@gmail.com on 23 Dec 2013 at 11:29

[GoogleCodeExporter]

thanks for the testing! i've been away the last weeks and am trying to catch up.

does the r66 with the patch from r73 work?
i'm guessing that the libnfc is working correctly.

i'll try to look into the code but my coding-fu is weak

Original comment by wwi...@gmail.com on 1 Jan 2014 at 11:37

[GoogleCodeExporter]

r66 compiles when patched but gives a wrong key.

About the "patch", in fact i copied mfcuk.c/h and mfcuk_mifare.c/h from r73 
which have minor modifications from r67, r68 and r69.

I took a look at the modifications but didn't find anything wrong up to now. 
That's why i started wondering if the problem was not coming from somewhere in 
libnfc. Hope you're more successful.

Original comment by algar...@gmail.com on 2 Jan 2014 at 10:22

[GoogleCodeExporter]

i'm busy right now with some other stuff (like working and such :/ )
but i'll try to look into it during the next few weeks.

I've read the patch notes and it might have something to do with a newer libnfc 
version ... well.. we'll see

Original comment by wwi...@gmail.com on 7 Jan 2014 at 12:31

[GoogleCodeExporter]

I've just noticed something while checking result differences between r65 and 
r66 and i just discovered where the problem is. 

The representation of the UID differs in the two versions and i think it comes 
from libnfc :
- r65 + libnfc 1.5.1 - UID = 0x1d3bc057 (right)
- r66 + libnfc 1.6.0 - UID = 0x57c03b1d (reversed)

Then i suppose either libnfc needs to be fixed to get the right UID or we have 
to revert the UID to get the right one in mfcuk.

I discovered this as i was checking how the lfsr was working as the UID is used 
to init it.

Original comment by algar...@gmail.com on 8 Jan 2014 at 5:54

[GoogleCodeExporter]

I think i went too fast on conclusions. It seems it comes from function 
bswap_32_pu8 (mfcuk.c line 215 in r93) which takes an array of 4 bytes to turn 
it into a 32bits value.

If the input is [0x01, 0x23, 0x45, 0x67], the output is 0x67452301 (which is 
definitely wrong). I've tried a bit to fix it but i really have too litle 
experience with C to do so. Fixing this should fix the retrieved key i think.

Anyone to do this ?

Original comment by algar...@gmail.com on 9 Jan 2014 at 10:39

[GoogleCodeExporter]

static uint32_t bswap_32_pu8(uint8_t *pu8)
{
  return pu8[0] << 24 | pu8[1] << 16 | pu8[2] << 8 | pu8[3];
}
is probably what you are talking about but I think that this function is not a 
problem (at least not only). Please do some testing and let me know.

Original comment by Luk...@gmail.com on 9 Jan 2014 at 11:50

[GoogleCodeExporter]

Ok I did some testing myself and this fix is working for me. Someone else 
should test and then maybe someone with write-permission will merge it upstream?

Original comment by Luk...@gmail.com on 10 Jan 2014 at 12:06

[GoogleCodeExporter]

Hi all,

Thanks to all users which attempt to fix this long-time bug.

LukSow, thanks for your contribution.

I just push your patch upstream, I hope users will test it and confirm (or not) 
this patch works.

If patch is correct, I'll release a new version of MFCUK.

Thanks!

Original comment by romu...@libnfc.org on 10 Jan 2014 at 1:03

[GoogleCodeExporter]

Issue 25 has been merged into this issue.

Original comment by romu...@libnfc.org on 10 Jan 2014 at 1:05

[GoogleCodeExporter]

I've just run a recover, works ok for me, id is right and key is right.

Thank you for the patch :)

Original comment by algar...@gmail.com on 10 Jan 2014 at 9:30

[GoogleCodeExporter]

Great, I'm glad I could help but you've done the most hard work so kudos to you!

Original comment by Luk...@gmail.com on 10 Jan 2014 at 6:38

[GoogleCodeExporter]

I can confirm this is working, too!

Original comment by S.Elsh...@gmail.com on 10 Jan 2014 at 8:52

[GoogleCodeExporter]

the revision 94 (the last one) works for me too, right key and right uid, 
thanks Luk!!!

Original comment by gonzaloc...@gmail.com on 11 Jan 2014 at 1:46

[GoogleCodeExporter]

Thanks for the quick fix!

Is there anything else that needs working?

Original comment by wwi...@gmail.com on 19 Jan 2014 at 4:01

[GoogleCodeExporter]

Thanks for the Fix !
It's working here

Adafruit PN532
libnfc 1.7.0
mfcuk - 0.3.8 (revision 94)

Original comment by goncapir...@gmail.com on 19 Jan 2014 at 6:50

[GoogleCodeExporter]

Dear all, I've used the last revision (94) but didn't work for me...
how much does it take to recover a key? I've waited for 1-2 hours but the 
process didn't finish at last.
Could you please inform me about your experiences?
Thanks a lot

Original comment by e.moradi...@gmail.com on 28 Jan 2014 at 1:58

[GoogleCodeExporter]

./mfcuk -C -R 0 -v 3 -s 250 -S 250 -o dump.bin

Recovered key A and B from sector 0 in 1 hour

Original comment by goncapir...@gmail.com on 28 Jan 2014 at 3:12

[GoogleCodeExporter]

Goncapir,
I too have the Adafruit PN532, do you get this error while mfcuk is running?
"mfcuk: ERROR: mfcuk_key_recovery_block() (error code=0x03)"
I have a card with default keys I'm testing on and it just sits there for hours 
(12+) without finishing. Any ideas?

Original comment by h.san...@gmail.com on 29 Jan 2014 at 9:09

[GoogleCodeExporter]

After further investigation I found that I seem to be having the same exact 
problem as the one discussed in issue 25. That issue was later merged with this 
issue, but to me it seems like these could be two separate issues that may have 
been mixed.

I can verify keys with the -V flag, but I am unable to crack ANY keys, even 
when specifying default keys with the -d flag. If I try to crack the keys 
normally it will just sit there for hours, I let it run for 24 before giving up.

Not sure it it's related, but when I compile mfcuk I receive the following 
error:
mfcuk.c:247:17: warning: ‘mfcuk_verify_key_block’ defined but not used 
[-Wunused-function]

Again, not sure if this is related as I have found instances of people 
recovering keys even with this error, but a couple of times per minute I get 
the following error:
mfcuk: ERROR: mfcuk_key_recovery_block() (error code=0x03)

My setup:
MFCUK rev.94
libnfc-1.7.0
Adafruit PN532 ver. 1.3
Raspbian 2014-01-07

Here is my output from mfcuk:

    pi@raspberrypi ~/mfcuk/mfcuk-read-only $ mfcuk -C -V 0:A:FFFFFFFFFFFF -s 250 -S 250 -v 2 
    mfcuk - 0.3.8
    Mifare Classic DarkSide Key Recovery Tool - 0.3
    by Andrei Costin, zveriu@gmail.com, http://andreicostin.com

    WARN: cannot open template file './data/tmpls_fingerprints/mfcuk_tmpl_skgt.mfd'
    WARN: cannot open template file './data/tmpls_fingerprints/mfcuk_tmpl_ratb.mfd'
    WARN: cannot open template file './data/tmpls_fingerprints/mfcuk_tmpl_oyster.mfd'

    INFO: Connected to NFC reader: pn532_uart:/dev/ttyAMA0

    INITIAL ACTIONS MATRIX - UID 4d ad 81 9a - TYPE 0x08 (MC1K)
    ---------------------------------------------------------------------
    Sector  |    Key A      |ACTS | RESL    |    Key B      |ACTS | RESL
    ---------------------------------------------------------------------
    0       |  ffffffffffff | V . | . .     |  000000000000 | . . | . .
    1       |  000000000000 | . . | . .     |  000000000000 | . . | . .
    ...

    VERIFY: 
            Key A sectors: 0 1 2 3 4 5 6 7 8 9 a b c d e f
            Key B sectors: 0 1 2 3 4 5 6 7 8 9 a b c d e f

    ACTION RESULTS MATRIX AFTER VERIFY - UID 4d ad 81 9a - TYPE 0x08 (MC1K)
    ---------------------------------------------------------------------
    Sector  |    Key A      |ACTS | RESL    |    Key B      |ACTS | RESL
    ---------------------------------------------------------------------
    0       |  ffffffffffff | V . | V .     |  000000000000 | . . | . .
    1       |  000000000000 | . . | . .     |  000000000000 | . . | . .
    ...

    RECOVER:  0 1 2 3 4 5 6 7 8 9 a b c d e f

    ACTION RESULTS MATRIX AFTER RECOVER - UID 4d ad 81 9a - TYPE 0x08 (MC1K)
    ---------------------------------------------------------------------
    Sector  |    Key A      |ACTS | RESL    |    Key B      |ACTS | RESL
    ---------------------------------------------------------------------
    0       |  ffffffffffff | V . | V .     |  000000000000 | . . | . .
    1       |  000000000000 | . . | . .     |  000000000000 | . . | . .
    ...

With -d flag:

    pi@raspberrypi ~/mfcuk/mfcuk-read-only $ mfcuk -C -R 0:A -d ffffffffffff -s 250 -S 250 -v 2
    mfcuk - 0.3.8
    Mifare Classic DarkSide Key Recovery Tool - 0.3
    by Andrei Costin, zveriu@gmail.com, http://andreicostin.com

    WARN: cannot open template file './data/tmpls_fingerprints/mfcuk_tmpl_skgt.mfd'
    WARN: cannot open template file './data/tmpls_fingerprints/mfcuk_tmpl_ratb.mfd'
    WARN: cannot open template file './data/tmpls_fingerprints/mfcuk_tmpl_oyster.mfd'
    DEFAULT KEYS:
            ff  ff  ff  ff  ff  ff  
            a0  a1  a2  a3  a4  a5  
            b0  b1  b2  b3  b4  b5  
            00  00  00  00  00  00  
            4d  3a  99  c3  51  dd  
            1a  98  2c  7e  45  9a  
            d3  f7  d3  f7  d3  f7  
            aa  bb  cc  dd  ee  ff  
            ff  ff  ff  ff  ff  ff  

    INFO: Connected to NFC reader: pn532_uart:/dev/ttyAMA0

    INITIAL ACTIONS MATRIX - UID 4d ad 81 9a - TYPE 0x08 (MC1K)
    ---------------------------------------------------------------------
    Sector  |    Key A      |ACTS | RESL    |    Key B      |ACTS | RESL
    ---------------------------------------------------------------------
    0       |  000000000000 | . R | . .     |  000000000000 | . . | . .
    1       |  000000000000 | . . | . .     |  000000000000 | . . | . .
    ...

    VERIFY: 
            Key A sectors: 0 1 2 3 4 5 6 7 8 9 a b c d e f
            Key B sectors: 0 1 2 3 4 5 6 7 8 9 a b c d e f

    ACTION RESULTS MATRIX AFTER VERIFY - UID 4d ad 81 9a - TYPE 0x08 (MC1K)
    ---------------------------------------------------------------------
    Sector  |    Key A      |ACTS | RESL    |    Key B      |ACTS | RESL
    ---------------------------------------------------------------------
    0       |  000000000000 | . R | . .     |  000000000000 | . . | . .
    1       |  000000000000 | . . | . .     |  000000000000 | . . | . .
    ...

    RECOVER:  0

Original comment by h.san...@gmail.com on 30 Jan 2014 at 11:38

[GoogleCodeExporter]

What i see from issue 25 is this : "diff Nt: 65536" this means mfcuk has 
received 65536 different nonces from the tag and that's its upper limit before 
giving up. Try running mfcuk with option "-v 3" and see if "diff Nt" and 
"auths" stay equals. If they are approximately equals with a lot of different 
nonces (i think 500 or 100 is enough), i would say you have a tag with a fixed 
prng.

I have experienced the same with a specific crypto-1 tag (the Classic Mini 
found in Disney Infinity figurines). The only explanation I have (it's a guess) 
is that they fixed the pseudo random number generator to keep its state when 
powered off. So it means mfcuk can't get a fixed nonce with its current 
technique (i think it could get it with another one, but not sure if its timing 
control can be accurate enough).

That's a guess, if anyone has a better explanation, I'd be happy to hear it.

Original comment by algar...@gmail.com on 30 Jan 2014 at 12:09