Talk:Research: Pwnage Patches

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-