iBeacons, Apple and Android: Is Google Hijacking Your Bluetooth LE?

Android Hijacks Your iBeacon?
Android Hijacks Your iBeacon?

Update (October 22, 2013): As noted in the comments below, Radius Networks has taken this question further, and answers with a, well, qualified “NO”, iOS will NOT let you find beacons that aren’t your own. Their conclusion?

  • There doesn’t seem to be any hack to look for an arbitrary iBeacon on iOS — you have to know at least the ProximityUUID to see one.
  • Using CoreBluetooth is pretty useless for working with iBeacons. You can see their advertisements, and measure the signal strength, but you can’t see any of the identifiers, and thus, you don’t even know for sure if any advertisement you see is an iBeacon at all, versus any other BluetoothLE device.

Their post however validates the original premise in this article: that you CAN “see” a beacon that isn’t your own, but the only thing you can see is a randomly generated UUID (not the same as the unique ID) and you can see the beacon’s signal strength. But the data is nearly worthless. Android, however, can SEE the unique non-changing identifier and its major and minor fields. (It’s not clear to me whether this is absolutely true in all cases – Bluetooth LE has three models for discovery and I’m not sure if it works for all three).

So what seems fairly clear that while Google lets you scan for devices that aren’t your own, iOS has obscured or locked off the ability to do so.

Update: It’s starting to look like the answer is YES. While still unclear, some back-and-forth with Joris Kluivers seems to indicate that you can’t ‘hack around’ Apple’s restrictions on accessing a beacon’s advertising packet.

So, Android can discover beacons that aren’t your own, while Apple restricts this ability. Having said that, the advertising packet contains very top-level data only, such as a beacon’s RSSI signal strength – it’s only when you ‘pair’ that you get access to the more useful data which lets you precisely determine proximity.

And so, my first sentence looks like it might be the correct one. But I look forward to comments or e-mails that can correct the record.

Google is making it easier to hijack customers in your competitor’s stores.

Or maybe Apple is making it difficult to take full advantage of the capabilities of Bluetooth LE.

It’s early days for iBeacons so the answer might lie in how you look at it, who you believe, or how deep you’re willing to dive into XCode to achieve the same thing.

But at the very least it seems that there’s a subtle difference in how Android and iOS recommend you “find” Bluetooth LE iBeacons. Apple recommends you only detect beacons whose identifiers you know, while Android has no such guideline. In other words, it seems like it’s a lot easier on Android to find someone else’s beacons and to therefore geo-locate someone.

This capacity was flagged in Radius Network’s recent launch of their iBeacon API for Android:

“The coolest thing about iBeacon Locate is that you can use it to see anybody’s iBeacons, even if you don’t know their UUID. (This is something that is currently not possible on iOS.) You can further track down an iBeacon that is nearby using the distance feature, which gives you an estimate of the distance to the iBeacon updated in real-time.”

Putting it in a retail context, the implication of this is that  if a customer walks into your store with your competitor’s app on their phone, nothing will happen if they’re using an iPhone configured using the iOS iBeacon API. But their app might wake up if they’re on Android and send them a quick coupon to head across the street.

But things aren’t as simple as Radius Network makes it seem: because although the Apple iBeacon framework requires that you indicate the UUID of the devices you’re looking for before it “unlocks” their data, it’s unclear whether those are recommendations or policies (that will boot your app from the app store by the friendly Apple team).

Throw in a wildcard string instead of a UUID and you might be finding the beacons in your competitor’s store across the street – something that Radius seems to be claiming is an ‘Android-only’ capability.

How iBeacons Work

For those of you who are like me and can’t quite understand what’s going on under the hood (but have heard that iBeacons are pretty cool) we’d better back up a bit.

The first thing to understand is that iBeacons aren’t the same thing as, say, WiFi or GPS. They’re small little transmitters that use a specification called Bluetooth Low Energy (a different thing from ‘standard’ Bluetooth). They consume very little power because they transmit very little data.

So regardless of the idea that iBeacons have ‘open data’ it’s not the same as someone hacking in to your passcode protected WiFi. There’s no “there there”…iBeacons aren’t transmitting passwords or credit card numbers or personal data – all they’re doing is acting as, well, beacons, and letting a phone know they’re in the area so that the phone can start to figure out exactly where it’s located.

