Exploits and Hackers via Stonelaughter
The life of the hacker is a mysterious one to most people and I'm no exception. So - being a person who likes to jailbreak his iPhone when he can, and someone who has a little computer knowledge on various platforms, I decided to have a look around and see what I could find out.
So it turns out that what a hacker spends his hack time doing is simply playing with his target device. A lot. When I say playing, I don't mean surfing the web with it or whatever; I mean connecting it to various computers in various ways, sending commands to it by various means, sending nonsense to it to see if it interprets it as NON nonsense and so on. The end purpose of all this is to see if there are any mistakes in the device's underlying systems which could be used to make the device lose control of itself.
In the Hacker's world, anything that makes his target device crash, or reboot itself, or a program fail, is a GOOD thing; it's his way to try to gain control over the device. Let's look a little deeper.
A crash is a computer's way of dealing with something it hasn't been programmed for. The programmer tries like crazy to cover all eventualities and make sub-programs which will deal with them in a nice clean way. Sometimes he fails; and that's when the operating system takes over and says "whoa that doesn't make sense, let ME deal with it". Usually by closing down the offending program and losing all the work you did in it. However, when the program which gets confused is the operating system itself, there's very little left - so the programmer who wrote it sends the execution to an "Exception routine" which usually makes a record of the state of the computer at the time (CPU registers, memory contents, the address at which the exception occurred, etc) and then either sits in a "failed" state or reboots itself. This puts the computer back in a known state so that it can start work again. The record of what was happening when the crash occurred enables programmers to figure out what caused the crash and repair it. Or exploit it.
So - how does an exploitable crash help the hacker? Well - when an OS crashes, it has basically lost control of the hardware. Usually, while an OS is running, it has absolute control over what happens to the files, hardware and memory contents of the computer; it controls what and who are allowed access to which resources in the machine. When it loses control, it is sometimes in a state for a short period where execution can be redirected to anywhere the hacker likes. When this occurs, the hacker sees the signs and writes a program which deliberately induces the crash, after setting up the redirection to his own program. So for instance, in the case of the JailBreakMe.com (Star) jailbreak, a PDF file malformed in a particular way caused the routines in iOS 4.0.1 and lower to fail and leave the computer in an uncontrolled state (in one way or another). The jailbreak program was loaded from a website and run; and I assume that what it did was immediately download a deliberately malformed PDF file from the website and redirect the crash-handling part of iOS 4.0.1 into itself. It would then arrange to use this state to gain access to the phone as the administrator or "root" user. Once a person has access as a root user, he can do ANYTHING. With this access, the program would then set up the phone such that the user can do things which the phone maker did not intend; such as for instance loading themes onto the iPhone or adding applications from sources not digitally signed by Apple.
Examples of the sorts of things which can be utilised by hackers are:
* Buffer Over/Underruns - when a program overfills a buffer by mistake, or tries to take out more values than a buffer contains;
* Negative numbers being returned to a program which expects only positive numbers;
* Pointers pointing to non-existent or protected memory areas; or string length indicators being negative
etc etc etc. All these conditions are the sorts of things which the programmer would have written routines for, had he thought they were possible - having made the decision they were impossible (or having not even thought of them) the program cannot continue to function when they occur and therefore its results and execution path cease to make sense. The operating system either fails completely and goes to its "complete crash" mode or detects the condition and closes the program which crashed. When the OS retains control the condition is only of use to a hacker trying to gain access to the program which crashed; however when the OS fails completely, the hacker begins to get REALLY excited.
