Mfc 1k Full emulation (not UID only) with OEM readers

[spp2000]

There are several reports (also in other communities) of lack of communication between Ultra/Lite and various OEM readers (for Mifare Classic 1k Full Emulation), so they do not respond at all when an Ultra/Lite approaches. At the same time, not a single case seems to be reported yet where Full Emulation works properly with OEM readers. Conversely, there are no problems if the reading tests are performed with the various tools (Proxmarx3 all versions, Chameleon Ultra as a reader, Flipper zero and smartphones), which would seem to be much more tolerant. But the real purpose of Chameleon is not to use with these devices!

The problem lies in the fact that, while the Anti-collision is completed, the Authentication to the Mifare blocks is not completed (therefore the ReadBlock is not reached). For this reason the issue concerns the Full emulation: if the OEM application needs only the UID there are no problems, while if it requires the reading of a block it fails (no answer at all).

Various traces (Proxmark3 sniff) have been acquired with Ultra/Lite, from which it can be seen that with the current firmware the authentication phase to the Mifare blocks is not completed. To have a reference of how the communication should be, traces were also acquired with a passive tag and Mini Rev.G (which works fine).

The problem seems to be mainly related to the Frame Delay Time (fdt) after AUTH-B (61xx), which seems to be too short so the reader stops communicating.

As suggested by @doegox, mainly two types of tests were done:

1. disabling Fast Emulation (NFC_MF1_FAST_SIM in nfc_mf1.h)
2. leaving Fast Emulation active but adding a delay (bsp_delay_us(30); in nfc_mf1.c line 558 + #include bsp_delay.h)

Test results:

1. you get an increase in fdt, communication has improved a bit, but the OEM readers still fail to complete authentication.
2. As suggested, delays from 42 to 50 were tested, without success. The first complete reading was obtained with a delay of 30.

These tests were performed with Chameleon Lite because with Ultra it isn't possible to sniff, because the field is too weak (small antenna?) to couple reader ad Ultra with the Proxmark3 (Easy) in the middle (white LED doesn't turn on) Furthermore, loading this modified FW on Ultra too, it doesn't work. I do not know why.

Not having all the necessary skills to go further, I submitted this issue to you. I hope it helps as a starting point to get a definitive fix. If you need, I can help by testing the fix (or trials) on 3 different OEM applications with both Ultra and Lite.

Attachments:

• Doegox suggestion
• Trace of Lite with actual FW: too fast/incomplete authentication
• Trace of Lite with bsp_delay_us(30): quite ok with Lite, still KO with Ultra (idk)
• Trace of Passive Tags: OK
• Trace of Mini Rev.G: OK
• Comparison of traces with different devices (see 1st column)

Lite with actual FW: too fast/incomplete authentication

Lite with bsp_delay_us(30): quite OK with Lite (still KO with Ultra)

Passive Tags: OK

Mini Rev.G: OK

Comparison of traces with different devices (see 1st column). Last 3 raws are derived from pictures in this repo.

It's interesting (for me) that after AUTH-B(16) we have:

Lite w/ FAST_SIM & no delay: fdt 1444 is too fast Lite w/ FAST_SIM & delay(30): fdt 1924 seems OK! Lite w/ FAST_SIM & delay(42): fdt 2084 KO! ...slow? Lite w/ FAST_SIM & delay(60): fdt 2340 KO! ...slow?

BUT

Passive tag: fdt 2036 is OK! Mini Rev.G: fdt 9332 is OK! See previous picture.

Thank you very much!

[doegox]

The emulated tag I tried to read with MCT had half first sectors with unknown key and second half with FF and there were no bugs

[xianglin1998]

The emulated tag I tried to read with MCT had half first sectors with unknown key and second half with FF and there were no bugs

My phone is no bug too.

[xianglin1998]

The biggest difference between fixed patches and master branch is nfc_tag_14a_tx_bits function, prior to this, the function that sent the bit stream used FreeRun FrameDelay mode, and immediately sent the data after all encryption calculations were completed, regardless of timing synchronization. In theory, this patch should work very well, but currently it doesn't. Is there a more difference in the timing required for mobile phones compared to OEM Readers?

[xianglin1998]

Is it still too fast to respond the bitstream data now? So much so that the phone hasn't ready yet?

