The iPhone Wiki is no longer updated. Visit this article on The Apple Wiki for current information. |
Difference between revisions of "Decrypting Firmwares"
m (5urd moved page Obtaining Decryption Keys to Decrypting Firmwares without leaving a redirect) |
m (added link to blackbird) |
||
(37 intermediate revisions by 8 users not shown) | |||
Line 1: | Line 1: | ||
− | iOS contains many layers of encryption. This page details how to |
+ | iOS contains many layers of encryption. This page details how to remove the encryption wrapper around each file in the [[IPSW File Format|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]]. |
||
− | == 1.0.x == |
||
− | With the release of the [[m68ap|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(1)</code><sup>[{{man|dd|1}}]</sup>: |
||
− | dd if=''ramdisk.dmg'' of=''ramdisk.stripped.dmg'' bs=512 skip=4 count=37464 conv=sync |
||
− | :where ''ramdisk.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 ''ramdisk.stripped.dmg'' is the output file name |
||
+ | == Ramdisks == |
||
− | Once the data has been stripped, you can then mount ''ramdisk.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. |
||
+ | This section details the decryption of the ramdisks in an [[IPSW File Format|IPSW]] file. The listed console commands are applicable to the [[S5L File Formats#IMG2|IMG2]] or [[IMG3 File Format|IMG3]] files under <code>/Firmware</code> also. |
||
− | == 1. |
+ | === 1.0.x === |
+ | With the release of the [[M68AP|iPhone]], the [[IMG2 File Format|IMG2 files]] weren't encrypted. So, in order to use them, all you need to do is remove the 2048 byte (2 KiB) [[8900 File Format|8900 header]] from the file. You can do this with either a hex editor, or open up a console and run <code>dd(1)</code><sup>[{{man|dd|1}}]</sup>: |
||
− | With the release of the [[n45ap|iPod touch]], Apple added a layer of encryption around the ramdisks. The decryption key wasn't obscured however, and a simple analysis of [[iBoot]] by [[User:Zibri|Zibri]] revealed the [[AES Keys#Key 0x837|0x837 key]]. At first, its purpose wasn't known. After a while, [[User:Geohot|geohot]] discovered its purpose. |
||
+ | 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 [[wikipedia:Hierarchical File System|HFS filesystem]]. |
||
− | In order to decrypt them, all you need to do is remove the <code>0x800</code> byte (2 kibibytes) header<!-- INSERT dd COMMAND LINE -->, then open a console and run <code>openssl(1)</code><sup>[{{man|openssl|1}}]</sup>: |
||
− | openssl enc -d -in ''ramdisk.dmg'' -out ''ramdisk.decrypted.dmg'' -aes-128-cbc -K 188458A6D15034DFE386F23B61D43774 -iv 0 |
||
− | :where ''ramdisk.dmg'' is the file name of the ramdisk you are decrypting (ex: the [[Snowbird 3A109a (iPhone)|iPhone 2G 1.1.1 firmware]] (3A109a) would be either <code>022-3630-9.dmg</code> or <code>022-3629-9.dmg</code>) |
||
− | :where ''ramdisk.decrypted.dmg'' is the output file name |
||
− | == |
+ | === 1.1.x - 2.0b3 === |
+ | With the release of the [[N45AP|iPod touch]], Apple added a layer of encryption around the [[IMG2 File Format|IMG2]]. The decryption key wasn't obscured however, and a simple analysis of [[iBoot]] by [[User:Zibri|Zibri]] revealed the [[AES Keys#Key 0x837|0x837 key]]. |
||
− | The ramdisks on 2.x and up firmwares is a simple [[IMG3 File Format|IMG3 file]] that you can decrypt using [[img3decrypt]][http://code.google.com/p/img3decrypt/] or [[xpwntool]][http://github.com/planetbeing/xpwn/tree/master]. 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 <tt>cd</tt> command to navigate to the [[XPwn]] directory. |
||
+ | In order to decrypt them, you need to remove the 2048 byte (2 KiB) [[8900 File Format|8900 header]] from, then decrypt the resulting file. You can do this with either a hex editor, or open up a console and run <code>dd(1)</code><sup>[{{man|dd|1}}]</sup>: |
||
− | If you're using [[img3decrypt]], run this: |
||
+ | dd if=''input'' of=''stripped'' bs=512 skip=4 conv=sync |
||
− | img3decrypt e restore_ramdisk.dmg restore_ramdisk_decrypted.dmg "Ramdisk_IV" "Ramdisk_Key" |
||
+ | Once the header is stripped, you need to do the actual decryption. The ramdisk is encrypted using [[wikipedia:Advanced Encryption Standard|AES]]-128 with [[wikipedia:Block cipher mode of operation#Cipher Block Chaining (CBC)|cipher block chaining]] (CBC). The [[wikipedia:Key (cryptography)|key]] is the 0x837 key with no [[wikipedia:Initialization vector|IV]]. To decrypt, open up a console and run <code>openssl(1)</code><sup>[{{man|openssl|1}}]</sup>: |
||
− | If you're using [[xpwntool]], run this: |
||
+ | openssl enc -d -in ''stripped'' -out ''output'' -aes-128-cbc -K 188458a6d15034dfe386f23b61d43774 -iv 0 |
||
− | xpwntool restore_ramdisk.dmg restore_ramdisk_decrypted.dmg -k "Ramdisk_Key" -iv "Ramdisk_IV" |
||
+ | Once decrypted, you will be left with either an IMG2 file or a mountable [[wikipedia:Hierarchical File System|HFS filesystem]]. |
||
+ | === 2.0b4 - 3.0b5 === |
||
− | 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. |
||
+ | With the fourth beta of 2.0, Apple introduced the [[IMG3 File Format|IMG3]] file format, replacing the broken [[IMG2]] file format. This format was soon reversed and [[img3decrypt]]<sup class="plainlinks">[[http://code.google.com/p/img3decrypt/ src]]</sup> was created by Steven Smith (@[http://twitter.com/stroughtonsmith stroughtonsmith]) on {{date|2008|08|21}}. His code was later implemented into [[xpwntool]]<sup class="plainlinks">[[http://github.com/planetbeing/xpwn/tree/master src]]</sup>. 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'' |
||
+ | The IV and key for a specific firmware is available through the [[Firmware Keys]] page or from the <code>Info.plist</code> file underneath [[PwnageTool]]'s <code>/FirmwareBundles</code> folder. |
||
+ | Once decrypted, you will be left with either a raw binary blob. If <code>''input''</code> was a ramdisk, <code>''output''</code> will be a mountable [[wikipedia:Hierarchical File System|HFS filesystem]]. |
||
− | 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. |
+ | === 3.0 [[Golden Master|GM]]/3.0 === |
+ | OS X Snow Leopard introduced the HFS compressed disk image. With 3.0 (what beta?), Apple began using Snow Leopard to package the [[ramdisk]]s. 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 [[Talk:Decrypting Firmwares|the talk page]]. |
||
− | === [[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 |
||
− | === [[ |
+ | ==== [[S5L8900]] ==== |
+ | <!-- This needs to be moved to a new page. Maybe [[Obtaining Decryption Keys]]? --> |
||
+ | With the 3.0 Golden Master (7A341) and 3.0.1, Apple messed up and, instead of using the [[Application Processor|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 [[#2.0b4 - 3.0b5|as above]]. |
||
+ | |||
+ | ==== [[S5L8720]] ==== |
||
Business as usual, but keys and IVs have to be decrypted on the device still, unlike with the new [[S5L8900]] [[KBAG]]s. 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. |
Business as usual, but keys and IVs have to be decrypted on the device still, unlike with the new [[S5L8900]] [[KBAG]]s. 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]] === |
+ | ==== [[S5L8920]] ==== |
− | The [[ |
+ | 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]] on [[Application Processor|SoCs]] that have a CPFM of 03 (Production & Secure), and the second seems to be for decrypting with [[Application Processor|SoCs]] that have a CPFM of 01 or 00 (Development & Secure or Development & Insecure), as the CPFM seems to change which [[GID Key]] it uses. CPFMs of lower than 01 are normally prototypes in the DVT stage or lower. 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 ==== |
||
+ | With [[S5L8960]], Apple changed the file format to use [[IMG4 File Format|IMG4]] files instead of [[IMG3 File Format|IMG3]]. Decryption can be performed by running the following in a command line application (make sure you have the [https://github.com/xerub/img4lib img4lib]): |
||
+ | |||
+ | img4 -i INPUT -o OUTPUT -k 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. |
||
+ | |||
+ | == SEP == |
||
+ | This section details the decryption of the [[Secure Enclave Processor]] in an [[IPSW File Format|IPSW]] file. The listed console commands are applicable to the [[IMG4 File Format#IMG4_Payload|IM4P]] files under <code>/Firmware/all_flash</code>. |
||
+ | |||
+ | With the release of [[checkra1n]] 0.12.0, pongoOS has been updated to include [[Pangu]]'s project [[blackbird Exploit|blackbird]] which allows the exploitation of the [[Secure Enclave Processor]] to [[A10]] and [[A10X]] devices (for now, others will be supported in the future) from [[iOS]]/[[tvOS]] 12.0 - 14.2. To decrypt it, you'll need to enter pongoOS and insert the [[KBAG]]. This is done by compiling the <code>pongoterm</code> binary from the checkra1n project [https://github.com/checkra1n/pongoOS pongoOS] then execute a few commands in Terminal. |
||
+ | |||
+ | On macOS, if the checkra1n app is inside the <code>/Applications</code> folder: |
||
+ | |||
+ | <code>/Applications/checkra1n.app/Contents/MacOS/checkra1n -cp</code> |
||
+ | |||
+ | Alternatively, you could right-click the checkra1n.app and select "Show Package Contents" then navigate to <code>/Contents/MacOS/</code> and drag the checkra1n binary directly inside Terminal then adding <code>-cp</code> to the end. |
||
+ | |||
+ | Otherwise, with Linux you can install the latest via the [https://checkra.in/linux repository] then launching the checkra1n CLI: |
||
+ | |||
+ | <code>sudo checkra1n -cp</code> |
||
+ | |||
+ | Once done, use a USB to connect and place the device in [[DFU Mode]]. The process will begin with checkra1n running the device exploitation stages until a device boot is initiated. The Apple logo will show following the checkra1n logo shortly after along with some text on the screen. From here the user can execute the <code>pongoterm</code> command to enter the PongoOS shell. |
||
+ | |||
+ | Inside this shell you can type in <code>sep auto</code> which will start the [[Secure Enclave Processor]] exploitation process. |
||
+ | |||
+ | Then inserting the [[KBAG]] by typing in <code>sep decrypt [[KBAG]]</code>. |
||
+ | |||
+ | PongoOS will display the input [[KBAG]] from the [[IMG4 File Format#IMG4_Payload|IM4P]] file and output the decrypted [[wikipedia:Initialization vector|IV]] and [[wikipedia:Key (cryptography)|Key]]. |
||
+ | |||
+ | |||
+ | [[Category:Decryption]] |
Latest revision as of 08:42, 7 February 2022
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.
Contents
Ramdisks
This section details the decryption of the ramdisks in an IPSW file. The listed console commands are applicable to the IMG2 or IMG3 files under /Firmware
also.
1.0.x
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(1)
[man]:
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
With the release of the iPod touch, Apple added a layer of encryption around the IMG2. The decryption key wasn't obscured however, and a simple analysis of iBoot by Zibri revealed the 0x837 key.
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(1)
[man]:
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(1)
[man]:
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 August 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
The IV and key for a specific firmware is available through the Firmware Keys page or from the Info.plist
file underneath PwnageTool's /FirmwareBundles
folder.
Once decrypted, you will be left with either a raw binary blob. If input
was a ramdisk, output
will be a mountable HFS filesystem.
3.0 GM/3.0
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.
S5L8900
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.
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 on SoCs that have a CPFM of 03 (Production & Secure), and the second seems to be for decrypting with SoCs that have a CPFM of 01 or 00 (Development & Secure or Development & Insecure), as the CPFM seems to change which GID Key it uses. CPFMs of lower than 01 are normally prototypes in the DVT stage or lower. 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
With S5L8960, Apple changed the file format to use IMG4 files instead of IMG3. Decryption can be performed by running the following in a command line application (make sure you have the img4lib):
img4 -i INPUT -o OUTPUT -k 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.
SEP
This section details the decryption of the Secure Enclave Processor in an IPSW file. The listed console commands are applicable to the IM4P files under /Firmware/all_flash
.
With the release of checkra1n 0.12.0, pongoOS has been updated to include Pangu's project blackbird which allows the exploitation of the Secure Enclave Processor to A10 and A10X devices (for now, others will be supported in the future) from iOS/tvOS 12.0 - 14.2. To decrypt it, you'll need to enter pongoOS and insert the KBAG. This is done by compiling the pongoterm
binary from the checkra1n project pongoOS then execute a few commands in Terminal.
On macOS, if the checkra1n app is inside the /Applications
folder:
/Applications/checkra1n.app/Contents/MacOS/checkra1n -cp
Alternatively, you could right-click the checkra1n.app and select "Show Package Contents" then navigate to /Contents/MacOS/
and drag the checkra1n binary directly inside Terminal then adding -cp
to the end.
Otherwise, with Linux you can install the latest via the repository then launching the checkra1n CLI:
sudo checkra1n -cp
Once done, use a USB to connect and place the device in DFU Mode. The process will begin with checkra1n running the device exploitation stages until a device boot is initiated. The Apple logo will show following the checkra1n logo shortly after along with some text on the screen. From here the user can execute the pongoterm
command to enter the PongoOS shell.
Inside this shell you can type in sep auto
which will start the Secure Enclave Processor exploitation process.
Then inserting the KBAG by typing in sep decrypt KBAG
.
PongoOS will display the input KBAG from the IM4P file and output the decrypted IV and Key.