Errors/missing parts when sniffing in both directions

[madalinaStreche]

I try to record a communication between 2 devices, but from my logs it seems that Chameleon manages to sniff only in one direction: reader -> card. What about the transmitted data from the card to the reader? Are there any updates on this?

[fptrs]

Hi @madalinaStreche,
did you already take a look at #220?

[madalinaStreche]

Hi! I managed to update the Chameleon and now I can see the logs from both sides (card/reader). The other issue that I have right now is the fact that some messages are incomplete, altered or modified. I tried to record an EMV communication between a smartwatch and a Raspberry PI that acts like a POS. I sniffed with the Chameleon the same communication for 20 times, each communication has in total 14 messages(7 from the Raspberry and 7 responses from the smartwatch) and I created a statistics which suggests the frequency of altered/missing/incomplete messages. Most messages that have problems are responses from the smartwatch.
Do you have any idea why this is happening?

[ceres-c]

It might be due to autocalibration not being perfect, so quality of sniff depends on the physical position of the chameleon in the NFC field

[david-oswald]

@madalinaStreche Sniffing in the direction from reader to card should normally work without problems. The opposite direction is much harder due to the weaker load modulation. So it might depend on setup, calibration etc as the others pointed out.

[madalinamarin]

The autocalibraton mode is available only for reading mode? It will help if I will run the autocalibration in reader mode first and then change to sniffing?
Also, I just tried to sniff a real communication between smartwatch and POS during a payment and the statistics are really bad, 95% are altered/missing messages. In this case the messages from the reader have problems too. What is different in this case? I kept the Chameleon right between the smartwatch and POS.

[ceres-c]

#220 (comment)

Sniffing NFC fields is always a finicky process since reader's field is MUCH stronger than card modulation, which means picking a threshold to discriminate noise from actual data is nontrivial. Have a look at the scope captures in this post for more insight (it's about the Proxmark but the concepts are the same) https://swende.se/blog/PM3-development.html