MiFare | MiFare Classic support for UWP and Windows Desktop apps | Runtime Evironment library

You need to read the datasheet for the tag.

Section 8.5.7 and allows you with the AUTH0 field to set the first page at which the password is used from.

Thus the first part of the Tag can be readable and later pages can be read/write protected. As long as the tag is big enough to store Ndef message at the beginning of the Tag and your private data at the end of the Tag without using overlapping pages you can achieve free to read and password protected data.

You can also set the AUTHLIM to set the maximum number of negative password verification attempts so that it is not possible to brute force the password.

To configure these features you need to write to the appropriate memory pages using the low level NfcA transceive commands detailed in the datasheet.

The biggest problem you have with password protection is if you freely hand out an App that uses the password as it is trivial to reverse engineer the password from the JVM byte code that uses it.

You don't really need to know the different Tags are identified but having a good understanding of how the different levels of protocols and standards fit together is key, this is where this diagram from wikipedia is good.

You can use widget for get a value of variable of the constructor

Like this: widget.requestText

.forEach() doesn't wait for async callbacks (see this article), so your readBulk function is actually calling this.read() on all sectors at once, without waiting for cleanup. forEach is just running through and firing off callbacks for all of the elements in this.sectors.

To wait for each auth/read/cleanUp cycle before continuing, you can refactor it like so:

I'm not sure why you are looking at the Intent Action as it is of no significance to NFC really.

Some background of how Android handles NFC should help explain it.

In Android all Tag detection is handled by a System NFC service/App.

When you App is not running and a NFC Tag is detected the System Service works out if any App has requested to be started when that type of Tag is seen. It then crafts an Intent to get the System Launcher to launch the main Activity of you app and bundles information about the NFC data in the extras section of the Intent for the System Launcher to pass on in the Intent to your app at Launch time.

When you are doing requestTechnology your App is already running and you are telling the System NFC Service to pass the NFC data directly to your App, the System Launcher does not need to be involved as your App is already running.

Now Android has two methods of passing this data directly to your running App, enableForegroundDispatch or the later and much better enableReaderMode.

You configured react-native-nfc-manager to use the older enableForegroundDispatch which tells the system NFC service to send the Tag details directly to your running Activity. So it does not need to add an Action to tell the system Launcher what to do. But to deliver that Intent with the extras contain data about the Tag directly to your App, the only way for it to do that is to basically restart your App which causes a Pause and Resume.

But react-native-nfc-manager handles all this for you, so you should not need to worry about what is in the Intent

Note you can configure react-native-nfc-manager to use enableReaderMode and instead of overloading an Intent to deliver this data to you, if basically creates a Thread in your running App and gives the Thread the Tag data directly and thus does not need to pause and resume your App (plus you get more control of things like NFC detection sound with this newer method)

So overall the behaviour you are seeing is expected and normal and nothing you should be concerned about or have a problem with.

Note iOS handles this completely differently but again react-native-nfc-manager handles this via it's iOS specific methods.

There are two problems with this code.

1)You have created a "stream of bytes" of the ndef message but the SimpleMFRC522 package expects a Unicode String and encodes it to convert it to a "stream of bytes", so basically as it is already a "stream of bytes" it cannot be double encoded.

2)The Mifare S50 chip is a Mifare Classic family chip and these are a proprietary format and don't conform to the NFC Forum Standards and thus don't have a Standards defined way to store Ndef data on them (You need to do more than write a raw set of bytes to the memory to chip for it to be recognised as the data being the Ndef format of data).

For NFC standard compliant/compatible chips there are a number of defined types of how the Ndef data is stored on each type.

While NXP has defined a proprietary way to store Ndef data on a Mifare Classic chip, but the "SimpleMFRC522" is very simple indeed and does not have the code to write the Standard Ndef messages never mind the non standard proprietary methods.

I also note that while the iPhone hardware can read Mifare Classic cards at the low level, I'm not sure it has implemented the Ndef data format on top as well. I do know that some Android phones don't support the proprietary Mifare Classic Hardware at all.

I suggest you read https://www.nxp.com/docs/en/application-note/AN1305.pdf as this is the proprietary format definition on how to store NDEF data on these cards

Unfortunately the RC522 is very old and has limited capabilities and thus is not well supported by more capable Python NFC modules.

You might be better off with https://github.com/ondryaso/pi-rc522 as that at least allows you to write raw bytes.

If you want to convert this in to your text string, then you need to understand the NDEF data format as this looks like a dump of raw data from reading an NFC card with an Ndef record on it.

Not many libraries have a decoding method only encoding methods.

So the Key points are:-

typeNameFormat: 1 is the code for "Well known Ndef format"

type: [84] is the code for Ndef Text Record

This leads you to specification for the Ndef text Record https://github.com/haldean/ndef/blob/master/docs/NFCForum-TS-RTD_Text_1.0.pdf

Then

payload: [2, 101, 110, 123, 39, 99, 109, 100, 39, 58, 39, 110, 101, 119, 95, 102, 114, 105, 101, 110, 100, 39, 44, 39, 117, 115, 101, 114, 39, 58, 39, 116, 101, 115, 116, 39, 125]

the

2 is 2 bytes for language identifier length

101 is the decimal code for US ASCII char of e

110 is the decimal code for US ASCII char of n

So the text is in English

123 is the decimal code for US ASCII char of {

etc.

Should have said this is not JSON but a dump of a Javascript Object in Javascript

Turns out the access bit subsequently set by the supplier ff0780 means you need to authenticate the read_key (Key A) in order to write to the trailer block. Very counterintuitive, but works for Mifare 4K card where the access bit was previously set to ff0780:

After tinkering for a while, I am able to find the proper way to get the file size using below Kotlin snippet:

You need to send each block separately. The Mifare Classic Write command will only write one block at once.

See Section 12.3 of the Card's Data sheet

So RFTransmit the write command for the first 16 bytes to the first block and RFTransmit the write command for the second 16 bytes to the next block.