iPhone 7 Not Randomizing Mac Addresses For WiFi Probe Requests

Have a look at the below wifi traffic history for my daughter’s iPhone 7.

The data was generated via a packet sniffer running on my laptop looking for the mac address of my daughter’s phone.

What is the difference between the upper and the lower traffic pattern?

The upper pattern is from when the sniffer and the iPhone were on the same frequency. The different shades of green show different traffic volumes.

The lower pattern is with the sniffer on 5GHz and the iPhone on 2.4GHz. All the sniffer can pick up are probe requests (and some probe responses). The pattern is less solid because sometimes the iPhone seems to take a break from sending out probe requests for 10 or more minutes.

My point is, that the iPhone should not send out probe requests with unrandomized mac addresses on different channels at all. If those probe requests were randomized, I would not be able to monitor so easily.

‘So easily’ is the point here. I could still monitor all iPhones in the neighborhood by channel hopping while sniffing. Every time the sniffer happens to be on the same channel as a phone, it would pick up traffic, but the traffic volumes would become less telling because most of the time I would be on the ‘wrong’ channel.

Using channel hoppers is a pain. For one thing, you lose your internet connection if the wifi connection is all you have. On top of that, your overall system becomes less stable and tends to crash more often, so people are reluctant to use them.

Go Apple, fix this. It’s too easy now. I don’t need to know when all my neighbors with iPhones are home and when they are out. Oh, and I don’t like that everybody else can so easily monitor my wife, my daughter and me either. Randomize ALL probe requests. Also those you send out while connected to a network.Screen Shot 2017-03-21 at 15.23.25.png

Just in case you think Android is any better, I include a scan for my Samsung S7 running on Android 7.0.


You can clearly see when I switched the scanner to the same channel as the sniffer. The patchy pattern in the lower half means that my phone is also not randomizing mac addresses of probe requests. Samsung, you’ve got some work to do too.

I put Apple in the title because Apple appears more sensitive to issues of this nature and Samsung will follow their lead eventually.

The Astonishing Power of Probe Response Packets

Wi-Fi enabled devices like mobile phones and tablets send out probe request packets in regular intervals. These probe requests have received a lot of attention recently, because they can be used for all sorts of legitimate but also nefarious purposes.

Presence detection systems for example, can pick up probe requests and monitor mobile devices without the device owner’s cooperation.
Many are aware of this problem in principle (and know about the solution) but underestimate the reach of probe requests.
Screen Shot 2017-03-28 at 18.11.58.png
In the above secenario, the mobile device sends probe requests, but is still too far from the monitoring station to be picked up. So, the monitoring station is still unaware of the nearby presence of the mobile device.
So far, that’s all as expected. No surprise here.
When I analyzed data captures I made, I realized that in the real world, things are more complex. In the real world people have neighbors.
Let’s look at the above scenario again with a neighbor who is not monitoring traffic and who is not cooperating with the monitor, but who has a Wi-Fi router to provide internet access for the family.
The target device is still too far from the monitoring station, but look what happens.
Screen Shot 2017-03-28 at 18.19.06.png
Now the neighbor’s router picks up the probe request from the target device and responds with a probe response. The neighbor’s router is within reach of the monitoring station and so not only the target device but also the monitoring station can pick up the probe response. Bingo. The probe response contains the mac address of the target device as the destination address.

The monitoring station knows that the neighbor’s router only sends a probe response to the target device after it has picked up a probe request. Clearly, the target device must be within reach of the neighbor’s Wi-Fi router.

Now the monitoring system also knows the direction from which the target device is approaching, because it knows from which neighbor the probe response came. It also knows that it has not yet picked up a probe request, so the target device is within the neighbor’s reach, but outside the monitor’s reach. Not enough information for an exact location yet, but good data points.
If there is not only one neighbor but many, it’s easy to see how a monitoring system can cover an area considerably larger than what it could cover alone. I found that quite astonishing. Probe requests have gotten a lot of bad press in the last few years, but probe responses have to take some blame too. And neighbors of course.

How Common and How Reliable Are Randomized Mac Addresses

Aren’t mobile phones using mac randomization these days? When they send out probe requests, they are not doing it by broadcasting their real mac address, this globally unique identifier, or are they?

I have been asked that a few times recently. The below is a summary of how things look from my perspective.

