Develop Reference

Mi Band 2 past data

I'm writing my thesis on how to obtain data from different fitness bands.
At the moment I'm doing some research on the Mi Band 2 using bluetooth connection with my PC, unfortunately BLE is a new field for me.
By looking at projects like Gadgetbridge or miband2-python-test I try to understand the protocol. I get how the authentication works and how to extract data like battery or time information. However, I don't understand the protocol to obtain past data, like the minutely steps from two days ago until now.
I would be pleased if someone could help me by giving a tip or explaining the steps of the protocol. Thanks in advance!
That's my code for now, as far as I understood the protocol:
UUID_CHAR_ACTIVITY_DATA = "00000005-0000-3512-2118-0009af100700"
UUID_CHAR_FETCH = "00000004-0000-3512-2118-0009af100700"
CCCD_UUID = 0x2902
class MiBand2(Peripheral):
[...]
self.char_activity_data = self.getCharacteristics(uuid=UUID_CHAR_ACTIVITY_DATA)[0]
self.char_fetch = self.getCharacteristics(uuid=UUID_CHAR_FETCH)[0]
self.cccd_fetch = self.char_fetch.getDescriptors(forUUID=CCCD_UUID)[0]
def fetch_activity_data(self):
# \x01\x01 key?
# \xe2\x07 2018 year
# \x05 month
# \x03 year
# \x11 hour
# \x2f minute
# \x00\x08 timezone
value = b'\x01\x01\xe2\x07\x05\x03\x11\x2f\x00\x08'
self.cccd_fetch.write(b'\x01\x00', False)
self.char_fetch.write(value_from_wireshark, False)
for i in range(30):
self.waitForNotifications(1.0)
class AuthenticationDelegate(DefaultDelegate):
[...]
def handleNotification(self, hnd, data):
[...]
if hnd == self.device.char_fetch.getHandle():
if data[:3] == b'\x10\x01\x01':
self.device.char_activity_data.write(b'\x01\x00', False)
# After \x02 I receive \x10\x02\x01 instead of fitness data as I thought
self.device.char_fetch.write(b'\x02', False)

It is need to analyze btsnoop_hci.log
On every 30 minute the device send a notification value 0x0e from 00000010-0000-3512-2118-0009af100700. Then you must start to take your past data. Firstly you need to enable notification descriptors for UUID_CHAR_ACTIVITY_DATA and so called UUID_CHAR_FETCH. Then you need to get count of packages from your last successful getting of data. So you send a value 0x0101+datatime+tz to UUID_CHAR_FETCH. The device response to you with value of 0x100101+packages_count+1st_package_datetimetz if no gaps the 1st_package_datetimetz is that you send previously. Now you need to start transfer past data, just send one byte value 0x02 to UUID_CHAR_FETCH and device will send notifications from UUID_CHAR_ACTIVITY_DATA. Every activity data notification value has a queue number in first byte and maximum 4 packages of data in remain bytes. Every single package of past data consists of 4 bytes and has this format: activity_type,intensity,steps,heart_rate. The device stores data for every minute. So usualy on every 0x0e event you will get 30 packages in 8 notification message values by 4 packages most of time. After the last notification got the device will send notification of success 0x100201 from UUID_CHAR_FETCH. I don't know why but it need to be done the last 3-rd step: send a single byte 0x03 to UUID_CHAR_FETCH then get success response 0x100301. This actualy all what you need but Mi Fit does bouble check for a new data packages, then gets zero count and then does last 3-rd step. Now it need to set notification descriptors off with value 0x0000. After all this your success synchronize datatime will be grater for count of past data packets you got * 60 seconds.
If you have response packages count = 0 after 0x0101 command the device will obviously send to you nothing after command 0x02 and then send success 0x100201 :)
I don't know what for 0x0102+datatimetz is. It always response packages count = 0 in my btsnoop_hci.logs.
I think it is not necessary to synchronize by 0x0e event.
https://gist.github.com/Roxxor91/0d3ff17153270e447d01e7afd0c54e0f

Android nfcA.connect(), nfcA.transceive(), nfcA.setTimeout() and nfcA.getMaxTransceiveLength()

