Stuck on the same distance 65439

[bzt543]

Is there a reason why im stuck on the same distance when running MFOC? Currently using ACR122U reader trying to find the keys to Mifare Classic 1K tag. Thanks.

Using sector 02 as an exploit sector
Sector: 0, type A, probe 0, distance 65439 .....
Sector: 0, type A, probe 1, distance 65439 .....
Sector: 0, type A, probe 2, distance 65439 .....
Sector: 0, type A, probe 3, distance 65439 .....
Sector: 0, type A, probe 4, distance 65439 .....
Sector: 0, type A, probe 5, distance 65439 .....
Sector: 0, type A, probe 6, distance 65439 .....
Sector: 0, type A, probe 7, distance 65439 .....
Sector: 0, type A, probe 8, distance 65439 .....
Sector: 0, type A, probe 9, distance 65439 .....
Sector: 0, type A, probe 10, distance 65439 .....
Sector: 0, type A, probe 11, distance 65439 .....
Sector: 0, type A, probe 12, distance 65439 .....
Sector: 0, type A, probe 13, distance 65439 .....
Sector: 0, type A, probe 14, distance 65439 .....
Sector: 0, type A, probe 15, distance 65439 .....
Sector: 0, type A, probe 16, distance 65439 .....
Sector: 0, type A, probe 17, distance 65439 .....
Sector: 0, type A, probe 18, distance 65439 .....
Sector: 0, type A, probe 19, distance 65439 .....
Sector: 0, type A, probe 20, distance 65439 .....
Sector: 0, type A, probe 21, distance 65439 .....
Sector: 0, type A, probe 22, distance 65439 .....
Sector: 0, type A, probe 23, distance 65439 .....
Sector: 0, type A, probe 24, distance 65439 .....
Sector: 0, type A, probe 25, distance 65439 .....
Sector: 0, type A, probe 26, distance 65439 .....
Sector: 0, type A, probe 27, distance 65439 .....
Sector: 0, type A, probe 28, distance 65439 .....
Sector: 0, type A, probe 29, distance 65439 .....
Sector: 0, type A, probe 30, distance 65439 .....
Sector: 0, type A, probe 31, distance 65439 .....
Sector: 0, type A, probe 32, distance 65439 .....
Sector: 0, type A, probe 33, distance 65439 .....
Sector: 0, type A, probe 34, distance 65439 .....
Sector: 0, type A, probe 35, distance 65439 .....
Sector: 0, type A, probe 36, distance 65439 .....
Sector: 0, type A, probe 37, distance 65439 .....

[KiralyCraft]

I'm facing the same issue. It may be that your card (and mine) use a static nonce generator, or somehow have the PNRG issue fixed. mfcuk doesn't work either

EDIT: I have researched this further, and now I'm not so confident in my reply.

[PE-60]

