NFC: Add support for Gen4 "ultimate card" in Magic app

[nullableVoidPtr]

What's new

• Add functionality to the nfc_magic for Gen4 magic cards
  • Write Mifare Classic 1k/4k or Ultralight
  • Change password
  • Wipe
• Restructure app GUI to accommodate for multiple magic card types
• Refactor NFC Magic worker code
• Define NfcMagicDevice struct to hold magic device information

Verification

• I verified all functions (check, write, wipe, change passwords) with my own magic devices (Gen1A keyfob and Gen4 card)

Checklist (For Reviewer)

• PR has description of feature/bug or link to Confluence/Jira task
• Description contains actions to verify feature/bugfix
• I've built this code, uploaded it to the device and verified feature/bugfix

[rozetkinrobot]

Not working with my Gen4 Card because of 2 problems:

1. Can't select 7uid/4k card dump (on-screen "Gen1 only supports 4 bytes UID Mifare classic 1k", but there is Gen4 card)
2. Using furi_hal_nfc_detect at nfc_magic_worker_write produces an infinity loop of card detection (like in firmware nfc app), so writing dump to the card is impossible

[nullableVoidPtr]

1. Can't select 7uid/4k card  dump (on-screen "Gen1 only supports 4 bytes UID Mifare classic 1k", but there is Gen4 card)

Could you provide more details of the dump? Is it an Ultralight dump, or a Classic with 7 UID? The error message also needs to be more specific so I'll get around to improving that.

2. Using furi_hal_nfc_detect at nfc_magic_worker_write produces an infinity loop of card detection (like in firmware nfc app), so writing dump to the card is impossible

Assuming it's already detected as Gen 4 GTU at the read screen, I can only guess that the same CUID check fails (which in hindsight I should have made clear in the GUI), although this is behavior which I never observed with my magic card that I tested this with. Which supplier did you get your card from?

[eliecharra]

I tried this PR locally, and yeah it seems that we cannot write Mifare classic 1K with 7 bytes UID.

It is working well with a 4 byte dump for me, no infinite loop.

Thanks for adding gen 4 support 👍🏻

[skotopes]

@gornekich can you take a look?

[rozetkinrobot]

I can only guess that the same CUID check fails (which in hindsight I should have made clear in the GUI)

No, I checked, and it stops on calling furi_hal_nfc_detect(&nfc_data, 200), not on CUID check. For same reason, this card cannot be readed through the NFC application.

It's card from proxgrind store on Aliexpress.

[nullableVoidPtr]

No, I checked, and it stops on calling furi_hal_nfc_detect(&nfc_data, 200), not on CUID check. For same reason, this card cannot be readed through the NFC application.

Sorry that I misunderstood you at first and thanks for debugging for me! I don't have access to a WiFi dev board or any other means to debug "properly".
It may be the case that the card is misconfigured with an incorrect parameters (combination of ATQA + SAK and configured UID length) and the "normal" anti-collision/card-activation sequence fails. In your case, the card is probably activated at one cascade level, but the Flipper Zero is now expecting a response for higher cascade level since it has calculated it from the SAK value, but it's hard to know for sure without further debugging into RFAL.

If you have a Proxmark, please refer to this to see if you can restore your card such that the main NFC reader app can read it. Use -k to keep the field so you can reconfigure your card:

hf 14a config --atqa force --bcc ignore --cl2 force --cl3 skip --rats skip
hf 14a reader -k

With this you are essentially forcing activation of a card to a certain cascade level (try 1 then 2 then 3) while ignoring ATQA and SAK. You can test if the card is activated after a select attempt using this raw command:

hf 14a raw -s -c -t 1000 CF00000000C6

The above assumes a default password of 00000000, but if you have really lost the backdoor password to your magic card, then there is no way to recover this.

[rozetkinrobot]

In your case, the card is probably activated at one cascade level, but the Flipper Zero is now expecting a response for higher cascade level since it has calculated it from the SAK value, but it's hard to know for sure without further debugging into RFAL.

In my case, there is really a problem at the anticollision stage. Flipper's trace debug:

