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!

[cyber-vi-king]

I'm sure this won't help much, but last week I successfully used a SALTO 1K 7b UID tag on my ultra to open a door. And I kinda assumed that they check more than just the UID. I didn't sniff any communication though and have no access to said door for another one or two weekends.

[spp2000]

It could be very interesting to have a trace of that, to confirm what you are assuming and to make a comparison with your reader. If you can do it, we will appreciate it. Thanks

[JianbangWu]

Hoping my trace files can help. #91

[spp2000]

Hoping my trace files can help. #91

Hi, the trace physicalcard is useless because the Reader is missing, btw the trace with Chameleon is fine and it's useful because we have the same problem: Anticollision is ok (reader gets correctly the UID), but the Authentication fails at the same point, so the reader can't get the content of the block 2 (in your case). I hope I explained well. Do you have some info about the reader? brand, model, picture... Thanks

[xianglin1998]

Let me conclude:

1. Unable to work on OEM reader after turn off FAST_SIM too. Can you describe the reason why although communication has improved, it still cannot work on the reader? That is to say, which step in the communication did the problem occur? The fdt result for my ChameleonDev disable fast_sim to simulation: The FDT above is noticeably much slower, which should not be unable to work.

2. Can work after adding Delay In which steps did you add a delay?

[spp2000]

Let me conclude:

1. Unable to work on OEM reader after turn off FAST_SIM too. Can you describe the reason why although communication has improved, it still cannot work on the reader? That is to say, which step in the communication did the problem occur? The fdt result for my ChameleonDev disable fast_sim to simulation: The FDT above is noticeably much slower, which should not be unable to work.
2. Can work after adding Delay In which steps did you add a delay?

Hi @xianglin1998,

1. With "actual github" fw setting the communication never go further auth-nt. With FAST_SIM disabled, often (reading the whole trace) it can go further, but not to the end (= read_block data w/ CRC OK); in the full pm3 trace I see more auth-at, sometimes with "wrong key" or data_block with bad/incomplete data.
2. With the delay (maybe having a better control on the fdt) the communication is still improved because I can go to the readblock data, with data correctly read by the reader (CRC OK). But this not always happens, in fact I have to stay few seconds with chameleon near the reader (also changing the distance) and wait for a complete communication. So it needs to be improved. The delay is added where doegox suggested, please see 1st picture.

Note: as I said, these test were performed with Chameleon Lite, because Ultra can't work even with that delay. I have to find a way to sniff Ultra too.

I hope I answered your questions Why, in you hf mf list -f , CRC and annotation columns are blank (so you had to write your annotation on the picture)?

[doegox]

Here are some traces shared by someone having similar issues. I got a setup so I should be able to do some more tests by myself soon.

"reader" = the problematic OEM reader.
Filenames should speak by themselves.

• ultra_reader_FASTSIM_broken.txt: it seems even the Proxmark has difficulties parsing the Ultra AUTH_NT
• ultra_reader_NOFASTSIM.txt: reader replies to AUTH_NT, tag sends AUTH_AT but reader doesn't see it? on second trace, even Proxmark doesn't see it?
• ultra_reader_FASTSIM_delay100.txt: AUTH_NT ok, then even Proxmark doesn't see AUTH_AT?
• ultra_reader_FASTSIM_delay50.txt: AUTH_NT ok, then even Proxmark doesn't see AUTH_AT?
• mfcev1_reader.txt: testing reader with a MFC EV1, all fine
• oldinfineon_reader.txt: testing reader with an old MFC, all fine
• mfp2kev1sl1_reader.txt: testing reader with a MF+ 2k EV1 in SL1, all fine
• minig_reader.txt: testing reader with Chameleon Mini revG emul, all fine
• pm3_reader.txt: testing reader with Proxmark3 emul, all fine
• ultra_pm3_FASTSIM.txt: testing Ultra with Proxmark3, all fine
• ultra_pm3_NOFASTSIM.txt: testing Ultra with Proxmark3, all fine