[doegox]

@LoganMcClay what model is your phone ?

[xianglin1998]

@LoganMcClay what model is your phone ?

BTW, Samsung and Google phones are not commonly used in China. Hahaha

[doegox]

ok, Pixel 6 Pro has a STMicroelectronics NFC Controller ST54K Maybe other brands in China use the same chipset @xianglin1998 ?

[xianglin1998]

ok, Pixel 6 Pro has a STMicroelectronics NFC Controller ST54K Maybe other brands in China use the same chipset @xianglin1998 ?

It is possible, but mobile phone manufacturers have not publicly disclosed the chip models they use, making it difficult to obtain relevant information.

[spp2000]

Yes it's always interesting to try to understand the issue. Maybe also for DXL. If it's content dependent, could you create some arbitrary contents showing the different behaviors so no personal data is used and you can share them freely ? If there is really a dependence with the data, this should be with anticollision data before crypto1. Block content encrypted with crypto1 will always be different according to the nonces so I don't see how one block content could systematically cause issues compared to another block content. But who knows...

Very nice tool that nfc-laboratory! Great. ;) The collision you showed us, did you see it with the proxmark as reader?

Using the patch (which should be: DXL fix + your delay w/ FAST_SIM) did not bring visible improvement in smartphone tests.

Ok, I'll try changing some personal data and changing some keys (not to be public) to freely share these dumps and, at the same time, to see if by any chance there is something different in the behavior. I need some time to do this. I'll be back as soon as I can.

Before crypto1 there should be only ATQA, UID and SAK. Is it correct? I'll try to find some correlation with my UID and SAK.

I will also try to get new traces to see if I find collisions in other places too, maybe during or after the authentication. I don't know

[doegox]

Collision is with the OEM reader. Yes before crypto1 is just the anti-collision messages then 60xx. From there it is "random" and statistically independent of the block data

[spp2000]

Doing some tests by modifying the dumps and trying to read them with the phone, I came to a couple of very weird conclusions:

• what causes the behavior of "Dump Slot1" (flickering of the RF LED and occasional detection of the tag) is... the keyA of sector 0! If A0A1A2A3A4A5 then there's flickering, otherwise it remains still. confused I did a cross check: if I start from a blank dump and only set KeyA(0)=A0A1A2A3A4A5 I have flickering and bad detection of the tag. If I start with the full "Dump Slot1" (which had flickering and had that key) and if I change even a single byte of that key, the flickering disappears and it behaves like "Dump Slot2".

• now, let's talk about the reading of a dump without flickering (with KeyA(0) different from A0A1A2A3A4A5). If I try to read the content with MCT using the correct keyset, as soon as I tap the "Start mapping & Read tag" button, the phone beeps/vibrates and pops up the message "Found new tag". It seems like the communication restarted from the beginning. BUT... if I try to read it using a different keyset (even very large), which does not contain any correct key....the communication is not lost (no beep/vibration, no "Found new tag" pop-up) and MCT tries to read it with all those keys, without ever losing connection with the tag. At the end it simply tells me that it haven't found any valid key. So it seem that the connection resets as soon as it makes a valid authentication. It likes wrong keys! :D

I hope these tests have added some useful information, even if they aren't related to the collisions that @doegox showed us.

[doegox]

The different behaviour with A0A1A2A3A4A5 is probably due to a tentative to handle the tag as having a MAD content, maybe even a NDEF. Cf https://www.nxp.com/docs/en/application-note/AN1305.pdf figure 10. Still the emulation should not differ from a real tag with the same content :)

[spp2000]

Looking at the traces, my phone always try to read blocks 1-2-3 with A0A1A2A3A4A5 as a credential approaches. Imho also the Reader no.2 could try the same, bacause its MAD blocks are properly written, are consistent with the content of the tag. Maybe it want to check if the tag is familiar.

[spp2000]

@xianglin1998 looking at the code, can you think of anything that can cause those two strange behaviors?

Meanwhile I'm looking at the differences between the traces with legit tag, patched fw and master branch fw

[xianglin1998]

@xianglin1998 looking at the code, can you think of anything that can cause those two strange behaviors?

Meanwhile I'm looking at the differences between the traces with legit tag, patched fw and master branch fw

