added ISO15693 (NfcV) reading, saving, emulating and revealing from privacy mode (unlock)

[g3gg0]

What's new

This PR is related to #1991 (without all its history), built on top of #2070 (candidate for merge) and from a new branch.

• Added NfcV through various layers
• Added NfcV memory and system info reading
• Added loading/saving/emulating
• Added unlocking NfcV type NXP SLIX-L (reveal from privacy mode)
• Usable for another module already in development by @nvx (picopass emulation)

This is a PR, being aware that:

• rfalNfcv* calls are being made from lib/ level
• Nfc code is undergoing a refactoring

Q: Might someone of the maintainers help touching some of the quesionable code sections, as i am still not very confident with the inner workings etc?

I consider the code being good enough for a PR process, few reworking will have to be done. I you disagree, please tell.

regards, g3gg0

[nemanjan00]

READ_MULTI_BLOCKS seems to be broken:

Flipper:

        384 |      59264 | Rdr |62  23  ff  ff  ff  ff  00  00  07  e0  00  05  aa  eb                   |  ok | READ_MULTI_BLOCK(0-5)
      63296 |     177984 | Tag |00  12  34  56  78  90  12  34  56  78  90  12  34  56  78  90  12  34   |     | 
            |            |     |56  78  90  12  34  56  78  04  84                                       |  ok | 

Real card:
        384 |      59264 | Rdr |62  23  ff  ff  ff  ff  00  00  07  e0  00  05  aa  eb                   |  ok | READ_MULTI_BLOCK(0-5)
      63552 |     202816 | Tag |00  00  12  34  56  78  00  90  12  34  56  00  78  90  12  34  00  56   |     | 
            |            |     |78  90  12  00  34  56  78  90  00  12  34  56  78  55  31               |  ok | 

[g3gg0]

thanks, didn't notice and will have a look at it.

[g3gg0]

this is in unadressed mode:

here in adressed mode:

here with 1oo256 mode:

why is the custom bit set in your request?

[nemanjan00]

Looks like you are missing block security status

[g3gg0]

from which datasheet are you citing?

[nemanjan00]

BS_ISO_IEC_15693-3-2009__A2-2015.pdf

[g3gg0]

ah okay i have a quite old standard revision. seems the block security status is requested when the custom flag is set (?)

need to find a latest datasheet. if someone knows where to find it -> git - at - g3gg0.de

[nemanjan00]

Guessing you will probably write it better, but, anyway...