I have a a number of newbie NfcA questions. There seems to be little guidance on this in the docs and elsewhere on the web, so I hope no-one minds me stringing a few basic questions together here...
I am using nfcA.transceive() to write data to my NTAG213 tag like this:
byte[] result = nfcA.transceive(new byte[] {
(byte)0xA2, // WRITE
(byte)(pageNum & 0x0ff),
myData[0], myData[1], myData[2], myData[3]
});
1. The result array is a single byte of value 10. What does this mean and what other values should I look out for?
I am also using the same method to read data from my NTAG213 tags:
byte[] result = nfcA.transceive(new byte[] {
(byte)0x30, // READ
(byte)(pageNum & 0x0ff)
});
2. I expected this to return 4 bytes of user data (i.e., the 4 bytes that correspond to my pageNum), but it returned 16 bytes. Why is that the case?
3. Is it good practise to check nfcA.isConnected() before calling nfcA.connect() and, if so, is there likely to be any sigificant performance penalty in doing so? (I ask as I have seen code examples from reputable sources of both.)
4. Is it better to call nfcA.setTimeout() before or after nfcA.connect()?
5. For my NTAG213 tags nfcA.getMaxTransceiveLength() returns 253. Does that really mean I can write up to 251 bytes of user data (plus the 2 other bytes) in one go and, if so, is that advisable or is it better to write each page (4 bytes) with separate nfcA.transceive() calls?

1. The result array for a WRITE command is a single byte of value 10. What does this mean and what other values should I look out for?
The value 10 (Ah in hexadecimal or 1010b in binary representation) is an explicit ACK, an acknowledgement returned when a command that returns no data succeeds.
The possible values are actual data, ACK, passive ACK, or NACK. These are defined by the NFC Forum Digital Protocol specification and by the NFC Forum Type 2 Tag Operation specification.
If the command is expected to return actual data on success, the data is returned instead of an explicit ACK value.
ACK is defined as a 4-bit short frame (see NFC Forum Digital Protocol specification and ISO/IEC 14443-3 for further details) with the value 1010b (Ah).
A passive ACK is defined as the tag not sending a response at all within a certain timeout.
NACK is defined as a 4-bit short frame with the value 0x0xb (where x is either 0 or 1).
The NTAG213/215/216 product data sheet is a bit more specific on possible NACK values:
0000b (0h) indicates an invalid command argument.
0001b (1h) indicates a parity or CRC error.
0100b (4h) indicates an invalid authentication counter overflow.
0101b (5h) indicates an EEPROM write error.
In addition to the above, the NFC stack implementations on some devices do not properly propagate NACK responses to the app. Instead they either throw a TagLostException or return null. Similarly, you might(?) get a TagLostException indicating a passive ACK.
Thus, you would typically check the result of the transceive method for the following (unless you send a command that is expected to result in a passive ACK):
try {
response = nfca.transceive(command);
if (response == null) {
// either communication to the tag was lost or a NACK was received
} else if ((response.length == 1) && ((response[0] & 0x00A) != 0x00A)) {
// NACK response according to Digital Protocol/T2TOP
} else {
// success: response contains ACK or actual data
}
} catch (TagLostException e) {
// either communication to the tag was lost or a NACK was received
}
2. I expected the READ method to to return 4 bytes of user data (i.e. the 4 bytes that correspond to my pageNum), but it returned 16 bytes. Why is that the case?
The READ command is defined to return 4 blocks of data starting with the specified block number (in the NFC Forum Type 2 Tag Operation specification). Thus, if you send a READ command for block 4, you get the data of blocks 4, 5, 6, and 7.
3. Is it good practise to check nfcA.isConnected() before calling nfcA.connect() and, if so, is there likely to be any sigificant performance penalty in doing so?
If you receive the Tag handle directly from the NFC system service (through an NFC intent) the tag won't be connected. So unless you use the Tag handle before calling nfca.connect(), I don't see why you would want to call nfca.isConnected() before. However, calling that method before connecting has barely any performance overhead since calling isConnected() on a closed tag technology object will be handled by the famework API without calling into the NFC system service. Hence, it's not much more overhead than a simple if over a boolean member variable of the NfcA object.
4. Is it better to call nfcA.setTimeout() before or after nfcA.connect()?
I'm not sure about that one. However, the transceive timeout is typically reset on disconnecting the tag technology.
5. For my NTAG213 tags nfcA.getMaxTransceiveLength() returns 253. Does that really mean I can write up to 251 bytes of user data (plus the 2 other bytes) in one go and, if so, is that advisable or is it better to write each page (4 bytes) with separate nfcA.transceive() calls?
No, you can only write one block at a time. This is limited by the WRITE command of the NTAG213, which only supports one block as data input.
However, a transceive buffer size of 253 allows you to use the FAST_READ command to read multiple blocks (up to 62, so up to 45 for the NTAG213) at a time:
int firstBlockNum = 0;
int lastBlockNum = 42;
byte[] result = nfcA.transceive(new byte[] {
(byte)0x3A, // FAST_READ
(byte)(firstBlockNum & 0x0ff),
(byte)(lastBlockNum & 0x0ff),
});

