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.
Thursday, July 31, 2008
Saturday, July 19, 2008
How to fix a bricked iPhone
So how did I manage to FIX the problem I mentioned earlier? The reason I was so vague on the details is that I used a confidential iBoot vulnerability that we didn't want Apple to know even existed! This allowed me to bootstrap openiboot directly from a stock iBSS that was loaded through DFU mode. I still can't tell you exactly what it is, but since geohot already leaked the existence of it, I figure I can tell you it exists and is what I used. :)
Then, it was a simple matter of using openiboot's NOR engine to restore everything. I even can use the new image list parser and AES engine to have a very nice high level interface to the image list, allowing me to "pwn" just with openiboot; no ramdisk futzing around!
The AES code has been in SVN for awhile, but to anyone following jailbreaking news, it's probably obvious why I suddenly, out of the blue, decided to reverse it and write it. Haha. So the night that I committed the AES code, is the night the Dev Team first decrypted the new img3 shit. :)
Then, it was a simple matter of using openiboot's NOR engine to restore everything. I even can use the new image list parser and AES engine to have a very nice high level interface to the image list, allowing me to "pwn" just with openiboot; no ramdisk futzing around!
The AES code has been in SVN for awhile, but to anyone following jailbreaking news, it's probably obvious why I suddenly, out of the blue, decided to reverse it and write it. Haha. So the night that I committed the AES code, is the night the Dev Team first decrypted the new img3 shit. :)
Thursday, July 10, 2008
Conclusive proof that there is no way to (accidentally) brick s5l8900
In the process of testing NOR, I did a pretty lulzy thing. Remember what I said earlier about the memory controller possibly ignoring the first 4 bits? Well, the NOR device ignores the top 12 bits, since it's only 1 MB in total size. This makes a lot of sense. All the designers have to do is basically not wire up some parts of the address bus. So whether you try to address 0x0 or 0x100000 on the NOR, it looks the same to it.
The problem came about because I attemped to add too many images to NOR; a few 140 KB iBoot images can add up pretty quickly. The last one I added ended up shooting into the range reserved for NVRAM (at the end of NOR) and then "wrapping around" to clobber SysCfg, IMG2, and part of the LLB. =P
Hahaha, that's the equivalent of shooting yourself simultaneously in every vital organ. SysCfg stores your SERIAL NUMBER and other unique, irreplaceable pieces of information. The NVRAM contains information iBoot needs to boot up the kernel. The LLB is the thing that securebl tries to load in order to access everything else on NOR and bootstrap iBoot. As the coup de grace, IMG2 contains information that allows the LLB and iBoot to find where the Img2 data starts, so that they can be loaded. This mistake basically was the equivalent of erasing the entire NOR: Every single piece of information on it was rendered unusable. :P
Luckily, as the first test of my NOR driver, I had made a dump of my original NOR, so I was able to restore the SysCfg information. The interesting bit about all this is that you don't even have to do a restore and lose all your data on the NAND even, if you're clever. What I did was let iTunes talk to DFU mode to get into an iBoot. The iPhone actually has a pretty standard DFU mode, as defined by the USB standard. It reports itself as having the correct class, and OpenMoko's dfu-util manages to get, well, something with it. It successfully uploads the iBSS 8900 file (looking at a USB dump, it looks like just the entire file with the 8900 header, signatures, certificates, etc.) but reports that the firmware is corrupted. So at least it seems to use standard status indicators, etc. However, since I couldn't get dfu-util to work, I just used iTunes and pulled the cable out right after it finishes uploading the iBSS. DFU mode doesn't actually change the NOR, it just loads iBSS into memory and executes it. So after this process is done, iBSS will be loaded and you can connect to it via iBooter.
If you had pulled out the cable just a little too late, you can even see the commands iTunes executed on iBSS in the scrollback, Like setpicture and bgcolor. =P
Using the loaded 1.1.4 iBSS, you can bootstrap the necessary actions to restore your NVRAM from backup. I will talk about that in more detail in a future post. But the upshot is, even if you complete kill your "bootloader", and indeed, everything you can possible write to on the iPhone, you can still get things back to normal. :)
Unfortunately, I probably won't have a chance to work on iPhoneLinux stuff much this weekend. I have already been activated by the Dev Team because you-know-what is happening. Time to hax.
The problem came about because I attemped to add too many images to NOR; a few 140 KB iBoot images can add up pretty quickly. The last one I added ended up shooting into the range reserved for NVRAM (at the end of NOR) and then "wrapping around" to clobber SysCfg, IMG2, and part of the LLB. =P
Hahaha, that's the equivalent of shooting yourself simultaneously in every vital organ. SysCfg stores your SERIAL NUMBER and other unique, irreplaceable pieces of information. The NVRAM contains information iBoot needs to boot up the kernel. The LLB is the thing that securebl tries to load in order to access everything else on NOR and bootstrap iBoot. As the coup de grace, IMG2 contains information that allows the LLB and iBoot to find where the Img2 data starts, so that they can be loaded. This mistake basically was the equivalent of erasing the entire NOR: Every single piece of information on it was rendered unusable. :P
Luckily, as the first test of my NOR driver, I had made a dump of my original NOR, so I was able to restore the SysCfg information. The interesting bit about all this is that you don't even have to do a restore and lose all your data on the NAND even, if you're clever. What I did was let iTunes talk to DFU mode to get into an iBoot. The iPhone actually has a pretty standard DFU mode, as defined by the USB standard. It reports itself as having the correct class, and OpenMoko's dfu-util manages to get, well, something with it. It successfully uploads the iBSS 8900 file (looking at a USB dump, it looks like just the entire file with the 8900 header, signatures, certificates, etc.) but reports that the firmware is corrupted. So at least it seems to use standard status indicators, etc. However, since I couldn't get dfu-util to work, I just used iTunes and pulled the cable out right after it finishes uploading the iBSS. DFU mode doesn't actually change the NOR, it just loads iBSS into memory and executes it. So after this process is done, iBSS will be loaded and you can connect to it via iBooter.
If you had pulled out the cable just a little too late, you can even see the commands iTunes executed on iBSS in the scrollback, Like setpicture and bgcolor. =P
Using the loaded 1.1.4 iBSS, you can bootstrap the necessary actions to restore your NVRAM from backup. I will talk about that in more detail in a future post. But the upshot is, even if you complete kill your "bootloader", and indeed, everything you can possible write to on the iPhone, you can still get things back to normal. :)
Unfortunately, I probably won't have a chance to work on iPhoneLinux stuff much this weekend. I have already been activated by the Dev Team because you-know-what is happening. Time to hax.
Wednesday, July 9, 2008
State of iPhone Linux
So the methodology has currently been trying to proceed as quickly as possible, trying to get every device working and aiming for breadth instead of stability. This allows me to do more high-value tasks like reverse engineering, rapidly gaining understanding of the platform instead of just getting bogged down debugging every single thing. Unfortunately, we're paying a bit for it now as I try to get things into gear to put together applications.
First thing is, I don't really trust the current memory structure. For one thing, it's WEIRD. It seems like even if I turn the MMU off, 0x0 is still mapped to 0x18000000. I know the MMU is working, somewhat, because if I allow the heap to run into the place I put my pagetable, bad things happen. =P I understand there's not going to be enough devices or memory to fill out the entire 32-bit address space, though, so maybe there was already some sort of static mapping. I also believe 0x9000000 (the range used by iboot's file transfer facility) is mapped to 0x18100000. That is, 0x0 == 0x80000000 == 0x18000000. The problem is that there are no such mappings in the page table. 0x80000000 to 0x180000000 is set cacheable and bufferable, but is identity mapped. Anyone have enough experience with the hardware to tell me if this makes sense? I mean, maybe it's just that the top 4 bits are just completely ignored by the memory controller.
Second thing is, sometimes I get random freeze-ups and I don't know why. Maybe I'm just hallucinating or screwing up somewhere, or maybe it's just me failing at C (wouldn't be the first time this happened). Anyway, the upshot is, I want to go back through and clean up/refactor the code into its final form. I tried to follow best programming practices as much as possible the first time around, but sometimes it just was too inefficient to do so when dealing with only half-way reverse engineered device drivers.
The third thing is what I'm working on currently. I need openiboot to replace iBoot. I currently have written a pretty simple chainloader. All it does is warm up all the devices as usual, and then load iBoot from NOR and then jumps to it. iBoot is relocateable and should be able to get itself to the right place. Now this works fine from a copy of openiboot that is started from iBoot using "go", but after I flash openiboot onto the "ibot" image in NOR, the device goes straight to DFU. Now either I'm screwing up hardware initialization or there is some additional verification (checksums, probably not signatures) done before LLB wants to load iboot. It may be that the latter is more likely, since I end up in DFU mode rather than a hung device. Not sure if the device is intelligent enough to recognize a failed boot if I don't say, update the powernvram.
After I get this working, the next thing is to see if the gamma table stuff works then (and if not, fix it). After that, the boot menu I talked about can be written. The next thing I want to work on is NAND FTL. That's the last piece before we reach the end of the "openiboot" phase and can move into the Linux phase. Pretty much all the drivers people expect will be ready and the fun can begin.
I know it seems like we're still very far, but I think we've made very concrete and tremendous progress in a fairly reasonable period of time. A lot of things are now clear and the biggest obstacles are not Apple's protections, or a lack of understanding, but merely my own stupid mistakes and typos.
Speaking of horribly stupid mistakes, my next post will be the story of how I almost bricked my phone yesterday night (but not really :P).
First thing is, I don't really trust the current memory structure. For one thing, it's WEIRD. It seems like even if I turn the MMU off, 0x0 is still mapped to 0x18000000. I know the MMU is working, somewhat, because if I allow the heap to run into the place I put my pagetable, bad things happen. =P I understand there's not going to be enough devices or memory to fill out the entire 32-bit address space, though, so maybe there was already some sort of static mapping. I also believe 0x9000000 (the range used by iboot's file transfer facility) is mapped to 0x18100000. That is, 0x0 == 0x80000000 == 0x18000000. The problem is that there are no such mappings in the page table. 0x80000000 to 0x180000000 is set cacheable and bufferable, but is identity mapped. Anyone have enough experience with the hardware to tell me if this makes sense? I mean, maybe it's just that the top 4 bits are just completely ignored by the memory controller.
Second thing is, sometimes I get random freeze-ups and I don't know why. Maybe I'm just hallucinating or screwing up somewhere, or maybe it's just me failing at C (wouldn't be the first time this happened). Anyway, the upshot is, I want to go back through and clean up/refactor the code into its final form. I tried to follow best programming practices as much as possible the first time around, but sometimes it just was too inefficient to do so when dealing with only half-way reverse engineered device drivers.
The third thing is what I'm working on currently. I need openiboot to replace iBoot. I currently have written a pretty simple chainloader. All it does is warm up all the devices as usual, and then load iBoot from NOR and then jumps to it. iBoot is relocateable and should be able to get itself to the right place. Now this works fine from a copy of openiboot that is started from iBoot using "go", but after I flash openiboot onto the "ibot" image in NOR, the device goes straight to DFU. Now either I'm screwing up hardware initialization or there is some additional verification (checksums, probably not signatures) done before LLB wants to load iboot. It may be that the latter is more likely, since I end up in DFU mode rather than a hung device. Not sure if the device is intelligent enough to recognize a failed boot if I don't say, update the powernvram.
After I get this working, the next thing is to see if the gamma table stuff works then (and if not, fix it). After that, the boot menu I talked about can be written. The next thing I want to work on is NAND FTL. That's the last piece before we reach the end of the "openiboot" phase and can move into the Linux phase. Pretty much all the drivers people expect will be ready and the fun can begin.
I know it seems like we're still very far, but I think we've made very concrete and tremendous progress in a fairly reasonable period of time. A lot of things are now clear and the biggest obstacles are not Apple's protections, or a lack of understanding, but merely my own stupid mistakes and typos.
Speaking of horribly stupid mistakes, my next post will be the story of how I almost bricked my phone yesterday night (but not really :P).
Friday, July 4, 2008
LCD working! (sort of...)
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.
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.
Thursday, July 3, 2008
LCD status
Looks like the LCD initialization stuff wasn't as simple as I thought. Depending on the way you look at it, there are three or four major initialization steps for the display. The first step initializes the display controller chip, sets the clock and everything. The could of messages you see about the framerate and clock are from this step. The second step ought to initialize the framebuffer for the display controller. I've reverse engineered and implemented those two steps so far.
The third step is to communicate with the LCD panel itself, and likely configure it and configure the display controller for it as well. This is the infamous "merlot_init" function. I have no idea what merlot is (other than a wine variety). Could be the codename for the driver, or the display controller. Can't be for the LCD itself, since its design to hande many different panel types. It's a pretty funny name, though, so I've started working on syrah_init. Syrah, because the 2005 Dalla Vina vintage was an award-winner at the Spring Beer & Wine Fest that I went to last year.
The problem with merlot_init is that it uses GPIO, SPI, I²C as well as memory mapped registers to communicate with the panel and/or the display controller. That's almost every single bus on the iPhone, so basically I had to write drivers for those controllers as well before I could start on merlot_init. Those are now written; no idea if they work, but they're written. It's going to be a big pain in the butt to debug such a complicated driver. There's just too many things that can go wrong.
It's possible I might start implementing some of the PCF50633 (iPhone's power management unit) functionality. I can at least access powernvram (the general purpose memory registers on the PMU, really) pretty simply using I²C and I ought to be able to test that piece out anyway.
On another note, for the longest time I couldn't figure out what those gpmem registers did on the PMU. I reversed some code that manipulated them, but I couldn't figure out where the data was being used, etc. However, I didn't spend much time on it because I didn't think they were going to be very important for what I was doing (since their values don't affect the initialization of any of the other drivers). Well, last night I told MuscleNerd about this for some reason, and he pointed out that there's a command called "powernvram" in iBoot that, no less, attaches descriptions to every single one of those registers! They just keep track of boot failures and stupid stuff like that. It just goes to show that you can't spend TOO much time just doing static RCE. Sometimes you've got to fire up the actual application, or at least give the old ztringz a go. ;)
The third step is to communicate with the LCD panel itself, and likely configure it and configure the display controller for it as well. This is the infamous "merlot_init" function. I have no idea what merlot is (other than a wine variety). Could be the codename for the driver, or the display controller. Can't be for the LCD itself, since its design to hande many different panel types. It's a pretty funny name, though, so I've started working on syrah_init. Syrah, because the 2005 Dalla Vina vintage was an award-winner at the Spring Beer & Wine Fest that I went to last year.
The problem with merlot_init is that it uses GPIO, SPI, I²C as well as memory mapped registers to communicate with the panel and/or the display controller. That's almost every single bus on the iPhone, so basically I had to write drivers for those controllers as well before I could start on merlot_init. Those are now written; no idea if they work, but they're written. It's going to be a big pain in the butt to debug such a complicated driver. There's just too many things that can go wrong.
It's possible I might start implementing some of the PCF50633 (iPhone's power management unit) functionality. I can at least access powernvram (the general purpose memory registers on the PMU, really) pretty simply using I²C and I ought to be able to test that piece out anyway.
On another note, for the longest time I couldn't figure out what those gpmem registers did on the PMU. I reversed some code that manipulated them, but I couldn't figure out where the data was being used, etc. However, I didn't spend much time on it because I didn't think they were going to be very important for what I was doing (since their values don't affect the initialization of any of the other drivers). Well, last night I told MuscleNerd about this for some reason, and he pointed out that there's a command called "powernvram" in iBoot that, no less, attaches descriptions to every single one of those registers! They just keep track of boot failures and stupid stuff like that. It just goes to show that you can't spend TOO much time just doing static RCE. Sometimes you've got to fire up the actual application, or at least give the old ztringz a go. ;)
Subscribe to:
Posts (Atom)