i write some data (NDEF) into Mifare Ultralight Tag. Then the tag is set to read only with Ndef.MakeReadOnly(). The Tag seems to be read only afterwards.
But reading the Tag content shows, that only pages (4-15, Lx bytes are set to 1) are locked, the three BLx Bytes are left 0. When i got it right, this means that Pages Locks could be altered again. Page 2, Bytes 2 = 11111000, Page 2 Byte 3 = 11111111 - (see http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf , page 12).
Is there a way to make the tag permanently write protected?
Thanks for your time.
To make the whole tag read only, you could get the tag again as a MifareUltralight instead of as a Ndef. Then you do
MifareUltralightTag.writePage(2,new byte[] {0x00, 0x00, 0xFF, 0xFF});
followed by
MifareUltralightTag.transceive(new byte[] {0x26});
to "activate the new locking configuration."
Related
I'm attempting to lock a Mifare Ultralight C tag. I want to set NDEF pages 0x04 to 0x27 to read-only. I think this can be achieved via Ndef.makeReadonly().
Additionally, I would like to set pages 0x29 to 0x2F to be password protected (for read and write) so they can only be accessed after authentication was successful. I'm struggling to understand which bytes need to set in lock bytes (page 0x28, bytes 0, 1) and if sectors 0x2A and 0x2B need to be set as well.
I'm attempting to set NDEF pages 0x04 to 0x27 to readonly. I think this can be achieved via Ndef.makeReadonly().
Not necessarily, Ndef.makeReadonly() might only set the read-only flag in the capability container (according to the NFC Forum Type 2 Tag Operation specification).
If you want to make sure to set the actual lock bits, you would connect the tag as NfcA or MifareUltralight tag technology and issue a write command for the lock bits instead.
NfcA nfcA = NfcA.get(tag);
nfcA.connect();
byte[] result1 = nfcA.transceive(new byte[] {
(byte)0xA2, /* CMD = WRITE */
(byte)0x02, /* PAGE = 2 */
(byte)0x00, (byte)0x00, (byte)0xFF, (byte)0xFF /* DATA = lock pages 3..15 */
});
byte[] result2 = nfcA.transceive(new byte[] {
(byte)0xA2, /* CMD = WRITE */
(byte)0x28, /* PAGE = 40 */
(byte)0x0F, (byte)0x00, (byte)0x00, (byte)0x00 /* DATA = lock pages 16..27 */
});
Also see Mifare Ultralight: lock specific pages for the coding of the lockbits.
I would like to set pages 0x29 to 0x2F to be password protected (for read and write) so they can only be accessed after authentication was successful.
Using the write command that I showed above, you would first write your authentication key into pages 44..47. You would then write AUTH1 (page 43) as all-zeros. Finally, you would write AUTH0 (page 42) as 0x29 0x00 0x00 0x00 to require authentication for pages 41 and up. Actually I would suggest to lock pages 40 and up so that nobody could set the lock bits for those pages. Alternatively, you could set the block locking bits (i.e. write 0x1F 0x0F 0x00 0x00 to page 40) so that the lock bits for the unlocked pages cannot be changed.
Is it possible to write data to specific blocks in memory on the NfcV (ISO 15693) tag? E.g. write data to block# 5 or any specific block#.
I am new to NFC technologies. I am creating an application to read/write NfcV (ISO 15693) tags. I have successfully create the reading portion but the problem is on writing portion. When I want to write some text data into the tag it start from block# 2 to onward and every time doing the same procedure. I have searched lot but I can't find any solution to write data to specific blocks.
The exact details depend on which ISO 15693 compatible chip is inside the tag. The ISO 15693-3 standard lists different write commands. Support for these are all optional, so your tag may support one or more of these or even use a proprietary command for writing data. I would recommend to look up the datasheet of the chip and/or acquire the ISO standard to find out what the right command is.
Once you know what the right command is, you can simply pass the bytes of the command in a byte array to the NfcV.transceive() method. (Usually the command bytes consist of a flag byte, followed by a write command byte, one or more block bytes and the data bytes to be written.)
Tried the following: Getting the "Tag was lost" Exception:
nfc.connect();
byte[] arrByt = new byte[7];
arrByt[0] = 0x40;
arrByt[1] = 0x21;
arrByt[2] = 0x06;
arrByt[3] = 0x00;
arrByt[4] = 0x00;
arrByt[5] = 0x00;
arrByt[6] = 0x00;
byte[] response = nfc.transceive(arrByt);
I guess the android framework does not handle the response from the ISO15693 tags very well. I have been playing with HF-I tags. Few commands work flawlessly and for few other commands the NFC stack throws TAG Lost exception.
I'm trying to authenticate any sector of a MIFARE classic card. I'm using a twinlinx mymax sticker (which makes almost any bluetooth device NFC enabled). It sends commands to a connected NFC tag. I've already made a connection and sent and recieved data with a Ultralight C tag, but so far I had no success on accessing a Mifare Classic. Here is my authentication code:
private boolean authenticate(int sector, byte[] key, boolean keyA) {
byte[] cmd = new byte[12];
// First byte is the command
if (keyA) {
cmd[0] = 0x60; // phHal_eMifareAuthentA
} else {
cmd[0] = 0x61; // phHal_eMifareAuthentB
}
// Second byte is block address
cmd[1] = (byte) 0x03;
// Next 6 bytes are the key
System.arraycopy(key, 0, cmd, 2, 6);
// Next 4 bytes is the UID
System.arraycopy(Answer, 3, cmd, 8,4);
byte[] test = null;
//this makes a connection to the NFC tag (and this works)
TR.ConnectToExternalCard(AUTH, (byte)0x00);
//checking if the tag is still connected
if (TR.isCardPresent() == true){
//sending command to authenticate
test = TR.SendCommandPropAndWaitResponse(cmd, (byte) 0x00);
}
try {
if (test != null) {
return true;
}
}
I'm using standard MIFARE Classic keys, the tags are fresh from the factory. The complete command (in bytes) which is sent to the tag is:
[0x60, 0x3, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xf3, 0xf4, 0xa9, 0xfb]
Any Ideas? The tag seems to be non-responsive... tried accessing other Classic tags but also had no success. Thanks!
It is hard to say what you are doing wrong using an SDK that is not publicly available. However, the API looks familiar enough, so I will give it a try anyway. I can think of a number of things you may try (in decreasing order of likeliness):
The UID bytes may be in the wrong order, so try reversing them.
Perhaps Answer does not only contain the UID, but other bytes, too (e.g. SAK), and you are copying the wrong bytes from it.
The MIFARE Classic tags you have may have a 7-byte UID and you are not using the correct 4 bytes from that.
May be TR.SendCommandPropAndWaitResponse() is the wrong method to use. Perhaps there is a dedicated method for MIFARE Classic.
The MyMax sticker may not support MIFARE Classic. I don't see explicit confirmation on their website that they do. However, indications are that their solution is based on NXP hardware, which always supports MIFARE Classic.
Could somebody provide an NFC-V tag reading example code?
Android Development Guide provides only the NFCDemo code that is for NDEF tag only. There are no resources for all the other kinds of tags. Thanks!
Reading block 0 demo working for an 15693 i-code sli
ByteArrayOutputStream out = new ByteArrayOutputStream();
out.write(new byte[] { (byte)0x20, (byte)0x20 }); //addressed mode, read single blocks,
out.write(nfcV_tag.getTag().getId()); //address
out.write(new byte[] { (byte)blockIndex }); //block 0
byte errorcode_and_block0[] = nfcV_tag.transceive(out.toByteArray());
//1st byte should be 0 if everything is ok. next 4 bytes are block 0
Well - With Android 2.3.4 you can use the ordinary NDEF format and use the usual android API to write to the tag just like any other ndef complient tag. NFC-V has been the major feature for Android 2.3.4 after all.
If you otherwise want to communicate with the NFC-V tag: It's nothing more then the ISO 15693 standard. You should be able to find the PDUs that this tag understands with a google-search and then you can roll your own implementation if you really want.
This one really has me banging my head. I'm sending alphanumeric data from an Android app, through the BluetoothChatService, to a serial bluetooth adaptor connected to the serial input of a radio transceiver.
Everything works fine except when I try to configure the radio on-the-fly with its AT-commands. The AT+++ (enter command mode) is received OK, but the problem comes with the extended-ascii characters in the next two commands: Changing the radio destination address (which is what I'm trying to do) requires CCh 10h (plus 3 hex radio address bytes), and exiting the command mode requires CCh ATO.
I know the radio can be configured OK because I've done it on an earlier prototype with the serial commands from PIC basic, and it also can be configured by entering the commands directly from hyperterm. Both these methods somehow convert that pesky CCh into a form the radio understands.
I've have tried just about everything an Android noob could possibly come up with to finagle the encoding such as:
private void command_address() {
byte[] addrArray = {(byte) 0xCC, 16, 36, 65, 21, 13};
CharSequence addrvalues = EncodingUtils.getString(addrArray, "UTF-8");
sendMessage((String) addrvalues);
}
but no matter what, I can't seem to get that high-order byte (CCh/204/-52) to behave as it should. All other (< 127) bytes, command or data, transmit with no problem. Any help here would be greatly appreciated.
-Dave
Welll ... turns out the BluetoothChat code re-creates the byte array with message.getBytes() before sending to the service. (after all, being chat code it would normally source only regular ascii strings) As others on this site have pointed out, getBytes() can create encoding issues in some cases. So, for purposes of sending these extended-ascii commands, I don't mess with strings and just send the byte array to the service with
private void sendCommand(byte[] cmd) {
mChatService.write(cmd);
}
The so-called command array is first initialized with placeholders for the hex radio address elements
byte[] addrArray = {(byte) 0xCC, 16, 0, 0, 0, 13};
and then filled in with the help of the conversion method
radioArray = HexStringToByteArray(radioAddr1);
which can be found here: HexStringToByteArray#stackoverflow