|
The iPhone Wiki is no longer updated. Visit this article on The Apple Wiki for current information. |
Difference between revisions of "User talk:Scotty2"
ChronicDev (talk | contribs) (→iRecovery source code: new section) |
ChronicDev (talk | contribs) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | == |
+ | == method == |
| + | Hey. I was looking through some colloquy logs and I didn't appear to understand the significance of something you said, but now that I have educated myself quite a bit on this stuff, I wanted to know how you were able to do this memory dump. It may serve as very very useful in jailbreaking the new iPod Touch 2G, because we can boot the device into recovery or something and then dump a decrypted iBoot. Not to mention we could send it a ramdisk, and execute the ramdisk command. That will put the decrypted output of what we just sent to 0xC000000 in memory, and if we can dump that, then we can get the ASR key to decrypt the root filesystem. IN case you were wondering, the mdb iBoot command only works up to 0xAFF0000, so dumping anything that way is a no go :( |
||
| + | scotty2: no, i don't mesh with them. i got in fights with 2 of them yesterday once i learned just how wrong they were about the bootloader chain |
||
| − | holy shit dude where have ya been? glad to see you are back in the iPhone scene, a lot has changed around here as you might see from looking around on the wiki now :) |
||
| + | scotty2: they were arguing with me about something they had no idea about |
||
| + | scotty2: i told them that the vrom is not where they think it is, that what they're looking at is only a memory copy of it, and they just told me i was stupid. |
||
| + | scotty2: so i provided dumps |
||
| + | scotty2: and they stopped talking to me |
||
| + | scotty2: but basically, we are now able to observe the very first instructions that run on the application processor, and every step in between. hopefully we can look for an exploit down in unflashable space, like dfu |
||
| + | scotty2: the second you plug your phone into itunes in dfu mode with 7.7, it instantly uploads new dfu code. (can't flash it though, just in memory) which leads us to think that maybe they found a hole in the old dfu code. |
||
| + | BTW, I doubt they knew about the stack overflow in the old DFU mode, I really think that they just wanted to remove IMG2 support for several reasons. For example, they don't want people to downgrade and jailbreak, for one thing. Second, they dont want people sending a old iBoot and kernel to boot a ramdisk, or since that is much more complicated, I realized that someone could just use diags+114 iBoot and they could chainload a patched new iBoot, which they could use to boot a proper ramdisk (no exploit needed, since it has a valid integrity as far as iBoot knows, since it is patched) to use the AppleImage3NORAccess service feature to flash the NOR with patched stuff. I could be wrong, but it is much more feasible tat they were afraid of people using the previous two exploits, than them actually knowing there was a stack overflow. Either way, devteam probably knew that if they had people either get a 114 ipsw to use diags, or if they released the stack overflow, Apple would retaliate with burning the new WTF into bootrom of the new device (itouch 2g), so they probably just opted to go with the stack overflow since it is more classy and cleaner since from there you can just do an iTunes restore (because the iBSS that itunes sends when it takes it outof the pwned ipsw can be patched, as the WTF is the thing that verifies it but it itself is patched thanks to the stack overflow). |
||
| − | if you are going to stay back for a while, stop by #iphone-hax in irc.osx86.hu...we are working on jailbreaking+pwning the new iPod Touch :D |
||
| − | |||
| − | again, glad to see you are back dude |
||
| − | |||
| − | == on the kernel patch thing == |
||
| − | |||
| − | sorry about that, i just know that the file documenting the patches was long. i should have definitely checked out what each patch actually did. shouldn't have assumed. |
||
| − | |||
| − | == iRecovery source code == |
||
| − | |||
| − | If you are interested in helping out, here is the source code plus mac binary of the tool that we use to communicate with DFU plus spawn a shell with an uploaded iBSS: |
||
| − | |||
| − | http://www.mediafire.com/download.php?nhteveyndyz |
||
| − | |||
| − | We are trying to get response support (the best we have is a one line response from iBoot) so that we can have two way communication with 0x1281 |
||
| − | |||
| − | BTW, note the following:<br> |
||
| − | 0x1281 = Recovery Mode, or an iBSS uploaded to DFU<br> |
||
| − | 0x1227 = DFU Mode, only files can be uploaded, you cannot spawn a shell with it. That is why you need to upload an iBSS, so you can communicate with that. |
||
| − | |||
| − | If you are too busy, no problem :) just throwing it out there in case you wanted to help out. |
||
Latest revision as of 19:14, 15 October 2008
method
Hey. I was looking through some colloquy logs and I didn't appear to understand the significance of something you said, but now that I have educated myself quite a bit on this stuff, I wanted to know how you were able to do this memory dump. It may serve as very very useful in jailbreaking the new iPod Touch 2G, because we can boot the device into recovery or something and then dump a decrypted iBoot. Not to mention we could send it a ramdisk, and execute the ramdisk command. That will put the decrypted output of what we just sent to 0xC000000 in memory, and if we can dump that, then we can get the ASR key to decrypt the root filesystem. IN case you were wondering, the mdb iBoot command only works up to 0xAFF0000, so dumping anything that way is a no go :(
scotty2: no, i don't mesh with them. i got in fights with 2 of them yesterday once i learned just how wrong they were about the bootloader chain scotty2: they were arguing with me about something they had no idea about scotty2: i told them that the vrom is not where they think it is, that what they're looking at is only a memory copy of it, and they just told me i was stupid. scotty2: so i provided dumps scotty2: and they stopped talking to me scotty2: but basically, we are now able to observe the very first instructions that run on the application processor, and every step in between. hopefully we can look for an exploit down in unflashable space, like dfu scotty2: the second you plug your phone into itunes in dfu mode with 7.7, it instantly uploads new dfu code. (can't flash it though, just in memory) which leads us to think that maybe they found a hole in the old dfu code.
BTW, I doubt they knew about the stack overflow in the old DFU mode, I really think that they just wanted to remove IMG2 support for several reasons. For example, they don't want people to downgrade and jailbreak, for one thing. Second, they dont want people sending a old iBoot and kernel to boot a ramdisk, or since that is much more complicated, I realized that someone could just use diags+114 iBoot and they could chainload a patched new iBoot, which they could use to boot a proper ramdisk (no exploit needed, since it has a valid integrity as far as iBoot knows, since it is patched) to use the AppleImage3NORAccess service feature to flash the NOR with patched stuff. I could be wrong, but it is much more feasible tat they were afraid of people using the previous two exploits, than them actually knowing there was a stack overflow. Either way, devteam probably knew that if they had people either get a 114 ipsw to use diags, or if they released the stack overflow, Apple would retaliate with burning the new WTF into bootrom of the new device (itouch 2g), so they probably just opted to go with the stack overflow since it is more classy and cleaner since from there you can just do an iTunes restore (because the iBSS that itunes sends when it takes it outof the pwned ipsw can be patched, as the WTF is the thing that verifies it but it itself is patched thanks to the stack overflow).
