Bypassing regulatory locks, Faraday cages and upgrading your hearing

How we bypassed Apple's regulatory restrictions, built a Faraday cages and enabled georestricted features on the Airpods Pro 2 for our grandparents.

Update: We shared a bit more of the backstory on the Wired article here

---

Last week, right after Apple dropped the iOS 18.1 update, my dad and I set out to go buy a pair of AirPods Pro 2 for my grandma who is hard of hearing. Fifteen minutes after buying them, I found out that the device was for all intents and purposes useless, because Apple has region locked the Hearing Aids feature to the US and some other countries¹.

This kickstarted a few days of fiddling and learning how Apple typically implements region locked features, building a Faraday cage, and running a small camp to enable the hearing aids features for the grandparents of folks in our circle.

About hearing aids

Hearing aids typically cost anywhere from ₹ 50,000 to upwards of ₹ 8L depending on the correction capability. Apple advertises their hearing aids as being capable of recovering hearing upto 60dbHL particularly for frequencies in and around the vocal ranges. That’s quite incredible, and it actually makes them the budget option in a market that otherwise operates like a cartel.

Geo restrictions

If you own a pair of Airpods Pro 2s and head into your health app, and you’re in a supported location, you’ll probably see a screen that looks something like this:

Hearing Aid feature setup in iOS 18.1

This feature is, as far as we can tell, restricted to users who are residents of one of the countries in the list earlier, own a pair of Airpods Pro 2s, and are on at least iOS 18.1 and firmware 7B19 and greater² .

How does your device know where it is?

My initial digging showed me that there were at least three basic checks the iOS device would use to determine its location in the world.

• A GET request to the https://gspe1-ssl.ls.apple.com/pep/gcc endpoint, that returns a country code based on IP location. In our case, we wanted this to return US instead of IN, to get what we wanted.

• Apple store region, which we needed set to the USA.

• Device locale/timezone/language, although it’s not totally clear if this was needed in the end.

Additionally, we know that Apple uses several other techniques to determine location for GPS and mobile network enabled devices, including:

• GPS signal based location

• MCC/MNC based determination of location, where the device compares the received codes from the mobile network with an internal DB

In order to reduce scope, we tried our bypasses on an iPad 10th gen without telephony. Spoofing GPS and a network base station would not have been impractical given the faraday cage we would go on to build, but definitely a lot more labor.

After changing the locale and region in the iOS settings, I did the following:

• I proxied the device’s network traffic through my laptop and modified the response to the GET request for the geolocation endpoint, to make it look like it located in the US.

• I spoofed CoreLocation³ with Xcode’s simulated location feature

This didn’t work. There were certificate pinning issues, and the device would not connect to Apple’s servers for many apps and settings panes. It’s possible that the device needed to connect to Apple’s servers in order to enable features, but this was not tested completely.

At the same time, I had the device connected to my laptop, and was streaming the Console messages, where I saw this interesting line:

This was super confusing—the device was reporting that the feature should be enabled—but it was not. At this point, after spending a day on the problem, I called it a day. It was time to take a step back and think about the approach here.

What are we missing?

The day after, we regrouped at Lagrange Point to figure out what was going on. The obvious culprits were:

• Certificate pinning: This might mean that some system binaries weren’t able to download feature flag settings/critical data needed for them to activate the feature

• Was Xcode location simulation even working?

Going back to the logs from the iPad, we saw the following line:

This was very interesting, because it shows that the device knew that it was not located in the USA, despite spoofing IP location and locale.

We pulled the binaries for countryd and locationd, and went searching for these strings to see what we could find. Within locationd, we see the following class:

CLCountryTracker checks if CoreLocation is simulated, and seems to skip updating RegulatoryDomain if true.

On line 42, we see a boolean setting AllowSimulatedLocation, which has a default value of 0.

Additionally, there is a getter method called skipUpdatingRegulatoryDomain that returns the regulatory domain skip flag, which is presumably used in sendUpdateToRDIfAllowed to decide if it should update the RegulatoryDomain or not.

By this point, we could guess that ‘simulating’ CoreLocation with Xcode’s built in tools would not work⁴ . While the Hearing Aid features can be controlled via macOS, they must be enabled through an iOS device, so we had to teleport the iPad.