In other words, in most iBeacon configurations your phone is a scanner and receiver, and the iBeacon is a transmitter – but the only thing it’s transmitting is the equivalent of an “I’m here” message and some data about what “I’m here” actually means.

When your phone is scanning, it ‘finds’ an iBeacon which is transmitting. It then receives a small packet of data called an advertising packet. This packet includes some data about the beacon so that your phone can figure out how to talk to it and learn more. Once your phone and the beacon have been “paired”, more detailed information is sent through another channel.

The trick here seems to be that the beacon transmits signal strength in its advertising packet by sending out RSSI data: a decibel level of signal strength. So even though at this point your phone doesn’t know all that much about the beacon, what it does know is that it’s there, it has a signal strength, and we can roughly guess how far away it is.

Apple’s iBeacon API Simplifies (and Locks) Certain Things

One of the often hidden stories of Apple’s launch of iOS 7 was its support for Bluetooth LE through its iBeacon API. Some have called it an NFC-killer. But Apple hasn’t made a lot of noise about iBeacon and there’s a corresponding scarcity of data in their developer materials other than ‘the usual’ API reference documents.

However, the Apple iBeacon API makes things relatively simple to set up your iOS device to discover and ‘talk’ to iBeacons. iBeacons can be other phones, they can be commercial devices like Estimote, or they can be devices that you put together yourself.

But Apple being Apple there’s some stuff that they make either intentionally obscure….or just forget to document.

One of those things is how it measures a beacon’s “region”. When your iOS device finds a beacon, it assigns it to being Immediate/Near or Far…but there’s a lack of specificity as to how that calculation is made, and you’re left to hack around a little to figure out what that means. You can append region data with RSSI data (which is finicky and unreliable) and Tx Power Service  to more finely calibrate location. My guess is that we’ll start seeing third party frameworks to do triangulation for multiple beacons (amongst other features) – and in the meantime you can geek out on a study or two and brush up on your math.

Like other things that are ‘under the hood’, Apple has locked up some of the methods you use to discover and pair with iBeacons. On iOS, your app needs to know the beacon’s unique identifier before Apple will give you access to the some of the data that the beacon is broadcasting.

And this, I think, is the heart of where the difference is supposed to be between Android and iOS:

“A beacon region looks for devices whose identifying information matches the information you provide. When that device comes in range, the region triggers the delivery of an appropriate notification.”

Because although the beacon is transmitting its advertising packets, it’s only Apple’s iOS that requires you to provide the identifying information of the beacon before it will trigger access to the packet data.

But Aren’t There iOS Hacks?

I’ve yet to meet a programmer who accepts the word “impossible”. But “extremely bloody difficult” is a far cry from “simple hack”. But the idea that it’s only with an Android device that you can discover iBeacons doesn’t seem true, although the claim that Radius is making might be more subtle than it seems.

Because it certainly seems technically feasible to access the same advertising packet data via iOS. Joris Kluvers notes that you can bypass the iBeacon API and use CoreBluetooth to achieve proximity detection to nearby beacons, achieving what I’d assume is much the same result as what Radius is claiming for Android. He demonstrated this in a talk last April, when iBeacon wasn’t even available yet:

But what’s unclear is whether there’s a policy component to Apple’s guidelines. Maybe your app won’t make it onto iTunes if you don’t specify the beacon UUID in your code. Or maybe Android ‘reveals’ more data than iOS will allow you to unlock. Or maybe Radius means something different than my decidedly non-techy take on things when they say “something that is currently not possible on iOS”.

So What Does It All Mean?
Radius is proposing that there’s something possible on Android that isn’t on iOS. But I’m not sure the claim holds up – because while it might be harder, it doesn’t seem like it’s impossible: just dig down a layer or two in iOS, add a wildcard string, and you can probably accomplish much the same thing.

But for the rest of us non-techy types, the true value of Bluetooth LE remains.

Its value isn’t in detecting that there’s a beacon around or knowing its RSSI signal strength. If you want rough geolocation or proximity data we can already do that.

Yes, you can get a rough approximation of where a beacon is and thus where a user is located. But it’s only once the beacon and the device are “paired” that the real fun begins: the ability to precisely locate someone at the cash or in front of the produce aisle in a grocery store.

GPS can theoretically let your competitors know that a customer is in your store if they’ve installed their app. iBeacons can generally start to locate them more precisely just by detecting that an iBeacon is there.

