Proxmark3 community

Next Entry Z

Contributor

Registered: 2021-12-10

Posts: 2

Strange behavior for NACK check and Darkside attack

Hello everyone!
I have a small problem with Proxmark3 RDV4.01 that i would like to know more about.
I do not have serious knowledge in the field of radio technologies and RFID in particular.

Abstract:

Proxmark3 RDV4.01 checks for NAСK bug and performs a Darkside Attack for a very long time and sometimes goes into an endless loop, while Proxmark3 EASY 512K copes with these tasks in a much shorter time.

Short problem description:

I have two Proxmarks, one of them is the old Proxmark3 EASY 512K and other is Proxmark3 RDV4.01.

And the situation is as follows, there is ONE card [MIFARE Classic 1K, unknown manufacturer] on which i try darkside attack. The card 100% vulable to this attack, always leaks NACK and recovered in this way more than once.

Proxmark3 EASY copes with this task quickly and cleanly.
NACK bug check with hf mf nack almost immediately shows always leak NACK.
Darkside attack itself lasts no more than 20 seconds and shows correct key at the end.

A completely different situation occurs in the case of Proxmark3 RDV4.01.
Sometimes NACK bug check works as fast as in PM3-EASY, two status-dots appears in log and it done: always leak NACK. But in the other cases (to be honest i was unable to identify any pattern or reason for this) it can lasts really-really long, status-dots appears in log and nothing can halt it (neither Ctrl-C nor PM3-button).

What about darkside attack, it works a little oddly almost every time (comparing to the PM3-EASY scenario). The attack itself takes a very long time, more than two up to five minutes, or may not end at all. Errors [-] key not found (lfsr_common_prefix list is null) occurs very often, or sometimes even [#] Card didn't answer to CL1 select all (suddenly appears 1-2 times and process continues).
However, if you continue to wait for the end of the attack, then sooner or later it will come and display the absolutely correct key.

I draw your attention to the fact that the card used in the tests is the same. Proxmark3 RDV4.01 performs all other operations and functions perfectly and so far no problems have been found in other tasks. Interception for ISO 14443-A type cards works excellently, other types of interaction with other types of Mifare cards (Ultralight, Plus) occurs regularly too. The low-frequency range also works fairly well and did not give out any errors.

The problem arose a long time ago, it seems from the moment of purchase. However, only right now i got around to trying to find out the possible reasons.

It is quite possible i am doing something wrong or the problem lies on the surface. Therefore, any guess and suggestions will be helpful.

Thanks in advance to all those who answer!

More detailed problem description:

OS: Windows 10 x64 PRO
No windows drivers for proxmark installed.
The firmware and clients for both devices from the proxmarkbuilds.org, initially and in further flashed/updated without any problems.
On Proxmark3 EASY: RRG/Iceman/master/v4.14434-84-gad9f02230 2021-10-28 20:15:37
On Proxmark3 RDV4.01: RRG/Iceman/master/v4.14434-114-g287a99d18 2021-11-29 14:10:02

Devices during the tests are connected separately:
1) Connect PM3-EASY on USB Port N, performing tests. Disconnecting.
2) Connect on same USB port PM3-RDV4, performing tests...

PM3-EASY (generic) and PM3-RDV4 (no blueshark) console clients used.

PM3-RDV4 hw tune output for HF Antenna:

[=] ---------- HF Antenna ----------
[+] HF antenna: 46.66 V - 13.56 MHz
[+] Approx. Q factor (*): 8.1 by peak voltage measurement
[+] HF antenna is OK

A standard antenna is connected.

Typical PM3-EASY and "good" PM3-RDV4 NACK check log:

[usb] pm3 --> hf mf nack
[=] Checking for NACK bug
..
[+] NACK test: always leak NACK

Sometimes in PM3-RDV4:

[usb] pm3 --> hf mf nack
[=] Checking for NACK bug
................................................. (and so on forever...)

Typical PM3-EASY darkside attack log:

[usb] pm3 --> hf mf darkside
[=] --------------------------------------------------------------------------------
[=] Executing darkside attack. Expected execution time: 25sec on average
[=] press pm3-button on the Proxmark3 device to abort both Proxmark3 and client
[=] --------------------------------------------------------------------------------
[=] ..

[+] Parity is all zero. Most likely this card sends NACK on every authentication.
[-] no candidates found, trying again
[=] ..

