Short beacon analysis on the NHS iOS Tracking application

We recently helped the BBC with a piece on the new NHS COVID-19 tracking application.

Concerns were raised by some about the ability for the app to track interactions while it was running in the background. There had been some discussion that suggested two iOS devices running the app whilst backgrounded would not send Bluetooth beacons correctly, without a nearby Android device to ‘wake’ them up. That could render the tracking app ineffective at actually tracing potential infections.

We spent a couple of days investigating whether or not this was the case. Here’s how we did it.

First, we started by sniffing the BLE traffic, but because we’re techies our houses are full of BLE gadgets so the spectrum was quite busy! iOS also makes it harder to identify which traffic is related, owing to MAC address randomisation. This is great for privacy, but not so great when you’re trying to pin down a BLE beacon to a particular device!

Instead we took a different approach by directly instrumenting the methods which deal with tracking.  This post explains how we can do this.

Live analysis of applications has been made extremely easy by using the  Objection tool on jailbroken iPhones. The first step is to try and find some classes which we may want to investigate.

A good start is to look for the application name. We knew that a firm called ‘Sonar’ were involved in the app:

One interesting method is the Sonar.ConcreteBTLEListener method. So we hook that method to see what’s in that class:

We can watch all the methods within that class as follows:

This lets us see when methods are called but we are missing some of the details:

We are dealing with BTLE beacons so perhaps the RSSI method could shine some light on the frequency of communications? We can monitor these by using the following:

As we can see below we are starting to retrieve some information about the devices which are connected within the dumped arguments:

These details are printed out every time the method is called, so we set up a stop watch and use the split function to trigger on every logged beacon:

We found that, on the whole, beacons were picked up every 8 seconds, in certain instances the app alternated between 8 and 16 seconds intervals:

In some cases, after a period of time, the beaconing interval would increase to a little over a minute. This is probably a battery saving feature.

Taking devices in and out of range can be easily simulated by using a suitable Faraday cage (a microwave is handy if you don’t have one!)
As designed, the app beacons could be seen after removal from the cage.

We were also interested in monitoring how the beaconing performed when new and unknown devices were introduced, simulating a new ‘contact’.

With a fresh device that had not previously been in range of any of our test devices, we installed the app, backgrounded the application, turned off the screen and brought it within range of our test devices.

Initially our hooking of the methods returned an error until the fresh device came in range:

However as the device got closer we picked up its name:

Whilst far from exhaustive, tests did show that the beaconing process worked effectively between iOS devices, whether the app was backgrounded or not, whether the device screen was on or off.

So there you have it, a brief glimpse into hooking methods within an iOS app and monitoring the data that’s being handled.