Unfortunately, I stumbled upon the same issue and was using a Mifare Classic 1K tag with MFOC aswell, but with a PN532 board and a USB to UART cable. After a bit of digging I found a thread on reddit (link here: https://www.reddit.com/r/RFID/comments/m1qxv2/issues_with_mifarelibnfc/ ). So potentially the problem could have something to do with the wiring and the connections, but I doubt it. Try and run MFCUK and see if your Nt is constantly 1 (run verbose 3 and see what diff Nt reads). Also try mfoc hardnested and see if the nonces increase or remain the same. If Nt==1 and nonces stays at 1 then it's very likely that the card has a static/fixed nonce...which means it'll be tough to crack it (yeah, these cards are very annoying and the only ways I know of are either by using a Proxmark 3 with a type of a man-in-the-middle attack and the official card reader, or by brute forcing the nonce's key again with a proxmark).
In my case I got a static nonce card and the way I'm going to crack it is with a proxmark v3 and the "hf mf staticnested" attack... A bit more information on it: RfidResearchGroup/proxmark3#133
https://github.com/RfidResearchGroup/proxmark3

What i get from mfoc-harndested:

time | trg | #nonces | Activity                                                | expected to brute force          
     |     |         |                                                         | #states         | time
   0 |  0A |       0 | Start using 16 threads and AVX2 SIMD core               |                 |          
   0 |  0A |       0 | Brute force benchmark: 3273 million (2^31.6) keys/s     | 140737488355328 |   12h          
   1 |  0A |       0 | Using 235 precalculated bitflip state tables            | 140737488355328 |   12h          
1087 |  0A |       1 | Apply bit flip properties                               | 140737488355328 |   12h          Error while requesting plain tag-nonce

And MFCUK:

   Let me entertain you!
   -----------------------------
   uid: xxxxxxxx
   type: 08
   key: 000000000000
   block: 03
   diff Nt: 1
   auths: 47

[NikoCosmico01]

I am facing the same exact issue with a PN532. Have you found a solution by using the PN532? I would like to avoid buying the pm3 because of the high shipping time required.

[APOFISAN]

So far so good, the case is that I got my hands on a new card from this company and what was my surprise that when I try to read it with the proxmark3 and does not let me read sectors 1 and 2. This company has changed the passwords of sectors 0,3,4,5,6,7,8,9,9,10,11,12,13,14,15 and has put default keys FFFFFFFFFFFFFFFFFFFF. In the first one you only knew the password A of sector 0, which was A0A1A2A3A4A5.

if I use hf mf keycheck, it comes out empty, it does not find any key.
if I use hf mf fchk, I get all keys except for sector 1 and 2.
if I use hf mf autopwn, it only gets the FFFFFFFFFFFFFFFFFFFFF and at the end it says: nested: 00000000 vs 00000000. error: no response from proxmark3.

if use hf mf darkside pone runing darkside…- card is not vulnerable to darkside attack, doesn’t send NACK on authentication request.

Another change that I have seen and I had not noticed is that the header 0 of sector 0, has also changed, that is to say, this the uid and other numbers, that in the old cards except for the uid, were all the same. In this new change in each card are not the same.

[usb] pm3 → hf mf chk
[=] Start check for keys…
[=] …
[=] time in checkkeys 3 seconds

[=] testing to read key B…

[+] found keys:

[+] -----±----±-------------±–±-------------±—
[+] Sec | Blk | key A |res| key B |res
[+] -----±----±-------------±–±-------------±—
[+] 000 | 003 | FFFFFFFFFFFF | 1 | FFFFFFFFFFFF | 1
[+] 001 | 007 | ------------ | 0 | ------------ | 0
[+] 002 | 011 | ------------ | 0 | ------------ | 0
[+] 003 | 015 | FFFFFFFFFFFF | 1 | FFFFFFFFFFFF | 1
[+] 004 | 019 | FFFFFFFFFFFF | 1 | FFFFFFFFFFFF | 1
[+] 005 | 023 | FFFFFFFFFFFF | 1 | FFFFFFFFFFFF | 1
[+] 006 | 027 | FFFFFFFFFFFF | 1 | FFFFFFFFFFFF | 1
[+] 007 | 031 | FFFFFFFFFFFF | 1 | FFFFFFFFFFFF | 1
[+] 008 | 035 | FFFFFFFFFFFF | 1 | FFFFFFFFFFFF | 1
[+] 009 | 039 | FFFFFFFFFFFF | 1 | FFFFFFFFFFFF | 1
[+] 010 | 043 | FFFFFFFFFFFF | 1 | FFFFFFFFFFFF | 1
[+] 011 | 047 | FFFFFFFFFFFF | 1 | FFFFFFFFFFFF | 1
[+] 012 | 051 | FFFFFFFFFFFF | 1 | FFFFFFFFFFFF | 1
[+] 013 | 055 | FFFFFFFFFFFF | 1 | FFFFFFFFFFFF | 1
[+] 014 | 059 | FFFFFFFFFFFF | 1 | FFFFFFFFFFFF | 1
[+] 015 | 063 | FFFFFFFFFFFF | 1 | FFFFFFFFFFFF | 1
[+] -----±----±-------------±–±-------------±—
[+] ( 0:Failed / 1:Success )

[usb] pm3 → hf mf autopwn
[!] no known key was supplied, key recovery might fail
[+] loaded 45 keys from hardcoded default array
[=] running strategy 1
[=] Chunk 1.2s | found 28/32 keys (45)
[=] running strategy 2
[=] Chunk 1.2s | found 28/32 keys (45)
[+] target sector 0 key type A – found valid key [ FFFFFFFFFFFF ] (used for nested / hardnested attack)
[+] target sector 0 key type B – found valid key [ FFFFFFFFFFFF ]
[+] target sector 3 key type A – found valid key [ FFFFFFFFFFFF ]
[+] target sector 3 key type B – found valid key [ FFFFFFFFFFFF ]
[+] target sector 4 key type A – found valid key [ FFFFFFFFFFFF ]
[+] target sector 4 key type B – found valid key [ FFFFFFFFFFFF ]
[+] target sector 5 key type A – found valid key [ FFFFFFFFFFFF ]
[+] target sector 5 key type B – found valid key [ FFFFFFFFFFFF ]
[+] target sector 6 key type A – found valid key [ FFFFFFFFFFFF ]
[+] target sector 6 key type B – found valid key [ FFFFFFFFFFFF ]
[+] target sector 7 key type A – found valid key [ FFFFFFFFFFFF ]
[+] target sector 7 key type B – found valid key [ FFFFFFFFFFFF ]
[+] target sector 8 key type A – found valid key [ FFFFFFFFFFFF ]
[+] target sector 8 key type B – found valid key [ FFFFFFFFFFFF ]
[+] target sector 9 key type A – found valid key [ FFFFFFFFFFFF ]
[+] target sector 9 key type B – found valid key [ FFFFFFFFFFFF ]
[+] target sector 10 key type A – found valid key [ FFFFFFFFFFFF ]
[+] target sector 10 key type B – found valid key [ FFFFFFFFFFFF ]
[+] target sector 11 key type A – found valid key [ FFFFFFFFFFFF ]
[+] target sector 11 key type B – found valid key [ FFFFFFFFFFFF ]
[+] target sector 12 key type A – found valid key [ FFFFFFFFFFFF ]
[+] target sector 12 key type B – found valid key [ FFFFFFFFFFFF ]
[+] target sector 13 key type A – found valid key [ FFFFFFFFFFFF ]
[+] target sector 13 key type B – found valid key [ FFFFFFFFFFFF ]
[+] target sector 14 key type A – found valid key [ FFFFFFFFFFFF ]
[+] target sector 14 key type B – found valid key [ FFFFFFFFFFFF ]
[+] target sector 15 key type A – found valid key [ FFFFFFFFFFFF ]
[+] target sector 15 key type B – found valid key [ FFFFFFFFFFFF ]
[#] Nested: 00000000 vs 00000000

[!!] Error: No response from Proxmark3.

[usb] pm3 → hf mf darkside
[=] Expected execution time is about 25seconds on average
[=] Press pm3-button to abort

[=] Running darkside …[-] card is not vulnerable to Darkside attack (doesn’t send NACK on authentication requests)

[usb] pm3 → hf mf hardnested --tblk 4 --ta
[!] Key is wrong. Can’t authenticate to block: 0 key type: A
[usb] pm3 → hf mf hardnested --blk 0 -a -k FFFFFFFFFFFF --tblk 4 --ta
[=] Target block no 4, target key type: A, known target key: 000000000000 (not set)
[=] File action: none, Slow: No, Tests: 0
[=] Hardnested attack starting…
[=] ---------±--------±--------------------------------------------------------±----------------±------
[=] | | | Expected to brute force
[=] Time | #nonces | Activity | #states | time
[=] ---------±--------±--------------------------------------------------------±----------------±------
[=] 0 | 0 | Start using 16 threads and AVX2 SIMD core | |
[=] 0 | 0 | Brute force benchmark: 2630 million (2^31.3) keys/s | 140737488355328 | 15h
[=] 5 | 0 | Using 235 precalculated bitflip state tables | 140737488355328 | 15h
[#] AcquireEncryptedNonces finished
[!!] Error: Static encrypted nonce detected. Aborted.

[usb] pm3 → hf mf hardnested --blk 0 -a -k FFFFFFFFFFFF --tblk 4 --ta -f nonces.bin -w -s
[=] Target block no 4, target key type: A, known target key: 000000000000 (not set)
[=] File action: write, Slow: Yes, Tests: 0
[=] Hardnested attack starting…
[=] ---------±--------±--------------------------------------------------------±----------------±------
[=] | | | Expected to brute force
[=] Time | #nonces | Activity | #states | time
[=] ---------±--------±--------------------------------------------------------±----------------±------
[=] 0 | 0 | Start using 16 threads and AVX2 SIMD core | |
[=] 0 | 0 | Brute force benchmark: 2304 million (2^31.1) keys/s | 140737488355328 | 17h
[=] 4 | 0 | Using 235 precalculated bitflip state tables | 140737488355328 | 17h
[#] AcquireEncryptedNonces finished
[!!] Error: Static encrypted nonce detected. Aborted.

[usb] pm3 → script run hf_mf_keycheck.lua
[+] executing lua C:\Users\APOFIS\Downloads\ProxSpace\pm3\proxmark3\client\luascripts/hf_mf_keycheck.lua
[+] args ‘’
Found tag NXP MIFARE CLASSIC 1k | Plus 2k
Testing block 0, keytype 0, with 84 keys
Testing block 0, keytype 0, with 84 keys
Testing block 0, keytype 0, with 84 keys
Testing block 0, keytype 0, with 84 keys
Testing block 0, keytype 0, with 84 keys

Testing block 60, keytype 1, with 84 keys
Testing block 60, keytype 1, with 84 keys
Testing block 60, keytype 1, with 84 keys
Testing block 60, keytype 1, with 84 keys
Testing block 60, keytype 1, with 84 keys
Testing block 60, keytype 1, with 84 keys
Testing block 60, keytype 1, with 84 keys
Testing block 60, keytype 1, with 78 keys

[+] hf_mf_keycheck - Checkkey execution time: 332 sec

|—|----------------|—|----------------|—|

sec key A res key B res
000 ------------ 0 ------------ 0
001 ------------ 0 ------------ 0
002 ------------ 0 ------------ 0
003 ------------ 0 ------------ 0
004 ------------ 0 ------------ 0
005 ------------ 0 ------------ 0
006 ------------ 0 ------------ 0
007 ------------ 0 ------------ 0
008 ------------ 0 ------------ 0
009 ------------ 0 ------------ 0
010 ------------ 0 ------------ 0
011 ------------ 0 ------------ 0
012 ------------ 0 ------------ 0
013 ------------ 0 ------------ 0
014 ------------ 0 ------------ 0
015 ------------ 0 ------------ 0
— ---------------- — ---------------- —
Do you wish to save the keys to dumpfile? [y/n] ?
[usb] pm3 → hf mf nested --1k --blk 0 -a -k FFFFFFFFFFFF
[+] Testing known keys. Sector count 16
[=] Chunk 1.3s | found 28/32 keys (46)
[+] Time to check 45 known keys: 1 seconds

[+] enter nested key recovery
[#] Nested: 00000000 vs 00000000
[!!] Command execute timeout

[usb] pm3 --> hf mf nested --1k --blk 0 -a -k ffffffffffff --tblk 8 --ta
[-] Tag isn't vulnerable to Nested Attack (PRNG is not predictable).

I think it is a static encrypted nonces. Could it be?

[philicious]

I also came across a card where mfoc solely shows the same difference as mentioned.
Tweaking probes didn't help. Also mfoc-hardnested didn't work.

however mfcuk doesn't show Nt 1 🤔
Any idea what the reason might be?

I use a ACR122u / PN532.

(Luckily I already retrieved 1 of 3 missing keys by sniffing nonces from reader. Might be able to sniff other purpose readers tooti get remaining keys. Still would like to get mfoc working as an alternative)

[philicious]

I did some debugging and for the moment want to note:

for every probe, the nonces distances array, after qsort, always looks like:

Distance 1650
Distance 65439
Distance 65439
Distance 65439
Distance 65439
Distance 65439
Distance 65439
Distance 65439
Distance 65439
Distance 65439
Distance 65439
Distance 65439
Distance 65439
Distance 65439

the first distance is always different but the rest are all the same 65439.
and then the middle/median of that array is actually used. so thats the reason the distance for every probe is always 65439.

I also tried different combinations of versions

• mfoc (0.10.7 = which you get from mac hombrew but sh** old from 2013 and also latest from git = 11/2023)
• libnfc ( 1.7.1 and 1.8.0 )
  but that didnt seem to make a difference

maybe one of maintainers like @iceman1001 or @doegox have an idea.
to me it doesnt look like a static nonce as at least one distance always differs wrong assumption

Edit: as Block 0 starts with 0x90 and also contains 0x03 at byte 9, it might be a Fudan clone with encrypted static nonce, if I interpret @iceman1001 comment in a Reddit thread correctly

[iceman1001]

Close but no right, but the answer to this issue is "static encrypted nonce" and you will not be able to recover the keys.

[philicious]

Thx @iceman1001 for verification.

I'll just sniff the nonces from reader then. Which already worked for one of the three missing keys and I suspect to get the other keys from another reader there

[iceman1001]

That is correct, sniffing will give you the keys from the blocks of which the reader is trying to read.
Not more , not less.

[gmbgustavo]

I am having the same problem getting stuck with the nonces distances. I don't think static nonces are the problem, either it's my reader or some bug with libnfc version. The distance does not change at all, tested with several mifare cards that worked months ago.