[-] no candidates found, trying again
[=] ..

[-] no candidates found, trying again
[=] ..

[-] no candidates found, trying again
[=] ..

[+] found 28 candidate keys.

[+] found valid key: XXXXXXXXXXXX

On RDV4 with debug level = 3, in darkside also very often appears following message: [#] Mifare: Can't select card (UID)

Typical PM3-RDV4 darkside attack log:

[usb] pm3 --> hf mf darkside
[=] --------------------------------------------------------------------------------
[=] Executing darkside attack. Expected execution time: 25sec on average
[=] press pm3-button on the Proxmark3 device to abort both Proxmark3 and client
[=] --------------------------------------------------------------------------------
[=] ..........................

[-] key not found (lfsr_common_prefix list is null). Nt=7fa4cc7c
[-] this is expected to happen in 25% of all cases. Trying again with a different reader nonce...
[=] ..............

[-] key not found (lfsr_common_prefix list is null). Nt=7fa4cc7c
[-] this is expected to happen in 25% of all cases. Trying again with a different reader nonce...
[=] ...........................

[-] key not found (lfsr_common_prefix list is null). Nt=7fa4cc7c
[-] this is expected to happen in 25% of all cases. Trying again with a different reader nonce...
[=] .................

[-] key not found (lfsr_common_prefix list is null). Nt=7fa4cc7c
[-] this is expected to happen in 25% of all cases. Trying again with a different reader nonce...
[=] ........

[-] key not found (lfsr_common_prefix list is null). Nt=7fa4cc7c
[-] this is expected to happen in 25% of all cases. Trying again with a different reader nonce...
[=] ..........

[-] key not found (lfsr_common_prefix list is null). Nt=7fa4cc7c
[-] this is expected to happen in 25% of all cases. Trying again with a different reader nonce...
[=] ...............

[-] key not found (lfsr_common_prefix list is null). Nt=7fa4cc7c
[-] this is expected to happen in 25% of all cases. Trying again with a different reader nonce...
[=] ................

[-] key not found (lfsr_common_prefix list is null). Nt=7fa4cc7c
[-] this is expected to happen in 25% of all cases. Trying again with a different reader nonce...
[=] ..........

[-] key not found (lfsr_common_prefix list is null). Nt=7fa4cc7c
[-] this is expected to happen in 25% of all cases. Trying again with a different reader nonce...
[=] ..................

[-] key not found (lfsr_common_prefix list is null). Nt=7fa4cc7c
[-] this is expected to happen in 25% of all cases. Trying again with a different reader nonce...
[=] ................

[-] key not found (lfsr_common_prefix list is null). Nt=7fa4cc7c
[-] this is expected to happen in 25% of all cases. Trying again with a different reader nonce...
[=] .........

[-] key not found (lfsr_common_prefix list is null). Nt=7fa4cc7c
[-] this is expected to happen in 25% of all cases. Trying again with a different reader nonce...
[=] ...........

[-] key not found (lfsr_common_prefix list is null). Nt=7fa4cc7c
[-] this is expected to happen in 25% of all cases. Trying again with a different reader nonce...
[=] ..[#] Card didn't answer to CL1 select all
..............

[-] key not found (lfsr_common_prefix list is null). Nt=7fa4cc7c
[-] this is expected to happen in 25% of all cases. Trying again with a different reader nonce...
[=] .................................................................................................................

[-] no candidates found, trying again
[=] ........

[+] found 69 candidate keys.

[+] found valid key: XXXXXXXXXXXX

If move the card away from the device, then error [#] Card didn't answer to CL1 select all will start to appear (as expected).

So it seems like something happens to parity-bit zero attack, while card reads as expected.

It is also interesting that on PM3-RDV4, message Parity is all zero. Most likely this card sends NACK on every authentication. on first iteration of attack loop did not appears.

Maybe it is just some problem with the radio signal or its reception. Operations are performed with an open antenna cover.
In any case, any description or guidance would be helpful.

P.S. I apologize for possible errors in the text or in the reasoning, English is not my native language.

iceman

Administrator

Registered: 2013-04-25

Posts: 9,507

Website

Re: Strange behavior for NACK check and Darkside attack

Try some distance between tag & antenna or repositioning it.   I tend to have 1-2cm distance when it comes to 14A based tags for my RDV4.