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.
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
I can encoded an NFC Sticker with a website that will open when I tap it with a mobile phone. For the application I want to use it for I need to be able to expire that link so the user can't just save the URL and use it again. Basically I need to be able to put a random string in the URL that changes each time it gets scanned, such as www.mywebsite.com/TCHQ23, www.mywebsite.com/LQ8FT, ect.
Is this possible with a regular NFC sticker? If not, what kind of device would I use to make this happen? I know there are Arduino modules that can do this, but is there a simpler method or a ready made product that can act as an NFC but have the URL changed by a computer via a USB cable?
Thanks
NFC tags (some) have a feature called "Mirroring". You can mirror the read counter value to the URL, which gets incremented every time you tap it to reader i.e. Every time read command is called, the counter increases by 1. Tags like NTAG 213, NTAG 215 etc have that feature.
Update:
If your requirement is to get a portion of URL to to return random data and on a cheaper tag or sticker then I would suggest considering NTAG 213 tag, which is cost friendly and also have Mirroring feature supported.
If your URL data is http://www.abc#xyz.com then once the counter Mirroring is enabled (read counter must be enabled first) it will look something like
http://www.abc#xyz.com?000001
The last 6 digit value gets increased by value 1,every time a read command is invoked. (000002, 000003, 000004 and so on)
you can refer this link for more info
So your card/device has to present when read a NDEF record with a link in it (A "Well Known Type 1 with a record type definition of type U, etc), this will cause most phones to open a browser automatically
Some details on the Record type needed at https://www.oreilly.com/library/view/beginning-nfc/9781449324094/ch04.html
Most cards have the ability to store some static data, some have as #Adarsh Rotte says have counters, random number generators, crypto, password protection, mirroring (backup) of data, other functions but non of these will help as these custom functions and are card specific and don't / cannot present the data to match the NFC NDEF specification.
There is one type of card that can do this called JavaCard as these can run fully programmable Java Apps. These can be programmed to respond to NFC read request with the right NDEF measure where the URL can be generated on the fly.
There is a github repo with an example Java App to run on these cards that shows how to respond with and NDEF message at https://github.com/OpenJavaCard/openjavacard-ndef.
Watch out for https://github.com/OpenJavaCard/openjavacard-ndef/issues/10 if trying to use this, the default magic AID number is not the right one for NDEF and should be configured at the time you install the App on the Card.
This app emulates the behaviour of an NFC Type 4 spec card.
You would also need to customise it to have the right NDEF payload data with the right generated URL ending.
There are examples of the Card make/model supported by this App listed on the the github pages some are dual interface cards but there are some without the chip contacts and only NFC interface.
Generating the URL ending could be challenging or easy depending on level of security/validation you need.
Starting from a Random String which would be easy to fake because it has no level of validation, to a obfuscated counter, to a public key type encrypted counter.
There are also other solutions to generating the NDEF data with the right URL that don't use a Card and usually require there own power to run.
Some options:-
An Android phone can do what is call Host Card Emulation (HCE) which is very like what the JavaCard is doing, it is pretending to be a NFC Type 4 Card and the response it sends if fully programmable and could be the right type of NDEF message as per the JavaCard.
There are some "Card Reader" Devices that can be attach to a PC/Raspberry Pie via USB can also do HCE like the Android phone. e.g. https://www.acs.com.hk/en/products/342/acr1252u-usb-nfc-reader-iii-nfc-forum-certified-reader/ - this is well documented in the datasheets on how to do.
There are some other "Card Reader" modules that can connect via I2C to Arduino that can do HCE as well. (Technically most Arduino PN532 Chip's which are used in a lot of USB readers as well can do HCE but it is a bit undocumented on how to do it - see section 4 of https://www.nxp.com/docs/en/user-guide/141520.pdf)
There are some other chips that can act as static data NFC devices the also have an I2C interface to write the static data but allow a "pass through" mode to the I2C interface, again these tend to be NFC Type 4 but do some of the HCE type work for you.
e.g. the M24SR04-Y https://www.st.com/resource/en/datasheet/m24sr04-g.pdf can do it
So technically possible with a variety of methods but all not that simple to implement BUT not "Sticker" type format of NFC devices tend to be very simple NFC device as the format restricts the complexity of the hardware contained in them.
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.
I have an industrial sensor which is connected to a Interface Module that provides information to the end user via telnet.
Telnet Configuration
Port: 10001
Data Format: Little-Endian
Data payload
Preamble - 32 bit
Article number - 32 bit
Serial number - 32 bit
Channels - 64 bit
Status - 32 bit
Frame number M / - 16 bit/ 16 bit
bytes per frame
Measuring value counter - 32 bit
Measuring value frame 1 - N * 32 bit
..
..
This should be available after the TCP headers (if I understand correctly) i.e. Payload.
I am trying to learn golang with more practical examples and I am thinking in the following direction:
Create a TCP server for listening to the sensor's Interface module IP and port number
Extract the payload and just print it out as seperate parameters like preamble, article number etc. as a beginners task
I have gone through some blog-posts about TCP server/client creations but they only address string in their payload. How can I extract such a byte orientated custom payload as mentioned above?
P.S.
I can understand that this can be achieved in python probably via struct.pack and struct.unpack hence some correlation as understanding would be appreciated
In section 6.2 of your linked pdf document above there is a table listing the data you seem to list in the question
I would convert that table into a struct and then read into it with the encoding/binary module. See https://golang.org/pkg/encoding/binary/#example_Read for a relevant example
"All measuring values are transmitted as Int32, Uint32 or Float depending on the connected sensor" probably easiest to get them as uint32 and then convert them later
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.