Our asr binary, however, is embedded inside the packed Restore ramdisk image, stored at /018-6306-403.dmg within the IPSW. The iBSS and iBEC are files that live just inside the unzipped IPSW, at /Firmware/dfu/ and /Firmware/dfu/. Unfortunately, things aren’t quite so straightforward anymore. Well, we’re no stranger to code signing by this point, let’s just fire up our disassembler and patch around it.įirstly, we’ll need to set up some patching infrastructure like we’ve done already with the iBSS and iBEC. Instead, restored_external shells out to another program in the ramdisk, /usr/sbin/asr, with the following incantation: This is where we’ll want to inject whatever modifications we’d like to make to the ‘final’ iOS distribution installed on the device.Īs it turns out, the code for this doesn’t live in restored_external at all. Perhaps the most interesting work restored_external performs is flashing a new filesystem to NAND. Do we really need to embed a URL describing the plist grammar in every one of these thousands of interchanges? Apple says… Yes! There in a flash It’s therefore pretty fascinating that every single message shuffled between the device and host contains so much redundant metadata about the XML schema. Restored_external sends a lot of commands to the host, and the host sends a lot of data back. Command OOBData OOB Length 84 OOB Offset 72 Here’s what restored_external sends when it’s letting the host know that it’s next going to repartition the device’s disk: Restored_external sends its progress reports, and requests the next piece of the IPSW, using structured commands sent over a USB tunnel to and from the host. In this case, I’m using a hacked up fork of idevicerestore that reuses the internals to do the exact work that gala needs. Normally, this software running on the host would be Apple-owned code such as iTunes or Finder, but folks have done great work reverse engineering these protocols and providing open-source implementations. restored_external also relies on the host Mac to receive the IPSW data that the restore process will flash to the device (such as the root filesystem, baseband firmware, bootchain, etc). Throughout this process, restored_external will talk to software on the host Mac, keeping it abreast of the progress so far. Flashing the new bootloader chain to NOR.Updating the persistent boot arguments stored in NVRAM.Mounting the new partitions and flashing the OS image.Communicating logs from any previous failed restore attempts.Wiping the encryption key from the previous installation’s user data partition, rendering it unrecoverable.Writing disk partitions to the GPT and setting up new filesystems.restored_external kicks off and coordinates several important pieces of work: Taking a closer look at restored_external, it’s clear that this is the main driver for the device restore process.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |