Taking apart iOS OTA Updates

iOS introduced Over-The-Air (OTA) updates sometime back in 5.x, which was after the 1^st edition of MOXiI was already published. As such was the case, this very important discussion was left out of where it should have been included (Chapter 6). With the 2^nd edition in the works, OTAs will naturally be included - but since this information is immediately useful (as you'll see shortly), I figured it made sense to publish it as an article.

Why should you care? (Target Audience)

As you probably know, iOS software images (the well known .IPSWs, which I did cover in the book) are encrypted. Thanks to the hard work of the folks at the iPhoneWiki, decryption keys are made available fairly regularly for A4 and A5 devices - the former via limera1n, and the latter through an undisclosed but pretty well known exploit somewhere in the boot chain. The problem, however, is that no keys exist for A6+ devices, most notably the 64-bit devices (5S, 6, iPad Air, etc). This is exacerbated by Apple effectively phasing out A4 with 8, and the very likely end-of-line for A5 when iOS 9 is likely to be announced this summer.

Thankfully, OTA updates exist and are unencrypted. This means that if you have a jailbroken device of version 8.1.2 or lower, you can do two pretty amazing things:

1. Obtain the OTA update, and - using the techniques demonstrated here - unpack it so as to reverse engineer it to your heart's content
or
2. Update the iOS filesystem image manually - while maintaining the jailbreak. That's actually a long and very delicate process which, if done improperly, can render your device unbootable and force you to restore to the latest, non jailbreakable version. If carried out correctly, however, you get the latest and greatest iOS - without sacrificing a jailbreak. A manual update is effectively indistinguishable from a stock update, provided you don't mess with the kernelcache or dyld, thanks to which the jailbreak remains feasible. In fact, this is important enough to merit a nice div of its own:
If you ARE going to try this at home on a real device - caveat - if you accidentally update dyld or the core libs you might end up locking yourself out of the user mode component of a given jailbreak. If you touch the kernelcache you will render the apticket.der invalid - which is even worse, since iBoot will refuse to boot you - and force you to restore, when the only IPSWs Apple presently signs are no longer jailbreakable. At least, publicly. A future post will demonstrate how to do so - but it requires meticulous attention to detail. Believe me.

Both the above are great, but especially the latter. In the case of 8.2, for example, that gives you the Apple Watch support, in case you absolutely must send your heartbeat to your friends (Awwww). But going forward, this will likely be useful for whatever 9.x brings - if only to reverse the hell out of it. So let's get started, but before that - the usual disclaimer:

OTA update bundles are zip files which Apple makes readily available for download at http://appldnld.apple.com/. The zip files are cryptically named, in what's probably a SHA-1 of their "real" name. The convention appears to be:

Fortunately, you can find all the files easily through the iPhoneWiki OTA page - and download them easily. You don't even have to fake a User-Agent (Have I mentioned, Cupertino Syndrome? Lock the door (encrypt the fs), but leave the Window wide open :).

As you can see, each OTA update is basically keyed to two factors - the device build, and the base iOS version from which the update is taking place. This makes it easy to pick out the update that's just "right for you", given whichever device you have, and whichever version you're stuck in with the jailbreak. In our example, let's pick the version I used, which is to iOS 8.2 from iOS 8.1.2 on an iPhone 6. That's http://appldnld.apple.com/ios8.2/031-15794-20150309-8FF6FDB8-C21F-11E4-8DFB-9EA63780E501/com_apple_MobileAsset_SoftwareUpdate/58af7e9d9d6ade039f47f01bcd420887645204bb.zip.

Downloading this (or any other) update, an unpacking the zip, expect to see the same directory structure, which is something like this:

• META-INF/: Subdirectory containing a single file, com.apple.ZipMetadata.plist, which is a binary plist:

  morpheus@Zephyr(/tmp/OTA)$ cat META-INF/com.apple.ZipMetadata.plist   | plutil -convert xml1 -o - - 
  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
  <plist version="1.0">
  <dict>
  	<key>RecordCount</key>
  	<integer>3162</integer>   <!-- Count of files in Zip -->
  	<key>StandardDirectoryPerms</key>
  	<integer>16877</integer>  <!-- 40755 for directories -->
  	<key>StandardFilePerms</key>
  	<integer>-32348</integer> <!-- 644 for files         -->
  	<key>Version</key>
  	<integer>2</integer>
  </dict>
  </plist>
  

  all in all, nothing too interesting.
• Info.plist - As with any bundle, the required manifest. This is a standard Plist, which looks like the following:

  morpheus@Zephyr (/tmp/OTA)$ cat Info.plist 
  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
  <plist version="1.0">
  <dict>
          <key>CFBundleIdentifier</key>
          <string>com.apple.MobileAsset.SoftwareUpdate</string>
          <key>MobileAssetProperties</key>
          <dict>
                  <key>ActualMinimumSystemPartition</key>
                  <integer>2648</integer>
                  <key>Build</key>
                  <string>12D508</string>          Build of update (12D508 = 8.2)
                  <key>InstallationSize</key>
                  <string>0</string>
                  <key>MinimumSystemPartition</key>Min. partition size for upgrade
                  <integer>2648</integer>
                  <key>OSVersion</key>             Version of update 
                  <string>8.2</string>
                  <key>PrerequisiteBuild</key>     Build of origin (12B440 = 8.1.2)
                  <string>12B440</string>
                  <key>PrerequisiteOSVersion</key> Version of origin
                  <string>8.1.2</string>
                  <key>SUDocumentationID</key>
                  <string>PreRelease</string>      
                  <key>SUProductSystemName</key>   as can be expected..
                  <string>iOS</string>
                  <key>SUPublisher</key>
                  <string>Apple Inc.</string>
                  <key>SupportedDevices</key>
                  <array>
                          <string>iPhone7,2</string> Internal number of device (7,2 = 6)
                  </array>
                  <key>SystemPartitionPadding</key> Specified in MB
                  <dict>
                          <key>128</key>
                          <integer>1280</integer>
                          <key>16</key>
                          <integer>260</integer>
                          <key>32</key>
                          <integer>320</integer>
                          <key>64</key>
                          <integer>640</integer>
                          <key>8</key>
                          <integer>180</integer>
                  </dict>
                  <key>__AssetDefaultGarbageCollectionBehavior</key>
                  <string>NeverCollected</string>
          </dict>
  </dict>
  </plist>
  

• AssetData - Where the update binaries, etc are.

AssetData has an internal directory structure, like so:

• Info.plist - Once again (*sigh*) we have a plist here, containing similar keys to the previous one, but with the addition of a SystemUpdatePathMap dictionary, containing the names of the non-filesystem images (i.e. baseband, RAMdisk, glyphs, etc) which (from what I can see) aren't part of the update, or are present only in patch form)
• boot/ - A subdirectory containing actual non-filesystem images. These are all in the boot/Firmware/... directory, and contain the kernelcache.release.boardId, iBec/iBSS (in boot/Firmware/dfu), and iBoot and friends (in boot/Firmware/all_flash/all_flash.boardIdap.production.. These are all in im4p (or, pre-A7, IMG3) format, which means that they're encrypted. :-( Apple can encrypt those because they're handled during the boot process, wherein the GID key is still accessible.
• boot/ also contains a BuildManifest.plist, a lengthy manifest containing the update rules for the various im4ps. I'll leave this rather detailed description for the book..
• payloadv2/patches: A directory containing deltae to be patched. This is, of course, assuming, that the versions you're patching from are exactly the ones which came with stock iOS. These are in BXDIFF format, specifying offsets and patch data.
• payloadv2/prepare_payload: A PBZX file (see later), containing an (encrypted) IM4P. Likely used by iBoot and friends
• payloadv2/removed.txt: Specifying a list of files which will be removed (potentially replaced), one per line.
• payloadv2/links.txt: Specifying a list of symbolic links to link to (=) and add (+).
• payloadv2/payload: More on that in a moment
• Various BOM files

The BOM files

Apple uses the venerable NeXTSTEP Bill-Of-Materials (BOM) proprietary format for their bundles. The private Bom.Framework (which likely hasn't changed from NextSTEP, aside from 64-bit support..) handles these files, and you can view them on OS X using the lsbom(8) command, or package them yourself with mkbom(8). The files are:

pre.bom	Bill of materials of files pre-application of payload
post.bom	Bill of materials of files post-application of payload
payload.bom	Bill of materials of files in payload

An additional file, payload.bom.signature protects payload.bom from tampering, though in practice that's meaningless (binaries in BOM have to be codesigned anyway, and if you're on a jailbroken device this, too, can be bypassed). I've discussed the BOM format in the book (Chapter 6), so no sense adding more here. What's more interesting is the payload file itself.

The payload and pbzx files

The patches in the payloadv2 directory are only applicable to files which already exist on the system, and - by means of patch application - can be updated to a new file version. iOS updates, however, often contain new functionality (again, the Watch support in 8.2 being a great example).

New functionality can be found in the payloadv2/payload directory. Inspecting the file reveals a "pbzx" magic, like so:

morpheus@zephyr(/tmp/OTA/payloadv2)$ od -t x1 -t c payload  | more
0000000    70  62  7a  78  00  00  00  00  01  00  00  00  00  00  00  00
           p   b   z   x  \0  \0  \0  \0 001  \0  \0  \0  \0  \0  \0  \0
0000020    01  00  00  00  00  00  00  00  00  ed  37  20  fd  37  7a  58
         001  \0  \0  \0  \0  \0  \0  \0  \0 355   7     <fd>   7   z   X
0000040    5a  00  00  00  ff  12  d9  41  04  c0  e2  ed  b4  07  80  80
           Z  \0  \0  \0 377 022 331   A 004 300 342 355 264  \a 200 200
...
........   a1  86  1f  56  0d  d3  56  37  03  00  00  00  00  00  59  5a
         241 206 037   V  \r 323   V   7 003  \0  \0  \0  \0  \0   Y   Z

The <FD>7zX you see in the first row, and the YZ at the end of the file are clearly indicative of the XZ compression header and trailer. That Apple adopted LZMA is not surprising, considering that it's already used in the kernelcaches (as of 10.10/8.0). Outright using XZ was a surprise. But that makes our life easier - grabbing the XZ sources from tukaani.org, you can quickly build the XZ binary which will decompress it. But just stripping the pbzx encapsulation won't work - the XZ data is separated into chunks - somewhat akin to how Apple compresses DMGs, if you saw the other article of mine. So you need a small "extractor" for these chunks, before you can get to apply XZ on them. I've just the tool for that, which you can compile yourself from this listing:

#include <stdio.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>


typedef unsigned long long uint64_t;

int main(int argc, const char * argv[])
{

    // Dumps a pbzx to stdout. Can work as a filter if no argument is specified

    char buffer[1024];
    int fd = 0;

    if (argc < 2) { fd  = 0 ;}
    else { fd = open (argv[1], O_RDONLY);
           if (fd < 0) { perror (argv[1]); exit(5); }
         }


    read (fd, buffer, 4);
    if (strncmp(buffer, "pbzx", 4)) { fprintf(stderr, "Can't find pbzx magic\n"); exit(0);}

    // Now, if it IS a pbzx

    uint64_t length = 0, flags = 0;

    read (fd, &flags, sizeof (uint64_t));
    flags = __builtin_bswap64(flags);

    fprintf(stderr,"Flags: 0x%llx\n", flags);

    int i = 0;
    int off = 0;

    while (flags &   0x01000000) { // have more chunks
    i++;
    read (fd, &flags, sizeof (uint64_t));
    flags = __builtin_bswap64(flags);
    read (fd, &length, sizeof (uint64_t));
    length = __builtin_bswap64(length);

    fprintf(stderr,"Chunk #%d (flags: %llx, length: %lld bytes)\n",i, flags,length);
     
    // Let's ignore the fact I'm allocating based on user input, etc..
    char *buf = malloc (length);
    read (fd, buf, length);

   // We want the XZ header/footer if it's the payload, but prepare_payload doesn't have that, 
    // so just warn.
    

    if (strncmp(buf, "\xfd""7zXZ\0", 6))  { fprintf (stderr, "Warning: Can't find XZ header. This is likely not XZ data.\n"); }
    else // if we have the header, we had better have a footer, too
    if (strncmp(buf + length -2, "YZ", 2)) { fprintf (stderr, "Warning: Can't find XZ footer. This is bad.\n"); }

    write (1, buf, length);

    }

    return 0;
} 

And use like so:

morpheus@Zephyr (/tmp/OTA/payloadv2)$ cc pbzx.c -o pbzx
morpheus@Zephyr (/tmp/OTA/payloadv2)$ ./pbzx < payload > p.xz
morpheus@Zephyr (/tmp/OTA/payloadv2)$ ls -l payload p.xz
-rw-r--r--  1 root      admin  443537788 Mar 18 13:47 p.xz
-rw-r--r--@ 1 morpheus  admin  443539064 Feb 26 07:16 payload
morpheus@Zephyr (/tmp/OTA/payloadv2)$ xz --decompress p.xz
morpheus@Zephyr (/tmp/OTA/payloadv2)$ ls -l p
-rw-r--r--  1 root  admin  1310837211 Mar 18 13:47 p
morpheus@Zeyphr (/tmp/OTA/payloadv2)$ file p
p: VAX demand paged (first page unmapped) pure executable not stripped 

The compression is evident - and quite impressive (1.2GB compressed into 423MB - some 65% - not bad, considering this is binary data). And we now have a single archive - that p - which is the last part of the bundle we need to deal with, and is obviously not a VAX executable..