strange sittuation with key recovery, the card dosen´t give an answer

thefkboss · 2011-06-23 15:50:14

i have a card mifare 1k that when i try to recover the key with hf mf mifare

proxmark3> hf mf mifare
-------------------------------------------------------------------------
Executing command. It may take up to 30 min.
Press the key on proxmark3 device to abort proxmark3.
Press the key on the proxmark3 device to abort both proxmark3 and client.
-------------------------------------------------------------------------
#db# COMMAND mifare FINISHED
>

isOk:01

uid(6c20d425) nt(a65f4631) par(0000000000000000) ks(050609060b0f0806)

|diff|{nr} |ks3|ks3^5|parity |
+----+--------+---+-----+---------------+
| 00 |00000000| 5 | 0 |0,0,0,0,0,0,0,0|
| 20 |00000020| 6 | 3 |0,0,0,0,0,0,0,0|
| 40 |00000040| 9 | c |0,0,0,0,0,0,0,0|
| 60 |00000060| 6 | 3 |0,0,0,0,0,0,0,0|
| 80 |00000080| b | e |0,0,0,0,0,0,0,0|
| a0 |000000a0| f | a |0,0,0,0,0,0,0,0|
| c0 |000000c0| 8 | d |0,0,0,0,0,0,0,0|
| e0 |000000e0| 6 | 3 |0,0,0,0,0,0,0,0|
------------------------------------------------------------------
Key found:2cb03d140000

