In
contrast to OS X, the iPhone platform does not use an intermediate
compression format for applications such as DMG or StuffIt—and of
course, there is no concept of “Universal” binaries. Rather, they are
distributed directly as an application bundle. In this section we take a
closer look at the build and packaging characteristics of iPhone
applications, as well as code signing and distribution.
Build and Packaging
Applications are compiled via
Xcode similarly to OS X applications, using the GNU GCC compiler,
cross-compiled for the ARM processor of the iPhone device, as well as
for the local machine, to run in the emulator. Each application bundle
includes a unique application ID, a plist of entitlements and
preferences, a code signature, any required media assets or nib files,
and the executable itself.
As with an OS X application,
bundles must include an Info.plist, which specifies the majority of the
metadata about the application. Every Xcode-created project will include
an Info.plist under the Resources hierarchy. One or more preference
plists (Root.plist) can be included for application-specific
preferences.
Distribution: The Apple Store
Apple’s Application Store
was the first user experience that made acquiring mobile applications a
simple task. Apple exercises total control over the content of the
Application Store; all iPhone applications must be approved prior to
distribution, and
can be revoked at Apple’s discretion. The rules for forbidden
applications are something of a moving target, and therefore are
difficult to enumerate. However, with the advent of iPhone OS 3.0, Apple
seems to be making moves to loosen these restrictions.
Although there are many
disadvantages to this approach, it does mean that the App Store serves
as a security boundary. Programmatic security mechanisms for
applications running on the iPhone OS are fairly lax, but Apple can rein
in developers behaving in a deceptive or malicious fashion by refusing
to publish their applications or revoking them from the store.
In the event actively
malicious software does make it through the App Store, a second
approach, albeit one that has yet to be used by Apple, is a “kill
switch” allowing the blacklisting of applications after install.
Although there were some initial worries that Apple would be using this
to actively disable software it didn’t like, this has not been the case
to date.
Thus far, using Apple itself
as the gatekeeper and security boundary for iPhone applications has had
good results—except for developers, some of whom have had wait times of
up to six months just to get an application accepted. With the sheer
number of new iPhone applications appearing on a daily basis, it’s not
unlikely that more OS-based security features will be used more actively
in the future to smooth out the application-vetting process.
Code Signing
iPhone applications must be
signed by a valid code-signing certificate. Some applications, notably
ones that use the Keychain or cryptography primitives, are designed only
to be run on an actual device, rather than an emulator. To obtain a
code-signing certificate, use the Keychain Access tool to create a
Certificate Signing Request (CSR), as described in Apple’s Code Signing
Guide (see http://developer.apple.com/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html). Once the certificate has been issued (a fairly quick process), you can import the certificate into your Keychain.
If you don’t have a membership
with the iPhone Developer Program, it is still possible to use
self-signed certificates to sign applications. However, this involves
disabling security checks in the device, which is ill-advised for
devices that aren’t used solely for development. For more information on
the mechanisms behind Apple signature verification and how to bypass
them, see Jay Freeman’s page at www.saurik.com/id/8.
Executing Unsigned Code
As
mentioned before, third-party iPhone applications existed before the
App Store. On “jailbroken” phones, using Cydia and Installer are the two
most popular ways to install unauthorized third-party software. Even
without submitting your packages to a public repository, you can still
execute unsigned code on your device.
Once jailbroken, the iPhone can
run an SSH daemon that can be used to copy unsigned applications onto
the device. These applications can even run outside of the default Apple
sandboxing policies. To sideload your sneaky, illicit iPhone
application onto a device, you can perform the following steps:
Using Cydia, install the BSD Subsystem and OpenSSH packages.
Find the IP address of your iPhone by examining the Network Settings panel.
Using your OS X machine, open the Terminal application.
Type ssh root@10.20.30.40, where 10.20.30.40 is the IP address of your phone. When asked for a password, enter alpine.
The first order of business should be to change the device’s root password. Enter the command passwd to do this.
You can now copy your application to the device. To do this, archive the application on your OS X machine using tar -cvzf myapp.tar.gz MyApp, where MyApp is the application bundle.
Copy the bundle to the device using scp myapp.tar.gz root@10.20.30.40.
Once the archive is copied over, ssh back into the iPhone and cd to the Applications directory.
Execute tar -xvzf myapp.tar.gz. The application will be extracted.
Restart your springboard (with BossPrefs, for example) or reboot your device. Your application should appear on the springboard.
