Debunking iOS app encryption: How extensive is it really?

For some time, there's been a widespread assumption that iOS security is virtually impenetrable. Through the closed-source nature of the operating system, app encryption, and tight sandboxes, developers often assume that their iOS-based apps are secure by design. 

Of course, anybody who knows anything about security will tell you there’s no such thing as 'impenetrable security'. In fact, we’ve been debunking this misconception for some time now. 

Unsurprisingly, Apple is reluctant to discuss their security policies and defenses in detail. This means misconceptions about their security approach often extend as far as developers and security professionals. And when it comes to mobile app encryption, it turns out the widespread assumption was even further off the mark than we thought. 

I have recently discovered that the encryption in an iOS app was much less extensive than expected. In short, this means your iOS apps are probably less secure than you think. Here’s what you need to know about the discovery: 

iOS app encryption basics

A big misconception is that iOS app encryption protects your application, and I’d say that’s not correct. It’s mainly there to prevent the arbitrary passing around of apps—it’s about protecting your business model, not the source code or business logic or your apps. It’s there to stop end users from downloading an app and then distributing pirated or cracked versions of it.

It’s commonly assumed that when iOS apps are published to the app store, the entire app is encrypted as part of Apple’s wider suite of built-in security tools. Here’s what the basic process involves:  

• Developers submit a signed .ipa with an unencrypted binary to Apple via Xcode

• Apple encrypts the main binary, packages it as an .ipa file to be uploaded to the App Store, and signs the app with an AppStore certificate

• When the app is installed on a user’s device, Apple uses a hardware-software-derived decryption key specific to that device to run the app

On the surface, it would seem that all iOS apps are encrypted by design whenever they’re uploaded to the Apple Store. But while there is certainly some level of encryption, Apple is generally pretty quiet on how extensive this is and what it involves. 

This means there are a lot of misconceptions around what this iOS mobile app encryption is and what it’s designed to achieve:

• First, developers often assume that the entire app is encrypted. This is simply not true, as we’ll explain in more detail below. 
• Second, developers also assume this encryption aids mobile app security, but this isn’t really the case. In reality, it’s more designed for copyright than security. 

So how far does iOS encryption really go? 

Debunking iOS decryption myths: What we learned

I took an old jailbroken iPhone that ran iOS 16 and analyzed a well-known streaming app. This is virtually the same process that a hacker would use to analyze/reverse engineer an app. The results were a shock to both me and the wider Promon security team. The truth is, iOS app encryption is a lot less extensive than we thought. 

Most people operate under the assumption that the entire main binary is encrypted from start to finish. But, at least on these older devices, that’s not necessarily true. In fact, only a couple of pages of memory were actually encrypted, which was about 16kb of this multi-megabyte binary file. There was no encryption in either the libraries or other files and very little of the binary itself was encrypted, it was just a series of headings and a few sections of code. 

In all likelihood, this is a deliberate feature to enhance the performance of apps. The process of decrypting code and converting it back to computer-readable binary takes time, meaning more encryption would likely slow down the app’s startup processes. 

Nonetheless, this still means the built-in protections in iOS apps are far less extensive than we thought.  

So why isn’t this common knowledge? The truth is, few developers are analyzing apps in this way, because they’re focused on creating apps and shipping them quickly to market, not security. This explains why the misconceptions around iOS security are so widespread. 

Of course, this only applies to the iOS 16 operating system that I used to analyze the app. More recent iOS versions may encrypt the entire text section of the main binary. But since many customers are still running apps on older devices, it still leaves open a key vulnerability.

Read more: Securing streaming apps: How app shielding protects your intellectual property

Why iOS mobile app encryption isn't enough

All this means that a hacker with a jailbroken device has access to much more of the source code and business logic than we originally thought was the case. 

Of course, this will differ depending on how the app itself is architected. If most of the business logic is in libraries rather than the binary, they’ll be able to access virtually all of it. 

But as we’ve discovered, even the whole binary isn’t encrypted—at least not on the iOS 16 device we tested. This creates several key risks: 

• Cracking/pirating: If end users can access most of the source code for the app, there’s a much bigger risk that they can create and distribute pirated versions. They might be able to infer the encrypted sections from context, or just delete them entirely if they’re non-critical features. 
• Repackaging/malware: In many ways, this is the same as the last point, because it also involves the hacker creating an unofficial version of the app to distribute. Here, however, the goal is to add malware into the source code to infect any devices that download it. 
• Reverse engineering: If most of the app’s code/logic is available to the hacker, this gives them ample opportunity to understand more about how that app works and identify weaknesses. This can include software vulnerabilities, authentication issues, as well as other information they need to plan a successful attack. 
• Loss of IP information: Code logic, algorithms, and proprietary techniques may also be uncovered. As well as the security implications, this also risks revealing business-critical features and strategies to competitors or malicious actors.
• Tampering: Hackers can also identify ways to inject malicious code into the application. This might alter the app’s behavior (e.g. removing restrictions), or lead to wider security issues like injecting malware, exfiltrating sensitive data, or redirecting users to phishing sites.

All of these threats stem from one fundamental issue: the hacker can access the app’s code, logic, or sensitive information using a jailbroken device. 

While jailbreaking is still fundamentally possible, this will always be an issue. And since there is no 100% effective method of detecting jailbroken devices, we need to turn to other solutions to help keep our apps safe. 

An effective approach to iOS app security

If there’s one thing you should take away from this article it’s this: You can’t rely on out-of-the-box Apple security to keep your apps safe from either security or copyright issues.

Luckily, there are other options. In fact, there are a range of tools that can help protect your code and business logic from both runtime and static analysis. These include runtime application self-protection and code obfuscation.