|
The iPhone Wiki is no longer updated. Visit this article on The Apple Wiki for current information. |
Difference between revisions of "Talk:Research: Pwnage Patches"
ChronicDev (talk | contribs) (→seriously?: new section) |
|||
| (54 intermediate revisions by 8 users not shown) | |||
| Line 1: | Line 1: | ||
| + | == Kernel and ramdisk patches == |
||
| − | What is more important, is the code before 1800587C. |
||
| + | Anyone care to share what is patched? |
||
| + | == yup == |
||
| − | Compilers translate actions like |
||
| + | '''ramdisk''': |
||
| − | :if (condition is good) |
||
| − | ::then |
||
| + | '''asr''' - patch out rootfs SHA1 check |
||
| − | into conditional jumps. What you can see with the MOV and NEG is most probably the result of a failed condition (-1) (or failed function result). Afterwards it depends on the compiler, how it further treats the result. |
||
| + | '''restored_external''' - patch wiping routine |
||
| − | Maybe the original pseudo code is as follows: |
||
| + | '''kernel''': |
||
| − | sig_check_result = do_check(important args); |
||
| − | ... |
||
| − | if (sig_check_result == 0) |
||
| − | everything goes fine ... |
||
| − | ... |
||
| − | a.s.o |
||
| + | haven't looked into this, but there are four patches, at least some of them are for codesign and apparently one of them has to do with virtual memory mapping. |
||
| − | So the question is, why it goes to the branch where R0 is set to -1 (patch 0) and what conditional branches lead to this code position? And the even more important question is, what is the underlying pseudo code? |
||
| + | == Thanks == |
||
| − | And the even more important question is, why is it really necessary to do reverse engineering of reverse engineering?? Could be much more simple the questions are answered by some people that tend to mystify some things... </sarcasm> |
||
| + | Do you know how the new codesign is added yet? |
||
| + | I notice you think they didn't use ldid. |
||
| + | It seems that the second patches to asr and restored are codesign (from what I can tell when 2.1 and 2.2 files are compared), but I don't see any in the kernel, they're all simple. |
||
| + | == patches == |
||
| − | said people would like to document, but most of the they're too busy using the little free time they have actually getting stuff done that people need done rather than documentation that 1% wants |
||
| + | patches to asr and restored are the patches i listed above, and patches for the hashes so that they will run. when i say in the kernel codesign is patch, then it wil patch out the need for code to be signed, but apparently it was determined that the sha1 hash check was too annoying to patched as it would always be changing, so they just rehashed asr and restored, not codesign, just rehashed. |
||
| − | If it's really like this, then I retract my statement. But then I hope 'said people' catch up on everything... Missing documentation and rare information (policies) were the main causes of the foundation of this wiki. |
||
| − | == |
+ | == hashes == |
| + | What are you taking the hash of? |
||
| − | so wait, if you don't have the time to document it, why are you getting mad that others are? some people are interested in it...is something wrong with that? if you aren't interested, you don't have to look at this page if you don't want to. Pwnage, especially Pwnage 2.0, is especially mystifying to some people. Pumpkin, I have personally asked you if I may take a look at the individual patches to understand ARM better and to see how Pwnage works, but you politely declined my offer. I mean...if I am curious about something, and I cannot find out about it via the official creators, is it a sin for me to want to find out anyway? I really don't see what the big deal is...Apple can just as easily extract and diff the files. They would especially want to do this, come to think of it. It is only the developers that might want to find out how Pwnage really works that are in the dark. |
||
| + | For example, I extracted asr from a stock 018-4378-1.dmg from 2.2 and compared it to one from a custom disk image; diffing them shows two patches; the first I assume to be the SHA1 check (at 0x12F16). |
||
| + | The second at 0x27C7A confuses me though, because I think this must be the hash (I'm new to this stuff, so forgive me if I'm just missing something incredibly obvious). |
||
| + | If I take the hash of the stock asr (9146c06d34b4fa9fc3cb3c7490851fabb875e3c8) and compare it to the hash within the file, it doesn't match (6350E8890FD7217152F72B3EA3285B6D7E617020). |
||
| + | The hash of the custom asr doesn't match the internal hash either, and the same goes for restored. |
||
| + | == isha / ldid == |
||
| − | I must say, I really like what you have done. The concept of your "Simple Unlock", it seems, you have applied to activation, and Pwnage itself. I'm not even being sarcastic. I really think it is pretty awesome. |
||
| + | it is rehashed with isha or ldid -s, i don't really know the nitty gritty of that stuff. |
||
| − | Peace, |
||
| + | |||
| − | [[User:ChronicDev|ChronicDev]] |
||
| + | == 2G DeviceTree == |
||
| + | |||
| + | It seems that this was never patched until redsn0w QuickPwn. |
||
| + | What exactly is the patch made--[[User:Cool name|Cool name]] 02:24, 14 April 2009 (UTC)--[[User:Cool name|Cool name]] 02:24, 14 April 2009 (UTC) to allow LogoMe to work? |
||
| + | I tried old patches (function-disable_keys -> xxxxxxxx-disable_keys, secure-root-prefix doesn't exist at all), but they don't seem to work. |
||
| + | |||
| + | :disable keys and secure root patches should have worked, afaik, are u sure u decrypted it correctly? [[User:ChronicDev|ChronicDev]] 23:44, 13 April 2009 (UTC) |
||
| + | |||
| + | ::I believe I did, all names are visible. I notice at 0x0 - 0x10, there seems to be secure-root-prefix, but it is garbled (*junk*oot-prefix), I don't know what this is about.. |
||
| + | ::I patched function-disable_keys at 0x3534, though.--[[User:James|James]] 00:10, 14 April 2009 (UTC) |
||
| + | |||
| + | :::you somehow used the wrong IV probably, double check that [[User:ChronicDev|ChronicDev]] 02:00, 14 April 2009 (UTC) |
||
| + | |||
| + | ::::I used the IV from ChronicDev GoogleCode, is it correct? I actually don't have a 2G so I cannot verify it. --[[User:James|James]] 02:03, 14 April 2009 (UTC) |
||
| + | |||
| + | |||
| + | :::::Err, James. How do you know the DeviceTree patches are not working if you do not have a 2G to get the keys from?--[[User:Cool name|Cool name]] 02:24, 14 April 2009 (UTC) |
||
| + | |||
| + | ::::::I've had other people test them for me. I always thought it was fishy that there was what was seemingly garbage at the beginning of the file, but went with it anyways and made the patch I could. The resulting image would never work, so I knew there must be either another patch or I did it wrong. --[[User:James|James]] 02:29, 14 April 2009 (UTC) |
||
| + | |||
| + | :::::::Ahh ok. You should have someone independently verify the keys of that DeviceTree, because as chronic said that IV is most likely incorrect.--[[User:Cool name|Cool name]] 02:39, 14 April 2009 (UTC) |
||
| + | |||
| + | ::::::::I most certainly remember there being a slip up with the devtree key, my bad, we never fixed that. if you can, in the meantime, use planet's crypto bundle to get the right IV |
||
| + | |||
| + | :::::::::Yeah, that's what I plan on having someone do. It's really weird though, we correctly decrypted 3.0b2 keys on the device with a seemingly bad DeviceTree flashed. It only had disable_keys patched out and garbage at the beginning iirc. Weird stuff. I'll comment the page with the correct IV when it's found though so you can edit it in. I'm kind of making this wiki a chat though, so I'll stop the edits. --[[User:James|James]] 03:00, 14 April 2009 (UTC) |
||
Latest revision as of 03:00, 14 April 2009
Contents
Kernel and ramdisk patches
Anyone care to share what is patched?
yup
ramdisk:
asr - patch out rootfs SHA1 check
restored_external - patch wiping routine
kernel:
haven't looked into this, but there are four patches, at least some of them are for codesign and apparently one of them has to do with virtual memory mapping.
Thanks
Do you know how the new codesign is added yet? I notice you think they didn't use ldid. It seems that the second patches to asr and restored are codesign (from what I can tell when 2.1 and 2.2 files are compared), but I don't see any in the kernel, they're all simple.
patches
patches to asr and restored are the patches i listed above, and patches for the hashes so that they will run. when i say in the kernel codesign is patch, then it wil patch out the need for code to be signed, but apparently it was determined that the sha1 hash check was too annoying to patched as it would always be changing, so they just rehashed asr and restored, not codesign, just rehashed.
hashes
What are you taking the hash of? For example, I extracted asr from a stock 018-4378-1.dmg from 2.2 and compared it to one from a custom disk image; diffing them shows two patches; the first I assume to be the SHA1 check (at 0x12F16). The second at 0x27C7A confuses me though, because I think this must be the hash (I'm new to this stuff, so forgive me if I'm just missing something incredibly obvious). If I take the hash of the stock asr (9146c06d34b4fa9fc3cb3c7490851fabb875e3c8) and compare it to the hash within the file, it doesn't match (6350E8890FD7217152F72B3EA3285B6D7E617020). The hash of the custom asr doesn't match the internal hash either, and the same goes for restored.
isha / ldid
it is rehashed with isha or ldid -s, i don't really know the nitty gritty of that stuff.
2G DeviceTree
It seems that this was never patched until redsn0w QuickPwn. What exactly is the patch made--Cool name 02:24, 14 April 2009 (UTC)--Cool name 02:24, 14 April 2009 (UTC) to allow LogoMe to work? I tried old patches (function-disable_keys -> xxxxxxxx-disable_keys, secure-root-prefix doesn't exist at all), but they don't seem to work.
- disable keys and secure root patches should have worked, afaik, are u sure u decrypted it correctly? ChronicDev 23:44, 13 April 2009 (UTC)
- I believe I did, all names are visible. I notice at 0x0 - 0x10, there seems to be secure-root-prefix, but it is garbled (*junk*oot-prefix), I don't know what this is about..
- I patched function-disable_keys at 0x3534, though.--James 00:10, 14 April 2009 (UTC)
- you somehow used the wrong IV probably, double check that ChronicDev 02:00, 14 April 2009 (UTC)
- I used the IV from ChronicDev GoogleCode, is it correct? I actually don't have a 2G so I cannot verify it. --James 02:03, 14 April 2009 (UTC)
- Err, James. How do you know the DeviceTree patches are not working if you do not have a 2G to get the keys from?--Cool name 02:24, 14 April 2009 (UTC)
- I've had other people test them for me. I always thought it was fishy that there was what was seemingly garbage at the beginning of the file, but went with it anyways and made the patch I could. The resulting image would never work, so I knew there must be either another patch or I did it wrong. --James 02:29, 14 April 2009 (UTC)
- Ahh ok. You should have someone independently verify the keys of that DeviceTree, because as chronic said that IV is most likely incorrect.--Cool name 02:39, 14 April 2009 (UTC)
- I most certainly remember there being a slip up with the devtree key, my bad, we never fixed that. if you can, in the meantime, use planet's crypto bundle to get the right IV
- Yeah, that's what I plan on having someone do. It's really weird though, we correctly decrypted 3.0b2 keys on the device with a seemingly bad DeviceTree flashed. It only had disable_keys patched out and garbage at the beginning iirc. Weird stuff. I'll comment the page with the correct IV when it's found though so you can edit it in. I'm kind of making this wiki a chat though, so I'll stop the edits. --James 03:00, 14 April 2009 (UTC)