But the richer experiences that are available once beacons and mobile devices are paired still requires more than detection – it requires that your app and your beacon know how to give each other permission to have a deeper conversation.

And so while the ability to detect someone else’s beacons is possible regardless of platform, it doesn’t negate the value of the proximity capabilities of Bluetooth LE capable Android and iOS devices: to locate through Bluetooth LE beacons and then create an experience based on a precise sense of place.

Do you have some light you can shed on all this? Please do drop it in the comments below – because I know there’s a lot more knowledge out there than my own limited insight!

12 Responses to “iBeacons, Apple and Android: Is Google Hijacking Your Bluetooth LE?”

  1. Good discussion. Based on our research at Radius Networks, neither Apple’s CoreLocation APIs nor its CoreBluetooth APIs allow you to discover iBeacons with unknown identifiers.

        • As all the iBeacon-Data is sent in the Advertising Package there is no need for pairing in General. So there are no security Features included.

          I think the post is wrong in the part about the needed pairing to get the ranging information. All the calculation on the proximity of the Beacon is done by the framework on the smartphone with help of the signal strength and the calibration data of the beacon.
          iBeacons are just dumb transmitters of their advertising data (UUID, Major, Minor and measured power at 1m)

          • Thanks Jonas. I’m still confused. My understanding is that Bluetooth LE devices can have different profiles. What’s unclear (and I’m not a coder so bear with me) is whether UUID, Major, Minor, Tx Power and other data are requirements for the advertising packet or vendor specified.

            Looking at a review such as this one I’m struck by the variations of channels and possible profiles.

            So my question is: in theory, could I create a Bluetooth LE device and specify that I need pairing before I “release” the UUID, Major, Minor etc….or is that data always transmitted no matter how the manufacturer configured their device?

          • Since Apple has not released the official iBeacons specification yet we have to rely on reverse engineering:


            Here David (from RadiusNetworks) describes what the result of his reverse engineering was, namely all the data is send in the advertisement. This is where ‘normal’ BLE Devices tell the world what services they offer in order to get a pairing request. But the Bluetooth 4.0 Specification allows to send other data in there — that is what iBeacons do.

            To answer your question: Surely it would be possible to build such a device, but it wouldn’t be recognized as an iBeacon by iOS because it expects the data in the Advertisement.

            Maybe David can tell you more about all this, I am just getting into this topic too ;)

          • That’s my take: that what the advertising packet includes is device-dependent. But I’m not sure that Apple expects all of that in the advertising packet. They seem to require in their hardware specification a minimum, flags, local name and TX Power level.

            So I’d conclude from all of this that Bluetooth LE would have been a very narrow use case technology if the device makers couldn’t include a bunch of different ways to configure their devices. If you want to really geek out on those variations, see Volume 6 Part D of the Bluetooth Core Spec.

            It also offers four types of advertising PDUs, outlined in Volume 6 Part B of the Bluetooth Core Spec. Each of them seems to have a flag where the advertiser tells your phone whether its PDU address is public or random. This means that the advertising packet can be sending out a random PDU (or random address).

            Here’s the spec from Apple which implies that you can use a random or public address for the advertising packet:

            3.3 Advertising PDU
            The accessory should use one of the following advertising PDUs:
            ● ADV_IND
            ● ADV_NOCONN_IND
            ● ADV_SCAN_IND
            ADV_DIRECT_IND should not be used. See the Bluetooth 4.0 specification, Volume 6, Part B, Section 2.3.1.

            3.4 Advertising Data
            The advertising data sent by the accessory should contain at least the following information as described in
            the Bluetooth Core Specification Supplement, Part A:
            ● Flags
            ● TX Power Level
            ● Local Name
            ● Services

            So: Apple, in defining Bluetooth LE compatible hardware, seems to be following the Core Spec fairly closely with a few exceptions (e.g. ADV_DIRECT_IND – or connectable directed advertising events). The Core Spec gives options, including random and public addresses. Therefore it seems like it’s device dependent whether the address is random and private or public.

  2. Thanks David – and hat tip to you guys for drilling down and figuring it out. Joris confirmed as much. By the way…just installed your virtual beacon – what a thing of beauty!!!!

  3. gurdeep singh

    please send me the link to download beacon wifi hacker for my android phone.


Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>