Como ler os blocos de uma tag ISO/IEC 15693?

Como uma requisição é montada

Uma requisição ISO/IEC 15693 é um byte de sinalizadores, um código de comando, depois parâmetros. A referência do NfcV pede ao código Android exatamente essas três partes e acrescenta o CRC sozinha. O Core NFC monta a requisição para cada comando da norma e recebe os sinalizadores como um conjunto de opções, NFCISO15693RequestFlag.

Quatro sinalizadores importam na leitura, com os valores que as definições da pilha NFC de código aberto do Android lhes dão:

Sem o sinalizador Address nem o Select, toda tag no campo que recebe a requisição a executa, o que é inofensivo com uma tag e ambíguo com duas. O Core NFC põe o sinalizador Address por padrão e envia o identificador da tag junto com o comando, e pôr o sinalizador Select desliga o endereçamento, segundo a referência do readSingleBlock.

A ordem dos bytes do identificador é onde o código escrito para uma plataforma quebra na outra. A Apple dá identifier na ordem big endian, então ele começa com 0xE0, o byte com que todo identificador ISO/IEC 15693 começa segundo as definições da pilha do Android. O código que monta à mão uma requisição endereçada, ou que compara identificadores lidos nas duas plataformas, confere em que ponta está o 0xE0 antes de usá-los.

Pergunte antes o tamanho à tag

Get System Information, 0x2B, devolve um byte de sinalizadores de informação, o identificador, depois campos opcionais, entre eles o tamanho da memória. Esse campo dá o número de blocos e o tamanho de bloco, ambos codificados como um a menos que o valor deles, o tamanho de bloco nos cinco bits mais baixos; a pilha do Android acrescenta um a cada antes de usá-los.

No iOS, getSystemInfo devolve os valores decodificados, e a partir do iOS 14 systemInfo(requestFlags:) os devolve como NFCISO15693SystemInfo, com blockSize e totalBlocks.

A resposta varia com o chip. A pilha do Android trata blocos de 4, 8, 16 e 32 bytes, e uma ICODE SLIX2 tem 80 blocos de quatro bytes, o último guardando um contador, segundo a ficha dela no wakdev.com. Alguns chips deixam o tamanho da memória de fora, e a pilha do Android recorre então a tamanhos que conhece para referências específicas, uma tabela que um aplicativo também teria de guardar.

Um bloco ou vários

Read Single Block, 0x20, recebe um número de bloco, de 0 a 255 na forma padrão, como declara a referência da Apple. Read Multiple Blocks, 0x23, recebe o primeiro bloco e uma contagem codificada como um a menos que o número de blocos, então 0x00 lê um bloco.

Uma tag com mais de 256 blocos precisa dos comandos estendidos, cujos números de bloco ocupam dois bytes: Extended Read Single Block é 0x30, da especificação da tag Tipo 5 do NFC Forum segundo a referência do extendedReadSingleBlock da Apple, e 0x33 lê vários.

Read Multiple Blocks é opcional. Numa tag formatada para NDEF, o bit 0 do quarto byte do contêiner de capacidade, no bloco 0, diz se a tag suporta o comando, e a pilha do Android lê esse bit antes de usá-lo. Sem ele, leia um bloco de cada vez.

Erros e comandos próprios

Uma tag que recusa uma requisição responde com o bit de erro, 0x01, posto nos sinalizadores de resposta dela, seguido de um código de erro: 0x03 para uma opção que a tag não suporta, 0x13 para um bloco que ela não conseguiu gravar, entre os códigos que a pilha do Android nomeia. O Core NFC informa uma resposta dessas como um erro cuja informação de usuário carrega NFCISO15693TagResponseErrorKey e o código da norma.

Os códigos de comando 0xA0 a 0xDF são comandos próprios, definidos por cada fabricante de chip. A referência do customCommand da Apple insere o código do fabricante depois do byte do comando, e os comandos em si, como os que gerenciam as senhas de um chip, vêm da ficha desse chip.