|
The iPhone Wiki is no longer updated. Visit this article on The Apple Wiki for current information. |
Difference between revisions of "Talk:Jailbreak (S5L8720x)"
ChronicDev (talk | contribs) |
ChronicDev (talk | contribs) |
||
| Line 15: | Line 15: | ||
the ramdisk in Pusher.app is somehow encrypted, btw. anyone good with x86 wanna take a stab at reversing it? |
the ramdisk in Pusher.app is somehow encrypted, btw. anyone good with x86 wanna take a stab at reversing it? |
||
| + | |||
| + | [[User:ChronicDev|ChronicDev]] 02:14, 5 January 2009 (UTC) |
||
Revision as of 02:14, 5 January 2009
Worth noting
There is a kernelcache in 2.1 betas, and possibly other firmwares too, with the extension ".s5l8920x". This implies that (1) Apple is making yet ANOTHER revision, for some reason, and (2) this is pure speculation, so take it as it is, but it _might_ mean that there is an exploit in the s5l8720x rev that Apple found and is quitely trying to fixed. Again, that is pure speculation, because for all we know that could have been the first new processor rev, then Apple might have found a bug in THAT, and replaced it with the s5l8720x. Who knows :P
For what it is worth though, the s5l8920x kernel cache uses aes-256 instead of the currently used aes-128. It also has a second KBAG with a "2" in the space that would normally have "1" (meaning IV / Key pair is encrypted by the GID key) or "0" (meaning the IV / Key pair is not encrypted, but I do not believe they ever used this publicly, I am just saying this based on the code in iBoot). Now, provided, it is probably known that this wouldn't really count as "new encryption", as we know form the support iBoot already has for it that the first 16 bytes are the IV and then the proceeding 32 are the key, and we know it is encrypted with the gid key because of the "1" identifier (at least on the first KBAG), but I am just throwing it out there.
ChronicDev 20:45, 4 January 2009 (UTC)
Do like Pusher does?
Have you considered using the method RiP Dev used for their Pusher app? They claim that unlike Pwnage their app uses Apple-approved means for initial software installation (they say that it is called in-house deploying from enterprise SDK) and do not change system partition contents. To bypass signature checking Pusher uses in-memory patching, they say, so the warranty remains valid.
RE: Do like Pusher does?
I'll look into it for the hell of it, but as far as I know, they use the Pwnage exploit. but hmmm...it would not be below RiP Dev to get an enterprise membership just so that they could codesign Installer, now that you mention it...
the ramdisk in Pusher.app is somehow encrypted, btw. anyone good with x86 wanna take a stab at reversing it?
ChronicDev 02:14, 5 January 2009 (UTC)
