Posted by George Hotz on under gizmodo, phes, recovery mode, iphone, possiblity, iboot, endpoint, dev team, 3g, bricks, date time, hack, protocol, fear, beta, truth | 
So I read
this on gizmodo. Here's the truth...
Post beta 4, the ramdisk hack stopped working. Sorry Zibri, guess you'll have to steal another exploit. They also changed the recovery mode USB protocol to use the control endpoint to send commands.
The possiblity of unlocking, which is very distinct from jailbreaking, is based entirely on the baseband bootloader. Apple doesn't appear to upgrade the bootloader on phones in the field, probably for fear of bricks. So any old iPhones out there today, regardless of version, can be unlocked.
The iPhone 3G uses a different bootloader, which I believe there aren't any known exploits in yet. So no unlock.
There is a known exploit in iBoot, on both the old and 3G iPhones. The "the specific date/time is not firm yet" pwnage tool will leverage it to jailbreak all 2.0 software iPhones, 3G and otherwise. Dev team, that date better be soon or I might just have to release
yiPhone. The iBoot exploit is yours, use it. You wouldn't want a repeat of ZiPhone now...
Tagi: gizmodo, phes, recovery mode, iphone, possiblity, iboot, endpoint, dev team, 3g, bricks, date time, hack, protocol, fear, beta, truth
Posted by George Hotz on under versis, dfu, binary file, filesystems, phe, iboot, file formats, mascot, 3g, peoe, pers |
I still can't believe how many people believed yiPhone. It's amazing how a couple lines of javascript(the counter) can piss so many people off. I was just trying to push dev to work a little harder ;-)
I have never done the jailbreaks for any previous versions of the phone, what makes you think this one would be different? I also like to think I have more honor than using someone elses exploit before they do. And really, who was the mascot in the picture? Yorro? Once he exists, maybe yiPhone will exist.
Also, heres why a certain person claimed the DFU was the key. You could, without any exploits, upload the 114 iBoot(even to the 3g), the 114 kernelcache(ok, this crashes on the 3g), and a hacked ramdisk. But the filesystems don't mount. And even if they did, you'd need a way around sig checking.
Here is a little program(with source of course) to run whatever you want at the DFU level; an implementation of the dev pwnage 2.0 exploit. Pass it a binary file, it will start executing at the start of the file(no file formats to deal with). I'll leave it to dev to explain the exploit used.
Tagi: versis, dfu, binary file, filesystems, phe, iboot, file formats, mascot, 3g, peoe, pers
Posted by planetbeing on under gamma table, th project, menu interface, byte values, iboot, lcd panel, two bits, kilobytes, svn, spi, init, linux |
After many frustrating hours debugging all the pieces that fit into this LCD driver, it now behaves as expected. Unfortunately, I still can't get the gamma table to install from a clean start-up (where openiboot powers down everything that iboot powers down before starting them back up). I think this is probably because the gamma table installation code that I reversed from iBoot is only designed to work in situations where the code is directly loaded from LLB. The other possibility is that I made a mistake somewhere in merlot_init. I know that the rest of my code is good because it generates the exact same register configuration that iBoot does. merlot_init is more difficult to diagnose because of all the SPI commands flying around. Most of them just read and write to registers on the LCD panel, though.
What's interesting about the gamma table installation function in iBoot is that it uses a custom, rudimentary form of compression. The gamma table is just a mapping from every R, G and B value (0 - 0xFF) to a range from 0 - 0x3FF. There are three table, one for red, one for green and one for blue. Each table has 0x100 4-byte values. That adds up to 3 kilobytes worth of tables! Since space on the NOR is at a premium, it's sensible that Apple use some kind of fast compression to store the gamma table data. Their compression encodes values two bits at a time, and takes advantage of the fact that each entry in the gamma table will be fairly close to the value of the last entry, just offset a little. They use the two bit control codes to select how to manipulate the differences. Iā??m not sure if this is any sort of standard compression, but I thought it was amusing that they had this in here. You can look in the
iPhone Linux SVN for the code.
Still, we have working code and just a relatively minor problem! I think that means we could probably start some sort of
logo contest. Here's how I think it will work: We need art for the bootloader menu interface. The art will naturally have to feature iPhone Linux, so that means that we also require a logo for this project. So we need the following things: A logo for iPhone Linux, and a logo (could be just a variant of the iPhone Linux logo) for openiboot (not sure what the canonical capitalization of that should be; we will probably use the logo as the reference). We also need art for the bootloader based on those logos. What I'm envisioning is just the logos, bracketed by arrows to make it obvious that you can select between them. Then, the standby key can be used to toggle through the various choices, and the home key will boot the selected one.
The winning set of artwork will be selected by
community consensus. The community is very small as of yet, so I'm sure it'll be easy to just to talk it over with everyone and decide what people like.
It's important to note that even if your logo is chosen, if someone offers us something prettier, we will switch, so don't do this if your feelings are easily hurt. =P
I really appreciate what artists do and the care and craftsmanship that they put into their work. You guys have a skill that I will never have and I know that it is a lot to ask to have you put that kind of work into something that might not even be used. However, I and many others have put analogous care into crafting the code for this project, and that is our salute to the community. So let's make something beautiful together.
To submit an entry, just contact me or cmw with it in some way, shape or form. Either on my gmail account (take a wild guess what my gmail address is :P), or on IRC, or here in the comments, or whatever. We'll see to it that everyone gets a chance to take a look at it.
Tagi: gamma table, th project, menu interface, byte values, iboot, lcd panel, two bits, kilobytes, svn, spi, init, linux
Posted by planetbeing on under th phase, th problem, cpu clock, clock cycle, random moments, bootstrapper, pseudo device, fashi, root filesystem, random data, random processes, iphe, aced, comete, iboot, own software, safe way, porti, copyright laws, qa |
SimilaritiesJailbreakBoth utilities jailbreak.
Payload mediumPrimary jailbreak payload is placed into iPhone memory for both jailbreaks
DifferencesTechniqueZiPhone uses, as the root filesystem device, a pseudo-device that provides a window to an arbitrary section of memory. This memory is not allocated or otherwise reserved by the operating system and hence will be used by other random processes in other random ways and will become more and more corrupted with every CPU clock cycle. The only safe way to use this is to mlock all memory used by the jailbreak binary as soon as possible, and then use data previously uploaded to flash. Anything else will cause either the jailbreak binary to crash at random moments or cause random data to be written to flash. I am not sure why Zibri elected not to implement ZiPhone in a safer fashion.
QuickPwn uses the same mechanism that Apple uses to send its update ramdisk. This memory is both allocated and reserved. It will not crash at random moments, or give you repeating BSD root errors. This is the way the XNU kernel is designed to use ramdisks.
LongevityZiPhone hinges on a BUG in iBoot that was quickly fixed by Apple.
QuickPwn uses an iBoot FEATURE that Apple cannot remove without rewriting their own software and undergoing lengthy QA. Even if Apple did change the architecture, it would be straight-forward to simply mimic what they do and adapt to it. The reason QuickPwn can do this is because it relies on a hardware exploit to bootstrap into this phase. Apple cannot fix this problem without changing the manufactured hardware.
EleganceZiPhone modifies an existing Apple ramdisk and ships it as a complete set.
QuickPwn contains all-original code and features a very tiny bootstrapper that allows it to use libraries and code that's already on the iPhone.
Not only does ZiPhone's distribution of Apple's binaries violate copyright laws, it also takes up a large portion of room on the ramdisk that could be used for the payload. Keeping its existing algorithm, ZiPhone would never have been able to install Cydia, for example. The maximum feasible ramdisk size is 32 MB; Cydia takes 13 and Apple's library take up a significant amount. With some work, Zibri could possibly make it just under the 32 MB limit, but with the large number of files in Cydia, and the large size of the corruptible area of memory, corruption would be inevitable.
Some history / A personal noteZibri claims to have "invented the ramdisk jailbreak". Even if this were true, it would have as much relevance to QuickPwn as the 1.0.2 jailbreak does: The techniques used are entirely dissimilar. Not a single step in the process is the same.
However, this is not even true. Before Zibri left, we already had a prototype ramdisk jailbreak in our SVN (which Zibri later leaked parts of). It was written by myself and stored under the very obvious name of "ramdisk-jb" and it contained a modified version of a launchd written by Turbo (who should be considered the father of the ramdisk payload). It basically untarred a SSH installation onto the rootfs. It was rudimentary, and required a lot of work to get up to production standards.
While it's obvious that Zibri has picked every bone of that SVN repository clean, I am puzzled why he did not learn from that example source code. It had mlock and it was written in proper C, unlike the rather make-do replacement of launchd with sh. Perhaps he did not understand the code.
A week before his release, we became aware that Zibri was going to write a ramdisk exploit. We considered racing him to it, but we were constrained by the fact that we had already publicized one working method of jailbreaking: The oft-loathed 1.1.3 soft-jailbreak, which we considered perfectly acceptable until the release of the SDK (we were not aware at the time the SDK release would take so long). In addition, 1.1.3 was a minor update and there was no reason people could not stay on 1.1.2 for awhile longer. The issue is that while a ramdisk jailbreak would certainly be easier and better, we would be burning this great exploit that allowed us to reliably decrypt ramdisks (which we had no other way of doing at the time).
Therefore, we chose not to build our own implementation and instead pursue Pwnage, a longer term project. It was ironic months later that Zibri came to flame us out about releasing the dual-boot method, accusing us of burning the exploit. It was amusing because it was so much lower value than the ramdisk exploit, which he was responsible for burning and really had no future prospects because of pwnagetool.
We are aware that the dual-boot method was the last remaining bit of non-public knowledge from our SVN that he had, and my belief was that the flame was caused by his soreness at losing his last chance at remaining relevant after the pmd ("ramdisk") vulnerability was patched.
Tagi: th phase, th problem, cpu clock, clock cycle, random moments, bootstrapper, pseudo device, fashi, root filesystem, random data, random processes, iphe, aced, comete, iboot, own software, safe way, porti, copyright laws, qa
Posted by planetbeing on under cpu caches, memory address, lcd driver, command processor, power c, static methods, wrg, address range, mmu, syrah, bgcolor, iboot, ibec, prob, typo, queue, gamma, ace, bugs, clock |
I had a lot of trouble getting the LCD driver to work. Everything seems to be fine except that when I try to write to the memory address range reserved for the LCD's gamma tables, it doesn't register. It's as if some clock or some device hadn't gotten turned on or something. Therefore, after loading openiboot from iBoot, the screen gets all screwed up.
However, if you load iBEC from iBoot, the screen doesn't get screwed up: you can still use bgcolor and everything works. I thought that meant at first there was something wrong with my LCD init code. I spent a frustrating day carefully auditing it for errors, and I did find two bugs that I fixed, but unfortunately it did not have any effect on the main problem. I got as far as I could with static methods so I decided to perform a series of experiments.
First, I had some trouble chainloading iBoot and iBEC from openiboot. There was a series of fails that I fixed along the way: trouble with USB send (just a silly typo in the client), trouble getting the resulting thing to execute in memory (you've gotta turn off the CPU caches, disable MMU and interrupts for it to work properly. It also can't be run as part of an ISR because, well, iBoot expects to be able to receive interrupts, so I had to move the command processor onto the main thread and just have the ISR queue up commands for the main thread to process). Anyway, those were eventually fixed.
My experiments showed that after openiboot did its inits, chainloaded iBoot and iBEC was unable to reinit the LCD properly (they had the same problem). I narrowed the problem down to the place in power.c where I "turn off" the LCD controller. This happened in the 114 iBoot, so I thought it was necessary. Analyzing the newer 2.x iBoots, that routine was actually removed. Since I am reasonably confident that my syrah_init is functionally identical to their merlot_init and this that power init that when present, causes LCD init to fail in all cases and when absent, allows LCD init to succeed in all cases, I'm pretty sure that's the problem.
So I went ahead and removed it. This may or may not mean I am actually depending on the iBoot that I chainloaded openiboot from for the LCD init. We'll see after I try to replace iBoot entirely in the bootchain.
Anyway, USB is solid as a rock now seemingly and chainloading seems to be working quite well. I'm actually able to load iBoot from NOR, patch it in memory, and then execute it from openiboot. This probably means I'm ready to try flashing the thing again.
Then we'll see how well it truly works.
Tagi: cpu caches, memory address, lcd driver, command processor, power c, static methods, wrg, address range, mmu, syrah, bgcolor, iboot, ibec, prob, typo, queue, gamma, ace, bugs, clock
