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"
Caique2001 (talk | contribs) |
Caique2001 (talk | contribs) m |
||
Line 59: | Line 59: | ||
:From a more 'outside' point of view: I did never feel this placed was biased against the dev team. It was just about letting people know what's going on and what's behind the scene. Something which was missing on dev teams site. Again: Clear communication is people's friend. You could have said, ''this'' is what we give you and ''the other stuff'' we are keeping secret, for ''these'' reasons. But looking on your blog was often looking on a mystified place. Giving a feeling of people self-praising themselves. And exactly this has been stopped by theiphonewiki. So it was not ''biased'' against dev team, but furthermore a correction of misled communication policies. To give an another example: Even now, your progress concerning 3G software unlock is not quite clear. What's wrong in communicating you could not run patched code? Do you fear disappointing people? You should focus on people that could work at the same level like you if they would belong to the ''inner circle''. Clearly communicate to them. They are not just 'curious', they could speed up progress. You don't want this, that's fine. But don't think you're better than the ordinary world. -caique2001- |
:From a more 'outside' point of view: I did never feel this placed was biased against the dev team. It was just about letting people know what's going on and what's behind the scene. Something which was missing on dev teams site. Again: Clear communication is people's friend. You could have said, ''this'' is what we give you and ''the other stuff'' we are keeping secret, for ''these'' reasons. But looking on your blog was often looking on a mystified place. Giving a feeling of people self-praising themselves. And exactly this has been stopped by theiphonewiki. So it was not ''biased'' against dev team, but furthermore a correction of misled communication policies. To give an another example: Even now, your progress concerning 3G software unlock is not quite clear. What's wrong in communicating you could not run patched code? Do you fear disappointing people? You should focus on people that could work at the same level like you if they would belong to the ''inner circle''. Clearly communicate to them. They are not just 'curious', they could speed up progress. You don't want this, that's fine. But don't think you're better than the ordinary world. -caique2001- |
||
:: Well it is biaised. See how the blog post began "I see a real problem with the iPhone hacking community. Most of the knowledge about the iPhone is somewhere within the dev team". How can you get more biaised than that, and why is it a problem btw ? To refer to your previous sentence, who do you think you are to dictate our agenda and the how and when people should document their work ? I have no problem to work with many people - note that coming around yelling "ohai, that's the the way you should work kthx" isn't the best way to be integrated in any team though (works well IRL too). Oh, and we can run patched code. But the question was flawed. Zf |
:: Well it is biaised. See how the blog post began "I see a real problem with the iPhone hacking community. Most of the knowledge about the iPhone is somewhere within the dev team". How can you get more biaised than that, and why is it a problem btw ? To refer to your previous sentence, who do you think you are to dictate our agenda and the how and when people should document their work ? I have no problem to work with many people - note that coming around yelling "ohai, that's the the way you should work kthx" isn't the best way to be integrated in any team though (works well IRL too). Oh, and we can run patched code. But the question was flawed. Zf |
||
− | :::I didn't dictate how anybody should work. Work as you like and as you belong to. I just tried to explain to you, why there could be some problems in the way you communicate. You do good work, btw. If I should have gone |
+ | :::I didn't dictate how anybody should work. Work as you like and as you belong to. I just tried to explain to you, why there could be some problems in the way you communicate. You do good work, btw. If I should have gone too far with my statements, I apologize. Have fun. -caique2001- |
::The stuff we keep secret, we keep secret for a reason. Other posts from you seem to indicate you understand why. The stuff we release, we release when it's nice and tested. Rather than document the how's and why's of what we've done, we'd rather move to the next challenge (and there are plenty of them). It's really that simple. Nothing sinister or dramatic. It's as simple as "it's fun to do, not fun to document". - MuscleNerd |
::The stuff we keep secret, we keep secret for a reason. Other posts from you seem to indicate you understand why. The stuff we release, we release when it's nice and tested. Rather than document the how's and why's of what we've done, we'd rather move to the next challenge (and there are plenty of them). It's really that simple. Nothing sinister or dramatic. It's as simple as "it's fun to do, not fun to document". - MuscleNerd |
||
Revision as of 14:04, 3 August 2008
What is more important, is the code before 1800587C.
Compilers translate actions like
- if (condition is good)
- then
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.
Maybe the original pseudo code is as follows:
sig_check_result = do_check(important args); ... if (sig_check_result == 0) everything goes fine ... ... a.s.o
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?
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>
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
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.
seriously?
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.
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.
Peace, ChronicDev
This is not about me wanting to keep this stuff secret, it's about what's efficient. I've already said that we don't have time to document them, but that we'll probably eventually get around to it. It just seems like a waste of resources to have anyone who is capable of reversing what we've done actually doing so, when there are so many other things that need looking at that the devteam could never even think of having the time to do. Why reverse something that will eventually be documented when Apple's stuff is sitting there and we all know it will never be documented?
--pumpkin
I strongly disagree. Let's take the example of zero-g, this little application, which unlocks at least 2G capabilities for a couple of people. Several people asked for the source code. Including me. With the effect of not even getting an answer. Oh, no, there is an answer, which IMHO is extremely arrogant, something like if you know what's going on, it's not much different from lamesaft. Oh, yeah, funny, funny. Lamesaft with size of ~400 bytes not much different to zero-g having ~1000 bytes. To go further, I would have to reverse the code of zero-g. Not that this is difficult, but I don't have the time and I am not amused about being forced doing so. To sum it up: A lot of people are pissed off of the dev team. And it is not, that there are no reasons for. And it's not, that the dev teams work would not be really cool. It's just behavior and communication, which is inappropiate and partially premature. -caique2001-
Bladox asked specifically to keep that code private. They (and we) do not wish to see more chinese crap coming out, thinking they have the ultimate solution because it worked for 2 minutes on their phone, resulting in more scams and legal risks. That network attack will be throughly documented, in due time (i.e. when it's not worth making a scam out of it any longer). And no, the previous comment wasn't really funny, it's actually very true. So rather than trying to understand how that thing works (as we stated previously, it doesn't), you should focus on other more interesting issues, such as issues that can be solved. -Zf
to caique2001: we realize that from the outside it must look like we're secrecy-loving clock-and-dagger assholes basking in our own knowledge, but there really are good reasons not to release stuff. when you're working against apple, whose only goal with respect to us is to patch up any vulnerabilities that are found, documenting those vulnerabilities is just making it easier for them to fix them. we don't really care if it makes us unpopular, but it means that more people can reap the benefits of the vulnerabilities for longer. a few legitimately curious people such as yourself will not have the source code, but honestly, is it that important?
- If you clearly communicate - and I interprete your statement now as having done so - this is okay. There is a tradeoff between releasing information and let people participate and keeping things closed to not let Apple know to much. Everybody understands that. But it's exactly the last phrase, which pisses people off. Was this really necessary? Who do you think you are? -caique2001-
- Pumpkin is a nice vegetable, and IMHO he just meant that having the source code isn't that important. Not that you are important, but I don't think anyone around is, so don't take it in a personal way. Zf
throwing it out there
I like what Zf said. I would like to branch off one of his last statements by saying, if I am ibterested in looking into this, then why criticize me for doing so...I don't understand, no offense, but why do you criticize people and not actually correct them? for example, on URC, I was laughed at for thinking that there was a hardware method for dumping the 3G booteom. I asked them to correct me? and they "didn't want to contribute to geohots ego boost"....I mean...that is like saying that someone is stupid because they don't know where the holy grail is but you won't say where it is, except in that case you would be being arrogant
No, that's just saying that my contributions here will be limited to drama & troll, because that place was biaised against the dev team from day one (see initial blog post, Constitution and subsequent revisions), so I don't see why I should feel welcome here, nor be useful. - Zf
- From a more 'outside' point of view: I did never feel this placed was biased against the dev team. It was just about letting people know what's going on and what's behind the scene. Something which was missing on dev teams site. Again: Clear communication is people's friend. You could have said, this is what we give you and the other stuff we are keeping secret, for these reasons. But looking on your blog was often looking on a mystified place. Giving a feeling of people self-praising themselves. And exactly this has been stopped by theiphonewiki. So it was not biased against dev team, but furthermore a correction of misled communication policies. To give an another example: Even now, your progress concerning 3G software unlock is not quite clear. What's wrong in communicating you could not run patched code? Do you fear disappointing people? You should focus on people that could work at the same level like you if they would belong to the inner circle. Clearly communicate to them. They are not just 'curious', they could speed up progress. You don't want this, that's fine. But don't think you're better than the ordinary world. -caique2001-
- Well it is biaised. See how the blog post began "I see a real problem with the iPhone hacking community. Most of the knowledge about the iPhone is somewhere within the dev team". How can you get more biaised than that, and why is it a problem btw ? To refer to your previous sentence, who do you think you are to dictate our agenda and the how and when people should document their work ? I have no problem to work with many people - note that coming around yelling "ohai, that's the the way you should work kthx" isn't the best way to be integrated in any team though (works well IRL too). Oh, and we can run patched code. But the question was flawed. Zf
- I didn't dictate how anybody should work. Work as you like and as you belong to. I just tried to explain to you, why there could be some problems in the way you communicate. You do good work, btw. If I should have gone too far with my statements, I apologize. Have fun. -caique2001-
- The stuff we keep secret, we keep secret for a reason. Other posts from you seem to indicate you understand why. The stuff we release, we release when it's nice and tested. Rather than document the how's and why's of what we've done, we'd rather move to the next challenge (and there are plenty of them). It's really that simple. Nothing sinister or dramatic. It's as simple as "it's fun to do, not fun to document". - MuscleNerd
- Well it is biaised. See how the blog post began "I see a real problem with the iPhone hacking community. Most of the knowledge about the iPhone is somewhere within the dev team". How can you get more biaised than that, and why is it a problem btw ? To refer to your previous sentence, who do you think you are to dictate our agenda and the how and when people should document their work ? I have no problem to work with many people - note that coming around yelling "ohai, that's the the way you should work kthx" isn't the best way to be integrated in any team though (works well IRL too). Oh, and we can run patched code. But the question was flawed. Zf
to whomever came before this last Zf comment: we criticize because it feels like a waste of time. sure, you're welcome to do whatever you like with your time, but we're criticizing your choice of what to do with your time, as we feel it's useless to have you reverse what we reversed when we eventually plan on just writing it up. the most we can do to "correct" with that form of criticism is try to justify why we think you're wasting your time, when you could very well be doing things that are more helpful to the community. For example, everyone and their mother has been asking me for a Safari file:// url patch, but I simply haven't had the time recently. Why must it be me? Surely someone else who is spending their time reversing our hacks has the skills to patch a couple of bytes here and there to make life easier for many people? note that if you were reversing some secret hack that someone had leaked from the devteam I would feel differently, but pwnage is out and available at no cost to everyone, so the only product of your work is going to be improved understanding of our technique (a noble goal). We tend to be pragmatists, though, and as much as I'd love to be able to poke around at inane frameworks on the phone, for example, I prefer to use the little free time I have to do something generally useful to the public. - pumpkin