At last year's WWDC conference, Apple announced iOS 18 along with macOS Sequoia. One of the newly introduced features sparked Jiska's and my interest: Using iPhone Mirroring, a locked iPhone would be controllable from a Mac in its proximity so you could access apps, notifications and so on.

I gave a talk about this feature at the 38th Chaos Communication Congress in December, but this blog post has another issue that I can now talk about as the responsible disclosure process with Apple has been completed. Take a look at the later chapters of this post if you are mainly interested in that.

What looks like a pretty useful feature to users at first glance is also exciting from the perspective of a security researcher. While the Apple ecosystem has always been known for how interconnected devices are, this new feature allows interacting with user data on a supposedly locked iPhone and even from a completely different device.

Wait, you're in the EU, right?

Before starting reverse engineering and security research, I wanted to see how this feature worked in practice to understand what I would be looking for and to how it is meant to be used.

What sounds like a pretty simple endeavor, was in fact not. As I work at HPI in Potsdam, thus in the European Union, the feature is not supposed to be available to me since Apple restricts access for EU citizens claiming that they would be impacted by the Digital Markets Act.

Thus, I needed to find a way around this restriction to get my iPhone to pair with my Mac.

What I didn't know at the time was that the first beta releases of iPhone Mirroring were less than stable, making it difficult to find out which part of about rebooting, changing configuration files on the Mac according to some blog posts and creating a US location Apple ID actually got it working. For now, it seems as though the United States Apple ID seems to do the trick as I have not had to modify anything on my Mac recently and the feature has been working relatively stable over the past months.

Playing Around

After I had gotten this feature to work, I played around a bit. Wanting to understand the limitations of the feature, I clicked through some apps and pretty soon noticed that access to the camera and microphone did not work. Though, at this time, only when I opened the FaceTime app, an error message actually showed up. In another beta release a few weeks later, the error message was finally displayed for all applications that tried to access these resources.

To this day, it is not entirely clear why Apple restricts this feature. Arguably, you don't need it for the use case of browsing around your phone while it is in your pocket, but that shouldn't be the reason to block it entirely. Instead I suspect that this might be a privacy feature.

Many will likely argue that there isn't anything to be protected here, as you need a Mac signed into the same Apple ID to even connect to an iPhone. But even Apple do not seem too certain about this working as they specify the notification during and after the connection on the iPhone to be such an important security feature that it is specified in their Platform Security Guide. This leads me to suspect that Apple expects at least some misuse of the feature where remote access is granted, but the iPhone user might in fact not expect or want this to happen. One such situation might be intimate partner abuse.

The camera blocking features were so important that it was accepted that users might run into weird behavior when using their devices due to the hastiness of the implementation. One such example is that when you take a picture while the camera is blocked, you get a completely green picture. App developers do not have any possibility to check whether they currently have access to the camera or it is blocked due to remote control as Apple does not provide a public API to check for the state of iPhone Mirroring. The same applies for the microphone: if you try to access it despite the restrictions, silence is all you get.

Shortcuts: An Incredibly Powerful Tool

Shortcuts are a relatively new feature in the iOS ecosystem. They allow users to automate certain tasks on their iPhone and other parts of the ecosystem. To me as a security researcher, they also presented a way to break out of the chains of the iPhone Mirroring restrictions as they continue running commands even after I disconnect from the iPhone.

And this already was my first mode of attack. Since the restrictions on camera and microphone only apply during Mirroring, if I was able to trigger a task during mirroring that would then run after I disconnected, I would be free to access the camera and microphone.

This allowed me to build two different shortcuts as a proof-of-concept. First, I created an audio recording that starts after a short delay and then runs for a specified amount of time. This recording would then be uploaded to the iCloud account but one could most likely also construct a setup where that file would be sent to an attacker directly. In the same way, a shortcut can also initiate a FaceTime call which even provided a live video and audio feed to an attacker.

I reported these findings to Apple in July of 2024. The report was originally closed as "expected behavior" four days after the initial report. In December, it was suddenly reopened and declared as addressed in January of 2025. The fix stops all shortcut executions when the iPhone disconnects preventing this exact attack vector.

How Does iPhone Mirroring Work?

Let's take a step back and look at how iPhone Mirroring works under the hood. While I have not fully reverse-engineered the protocols behind, there are a number of indicators that give a decent overview of the wireless technologies and security measures used and implemented.

First off, Apple seem to be using their proprietary Apple Wireless Direct Link (AWDL) protocol to establish connections and transfer control data such as keyboard and mouse input. Audio and video feeds are in turn transmitted over Apple's Low-Latency Wi-Fi (LLW). AWDL uses asymmetric cryptographic key pairs synced across the iCloud keychain so that devices can establish a local peer-to-peer connection and ensure their authenticity.

