MAC address

Every network interface carries a MAC address. The first three bytes form the Organisationally Unique Identifier, assigned by the IEEE to a specific company; the last three are that company’s own serial space. The registry is public and free to search, which means a MAC address is a claim about the hardware’s manufacturer that anybody can verify in seconds.

The two bits inside the first byte

Two flag bits live in the least significant positions of the first octet, and they are worth knowing because they turn a hex string into information.

• Bit 0 — unicast when 0, multicast when 1. A unicast interface address always has an even first octet.
• Bit 1 — the U/L bit: 0 means the address is globally unique and OUI-backed, 1 means it is locally administered, i.e. assigned by software rather than burned in.

The practical consequence: any locally administered address has 2, 6, A or E as the second hex character of its first octet. DA:A1:19:xx:xx:xx is software-assigned; 3C:5A:B4:xx:xx:xx claims a real OUI. That single character separates a randomised address from one purporting to come from a factory, and it is the first thing to look at when a MAC seems suspicious.

The OUIs that give away a virtual machine

Hypervisors do not invent addresses at random; they hold their own registered OUI blocks and hand out addresses inside them. That makes virtual adapters trivially identifiable:

• 08:00:27 and 0A:00:27 — VirtualBox, which is what Genymotion and several desktop emulators build on.
• 00:05:69, 00:0C:29, 00:1C:14 and 00:50:56 — VMware.
• 52:54:00 — QEMU and KVM, the basis of the Android SDK emulator.
• 00:15:5D — Microsoft Hyper-V.
• 00:16:3E — Xen.

A device whose build.prop claims a Samsung handset while its wifi interface carries 52:54:00 has contradicted itself in the space of one lookup. No retail phone has ever shipped with a QEMU OUI.

Randomisation, and why it is not a red flag

Modern Android randomises the MAC it broadcasts. Since Android 10 the behaviour is on by default and is per-SSID: the device generates one persistent random address per network it joins, so the same phone shows a different MAC on the home network than on the office one, while remaining recognisable to each. Android 12 added a non-persistent mode that re-randomises periodically. All of these set the locally administered bit, so they are visibly randomised — that is intended, and it is expected behaviour rather than evidence of anything.

What this changes for fingerprinting is who can see what. Since Android 6, WifiInfo.getMacAddress() and BluetoothAdapter.getAddress() return the constant 02:00:00:00:00:00 to every third-party app, and since Android 10 the underlying /sys/class/net/wlan0/address is no longer readable by apps either. So the MAC is no longer an app-side signal at all. It remains fully visible to the local network, to the router, to anyone on the same segment, and to whoever provisions the device — which is exactly the layer that matters when someone else operates your fleet.

Checking it

• adb shell ip link show wlan0 — the link/ether line holds the interface address.
• adb shell cat /sys/class/net/wlan0/address — same value, plainer output, may need root on Android 10 and later.
• adb shell settings get global wifi_connected_mac_randomization_enabled — whether per-network randomisation is active.
• adb shell cmd bluetooth-manager get-address on recent builds, for the separate Bluetooth interface address.
• Look up the first three bytes in the IEEE registry before assuming an address is fine.

The fleet mistake nobody expects

When operators do assign MACs across many devices, they usually pick one valid OUI and increment the last byte: AA:BB:CC:00:00:01 through AA:BB:CC:00:00:64. Every address passes an OUI lookup individually, and the set is a perfect arithmetic sequence — a stronger correlation signal than a shared address would have been, because it also reveals the size of the fleet and the order the devices were created in. Real hardware serials from one manufacturer cluster in a block but never march in sequence across a hundred units bought at different times.

A device also carries a separate Bluetooth MAC, usually adjacent to the wifi one in the same vendor block. Both should be distinct per device, both should be consistent with the brand the device claims, and neither should be a copy of a value seen on another unit — the same requirement that governs device isolation everywhere else in the stack.