501339980 [T][FuriHalNfc] State change 0 -> 10
501340118 [T][FuriHalNfc] State change 10 -> 11
501340132 [T][FuriHalNfc] State change 11 -> 34
501340135 [T][FuriHalNfc] State change 34 -> 2
501340138 [T][FuriHalNfc] State change 2 -> 10
501340231 [T][FuriHalNfc] State change 10 -> 11
501340245 [T][FuriHalNfc] State change 11 -> 34
501340248 [T][FuriHalNfc] State change 34 -> 2
501340251 [T][FuriHalNfc] State change 2 -> 10
501340277 [T][FuriHalNfc] Timeout

According to rfal_nfc.h there is a broken sequence: RFAL_NFC_STATE_NOTINIT -> RFAL_NFC_STATE_POLL_TECHDETECT -> RFAL_NFC_STATE_POLL_COLAVOIDANCE -> RFAL_NFC_STATE_DEACTIVATION

The card works correctly on all my devices except Flipper Zero (I tested it on 2 flippers). I tried to reconfigure the card, but it does not help. My guess is there is a problem in that fact, that card responds to 14a and 14b protocol commands at the same time.

I would be very grateful if you could help me in debugging and fixing this problem.

There is a trace of proxmark's hf 14a sniff:

      Start |        End | Src | Data (! denotes parity error)                                           | CRC | Annotation
------------+------------+-----+-------------------------------------------------------------------------+-----+--------------------
          0 |        992 | Rdr |52                                                                       |     | 
       2260 |       4628 | Tag |04  00                                                                   |     | 
      36240 |      41008 | Rdr |50  00  57  cd                                                           |     | 
    1219408 |    1220400 | Rdr |52                                                                       |     | 
    1544848 |    1545840 | Rdr |52                                                                       |     | 
    1547092 |    1549460 | Tag |04  00                                                                   |     | 
    1581088 |    1585856 | Rdr |50  00  57  cd                                                           |     | 
    2765232 |    2766224 | Rdr |52                                                                       |     | 
    3090656 |    3091648 | Rdr |52                                                                       |     | 
    3092916 |    3095284 | Tag |04  00                                                                   |     | 
    3126896 |    3131664 | Rdr |50  00  57  cd                                                           |     | 
    5342528 |    5343520 | Rdr |52                                                                       |     | 
    5344772 |    5347140 | Tag |04  00                                                                   |     | 
    5378752 |    5383520 | Rdr |50  00  57  cd                                                           |     | 
    6561968 |    6562960 | Rdr |52                                                                       |     | 
    6887408 |    6888400 | Rdr |52                                                                       |     | 
    6889652 |    6892020 | Tag |04  00                                                                   |     | 
    6923648 |    6928416 | Rdr |50  00  57  cd                                                           |     | 
    8162048 |    8163040 | Rdr |52                                                                       |     | 

hf 14b sniff:

      Start |        End | Src | Data (! denotes parity error)                                           | CRC | Annotation
------------+------------+-----+-------------------------------------------------------------------------+-----+--------------------
          0 |       3092 | Rdr |05  00  00  71  ff                                                       |     | 
 4294942868 |      34964 | Tag |50! 00! 01  02  03! 00! e9  b7! ff! 75  6d  af! 34  22!                  |     | 
     839428 |     842516 | Rdr |06  00  97  5b                                                           |     | 
    1441728 |    1444820 | Rdr |05  00  00  71  ff                                                       |     | 
    1417300 |    1476692 | Tag |50! 00! 01  02  03! 00! e9  b7! ff! 75  6d  af! 34  22!                  |     | 
    2254244 |    2257332 | Rdr |06  00  97  5b                                                           |     | 
    4483360 |    4486452 | Rdr |05  00  00  71  ff                                                       |     | 
    4458964 |    4518356 | Tag |50! 00! 01  02  03! 00! e9  b7! ff! 75  6d  af! 34  22!                  |     | 
    5295716 |    5298804 | Rdr |06  00  97  5b                                                           |     | 
    5851680 |    5854772 | Rdr |05  00  00  71  ff                                                       |     | 

[skynet01]

I can confirm that selecting 7uid/4k card dump doesn't let you write it. Also an issue with NTAG I2C 2K PLUS card. It writes the card but then the card shows up as Mifare Classic with uid 1111111.
My card is from 401lab.