It's interesting, which means that once the verification is successful, the phone will lose the link. And coincidentally, the nfc_tag_14a_tx_bits function is only called after successful validation.

[xianglin1998]

After anti-coll,

1. Reader send 60 xx to request auth.
2. Tag response a not encrypted nonce (bytes_transfer, call the nfc_tag_14a_tx_bytes function)
3. Reader send nr ar
4. Tag response at if auth success... (bits_transfer, call the nfc_tag_14a_tx_bits function)

You must be broken at auth success, interesting, the first call nfc_tag_14a_tx_bits is in here, and our key change is here. Yes, we change the nfc_tag_14a_tx_bits, from NRF_NFCT_FRAME_DELAY_MODE_FREERUN change to NRF_NFCT_FRAME_DELAY_MODE_WINDOWGRID to fixed timing bug. to controll timing.

I am very skeptical now, is there any register or parameter that needs to be reset after using this FDT parameter?

It is obvious that in order to fix the compatibility issue with OEM readers, we must strictly control the timing. We cannot abandon the change of this parameter, and we can only start from other places and try to solve the problem caused by this change.

[spp2000]

@doegox looking at the traces, the problem (that justifies both the weird behaviors) is that, after the first correct authentication, Ultra reply too fast to the first WUPA (fdt about 850 instead of 1250). The phone don't see it, assume that it's gone and restart again Anticoll....

• If KeyA is A0A1A2A3A4A5, the first correct authentication occurrs automatically as soon as Ultra approach the phone, so the communication restarts automatically and LED flickers
• Otherwise communication restarts only if the keyset is correct

DXL is now working to try to increase that fdt

First approach of Ultra to the phone, with keyA MAD:

(Key A different from MAD key) When I try to map the slot with correct keyset:

First approach of LEGIT TAG to the phone, with keyA MAD:

[spp2000]

@DXL did it! ;) No more LED flickering, able to dump Chameleon with my phone, Reader no.3 ok, mfkey32 ok. Next week I will test Reader no.2 (the hardest one) and Reader no.1

[Markg546]

Updated from DXL's patch to the latest on GitHub and the chameleon stopped working with the readers. While with DXL's it worked somewhere 2/3 times. What else was changed?

[doegox]

reopening till this last one is sorted out...

[mitmarcus]

Here's how the DXL patch works. From my own observations it only works when the chameleon wakes from sleep and you need some distance for it to work, also the RFID led behaves interestingly. Nonetheless it works for my house, fitness center and uni.

chameleon_ultra_app_update.zip

https://github.com/RfidResearchGroup/ChameleonUltra/assets/114725463/146d761d-b912-4aea-91bb-c52fe5e007b5

This is the current fw from github (05b220). It just fails to work with my house. Got it to work 1/3 times at the fitness center but that was a bit embarrassing. And no idea if it works with the uni.

https://github.com/RfidResearchGroup/ChameleonUltra/assets/114725463/4eb91dca-ea7c-4c6e-91cf-5b4de5310d36

Sadly I don't possess a PM3 to sniff the data, however I would be glad to help if there are any tests I can do.

[spp2000]

Hi, I'm testing again the last FWs to see if and when I have issues. In the meantime, if there are no other suggestions, @Markg546 @mitmarcus can you check if this fw is good for you? This the one with the bugfix for Lite (and Ultra too).

ultra-dfu-app_commit-f934f54.zip

[spp2000]

DXL.mp4

Current_github.mp4

Sorry, @mitmarcus I've not understood what the reader should do (led color and beep) when it works correctly.

[mitmarcus]

Sorry for not being concrete. Red and beeping means error. Green and just a short beep means open.

Here's your modified fw on the same reader. The led shines much more consistently but it still doesnt work.

https://github.com/RfidResearchGroup/ChameleonUltra/assets/114725463/403bbb5a-900a-482b-9b35-31cda9ba7d91

[spp2000]

My tests with last commits:

