Research, development and trades concerning the powerful Proxmark3 device.
Remember; sharing is caring. Bring something back to the community.
"Learn the tools of the trade the hard way." +Fravia
You are not logged in.
Time changes and with it the technology
Proxmark3 @ discord
Users of this forum, please be aware that information stored on this site is not private.
Pages: 1
If, after 30-60 mins, pm3 is not able to find any key:
Key not found (lfsr_common_prefix list is null). Nt=xxxxxxxxxxrepeated at each attempt
does that means it is impossible to recover the key ?
It should be a mifare 1k; it's the 1st time pm3 is not able to find a key...
If this is a normal behaviour of a new mifare card, the only method will be the snoop one ?
Offline
Good evening every one,
I have the same problem. After 30 mins trying to crack the keys of my vigik card which is report by "hf 14a read" as a NXP MIFARE CLASSIC 1k, I've got no result.
The hf mf mifare commands keep saying :
uid(8b43bXXX) nt(e688841f) par(5bc32b7b4be32bb3) ks(0b0e08060909080c)
|diff|{nr} |ks3|ks3^5|parity |
+----+--------+---+-----+---------------+
| 00 |00000000| b | e |1,1,0,1,1,0,1,0|
| 20 |00000020| e | b |1,1,0,0,0,0,1,1|
| 40 |00000040| 8 | d |1,1,0,1,0,1,0,0|
| 60 |00000060| 6 | 3 |1,1,0,1,1,1,1,0|
| 80 |00000080| 9 | c |1,1,0,1,0,0,1,0|
| a0 |000000a0| 9 | c |1,1,0,0,0,1,1,1|
| c0 |000000c0| 8 | d |1,1,0,1,0,1,0,0|
| e0 |000000e0| c | 9 |1,1,0,0,1,1,0,1|
#db# COMMAND mifare FINISHED
Key not found (lfsr_common_prefix list is null). Nt=e688841f Thank you in advance for your attention to this matter
Offline
Did you try to use the original nonce2key tool, or does this recovered key make no sense at all?
$cd proxmark3/tools/nonce2key
$make
gcc -Wall -O4 -c -o crypto1.o crypto1.c
gcc -Wall -O4 -c -o crapto1.o crapto1.c
gcc -o nonce2key crypto1.o crapto1.o nonce2key.c
$./nonce2key 8b43bXXX e688841f 5bc32b7b4be32bb3 0b0e08060909080c
uid(0008b43b) nt(e688841f) par(5bc32b7b4be32bb3) ks(0b0e08060909080c)
|diff|{nr} |ks3|ks3^5|parity |
+----+--------+---+-----+---------------+
| 00 |00000000| b | e |1,1,0,1,1,0,1,0|
| 20 |00000020| e | b |1,1,0,0,0,0,1,1|
| 40 |00000040| 8 | d |1,1,0,1,0,1,0,0|
| 60 |00000060| 6 | 3 |1,1,0,1,1,1,1,0|
| 80 |00000080| 9 | c |1,1,0,1,0,0,1,0|
| a0 |000000a0| 9 | c |1,1,0,0,0,1,1,1|
| c0 |000000c0| 8 | d |1,1,0,1,0,1,0,0|
| e0 |000000e0| c | 9 |1,1,0,0,1,1,0,1|
key recovered: c5d601250000Offline
The noncekey tool give me a key :
./nonce2key 8b43XXXX 6ee83bb0 5e8eee0626eed696 080b0d0f050d0102
uid(8b43XXXX) nt(6ee83bb0) par(5e8eee0626eed696) ks(080b0d0f050d0102)
|diff|{nr} |ks3|ks3^5|parity |
+----+--------+---+-----+---------------+
| 00 |00000000| 8 | d |0,1,1,1,1,0,1,0|
| 20 |00000020| b | e |0,1,1,1,0,0,0,1|
| 40 |00000040| d | 8 |0,1,1,1,0,1,1,1|
| 60 |00000060| f | a |0,1,1,0,0,0,0,0|
| 80 |00000080| 5 | 0 |0,1,1,0,0,1,0,0|
| a0 |000000a0| d | 8 |0,1,1,1,0,1,1,1|
| c0 |000000c0| 1 | 4 |0,1,1,0,1,0,1,1|
| e0 |000000e0| 2 | 7 |0,1,1,0,1,0,0,1|
key recovered: 5bd286XXXXXXBut when i check it with "hf mf chk *1 ? 5bd286XXXXXX", it doesn't seems to be a right key ...
Offline
I can confirm this problem. Our Proxmark3 has the following config (latest of everything as of this post):
proxmark3> hw version
#db# Prox/RFID mark3 RFID instrument
#db# bootrom: svn 698 2013-04-15 10:55:30
#db# os: svn 698 2013-04-15 10:55:30
#db# FPGA image built on 2012/ 1/ 6 at 15:27:56We are testing on two different types of cards. One type is the regular white MF Classic 1K (not the Chinese but fixed UID). These all have keys 0x000...0 (for A) and 0xFFF...F (for B), which is confirmed by hf mf chk *1 ?. However, when we try the mifare nonce-attack, we get these results:
proxmark3> hf mf mifare
-------------------------------------------------------------------------
Executing command. It may take up to 30 min.
Press the key on the proxmark3 device to abort both proxmark3 and client.
-------------------------------------------------------------------------
.#db# COMMAND mifare FINISHED
isOk:01
uid(8d8fXXXX) nt(5f5ef1a8) par(0000000000000000) ks(090a0b070c0c0b0e)
|diff|{nr} |ks3|ks3^5|parity |
+----+--------+---+-----+---------------+
| 00 |00000000| 9 | c |0,0,0,0,0,0,0,0|
| 20 |00000020| a | f |0,0,0,0,0,0,0,0|
| 40 |00000040| b | e |0,0,0,0,0,0,0,0|
| 60 |00000060| 7 | 2 |0,0,0,0,0,0,0,0|
| 80 |00000080| c | 9 |0,0,0,0,0,0,0,0|
| a0 |000000a0| c | 9 |0,0,0,0,0,0,0,0|
| c0 |000000c0| b | e |0,0,0,0,0,0,0,0|
| e0 |000000e0| e | b |0,0,0,0,0,0,0,0|
Key not found (lfsr_common_prefix list is null). Nt=5f5ef1a8 It doesn't find the key, and after many minutes it seems like it hangs up somehow. The dots continues in the terminal but the LEDs stop blinking and turn to a solid state, usually with yellow, red and green.
On the other type of card we don't know the keys. We are not exactly sure what kind of variant of Mifare it is, this is what we get from the proxmark:
proxmark3> hf 14a reader
ATQA : 04 00
UID : 93 ba XX XX
SAK : 08 [2]
TYPE : NXP MIFARE CLASSIC 1k | Plus 2k
proprietary non iso14443a-4 card found, RATS not supportedThere are some noteworthy differences when we run hf mf mifare on these cards:
The "key not found" messages appear a lot more frequently with the white cards.
The nonces (nt) from the white card are reappearing often in the same run, while the other cards seem to have different nonces each time the "no key found" message appears.
The parity of the white cards are usually 000...0 (as seen above) while the other cards have a more equal distribution between 1:s and 0:s.
May this different behavior be an indication of that the other cards has some protection against the nonce-vulnerability? Perhaps they are a newer generation of Mifare classic, or even Mifare plus? Any help to point in the right direction would be greatly appreciated.
For both types of cards we tried the nonce2key tool. It yielded keys, but the keys didn't work.
Offline
it could be that nonce2key finds multiple keys, it only tests the first one right now (since that is almost always the one). But you could easily patch nonce2key to test all the keys that lfsr_common_prefix() returns.
Offline
Same bug here. I had successfully braked key with "hf mf mifare" on six cards with previous revision don't remember exactly which, but now with this revision I can't brake key on this same six cards I get same situation as members bacon, asper and focus.
I have very low programming skills, maybe administrator Roel you can show for us how to patch nonce2key to test all keys? It would be very helpful... Thanks in advance.
Offline
Roel, I tried following your advice. It seems like the nonce2key tool doesn't check if the list returned from lfsr_common_prefix() is empty or what size it has. (Maybe this should go to the issue tracker?)
This is a patch I made, for the nonce2key tool, to try to find a potential key for each of the returned "Crypto1State" list. I'm still fairly new to this thing, so I might have done something stupid, anyway here goes (just apply svn patch and run make in the tools/nonce2key dir):
$ svn diff
Index: tools/nonce2key/nonce2key.c
===================================================================
--- tools/nonce2key/nonce2key.c (revision 696)
+++ tools/nonce2key/nonce2key.c (working copy)
@@ -6,7 +6,7 @@
typedef unsigned char byte_t;
int main(const int argc, const char* argv[]) {
- struct Crypto1State *state;
+ struct Crypto1State *statelist, state;
uint32_t pos, uid, nt, nr, rr, nr_diff, ks1, ks2;
byte_t bt, i, ks3x[8], par[8][8];
uint64_t key, key_recovered;
@@ -48,12 +48,17 @@
for (pos=0; pos<7; pos++) printf("%01x,",par[i][pos]);
printf("%01x|\n",par[i][7]);
}
-
- state = lfsr_common_prefix(nr,rr,ks3x,par);
- lfsr_rollback_word(state,uid^nt,0);
- crypto1_get_lfsr(state,&key_recovered);
- printf("\nkey recovered: %012"llx"\n\n",key_recovered);
- crypto1_destroy(state);
-
+ statelist = lfsr_common_prefix(nr,rr,ks3x,par);
+ int j;
+ for (j = 0; j < 10; j++) {
+ state = *(statelist + j);
+
+ // Check for "0-value", which indicates end-of-list
+ if (state.odd == 0 && state.even == 0) break;
+ lfsr_rollback_word(&state,uid^nt,0);
+ crypto1_get_lfsr(&state,&key_recovered);
+ printf("\npotential key recovered: %012"llx"\n\n",key_recovered);
+ }
+ printf("\n%i potential keys recovered\n\n", j);
return 0;
}I took the output I got from running hf mf mifare (on the white card) and inputed it directly to the modified nonce2key tool:
$ ./nonce2key 8d8fXXXX 5f5ef1a8 0000000000000000 070a0b070c0c0b0e
uid(8d8fXXXX) nt(5f5ef1a8) par(0000000000000000) ks(070a0b070c0c0b0e)
|diff|{nr} |ks3|ks3^5|parity |
+----+--------+---+-----+---------------+
| 00 |00000000| 7 | 2 |0,0,0,0,0,0,0,0|
| 20 |00000020| a | f |0,0,0,0,0,0,0,0|
| 40 |00000040| b | e |0,0,0,0,0,0,0,0|
| 60 |00000060| 7 | 2 |0,0,0,0,0,0,0,0|
| 80 |00000080| c | 9 |0,0,0,0,0,0,0,0|
| a0 |000000a0| c | 9 |0,0,0,0,0,0,0,0|
| c0 |000000c0| b | e |0,0,0,0,0,0,0,0|
| e0 |000000e0| e | b |0,0,0,0,0,0,0,0|
0 potential keys recoveredSomething is obviously fishy, but I don't know why.
Offline
So anyone have success on this bug? Because I can't use hf mf mifare for long time... please help what to do
Offline
Pages: 1