Free Soft
Oct 28
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

Oct 28
yiPhone and otherwise
Posted by George Hotz in versis, dfu, binary file, filesystems, phe, iboot, file formats, mascot, 3g, peoe, pers on 10 28th, 2008| icon3
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

Dec 4
I know I've been silent for a while on the Tap Tap front, but now I can break the news! Tap Tap Revolution has been bought by a new company called Tapulous, and they've hired me on as a developer to maintain TTR.

Suffice it to say, their push for more features definitely works out better for you guys. Here's a low-quality leaked video demonstrating the sweet new features and look:



Check out the rest of this post for some exclusive screenshots.

Read the rest of this post


Tagi: tap tap, iphone, frt, low quality, new features, revenge

Dec 4
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

Dec 4
I'm going to address the two comments I received in this post. This basically has nothing to do with Linux, and more to do with iPhone hacking. There's a lot of confusion around with the jailbreak/unlock. The two comments basically hit upon the main points. The main confusion centers around the fact that when you buy an iPhone, you're not just getting a computer, you're getting TWO computers.

What I'm interested in is the S5L8900, the thing that runs the iPhone software. There is another device called the commboard, which has its own processor, nonvolatile memory, boot sequence and everything. It's barely an oversimplification to state that the system board (the S5L8900) and the commboard can only communicate with each other over a serial UART. That is, the only way the system board can control the commboard is with human-readable AT commands! Not very low level at all; they're not very integrated. Being able to hack kernel mode code like iBoot does not give us any more access than we had through minicom on a jailbroken iPhone.

kavkan asked me if iPhone Linux would obviate the unlocks. He then started talking about putting on third-party applications, etc. Putting third party applications on your iPhone is usually referred to as jailbreaking: stuff we do on the S5L8900. When we say unlock, we're usually mean a SIM-unlock. That necessarily means breaking a whole other, entirely distinct, set of security that's on the commboard. A jailbreak makes it easier to do that (because you can now talk to the commboard with that serial UART I discussed earlier), but it's entirely separate.

marc asked me about "bootloader corruption" as it pertains to basebands. As I said earlier, the bootloader I am talking about is on the S5L8900. The baseband/commboard has its own bootloader and its own non-volatile memory (also NOR flash, probably the same bit of flash its bootloader and firmware sits on too). The recovery mechanism on the baseband is far less robust than the one on the S5L8900. The only sure way seems to be using that hardware testpoint to force it to accept a new bootloader, and even that can be defeated by carefully crafting the NOR contents. In other words, it sucks.

In addition, a lot of the problem is due to bad software overwriting the seczone with bad data, stuff that's unique to your phone. Therefore, information is irretrievably lost and there may not be a way to recover.

The disclaimer is, of course, I'm not a baseband expert. This stuff is only what I've surmised by hanging out with some of them. It's kind of funny. On the dev team, w___ and Zf (they're baseband guys) and I were talking about how little we each know about the others' work. We do pretty much the same work, but on different platforms. After I explained what we do on the S5L8900, I think w___ said that he did the same thing "only on the baseband, you have a man sitting on top that does stuff to you for unknown reasons". And for the S5L8900 people, we have a little black box connected to us that either magically works and lets us call people... or not.

Tagi: kernel mode, volatile memory, mode code, boot sequence, jailbreak, uart, two computers, iphe, iboot, firmware, sim, third party, linux

next >