diff --git a/lib/nfc/protocols/nfcv.c b/lib/nfc/protocols/nfcv.c
index cc7f4ad5..2ffdd0ea 100644
--- a/lib/nfc/protocols/nfcv.c
+++ b/lib/nfc/protocols/nfcv.c
@@ -537,6 +537,29 @@ void nfcv_emu_handle_packet(
             nfcv_emu_send(
                 tx_rx, nfcv_data, ctx->response_buffer, 1, ctx->response_flags, ctx->send_time);
         } else {
+            if(ctx->command == ISO15693_READ_MULTI_BLOCK) {
+                ctx->response_buffer[0] = ISO15693_NOERROR;
+
+                for(int current_block = 0; current_block < blocks; current_block++) {
+                    memcpy(
+                        &ctx->response_buffer[1 + (1 + nfcv_data->block_size) * current_block + 1],
+                        &nfcv_data->data[nfcv_data->block_size * (block + current_block)],
+                        nfcv_data->block_size);
+
+                        ctx->response_buffer[1 + (1 + nfcv_data->block_size) * current_block] = 0;
+                }
+
+                nfcv_emu_send(
+                    tx_rx,
+                    nfcv_data,
+                    ctx->response_buffer,
+                    1 + (nfcv_data->block_size + 1) * blocks,
+                    ctx->response_flags,
+                    ctx->send_time);
+
+                break;
+            }
+
             ctx->response_buffer[0] = ISO15693_NOERROR;
             memcpy(
                 &ctx->response_buffer[1],

[g3gg0]

thanks, when trying a real SLIX-L it looks like that:

so if the custom bit is set, it seems the card will send the security status. can you check the standard if this bit 6 (0x40) in the flags is set, the security status is prepended?

[nemanjan00]

Yes, according to spec, Block security status is optional and depends on Option_flag

Also I have sent you email with spec pdf

[nemanjan00]

Also, I assume TwoSubcarrier is not supported?

[g3gg0]

that is correct. this is not supported (yet). see nfcv_emu_alloc() line 284 here i allocate the waveforms for high and low data rate. subcarrier modulation would have to get added here.

[nemanjan00]

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: E0 07 00 00 FF FF FF FF
# Data Storage Format Identifier
DSFID: 00
# Application Family Identifier
AFI: 00
IC Reference: 01
# Number of memory blocks, usually 0 to 256
Block Count: 28
# Size of a single memory block, usually 4
Block Size: 04
Data Content: 12 34 56 78 90 12 34 56 78 90 12 34 56 78 90 12 34 56 78 90 12 34 56 78 90 12 34 56 78 90 12 34 56 78 90 12 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
# Subtype of this card (0 = ISO15693, 1 = SLIX, 2 = SLIX-S, 3 = SLIX-L, 4 = SLIX2)
Subtype: 00
# End of ISO15693 parameters

Just in case you need sample I used that made PM3 use that flag

[g3gg0]

first/third real SLIX-L, second/fourth flipper

[nemanjan00]

I use:

hf 15 rdmulti -* -b 0 --cnt 6

[g3gg0]

fixed that part, thanks a lot!

[nemanjan00]

Thank you!

[nemanjan00]

One of my readers causes Flipper to crash will NULL pointer when I open Log. I will be sniffing traffic tomorrow and sending more info

[g3gg0]

thanks. in the evening i will check where NULL dereference might have happened.

[g3gg0]

@nemanjan00 I pushed a few changes. maybe you can check if you still see crashes? thanks!

[g3gg0]

One of my readers causes Flipper to crash will NULL pointer when I open Log. I will be sniffing traffic tomorrow and sending more info

this issue is also fixed. that was the case if the only received commands were addresses and the log was opened.

[g3gg0]

ok, added a few more optional commands, just to make it more complete. not sure which systems use them, but now DSFID and AFI should be handled as the standard suggests.

[gornekich]

Hello @g3gg0 ! Thanks for your work on NFC-V support! Since this PR is based on #2070 , I convert this PR to draft until your previous PR is merged. However ,I am starting to test and review this PR now

[nvx]

Rebased onto latest version of #2070 (which in turn was rebased onto the latest dev branch). Once #2070 is merged this should be good to go as well.

[g3gg0]

@nvx you tell me when to issue this PR for review again?

[nvx]

@nvx you tell me when to issue this PR for review again?

Will do. I figure worth leaving it as draft until #2070 is merged, then a quick rebase if necessary and can submit for review then.

[g3gg0]

for those who have issues with the ISO15693 emulation, there is also some issue when reading with mobile phones using e.g. "NFC Tools". however from the looks @nvx and me are quite certain this feature sends the correct data, but the phone cannot detect the bits. could as well be the antenna or the NFC chips modulation rate causing issues.

[nvx]

Branch updated to latest dev and api symbols updated (both f7 and f18 targets). Functionality tested fine. Ready for merge or feedback :)

[nvx]

Branch updated to latest dev and api symbols updated (both f7 and f18 targets). Functionality tested fine. Ready for merge or feedback :)

[g3gg0]

here as reference a comparison of flipper' response (top) and an original SLIX-L (bottom) to an IDENTIFY request.

you see the reader's request last bits on the left side and the load modulation on the right side

zoomed in a bit, shows the modulation which initially looked very promising, but zooming into it, flipper's modulation is a bit more noisy. might come from the general RF noise emitted by flipper, not sure. thats nothing that can (reasonably) be influenced by these patches.

edit: to prevent misunderstandings: i don't think that causes any issues. it's just the signal is not 100% as clean as those from tags.