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

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

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?

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 👍🏻

@gornekich can you take a look?

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.

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.

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                                                       |     | 

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.

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 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)?

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

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.

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.

Yeah I did notice that sometimes it takes a while to wipe. But sometimes after 15 minutes I just give up it shouldn't be THAT slow. Could it be that the signature or version is not written correctly?

With proxmark lua script I can't seem to write a signature/version for Ntags using the script, just gives an error but writing in raw works (could be that I have I-copy XS but dont think that should matter). I am more than happy to experiment with you on discord as I have 2 gen4 cards.

Could it be that the signature or version is not written correctly?

So I'm writing those using a different method to the Lua script. Instead of using an UL/NTAG write command, the code uses the backdoor write to special blocks located at 0xFX. IMO this shouldn't be any different; the signature and version reads fine in my case, but it may different for your card for some other reason, like a different configuration.

Obviously the Lua script functions differently, so it may expect something that's not the case with a Flipper-written card. In my case, I had Incorrect ul come up with every script run, but I'm still unsure why this is the case.

Can you dump the configuration of your two cards separately so I can compare to mine? Please also reach out to me on the Flipper Discord. My username should be distinct enough for you to find.

Hi all,

are you planning to add gtu 4 gen support again? I use it a lot and it work for me.

Thanks for all

@Mtt0836 in long term - yes.

I am sorry to bother but I am just starting to learn how to handle my flipper zero. How can I add the write to Mifare Classic 1k/4k or Ultralight? How do I convert to a .FAP ? Is there a tutorial?

Merci...

@Tahtmaache try corresponding channels on our discord or forum

Sweet. I found the NFC_Magic_Gen4.FAP in the "were can I find,", but it doesnt seem to Write Mifare Classic Ultralight. Is there another version somewere?

Thks

Hi ! I have been testing this firmware for a few days and the new functionality seems to work correctly. However, the application might have a problem : in some cases, consumption of the flipper can get up to 200mA !

Here is how to reproduce the issue :

• Open the app
• Select "Authenticate Gen4"
• Enter the password of your gen4 card
• Put the card under the flipper
• Select "More"
• Press the back key until you exit the application
• Go to the settings --> Power --> Battery Info
• High consumption

The only solution to cool your flipper down seems to be a good old reboot.

Can someone try to reproduce the issue ? I looked quickly but I could not see the part inside the source code that could explain this high consumption.

@nullableVoidPtr I've received gen4. Please sync this PR with dev and un-draft when ready.

Has anyone got the latest version working on v20 API (got the precompiled version from here: https://github.com/xMasterX/all-the-plugins/tree/main/apps and it seems to crash for me on open)

@skynet01 IIRC, with the recentmost commit I just merged with dev and the new major API with a compile test on my machine, but no further.

I'm currently travelling, so I unfortunately don't have a GTU card I can test with, but in hindsight I should have launched the app as a smoke test. I'll get to that shortly.

Are there any concrete plans / ETA on getting this merged?

@hacdias as soon as PR creator un-draft it

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

I’m super exited and just want to make sure. @nullableVoidPtr With this update would we be able to write 7-byte UID? If so this would be a function I've been waiting for months! Thank for all the help and work.

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

I’m super exited and just want to make sure. @nullableVoidPtr With this update would we be able to write 7-byte UID? If > so this would be a function I've been waiting for months! Thank for all the help and work.

The previous API version worked with 7-byte UID, I tested it myself. We just need to wait for him to update it so it works with the latest API. I've haven't updated my flipper for the last 3 weeks because I use this functionality often :)

I can also confirm the bug @MatthisC describes. After following the steps to reproduce, the power consumption goes over 200mA and stays there until reboot.

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.