[mitmarcus]

How can one try the delay fix?

[spp2000]

Great news that you got a setup @doegox!! and thank you for sharing this interesting test results.

Newbie question: is it normal that fdt after AUTH-A|B is different depending on whether I read Chameleon with Pm3 or with the "reader" (w/ Pm3 in the middle)? In my traces too, I see that if I use proxmark as reader the fdt is shorter by 100-150. In my mind it should be indipendent of the reader :)

PS: the only comforting thing for me is that the issue is always the same and seems to be perfectly reproducible.

[spp2000]

How can one try the delay fix?

Hi @mitmarcus, please read 1st picture...you have to add an include at the beginning and the delay at line 558 (actual nfc_mf1.c). Btw maybe the delay isn't the only responsible for the issue.

[xianglin1998]

Here are some traces shared by someone having similar issues. I got a setup so I should be able to do some more tests by myself soon.

"reader" = the problematic OEM reader. Filenames should speak by themselves.

• ultra_reader_FASTSIM_broken.txt: it seems even the Proxmark has difficulties parsing the Ultra AUTH_NT
• ultra_reader_NOFASTSIM.txt: reader replies to AUTH_NT, tag sends AUTH_AT but reader doesn't see it? on second trace, even Proxmark doesn't see it?
• ultra_reader_FASTSIM_delay100.txt: AUTH_NT ok, then even Proxmark doesn't see AUTH_AT?
• ultra_reader_FASTSIM_delay50.txt: AUTH_NT ok, then even Proxmark doesn't see AUTH_AT?
• mfcev1_reader.txt: testing reader with a MFC EV1, all fine
• oldinfineon_reader.txt: testing reader with an old MFC, all fine
• mfp2kev1sl1_reader.txt: testing reader with a MF+ 2k EV1 in SL1, all fine
• minig_reader.txt: testing reader with Chameleon Mini revG emul, all fine
• pm3_reader.txt: testing reader with Proxmark3 emul, all fine
• ultra_pm3_FASTSIM.txt: testing Ultra with Proxmark3, all fine
• ultra_pm3_NOFASTSIM.txt: testing Ultra with Proxmark3, all fine

Perfect testing and summary, so that I have a clear understanding of where the problem occurred.

[mitmarcus]

How can one try the delay fix?

Hi @mitmarcus, please read 1st picture...you have to add an include at the beginning and the delay at line 558 (actual nfc_mf1.c). Btw maybe the delay isn't the only responsible for the issue.

Having a bit of a problem

Also is there a way to disable fast simulation?

[spp2000]

How can one try the delay fix?

Hi @mitmarcus, please read 1st picture...you have to add an include at the beginning and the delay at line 558 (actual nfc_mf1.c). Btw maybe the delay isn't the only responsible for the issue.

Having a bit of a problem

Also is there a way to disable fast simulation?

If you want I can send you the compiled DFU FW with this partial fix so you can test it easily. DM @paul.73 in discord

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

[xianglin1998]

My changelog:

[xianglin1998]

@spp2000 Can you help me test it?

[spp2000]

Thank you @xianglin1998. I try it now on 2 readers. If you give me the Lite too I can also sniff the communication with pm3

[xianglin1998]

Ok，here：@spp2000 chameleon_lite_app_update.zip

[spp2000]

Ok，here：@spp2000 chameleon_lite_app_update.zip

@xianglin1998 Lite won't update fw. Did you modified build.sh too?

[xianglin1998]

Let me review it, After the review, no abnormal modifications were found. This is the command I used to generate Lite firmware: nrfutil pkg generate --application application.hex --application-version 1 --hw-version 1 --sd-req 0x100 --key-file ../ChameleonUltraRRG/resource/dfu_key/chameleon.pem chameleon_lite_app_update.zip I am developing using Windows, so I did not use build.sh, but theoretically their functionality is the same.

[spp2000]

Sorry, I tried again and now it has programmed..i don't know why refused to program before

[spp2000]