Geolocation

At this point, a friend explained that modern devices position you within cities by using a combination of WiFi SSIDs + MAC addresses of routers and devices around you as well as GPS to triangulate your location. This was also the reason that our WiFi only iPad was able to display an accurate location in apps even though it had neither GPS nor cellular.

There are a couple of open source WiFi location databases out there, we chose to sign up on Wigle, and pull some data that we could broadcast on an ESP32 and trick iOS into thinking that we were actually in Menlo Park, California.

In order to make this work, we forked and modified the awesome Skylift project. This works by making an ESP32 cycle through WiFi SSIDs in rapid sequence, essentially simulating the air from another part of the world. We also bumped the number of SSIDs to cycle up through to 100 from 10.

This however would not be sufficient—we have a lot of WiFi networks in the homes around Lagrange Point, and needed to either dampen or overpower their strength so that the device would not be report any other networks around. It was time to build a Faraday cage.

Faraday Cage and a Free Wifi Jammer

This was easily the most fun part of this exercise. To build our initial version of the cage, we lined and wrapped a cardboard box with Aluminium foil. Inside the box, we had an ESP32 broadcasting SSIDs from California at the iPad, and connected the iPad to a laptop for console logs and also internet access.

Since WiFi and a microwave operate at the same frequency (2.4GHz), we ran our leaky microwave at full power to block out any persistent network signals in the air.

We finally set up a script to reboot the iPad and turn on the network after 5 minutes inside the box. If all went well, the iPad would wake up in California!

A makeshift Faraday cage and a Wifi jammer in our kitchen

And exactly five minutes later, our iPad restarted, but unfortunately it was still in region IN.

After a few attempts of adjusting our Faraday cage, our jammer–microwave, and restarting the device, we finally saw this print into our Console:

We quickly pulled the device out of the box, flipped open a pair of Airpods and right away, were greeted with the Hearing Aid setup process!

Once we had a proof-of-concept, we decided we’re going to unlock this feature for everybody who could use it. There was more work to be done: we needed a reliable reproduction, and a concrete process.

Over the next few days, we iterated on both things. The core part of this effort was the construction of a more permanent faraday cage, pictured below.

We went overboard—the consensus at Lagrange Point was that a Faraday cage is simply a great thing to have, and we imagined many experiments we could do with it

Faraday cage v2, ready for more signal and radio experiments.

Mass unlocking

Enabling this feature in India for our grandparents was a really fun weekend hack, but we wanted to take things one step further.

We’re going to be running a small camp at Lagrange Point to unlock Airpods for anyone in Bengaluru who’d benefit from being able to use Airpods as hearing aids. We think everyone should have access to this tech—if you know anyone or would benefit from this personally, please reach out to us over at X, and we’ll make it happen!

Follow along for updates on the tweet thread: here!

Other notes

• It appears that the Hearing Aid feature is actually an equalizer preset that is pushed to the AirPods and will replace your transparency mode.

• Once the Hearing Aid feature is enabled, it syncs the feature flag to your iCloud account, making it available on all your devices without needing to deal with going through this process for all your devices

Credit and greetz

• Raghav Toshniwal, for explaining the device geolocation process and building

• Our grandparents for putting up with endless tests as we figured this stuff out

• Rithwik’s dad for purchasing the Airpods. Rithwik was told that if he didn’t figure out how to enable the feature, he’d just bought himself a pair of very expensive earphones x)

• Apoorva Verma, for helping build the Faraday Cage, and taking great pictures

Additional Details

Rithwik's thread on X

Arnav’s thread on X

1. Apple hearing aid availability, as of November 2024

2. This is not totally true, as we discovered, the Hearing Aid features seem to be available as a ‘equalizer’ profile for the transparency mode and if you ‘enable’ it on an iOS device >= 18.1, you can actually push the feature onto devices as old as firmware version 7A294.

3. Or thought I did. It turned out that locationd is set up to specifically ignore simulated locations, as we discovered later.

4. Another interesting angle that we could have explored was editing these binaries on macOS with SIP disabled to see if we could enable the features directly.