Mifare Plus Atack

my_fair_cats_sick · 2016-07-22 14:27:05

I have noticed with many runs on the same card, that sometimes even with the original value for GOOD_BYTES_REQUIRED, that I get back the incorrect key (well, at least not the key I set). I would say it's about a 30% failure rate.

Is it possible that the cheap cards I have can have multiple keys that work (seems crazy) - or is there something in the attack that still makes it think it got the right answer but it really didn't? I may add a check to auth to the sector using the key found so that it can provide an answer with 100% confidence or just say it failed.

piwi · 2016-07-22 17:13:32

That's expected. Remember that we are guessing only. With the original setting 30 guessed Sum properties are used for key space reduction. You should have a smaller failure rate with the lower value of 10 but still around 15%.

my_fair_cats_sick · 2016-07-22 17:25:13

Ok thanks. Would it be useful to just have that guessed key actually try and auth to the block under question, see that it doesn't work and then start over? It would just be a level of automation over doing all that by hand. Nothing to special to code that up but I might do it for my own purposes. If you'd like me to just branch it somewhere I can do that or just pass on the code if anyone wants it.

I'd like to improve the actual attack time as well, so i'm still looking into understanding the sum portion and if there is any way we can predict the number of nonces needed, and also then look to see if I can understand the bitfipping and implement the 2nd byte portion.

@iceman is your latest branch using the latest @piwi code? If so, thats what i'm adding to. I'll branch whatever repo is easier for you guys to merge changes in with. Want to make this easiest for everyone who cares to use it.

iceman · 2016-07-22 21:57:47

Yes, my fork has piwi's hardnested imp.

Suggestions,
if you want to fiddle with @piwi's attack implemention, do it in his fork and dedicated branch.
if you want to fiddle with the complete code (ie piwi's attack imp and azcid's brute force solver), do it in my fork.

I'll find your changes once you make a PR since I keep scanning Github for Proxmark3 code all the time.
or send me a mail/mess when you are ready to make a PR.

my_fair_cats_sick · 2016-07-24 19:15:22

So I have implemented a check for if the hardnested "guessed" key is correct or not and recursively call brute_force() if not. What is interesting (to me anyway) is that the brute force answer continues to come up with different answers but incorrect over and over once it's bad. What is also interesting is that the wrong guesses repeat exactly in the same order! That is confusing to me at the moment. I also tried doing a full re-run of the hardnested attack with the same input parameters (not disconnection from the proxmark or not, just immediately re-running it) and I continue to get the exact same wrong answers, in the exact same order.

For example - my correct key for block 3 is 0x123456789009. When I get the wrong answer, the first time is always 0x2468acf12012, then the second try is always 0x369d0369b01b, and I could go on here...and it repeats. This is odd to me but I also don't understand every detail of the attack. Here is actually the sequence of bad guesses - another interesting fact is that the first digit is increasing by one each guess, and then it's actually seems to get larger than 6 bytes and roll over somehow? Maybe this is some undefined behavior.

2468acf12012
369d0369b01b
48d159e24024
5b05b05ad02d
6d3a06d36036
7f6e5d4bf03f
91a2b3c48048
a3d70a3d1051
b60b60b5a05a
c83fb72e3063
a740da6c06c
eca8641f5075
fedcba97e07e
1111111107087

I'm wondering if the pro's here think it's worth doing an analysis somehow on the nonces collected and possibly be able to tell as they are collected if they are "useful" or not.

Relying on 10 good bytes collected vs 28 definitely speeds up the attack, which is why i wanted to try that in conjunction with checking if the guess is correct or not. This is nice in my case because the brute force time is very short - like 10-15 seconds. If it was stuck in there for hours this wouldn't make sense to do anymore.

Last edited by my_fair_cats_sick (2016-07-25 02:40:51)

my_fair_cats_sick · 2016-07-27 12:23:32

what else is interesting is the attack seems to fail every other run - and I must disconnect and reconnect to the proxmark. Still seems so far that the failures are predictable. I still need to analyze the nonces but was hoping before I put that time in anyone could comment and say thats expected for some reason or not.

iceman · 2016-07-27 12:28:26

Do you have the latest changes in my fork when doing these test? or did you merge the patch yourself?
The repeating pattering I think is fixed.

my_fair_cats_sick · 2016-07-27 12:36:00

I run everything with:

docker run -it --device="/dev/ttyACM0" -v $HOME/Downloads:/opt/proxmark3/Data iceman1001/proxmark3:1.6.2

To be honest i'm not docker savvy - how do I update to the latest from here? I thought this pulled the latest for me.

