![]() Tracking this down further, it turns out that if I merely mount the ramdisk. This is a serious problem, as we’ll need to modify this ramdisk to disable code signing mechanisms within binaries it contains. In any case, making any patches to anything in the ramdisk causes this critical Validating source. I think this might be because asr is comparing the ramdisk loaded on-device to the one that’s stored in the IPSW, but I’m not too sure. I eventually realize that applying any patches to the ramdisk causes asr to reject the IPSW. I’m tempted to dive straight into patching around this, but it’s important to eat our vegetables: we’ve only managed to get this far by using the unmodified Restore ramdisk, and we’ll definitely want to make sure that we can flash an OS image from a ramdisk that we fully control before we move on from here. On our first try with this hack, flashing the LLB to NOR fails with an opaque error code. After the main filesystem image is flashed to NAND, the restore process moves on to other tasks under its purview, such as flashing the new bootchain to NOR. I was able to disable the IPSW personalization checks in the kernel, without touching the contents of the ramdisk itself, which allowed the restore to steam through with an unpersonalized IPSW. However, we do get past the critical step of asr deciding that it’s willing to give us the time of day. iOS 4 is long unsupported by Apple, and therefore such signing is no longer possible. It’s always nice to see things moving a bit further along in the restore! The restore eventually fails because the restore process expects a valid IPSW that’s been personalized and signed by Apple. Let’s start by running the original ramdisk that comes from the IPSW, with no modifications whatsoever: Over the course of this, I rely on the time-worn tradition of getting as close as possible to something that works, then steadily deviating towards the behavior I actually want. Systematic investigationĭecked out in my full detective regalia, I peer under sewer grates and scrapbook loose hairs, searching for any clue on how to get asr to accept the host’s IPSW. This kind of thing is always more fun when you know with certainty that you’ll figure it out in the end, but here I didn’t feel like I had any such guarantee. I scraped my fingernails across asr for a week. Perhaps if we patch some important routines in amework everything will just fall into place? Mounted_restore_ramdisk/System/Library/PrivateFrameworks/amework/DiskImagesĬool! This comes from within /System/Library/PrivateFrameworks/, which is a bit more of a plausible search radius. $ grep -arl "Using Hardware AES" mounted_restore_ramdisk ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |