I have been reading answers on stackoverflow for a while now and this is the first time I actually am required to ask a question:
I have a small sensing device (literally a black box) which is used during sporting activities and is tracking acceleration and GPS data (not necessarily with the same frequency, according to a patent from the vendor). After a session, one can connect the device to a smartphone and import the session data to view statistics.
Now I am trying to acquire the raw data to apply some own statistics onto it.
I know that the device connects to my phone via Bluetooth. So I activated the Bluetooth HCI snoop log following this tutorial:
http://www.fte.com/WebHelp/BPA600/Content/Documentation/WhitePapers/BPA600/Encryption/GettingAndroidLinkKey/RetrievingHCIlog.htm
I can then transfer the files by renaming them into .cap files on the PC and load them into wireshark. This is where it gets tricky:
I have found out, that the first connection is established via Bluetooth low energy. When the connection is established and the user has selected to download a session from the device via the app, the connection switches to a normal Bluetooth connection.
I know that the device contains a GPS and a 9-axis accelerometer including a Gyro.
Apparently the Bluetooth protocol to transfer data is the SPP protocol (https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles#Serial_Port_Profile_.28SPP.29), used to simulate a RS-232 connection.
I have attached a screenshot from wireshark showing a reassembled data packet. I do not know what it contains and the rendering from Wireshark does not make any sense to me. The frame content is displayed in the bottom most tab. The left is the raw HEX transmission, the right shows the rendered version. It neither looks like any GPS sentence (http://www.gpsinformation.org/dale/nmea.htm), nor like any accelerometer data:
The general setting is an encryption-less connection, but at some stage the host and controller try to switch to an encryption, but this never gets transmitted to the peripheral slave (as far as I can see). I am wondering how to make sense of this data, whether there is a way for me to find out whether an encryption is activated and if it is, is it logged and can I retrieve the key from this log?
Can anyone help me to figure out the data here or tell me where I can find some hints about whether it is encrypted or not?
Edit:
I have added a screenshot from the first SPP transmission packet. The packet in question and the payload are marked in black. It seems to contain some information about device and other configuration settings or initial values for the sensors at the beginning. I suspect the app and the device to have settled on a proprietary scrambling or encrypting, since there are readable values at the beginning, but not after that black box marked in the image. My suspicion is, that bluetooth encryption is not being used at all and I therefore stand no chance of decrypting the information at all? Can someone confirm or deny this suspicion?
where I can find some hints about whether it is encrypted or not?
What you see in Wireshark is the HCI interface (commands and events) between Host and Controller. Since encryption is done in the controller (see Bluetooth Core spec. Vol. 1 Part A Section 5.4.3), what you see is unencrypted data.
Can anyone help me to figure out the data here
It's hard to understand from your single screenshot. I suggest you take a look at the RFCOMM specification, Figure 6.1 in paricular:
In the Information field you should find your data.
Related
I am engineering two BLE devices, a central and peripheral. (Using a PSoC 4 BLE, not that it matters)
There will be a lot of these in a small space, maybe up to 8 within range, but hundreds of peripherals and tens of centrals all coming and going, with no particular rhyme or reason behind which one central/peripheral the user will want to pair at any given time.
I also have an unrelated technology that makes it very easy for the user to move a blob of data from the central to the peripheral of their choosing. I believe this will make pairing much easier in most but not all scenarios.
I figure the non-BLE blob would contain at least the central's mac address, and maybe a randomly generated pin or shared key. Because the blob can only go from the central to the peripheral, the receiving peripheral is really the only device that knows the addresses of the two devices that are supposed to connect.
However, as I understand it, peripherals can't make outgoing connections. I can't swap roles because I still need the BLE search to work the traditional way.
I can think of a lot of ways to get this done, but I'm very interested in hearing the opinion of someone who has worked with BLE long enough to know what might fit best (or if I'm wrong about some assumption).
Some constraints I'm working with:
The peripheral is battery powered.
The usual search and pair method must also still work.
My own half-baked ideas:
Make the peripheral able to be a central too, but then does that
introduce more nuances and complications?
Broadcast from the peripheral, "whoever has X mac address,
please connect to me"
Put a similar message in the advertising packet and increase advertising
rate.
Directed advertising similar to above?
You could let the "non-BLE blob" contain a static random address which the central generates. After the peripheral receives that, it starts advertising with that static random address. The central is also configured to initiate a connection to that particular static random address. Will this work?
I have been trying to set up two XBees to communicate since the last three days. X-CTU seems to be the perfect option to do so, however, it is a real menace when it comes to discovering XBees on serial ports.
I was able to detect one XBee by luck just once and the other one never showed up. I have even replaced both my XBees. I am trying to figure out the alternative, i.e. using a serial console to perform the operation. I haven't been able to receive an OK response from the device upon issuing +++.
Since I haven't had a good experience using a PC to communicate with ESP8266 devices earlier, I tried to figure out a workaround by using the second Serial port of an Arduino to send such configuration messages and read the response by printing it out on the default serial console.
It also appears that configuration messages can differ depending on the mode of the device. If it's in API mode, the frame has to be generated in a specific format (I use the X-CTU frame generator for this purpose).
Why am I not able to receive a response from the XBee upon issuing a +++?
The devices are Series 1 XBees and the exact part number is XB24-AWI-001. Any help is highly appreciated.
Have you considered the XBee being in API mode? Maybe should you consider to reflash the device in AT mode to start playing with it.
To test if it's in API mode, you can refer to the guide, chapter 9 for the API mode structure:
http://eewiki.net/download/attachments/24313921/XBee_ZB_User_Guide.pdf?version=1&modificationDate=1380318639117&api=v2
Basically, a datagram in API mode starts with ~, and it's built as follows:
[0x7E|length(2B)|Command(1B)|Payload(length-1B)|Checksum(1B)]
As 0x7E is ~ on the ASCII table, you should try typing a bogus datagram in a serial terminal session like:
~ <C-d> AAAA
N.B.: The <C-d> characters means Control-d under unix., which is the EOF character.
Obviously such a message isn't likely to work, and you will receive a reply asking you to send that datagram again. That's because the EOF character being ASCII code 4, it means that the length of the datagram will be 4 bytes. So then you send four bogus bytes, the checksum will be A, which is very likely to be right, and the receiver will assume the transmission has been corrupted. So the datagram will be asked again, meaning you will receive a datagram to do that query.
Though I can only advice you to consider running it only in API mode (more reliable and a better API, but you cannot play around with it and understand what's going on by tapping on the line with a logic analyzer… though giving enough time, you'll start to read API datagrams like it's English ☺).
I wrote a page with a few resources to check on how to reflash the XBees:
https://github.com/hackable-devices/polluxnzcity/wiki/Flash-zigbee
and here's other advices from another totally unrelated project:
https://github.com/andrewrapp/xbee-api#documentation
And I also wrote a lib (aimed at beaglebones but you can tweak it for your use) that handles API mode 2 with XBees:
https://github.com/hackable-devices/polluxnzcity/blob/master/PolluxGateway/include/xbee/xbee_communicator.h
https://github.com/guyzmo/polluxnzcity/blob/master/PolluxGateway/src/xbee/xbee_communicator.C
but I bet with a little google search you can find more widely used libraries than those ones, and even some aimed to be run on Arduinos (N.B.: that lib was originally written for Arduinos, and then adapted to run for Beaglebone, so reversing the operation shouldn't be hard).
Please feel free to slap me and send a link if this question has already been answered; I just couldn't find it. I did search though.
I've been trouble-shooting communication with a serial device. In looking over lots of documentation, I now understand what the settings for "baud rate," "data bits," "stop bit," and "parity" mean. But what I can't seem to understand is who (sender or receiver) determines these settings.
Say I have a serial device plugged into my computer. In my code, I open a connection to the serial port and specify something like 9600,8,E,1. When I specify these settings, do these get sent to the sending itself, so that it knows how to send the data to my receiver? Or is it more common for a sender to expect a receiver to comply with strict settings?
The issue I'm having is that I attempted to use "Even" parity, and that resulted in tons of irregular transfer errors. When I use "Odd" parity, however, those errors go away. There is also a USB to Serial adapter involved in my set up. There aren't any transfer errors with Even or Odd parity without the adapter in the middle. So I'm just having a hard time understanding whether the device itself doesn't support sending with Even parity, or whether the adapter is the thing causing trouble, etc.
Thanks.
When I specify these settings, do these get sent to the sending itself, so that it knows how to send the data to my receiver?
No.
To expand on the comment by Hans Passant, both sides of the serial port have to agree on the settings, otherwise they won't talk to each other. If they don't agree, you will get gibberish data on either side as the hardware will read the data at an incorrect time. The settings are normally documented in the manual for the device that you are attempting to communicate with. For example, to communicate with a Cisco router, you will generally use the following settings:
Bits per sec : 9600
Data bits : 8
Parity : none
Stop bits : 1
Flow control : none
When you setup the serial port on your side, you must use these same settings, there is no hardware-level handshake between the two devices that determines the speed that they will communicate at.
Sometimes, the format for the serial port settings may be given in a format like the following:
9600,8,N,1
Which is just shorthand for the above quote(9600 baud, 8 data bits, no parity, 1 stop bit)
In my experience, most devices default to 9600,8,N,1, the next common serial setting is 115200,8,N,1
Being somewhat of a newbie I was wondering if there is a way to hard-code something on a peripheral that would only allow a single unique central/master to connect.....?
i.e. / eg
I have the ‘simple chat’ Arduino app on a RedBearLab Blend-Micro (which is for all intensive purposes the same as a Arduino Uno with a BLE shield) and I only want one single / unique phone to BE ABLE TO connect with it and therefore work with it.
My understanding is that the GAP handles security features during a BLE connection.
Therefore, is there some way to ‘code’ the peripheral device in / below one of the following includes:
spi.h ?
boards.h ?
EEPROM.h ?
RBL_nRF8001.h (or similar) ?
Other?
Didn't quite get an answer from Restricting the BLE peripheral device to connect to only one Master
OR
Am I stuck with EVERYTHING connecting but coding the peripheral in some other way in a GATT profile (I think) to ONLY do something with a predefined unique central/master (how/where to code?).
Many thanks for thoughts in advance
Being somewhat of a newbie I was wondering if there is a way to hard-code something on a peripheral that would only allow a single unique central/master to connect.....?
Theres the "Advertising Filter Policy" as specified in the Bluetooth Core V4.0 specification. Its a Byte in the Advertising Parameters as specified in Section 7.8.5 LE Set Advertising Parameters Command.
For example the value 0x02 reads Allow Scan Request from Any, Allow Connect Request from White List Only.
Then theres section 7.8.16 LE Add Device To White List Command.
That said, if your device confirms to the Bluetooth 4.0 specification, it should support these HCI commands. However there might be functions that simplify these procedures, wrapping those HCI commands for easier use. Check the Documentation of your device for such methods.
Good Luck!
I was asked to answer this question via email. It's been almost a year since I quit working on BLE. So I only answer this question based on my memories.
Basically #dominik has it right.
If the device is freshly new, it should advertise normally (without setting the whitelist only bit), then any central device could connect and bond. Once it is bonded, you should save this bonded flag and the bonded master's bd_addr to EEPROM. If the next time the master is lost, you will advertise with that white-list-only flag set. If a new central tries to connect, you could verify if its address is the same as your master.
I don't have the BLE spec at hand and I kind of forgot a lot about BLE already. Probably the spec says somewhere that if a central sees a peripheral device is broadcasting with white-list-only flag set, it wouldn't try to connect if it doesn't recognize that peripheral device. This saves both some effort.
But a master could always initiate a connection to your peripheral device regardless the white-list-only flag. So checking if the connecting central device's address is the same as your previously bonded master is the last resort.
[Update]
I used CSR1010 chips. I remembered that the BLE stack actually allows me to insert a list of bd_addr to the white-list data structure maintained by the stack. Then, with the white-list-only flag set, the lower-level stack layer will help you filter devices that are not in that white-list without your knowing.
However, you can always filter bd_addrs from your application code.
My application can send and receive data independently on COM Port (9 pin). Now the scenario is that, the destination device while sending data can also request some data. Now, in that case my application while receiving the data from the device, would have to send the requested data as well. So the question is, is it possible conceptually to send some data while receiving data from the same COM port ?
Note: If this is not the right place to ask this question, please let me know which SO site is apt for this.
Sure it is. The RS232 is a full duplex interface, hence there are two independent channels for each direction.
But note that these two channels are different pins of course. You cant send and receive on the same pin with the RS232 (Although it is theoretically possible to transmit and receive data over a single line simultaneously - but not in this case).