@xianglin1998 First test with reader no. 1 is OK with Lite and Ultra. This is Lite trace. this is the first part of the trace, so it worked fine soon without hesitation! Great!

With reader no. 2 I have a problem because Chameleon reboot continuously after few seconds... Maybe again watchdog issue?

[xianglin1998]

@xianglin1998 First test with reader no. 1 is OK with Lite and Ultra. This is Lite trace. this is the first part of the trace, so it worked fine soon without hesitation! Great!

With reader no. 2 I have a problem because Chameleon reboot continuously after few seconds... Maybe again watchdog issue?

I am not sure about the issue with continuously restarting. Perhaps I made some changes that caused the device to have this problem, but I am happy to hear you tell me that it is working because the NFC chip of NRF52 has a lot of registers to set. I may not have a good understanding of the register during my previous development, which resulted in some parameter settings being incorrect, such as the current issue, It may be caused by frame delay (and possibly other factors).

[spp2000]

@xianglin1998 Update: With this fix both ultra and lite are no more recognised by the phone nfc. RF led blinks and nothing happens

[xianglin1998]

@xianglin1998 Update: With this fix both ultra and lite are no more recognised by the phone nfc. RF led blinks and nothing happens

OK, not big problem.

[spp2000]

---

In this comment I will publish all the results with DXL fix. I will edit only this comment for every test I do, to have a complete overview in the same place.

---

• Reader no.1 (readblock operation only) --> OK Lite and Ultra now can be read without problem. Lite trace:

• Reader no.2 (readblock(s), writeblock(s), increment, decrement operations) --> work in progress Ultra and Lite ko: by looking at the reader's LEDs (and beeps), the reader does correctly Anticollision, Auth and ReadBlock, but instead of waiting for next commands, it starts again with Anticollision, etc etc Have some problem taking a good trace to find out why the communication restart from the beginning... Still work in progress....

• Reader no.3 (readblock operation only) --> OK Also with this reader both Lite and Ultra are recognized correctly!! Great

• Smartphone --> work in progress With a specific dump, Lite and Ultra are not recognized by the phone when they approach it. The same dump in a tag or in Chameleon Rev.G has no problem with the same phone. I have to better investigate. Still work in progress...

We are seeing the light at the end of the tunnel, thx to @xianglin1998

---

As a consequence of this fix, also the issue of the few nonces - no key recovered seems to be fixed. Comparison between today's build Vs fixed build:

[xianglin1998]

@xianglin1998 Update: With this fix both ultra and lite are no more recognised by the phone nfc. RF led blinks and nothing happens

I just tested it and found that this can be recognized by my phone. But at the beginning, it also couldn't work until I run the hw factory_reset, I suspect that my firmware is too old, so that some settings or data that exist in flash are outdated.

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

https://github.com/RfidResearchGroup/ChameleonUltra/assets/114725463/29981e57-9b1e-411d-a6b1-5a74d87b7404

Thank you for the build. The chameleon finally works with the reader I have (Salto Modular XS). Distance seems to play a role in it working or not. But at least the reader doesn't outright deny the chameleon.

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

20230831_162141.mp4 Thank you for the build. The chameleon finally works with the reader I have (Salto Modular XS). Distance seems to play a role in it working or not. But at least the reader doesn't outright deny the chameleon.

I am very happy to hear this feedback, it seems that the situation is becoming increasingly clear.

[LoganMcClay]

Fixed firmware also works for me on Urmet reader, it was failing with all previous builds. Cards are MFC 1k.

(Offtopic, but like Comelit brand, it uses some patterns to track copied badges but that protection is not used here.)

[spp2000]

DXL fw - Ultra - Reader no.3

Can't stop!

https://github.com/RfidResearchGroup/ChameleonUltra/assets/42212032/1e53dafc-a7ca-44a4-90a0-2836c2012daa

[Markg546]

DXL fw - Ultra - Reader no.3

Can't stop!

DXL_ultra_Reader3.mp4

That's a nice case, where did you get that?

