Difference between revisions of "Decrypting Firmwares"

From The iPhone Wiki
Jump to: navigation, search
(moving content over...)
(added summary (needs work), rewrote 1.0.x section, and removed "See Also")
Line 1: Line 1:
  +
iOS contains many layers of encryption.<!-- TODO: FINISH -->
==1.0.x==
 
  +
If you want to decrypt 1.0.x [[iPhone]] Ramdisks, you must remove some trash from the beginning of them. You can do this in Terminal.app (on Mac OS X you can find them in /Applications/Utilities/).
 
  +
== 1.0.x ==
# Unzip firmware image (change extension .ipsw to .zip and double click on archive) and find restore ramdisk.
 
  +
With the release of the [[iPhone]], the [[ramdisk]]s weren't encrypted. So, in order to mount them, all you need to do is remove some data from the beginning. You can either open up a hex editor and remove ##### bytes from the beginning, or open up a console and run <code>dd</code><sup>[{{man|dd|1}}]</sup>:
# In Terminal.app, run
 
dd if=restore_ramdisk.dmg of=restore_ramdisk.stripped.dmg bs=512 skip=4 count=37464 conv=sync
+
dd if=''restoreRamdisk.dmg'' of=''restoreRamdisk.stripped.dmg'' bs=512 skip=4 count=37464 conv=sync
Where '''restore_ramdisk.dmg''' is image of restore ramdisk (for example 1.0 iPhone firmware restore ramdisk is 694-5259-38.dmg), and '''restore_ramdisk.stripped.dmg''' is 'decrypted' image, that you can mount and explore from Finder.
+
:where ''restoreRamdisk.dmg'' is the file name of the restore ramdisk (ex: the [[Heavenly 1A543a (iPhone)|iPhone 2G 1.0 firmware]] (1A543a) would be <code>694-5259-38.dmg</code>)
  +
:where ''restoreRamdisk.stripped.dmg'' is the output file name
   
NOTE: If after mounting stripped ramdisk you see errors, ignore them.
+
Once the data has been stripped, you can then mount ''restoreRamdisk.stripped.dmg'' in Finder on OS X, or with any other program. If you encounter errors after mounting the stripped ramdisk, you can safely ignore them.
   
 
== 1.1.x ==
 
== 1.1.x ==
Line 39: Line 40:
 
=== [[S5L8920]] ===
 
=== [[S5L8920]] ===
 
The [[n88ap|iPhone 3GS]] firmware files are interesting. They have two [[KBAG]]s, 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.
 
The [[n88ap|iPhone 3GS]] firmware files are interesting. They have two [[KBAG]]s, 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.
 
== See Also ==
 
* [[VFDecrypt Keys|Decrypting 3.0GM+ Firmware]]
 

Revision as of 20:21, 13 August 2013

iOS contains many layers of encryption.

1.0.x

With the release of the iPhone, the ramdisks weren't encrypted. So, in order to mount them, all you need to do is remove some data from the beginning. You can either open up a hex editor and remove ##### bytes from the beginning, or open up a console and run dd[man]:

dd if=restoreRamdisk.dmg of=restoreRamdisk.stripped.dmg bs=512 skip=4 count=37464 conv=sync
where restoreRamdisk.dmg is the file name of the restore ramdisk (ex: the iPhone 2G 1.0 firmware (1A543a) would be 694-5259-38.dmg)
where restoreRamdisk.stripped.dmg is the output file name

Once the data has been stripped, you can then mount restoreRamdisk.stripped.dmg in Finder on OS X, or with any other program. If you encounter errors after mounting the stripped ramdisk, you can safely ignore them.

1.1.x

To decrypt the 1.1.x Ramdisks, you must do a little extra work.

  1. Strip the first 0x800 bytes. (2 kilobytes[1])
  2. In Terminal.app, run
openssl enc -d -in ramdisk.dmg -out de.dmg -aes-128-cbc -K 188458A6D15034DFE386F23B61D43774 -iv 0

This uses the iPhone's 0x837 key which was first leaked by Zibri and had its purpose revealed on Geohot's (now closed) blog.

2.x+

The ramdisks on 2.x and up firmwares is a simple IMG3 file that you can decrypt using img3decrypt[2] or xpwntool[3]. You must download one of these utilities. For easier access, put them in /usr/local/bin on Unix-based and Linux-based machines or wherever on Windows. If you use Windows, you must use the cd command to navigate to the XPwn directory.

If you're using img3decrypt, run this:

img3decrypt e restore_ramdisk.dmg restore_ramdisk_decrypted.dmg "Ramdisk_IV" "Ramdisk_Key"

If you're using xpwntool, run this:

xpwntool restore_ramdisk.dmg restore_ramdisk_decrypted.dmg -k "Ramdisk_Key" -iv "Ramdisk_IV"


Where restore_ramdisk.dmg is image of restore ramdisk and restore_ramdisk_decrypted.dmg is decrypted image, that you can mount and explore from Finder. "Ramdisk_IV" and "Ramdisk_Key" is the decryption keys that you can find at the VFDecrypt Keys page or in the Info.plist from PwnageTool FirmwareBundles folder.

Because of the new HFS Compression used in Snow Leopard and 3.0 DMGs, you may see zero-sized files in the DMG if you don't use Snow Leopard. In order to extract those, check Talk:Obtaining Decryption Keys.

3.0GM+

S5L8900

To decrypt a firmware file, decrypt the encrypted key and IV in the KBAG using GIDecrypt, or OpenSSL with the key 5F650295E1FFFC97CE77ABD49DD955B3 and the iv 0

S5L8720

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.

S5L8920

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.