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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] on 22 Feb 2013 at 4:50

[GoogleCodeExporter]

Also looking for a solution. Thanks

Original comment by [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] on 17 Dec 2013 at 8:16

[GoogleCodeExporter]

[deleted comment]

[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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] on 10 Jan 2014 at 1:03

[GoogleCodeExporter]

Issue 25 has been merged into this issue.

Original comment by [email protected] 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 [email protected] 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 [email protected] on 10 Jan 2014 at 6:38

[GoogleCodeExporter]

I can confirm this is working, too!

Original comment by [email protected] 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 [email protected] on 11 Jan 2014 at 1:46

[GoogleCodeExporter]

Thanks for the quick fix!

Is there anything else that needs working?

Original comment by [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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, [email protected], 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, [email protected], 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 [email protected] 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 [email protected] on 30 Jan 2014 at 12:09

[GoogleCodeExporter]

Thanks for the quick response!

I just ran mfcuk again, this time with -v 3 and it seems I may have a slightly 
different issue at hand after all. My "diff Nt" and "auths" are not as equal as 
they were in issue 25.

    $ mfcuk -C -R 0:A -d ffffffffffff -s 250 -S 250 -v 3
    ...
    -----------------------------------------------------
    Let me entertain you!
        uid: 4dad819a
       type: 08
        key: 000000000000
      block: 03
    diff Nt: 84
      auths: 484
    -----------------------------------------------------

Original comment by [email protected] on 30 Jan 2014 at 2:55

[GoogleCodeExporter]

I don't have many explanations for this. But from what i know, the error you 
get : "ERROR: mfcuk_key_recovery_block()", i've seen it sometimes when mfcuk 
had all 8 variations of data corresponding to a single nonce but fails to 
recover the key. It then goes on and try recovering the key with another nonce. 
I'd suggest you to try with other -s/-S values (even defaults) and see if you 
ever recover the key.

If you still can't recover the key, you should maybe try with another tag if 
possible (from an other manufacturer i mean). You can also try with a previous 
version of mfcuk (i'd suggest r65 with libnfc 1.5.1).

If you have the same error, well, i don't know what else it can be. Anyway, i 
think it should be discussed in another issue as it is unrelated to this one.

Original comment by [email protected] on 7 Feb 2014 at 2:10

[GoogleCodeExporter]

Hi,

Please send me r65 version via email or let me how to get its source.  I can 
not find it in Downloads section. (mfcuk-0.3.3 is not present)



Thanks in advance.

Original comment by [email protected] on 16 Mar 2014 at 7:36

[GoogleCodeExporter]

Yavari, in linux you can download it directly from terminal using this command. 

svn checkout -r 65 http://mfcuk.googlecode.com/svn/trunk/ mfcuk-read-only

Original comment by [email protected] on 21 Mar 2014 at 9:20

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Someone managed to solve the problem of "mfcuk_verify_key_block"? 

I remember a year ago I could compile without this error, and could run 
normally, the problem could be an update of some lib dependency? 

Already tried on two different computers with Ubuntu and the same problem 
happens when compiling and when running this.

Original comment by [email protected] on 31 Mar 2014 at 4:53

[GoogleCodeExporter]

hello all, I have a  problem, how install revision 94 in kali linux? 
please I need help!! 
please!

Original comment by [email protected] on 11 Jul 2014 at 12:10

[GoogleCodeExporter]

To get this working on Kali, download the mfcuk.c file from 
https://code.google.com/p/mfcuk/source/browse/trunk/src/mfcuk.c.

Then run through this process 
http://docs.kali.org/development/rebuilding-a-package-from-source and make sure 
to replace the mfcuk.c file in the src directory with the one you downloaded.

When you get to the bit where you need to run dpkg-buildpackage, add -b to the 
command or it will fail. So the command is dpkg-buildpackage -b.

Original comment by [email protected] on 26 Sep 2014 at 11:13

[GoogleCodeExporter]

Alternatively, here's the deb file with the fix implemented for 64 bit 
architecture, just install with dpkg -i mfcuk_0.3.8-0kali3_amd64

Original comment by [email protected] on 26 Sep 2014 at 11:54

Attachments:

• mfcuk_0.3.8-0kali3_amd64.deb

[GoogleCodeExporter]

Hi all,

I've an so called "Eurest à la Carte" Prepaid card for our cantine and my plan 
was to build a little App which shows us the current charge. But I can't get 
the Key A of sector 9-12. mfoc didn't got the key and same for mfcuk. I tried a 
lot of versions all with the same results:

screen mfcuk -C -R 9:A -v 3
...
-----------------------------------------------------

-----------------------------------------------------
Let me entertain you!
    uid: f2dfe2dd
   type: 08
    key: 000000000000
  block: 27
diff Nt: 65535
  auths: 65536
-----------------------------------------------------

-----------------------------------------------------
Let me entertain you!
    uid: f2dfe2dd
   type: 08
    key: 000000000000
  block: 27
diff Nt: 65536
  auths: 65537
-----------------------------------------------------
mfcuk: ERROR: mfcuk_key_recovery_block() (error code=0x09)

-----------------------------------------------------

I killed the tool at this point, I think it makes no sense to keep it running, 
isn't it?

So it could be possible that there are a lot of cards in circulation with fixed 
random generator or whatever...

BR
Daniel

Original comment by [email protected] on 16 Dec 2014 at 8:15

[GoogleCodeExporter]

As I see from a lot of discussion in the WEB, mfcuk doesn't work any more? 

Original comment by [email protected] on 7 Jan 2015 at 9:43