Jeez this was a pain in the ass, hopefully this will help someone else out too.
When I first began working on this project, I attempted to boot iOS 4.3, it had worked for me on all the a4 devices I owned. I figured with some minor tweaks, I could manage to get it to work on an a5 iPad 2. Boy was I wrong, and this put me for a spin. There was this odd error that kept presenting itself whenever I tried to boot (we'll get into this later). After a day of confusion, I decided to boot ios 4.3.5; I figured if this didn't work, no version of iOS 4.3.x would. Surely enough, it worked first try. Quick sidebar — I tend to take a bottom-up approach when working with iOS, meaning that, rather than developing from 4.3.5 down, I'll develop from 4.3 up. This is generally a good practice, but it caused a lot of pain here. Next, I attempted to boot 4.3.4, and of course, it worked first try. Then I tried to boot 4.3.3 (more on why later), and I, unfortunately, saw the same message I was greeted with a few days back when attempting to boot 4.3.
Now, we have to play detective and begin putting together what we know. First, if we know 4.3 and 4.3.3 don't work, then, logically speaking, 4.3.1 and 4.3.2 won't work either. Now, we can infer that there's some fundamental difference between these versions and 4.3.4 and 4.3.5, specifically, that Apple had to have made some modification between 4.3.3 and 4.3.4. We have no clue where this modification might be, nor do we know what it is. Still, we have two vital pieces of information: an error, and two versions to compare.
Up until this point, I had no clue what the actual "error" was. I just knew that there was some general error during the boot process. Luckily we can modify a 4.3.3 iBoot slightly and run it with Kloader to see if we can extrapolate this error. The error was an issue with NAND, iBoot was reporting that there was an incompatible signature, and we'd have to reformat it. I had some theories about what might be causing this, but a quick google search clarified the issue. Apparently, Apple modified the security epoch, evident in SEPO. If we juxtapose a 4.3.3 iBoot with a 4.3.4 one, say via Morpheus' img3 tool, and compare tags, we can see that SEPO was modified by a single bit. 4.3.3 has 10000000 instead of 11000000 in 4.3.4. We can patch this bite, and use the 4.3.3 iBoot.
I decided to test the 4.3.3 iBoot by having it boot 4.3.4. This worked, our iBoot issue is resolved. I then decided to use the 4.3.3 devicetree with 4.3.4, and again, this worked. Then I tried the 4.3.3 kernelcache; this, unfortunately, did not work — it couldn't get past the Apple Logo. I thought it was a result of me trying to boot 4.3.4, so I tried 4.3.3, this didn't work as well. Now, we have another issue, this kernelcache. In a last-ditch effort, I decided to use the 4.3.4 kernelcache. This got past the Apple Logo but was not able to load launchd, and thus 4.3.3 didn't boot.
Here's why 4.3.3 is so valuable: it's the only version of ios 4 that has a Jailbreak for an iPad 2. But, as I began thinking, I realized I could just take it upon myself to get a Jailbreak working on different versions (and it wouldn't be difficult at all). I decided to try Jailbreaking 4.3.4. At its heart, a Jailbreak really only requires kernel patches and r/w permissions. We already have the r/w, because we can modify fstab from the main os. Now, you might be saying, "you're forgetting something, you need an exploit." Actually, not in our case. We don't need to, for example, overwrite kernel memory because we can just modify the kernel itself (this is way oversimplifed, I know). By using Kloader, we're essentially using custom boot components. In summation, a jailbreak requires some loophole to read and write to kernel memory, essentially breaking Apple's walled garden. We don't need this, as we can just modify the kernel itself, and by using Kloader, we're outside of this walled garden. All in all, this was relatively painless. While I did run into some issues when packing the patched kernelcache into an img3, this turned out to just be an issue with xpwntool.
Now we can install Cydia and give it a shot. It seemed to be working, but I encountered a few sandboxing issues. Specifically, some Apple apps like Safari would not launch, while others would. Apparently, this was nothing new, and Comex had an easy to implement solution. Ok, so now we've bypassed the 4.3.3 Jailbreak limitation — we can use 4.3.4, but why stop there? I decided to try using my components with 4.3.3, and it worked. Here is the lesson I learned: an unmodified 4.3.4 kernel cannot boot another version as its launchd is not properly signed. However, now that our 4.3.4 kernel is patched, this doesn't matter, it will run. It worked, and this was an indicator that all other versions should work too; I tried the exact same method with 4.3, 4.3.1, 4.3.2, and 4.3.5, it worked on each version.
There are definitely more efficient ways to go about doing this. Odds are I'll just write an iBoot payload, which will take care of this entire process on the device. Hopefully, this helps you. It all seems obvious to me now, but putting the pieces of the puzzle together was a b*tch and half. If you encounter an issue like this (which I already have with ios 5 and 6 on different devices), this method works most of the time. Reguardless, it would be interesting to determine what the actuall issue is with the kernel.
- Prepare a 4.3.3 or lower iBoot as you would any other, but patch SEPO.
- Prepare a 4.3.4 or higher kernelcache and perform Jailbreak patches.
- Run. Install Cydia. Do what you want.