Verification process while restoring iPhone firmware through iTunes

This article is explaining how is the process of iPhone firmware verification while restoring through iTunes.

Understanding the iTunes verification server
By iGuru – Version 1.1 – 26th September 2009
Visit https://www.macdotnub.co.cc/articles/ for the latest version.
Dedicated to: Jay Freeman (Saurik), semaphore and Apple.
Background:
With the introduction of the iPhone 3G[S] (3GS, not 3G) Apple introduced a new feature – restore verification.
This process relies on specific data that is unique to each phone, including the iPhone 3G[S]’ ECID, a new ID that is unique to every phone produced.

How the verification process works:

Essentially, when you attempt to restore the iPhone using iTunes, a specific file called a Property List (plist – A specific XML file format that Apple Computer & GNUstep, formerly known as NeXT created) is generated, and a challenge/response protocol is initiated between the iPhone and Apple, during which a partial digest is sent to Apple. The server then decides if they are going to sign it, and sends back the response.

The Request:
This plist file contains 20 requests for specific information listed below, which is then sent to Apple’s verification server.
– AppleLogo, BatteryCharging, BatteryCharging0, BatteryCharging1, BatteryFull, BatteryLow0, BatteryLow1, BatteryPlugin, NeedService, RecoveryMode, RestoreLogo – all of which are images in the img3 format.
– DeviceTree (The Device Tree for your iPhone)
– KernelCache (The Kernel Cache for your iPhone)
– LLB (The Low Level Bootloader, this runs several setup routines, and checks the signature of iBoot before loading it)
– RestoreDeviceTree (The Device Tree used when restoring the iPhone)
– RestoreKernelCache (The Kernel Cache used when restoring your iPhone)
– RestoreRamDisk (The RAM Disk used when restoring your iPhone)
– iBEC (A stripped down version of iBoot, which is used when performing a restore from a Fake DFU mode via the LLB)
– iBSS (A stripped down version of iBoot, missing things such as interfacing with the filesystem – used to bootstrap iBEC during a DFU restore)
– iBoot (The iPhone Stage 2 Bootloader)
All each of these requests are contained in the plist along with a Digest, Partial Digest and Trusted key value, along with a file path string.

All files other than KernelCache, RestoreDeviceTree, RestoreKernelCache, RestoreLogo, RestoreRamDisk, iBEC, and iBBS also contain the key IsFirmwarePayload.

The plist request also contains the following information:
– HostIpAddress (The IP address of your computer)
– HostPlatformInfo (darwin or windows)
– Locality (e.g. en_GB)
– VersionInfo (With a value of 3.8)
– ApBoardID (The ID of the board contained in your phone)
– ApChipID (The ID of a chip contained in your phone)
– ApECID (A number generated from the ECID, a unique ID for each phone manufactured)
– ApProductionMode (With a value of true or false)
– ApSecurityDoman (With a value of 1)

The Response:
The iTunes verification server takes the request plist sent to it, and verifies it, if it contains a request for a version of the iPhone OS that they are currently signing, the status will be 0, a message will be sent back saying SUCCESS, and the request string will contain a plist with the data required for the restore, after which and verification will pass.
If however, Apple is no longer signing requests for that OS version the server will return status 94, and the message ‚ÄúThis device isn’t eligible for the requested build.‚Äù, no plist response will be sent back and iTunes will then display the error message ‚ÄúThe iPhone “iPhone” could not be restored. This device isn’t eligible for the requested build.‚Äù Assuming you are trying to restore from DFU or Recovery mode.

If the plist is returned successfully, it will contain the 20 responses to the requests listed above in a slightly different format, containing the data response blob, along with a partial digest key, and the file path.

Conclusion:
Apple, what can I say? You put so much effort into designing a system to stop people from downgrading the firmware with these new devices, yet it can be defeated by a simple man in the middle attack (see further reading for details).
Further Reading:
Caching Apple’s Signature Server, by Jay Freeman (Saurik) – https://www.saurik.com/id/12
How to setup a local iTunes restore verification server, by iGuru – https://bit.ly/JnDw2
Credits:
Jay Freeman (Saurik), for the first working unofficial restore verification server.
semaphore, for the first local iTunes restore verification software (Umbrella & TinyTTS).

source: iGuru’s article