• 05b2270 (actual): no issue (Ultra/Lite) with phone and Reader no.3
• f934f54 (bugfix for Lite): no issue (Ultra/Lite) with phone and Reader no.3
• cda2413 (first big DXL fix): no issue, except that Lite is not seen by the phone (Lite doesn't reply to the phone - RF LED flashing)

Tomorrow I will test (and pm3 sniff) other 2 readers to see if I experience the same issue of @mitmarcus so we can figure out where the issue occurs.

[spp2000]

You are lucky (not me). 😄 I confirm that with latest FW 05b2270 from github CU and CL don't work with my Readers no. 1 and 2.

Reader no. 1: no reaction at all with CU/CL. RF LED blinks slowly (about 1Hz). Never had problem with this reader before

Reader no. 2: communication restart continuously, maybe after 1st good authentication

I'm going to investigate.

[mitmarcus]

You are lucky (not me). 😄 I confirm that with latest FW 05b2270 from github CU and CL don't work with my Readers no. 1 and 2.

Reader no. 1: no reaction at all with CU/CL. RF LED blinks slowly (about 1Hz). Never had problem with this reader before

Reader no. 2: communication restart continuously, maybe after 1st good authentication

I'm going to investigate.

Got super lucky that the DXL fw is actually working on the readers more often than not😄. Thank you for investigating!

[spp2000]

Populating this matrix... because I was lost with all that test results Almost finished. I've got also traces of the last column..to be analysed...

@xianglin1998 @doegox what do you think? @mitmarcus @Markg546 can you summarize your tests, so I can add them to this matrix to have a global overview?

[spp2000]

Last column, actual situation, these are my two KO (Rdr 1 & Rdr 2), the same for Lite and Ultra:

• Rdr 1 - no response - only RF blinking.txt
• Rdr 2 - Continuous restart of communication.txt

These are the traces of Rdr 2 with its TAG: Rdr 2 - Legit TAG (trace 1).txt Rdr 2 - Legit TAG (trace 2).txt Rdr 2 - Legit TAG (trace 3).txt

[mitmarcus]

Populating this matrix... because I was lost with all that test results Almost finished. I've got also traces of the last column..to be analysed...

@xianglin1998 @doegox what do you think? @mitmarcus @Markg546 can you summarize your tests, so I can add them to this matrix to have a global overview?

yes, no fancy excel and less scientific because the results are the same. All but the first DXL patch give the same results. Reader denies the card. Seems to try to read it fine but then spits out error (home, uni, fitness).

The first DXL patch for me is quite a miracle. It works on all of them (home, uni, fitness). But really interesting observation, distance seems to play a big role. Upon further test it only works from about 3cm (fitness, uni) and about 5cm (home).

Now because its a campus (home) I have access to a lot of readers here. They are the same type (Salto Modular XS). However they don't seem to behave the same. I found one which seems to have a weeker antena? with that one I can come closer (again around 3 cm) but get any closer and it gives out error get any farther and it isnt enough to activate the chameleon.

I would continue using the DXL patch because it does it's job, but curiosity is killing me. Also the slowness of reading from the chameleon :d

TLDR: DXL patch nr1 is the only thing that works with the readers I have around me. Seems to work with all, not 100% of the times but I've gotten pretty good at finding the sweet spot. Other patches, even factory fw do not work.

[doegox]

The first DXL patch for me is quite a miracle. It works on all of the

cda2413, the last but one column ?

[mitmarcus]

The first DXL patch for me is quite a miracle. It works on all of the

cda2413, the last but one column ?

could you please elaborate what you mean?

[doegox]

could you please elaborate what you mean?

What is "the first DXL patch" ? does it correspond to commit cda2413 which is the last but one column of @spp2000 ? or another column? or yet something not in the table ?

[mitmarcus]

could you please elaborate what you mean?

What is "the first DXL patch" ? does it correspond to commit cda2413 which is the last but one column of @spp2000 ? or another column? or yet something not in the table ?

Iiiiiii ... am not sure, shows dev-172-gc70165f-dirty.

This one is the one I refer to as DXL first patch

chameleon_ultra_app_update.zip

I disabled FAST_SIM and modified the transfer function. For quick testing, I will first directly build an update package. If it works, I will submit the code to the repo.

[doegox]

ok, I tried to create a branch with what I assume was the code used in the "1st DXL patch". @mitmarcus could you test code from this branch https://github.com/RfidResearchGroup/ChameleonUltra/tree/test_dxl_1st_patch ? Ultra DFU app artifacts is here: https://github.com/RfidResearchGroup/ChameleonUltra/suites/15853816969/artifacts/904631629

[mitmarcus]

ok, I tried to create a branch with what I assume was the code used in the "1st DXL patch". @mitmarcus could you test code from this branch https://github.com/RfidResearchGroup/ChameleonUltra/tree/test_dxl_1st_patch ? Ultra DFU app artifacts is here: https://github.com/RfidResearchGroup/ChameleonUltra/suites/15853816969/artifacts/904631629

Tried with home reader, fails constantly. Used the artifact from link provided (1dcafce)

[doegox]

Hmm then I don't know what was exactly in the code of that 1st patch :(

[mitmarcus]

chameleon_ultra_app_update.zip

I disabled FAST_SIM and modified the transfer function. For quick testing, I will first directly build an update package. If it works, I will submit the code to the repo.

do you remember what you changed?

[spp2000]

@doegox , I suppose @mitmarcus is referring to the 2nd column: "chameleon_ultra_app_update.zip - from DXL issue #110" . In fact the file that DXL attached here wasn't compiled from github (so it's dirty) Hope you understand me :)