I experimented with swapping these AWDL keys across different Macs to see how they behave and found that these swaps did not change anything about iPhone Mirroring, which led me to believe that Apple had introduced an additional layer of authentication for this highly critical feature. I speculated that they likely used the secure enclave processors for this purpose as these are specified as a hardware requirement to use iPhone Mirroring. Recently, Apple confirmed this suspicion in their Platform Security Guide:

When the user enables iPhone Mirroring and enters their passcode on the iPhone, the current cryptographic identity for the Mac is recorded. The private key for this identity is protected in the Secure Enclave.

While this is mentioned in the section about the notification mirroring, this is very likely also used for remote control. Thus, they have introduced security measures that appear to protect against many software-based attacks on macOS, making the attack vector of compromising a Mac to then compromise an iPhone far more difficult.

Hiding Access

As I mentioned above, the notifications on the lock screen during remote control and the pill shown after the next unlock are such an essential part of iPhone Mirroring that Apple decided to specify them in their Platform Security Guide. Users who see such a notification that didn't expect a connection do, however, not only want to know that a Mac connected to their device but rather which device and when to be able to do something about this apparent compromise of their device. While not present in the first beta releases, the settings page for iPhone Mirroring now shows a list of paired Macs along with the time they last connected, giving users transparency over the use of the feature.

While I did not find a way to prevent the notifications from appearing, the connection history was a different story.

The main issue here lies in the fact that the iPhone Mirroring settings page can be accessed via iPhone Mirroring. This means that a remote user can remove Macs from the list of paired devices. Additionally, the settings page can only be accessed when at least one Mac is paired. This means that if an attacker removes all Macs including their own, the history page becomes inaccessible. Users clicking the Settings button in the notification just end up on the parent settings page that does not even have any reference to iPhone Mirroring at all.

I reported this issue to Apple in October 2024 but was told that this was in fact not a security issue at all. I disagree with this assessment as this issue prevents users from gaining transparency over how their device was controlled. Compromised users only see a notification that appears after a few seconds and cannot reconstruct in which way their iPhone was compromised.

What Else Changes When Using iPhone Mirroring?

Even the basic idea of remote-controlling a locked iPhone is pretty wild in itself. In their presentation at WWDC, Apple claimed that the iPhone would remain fully locked for an attacker holding it in their hand while the legitimate user accesses it from their Mac. But this is far from true in practice.

After all, users are able to access almost all features as though the device were unlocked via the remote connection. But still, the iPhone held in an attacker's hand is supposed to behave like a locked device.

This security guarantee is incredibly complicated to implement. There are a number of applications running on an iPhone that limit their features when the iPhone is locked but can still be accessed from the lock screen. These apps aware of the locking state of the iPhone include things like Siri and the camera. For example, the camera app does not allow accessing older photos and Siri requires authentication when accessing protected data such as messages. All of these applications must be aware of the current iPhone Mirroring state and act accordingly. Just one oversight here can lead to information exposure or even more.

Siri

And exactly such an issue was present in Siri in an initial beta releases of iOS 18. When giving the command to send an iMessage, Siri should prompt for biometric authentication when the iPhone is locked. If, however, the iPhone was connected via iPhone Mirroring, this was not the case. It just executed the query. Even worse, you could ask Siri to read out any recent messages from any user and the iPhone would just do so.

I reported this issue to Apple in July 2024, the issue was resolved with the final release of iOS 18 in September. However, the issue was marked as a duplicate report when it came to bug bounties and giving credit, so I was likely neither the only nor the first one to find this issue.

Stolen Device Protection

Stolen Device Protection (SDP) is Apple's response to a number of reports of thefts of iPhones where thieves had observed people entering their passcodes such that they were able to unlock the stolen devices. This allowed them to use Apple Pay or even apply for credit cards as well as changing the Apple ID password (I still do not entirely understand why this is meant to be possible in the first place).

With SDP enabled, such high security operations require the use of biometrics to authenticate. Additionally, you have to start a so-called Security Delay by presenting your biometric authentication, wait for an hour and then authenticate again to access some settings. Interestingly, SDP is only available on iPhones. iPads, which have the same ability to change the Apple ID password, do not have this feature.

There are some more aspects that change with the use of SDP, although these are not officially documented. People might, however, rely on the behavior they observe for their personal security and privacy. One such case is the new App locking option that was also introduced with iOS 18 that can lock apps with additional authentication measures. By default, you are requested to present biometrics but if that authentication fails, the iPhone falls back to prompting you for your passcode.

