|
The iPhone Wiki is no longer updated. Visit this article on The Apple Wiki for current information. |
Difference between revisions of "Minus 0x20000 with Back Extend Erase"
(New page: The first exploit I found, at around 4 AM last night, was the -0x20000 exploit. Just like the -0x400 exploit, but -0x20000. Go figure. I guess Apple thought big numbers were harder to gues...) |
(added links to secpack) |
||
| (10 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
| + | This is the exploit used to unlock all phones with a 4.6 bootloader. |
||
| − | The first exploit I found, at around 4 AM last night, was the -0x20000 exploit. Just like the -0x400 exploit, but -0x20000. Go figure. I guess Apple thought big numbers were harder to guess. I was really pumped, hence the blog post. But that wasn't even half the battle. |
||
| + | ==Credit== |
||
| − | Like I said in the "impossible" post, 0x3C0000 can't have a valid secpack to allow booting. I spent the next 16 hours finding a way to do this. I can already write unsigned to the main fw section, all I need is a way to erase the secpack. My first idea was the eeprom secpack; upload the eeprom, endpack it, and the secpack is erased because the eeprom is "clean". But you can't upload a eeprom secpack until the 0x3C0000 is blank. My next idea was that the bl must erase the secpack before writing it. So a simple timing attack should do it. It turns out that no secpacks, even the same one, will write. |
||
| + | [[User:Geohot|geohot]] |
||
| + | ==Description== |
||
| − | I finally found a working exploit about 23 hours into my search for the software unlock. The explicit addresses 0xA03D0000-0xA03F0000 will always erase. This exploit relied on two things, the secaddrs are copied before the secpack is validated(stupid), and the erase command extends the range to whatever is in the secpack. So I tell it to erase 0xA03D0000-0xA03F0000, the erase command sees 0xA03C0000 to 0xA03F0000 in the secpack; BOOM secpack erased. |
||
| + | Writing -0x20000 before the firmware starts allows you to write anything you want. |
||
| − | The third minor concern was the full range check of 1.1.3. So use 1.1.2 :) This allows full unsigned code execution, it is a relatively simple matter of patching the bootloader to skip the range check. And while you are at it, patch the bootloader to validate all tokens. IPSF style unlock w/o touching the seczone. |
||
| + | |||
| + | 0x3C0000 can't have a valid [[secpack]] to allow booting. The explicit addresses 0xA03D0000-0xA03F0000 will always erase. This exploit relied on two things, the secaddrs are copied before the [[secpack]] is validated(stupid), and the erase command extends the range to whatever is in the [[secpack]]. So erase 0xA03D0000-0xA03F0000, the erase command sees 0xA03C0000 to 0xA03F0000 in the [[secpack]]; BOOM [[secpack]] erased. |
||
| + | |||
| + | ==Implementations== |
||
| + | *[[gunlock]] |
||
| + | *[[BootNeuter]] |
||
| + | |||
| + | [[Category:Unlocking Methods]] |
||
| + | [[Category:Baseband Exploits]] |
||
Latest revision as of 19:58, 22 October 2010
This is the exploit used to unlock all phones with a 4.6 bootloader.
Credit
Description
Writing -0x20000 before the firmware starts allows you to write anything you want.
0x3C0000 can't have a valid secpack to allow booting. The explicit addresses 0xA03D0000-0xA03F0000 will always erase. This exploit relied on two things, the secaddrs are copied before the secpack is validated(stupid), and the erase command extends the range to whatever is in the secpack. So erase 0xA03D0000-0xA03F0000, the erase command sees 0xA03C0000 to 0xA03F0000 in the secpack; BOOM secpack erased.