[spp2000]

DXL fw - Ultra - Reader no.3 Can't stop! DXL_ultra_Reader3.mp4

That's a nice case, where did you get that?

Are you referring to the condom? ;) Found inside the box Silicone case, nice feeling

[Markg546]

DXL fw - Ultra - Reader no.3 Can't stop! DXL_ultra_Reader3.mp4

That's a nice case, where did you get that?

Are you referring to the condom? ;) Found inside the box Silicone case, nice feeling

haha nice addition to the "package" ;)

[spp2000]

Hi there! @mitmarcus @LoganMcClay @Markg546 I need your feedback. After updating Chameleon with this fixed firmware are you still able to dump the content of the slots with your smartphone (e.g. with MCT app)? What model?

@doegox may we have a feedback on this fix also from you and the guy who sent the pm3 traces?

Thanks

[doegox]

Hi I also confirm it works fine on the reader that was causing troubles previously.

Maintaining the ultra on the reader: once the reader has read a tag, it polls continuously with a brief 5.3ms RF field off then anticol. When it sees the same tag it does nothing for 85ms then start next polling. Under these conditions, the ultra stays simply activated all long, without any reboot or whatever.

Smartphone: Reading ultra mfc with MCT went fine on my OnePlus 7t pro.

So no problem so far here.

FYI the previous "ultra_reader_FASTSIM_broken.txt: it seems even the Proxmark has difficulties parsing the Ultra AUTH_NT" behavior was due to the reader to not see and not wait for AUTH_NT and to send another command at the same time the end of the ultra frame was still being emitted.

[mitmarcus]

Hi there! @mitmarcus @LoganMcClay @Markg546 I need your feedback. After updating Chameleon with this fixed firmware are you still able to dump the content of the slots with your smartphone (e.g. with MCT app)? What model?

@doegox may we have a feedback on this fix also from you and the guy who sent the pm3 traces?

Thanks

Dumping seems to work no problem. The chameleon works with all readers it previously didn't for me. Galaxy S8 also sees the card.

[doegox]

I tested also DXL patch but with keeping NFC_MF1_FAST_SIM and introducing a bsp_delay_us(50); before outputting AUTH_NT.

It works also very well against "the reader" and against my phone (MCT).

I think it's interesting to keep the NFC_MF1_FAST_SIM because it gives more flexibility on timings. It's just a matter of introducing delays to adjust to any timing we want to test.

Comparing FDT of the different tag responses towards the reader, I get:

Response	DXL	DXL+FAST_SIM+delay(50)	old MFC	MFC EV1	MF+ 2k EV1 SL1
AUTH_NT	2084	2084	1956	4772	11540
AUTH_AT	3124	2148	1188	1252	4948
Block data	5284	3236	1332	1188	15508

[LoganMcClay]

I have mixed results reading the emulated cards on my phone.

• Chamele0n Ultra
• Pixel 6 Pro
• Slot 1 : Urmet Captiv dump.
• Slot 2 : Comelit Immotec dump.

Both emulated cards works on their respective reader with the fixed firmware, but when trying to read them with MCT, Slot 1 card works, but slot 2 card fails every time...

[doegox]

Both emulated cards works on their respective reader with the fixed firmware, but when trying to read them with MCT, Slot 1 card works, but slot 2 card fails every time...

how does it fail ? what is the difference you observe between reading the real tag with MCT and reading the ultra with MCT?

[doegox]

I tested also DXL patch but with keeping NFC_MF1_FAST_SIM and introducing a bsp_delay_us(50); before outputting AUTH_NT.

the patch if some of you want to test this approach as well (remember to undo commenting NFC_MF1_FAST_SIM if you did for testing)

