libnfc icon indicating copy to clipboard operation
libnfc copied to clipboard

Documentation of NP_EASY_FRAMING and NP_HANDLE_CRC

Open JanBeh opened this issue 7 months ago • 3 comments

For accessing an NTAG215, I have been looking into utils/nfc-mfultralight.c.

For certain commands (but apparently not all commands), the nfc-mfultralight tool disables NP_EASY_FRAMING and NP_HANDLE_CRC (see source).

I would like to understand why.

Also, when disabling the CRC check, this seems to be done for the TX and RX part, see source for the PN53x chip. In nfc-mfultralight.c the CRC has to be manually added for the TX direction (see source). But where does a received CRC end up? Does it get checked at all? And by which hardware or software component?

Any help in understanding the process better (or improving documentation in this matter) is appreciated. 🙏

The existing documentation here is rather short:

If NP_EASY_FRAMING option is disabled the frames will sent and received in raw mode: PN53x will not handle input neither output data.

It does not explain why, for example, nfc-mfultralight uses NP_EASY_FRAMING and NP_HANDLE_CRC for read/write operations but not for auth operations.

JanBeh avatar Apr 08 '25 22:04 JanBeh

Digging into old commits...

https://github.com/nfc-tools/libnfc/commit/8de7ce38 added raw mode to support magic cards wakeup

https://github.com/nfc-tools/libnfc/commit/ca96e50e reused it for EV1 auth, but I don't think it's needed, as GET_VERSION and PWD_AUTH responses have a proper CRC. @AdamLaurie do you remember why you used the raw mode?

doegox avatar Apr 09 '25 11:04 doegox

hmmm... that commit from 8 years ago? let me think.... lol,nope!

I can only assume that the cards I had at the time were not responding as expected or some other issue, sorry.

AdamLaurie avatar Apr 09 '25 11:04 AdamLaurie

But where does a received CRC end up?

Regarding NP_HANDLE_CRC, the CRC seems to simply end up in the response (when authorizing, I get four instead of two bytes), but utils/nfc-mfultralight.c doesn't seem to verify the CRC (see source, where only two bytes are displayed). Maybe the missing CRC check could be considered a thing to fix in nfc-mfultralight.c?

Setting NP_HANDLE_CRC to false seems to be unnecessary (at least for authentication, and at least in my scenario).

But I did try leaving NP_EASY_FRAMING set to true, and this indeed causes problems with my NTAG215. When NP_EASY_FRAMING is true during authentication, I get this error message printed to stdout:

error   libnfc.driver.acr122_usb        Invalid RDR_to_PC_DataBlock frame

JanBeh avatar Apr 10 '25 08:04 JanBeh