What information is contained within the manufacturer block of a Mifare Classic? From what I can gather:
Bytes 0 through 4 contain the UID
Byte 5 contains the BCC for the UID
What about the rest of the data?
The data sheet provides no clue, and also does not distinguish between byte 5 and others (so these may be different in chips by other manufacturers).
I assume, that you mean a sort of checksum, but don't recognize the abbreviation BCC.
Related
I'm trying my hand at using iso 14443 cards. I can't find a way to read or write on them via android app. Anyone have any solutions?
For now I have downloaded android apps like NFC tools, but I'm not very smart in using them.
So as these are sort of like Type 2 NfcA Tags (though not fully Type 2 compliant) and have a datasheet of what commands they support and what their memory organisation is like.
So to read and write data to these Tags you need to transceive a byte array containing the right commands and then you will receive back another byte array with the results of the command.
So here is an example of how to transceive to NfcA on Android.
So your Tag does not support the Fast Read (0x3A) command used in this example but does support a more standard Read command
e.g. send the byte array
0x30,0x00 to read the first 4 blocks of data (16 bytes) from the Tag (see section 6.2.1 of the datasheet and note the CRC is calculated for you.)
A write command begins with 0xA2,0x05 with 4 more bytes of data to write to the first user data area memory block
Im trying read data from NFC tag using MFRC522. I can read ID, SAK, ATQA ,ATS, but im not understand how read blocks data from tag and file JSON.interested in a simple sequence of commands performing a given task.
I have NFC type 4A Mifare plus.Reading ID is performed using functions Anticollision and Select.
According to the Mifare Plus datasheet just Transceive as you would do a a Mifare Classic 1/4K whose datasheet Section 12 says Transceive 30h00h to read block 0
As you don't specify how you are connecting to the MFRC522 and with what language, but you can read the ID, etc you must be familiar in sending commands like Transceive to it and getting data back.
How a JSON file is stored in the blocks is specific to your implementation (though it could be a propriety encoding of NDef only you will know by looking at it)
I was recently using a Mifare Classic 1k smartcard. I used the manufacturer block (sector 0, block 0) to identify the card, since the UID of Mifare Classic cards is not really unique.
My application scenario is that I want to read an identifier from the smartcard and compare it to a database, in which every user has a smartcard assigned to them. So a user can log in with their card.
Now I have to use new Mifare DESFire EV1 4k cards. Do these cards also have something like the manufacturer block or just the 7-byte UID? Is it safe to use this UID to identify the card?
You can expect the 7-byte UID of genuine MIFARE DESFire EV1 cards to be unique. Be aware, though, that DESFire EV1 cards can be configured to use a random 4-byte UID. In that case, the UID is randomly generated for each RF activation. The 7-byte UID of such cards can only be obtained using the GetCardUID command (command code 0x51) after authentication.
However, you should be aware (in particular considering your use case) that the UID can easily be cloned and is not suitable to authenticate cards (or their users). See also
Serials on NFC Tags - truly unique? cloneable?
How do NFC tags prevent copying?
If you want something that is compareable to the manufacturer block of MIFARE Classic (i.e. something that reveals information about the product type and the production batch), MIFARE DESFire cards have a GetVersion command (command code 0x60).
Finally, note that the manufacturer block of a MIFARE Classic card does not really provide more uniqueness than the UID on its own. The reason for this is that the first 4 bytes of the manufacturer block are the UID itself. The next byte is the checksum over the UID (so its value is the same for cards with the same UID). The next 3 bytes are the SAK and ATQA values, which are typically '88' and '0400' for all (most?) MIFARE Classic 1K cards. The remaining bytes identify the chip type (hence identical for all cards of same type) and the production batch (hence identical for at least each batch).
I'm having trouble understanding how OSX formats BLE advertising packet data. In the screenshot below, kCBAdvDataServiceUUIDs in the locals window (on the left) has a certain format that I don't understand (for example, ...376A0). In the log window (on the right), they're printed in a recognizable format (for example, 180D). How is the translation done?
More importantly, I don't understand the kCBAdvSDataServiceData format <3a636401 01>. The service data in my peripheral has 1 byte for the length + 2 bytes for the service + 5 bytes of data. How can I translate the service data into something I understand? In my peripheral, the service data uses 0x180D.
Advertising Data is a list of AD structures.
An AD structure contains:
- length (1 byte) = total length of Type + Data
- AD Type (1 byte)
- AD Data (length-1 bytes)
AD Structures are concatenated to form the Advertising Data.
Same goes for Scan Response Data.
The AD Type is defined by the SIG and has many possible values. As far as I know, iOS/OSX only allows 3 types to be defined by the user: Local Name, Service UUID List, don't know the third one. But there are many more, check the complete list here: https://www.bluetooth.org/en-us/specification/assigned-numbers/generic-access-profile
The AD Data and length is specific to each AD Type.
I'm using the WML function "providelocalinfo" to put location information into Short Messages send via a WIB menu on a GSM handset.
I'm using the WIG WML v.4 Spec from SmartTrust. The relevant section is "9.4 providelocalinfo Element"
I use the code as in the example, and then transmit the variable via SMS, and use Kannel to retrieve the message from the SMSC.
Here's the code that I'm using, with the exception of [myservicecentre] being my actual service centre:
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE wml PUBLIC "-//SmartTrust//DTD WIG-WML 4.0//EN"
"http://www.smarttrust.com/DTD/WIG-WML4.0.dtd">
<wml wibletenc="UCS2">
<card id="s">
<p>
<providelocalinfo cmdqualifier="location" destvar="LOC"/>
<setvar name="X" value="loc=" class="binary"/>
<sendsm>
<destaddress value="367"/>
<userdata docudenc="hex-binary" dcs="245">
$(X)$(LOC)
</userdata>
<servicecentreaddress value="[myservicecentre]"/>
</sendsm>
</p>
</card>
</wml>
What I see in my received messages is "loc=" followed by 7 bytes (octets) or binary data. I have tried to find documentation explaining how to decode this data, but found nothing the explains this clearly.
Of the decoded 7 octets,
the first 3 octets are always the same,
The next 2 octets tend to vary between three unique values,
the last 2 octets appear to be the cellid.
So I have coded the receiver to pull the last two octets and construct a 16-bit GSM cellid. Most of the time it matches known cellids from the network. But quite often, the value does not match.
So I'm trying to find information on the following:
How to properly transmit the location information in a safe manner (encodings, casts, etc)
How to decode the information properly
How to configure Kannel to honor binary location data
I've examined the following documents in my vain searching, but not found the relevant data:
GSM 03.38, GSM 04.07, GSM 04.08, GSM 11.15, as well as the WIG WML Spec V .4
Any insight into what I might be doing wrong would be appreciated!
To decode the location info, you need to look in GSM 11.14 page 48
1.19 LOCATION INFORMATION
Byte(s) Description Length
1 Location Information tag 1
2 Length (X) of bytes following 1
3-5 Mobile Country & Network Codes (MCC & MNC) 3
6-7 Location Area Code (LAC) 2
8-9 Cell Identity Value (Cell ID) 2
The mobile country code (MCC), the mobile network code (MNC), the location area code (LAC) and the
cell ID are coded as in TS GSM 04.08 [8].
From personal experience, the first octet mentioned here is usually left off, so your first three unchanging bytes are the length and the country. The next 2 are the network operator code.
Not too many bites on this question! I wanted to summarize my findings in case others can find them useful:
Need to send messages with a dcs setting not equal to 0. dcs="0" sends data packed (honoring the lower 7-bits of each octet; this allows 160 character SMS messages when the max message size is actually 140 octets)
Need to parse the data in a binary safe manner: regex expressions that stop searching when 0x0A is encountered will fail when the binary data itself can be that value.
I found no need to change Kannel's default configuration.
Cheers
Disclaimer: Safe transmission of 16-bit GSM Cell-Ids requires dealing with a few settings that I understand only because they weren't configured by default. There are probably other defaults that I've depended on but am unaware that they can vary.