Crash when reading a ISO15693 NFC dump that used to work in older versions.

[ffurano]

Hi, loading an NFC dump that used to work in previous versions now crashes the F0.

The Flipper reboots and then the screen shows this message:

flipper crashed but has been rebooted

malloc(0)

The CLI log of the crash seems to point to the zolotaya_korona_parser:

47663 [T][StorageApi] File 00005FF0 - 0000D69C open (/data/plugins/zolotaya_korona_parser.fal)
747708 [I][Elf] Total size of loaded sections: 2012
747711 [T][StorageApi] File 00005FF0 - 0000D69C closed
747714 [T][StorageApi] File/Dir 00005FF0 free
747716 [D][Fap] Library for NfcSupportedCardPlugin, API v. 1 loaded
747721 [T][StorageApi] Dir 000031C8 - 0000A5CC closed
747723 [T][StorageApi] File/Dir 000031C8 free
747726 [D][NfcSuppo ....... CRASH!...REBOOT!

Funnily enough, the log never prints the filename that it should have been opening.

I attach the file in question... zipped
nfc-crash-f0.zip

It's content is like follows:

$ cat nfc-crash-f0.nfc
Filetype: Flipper NFC device
Version: 3
# Nfc device type can be UID, Mifare Ultralight, Mifare Classic or ISO15693
Device type: ISO15693
# UID is common for all formats
UID: 5C 66 AA 95 32 C1 07 E0
# Data Storage Format Identifier
DSFID: 00
# Application Family Identifier
AFI: 00
IC Reference: 00
# Number of memory blocks, usually 0 to 256
Block Count: 0
# Size of a single memory block, usually 4
Block Size: 00
Data Content:
# First byte: DSFID (0x01) / AFI (0x02) / EAS (0x04) / PPL (0x08) lock info, others: block lock info
Security Status: 00
# Subtype of this card (0 = ISO15693, 1 = SLIX, 2 = SLIX-S, 3 = SLIX-L, 4 = SLIX2)
Subtype: 00
# End of ISO15693 parameters

Reproduction

Switch on
Load my .nfc file from the memory card
(system crash)

Anything else?

Also saving correctly decoded ISO15693 files leads to a crash, yet different. Will document in a different ticket

[Willy-JL]

Are you able to read that card and save it again?

[ffurano]

From a computer you mean? Yes.

[Willy-JL]

No, from flipper of course. Can you read the card on flipper again, save it, and does that work?

[ffurano]

No, it does not work. Just the act of loading it triggers the crash, as I wrote in the first message. This is 100% repeatable, I'd be curious to see if it has the same outcome also for others (you?). I had attached the incriminated file.
And I am sure that in some previous version of the FW it was working, I could load and save.

[Willy-JL]

I am not asking about opening this file. I am asking about reading the physical card again.

[ffurano]

I can list the content no probs if this is what you mean, and other files can be read ok (but they are not ISO15693)

[Willy-JL]

I am asking about in your flipper going to NFC > Read, and touching the physical card, NOT the file, the real card in your hand, against the back of the flipper. Does that work?

[ffurano]

NFC->Read always worked (but will give an error when saving an ISO15693 key)

This ticket is about NFC->Saved->nfc-crash-f0.nfc->crash

Does this answer your question?

[Willy-JL]

This ticket is about NFC->Saved->nfc-crash-f0.nfc->crash

which is expected since this contains no data?

[Willy-JL]

there are 0 blocks of 00 size...

please scan the tag in full and save it in full, then send that.

[ffurano]

A crash/reboot is definitely not the thing that one would expect for such a legitimate file content. The file is not empty, and at least contains an ID, and it could be loaded fine with the release of a few months ago. This is a new introduced bug.

I can't scan it in full and save it because there's another new bug that gives an error when saving it after being read OK. The outcome is that that kind of ISO15693 dongles can't be dealt with at all with recent releases

[Willy-JL]

@ffurano please try to scan and save again on latest dev branch, then send this new file. it crashes because this file itself doesnt have any data (you say it contains an ID, and yes this is called a UID, and it not what we consider "data" of the card), so it is trying to allocate a data buffer when there is actually no data. it is not clear if this is due to bad reads in the past, or if it is actually possible to have 0 blocks of size 0 on such cards. also send a screenshot of what the flipper screen shows when reading it please.

[Willy-JL]

ive got a rudimentary "fix", but as i said it is really weird that the card has 0 data blocks. i could understand the blocks being empty, but a card with no blocks is weird, hence why the code does not expect such a situation. also my rudimentary fix manages to load the file and save it again, but when emulating it gets picked up as 256 blocks of 32 bytes of data by another flipper, so again its weird. please give some more information on this card, because i find it really hard to believe it has 0 blocks.

[Willy-JL]

also maybe consider reaching out to OFW about this, its not related to any of our code as far as i can see.

[ffurano]

OK. That's the trash dongle of my father. It surely works, because he can use it. I can have it in my hands not earlier than a few weeks. If you think it's better, I'll open the same ticket somewhere else, just please give me a pointer

Thanks

[Willy-JL]

I suggest opening an issue for this at https://github.com/flippersevices/flipperzero-firmware

Also if you have any more info on this card/dongle it would be very welcome, both here and on official firmware issue if you open one as I suggested

[ffurano]

I finally had the guilty key in my hands again, and have to say that now it works with other firmwares, meaning that I can read it, write it to disk, and emulating. Don't know if the emu really does any good, but at least nothing crashes anymore.

Effectively, the data part is zero bytes, and the older code was not dealing correctly with it. Now it seems to be ok, someone must have done fixes upstream.

I do have the file saved, and will test with Momentum in the next days

[Willy-JL]

That's great to hear! When you test with momentum, make sure to use the dev builds, as the release is over a month old by now and probably won't have the fix in question