[idea] ISO15693 Magic Tag V3 Support / CLI Design Question

[0x6r1an0y]

Is your feature request related to a problem? Please describe.

I recently obtained a new ISO15693 magic tag variant that is not compatible with the current hf 15 csetuid implementation.

Unlike the currently supported Gen1 and Gen2 cards, this card exposes a temporary configuration mode.

Writing to blocks 0x10 and 0x11 immediately updates the card UID, and the UID can be changed repeatedly while the card remains in this state.

A separate vendor-specific finalize operation is then performed by writing magic values to blocks 0x14 and 0x15. After finalization, the card exits configuration mode and UID modification is no longer possible.

Additionally, blocks 0x14 and 0x15 appear to be safety-critical. Writing arbitrary values instead of the expected vendor-specific magic values may permanently render the card unusable (effectively bricking it).

Because of this, I am unsure how support for this card should fit into the existing CLI design.

Describe the solution you'd like
I'd like to add support for this new card type, but I would first like feedback on the preferred CLI design.

One possible workflow would be:

hf 15 csetuid -u <uid> --v3

which only writes the UID configuration data.

Then a separate command performs the irreversible finalize step:

hf 15 cfinalize -y

This would be similar to the existing Mifare Gen3 workflow:

hf mf gen3freeze -y

where the irreversible operation is intentionally separated and requires explicit confirmation.

Describe alternatives you've considered

An alternative would be:

hf 15 csetuid -u <uid> --v3

which automatically performs both:

write UID configuration
finalize card

However, this means a seemingly simple UID change command would permanently disable future UID modifications, which may be unexpected for users.

Another option would be:

hf 15 csetuid -u <uid> --v3 --finalize

but this still combines configuration and irreversible finalization into a single command.

Additional context

Current behavior observed from reverse engineering:

• Blocks 0x10 and 0x11 contain the UID shadow/configuration data.

• Writing vendor-specific values to blocks 0x14 and 0x15 finalizes the card.

• After finalize:

  • The configuration area is erased.
  • UID changes are no longer possible.
  • The card behaves like a normal ISO15693 tag.

• Before finalize:

  • UID can be modified repeatedly.

Before preparing a PR, I would like feedback on which CLI design would be preferred by the maintainers.

[iceman1001]

Depends on the commands and if we have a definite way of detecting this sort of magic tag. If we have we can let the command auto-detect it in order to keep the client simple.