It is relatively easy to process ipsw files in order to slipstream content into flashable images. The iOS ipsw files are zip files containing disk images and files required for flashing. Roughly, the same method can be used to reverse a prepared image from sno0wbreeze or redsn0w in order to create your own image with custom content.

The article is inspired from mbirth's wiki but with several adaptions on getting the tools compiled, extra information and a clear distinction between the various image files containted in an IPSW bundle.

The following are the disk images contained in a vanilla 4.2.1 iPad-iOS ipsw file:

Image	Size (MB)	Description	Marker used in this article
038-0018-002.dmg	506	Root filesystem
038-0024-002.dmg	15	Update ramdisk
038-0032-002.dmg	15	Restore ramdisk

The root filesystem is handled differently than the update and restore ramdisks and we use and so that you know which one we are talking about.

All disk images are encrypted and must be decrypted in order to be able to mount them. We will be setting up a kitchen in order to process the disk images. So far, the required tools are:

• GenPass

This is required to extract keys but it may be redundant if the keys are posted at the iPhone wiki vfdecrypt page.

• vfdecrypt-linux.tar.gz

Will be used to decrypt the disk images based on the keys supplied at the iPhone wiki vfdecrypt page.

• xpwn

This tool can be cloned with git:

git clone https://github.com/planetbeing/xpwn.git

This tool is optional for slipstreaming because the known decryption keys have already been recovered and are at the iPhone wiki vfdecrypt page.

• openssl-0.9.8h.tar.gz

Newer versions may work but it is a good choice to follow the same setup that has been known to work.

• cmake-2.6.2.tar.gz

Again, this may already be installed, but we follow the setup recommended by xpwn.

Now we build the required tools and create a fake root to which we will point the environment. We additionally use checkinstall as a wrapper around packages so we do not pollute the OS with outdated files. If your operating system does not have a bundled package of checkinstall, you can get the sources from the checkinstall page.

We set-up a directory for the kitchen:

mkdir ~/ios-kitchen

cd cmake-2.6.2
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
make
checkinstall --install=no

And we extract the package to:

~/ios-kitchen

The shared flag is requried to build the libraries, or xpwn will not find libcrypto:

cd openssl-0.9.8h
./config --prefix=/usr zlib-dynamic --openssldir=/etc/ssl shared
make

And extract the package to the kitchen:

~/ios-kitchen

gcc genpass.c ~/ios-kitchen/usr/lib/libcrypto.a -o genpass -I ~/ios-kitchen/usr/include

And we move it to the kitcken at:

~/ios-kitchen

gcc vfdecrypt.c ~/ios-kitchen/usr/lib/libcrypto.a -I ~/ios-kitchen/usr/include -o vfdecrypt

And we move it to the kitcken at:

~/ios-kitchen

First, make sure that you have the following libraries required by xpwn:

• libbz2
• zlib
• libusb2
• libpng
• curl

You need the development files along with the libraries and executables. On Debian-like Linux, you should install the -dev package for those tools which pulls the binaries as well.

Then, we remap the PATH so that the binaries are picked up from the kitchen and only then from the OS:

export PATH=~/ios-kitchen:$PATH

Provided that you cloned xpwn to ~/xpwn.

For some outdated reason, the cmake 2.6.2 build system contains a bug in FindOpenSSL which may fail to pick-up the OpenSSL libraries (even if -DOPENSSL_INCLUDE_DIR and -DOPENSSL_LIBRARIES are correctly specified) and headers and will require some changes to xpwn:

In xpwn/dmg/CMakeLists.txt, add the path to the kitchen for the libraries:

FIND_LIBRARY(CRYPTO_LIBRARIES crypto
      PATHS
      ~/ios-kitchen/usr/lib/          # Add the absolute path (expand ~ to your home directory).
      /usr/lib
      /usr/local/lib
   )

And pivot ~/ios-kitchen/usr/include/openssl to /usr/include/openssl:

mv /usr/include/openssl /usr/include/openssl.stock
cp -Ra ~/ios-kitchen/usr/include/openssl /usr/include/openssl

We create a build directory and compile:

mkdir ~/xpwn-build
cd ~/xpwn-build
cmake ~/xpwn

The process runs as follows:

1. use genpass to recover the key for an image (or skip this step if you know the keys from the iPhone wiki vfdecrypt page.
   • for image files, use vfdecrypt to decrypt the image file.
   • for image files, use xpwntool from xpwn/crypto/xpwntool.
2. use dmg if the decrypted image is compressed.

We first use genpass to recover the encryption key. Alternatively, you can just find the key for the device and iOS version on the iPhone wiki vfdecrypt page and skip this step.

genpass s5l8900x ./root_image.dmg α

where α () represents the root filesystem image.

After a while, the key will be spat out:

vfdecryptk: 6380bc27ef713750c21759ce770cb6540a8e31fca4c78820fd7be3a02030365a59257582

Using the vfdecryptk from the former section, we decrypt the image:

./vfdecrypt -iα -k6380bc27ef713750c21759ce770cb6540a8e31fca4c78820fd7be3a02030365a59257582 -oroot_image_decrypted.dmg

where α () represents the root filesystem image.

The root filesystem () is compressed, and we can test with dmg from the xpwn utilities whether the decryption succeeded:

dmg extract root_image_decrypted.dmg root_image_decrypted_decompressed.dmg

./xpwntool β upload_image_decrypted.dmg -iv 509e699fcfbc5317fa5eb3e79fc5a932 -k 9cee1bb0bf019db324eb266f426b80fbcfba614464932c6b416ed039fbde73dd

where β () is either an update or restore ramdisk and the keys can be obtained from the iPhone wiki vfdecrypt page.

By using the command-line utility file on each decrypted (and decompressed) dmg file, the output should be somewhat similar to:

Macintosh HFS Extended version 4 . . . 

which indicates that images are ready to be mounted.