What's meaning of range start=range end in http response

When I try to analyse CDN download, some logs looks like below:
GET http://1234.apk?track=mmmmmmm range:bytes-sent=[500-500], content-length:1500 ...
In my understanding, range:bytes-sent represents continue download after break and it should have different number in bytes-sent, the followings are reasonable:
bytes-sent=[500-600]
bytes-sent=[500-]
bytes-sent=[-500]
but what meaning of range start = range end like [500-500]? It seems no data should be downloaded but generates http response.
Thanks first~

The bytes mentioned in the range are also sent. Hence if the server wants to only send the 500th byte, the server would send [500-500] as the bytes range. Have a look at https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-p5-range-26 which has an example of how the first and last byte are sent :
o The first and last bytes only (bytes 0 and 9999):
bytes=0-0,-1

CDMA PDU parsing on Android

I have written a program to decode a CDMA 3GPP2 point-to-point SMS message. I tested it on a couple CDMA PDU hex strings I found on the internet, and it works perfectly. However, when I try to implement it on all incoming text messages on the Android platform, it always fails.
I took a look at the incoming PDU, and it doesn't seem to follow the same pattern I have been used to seeing. Can anyone explain what format this PDU is in, or what I am missing to correctly decode this PDU? Is there additional header or fields I am not taking into account?
Example PDU pulled from a incoming text message on my phone:
000000000000100200000000000000000A36373839313031363734000000000000000000001B000310864D000306120624205611010B104C2CF9F3F5EBD73E7000
All of the CDMA pdus I found and tested my parser on look more like:
00000210020207028CE95DCC65800601FC08150003168D3001061024183060800306101004044847
Carrier: Verizon
Phone: Samsung Galaxy S Fascinate running Android 2.3.3

See the javadoc from $SDK/sources/android-16/com/android/internal/telephony/cdma/SmsMessage:
/**
* Creates byte array (pseudo pdu) from SMS object.
* Note: Do not call this method more than once per object!
*/
...so it's not following any particular CDMA standard. You can decode it however; so in fine ASCII art:-
000000000000100200000000000000000A36373839313031363734000000000000000000001B000310864D000306120624205611010B104C2CF9F3F5EBD73E7000
--------messageType --digitMode --------bearerReply ------------------------------------------------------bearer data
--------teleService --ton --------------------src --replySeqNo --messageID --msts --userdata
--------serviceCategory --errorClass --len --XX--len --len
--numberMode --causeCode ------ ------------2012/06/24 20:56:11
--npi --------bearerDataLength ----------------------userdata
--len
Note that I think you made a cut/paste error in your message - the 00 byte marked 'XX' I think shouldn't be there - luckily it's easy to spot the date and work backwards. So this is a message from 6789101674 with userdata:
104C2CF9F3F5EBD73E7000, the first five bits of which show that it's 7-bit encoded (0x02). Having shifted the remainder of the userdata 5 bits to the left, we're left with:
09859f3e7ebd7ae7ce00
--len(septets) 9 septets == 63 bits, so we expect 8 bytes of body
----------------7bit-body
So your 7bit-body decoded is "Bggguuugg".

How can I determine the length of received bytes of UsbRequest.queue(..) method?

I have troubles with UsbRequest class in Android 3.1.
This is my code:
ByteBuffer buffer = ByteBuffer.allocate(4096);
buffer.order(ByteOrder.LITTLE_ENDIAN);
UsbRequest request = new UsbRequest();
request.initialize(mConnection, mEndpointIn);
request.queue(buffer, 4096);
if (mConnection.requestWait() == request) {
byte[] data = buffer.array();
}
The size of array data is 4096, but the length of really received bytes is much more smaller.
How can i determine the size of really received bytes?
Thanks.

This was a bug in Android. On afflicted versions, there's no workaround, because the implementation simply doesn't pass the length up.
It was fixed in JB-MR1 (API level 17 onwards).

It seems to me that the current asynchronous USB API has no way to return the read size. 2 "workarounds" use synchronous transfers as there you receive the number of bytes read/written or maybe the protocol you are implementing sends you the number of bytes you'll receive. E.g. i'm currently implementing something where every higher-level packet i receive has the number of bytes in the first 4 bytes of the packet. Based on this number i know if i have to do multiple reads.

You can use request.queue(buffer, bufferLength);. This should solve your problem. Now, you should refer android documentation, it's well documented and helpful.

I believe buffer.limit() should return the number of received bytes. Does that work?