Last edited by my_fair_cats_sick (2016-07-27 12:42:20)

iceman · 2016-07-27 12:45:20

well, no, you missed something in the readme

That is the correct way of running the docker image. all fine.
However if you want to get the latest source / compile, you need to

-> ./start.sh

That will pull & compile from GitHub. You might need to flash your firmware also..

my_fair_cats_sick · 2016-07-27 12:49:43

Thanks - is this normal near the end of the compile?

gcc -O3 -Wall -DLUA_COMPAT_ALL -DLUA_USE_LINUX    -c -o linit.o linit.c
ar rcu liblua.a lapi.o lcode.o lctype.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o lbitlib.o lcorolib.o ldblib.o liolib.o lmathlib.o loslib.o lstrlib.o ltablib.o loadlib.o linit.o 
ranlib liblua.a
gcc -O3 -Wall -DLUA_COMPAT_ALL -DLUA_USE_LINUX    -c -o lua.o lua.c
gcc -o lua   lua.o liblua.a -lm -Wl,-E -ldl -lreadline -ltermcap -lncurses 
/usr/bin/ld: cannot find -lncurses
collect2: error: ld returned 1 exit status
make[3]: *** [lua] Error 1
make[3]: Leaving directory `/opt/proxmark3/liblua'
make[2]: *** [linux] Error 2
make[2]: Leaving directory `/opt/proxmark3/liblua'
make[1]: *** [lua_build] Error 2
make[1]: Leaving directory `/opt/proxmark3/client'
make: *** [client/all] Error 2

osys · 2016-07-27 12:51:02

apt-get install libncurses5-dev

my_fair_cats_sick · 2016-07-27 12:54:25

Ok thanks - will that stay in the docker image from now on or do I need to save it somehow?

my_fair_cats_sick · 2016-07-27 14:55:01

Seems it just hangs for me...do I need to update the bootloader as well?

##################################################
##                                              ##
## Iceman fork, docker container version 1.6.2  ##
##                                              ##
##################################################
# You can now flash the device or run the client
#
# client/flasher /dev/ttyACM0 armsrc/obj/fullimage.elf
#
# or
#
# cd client && ./proxmark3 /dev/ttyACM0
#

root@2b861cdf6155:~# client/flasher /dev/ttyACM0 armsrc/obj/fullimage.elf
Loading ELF file 'armsrc/obj/fullimage.elf'...
Loading usable ELF segments:
0: V 0x00102000 P 0x00102000 (0x00030080->0x00030080) [R X] @0x94
1: V 0x00200000 P 0x00132080 (0x00001ae4->0x00001ae4) [RW ] @0x30114
Note: Extending previous segment from 0x30080 to 0x31b64 bytes

Waiting for Proxmark to appear on /dev/ttyACM0. Found.
Entering bootloader...
(Press and release the button only to abort)
Waiting for Proxmark to reappear on /dev/ttyACM0.......................................................................................................................................................................
...........................................................................................................................................................................................
...........................................................................................................................................................................................
...........................................................................................................................................................................................
...........................................................................................................................................................................................
..............

Last edited by my_fair_cats_sick (2016-07-27 14:56:24)

iceman · 2016-07-27 18:21:26

How about you start another thread about flashing the pm3 device in the docker container.

my_fair_cats_sick · 2016-07-27 18:31:37

OK will do. Feel free to delete these from this thread.

piwi · 2016-07-27 20:09:23

Please don't invest too much time. I do have a much improved version nearly ready. Give me a few weeks more.

May I have the UID of your test card in order to run tests with my improved version and to compare results?

my_fair_cats_sick · 2016-07-27 20:49:26

UID : 04 5D 95 4A 95 36 80

May I ask how is that all you need?

I am working on a project to learn more about this technology as well - so even though your work will likely supercede mine, I would still like to learn, stay on top of it and contribute what I can.

piwi · 2016-07-28 12:25:29

my_fair_cats_sick wrote:

UID : 04 5D 95 4A 95 36 80
May I ask how is that all you need?

The cypher is initialized with UID and key. You had already provided the key in one of your previous posts. This is all we need to generate encrypted nonces in order to test the attack.

iceman · 2016-07-28 16:14:04

Nice to hear from you @piwi, didn't think you liked working in the summer with this stuff. The sun is shining you know.

my_fair_cats_sick · 2016-07-28 18:46:21

I see just the latest branch from @iceman works much more consistenly with even just 10 good bytes. My card works every time now over and over! Is there a good description of how that was fixed? Otherwise I'll just go look at the GitHub change log - because I know developers always document their changes so well

iceman · 2016-07-28 19:10:53

Piwi's implementation was aimed at implementing the attack, so there bound to be some bugs with respect to variables.
The key and repeating attack was some resetting of the variables. You can see it in the changelog (or diff for the file)

my_fair_cats_sick · 2016-08-03 17:42:59

I am comparing the @aczid solver with Libnfc and the PM3 solution in @iceman's docker image which uses @piwi's hardnested implementation. It appears the PM3 performs much better at finding valid solutions on some cards. The @aczid solver tries over and over and claims it can't find a solution - but PM3 finds it no problem. Are there some known implementation differences (or maybe many) between the two? I would try and pull over anything that possible to share between the two so it finds the solution as well in Libnfc version as well. I realize this is PM3 forum but just coming here for guidance on anything that would help between the two if anyone knows.

iceman · 2016-08-03 18:05:42

You should ask @aczid about his libnfc implementation.

my_fair_cats_sick · 2016-08-11 21:18:50

I am having some issues with the very latest hardnested attack (@iceman's branch as of a week ago or so)- I have been trying to run many attacks on the same card and it appears i'm getting to the point where the keyspace is reduced to 2^-inf (or zero possible keys):

Number of remaining possible keys: 0 (2^-inf)

Has anyone seen this or understand how this can be explained? I ran hardnested about 50 times on the same card with different keys...it failed to find a key maybe 30% of that time on the first try. I got to a point where it has been failing over and over with the above error.

Any clues as to what may be going on?

iceman · 2016-08-11 21:26:49

If you look at the latest version, I've change the number of good tries needed.
https://github.com/iceman1001/proxmark3 … hard.c#L40

You can adjust that one and recompile the client.

my_fair_cats_sick · 2016-08-11 22:11:33

Hmm, that didn't solve my problem, I put it back to 28. Over and over I keep failing on one card I have. Key cracking should be based on the PRNG not the key value itself, correct? I doubt I wore out the card, but I guess its possible with the amount of automated testing i've been doing lately.

iceman · 2016-08-12 08:33:35

Which keys did you use that are hard to solve?

my_fair_cats_sick · 2016-08-12 14:20:49

Ha, well....unforunately I wrote a script which grabs 12 valid hex bytes random bytes from /dev/urandom and writes that to the card using nfc-mfclassic, and then I run the PM3 attack, and it cycles over and over.....and I didn't write my known keys out to a log file. Oops!

I will try some more, but otherwise the card will just be a brick! If anyone wants it I could certainly mail it out, its one that I created from a factory fresh card I bought, so its not really any risk.

my_fair_cats_sick · 2016-08-12 14:38:03

Could I post my nonces.bin and have anyone take a look at that by chance? I can post a few of them, it constantly fails over and over. Other cards are working fine.

piwi · 2016-08-13 14:36:03

Yes, you can post your nonces.bin (link to some file sharer) and I will test with my new version. The one on my and iceman's git repository is just a proof of concept, it is not efficient, it is not effective, and it has some bugs...

My current hardnested version reduces 95% of all cases to a remaining key space of 30 Bits or less (this is with GOOD_BYTES_REQUIRED 10), but there are still these 5% which will take much more time to brute force. I am thinking of a "secure MF key generator" already.

my_fair_cats_sick · 2016-08-13 15:02:37

Thanks @piwi - sounds like you are hard at work! For now I'm just looking to understand the attack best I can and get a feel for where improvements are possible. Then someday when you release your version I'll be better equipped to understand the differences. Code diffs aren't quite the same if you don't know what the heck you are looking at!

So, that last 5% which is difficult, is the difficulty based on the key value itself? That is pretty interesting. If you have any need to testing or help with that last 5% and can help get me or the community up to speed on it, I would be happy to help. I am in a Masters program currently and have access to some crypto professors as well. Sounds like a fun challenge. However, with the rate you are going you'll beat out 10 people working on the issue by yourself, you've proven that before!

Here are two sets of nonces, same card, UID is part of the filename. Thanks for your time @piwi
https://www.dropbox.com/s/i4zh8yq86yya37w/nonces_uid_04450bb2d03280_1.bin?dl=0
https://www.dropbox.com/s/p2ndoohe80w6duj/nonces_uid_04450bb2d03280.bin?dl=0

my_fair_cats_sick · 2016-08-15 04:09:03

Here is one key that is not cracking right now:

CAB444FC3AB9

if that helps to begin to characterize which keys are troublesome.

piwi · 2016-08-15 08:05:26

my_fair_cats_sick wrote:

Here is one key that is not cracking right now:
CAB444FC3AB9

Is this the key belonging to the nonces files above? If yes, then there must be something wrong with nonce acquisition. Sum properties for this key are Sum(a0)=128 and Sum(a8)=128 (which is the worst possible combination). However, estimated Sum(a8) for your nonces files are different.

my_fair_cats_sick · 2016-08-15 13:40:06

No - the nonces are for a different key which I do not know (poor logging!). the CA.... key is just another one that the existing version of the hardnested attack couldn't crack.

piwi · 2016-08-15 14:11:43

The nonces files fail for me as well. Without knowing the correct key it is impossible to say where it fails. Most probably one of the 28 Sum(a8) properties is guessed wrong. This is why you should follow Iceman's (and my) advise and reduce GOOD_BYTES_REQUIRED. The less you have, the less can be wrong (at the cost of an increased remaining key space though).

my_fair_cats_sick · 2016-08-15 16:14:16

Thanks @piwi for your detailed explanation - I understand much better now, I was thinking that more nonces and reducing more of the keyspace was better, but I see that its still a guess at that point and something about that key value/card id/PRNG is causing an issue with the guess. I will reduce the GOOD bytes required and try a longer brute force.

Is there any suggested analysis which may help us understand WHY these certain keys (not sure if there are other factors) are causing incorrect guesses? I'm also curious as to why a different set of nonces does not help. I ran for 24 hours or so with a pretty powerful laptop and PM3 and it never came up with an answer with 13 GOOD bytes required, I gave up at that point assuming it would ever guess correctly. Im trying now with 8 GOOD bytes required...brute force in progress.

iceman · 2016-08-15 17:41:28

There is only one here that understand the hardnested attack and that is not me. Just follow @piwi's directions.

Btw, can someone explain the flipbit property in layman terms?

piwi · 2016-08-15 20:35:31

The bitflip property is a property of the bytes of the encrypted nonces, i.e. what is delivered by the tag during the nested authentication sequence. If we look at the first byte of the nonces only, then there will be pairs of first bytes where only the last bit (a7) differs. E.g. 0xff and 0x7f. Or 0x80 and 0x00 (there are 128 pairs like this). A nonce byte has bitflip property (on a7) if the encrypted parity bits of the byte pair differ. E.g. 0xff has bitflip property on a7 if the encrypted paritiy bits of 0xff and 0x7f differ.

Likewise, 0xff has bitflip property on a6 if the encrypted parity bits of 0xff and 0xbf differ.

my_fair_cats_sick · 2016-08-16 15:09:32

Well, I have gone down to GOOD_BYTES required = 1 and this still doesn't work, for key CAB444FC3AB9 and card UID 045d954a953680

I can post nonces if that helps otherwise I think thats all thats necessary to emulate a card, if anyone has time to check as well.

piwi · 2016-08-26 06:27:43

After two weeks of debugging I do have a working version of hf mf hardnested again. I have added a test mode to simulate random and specific keys. With key CAB444FC3AB9 and GOOD_BYTES_REQUIRED = 10 the remaining key space after hf mf hardnested is 2^30 keys - CAB444FC3AB9 is among them.

I am done with the key space reduction phase. I am still not satisfied with the acquisition phase, i.e. when to stop acquisition.

Last edited by piwi (2016-08-26 06:28:16)

my_fair_cats_sick · 2016-08-26 16:46:22

thanks for all your hard work @piwi - I'm looking forward to trying it out, I assume @iceman will incorporate this into his docker image once you make the new source available.

I wrote a script to do the random key tests and physically write to the card - I did notice on a few test cards that didn't solve on Proxmark after numerous tries, it solved quite easily on @aczid's solver with LibNFC and a standard SCL3711 usb reader.

I'll test again once there is something new out! Thanks again for the update!

matrix · 2016-10-22 11:08:07

Hi,
there's something new in the attack implementation.
Please retry with iceman proxmark3 if you can

bye,
matrix

my_fair_cats_sick wrote:

thanks for all your hard work @piwi - I'm looking forward to trying it out, I assume @iceman will incorporate this into his docker image once you make the new source available.
I wrote a script to do the random key tests and physically write to the card - I did notice on a few test cards that didn't solve on Proxmark after numerous tries, it solved quite easily on @aczid's solver with LibNFC and a standard SCL3711 usb reader.
I'll test again once there is something new out! Thanks again for the update!

my_fair_cats_sick · 2016-10-22 14:11:14

Anyone like to explain what has changed so I know what to test?

matrix · 2016-10-22 14:46:57

Now the key cracking process is not started only if we reach 13 "good bytes".

Every 2500 acquired nonces with distinct bytes 0 and 1 will be processed the generate_candidate function for calculate the number of remaining possible keys.
If this value is < 2^39 the nonces acquisition will be paused and will be started the cracking process.
If the key is not found the nonces acquisition will be re-enabled, and go on ...

In that way I think, because I do , you can successfully recover all the keys with PM3 faster than before.

Bye,
matrix

Last edited by matrix (2016-10-22 14:50:08)

iceman · 2016-10-28 12:22:18

Tried your enhanced way today, @matrix,

Ref: http://pastebin.com/T2VQQKGd

Within the first 4000nonces, it got lucky and found the key. That reduces the long time with nonces collecting drastically.
I can imagine it doesn't do this all the time but still its a great optimization.

When will you push your latest fixes?

piwi · 2016-10-28 14:54:09

iceman wrote:

Ref: http://pastebin.com/T2VQQKGd

Success! Tested 2289753864 states, found 1 keys after 7584392 seconds

This isn't true, isn't it? That would be 87 days. How long does it really take?

iceman · 2016-10-28 15:04:59

nop, the timer doesn't work very well on in my mingw env. Strange thing that difftime call.

piwi · 2016-10-28 16:12:35

How fast is it? Do we talk milliseconds, seconds, minutes, hours or days?

iceman · 2016-10-28 17:37:22

Seconds not minutes.
But I guess it comes down to the fact that 2^39 is quite huge still.
The nonce collecting part depends on if it can deduct down to below that limit.
And the average speed of the BF solver you already know.

piwi · 2016-10-29 13:33:56

No I don't. Therefore I'm asking.

Proxmark3 community

Announcement

#201 2016-07-22 14:27:05

Re: Mifare Plus Atack

#202 2016-07-22 17:13:32

Re: Mifare Plus Atack

#203 2016-07-22 17:25:13

Re: Mifare Plus Atack

#204 2016-07-22 21:57:47

Re: Mifare Plus Atack

#205 2016-07-24 19:15:22

Re: Mifare Plus Atack

#206 2016-07-27 12:23:32

Re: Mifare Plus Atack

#207 2016-07-27 12:28:26

Re: Mifare Plus Atack

#208 2016-07-27 12:36:00

Re: Mifare Plus Atack

#209 2016-07-27 12:45:20

Re: Mifare Plus Atack

#210 2016-07-27 12:49:43

Re: Mifare Plus Atack

#211 2016-07-27 12:51:02

Re: Mifare Plus Atack

#212 2016-07-27 12:54:25

Re: Mifare Plus Atack

#213 2016-07-27 14:55:01

Re: Mifare Plus Atack

#214 2016-07-27 18:21:26

Re: Mifare Plus Atack

#215 2016-07-27 18:31:37

Re: Mifare Plus Atack

#216 2016-07-27 20:09:23

Re: Mifare Plus Atack

#217 2016-07-27 20:49:26

Re: Mifare Plus Atack

#218 2016-07-28 12:25:29

Re: Mifare Plus Atack

#219 2016-07-28 16:14:04

Re: Mifare Plus Atack

#220 2016-07-28 18:46:21

Re: Mifare Plus Atack

#221 2016-07-28 19:10:53

Re: Mifare Plus Atack

#222 2016-08-03 17:42:59

Re: Mifare Plus Atack

#223 2016-08-03 18:05:42

Re: Mifare Plus Atack

#224 2016-08-11 21:18:50

Re: Mifare Plus Atack

#225 2016-08-11 21:26:49

Re: Mifare Plus Atack

#226 2016-08-11 22:11:33

Re: Mifare Plus Atack

#227 2016-08-12 08:33:35

Re: Mifare Plus Atack

#228 2016-08-12 14:20:49

Re: Mifare Plus Atack

#229 2016-08-12 14:38:03

Re: Mifare Plus Atack

#230 2016-08-13 14:36:03

Re: Mifare Plus Atack

#231 2016-08-13 15:02:37

Re: Mifare Plus Atack

#232 2016-08-15 04:09:03

Re: Mifare Plus Atack

#233 2016-08-15 08:05:26

Re: Mifare Plus Atack

#234 2016-08-15 13:40:06

Re: Mifare Plus Atack

#235 2016-08-15 14:11:43

Re: Mifare Plus Atack

#236 2016-08-15 16:14:16

Re: Mifare Plus Atack

#237 2016-08-15 17:41:28

Re: Mifare Plus Atack

#238 2016-08-15 20:35:31

Re: Mifare Plus Atack

#239 2016-08-16 15:09:32

Re: Mifare Plus Atack