[spp2000]

If you go here you can see also the changelog

I've finished populating my matrix. The only reader that could behave like mitmarcus might be Rdr 1 (only 2nd column works), but in my case Chameleon don't answer at all to the Rdr 1 (not even ATQA), while mitmarcus receive an error from the reader).

@mitmarcus I think it's time to give yourself a proxmark3, you deserved it! ;)

[xianglin1998]

chameleon_ultra_app_update.zip I disabled FAST_SIM and modified the transfer function. For quick testing, I will first directly build an update package. If it works, I will submit the code to the repo.

do you remember what you changed?

All changes to this firmware are recorded in the screenshot below.

[xianglin1998]

@mitmarcus Try it: chameleon_ultra_app_update.zip

[xianglin1998]

And this file is compile from 8cd427e

[mitmarcus]

@mitmarcus Try it: chameleon_ultra_app_update.zip

tried this one (dev-210-g1dcafce-dirty). Have so far tried with only my uni (HID IClass SE) and it works 📣!

[xianglin1998]

@mitmarcus Try it: chameleon_ultra_app_update.zip

tried this one (dev-210-g1dcafce-dirty). Have so far tried with only my uni (HID IClass SE) and it works 📣!

Why using (HID IClass SE) to test? Can this firmware work on your home card reader?

[mitmarcus]

@mitmarcus Try it: chameleon_ultra_app_update.zip

tried this one (dev-210-g1dcafce-dirty). Have so far tried with only my uni (HID IClass SE) and it works 📣!

Why using (HID IClass SE) to test? Can this firmware work on your home card reader?

I will be able to do that only later in the day

[xianglin1998]

@mitmarcus Try it: chameleon_ultra_app_update.zip

tried this one (dev-210-g1dcafce-dirty). Have so far tried with only my uni (HID IClass SE) and it works 📣!

Why using (HID IClass SE) to test? Can this firmware work on your home card reader?

I will be able to do that only later in the day

Why you are (dev-210-g1dcafce-dirty), Are you downloading the firmware I sent:

[mitmarcus]

@mitmarcus Try it: chameleon_ultra_app_update.zip

tried this one (dev-210-g1dcafce-dirty). Have so far tried with only my uni (HID IClass SE) and it works 📣!

Why using (HID IClass SE) to test? Can this firmware work on your home card reader?

I will be able to do that only later in the day

Why you are (dev-210-g1dcafce-dirty), Are you downloading the firmware I sent:

yup its the zip, I just flash the zip you sent in this chat.

[xianglin1998]

@mitmarcus Try it: chameleon_ultra_app_update.zip

tried this one (dev-210-g1dcafce-dirty). Have so far tried with only my uni (HID IClass SE) and it works 📣!

Why using (HID IClass SE) to test? Can this firmware work on your home card reader?

I will be able to do that only later in the day

Why you are (dev-210-g1dcafce-dirty), Are you downloading the firmware I sent:

yup its the zip, I just flash the zip you sent in this chat.

In this firmware, I disabled resetting the NFC core when leaving the Field, which is a critical modification. Please review the code for details. If you test later and it can work on your home card reader, then the problem may be clear.

[spp2000]

Could Chamele0n behave differently than Chameleon? or they have to behave in the same way?