|
The iPhone Wiki is no longer updated. Visit this article on The Apple Wiki for current information. |
Difference between revisions of "Talk:ARM7 Go"
(→Chronic, I may have found the way to use arm7_go) |
|||
| (6 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| + | == Vulnerability vs. Exploit and Credits == |
||
| − | ==My Payload== |
||
| + | @Chronic: I'm fine with you adding that you found it independently, but you have to be careful with the wording in general. |
||
| − | (Since RedSn0w will be out any day, this is just for the hell of it :) |
||
| + | It seems there are a great deal of misusages of the word "exploit" vs. vulnerability in this community. So if you don't mind, I'd like to clarify: |
||
| + | '''A vulnerability is the actual bug/security hole, whereas an exploit is the actual implementation which allows one to exploit the vulnerability.''' |
||
| − | If anyone has any ideas and would like to mess around with this hack, here is some code that (should) patch a 2.1.1 iBSS that you loaded, in memory. Again, just for fun, as the [[dev team]] probably has redsn0w, it's payload, and program almost completed. |
||
| + | For instance in the following sentence from the wiki: |
||
| − | <pre> |
||
| + | "The actual exploit is that, in the iPod Touch 2G 2.1.1 firmware, they left behind two commands: arm7_stop and arm7_go", the word "exploit" is not used properly. You are here talking about the vulnerability, not the exploit. |
||
| − | @ ipod touch 2G ibss 2.1.1 patcher |
||
| − | @ by chronic with some gas help from ius |
||
| − | @ |
||
| − | @ assemble this with gas |
||
| + | In my opinion, credits for vulnerability and exploit should be separated in general (I'm not talking about this one in particular, but I'm talking about vuln/exploit in general). One can find a vulnerability without exploiting it (because he doesn't want to, doesn't have the time, or it's too complicated and he doesn't manage actually to exploit it), and likewise someone can implement an actual exploit without discovering the initial vulnerability. IMHO, '''most of the time''', the exploit is where the skills really are, because it's one thing to understand why something is a security vulnerability, it's often another to make it actually real with a POC code (because of sanity checks, checking, filters and so on). Although sometimes, I do agree that finding the vulnerability itself requires mad skillz (as an example, prop' to Bleichenbacher for finding his RSA attack), it is my belief that most of the time, the exploit is where the difficulty lies. |
||
| − | .section .text |
||
| − | .global _start |
||
| − | _start: |
||
| − | stmdb sp!, {r0-r6} |
||
| − | ldr r0, =rangePatch |
||
| − | ldr r1, =permsPatch |
||
| − | ldr r2, =sigchPatch |
||
| − | ldr r3, =sigchecLoc |
||
| − | ldr r4, =permschLoc |
||
| − | ldr r6, =rangechLoc |
||
| − | strh r1, [r4] |
||
| − | strh r0, [r6] |
||
| − | strh r2, [r3] |
||
| − | ldmia sp!, {r0-r6} |
||
| − | mov pc, lr |
||
| + | Anyway, I think this page contains misusage of the word exploit, and other pages too, and I just wanted to point it. |
||
| − | .section .data |
||
| − | sigchecLoc: .word 0x2200F2FE |
||
| − | permschLoc: .word 0x2200C330 |
||
| − | rangechLoc: .word 0x2200C3A6 |
||
| − | rangePatch: .hword 0x0120 |
||
| − | permsPatch: .hword 0x0124 |
||
| − | sigchPatch: .hword 0x0020 |
||
| − | </pre> |
||
| + | Theres one thing to be said for finding a vuln and seeing it crash, sure, thats usually not where the skill is and I'm not sure how much credit it deserves. But after an exploit is out using the vuln, it's a lot easier to get yourself to write another exploit since you have confirmation that the vuln is exploitable. The iBoot envvar one happened to be reasonably easy to find yet reasonably hard to exploit. If you really had your exploit working pre ra1n then props. But if you wrote an exploit post ra1n it's a lot easier knowing that this vuln can work. --[[User:Geohot|geohot]] 18:44, 7 July 2009 (UTC) |
||
| − | [[User:ChronicDev|ChronicDev]] 19:45, 16 January 2009 (UTC) |
||
| + | iZsh, when I wrote this article I was a little less experienced, and have adjusted it a bit. That being said, if you check the chronic dev google code svn, you will see that I did implement it in a payload called "0wnboot". But yes, I did confuse the "exploit" and "vulnerability" definitions. [[User:ChronicDev|ChronicDev]] 19:16, 7 July 2009 (UTC) |
||
| − | ==Chronic, I may have found the way to use arm7_go== |
||
| − | Try to add the size of your payload just before it as an 32bit integer. |
||
| + | @geo: I can ensure you we definitely found it independently and implemented way before you released purplera!n. And I agree that re-implementing a different exploit once you know a vuln to be workable is not credit-able. Only fully independent discovery/implementation is. |
||
| − | 1. without size : |
||
| − | I assembled your payload with gas then tried to upload it at 0x09000000 and start arm7_go. |
||
| − | It did nothing. |
||
| − | 2. with size before : 0x00000048 then your payload uploaded at 0x09000000. |
||
| − | arm7_go => it crashed my ipod 2G. |
||
| + | I believe you now, but I'm a little surprised you don't have hashes. Your "exploit" is quite a bit different, and theres no way you would've wrote something that complicated after seeing the simplicity of rain. jkjk, nice job guys, and feel free to add your name and a writeup to the [[IBoot Environment Variable Overflow]] page --[[User:Geohot|geohot]] 21:53, 7 July 2009 (UTC) |
||
| − | I hope it can help. I am continuing my reasearches. |
||
| − | |||
| − | ~[[User:pod2g|pod2g]] |
||
| − | |||
| − | ==How do you pass the bootrom RSA checks?== |
||
| − | I've noticed that the exploit is at the iBoot level. So how do you (or the Dev-Team) pass the bootrom RSA checks? |
||
| − | |||
| − | ~[[User:Oranav|Oranav]] |
||
| − | |||
| − | ==RE: How do you pass the bootrom RSA checks?== |
||
| − | I do not know how it is done, but taking the screenshot on the latest devteam blog post, they have found a way to do so. |
||
| − | |||
| − | == RE: RE: How do you pass the bootrom RSA checks? == |
||
| − | |||
| − | Okay, as to MuscleNerd's redsn0w demo, it's pretty yellowsn0w like - you have to let the bootrom sigchecks pass, and then use the exploit every time the device boots. Pretty annoying, but that's the only option without a way to pass bootrom sigchecks. |
||
| − | |||
| − | ~[[User:Oranav|Oranav]] |
||
| − | |||
| − | == Wel... == |
||
| − | |||
| − | They noted they are looking for a way around that. |
||
Latest revision as of 21:53, 7 July 2009
Vulnerability vs. Exploit and Credits
@Chronic: I'm fine with you adding that you found it independently, but you have to be careful with the wording in general. It seems there are a great deal of misusages of the word "exploit" vs. vulnerability in this community. So if you don't mind, I'd like to clarify:
A vulnerability is the actual bug/security hole, whereas an exploit is the actual implementation which allows one to exploit the vulnerability.
For instance in the following sentence from the wiki: "The actual exploit is that, in the iPod Touch 2G 2.1.1 firmware, they left behind two commands: arm7_stop and arm7_go", the word "exploit" is not used properly. You are here talking about the vulnerability, not the exploit.
In my opinion, credits for vulnerability and exploit should be separated in general (I'm not talking about this one in particular, but I'm talking about vuln/exploit in general). One can find a vulnerability without exploiting it (because he doesn't want to, doesn't have the time, or it's too complicated and he doesn't manage actually to exploit it), and likewise someone can implement an actual exploit without discovering the initial vulnerability. IMHO, most of the time, the exploit is where the skills really are, because it's one thing to understand why something is a security vulnerability, it's often another to make it actually real with a POC code (because of sanity checks, checking, filters and so on). Although sometimes, I do agree that finding the vulnerability itself requires mad skillz (as an example, prop' to Bleichenbacher for finding his RSA attack), it is my belief that most of the time, the exploit is where the difficulty lies.
Anyway, I think this page contains misusage of the word exploit, and other pages too, and I just wanted to point it.
Theres one thing to be said for finding a vuln and seeing it crash, sure, thats usually not where the skill is and I'm not sure how much credit it deserves. But after an exploit is out using the vuln, it's a lot easier to get yourself to write another exploit since you have confirmation that the vuln is exploitable. The iBoot envvar one happened to be reasonably easy to find yet reasonably hard to exploit. If you really had your exploit working pre ra1n then props. But if you wrote an exploit post ra1n it's a lot easier knowing that this vuln can work. --geohot 18:44, 7 July 2009 (UTC)
iZsh, when I wrote this article I was a little less experienced, and have adjusted it a bit. That being said, if you check the chronic dev google code svn, you will see that I did implement it in a payload called "0wnboot". But yes, I did confuse the "exploit" and "vulnerability" definitions. ChronicDev 19:16, 7 July 2009 (UTC)
@geo: I can ensure you we definitely found it independently and implemented way before you released purplera!n. And I agree that re-implementing a different exploit once you know a vuln to be workable is not credit-able. Only fully independent discovery/implementation is.
I believe you now, but I'm a little surprised you don't have hashes. Your "exploit" is quite a bit different, and theres no way you would've wrote something that complicated after seeing the simplicity of rain. jkjk, nice job guys, and feel free to add your name and a writeup to the IBoot Environment Variable Overflow page --geohot 21:53, 7 July 2009 (UTC)
