Chapter 4
Code Signing and Memory Protections
When iOS 2.0 was released in 2008, Apple began a program to tightly control the code that can execute on an iOS device. This is done through Mandatory Code Signing. An approved party must sign every application that is run on an iOS device. If the code is not signed, checks in the kernel will not allow it to execute on the device. All the applications that come on a factory device, or are installed from the App Store, are signed by Apple's private key. Additionally, enterprises, universities, and individual developers can specially provision their devices to allow signatures from other parties. But, Mandatory Code Signing doesn't just affect binaries. It affects all code, including libraries and even all executable code in memory. The one exception to this rule has to do with Just In Time compiling for the web browser, MobileSafari.
Code signing plays two important security-related roles in iOS. One is that it makes it difficult for malware to get on iOS devices. The only way to run code on an iOS device is to get it from the Apple App Store (unless the device has been specially provisioned). Because Apple reviews all apps in the App Store prior to posting, Apple can review each app to ensure it is not malicious. Compare this approach to the one taken by Android, where any self-signed application can run on an Android device. You can download and run arbitrary files, just like a PC. This makes malware a much more real threat on Android ...
Get iOS Hacker's Handbook now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.