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.

[skotopes]

@g3gg0 that was some serious journey, my congratulations.

[team-orangeBlue]

and it's merged. cool!

[g3gg0]

wow, great!!
thanks a lot to you and all contributors!

[eychei]

Hi everyone,

@g3gg0
I am trying to emulate a Slix2 tag with a different originality signature.

This is from the datasheet:

• Originality signature:
32 byte ECC based originality signature

It is set by NXP in production and can be changed for customers.

The Dymo label writers do have a different signature thus I can not emulate the tag.
This is a link to the forum post: https://www.eevblog.com/forum/reviews/dymo-550-thermal-printer-drm-hacking/

This is a dump of a tag with the originality signature (the signature is different for every UID it seems):

inventory: 0x01,0x5C,0x63,0x7B,0x3F,0x08,0x01,0x04,0xE0
sysInfo: 0x0F,0x5C,0x63,0x7B,0x3F,0x08,0x01,0x04,0xE0,0x01,0x3D,0x4F,0x03,0x01
signature: 0x6A,0x67,0x2D,0xAE,0x8D,0xFB,0xC7,0xC2,0x12,0x65,0x49,0x41,0x9B,0x3C,0x5F,0xAF,0xD7,0xC6,0xC0,0x97,0x33,0x43,0x99,0xE5,0xD0,0x5A,0xD9,0x71,0xFE,0x7B,0x74,0xA9
blocks:
0x03,0x0A,0x82,0xED,0x86,0x39,0x61,0xD2,0x03,0x14,0x1E,0x32,0xB6,0xCA,0x00,0x3C,0x62,0x64,0xCE,0x0F,0x33,0x30,0x32,0x35,0x36,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xFF,0x24,0x01,0x01,0x00,0x00,0x00,0x22,0x04,0x1E,0x00,0x23,0x00,0x00,0x00,0x00,0x00,0x10,0x00,0xF8,0x03,0x4B,0x02,0x00,0x00,0x00,0x00,0x6B,0x02,0x2C,0x01, 0x04,0x3E,0x1E,0x00,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xD7,0xFA,0x00,0x1C,0x63,0xF2,0x1B,0xE0,0x04,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xDD,0x4B,0x9D,0x05,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x32,0x8C,0x00,0x30,0x06,0xE2,0xDA,0x89, 0x00,0x00,0x00,0x00,0x6B,0x22,0xD6,0x76,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x11,0xF3,0x00,0x2C,0xDD,0xC3,0x3E,0x91,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xB6,0xFE,0x00,0x01

Hope you can help out.

-e

[g3gg0]

a) as I didnt check that stuff yet, I cannot tell anything.
b) i can add those extended SLIX2 features (statically) and supply some test releases
c) send me a tag and I can check if it behaves as the original.

Please note that the signature seems to be a ECC signature and emulating it (i.e. generating matching it to the emulated UID) is nearly impossible.
Asymmetric ciphers are designed to not be cracked by hobbyists btw :)

NXP AN11600 describes how to verify the signature, but it is restricted.
If anyone has it, feel free to mail iso15693g3gg0.de

[eychei]

Thanks.
It seems that if we just emulate the signature (memory) nothing needs to be computed.
The reader firmware will check if the signature is correct.
Where can I send you a tag to? Will do asap.

-e

[g3gg0]

ah, found this.

yes, that can be emulated easily i guess.

[eychei]

I think one little bit is also missing.

The read password needs to be set to increment the counter. It is set for each tag differently. I can sniff the password for one of my tags and we could test on that data.

-e

[g3gg0]

if the code accepts any password, wouldn't that work as well?

[g3gg0]

the code says so

[eychei]

The firmware needs the correct password. It is generated for each UID.
I do not have the generation scheme.
The firmware is locked and I can not read it out. The STM32F072 is in RDP Level 2.
I do have a chipwhisperer but can not get it down to Level 1 or 0.

It may be that the counter will not work but the firmware may ignore that.
We could have the generate random number command send out the same number every time and the set password command always return a 1 (OK).

OH!
You are right. This is not needed. Just return the signal as true (success).

[g3gg0]

can you start a feature request / issue for this?

[eychei]

Yes will do now.

-e

[eychei]

Added feature request here:

#2781 (comment)

[semaf]

@g3gg0

What is the point of "Can not save key file" after I try to save the read data (tonies)? Emulating is working. It still save it but get the error "Can not parse file".

Content of the .nfc file:

Filetype: Flipper NFC device
Version: 3
Nfc device type can be UID, Mifare Ultralight, Mifare Classic, FeliCa or ISO15693
Device type: ISO15693

I managed to read before with your fork that saved .nfc and .shd files but now the official firmware nor the rogue firmware is working. Not tested with your latest fork on github. Emulating on official firmware is not working but on Rogue firmware.

[skotopes]

@semaf do you have proxmark ? can you send us card dump ?

[g3gg0]

Unfortunately I don't have my flipper at the moment.
Back then, the code did unlock and save the. nfc file immediately.
Seems something has changed and the saving code doesn't work anymore. Thus you get the error I guess?

[semaf]

@semaf do you have proxmark ? can you send us card dump ?

Yes I do but will have time the next days..

[semaf]

Unfortunately I don't have my flipper at the moment.

Back then, the code did unlock and save the. nfc file immediately.

Seems something has changed and the saving code doesn't work anymore. Thus you get the error I guess?

The latest unleashed firmware version is working without any issue. Saving .nfc files.

[bitboxer]

Is there a reason this is no longer on the dev branch of Flipper? This PR #3050 removed it all?

[team-orangeBlue]

Well, yes.
The NFC refactor blew up all of NFC. It now works for itself and nothing else.
That means, the app will work, but

• nfc apdu is gone
• Outside implementations, like nested/NFC magic are gone
• other firmwares (lol) just didn't merge this and when one did (MH-HM) the dev said his compiler exploded

So uhhh... yeah. But we still have ISO15693!

[gornekich]

@bitboxer We are working on this functionality now. Will be ready soon

[g3gg0]

didn't follow the development since merge.
do you need support from my side?

[gornekich]

@g3gg0 thanks, I think I will do it by my self and once it's done I will ask you to test it