iOS contains many layers of encryption. This page details how to remove the encryption wrapper around each file in the IPSW file. A decrypted ramdisk is required to obtain the key for the root filesystem, but not to simply decrypt it with an existing key.
For more history, see Firmware Keys.
With the release of the iPhone, the IMG2 files weren't encrypted. So, in order to use them, all you need to do is remove the 2048 byte (2 KiB) 8900 header from the file. You can do this with either a hex editor, or open up a console and run
dd if=input of=output bs=512 skip=4 conv=sync
Once the header has been stripped, you will be left with either an IMG2 file or a mountable HFS filesystem.
1.1.x - 2.0b3
In order to decrypt them, you need to remove the 2048 byte (2 KiB) 8900 header from, then decrypt the resulting file. You can do this with either a hex editor, or open up a console and run
dd if=input of=stripped bs=512 skip=4 conv=sync
Once the header is stripped, you need to do the actual decryption. The ramdisk is encrypted using AES-128 with cipher block chaining (CBC). The key is the 0x837 key with no IV. To decrypt, open up a console and run
openssl enc -d -in stripped -out output -aes-128-cbc -K 188458a6d15034dfe386f23b61d43774 -iv 0
Once decrypted, you will be left with either an IMG2 file or a mountable HFS filesystem.
2.0b4 - 3.0b5
With the fourth beta of 2.0, Apple introduced the IMG3 file format, replacing the broken IMG2 file format. This format was soon reversed and img3decrypt[src] was created by Steven Smith (@stroughtonsmith) on 21 Aug 2008. His code was later implemented into xpwntool[src]. In order to decrypt an IMG3 file, open a console and run one of the commands depending on your program choice:
img3decrypt e input output iv key xpwntool input output -k key -iv iv
Once decrypted, you will be left with either a raw binary blob. If
input was a ramdisk,
output will be a mountable HFS filesystem.
OS X Snow Leopard introduced the HFS compressed disk image. With 3.0 (what beta?), Apple began using Snow Leopard to package the ramdisks. This results in some zero sized files in the disk image if you don't use Snow Leopard or newer. A discussion on extracting those files is available on the talk page.
With the 3.0 Golden Master (7A341) and 3.0.1, Apple messed up and, instead of using the application processor-specific GID Key, used a pseudo-GID of 5f650295e1fffc97ce77abd49dd955b3 to encrypt the KBAG. This makes obtaining the keys for this version dead simple. Once you have decrypted the KBAG, decryption using the keys in it is the same as above.
Business as usual, but keys and IVs have to be decrypted on the device still, unlike with the new S5L8900 KBAGs. Apple incorrectly assumed that by encrypting iBEC and iBSS they were being sly. They were not. You can decrypt those on a 2.2.1 aes setup no problem whatsoever.
The iPhone 3GS firmware files are interesting. They have two KBAGs, which use AES-256 instead of the S5L8900 and S5L8720 that are using AES-128 still. The first KBAG has an identifier in it's header indicating that it is to be decrypted with the gid key, and the second is not known. For those that don't know how AES256 works, this now means that the first 0x10 bytes are the IV, and the remaining 0x20 bytes (not 0x10 anymore!) are the key.
S5L8960 and later
img4 -i INPUT OUTPUT ivkey
INPUT is the file you want to decrypt, OUTPUT is the file you want to output once decrypted and ivkey is the IV and Key together for the file you are trying to decrypt.