[NFC] Protocol st25tb write data 0 at block when not initialized

[yashikada]

Describe the bug.

I'm developing a simple app for read tag ST25TB, after I started the poller with callback function where the NfcCommand is always Continue and no events are managed, start a write at block 0 with data 0x000000.
In that device block 0x0 is OTP so is irrecoverable unless you use a sequence of commands to reset the OTP area to the value 0xFFFFFFFF.

In file lib/nfc/protocols/st25tb/st25tb_poller.c function st25tb_poller_request_mode_handler should be check also the mode St25tbPollerModeWrite and don't assume it's Write if it's not Read.
In my test code the value of variable st25tb_event->data->mode_request.mode is 4, which means no mode, but everything that is not Read is automatically Write. So start a write which is never requested.

Reproduction

1. develope an example NFC app which use St25Poller
2. compile
3. run
4. put a tag ST25TB under FZ
5. verify if the block 0 is written to 0x000000, you can see also in log debug

Target

No response

Logs

84872 [D][Nfc] FWT Timeout
84883 [D][ST25TBPoller] Read_block(0) result: 00000000
84886 [D][ST25TBPoller] wrote 00000000 to block 0

Anything else?

No response

[skotopes]

@RebornedBrain FYI

[augustozanellato]

I don't feel like this is actually a bug, the only valid operations you can request from the poller are read or write, if you don't intend to do any of those you might as well just return NfcCommandStop and stop it.

Full disclosure: I'm the poller author

[yashikada]

you might as well just return NfcCommandStop and stop it.

now that I have developed the first nfc yes FZ app I know it too, but at the beginning I didn't know it and I was doing tests with the firmware release. After opening the issue I saw that furi_assert is only compiled as a firmware debug, even putting furi_check would be fine.
I opened the issue to prevent what happened to me from happening to others, if it wasn't an OTP area it wasn't a problem.

I don't feel like this is actually a bug, the only valid operations you can request from the poller are read or write

No, with furi_assert compiled only in firmware debug, with firmware release all operations are valid, the value 4 become write also if don't request write, this is the bug.
In my test app I never requested write but simple scan to see all generated events.

[augustozanellato]

the value 4 become write also if don't request write

You requested an undefined operation so that's on you, the furi_assert is there to save you on debug builds but is disabled on release builds due to performance issues.

[yashikada]

4 is the default value, I don't request nothing, the callback function return continue and print status.
So without assert, it's wrong to think if is not read is write.
For me that code is bad.

[augustozanellato]

There are only two valid values so it’s safe to assume that if it’s not one it’s the other.
The check for valid values is there, but as I said it’s only checked on debug builds.