Analyzing the official software

150 packets were captured Packets 1-62 are to establish a connection (were made as soon as the device connected).

Packets 63-142 are for data (were made after the "read device data" button was pressed).

Packet 63 seems to be a request for the meter's information, since 2 responses later the meter dumps its metadata in ASCII format. I also suspect that this request is being used as a heartbeat signal to keep the meter on, since on linux (which has no drivers for the meter) it turned off after a few seconds.

Here's its data:

1b 00                                                   # pseudoheader length
60 fa f6 8c 03 c0 ff ff                                 # IRP ID
00 00 00 00                                             # USB status (success)
09 00                                                   # URB Function (BULK_OR_INTERRUPT_TRANSFER)
00                                                      # Direction
01 00                                                   # URB Bus ID (1)
02 00                                                   # Device address (2)
01                                                      # Endpoint (Out, 1)
03                                                      # Transfer Type (BULK Out)
12 00 00 00                                             # Packet data length
e7 00 00 0e 00 0c 00 02 01 03 00 06 00 00 00 00 00 00   # Packet Data

Blood Glucose data was consistently found in packet 124 (62nd packet from the data request), starting at the 37th byte.

The data was split into packets each containing a maximum of 64 bytes of data + pseudoheader. Each reading took 12 byes, meaning a maximum of 5 readings could be put into a single packet.

The request for this data was found in packet 119, which is similar to 64, with the exception of a 20 (0x14) byte length and the following data: e7 00 00 10 00 0e 00 05 01 07 00 08 00 05 0c 1c 00 02 00 00.

Blood Glucose data was in the following format (HEX):

YY YY MM DD HH mm ss 00 RR RR 00 00 Example: 20 21 07 12 13 26 40 00 00 73 00 00

Y: Year M: month D: Day H: Hour m: Minute s: Second R: Reading/Result

Date-Time data was encoded as is (13 hours (1pm) was encoded as 0x13), while reading data was encoded properly (115mg/dl was encoded as 0x73).

The 00 between Date-Time and reading is assumed so based on the assumption that the reading is uint16, since blood glucose levels will never get above 65535.

The 2 00s at the end are assumed so because they consistently occur at the end of each reading, but never at the start of the first reading.

Data between the end of the readings (packet 128) and the end of the stream (packet 142) are not fully known, with messy data sent back and forth until a request similar to packet 119 is made in packet 131, this caused the meter to perform a data dump very similar to the blood glucose readings dump, but the format was different. Starting again at the 37th byte, the format was as follows:

YY YY MM DD HH mm ss 00 XX 80, XX was witnessed to be 00 in the first instance, and 0c in all subsequent instances. The times seem to match the testing times, which leads me to believe this is some form of a general log of what the device is doing at any time.

Writing software to interact with the meter

Starting off knees deep, I copied the request for meter data and sent it to the BULK_OUT endpoint, reading the BULK_IN endpoint showed that the meter ignored the data in the request and sent a response packet identical to the response to the first request after configuration is negotiated (an empty request). It seems like some sort of handshake has to occur before data can be requested. Which is obvious given that this communication was done with the driver (pre button press)