Proxmark developers community

Research, development and trades concerning the powerful Proxmark3 device!

You are not logged in.

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

thefkboss
Contributor
Registered: 2008-10-26
Posts: 151

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

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)

Offline

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

merlok
Contributor
Registered: 2011-05-16
Posts: 108

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

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)

Offline

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

thefkboss
Contributor
Registered: 2008-10-26
Posts: 151

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

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>

Offline

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

uberdude
Member
Registered: 2011-05-24
Posts: 17

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

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.

Offline

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

uberdude
Member
Registered: 2011-05-24
Posts: 17

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

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?

Offline

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

moebius
Moderator
Registered: 2011-03-10
Posts: 191

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

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

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!

Offline

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

henry2010
Member
Registered: 2010-06-11
Posts: 9

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

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?

Offline

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

merlok
Contributor
Registered: 2011-05-16
Posts: 108

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

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)

Offline

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

moebius
Moderator
Registered: 2011-03-10
Posts: 191

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

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

let's keep trying guys..

Offline

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

moebius
Moderator
Registered: 2011-03-10
Posts: 191

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

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?

Offline

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

uberdude
Member
Registered: 2011-05-24
Posts: 17

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

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

screencapdd.jpg

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

screencap2j.jpg

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

Offline

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

aminbakhtvar62
Member
Registered: 2011-02-23
Posts: 24

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

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

Offline

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

aminbakhtvar62
Member
Registered: 2011-02-23
Posts: 24

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

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

Offline

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

moebius
Moderator
Registered: 2011-03-10
Posts: 191

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

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

Thanks!

Offline

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

olivm
Member
Registered: 2012-02-29
Posts: 6

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

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 smile

Offline

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

moebius
Moderator
Registered: 2011-03-10
Posts: 191

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

It worked for me too.

Maybe someone can update the code in the svn.

Cheers!

Offline

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

o0o0o0o
Contributor
From: Germany
Registered: 2011-10-06
Posts: 64

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

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 ?

Offline

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

olivm
Member
Registered: 2012-02-29
Posts: 6

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

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>

Offline

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

thefkboss
Contributor
Registered: 2008-10-26
Posts: 151

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

for me it dosen´t work

Offline

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

vandreas
Member
Registered: 2012-03-26
Posts: 5

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

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

Offline

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

olivm
Member
Registered: 2012-02-29
Posts: 6

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

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 wink

Offline

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

vandreas
Member
Registered: 2012-03-26
Posts: 5

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

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 wink

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?

Offline

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

olivm
Member
Registered: 2012-02-29
Posts: 6

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

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 sad (or I timed-out before)

Offline

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

vandreas
Member
Registered: 2012-03-26
Posts: 5

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

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)

Offline

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

olivm
Member
Registered: 2012-02-29
Posts: 6

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

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...

Offline

Board footer

Powered by FluxBB