I live in the suburbs of Bankok and I have 7 days worth of mac addresses in my database. The mac addresses were collected with the help of my laptop’s wi-fi adapter in monitor mode. No special antenna or other dedicated hardware, just some freely available software.

Our house is not too far from a street with light car traffic. Most of the mac addresses are probably from devices in passing cars.

So, after one week, this is what has been collected:

Screen Shot 2017-03-21 at 10.25.00.png

A little more than half of the mac addresses collected are randomized mac addresses.

I group them by looking at the second last bit of the first byte of the mac address. If it’s a ‘0’ I count the mac address as a hardware mac, if it is a ‘1’ I count it as a randomized mac address, which sounds better than ‘locally administered mac address‘ as they are referred to in IEEE documents.

Recent reports have shown that the randomization schemes applied by Android and Apple phones have significant weaknesses, but let’s assume these weaknesses will eventually be fixed and in a purely passive traffic monitoring exercise one can only collect properly randomized mac addresses.

What can still be learned from wifi packets with a randomized mac address?

The below is an example from my data set:

Screen Shot 2017-03-21 at 09.19.54.png

Well, we know for one that a device was observed. We also know for how long this device was communicating with the same randomized mac address. Then we know that the total traffic observed was 71,817 bytes.

Screen Shot 2017-03-21 at 09.29.50.png

Most Google devices use ‘daa119’ as the first half of randomized mac addresses. Google actually bought that address space for that purpose. Since the first half of the mac address above is different, we also know that it is most likely not one of a great many Android devices who use this.

In my data set of 5,896 randomized mac addresses 823 start with ‘daa119’.

The main thing one cannot know with perfectly implemented randomization, is when the same device stays around for longer or comes back after a while. Without randomization this looks like the below:

Screen Shot 2017-03-21 at 09.47.28.png

I don’t know what device this is, but I have a lot more information to find out. I see presence patterns. I also see that the device is an Apple device. If this specific device appears again sometime in the future, I will recognize it as the same device.

With a bigger effort it is currently possible to link multiple randomized mac addresses generated by the same device. According to the report referenced above it is even possible to extract the hardware mac in many cases, even with strictly passive monitoring.

If one would be willing to go active and actually send out reply packages to probe requests from devices with randomized mac addresses, the devices would reply readily with their real hardware mac – the globally unique identifier – and the hiding game is over.

I have not done that, but it could be done easily. So easily that it is not even a challenge for a hobbyist like me.

The conclusion for me is that yes, mac address randomization, if done correctly, reduces the information content of packets anybody can pull out of the air, but it cannot be relied upon, because it is still too easy to get the real hardware mac from any device.

This does not make it useless. I look at it like a bicycle lock. With the right tools any bicycle lock can be broken, but still, it feels safer to have one.

Weeping Angel And My Samsung TV

That an internet connected TV with a camera and a microphone can be used as a surveillance tool is not a surprise. Still, one wonders how often this actually happens. Is it done on an ad-hoc basis or is it done systematically and most of the time?

I happen to have a Samsung TV. It is always connected to the internet via Wi-Fi and only via Wi-Fi (no ethernet cable). And it is always connected to the power supply.


Weeping Angle only affects Samsung TVs from 2012 and 2013, but still, I started to wonder. Is my TV as chatty as my mobile phone, which communicates almost constantly, even when I am asleep?

The answer surprised me.

First a typical traffic pattern from my phone. The darker the green, the more Wi-Fi traffic in that 5-minute interval.

Screen Shot 2017-03-20 at 10.03.06.png

In the whole period from Saturday 15:00 to Sunday 18:00 there was not one 5-minute interval in which my Samsung S7 running Android 7.0 was quiet.

Now the traffic pattern of the Samsung TV:

Screen Shot 2017-03-20 at 09.17.54.png

Lots of traffic while watching, but zero Wi-Fi packets in the air when turned off. How nice of you Samsung. I am impressed.

This to me means that spyware might collect data at any time of the day via my TV, but it does not send it when the TV is off. At least when the TV is turned off, the CIA, or any other agent, cannot listen into my living room live via this TV.

The spyware could use the time the TV is on to also communicate what it has recorded earlier, hidden in the flood of legitimate traffic, but that’s it.

Wi-Fi is the TV’s only connection to the internet and there is zero Wi-Fi traffic coming from the TV during the time the TV is off. At least not in the 7-day period I checked.

Am I missing something?