Closed GoogleCodeExporter closed 8 years ago
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
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
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
Also looking for a solution. Thanks
Original comment by benny.j....@gmail.com
on 26 Feb 2013 at 5:19
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
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
[deleted comment]
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
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
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
same here. @adrian: what is the latest version that worked for you?
Original comment by nelu.tarna
on 22 Aug 2013 at 8:46
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
[deleted comment]
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
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
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
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
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
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
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
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
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
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
@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
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
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
[deleted comment]
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
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
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
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
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
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
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
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
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
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
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
Issue 25 has been merged into this issue.
Original comment by romu...@libnfc.org
on 10 Jan 2014 at 1:05
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
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
I can confirm this is working, too!
Original comment by S.Elsh...@gmail.com
on 10 Jan 2014 at 8:52
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
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
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
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
./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
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
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
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
Original issue reported on code.google.com by
romu...@libnfc.org
on 18 Feb 2013 at 8:20