The wording in the dialog window shown when you lock an app is not entirely clear. While the description text clearly states "Touch ID or your passcode", all headers and buttons clearly only reference biometric authentication.

When using SDP, this behavior changes. When biometric authentication fails, you cannot open the app and there is no fallback. I argue that this aspect might lure people into thinking that biometrics are in fact the only way into apps protected this way. I see this "feature" being used by people who share their device passcode with a friend or partner but still want to keep some of their apps private using biometrics.

With iPhone Mirroring, another access path becomes possible. If someone already has access to a Mac signed into the same Apple ID (maybe because they are also sharing the password here), they can simply pair the iPhone to that Mac using the passcode they know. Then, when they access a locked app through the remote connection, they are only prompted for the Mac's password and don't require biometrics on the iPhone.

I reported this issue to Apple in August 2024. The report was closed the same day explaining that this was expected behavior as SDP and locked apps had nothing to do with each other.

Thank you for submitting your report! Stolen Device Protection and Locked Apps are separate components.

It is expected behavior for locked apps to use your Mac password instead when you authenticate the Mac for iPhone Mirroring. Stolen Device Protection ensures that your Apple ID account cannot be modified without biometric authentication when your device detects that it's in an unfamiliar location.

For more information on how Stolen Device Protection protects your Apple ID, please refer to https://support.apple.com/120340.

I disagree with this response because of the reasons I outlined here, but there was nothing for me to do to get this fixed. I have thus decided to publicly present these limitations and unexpected behaviors in my talk at 38C3 and in this blog post.

Wallet

While thinking about how network technologies could be used to attack an iPhone, I came across NFC. While NFC obviously is not exactly an easy to attack wireless technology – you need to be in very close proximity after all – it was one that seemingly hadn't been given any thought in the design of iPhone Mirroring.

Some experimentation showed that the NFC on a remote-controlled iPhone behaved exactly like when it is used in the normal unlocked state. You can scan and write tags, register shortcut automations to trigger when an NFC tag is presented and so on.

I thought about how this oversight might be turned into an attack vector. I remembered that passes for the Wallet apps on both Android and iOS support some NFC functionality. So, what would happen if I were to open an NFC pass in the Apple Wallet app? Well, an attacker can simply take the supposedly locked iPhone and hold it to an NFC reader and it will read the pass. Arguably, the case where someone opens an NFC pass on the wallet app on a remote iPhone is pretty rare, but I would still consider it a security vulnerability. Especially since the fix – disabling NFC – would be relatively unobtrusive. An additional attack vector one should always keep in mind when analyzing close-proximity communication is the possibility of using a relay (an NFC relay in this case) that is held up to the iPhone and where the other end can be held up to an NFC reader anywhere else as long as an internet connection can be made between the two components, thus greatly expanding the range.

I decided to report this issue to Apple in August of 2024. Two months later, in October, the Apple Product Security Team asked whether I was in fact able to exfiltrate data using that method. I had originally only demonstrated that I was able to read something from passes using a common NFC reader app for Android. This was due to the fact that the Value Added Services (VAS) NFC Passes communicate over an encrypted protocol which I did not want to reimplement just to prove this point. Luckily, I was able to find an open source implementation of such a reader app with which I proved that data could in fact be exfiltrated and sent a demo video to Apple a few days later.

In December, in preparation for my talk at 38C3 I asked whether I could expect that issue to be resolved until my presentation date. The response surprised me.

With the initial release of iOS 18, additional improvements were made to this area by prompting users for their iPhone's passcode in order to use Tap to Pay when in an iPhone Mirroring session.

This had nothing to do with what I reported in the first place apart from also mentioning Apple Wallet. I was surprised and restated my issue multiple times, but was ultimately told that they did not consider this issue problematic as attackers had to be in close proximity. In the review phase of this blog post, Apple informed me that my report had caused them to add additional protections to the tap to pay feature which was why they credited me in their release notes.

Summary

Apple's iPhone Mirroring was incredibly complex to get right in the first place. Apple used their expertise in designing secure systems to introduce a number of safeguards, including cryptographic measures and a User Experience that is meant to make misuse as difficult as possible.

Despite that, especially initial beta releases had critical bugs and even the final release version of the feature enables attack vectors that previously didn't exist.

The threat model used for the feature is not clearly defined. The fact that some of my issues were initially quickly closed and reopened months later lead me to believe that even inside of Apple, there seems to be a discussion about what the feature is meant to protect against.

For the future, I hope that Apple can specify more details about the threat model in their platform security guide. This would enable security researchers to know about what they are looking for, give users certainty about the security guarantees the feature gives them and also reduce the number of unwanted reports on Apple's side.