diff --git a/firmware/application/src/rfid/nfctag/hf/nfc_14a.c b/firmware/application/src/rfid/nfctag/hf/nfc_14a.c
index c293a84..be4f94f 100644
--- a/firmware/application/src/rfid/nfctag/hf/nfc_14a.c
+++ b/firmware/application/src/rfid/nfctag/hf/nfc_14a.c
@@ -295,7 +295,7 @@ uint8_t nfc_tag_14a_unwrap_frame(const uint8_t *pbtFrame, const size_t szFrameBi
  * @param[in]   appendCrc  Whether to send the byte flow, automatically send the CRC16 verification automatically
  */
 void nfc_tag_14a_tx_bytes(uint8_t *data, uint32_t bytes, bool appendCrc) {
-    NFC_14A_TX_BYTE_CORE(data, bytes, appendCrc, NRF_NFCT_FRAME_DELAY_MODE_WINDOW);
+    NFC_14A_TX_BYTE_CORE(data, bytes, appendCrc, NRF_NFCT_FRAME_DELAY_MODE_WINDOWGRID);
 }

 /**@brief The function of sending the byte flow, this implementation automatically sends SOF
@@ -316,6 +316,7 @@ void nfc_tag_14a_tx_bytes_delay_freerun(uint8_t *data, uint32_t bytes, bool appe
  */
 #define NFC_14A_TX_BITS_CORE(bits, mode)                                                        \
     do {                                                                                        \
+        nrf_nfct_frame_delay_max_set(65535);                                                    \
         NRF_NFCT->PACKETPTR = (uint32_t)(m_nfc_tx_buffer);                                      \
         NRF_NFCT->TXD.AMOUNT = bits;                                                            \
         NRF_NFCT->INTENSET = (NRF_NFCT_INT_TXFRAMESTART_MASK | NRF_NFCT_INT_TXFRAMEEND_MASK);   \
@@ -332,7 +333,7 @@ void nfc_tag_14a_tx_bytes_delay_freerun(uint8_t *data, uint32_t bytes, bool appe
 void nfc_tag_14a_tx_bits(uint8_t *data, uint32_t bits) {
     m_is_responded = true;
     memcpy(m_nfc_tx_buffer, data, (bits / 8) + (bits % 8 > 0 ? 1 : 0));
-    NFC_14A_TX_BITS_CORE(bits, NRF_NFCT_FRAME_DELAY_MODE_FREERUN);
+    NFC_14A_TX_BITS_CORE(bits, NRF_NFCT_FRAME_DELAY_MODE_WINDOWGRID);
 }

 /**@brief The function of sending n bits is implemented, and this implementation is automatically sent SOF
diff --git a/firmware/application/src/rfid/nfctag/hf/nfc_mf1.c b/firmware/application/src/rfid/nfctag/hf/nfc_mf1.c
index 1939531..a262259 100644
--- a/firmware/application/src/rfid/nfctag/hf/nfc_mf1.c
+++ b/firmware/application/src/rfid/nfctag/hf/nfc_mf1.c
@@ -5,6 +5,7 @@
 #include "hex_utils.h"
 #include "fds_util.h"
 #include "tag_persistence.h"
+#include "bsp_delay.h"

 #ifdef NFC_MF1_FAST_SIM
 #include "mf1_crypto1.h"
@@ -555,6 +556,8 @@ void nfc_tag_mf1_state_handler(uint8_t *p_data, uint16_t szDataBits) {
                             // Set key flow
                             crypto1_word(pcs, bytes_to_num(UID_BY_CASCADE_LEVEL, 4) ^ bytes_to_num(CardNonce, 4), 0);
 #endif
+                            // Don't be faster than standard cards on AUTH_NT...
+                            bsp_delay_us(50);
                             // Responsible for clear -scale random number to read the card reader
                             nfc_tag_14a_tx_bytes(m_tag_tx_buffer.tx_raw_buffer, 4, false);
                             break;

[LoganMcClay]

The original Comelit card is read correctly by MCT, but the Ultra fails with error "None of the keys were valid for reading" Of course, I double checked and confirmed I was using the right keyset, dump and slot all matching.

[xianglin1998]

I feel like I need to find a phone that can reproduce this issue, which will make it easier for us to troubleshoot the problem.

[spp2000]

Thank you all! Interesting feedbacks. Next step for me is to test the @doegox patch with all my readers/phones. Thanks

---

The behavior described by @doegox is very interesting for me (at some point the reader no longer sees Ultra and starts sending commands before Ultra has finished) and seems to be compatible with the most of issues I'm having! I think I observed it in some traces taken with the legit Reader no.2. Since these traces looked bad, I thought the problem was that I hadn't been able to catch them, but it might be due to the fact that hf mf list fails to interpret this commands overlay well, with the result that the trace looks bad. Could this be the reason of my bad traces? At this point if they can help, I can try to acquire them again next week.

---

The smartphones I have problems with are Samsung A32 and A52s. (note: with the current fw from github I can dump fine Ultra and Lite)

The problem with the phones is also dependent on the content of the slots, as @LoganMcClay noted. While he can read one but not the other, In my case I can't read anything but I have different behaviors. I try to explain:

• Dump in Slot1: when Chameleon approaches the phone, it is not always seen (no beep from the phone) and the RF LED is flickering (bad). MCT sometimes sees the UID but then doesn't seem to see it anymore.
• Dump in Slot2: when Chameleon approaches the phone, it is immediately seen (phone beeps and UID appears on the screen), the RF LED remains still, but as soon as I tap the read button, it loses the connection and immediately the phone sees it again (beeps )...and so on. Sometimes randomly, he starts trying to read but says he can't find any keys (keys are of course correct)

@doegox I took 2 traces trying to read the Slot2 above with the current FW (OK) and with the FW DXL fix (KO). If you want I can send them to you.

[doegox]

The behavior described by @doegox is very interesting for me (at some point the reader no longer sees Ultra and starts sending commands before Ultra has finished) and seems to be compatible with the most of issues I'm having! I think I observed it in some traces taken with the legit Reader no.2. Since these traces looked bad, I thought the problem was that I hadn't been able to catch them, but it might be due to the fact that hf mf list fails to interpret this commands overlay well, with the result that the trace looks bad. Could this be the reason of my bad traces? At this point if they can help, I can try to acquire them again next week.

Yes your "broken" traces are very probably due to the same communication collision. I don't think it's needed to redo traces, whatever causes the reader to not see the tag message and to provoke a collision happens before the collision so we don't really care about what's going on after that.

Here is an example captured with nfc-laboratory btw

[doegox]

The smartphones I have problems with are Samsung A32 and A52s. (note: with the current fw from github I can dump fine Ultra and Lite)

The problem with the phones is also dependent on the content of the slots, as @LoganMcClay noted. While he can read one but not the other, In my case I can't read anything but I have different behaviors. I try to explain:

• Dump in Slot1: when Chameleon approaches the phone, it is not always seen (no beep from the phone) and the RF LED is flickering (bad). MCT sometimes sees the UID but then doesn't seem to see it anymore.
• Dump in Slot2: when Chameleon approaches the phone, it is immediately seen (phone beeps and UID appears on the screen), the RF LED remains still, but as soon as I tap the read button, it loses the connection and immediately the phone sees it again (beeps )...and so on. Sometimes randomly, he starts trying to read but says he can't find any keys (keys are of course correct)

@doegox I took 2 traces trying to read the Slot2 above with the current FW (OK) and with the FW DXL fix (KO). If you want I can send them to you.

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

[doegox]

The smartphones I have problems with are Samsung A32 and A52s.

Hmm according to https://chipik.com.ua/ua/p1828098753-mikroshema-s3nrn4vxs1-mx30.html both might use the S3NRN4VXS1-MX30 Samsung-specific NFC controller chip

[xianglin1998]

For example, using MCT to check read only one sector.

[xianglin1998]

If all the keys are successfully verified (0xFF * 12) and there are no sectors that failed verification. will there be no problem of losing links or having no valid keys?

[xianglin1998]

I'm guessing if for some reason, once a auth failure occurs, communication will be disrupted, resulting in all subsequent auth failing.