You can test this (along with other cards) by using the stock nfc app to generate blank cards of different variety (most worked for me). Thank you again for making this!

Small tweak request: when selecting write option it would be nice if it would take you to the nfc folder by default. Also would be awesome to be able to have other features like shadow mode or be able to set other parameters like SAK, ATS etc.

[nullableVoidPtr]

I have made a small change which should allow 7-byte UIDs.
@rozetkinrobot I can't quite figure out what's going on, the code should mostly work with NFC-A unless I'm missing something. Your sniff using a proxmark is a simple WUPA which is being responded to with what appears to be a normal ATQA, at which point the reader issues a HLTA. Can you do a proper read, trying to read the ATQA, SAK, and full UID using the proxmark?

[skynet01]

I have made a small change which should allow 7-byte UIDs.

That's awesome! Any idea why NTAG I2C 2K PLUS does not get written properly? Also I noticed that wipe command does not work if something incorrect is written, for example if you write Ntag i2c 2k plus blank card (generated by NFC app) you can't wipe the card anymore as it's not being detected properly (proxmark3 wipes it fine without issues).

Maybe just adding a timeout to Authenticate 4gen scanning screen? if detection fails it gives you an option to force wipe the card (could also be a footer button screen option)?

[gornekich]

Hi @nullableVoidPtr . Thanks for PR!
I am waiting for Gen4 card to test your PR. I might take some time...

By the way, is your PR WIP or it's ready for review? In case it's WIP, please convert it to draft

[nullableVoidPtr]

I've made it a draft pending NTAG-writing issues and fleshing out GUI error reporting. I've ensured that something as simple as UL11 works by writing an NFC file and comparing differences between the original and a card read.

[nullableVoidPtr]

Also I noticed that wipe command does not work if something incorrect is written, for example if you write Ntag i2c 2k plus blank card

Wipe is rather slow as I'm (admittedly, very stupidly) overwriting every sector to the card to reset back to a MIFARE 4K. For whatever reason, the current code doesn't change the state of the wipe scene to "Card Found" upon finding a card, but I can confirm that wiping a card with I2C Plus 2K data works, just takes a while and is not visible.

I'll still need to figure out that, and why NTAG isn't quite working though. My proxmark appears to have read the card up to CL2 successfully but the 7 byte UID is all zero for whatever reason, just the ATQA and SAK appear to work fine.

[superswiegie]

I have made a small change which should allow 7-byte UIDs.
@rozetkinrobot I can't quite figure out what's going on, the code should mostly work with NFC-A unless I'm missing something. Your sniff using a proxmark is a simple WUPA which is being responded to with what appears to be a normal ATQA, at which point the reader issues a HLTA. Can you do a proper read, trying to read the ATQA, SAK, and full UID using the proxmark?

I'm super thankful for your support. Would love to write 7byte UID (finally). Could you tell me what the status is? Can I mail a 'maintainer'. to speed up the proces? Once more: Thanks for your contribution! I'm happy.

[skynet01]

+1 any updates on this. Willing to donate to this project to keep it going :)

[nullableVoidPtr]

Ready for review now; I've deferred the NTAG I2C issue for later; it turns out the GTU card does not support the simpler I2C layout for first pages at all when determining its UID; the best it can do is send the corresponding ATQA and SAK. For any meaningful I2C emulation, the source data would have to be modified, specifically pages 0 and 1 to the different Ultralight layout, which may or may not effect anything which reads from the written I2C tag beyond anti-collision.

[skotopes]

Un-draft when ready.

[nullableVoidPtr]

Argh, looks like you don't trust sleep deprived code! The continues make card_found_notified kinda moot. I'll have to refactor how card found notifications work and retest all functionality.

[nullableVoidPtr]

@skotopes bump: ready for review

[skotopes]

[CasseThor]

Same problem, buy ultimate card gen4 on lab401.com with latest flipper zero
cant write card (bip and redlight) (uid with 7byte) and doesn't detect card if i want wipe it !

[skotopes]

@CasseThor check latest version of the Magic app from catalog.