Security is a critical factor when developing iOS applications. The iOS security model is a monolithic one. When developers are expected to write code in accordance with best practices as defined by Apple, the situation presents both a boon and a potential pitfall for developers.

Why should businesses take the initiative to understand potential weaknesses in the security features of their planned mobile app products? Those that do are better equipped to prevent data hacks later on. It’s not just a matter of protecting a business’s private information, but that of all of customers as well.

iOS Security Strengths and Weaknesses

Working within the guidelines set by Apple makes it easier for a developer to deliver a finished product within a defined and “supposedly” reliable security model. Apps developed and made available according to Apple guidelines are on par with other Apple-endorsed iOS apps already on the market. Developers developing for iOS are more like clients to Apple since their apps must comply with Apple’s frameworks.

However, it is risky for developers to take for granted the fact that Apple’s frameworks and technologies provide absolute security as long as one complies with their usage suggestions. When these technologies are hacked, all iOS apps becomes vulnerable.

When that happens, developers can do little. In the future, they could obfuscate their code before compilation, a tactic used by Google. Code obfuscation is a process in which the text file that contains the source code is formatted so that it is unreadable: no whitespaces, and all meaningful names are swapped with random strings.

Jailbreaking Apple’s iOS Security Features

Apple’s iOS software is prone to jailbreaking, meaning Apple’s security features are surpassed to gain root privileges or system administration capabilities. One can run unsigned code on devices that are jailbroken. Jailbreaking is hacking, and it fuels Apple’s ongoing efforts to protect their software ecosystem.

Jailbreaking is a major headache for software architects at Apple. Whenever new jailbreak tactics are made available to the public, Apple must develop a patch to the jailbreak, in the form of a new version of iOS, within one to two weeks, if not sooner.

Apple has increased efforts to analyze and improve the security of its mobile operating system. Started in late 2016, the Apple Bug Bounty Program rewards those who identify and report weaknesses in iOS security. Invested in increasing the security of its software, Apple compensates those who identify major vulnerabilities in secure boot firmware components handsomely.

Apple is not alone in the quest for finding and securing people with these refined code-breaking capabilities. The company must compete to recruit these people against the very entities that try to hack software companies like Apple.

How Do .ipa Files Distribute Apps Securely in iOS?

Every application submitted to the Apple App Store is prepared for download in a confidential way known only to Apple. When a user downloads an application, a unique version of the app is encrypted for each device upon which the user chooses to install the app. The idea is to ensure that this app will not run on a device where it is not meant to be.

Apple applies a similar security approach to downloads of video and music from iTunes, where the name of the encryption system is called Apple FairPlay DRM.

When a user downloads an app from the App Store to a Mac, it can be located in the computer’s file system. Both hybrid and native apps are stored locally with an .ipa file extension (indicating they are iOS application archive files). This file is nothing more than a zip archive that contains meta files and a Payload folder where the app is stored in a very similar way to macOS apps (indicated with the .app extension).

Inside the .app directory all app resources like property lists (.plist), storyboards, images, sounds, scripts, etc. are stored. Besides resource files, there is one additional file in each application archive: the executable binary file.

This file is a large binary file with no explicit extension, and it conforms to the Mach-O executable file format. (This file will be referenced as Mach-O file or executable file). The Mach-O executables have very interesting structures and security mechanisms that differentiate native and hybrid apps in terms of security.

Mach-O Files and Native Apps

Generally speaking, Mach-O binaries can be divided into two groups: universal and for specific architecture. In iOS, both are used. The CPU architectures of iOS devices are armv6, armv7, armv7s, arm64. If you want to build an app that functions on both the newest and older iPhones, then the app must be compiled for different architectures, thus resulting in a universally executable file. Those multi-architecture binaries are also known as “fat binary” because they contain your code compiled several times for different architectures (“fattened”). We can think of universal binaries as collections of single architecture binaries.

Each single-architecture binary has three main parts:

1. Mach-O Header
2. Load Commands
3. Data

The first part contains meta information, encryption information and various offsets. The second part contains definitions of all functions inside its program and the third part contains the implementations of those functions, among other resources.

Mach-O files can be encrypted. That is the case with the executable files of App Store apps. This encryption can be decrypted (on a hardware level) only on the device for which this build of the app is intended. A few years ago Apple introduced additional security features to its executable files (ASLR). This feature makes it harder for an attacker to apply modifications to a program’s data on memory addresses of his choice by altering those addresses on each launch.

Mach-O Files and Hybrid Apps

For hybrid apps the same information applies, but their Mach-O files are not the point of interest, because hybrid apps contain some bounding logic stored in their Mach-O executable files. Their main logic is stored in human readable files, which are more interesting to hackers who want to reverse engineer the app. Since these human readable files are treated as resource files because they are scripts (xml, json, js), they do not receive the same security treatment from Apple as Mach-O files. So all of this security goes to securing the irrelevant bounding logic inside the hybrid app’s Mach-O executable, leaving the main application logic files prone to attack.

Security and Reverse Engineering Hybrid and Native Apps

Hybrid

When an .ipa file has been unarchived, we can find a significant part of the code in an uncompiled human-readable format. At its core, a hybrid app relies on programming languages that are interpreted rather than compiled. An example of such programming language is JavaScript. Creating a logic diagram of the app is a fairly easy task once you have access to these source files.

Native

The code for a native app is stored in the form of a binary executable file, which is further encrypted; its decryption is performed only when the executable file is loaded by the processor into the random access memory and the whole decryption process happens at the hardware level. That is why it is very hard to create offline decryption tools. The only way to decrypt encrypted binary data is on a jailbroken device with a few special tools installed.

The difficulties do not end even after successful decryption of the binary. This binary contains the application logic in machine code, which is not human-readable. Decompilers like IDA and Hopper can help by presenting the app logic in Assembler and give some basic information about method and class names. After extensive review, one can draw a diagram that illustrates application logic. This is a very hard task because reading the assembly code of complex software is exceedingly difficult.

Application Logic and Security

An .ipa file, once modified, becomes invalid for installation on iOS devices. That’s why such modifications on the app it contains are only possible on a jailbroken device, where the .ipa file is already unpacked. Once the app is installed on a jailbroken device, alteration of application logic is possible for hybrid and native apps with the help of various tools; however the process is simpler for hybrid apps because their human-readable code is easily accessible.

With a native app, such manipulations are possible on Assembly level and even Objective C, thanks to the flexibility of Objective C Runtime. While this flexibility works to the detriment of Apple’s security efforts, modifying native code is undoubtedly much harder than modifying hybrid code. Similarly, reverse engineering hybrid apps is easier, and therefore the confidential data they contain is at greater risk to hacking.

Here the success of the hacker’s efforts depends a lot on his understanding of the application logic and how well he can reverse engineer it.

Seek Security in Native Apps

In conclusion, hybrid and native apps are considered secure when executed on stock iOS devices. However, they are vulnerable to hacker attacks when they run on jailbroken devices. Elite level iOS hackers who develop their own method of jailbreaking devices are able to freely modify iOS apps and install other unauthorized software. They can more easily reverse engineer hybrid apps because their application logic is stored in human readable format.

Choosing to build a native over hybrid app alone isn’t enough to protect a business and its clients from hackers seeking sensitive information. Ensuring app security is an ongoing effort for developers of any mobile app and the businesses who must protect sensitive customer data.

 

Image Source: Dennis Cortés, Unsplash