Found invalid key. ( Nt=a65f4631
proxmark3>

proxmark3> hf 14a list
recorded activity:
ETU :rssi: who bytes
---------+----+----+-----------
+ 0: : 52
+ 236: 0: TAG 04 00
+ 0: : 93 20
+ 452: 0: TAG 6c 20 d4 25 bd
+ 0: : 93 70 6c 20 d4 25 bd c7 5f
+ 308: 0: TAG 08 b6 dd
+ 0: : 60 00 f5 7b
+ 404: 0: TAG 4c ad dc f6
+ 0: : a1 1a 07 53 e6 7c 0d ac !crc
+ 124: 0: TAG 09!

but nested recover all the keys fine

why this happend?
i have encreased spin delay with the same result

Last edited by thefkboss (2011-06-23 16:03:22)

merlok · 2011-06-23 17:56:12

there is a strange parity "0,0,0,0,0,0,0,0"
it seems, there is no calc parity at all
Tomorrow Ill look into the code and maybe ill find something (why it happend)

may you issue the command:
hf mf mifare a65f4631
and post here the results

Last edited by merlok (2011-06-23 17:56:47)

thefkboss · 2011-06-23 18:58:08

the same result

Connected units:
1. SN: ChangeMe [bus-0/\\.\libusb0-0002--0x9ac4-0x4b8f]
proxmark3> hf mf mifare a65f4631
-------------------------------------------------------------------------
Executing command. It may take up to 30 min.
Press the key on proxmark3 device to abort proxmark3.
Press the key on the proxmark3 device to abort both proxmark3 and client.
-------------------------------------------------------------------------
..

isOk:01

uid(6c20d425) nt(987e19c5) par(0000000000000000) ks(0a030906000f0701)

|diff|{nr} |ks3|ks3^5|parity |
+----+--------+---+-----+---------------+
| 00 |00000000| a | f |0,0,0,0,0,0,0,0|
| 20 |00000020| 3 | 6 |0,0,0,0,0,0,0,0|
| 40 |00000040| 9 | c |0,0,0,0,0,0,0,0|
| 60 |00000060| 6 | 3 |0,0,0,0,0,0,0,0|
| 80 |00000080| 0 | 5 |0,0,0,0,0,0,0,0|
| a0 |000000a0| f | a |0,0,0,0,#db# COMMAND mifare FINISHED
0,0,0,0|
| c0 |000000c0| 7 | 2 |0,0,0,0,0,0,0,0|
| e0 |000000e0| 1 | 4 |0,0,0,0,0,0,0,0|
------------------------------------------------------------------
Key found:af99b6e70000

Found invalid key. ( Nt=987e19c5
proxmark3>

proxmark3> hf 14a list
recorded activity:
ETU :rssi: who bytes
---------+----+----+-----------
+ 0: : 52
+ 236: 0: TAG 04 00
+ 0: : 93 20
+ 452: 0: TAG 6c 20 d4 25 bd
+ 0: : 93 70 6c 20 d4 25 bd c7 5f
+ 308: 0: TAG 08 b6 dd
+ 0: : 60 00 f5 7b
+ 404: 0: TAG 62 6a e5 b6
+ 0: : fb 1a e0 34 a7 58 7b 39 !crc
+ 124: 0: TAG 0a!
proxmark3>

uberdude · 2011-06-26 22:31:33

I've run into this same problem. Tried it 4 times with the Nt from the previous attempt. I'll take a look at it when I get a chance.

uberdude · 2011-07-21 01:30:46

I've been reading up on the darkside attack to try to understand the program and possibly fix this problem. In the original article by Courtois, section 5, he states,

"A pre-requisite for our attack is a strict control of the timing of the transaction....we read that the accuracy of selecting a chosen nt by controlling the timing with a Proxmark3 device is 1 out of 10."

Have we just been unlucky? Or does the firmware understand this jitter in the timing of a proxmark and reject the nt's which do not fit the strict timing scheme necessary to make the dark side attack work? Is there a way to get around this inherent (?) limitation of the pm3?

moebius · 2011-07-21 18:14:34

Same problem here.. last REV invalid key is found...

right now trying nested...

I really don't understand why does the output say: found valid key: 0000[other bytes here]... the real key doesn't start with 0000 !?

thanx!

henry2010 · 2011-08-21 03:03:05

Sme result , do you using 64bits windows system?
found valid key: other bytes here]0000,[.. the real key doesn't end with 0000 .

Any idea?

merlok · 2011-08-25 19:20:10

Hi,

maybe there is some kind of "unlicensed" card.
some of that card always sends NACK answer.
and because of that there is so strange parity : (0000000000000000)

moebius · 2011-08-26 01:30:15

Same here.. those fuc**ng parity bits in zero...

let's keep trying guys..

moebius · 2011-08-26 01:39:20

merlok wrote:

Hi,
maybe there is some kind of "unlicensed" card.
some of that card always sends NACK answer.
and because of that there is so strange parity : (0000000000000000)

So, no Darkside attack (card only) is possible?

uberdude · 2011-11-20 18:51:39

Working on it a bit more, it seems that it is not just a darkside problem, but a problem with the nested command... here is a screencap with a factory key

Additionally, I changed a few of the passwords and it still gives me problems on the nested attack.

Not sure what is going on here... any ideas?

aminbakhtvar62 · 2012-01-15 16:11:14

its possible to solve it .u should just be aware that the "res" column is in decimal and by changing it to hex and replacing with the initial zeros it will give u the keys

aminbakhtvar62 · 2012-01-15 16:20:18

but still no idea about hf mf mifare.any help would be apreciated

moebius · 2012-02-27 00:50:28

When doing the nested attack, the output has 0000 in front of the real key... for example 0000FFFFFFFF ... ant thoughts?

Thanks!

olivm · 2012-02-29 16:04:46

Had the same issue with 0000, and came up with the following patch, because it is needed for keyB :
Add the line

PrintAndLog("Found valid key first part:%04llx", key64>>(8*8));

in ProxSpace\pm3\client\cmdhfmf.c on line 573
This might be necessary also on lines 79 and 633

It works for me

moebius · 2012-03-04 00:32:32

It worked for me too.

Maybe someone can update the code in the svn.

Cheers!

o0o0o0o · 2012-04-04 15:00:50

I have modified line 573, 79 and 634 but same thing is happening :

uid(c2b8c019) nt(7df7f623) par(0000000000000000) ks(090c0c02030d0c0e)

|diff|{nr} |ks3|ks3^5|parity |
+----+--------+---+-----+---------------+
#db# COMMAND mifare FINISHED
| 00 |00000000| 9 | c |0,0,0,0,0,0,0,0|
| 20 |00000020| c | 9 |0,0,0,0,0,0,0,0|
| 40 |00000040| c | 9 |0,0,0,0,0,0,0,0|
| 60 |00000060| 2 | 7 |0,0,0,0,0,0,0,0|
| 80 |00000080| 3 | 6 |0,0,0,0,0,0,0,0|
| a0 |000000a0| d | 8 |0,0,0,0,0,0,0,0|
| c0 |000000c0| c | 9 |0,0,0,0,0,0,0,0|
| e0 |000000e0| e | b |0,0,0,0,0,0,0,0|
------------------------------------------------------------------
Key found:cdbdf93b0000
#db# setfpga
#db# field_on
#db# tx WUPA: 52
#db# tx WUPA: 93 20
#db# RX: C2 B8 C0 19 A3
#db# tx SELUID: 93 70 C2 B8 C0 19 A3 A5 DF
#db# RX: 08 B6 DD
#db# NO 14a
Found invalid key. ( Nt=7df7f623

proxmark3> hf 14a list
recorded activity:
ETU :rssi: who bytes
---------+----+----+-----------
+ 0: : 52
+ 228: 0: TAG 04 00
+ 0: : 93 20
+ 444: 0: TAG c2 b8 c0 19 a3
+ 0: : 93 70 c2 b8 c0 19 a3 a5 df
+ 300: 0: TAG 08 b6 dd
+ 0: : 60 00 f5 7b
+ 396: 0: TAG 47 d4 7c 9d
+ 0: : 04 92 09 55 5e 6a 57 87 !crc
+ 116: 0: TAG 07

proxmark3> hf mf mifare 7df7f623
isOk:01
#db# COMMAND mifare FINISHED

uid(c2b8c019) nt(38330878) par(0000000000000000) ks(07090a050202080a)

|diff|{nr} |ks3|ks3^5|parity |
+----+--------+---+-----+---------------+
| 00 |00000000| 7 | 2 |0,0,0,0,0,0,0,0|
| 20 |00000020| 9 | c |0,0,0,0,0,0,0,0|
| 40 |00000040| a | f |0,0,0,0,0,0,0,0|
| 60 |00000060| 5 | 0 |0,0,0,0,0,0,0,0|
| 80 |00000080| 2 | 7 |0,0,0,0,0,0,0,0|
| a0 |000000a0| 2 | 7 |0,0,0,0,0,0,0,0|
| c0 |000000c0| 8 | d |0,0,0,0,0,0,0,0|
| e0 |000000e0| a | f |0,0,0,0,0,0,0,0|
------------------------------------------------------------------
Key found:eb9ff1620000
#db# setfpga
#db# field_on
#db# tx WUPA: 52
#db# tx WUPA: 93 20
#db# RX: C2 B8 C0 19 A3
#db# tx SELUID: 93 70 C2 B8 C0 19 A3 A5 DF
#db# RX: 08 B6 DD
#db# NO 14a
Found invalid key. ( Nt=38330878
proxmark3>

What about you thefkboss, does the solution given by olivm worked ?

olivm · 2012-04-06 15:39:59

o0o0o0o wrote:

What about you thefkboss, does the solution given by olivm worked ?

Here is what I use :

proxmark3> hf mf nested o 0 a a0a1a2a3a4a5 a 0
--block no:00 key type:00 key:a0 a1 a2 a3 a4 a5 etrans:0
--target block no:00 target key type:01

...uid:XXXXXXXXX len=3 trgbl=0 trgkey=1
.uid:XXXXXXXXX len=1 trgbl=0 trgkey=1
.uid:XXXXXXXXX len=3 trgbl=0 trgkey=1
.uid:XXXXXXXXX len=1 trgbl=0 trgkey=1
.uid:XXXXXXXXX len=3 trgbl=0 trgkey=1
.------------------------------------------------------------------
Total keys count:579487
cnt=0 key= b0 b1 b2 b3 b4 b5
cnt=1 key= e1 f4 75 f2 78 9b
cnt=2 key= 50 d7 75 f2 47 8a
cnt=3 key= ad e2 75 f1 da 31
cnt=4 key= 5d b1 75 f1 68 8e
cnt=5 key= 2a 0a 75 f0 da 33
cnt=6 key= ae 07 75 f0 9f 22
cnt=7 key= 4b d9 75 f0 9f 20
cnt=8 key= 2b 8f 75 f0 90 e0
cnt=9 key= 11 99 75 f0 79 b1
cnt=10 key= 13 e7 75 f0 6d b0
cnt=11 key= a5 13 75 f3 1b 57
cnt=12 key= bc 32 75 ed c3 e5
cnt=13 key= 21 31 75 ed b7 9a
cnt=14 key= fb 11 75 ec bc 6c
cnt=15 key= 99 e6 75 ec a4 e7
Found valid key:0000b2b3b4b5
Found valid key first part :b0b1
proxmark3>

thefkboss · 2012-04-06 17:11:04

for me it dosen´t work

vandreas · 2012-04-06 18:44:44

with revision 528
hf mf mifare gives invalid keys par(0000000000000000) ks(0000000000000000)
with nested attack the output has 0000 in front of the real key

olivm · 2012-04-09 09:26:48

For the 0000 in front of the key : I've given a solution for the nested attack. You seem to be using the brute force attack => the same patch should work if you apply it for the brute force function. Sorry, I don't have the code&device right now to help you more, but I'm sure that you can find the other places where to add the patch

vandreas · 2012-04-10 16:28:02

olivm wrote:

For the 0000 in front of the key : I've given a solution for the nested attack. You seem to be using the brute force attack => the same patch should work if you apply it for the brute force function. Sorry, I don't have the code&device right now to help you more, but I'm sure that you can find the other places where to add the patch

Yes I'm using the brute force attack. It gives me 0000 in the beginning and end of the key. (eg. 0000 ac23 0000)
How do I apply the patch for the trailing zeros? I 'm a C#/python developer and I don't quite understand your code,
but I found where I should place it. Is the par(0000000000000000) ks(0000000000000000) normal?

olivm · 2012-04-10 18:10:08

tell me where you found to add it, I'll have a look at the code
As for me, the brute force attack did not find the key (or I timed-out before)

vandreas · 2012-04-11 13:09:55

Thank you very much for your help. I really appreciate it.

So in http://code.google.com/p/proxmark3/source/browse/trunk/client/cmdhfmf.c
For the brute force attack:

line 74-75
PrintAndLog("Key found:%012llx \n", r_key);
PrintAndLog("Found valid key first part:%04llx", key64>>(8*8));

It gives the 1st 4 key digits but not the last 4

For the nested attack (I commented out the i array index, it does not let me post otherwise):

I change line 646-647:
PrintAndLog("|%03d| %012llx | %d | %012llx | %d |", i,
e_sector['i'].Key[0], e_sector['i'].foundKey[0], e_sector['i'].Key[1], e_sector['i'].foundKey[1]);

to:
PrintAndLog("|%03d| %012llx | %x | %012llx | %d | %04llx", i,
e_sector['i'].Key[0], e_sector['i'].foundKey[0], e_sector['i'].Key[1], e_sector['i'].foundKey[1], e_sector['i'].Key[0]>>(8*8));

line 611: e_sector['i'].Key[j] = key64;
The key is 11ffffffffff

The res column shows the correct 4 digits when I change %d to %x: 11ff
Your code gives me : ffff

I have a proxmark3 and an Omnikey 5321 reader.
Do you know if I can use the mfcuk with those?
I can't seem to find info on the web.

Thanks again

Last edited by vandreas (2012-04-11 13:21:16)

olivm · 2012-04-11 16:44:18

vandreas wrote:

For the brute force attack:
line 74-75
PrintAndLog("Key found:%012llx \n", r_key);
PrintAndLog("Found valid key first part:%04llx", key64>>(8*8));

I can't test it, but I'd rather write :

PrintAndLog("Key found:%012llx \n", r_key);
PrintAndLog("Key found first part:%04llx \n", r_key>>(8*8));
...
if (!isOK)
{
PrintAndLog("Found valid key:%012llx", r_key);
PrintAndLog("Found valid key first part:%04llx", r_key>>(8*8));
}

vandreas wrote:

For the nested attack (I commented out the i array index, it does not let me post otherwise):

I would take the same approach as you do with a

PrintAndLog("|%03d| %012llx (%04lx)| %d | %012llx (%04lx)| %d |", i,
e_sector['i'].Key[0], (e_sector['i'].Key[0])>>(8*8), e_sector['i'].foundKey[0], e_sector['i'].Key[1], (e_sector['i'].Key[1])>>(8*8), e_sector['i'].foundKey[1]);

But once again, I'm blind cause I can't test it.

vandreas wrote:

Do you know if I can use the mfcuk with those?

I'm no expert in that (yet?), sorry...

vandreas · 2012-04-12 12:30:22

if (!isOK) :

it doesnt go in here. It branches to the else part.

However it spits out a key previously in the: PrintAndLog("Key found:%012llx \n", r_key);
in the form 0000 xxxx 0000 which repeats itself (at least the middle part does) after a couple of tries so I thought i d test it if I could see it. (I also try with the nonce it gives me). But I still cant see the last 4 digits.

In the nested attack your code spits the wrong answer for me. Why do you shift the key? Is it a formatting issue?

olivm · 2012-04-12 13:05:39

Yes. The original code expects the system to handle a 12-digit output for a long, which obviously on our 32bit-systems is not the case.
So I shift the long to skip the first 8 digits, so that printf can display to 4 remaining digits.

vandreas · 2012-04-17 12:44:01

OK I swiched to 64-bit system and the nested attack worked. It shows all digits.
You were absolutely right olivm. Thank you.

The brute force attack however cycles through some keys of the form: xxxx xxxx 0000
is par(0000000000000000) normal?
I also try the Nt it gives me but still nothing

It gives repeated invalid keys

Last edited by vandreas (2012-04-17 15:21:50)

Proxmark3 community

Announcement

#1 2011-06-23 15:50:14

strange sittuation with key recovery, the card dosen´t give an answer

#2 2011-06-23 17:56:12

Re: strange sittuation with key recovery, the card dosen´t give an answer

#3 2011-06-23 18:58:08

Re: strange sittuation with key recovery, the card dosen´t give an answer

#4 2011-06-26 22:31:33

Re: strange sittuation with key recovery, the card dosen´t give an answer

#5 2011-07-21 01:30:46

Re: strange sittuation with key recovery, the card dosen´t give an answer

#6 2011-07-21 18:14:34

Re: strange sittuation with key recovery, the card dosen´t give an answer

#7 2011-08-21 03:03:05

Re: strange sittuation with key recovery, the card dosen´t give an answer

#8 2011-08-25 19:20:10

Re: strange sittuation with key recovery, the card dosen´t give an answer

#9 2011-08-26 01:30:15

Re: strange sittuation with key recovery, the card dosen´t give an answer

#10 2011-08-26 01:39:20

Re: strange sittuation with key recovery, the card dosen´t give an answer

#11 2011-11-20 18:51:39

Re: strange sittuation with key recovery, the card dosen´t give an answer

#12 2012-01-15 16:11:14

Re: strange sittuation with key recovery, the card dosen´t give an answer

#13 2012-01-15 16:20:18

Re: strange sittuation with key recovery, the card dosen´t give an answer

#14 2012-02-27 00:50:28

Re: strange sittuation with key recovery, the card dosen´t give an answer

#15 2012-02-29 16:04:46

Re: strange sittuation with key recovery, the card dosen´t give an answer

#16 2012-03-04 00:32:32

Re: strange sittuation with key recovery, the card dosen´t give an answer

#17 2012-04-04 15:00:50

Re: strange sittuation with key recovery, the card dosen´t give an answer

#18 2012-04-06 15:39:59

Re: strange sittuation with key recovery, the card dosen´t give an answer

#19 2012-04-06 17:11:04

Re: strange sittuation with key recovery, the card dosen´t give an answer

#20 2012-04-06 18:44:44

Re: strange sittuation with key recovery, the card dosen´t give an answer

#21 2012-04-09 09:26:48

Re: strange sittuation with key recovery, the card dosen´t give an answer

#22 2012-04-10 16:28:02

Re: strange sittuation with key recovery, the card dosen´t give an answer

#23 2012-04-10 18:10:08

Re: strange sittuation with key recovery, the card dosen´t give an answer

#24 2012-04-11 13:09:55

Re: strange sittuation with key recovery, the card dosen´t give an answer

#25 2012-04-11 16:44:18

Re: strange sittuation with key recovery, the card dosen´t give an answer

#26 2012-04-12 12:30:22

Re: strange sittuation with key recovery, the card dosen´t give an answer

#27 2012-04-12 13:05:39

Re: strange sittuation with key recovery, the card dosen´t give an answer

#28 2012-04-17 12:44:01

Re: strange sittuation with key recovery, the card dosen´t give an answer

Board footer