Interpreting bluetooth string Pebble watch

Question

I am trying to determine the bluetooth string that is sent when programmatically unloading an app from the Pebble watch. I have unloaded an app (in slot 2) 5 times, and got 5 similar but slightly different strings:

First Payload:  0b ef 2b 00 11 17 70 02 24 b0 a1 e5 f0 b1 44 0d 8e 53 8f 26 68 8a 3f 07 9a
Second Payload: 0b ff 2b 01 00 11 17 70 02 24 b0 a1 e5 f0 b1 44 0d 8e 53 8f 26 68 8a 3f 07 86
Third Payload:  0b ff 2b 02 00 11 17 70 02 24 b0 a1 e5 f0 b1 44 0d 8e 53 8f 26 68 8a 3f 07 86
Fourth Payload: 0b ff 2b 02 00 11 17 70 02 24 b0 a1 e5 f0 b1 44 0d 8e 53 8f 26 68 8a 3f 07 86
Fifth Payload:  0b ff 2b 02 00 11 17 70 02 24 b0 a1 e5 f0 b1 44 0d 8e 53 8f 26 68 8a 3f 07 86

Interestingly, the last 3 payloads were identical, but the first 2 differ from this. The first string much more different (perhaps anomalous, I'm not sure), but the others only have differences in the 4th octet.

What would the best way to proceed with analysing this type of data? I've never done any reverse engineering like this before, but unfortunately Pebble does not provide an API for programmatically unloading apps.

It would appear that the first 3 octets specify the action to be taken (in this case unloading an app), but 3 octets would be a strange size for an instruction (not a power of 2), and so I'm suspicious that this is not correct.

My use case for this is I wish to devise a polymorphic app which maximises use of the memory capacity of the pebble (in this case I can fill the 100K slot completely).

Answer 1

Because you have 3 of 5 messages absolutely identical, and because the other two differ very little, it seems probable that the first two messages were simply captured incorrectly.

The way to try to detect that would be to do the same thing several more times to see if that pattern holds.

More generally, reverse engineering a protocol like this often starts by gathering as much data as you can. This includes:

1. US Federal Communications Commission (FCC) database type approval database entries often describe details of RF emissions
2. patent information frequently reveals details of proprietary message formats
3. applicable technical standards, such as Bluetooth in this case
4. product information available on the web
5. technical information that comes with the product
6. reverse engineering software that comes with the product
7. searching the internet to see if someone has already done the work for you
8. careful notes and associated capture files that you create
9. financial/news information available about the producing company. Sometimes there are public announcements of acquisitions of product lines or announcements of deals with third party developers which can help you discover other lines of inquiry.
10. sample code from chip vendors. For some consumer products, the device more or less a customization of code provided as sample or reference design information from a chip vendor.

All of these can and often do lead to useful information. In addition, studying other similar protocols may give you insight into the types of data that is likely to be in these packets and sometimes particular details of individual fields such as details of a CRC or checksum calculation.

Answer 2

You have captured the bluetooth RFCOMM frames. These include various control fields which are handled by the bluetooth stack and are transparent to the overlying application layer. (Think serial port like communication with start/stop/parity bits being added but just over bluetooth instead.)

In your frames:

• The 1st byte 0B is the address field.
• The 2nd byte EF or FF is the control field.
• The 3rd byte 2B is the payload length field (0x2B => 21 byte payload)
• If the control byte = FF, the 4th byte is related to credit based flow control.
• The final byte 9A or 86 is the frame checksum

Accordingly, the payload data starts at the 4th or 5th byte and finishes with the penultimate byte.

In your case, all 5 frames have the same 21 byte payload data which is what the application transmitted and the other end will receive.

00 11 17 70 02 24 b0 a1 e5 f0 b1 44 0d 8e 53 8f 26 68 8a 3f 07

Speculating now, every Pebble app has a unique 16 byte UUID hat I would expect to be part of an uninstall command. If we assume the UUID is the last 16 bytes of the packet we then have data as follows-

00 11 17 70 02 [uuid]

The 00 11 occurring at the start could plausibly be some form of (big-endian) length field (17 bytes). In which case, I'd guess the uuid combines with the preceding 02 to make up the 17 bytes. This would result in the following payload structure:

[length] 17 70 { 02, [uuid] }

If my speculation is correct this leaves only the combination of 17 70 and 02 to mean uninstall.

With more captures (uninstall of a different app or an app install) it should be possible to prove (or disprove!) this.