Reverse Engineering iBeacon and Eddystone Bluetooth GATT Services

For some of our beacons such the manufacturers haven’t documented their Bluetooth Service Characteristics. This means that while they are ok for scanning/proximity type applications, you can’t write your own app to, for example, change programmatically the UUID, major and minor, transmit power, advertising period and must rely on the manufacturer’s configuration app. While this of no consequence for the majority of uses that set and forget settings, more ambitious scenarios might want directly access the Bluetooth GATT services to change settings.

Uri Shaked has a great article on Medium on how to Reverse Engineer a Bluetooth Lightbulb. His method uses the developer logging in Android 4.4 and later to allow inspection of the Bluetooth packets and hence the Bluetooth Services and Characteristics that are being used. This method can equally be used with iBeacon and Eddystone beacons to reverse engineer the Bluetooth GATT information.

Another method is to use a Bluetooth sniffer. This listens in on the Bluetooth communication between two devices. One way of doing this is with Nordic Semiconductor’s Sniffer software on a dongle. There’s a tutorial on JimmyIoT.

It’s usually ill-advised to reverse engineer interfaces to discover undocumented features because the manufacturer can change the implementation thus breaking your solution. However, it’s very rare that firmware is ever updated in beacons and when it is, it’s usually only to fix bugs rather than change the implementation.

Should I Use the Manufacturer iBeacon SDKs?

Some manufacturers offer SDKs to allow programmatic access to their beacons from iOS and Android.

Most SDKs tend to be poorly implemented/documented, tie your code into using that particular beacon and rarely get updated to use newer mobile platform APIs. They also tend to be thin abstractions over the Android and iOS Bluetooth APIs.

If you rely on a beacon manufacturer that doesn’t update their SDK, it’s eventually the case that the underlying Android and/or iOS API changes such that your solution becomes non-optimal and, in the worse case, breaks.

Instead, when you can, we recommend you use the iOS and Android Bluetooth APIs directly to make your code independent of the beacon type. In this way you don’t end up depending on intermediate code and this has the benefit that you can more easily change beacon providers.

Alternatively, use an independent 3rd party library such as Radius Network’s iOS SDK or one of the many Android Bluetooth libraries.