A
Friday, July 31, 2009
WRITING, DECISIONS, AND THINKING OUT LOUD
Okay people. I am trying to make a decision. I could use all of the input, advice and suggestions anyone has to offer.As most of you know I am working on writing my first book. After what seemed like hundreds of all-nighters, endless cups of coffee, and a million cigarettes, I was almost satisfied with [...]
LET?S TALK SOME SUMMER TELEVISION
[Now, before anyone yells at me! YES! I have been working diligently on my book. In fact, Chapter 10, 11, 12 and 13 are ALMOST finished and they will be posted in the near to immediate future. Just as soon as I make a few decisions.]That being said.Let’s talk some ‘Summer Television’ shall we?It’s pretty [...]
HAPPY FATHER?S DAY
Happy Father’s Day Everyone!!Especially to this guy:These are my favorite STORIES about my father! *** [click on the titles below] ***My Daddy And The SpiderWait! Isn?t that??My Daddy And 75 CentsMy Daddy And The TireMy Daddy And The BankMan I Am Glad That?s OverThese are my favorite VIDEO’S about my father! *** [click on the [...]
Thursday, July 30, 2009
THE VOICE(S) IN MY HEAD
[If you are looking for funny today?please just move along to the next blog!]Why is it that I find it easier to listen to [and even believe] the negative inner monologue that runs inside my head?Do you know that little voice that pipes in just to tell you all the bad things about yourself?Or am [...]
AS THE SAGA CONTINUES
[For those of you that read this blog, and have no idea what is going on over at Facebook, there is nothing for you to see here today. Please try again another day and hopefully you will find a post that is relevant.]As the ?Facebook Saga? continues, my personal profile page still remains disabled.It is [...]
SINGLE PARENT DISCRIMINATION
Warning!! This blog may contain several politically incorrect remarks. Please find another blog to read if you consider yourself a politically correct person (the irony is,that I am a Political Science Major.) Nice eh?
I have a few beefs and couple of bones to pick when it comes to the general treatment of Single Parents in this country (and I'm sure abroad.)Are we lesser beings? Ever feel as though you are at the bottom of the Sociotype Totem Pole? And why?? Because we believe the bull that we are fed.
The fact is, we work twice as hard as most families...The DINK's (Double Income No Kids),the Married with Children Types, Religiously Married with Children Types,or those whom are simply too Chic for kids! There are many more Sociotypes of course but these are the ones that really bug me!It's not their lives that I have a problem with. I envy most of them. It's their attitude.
How is it that we receive less respect for doing the job of a village,alone? You would imagine the opposite, but nope. Not gonna happen. Us, single mothers are often times seen as weak and needy and even more,a liability and risky investment. Yep, that's us,as we dustily sit upon the shelf,right next to the clearanced day old bread.
The thing that really chaps my hide is that Single Fathers seem to be treated in the exact opposite fashion. The are praised and admired. (This is all generally speaking of course, I realize the case is different for many.)
Have you ever been to a job interview when they carefully ask with a suspicious eye, "Tell me about yourself..." "What sorts of things do you do for fun...." or maybe they are more forward and just illegally and flat out ask if your married or have children. (It's happened to me several times, probably because they assume that some dumb single mom wouldn't even know that it's illegal or even care?) Of course once you fall into the trap and accidentally mention that you enjoy "Spending time with your Kids" (they notice the absence of the husband part.) Or maybe you just candidly answer the question, and then?....the tone changes. The interest and excitement that was on their face just seconds ago has now been traded in for pity and disappointment.
This, my friends is the Saga of the Single Mother. Who wants to hire woman who essentially has no back up for childcare? Who will inevitably need many sick days for sick children? Back to the 'poor investment' issue. Don't get me wrong though, good employers do exist! (Miss You Vicky and Victor!)
However,I am certain that I was not hired for several jobs that I have been more than qualified for,simply because of my social rank.
And Health Care? Don't even get me started,oh wait! I'm already started...
The discrimination I have seen over the last year and a half for being on Medicaid is unbelievable. My first Oncologist had the attitude that if I were to receive free Health Care, then I should receive the most basic or less than standard care. (The cheapest and least effective of course.)
He would not look me in the eye when we spoke and I felt the presence of death among me. His insensitive approach insinuated that he had already surrendered to the idea that I was not going to make it. Unsurprisingly, after 3 months on the WRONG chemo (the basic stuff), I had almost zero response. The tumors were almost exactly the same size. The words "Ms. Millet, I hate to tell you this,but it appears that you have not responded much to the A/C." The words echoed in my head. What? I AM THE PROBLEM? I didn't RESPOND? Funny how the way something is worded changes everything.I had become best friends with my toilet bowl for 3 months for nothing and in my opinion? All because I was on Medicaid.
I had known of other treatments available but he showed no interest in starting me on them, I had asked for Clinical Trials, but he made excuses. In my eyes? He was murdering me.
I immediately changed Oncologists and to my complete shock, I wasn't spoken to like I had the I.Q. of an Orangutan just because I was on Medicaid. A doctor who actually treated me like a person? I started a new treatment regimen and showed immediate improvement! Are we going to stand for this!? This kind of stuff is going on all over the world and when discrimination goes this far,it could mean a person's life!
If you have never experienced the pain and embarrassment of telling the Cashier at the Grocery Store that "It's an EBT Food Card." (Food Stamps), or if you have never been faced with the Horror of having to tell a Landlord that you are on Section 8 Housing (crossing fingers,toes and eyes just hoping that they will not look down on you and accept you),or if you have never had to encounter the flushed all over,color of of Fire Engine feeling of being told that your WIC check isn't good for THAT kind of Orange Juice or that you tried to cash it on the wrong day and therefore had to put all the groceries back....you are the lucky one!!!!
The brutal truth is that we have a hard time. We try so hard to better our lives for our children and ourselves but attitudes and circumstances can be stifling. I am curently trying to figure out how and where I will receive and pay for,childcare for my 3 children so I can attend College.It's just insane.
And then there are some callous people who dare go beyond just an attitude and would actually tell a Single Mother that she owes society because they are helping her or that she should send back the Christmas presents that the Doctors Office (yes,my Doctor is awesome) bought for her family. It's a good thing that some people care and that there ARE programs out there to help those seriously in need,but it is difficult to say the least at the same time.
You know, on the Housing program now, it is a requirement that you do 8 hours of Community Service a month if you are not working. No problem,it's just that...I don't believe that it prevents abuse.Those with no work ethic will simply claim disability for something as general as Depression, while those WITH a work ethic, struggle to find to find employment but in the mean time, must find a way to pay for day care while completing their community service on top of it.
Just a note (okay,it was more like a novel),to let you know that there is someone out there who cares, someone who has experienced the same things and someone who is FIGHTING for your rights as a Single Parent! That's why I'm going to Law School baby!
To protect those whom have had their basic Civil Rights violated. No more! Enough!
I will have more T-Shirts coming out soon. Let ya know as soon as it happens!!
QUICKOIB
Hey, I would just like to tell you about a project pH is working on called QuickOIB. It is an installer for openiboot that works on Mac OS and Linux. He also tells me that he is working on a Windows version.
I'm sure it'll be very useful to people wanting a quick way to get past the OpeniBoot stage and get directly to working with the Linux environment.
THE LOSERS TRAIN
Ever feel like you are perpetually stuck on a ride that you really would like to get off of? I have. Ever get the feeling that your life closely resembles that of a Hamster in a Cage? Me too.
Problem is,sometimes you don't know how to exit.What I am referring to is the 'Losers', you know who I'm talking about. You know the type. Come and go as they please.Can't hold a job. Prefer sleeping their car,or at your pad rather than 'wasting money on rent'? Sound familiar?
Maybe I'm kidding myself and I am the only one stuck in this diabolical amusement park designed specifically for my eternal misery.I highly doubt it though. I have met so many women with the same story.And why do these guys prey on single mothers? Why hurt our children? It is the most selfish,careless,insensitive thing I have ever witnessed.
The thing is,when I meet men that run away from their responsibilities,you know who I really get angry at? The parents. It makes me wonder what went wrong.How was this person not raised with the basic knowledge of respect and responsibility.But I have to admit from my own experiences,I have actually been personally abused by men that have no family history of abandoning their families or abuse.(at least not in their immediate family.)
Then many times,a woman gets the strength to get away,only to fall victim to another user,another loser. Same circumstances,only different scenery. How do we stop this? How can we rally together to save single mothers from this abuse,as extreme as that may sound,I feel it's sadly accurate.
It's a cycle.We,women need to believe in ourselves! Believe that we deserve better for us AND our children! It seems as though sometimes,our self-esteems' suffer so much damage from years of constant deterioration from our significant others that we actually start to believe their garbage,treating us as a landfill for all their emotional trash.
There is some good news.Usually women that get taken for are just kind-hearted and believe that there is good in everyone. The women who are attracted to men like this are attracted to them because they want to help them,because they believe that they can help them change! They fall in life with their potential and not who they are which always turns lethal for the relationship.
So,ladies,I have a new rule (okay,an old principal that I am trying to get back to again.)When meeting someone new,my belief is,that we pick our battles.Naturally,no one is perfect (another cop-out for falling for men like that.),BUT,if there is ANYTHING that you would change about that person,it's a NO!
If you think to your self "Well,when we get together,he will be happier and he is only explosive because of blah..blah..blah.", Or, "I really don't like his drinking,but he says he going to stop." Or, "I think he still has a thing for his ex-wife but once he spends more time with me,he'll forget all about her." Or, "Sometimes he seems to be insensitive to his children and mean to his mother,but he's just frustrated with his job."
Remember, how he treats children,his Mother,and his ex-wife...is how he is going to treat you!(even if right now he's "really nice".) And my last dead-giveaway that you are dating a loser is if they say "I'm not like those other guys." From my own experience,they've ended up to be the biggest jerks of all.
Try living on the edge. Next time,you may consider dating outside of your 'comfort zone',outside of your normal attraction.Someone completely opposite. You might give it a chance and find that the right person was always there...just waiting.It may seem foreign or weird at first,but it is just your brain adjusting to the fact that you DESERVE BETTER! (For those of you whom are in a relationship that is so perfect,you actually make others physically ill,this post was obviously not directed at you...any pointers though? =)
Wednesday, July 29, 2009
DEBIAN ON IPHONE LINUX
NAND writing is now semi-reliable (although one has to be VERY careful not to interrupt the device in the middle of a write operation), but it is enough to have something akin to a full-functional OS, backed by non-volatile storage.
People interested in the project should be familiar with the myriads of Linux "distributions" floating around. An operating system consists of two major domains: one is the kernel, which is what manages the hardware, and one is the userland which contains things like shells and other UIs, package managers, etc. Software that help users install and run useful programs. Ubuntu is a popular distribution that I run on my personal machine. Android could also be considered a distribution (though I believe it has some apparently messy kernel patches).
I decided that Debian would be an interesting thing to try, since we would then instantly have a userland and a pool of ready-compiled applications. Using a slightly dated root filesystem here: http://lists.debian.org/debian-arm/2007/01/msg00034.html, a initrd and further kernel configurations were sufficient to get it to run. Thus, we can now compile programs for iPhone Linux on iPhone Linux. The process is rather slow due to the processor and inefficient NAND device driver (pending a real FTL), but at least theoretically, iPhone Linux is now self-hosting.
This should be pretty much enough for those who are more into the userland development side of things to come in, possibly using Debian as a base to build anything else (as I believe it is standard enough).
I will be offering instructions on how to get this all to work soon. The (modified for gadget serial terminal) rootfs is fairly hefty (around 130 MB), so I'm not sure how we'll handle distribution of that.
"I KNOW WHAT IT'S LIKE,BECAUSE MY HUSBAND IS NEVER HOME"
You know,when others try to compare their lives to yours,it gets a teensy-bit annoying. There is absolutely no comparison on God's Green Earth,for a single mother to a married mother. So,if you are married and reading this? It is offensive to tell another single parent that you understand their strife because your counter-part is gone a lot of the time.
There is money coming in for one, you get to spend holidays together and your child HAS a Daddy!!!(or Mother,in the opposite case) And even though they may not be around much,at least when they are,you are free to go shopping by YOURSELF! (what I wouldn't give...),or maybe he/she is extra cool and helps by making dinner once in a while or giving the baby a bath. Even if he/she doesn't help out much,I'm sure just their presence alone,is comforting to both your children and you! .I was afraid to sleep for years after my divorce,especially when living in some 'not-so-great' neighborhoods at times. Even just having someone to kill an occasional spider for you is nice! ;) (okay...maybe just remove them to the outside for you spider lovers.)
But, you get my point right? I don't mean to rant,but going through Cancer AND keeping this four man ship afloat,is definitely a juggling act to say the least and when I hear remarks like that, I just cringe. This is not my most eloquently written post,as it is more venting than anything,but at least I dropped in to say hello!
P.S. Please send me your stories of 'Being Demeaned as a Single Parent'.(especially mothers). There seems to be a generally very low opinion of many single mothers,while single fathers often remain upon a pedestal and highly revered. It just doesn't seem right to me. We are one person doing the work of a village and I want to let other people know how single mothers are being treated by society as a whole.
PORTING DRIVERS TO LINUX
We've made some progress on the USB gadget driver for Linux, and we're now running a generic serial gadget for communication. This implementation is important because USB is now a lot less laggy and things like ethernet over USB, etc., can eventually be supported, easing access.
We've also got pretty far with porting the NAND driver to Linux. Most of the read support is now there, and we've isolated the routines in the iPhone kernel where the raw hardware write occurs. CPICH and c1de0x are working on reversing it. Hopefully, it will be analogous enough to reads that it won't take a huge amount of time to work out.
This is different from reversing their FTL, however, which is a complicated slew of data structures, merge buffers and other exotic algorithms that take care of evenly distributing writes throughout the device and also making writes take less time.
I think reversing all of that would take too much time and effort. Instead, my proposal is to just reverse the hardware NAND writes. Instead of using a partition, we would have a loop-mounted root filesystem (similar to how Wubi is setup), with the root filesystem being a file on the Media partition. Since there's a non-empty file at that location, the FTL system, whatever it is, must create a one-to-one mapping from logical sectors to physical NAND pages. We can already read the mapping it creates (we have already reversed the read-side FTL code), and so all we have to do to alter the data is to write to the same pages we would've read from. Of course, this means that wear-leveling and bad block handling is not performed. However, if we use a filesystem that's aware of bad blocks and can wear-level (YAFFS or JFFS2), then it amounts to the same thing. The wear-leveling would then take place over the particular physical pages belonging to the rootfs image, rather than the entirety of the NAND. This would make the physical pages belonging to the rootfs image wear out a little faster than the rest of the NAND, but the actual effect of this should be inconsequential.
The additional benefit of this setup is that there's no repartitioning required, so setup is cinch. See this wiki document for specific proposed implementation details.
DONATIONS...
A couple of people asked for a donate button of some sort. I hesitate because of the sudden complexity of things when money is involved. Here is what I think would be best:
- Donate your time and skills if you can rather than money.
- If you cannot do so, please consider sponsoring something we could directly use: Such as a USB serial cable (about $45 for parts from Sparkfun), or perhaps upgrading the Slicehost slice we're borrowing from pumpkin ($60 per month, though it would only be useful if we could get enough money for at least six months), used or broken devices for testing, etc. Or something like a pizza for one of our contributors on a late night hacking binge (we will distribute food donations on a round-robin basis =P)
- My paypal address is my gmail e-mail address (planetbeing). If you do make a donation, please specify exactly what it is for. A gigantic slush fund is something that I wish to avoid.
UPDATING AND UNINSTALLING OPENIBOOT
It's actually slightly problematic to use the "Update Firmware" feature of iTunes with openiboot installed, so I updated openiboot with an uninstall facility.
I uploaded the binaries and instructions necessary to update openiboot (and then uninstall it if you wish) to: http://www.iphone-dev.org/planetbeing/openiboot-uninstall.tar.gz
LINUX ON THE IPHONE!
I'm pleased to announce that the Linux 2.6 kernel has been ported to Apple's iPhone platform, with support for the first and second generation iPhones as well as the first generation iPod touch. This is a rough first draft of the port, and many drivers are still missing, but it's enough that a real alternative operating system is running on the iPhone.
What we have:
- Framebuffer driver
- Serial driver
- Serial over USB driver
- Interrupts, MMU, clock, etc.
What we have in openiboot (but hasn't been ported yet):
- Read-only support for the NAND
What we don't have (yet!):
- Write support for the NAND
- Wireless networking
- Touchscreen
- Sound
- Accelerometer
- Baseband support
The current userland we're using, in the interest of expedience, is a Busybox installation created with buildroot, but glibc works fine as well, and we're going to build a more permanent userland solution.
A demonstration video can be seen here: http://www.vimeo.com/2373142
Instructions here: http://www.iphone-dev.org/planetbeing/LINUX-README.txt
Download here: http://91.186.26.18/iphone/files/iphonelinux-demo.tar.gz (look for mirrors in the comments)
EDIT: The instructions are missing the step that you have to select openiboot console from the menu before performing the "sudo ./oibc" step. Just be aware you have to do that if it seems like you're not getting a response from the oibc client.
Project lead: planetbeing
Contributors: CPICH, cmw, poorlad, ius, saurik
If you're experienced with hacking/porting Linux and especially if you're experienced with porting Android, I'd definitely like to hear from you. Come chill in the #iphonelinux channel on irc.osx86.hu. Thanks. :)
EDIT: I was asked a couple times by people who wanted to donate (financially) to the project. I made a post discussing this possibility, if you are interested.
Tuesday, July 28, 2009
POORLAD'S MENU IMPLEMENTED; PORTING ISSUES RESOLVED
Yesterday night, I merged in a branch I was working on for poorlad's menu. A version of that beautiful menu is now in Git. His menu included a version string at the bottom. We didn't have any way to keep track of versions and builds before, so this was actually a good idea that I had to implement. Because I didn't want to implement support for non-fixed width fonts, or add another space-consuming font, I just used the console font I was already using for that part. I also had to brighten the gradient on the bottom of the screen, since it was basically invisible due to gamma issues otherwise.
The border between the gradient and the "black" is clearly visible on my device. This is probably because of a gamma issue. When poorlad comes back, we can ask him to calibrate it more.
Otherwise, it looks pretty good! In order to make this possible, I added in stb_images.c, a great tiny little image library that can read PNG, JPEGs and even PSD files and does zlib decompression as an added bonus. This will be a great help if we decide to change things or need to add more stuff that consumes a lot of space. I also added in a basic function to perform alpha blending (albeit comparatively slowly).
Sadly, while I was busy making these changes, ius from IRC actually begun to implement poorlad's menu without me knowing about it, so we ened up duplicating each other's efforts. He was able to compile in zlib and libpng, but the cost was to inflate the final binary to 347 KB. Whereas taking out the old menu images, and adding small, compressed PNGs and the stb_images library instead actually made openiboot smaller than it was before! His decision to preblend the images, rather than attempt alpha blending on the device, was probably more optimal from a performance perspective.
Steven Troughton-Smith told me on Twitter that he has actually implemented his own boot menu as well. I'm not sure if he used the new PNG code or not, but the new code makes it pretty easy for a competent programmer to add in whatever menu they would like. I'd tell everyone to skin away, but we should keep as few wild branches of this project as possible, since everyone randomly installing openiboot just for kicks (especially a modified version) and then coming to us (read: me, ultimately) for support is something we don't have the resources to handle at this moment.
On the porting side, the issues with installation, optimizing NOR access on iPhone 3G, NAND access on a few devices all seem to have been fixed, so we can basically scratch the first two items off of the list I put up in the last post. I'm pleasantly surprised at how relatively easy it was.
Anyway, now for the kernel. Well, if I don't get distracted by writing to NAND.
PORTING TO IPHONE 3G AND IPOD TOUCH
Hey guys,
The lack of updates for the past few days is because many of you decided to visit us in IRC, thus enabling work to be done on porting openiboot to the iPod touch and the iPhone 3G (in particular because I don't have an iPod touch at the moment).
I'm pleased to report that everything now seems to be working on the iPhone 2G and the iPhone 3G (albeit NOR read/write on the iPhone 3G is unoptimized and is unacceptably slow). There is apparently an outstanding issue with the NAND ECC on some (?) iPod touchs, and also some people can't seem to actually install openiboot to NOR on both iPhone 2G and iPod touch. Unfortunately, the problem is that these things happen on devices that I don't have physical access to, and IRC is often a frustrating medium for communicating with testers. I'm confident these issues will be resolved soon, though.
So, current simultaneous projects:
1. Resolve openiboot porting issues
2. Implement poorlad's boot menu
3. Work on write support for FTL
After at least one of those things are done, we'll be working on the Linux kernel.
NAND FILESYSTEM NOW READABLE!
Amazingly enough, the FTL_Read stuff from last night was pretty much correct! After that, it was relatively trivial to port over the HFS+ code I've already written (which was in pure C... finally that [fail] design decision has been vindicated =P).
As you can see in the screenshot below, with the latest Git revision, you can browse the filesystem from openiboot!
Next on the list is to port openiboot over to the iPod touch and iPhone 3G. It's probably just a matter of putting in different numbers for the GPIO ports, but we'll see.
After that, I will implement poorlad's bootmenu (which everyone seems to like).
After that, well... We have pretty much all the devices now, so we'll start looking at the Linux kernel. If you're a Linux kernel guy who would be willing to help (preferrably you have experience porting Linux to new ARM platforms), please leave a comment here. I can do most of the muscle work, but it'd be nice if someone can show me how to set up the source tree properly for the new port.
FTL
I don't know how I was talked into reversing a FTL, but we're actually on our way. I've managed to enlist the aid of CPICH (who has been helping with the lower layers as well, he's our human HexRays) and just recently, pumpkin, who you will know from the Dev Team. pumpkin will be the heavy support that's necessary to take down _FTLRestore, which is the most complex function I've seen in 1.1.4 iBoot (and I've pretty much have seen all of it). pumpkin is very good, so this task should be now be cut down to "fairly difficult" from "completely impossible".
The strategy so far has been me methodically hacking through the functions in the order that they are called, completely decompiling them, understanding them, and assimilating them into openiboot. Toward this end, I've been working on FTL_Open, which is a fairly large (but as it turns out, boring) function, but has been useful in enlightening us on several of the large data structures FTL uses.
Meanwhile, CPICH works on functions ahead of me, so that when I reach them, a lot of the thorny underbrush has been cleared out and my job becomes much easier and faster. Toward this end, he has been working on FTL_Read, which uses the data structures that the now-completed FTL_Open should populate.
_FTLRestore is sort of a "bonus", since it's not normally called if the iPhone was shut down normally and everything is cleaned up. However, since recovering faulty data structures require all redundancies to be exploited, reversing this would let us gain a lot of insight into how the FTL works. It's also, naturally, an enormously complex function, and hence I wisely delegated it to pumpkin. =P (We will probably end up working on it together)
The one thing that troubled me was that the code we were reversing is for 1.1.4 whereas we primarily need it to work on 2.0. However, due to the fact that I had it better mapped out than the 2.0 iBoot, and the fact that the equivalent 2.0 code was much more complex (lots of function pointers flying around, and a weird switch idiom I haven't quite figured out yet), We decided to stick to the 1.1.4 iBoot.
After completing FTL_Open, I had a bit of a panic when I discovered it did not work at all on my 2.1 phone, and I could not find any obvious bugs with it. This might've meant that all our work on 1.1.4's FTL was for naught. Forgoing sleep, I tore through the 2.1 iBoot, locating the analogues to my already reversed 1.1.4 functions (I had given up trying to trace through the function pointers the first time around), and called them directly with my special version of iBoot (patched so that one of the commands was able to call arbitrary iBoot functions with arbitrary arguments). I managed to find a couple of bugs with my VFL code, and after having fixed them, FTL_Open appears to have worked. I think. It just finds and reads several data structures from NAND. It remains to be seen if I'm even reading the right thing.
Now for some sleep.
WHY IPHONE LINUX?
This is a post I wrote a long time ago, when this blog was first conceived. I decided to hold off on posting it, because I thought it'd be better to do some technical posts before waxing philosophically. I think it is still appropriate, so as we work on reverse engineering the NAND FTL, here's some food for thought.
Porting Linux to the iPhone is an arduous project. We will be trying to develop an entire suite of device drivers for undocumented hardware and then attempt to run a full-fledged operating system on it. This thread speculates "10 days" or "3 hours" as the amount of time it'd take to get Linux up and running on the iPhone. Perhaps this figure would be accurate on a x86 platform, or other platforms with hardware for which device drivers are already written or for which at least documentation is available, but we have no such luck on the iPhone.
This comment on a O'Reilly Radar article about NerveGas's iPhone Open Application Development book says, with perhaps a little too much vitriol for my taste, that developers should not waste time on the iPhone, a closed platform, and spend time more productively on OpenMoko or Android: truly open platforms. Apple should thus be punished for not making the iPhone open. His point is well-taken though. Reverse engineering Apple's code is inefficient and ought to be unnecessary. Why do I bother when I can just develop on an open platform instead with no such wasted effort?
Finally, I have faced skepticism even from my fellow Dev Team members when I first talked about this project. The iPhone already has a perfectly serviceable operating system that we can develop on. Why does it need another one? Sure, Linux might be cool, but what practical use would it have? How does it justify the tremendous amount of effort that would need to be put in?
So. Why do I bother? Why should we bother?
Part of the answer is that I don't choose which platform I hack on based on how hackable it is. I choose it based on how much I like it. I don't own an OpenMoko device; it simply doesn't look as polished as the iPhone, and support is lacking for it. It wouldn't make sense to buy it to use it, only to buy it to hack on it. While this may work for other people, it's simply not the way a (relatively) starving college student does things. As for the Android, I'm not too convinced about how amazing it will be from the videos I've seen and besides: It doesn't even exist yet! In general, the more people use a device, the more hackers use it, and thus the more it is hacked on. Usability frankly trumps hackability.
The other part of the answer is that iPhone Linux will actually be of tremendous value. There will be no more need to port applications over: The applications already run on the iPhone! Also, with a familiar kernel, we can do all kinds of things I've wanted to do: doing security related work with the wi-fi for example. Plus, knowledge that we are gaining/will have gained about the iPhone hardware will be of incredible practical value to the homebrew iPhone community. We've always wanted to be able to plug in the iPhone as a simple USB mass storage device. With USB and NAND FTL drivers, we can actually implement this ourselves.
Perhaps my most important point is how iPhone Linux will affect the various open platforms in development. The iPhone has revolutionized the way the market thinks about mobile computing and now several mobile platforms are in development: OpenMoko, Google's Android, and Mobile Ubuntu (thought the last is not targeted for phones). All of these projects are based on Linux, and "based on Linux" means that, by definition, they "use the Linux kernel" and the Linux kernel is exactly what we're porting. As long as the kernel works, the rest of the operating system will barely need to be touched at all! (fine print: provided that the working configuration of the kernel can support all the features the userland requires).
Imagine OpenMoko on the iPhone. Android on the iPhone. Ubuntu Mobile on the iPhone. Consumers will have choice, and not some Linux-hippie idealistic choice-for-the-sake-of-choice choice: All of these platforms have major momentum behind them and it is very possible they will end up being better than the iPhone's platform (have better UI, more application support, etc.). Also, imagine what it will mean for the developers of these platforms: A ready userbase of millions of users. If many people can already install and try out one of these platforms, it'll be far easier to attract users to buy the hardware, and developers to develop for the platform. Thus, I do not believe we are harming the open platforms by developing on the iPhone. In fact, if all goes well, we will be allowing them to conquer the Apple iPhone.
Of course, I know the reply to all of this. "That sounds good, now show me the code." It's important not to overpromise and underdeliver, so I will be very cautious. What I have just said is the hope, the best possible outcome. But just having that as a possibility is tantalizing enough to justify working on this project. However, to be honest, my original justification (as stated to the dev team) for working on iPhone Linux was "for Skillz.app", our facetious term for working on something merely to hone one's skill or to satisfy one's curiosity. But honestly, what did you expect from a "hacker"? :)
We have already made more progress with openiboot than many people have anticipated would ever happen. Reverse engineering drivers is a laborious process, but one that doesn't require the luck of finding a security vulnerability: It just happens slowly and steadily, rather than unpredictably. Presumably after the drivers are in place, the Linux kernel will "just work" without too many other changes, since it is designed to be relatively portable, so we ought not to have many problems. After the kernel works, I hope enough developers will become interested and a nice userland can be developed without too much trouble. The userland work is much less risky from a time-investment point of view.
BOOT MENUS, SO FAR...
So, I'm already getting some boot menus from people! I'll put the entries up here. Please comment and critique them. I will also be giving some of my thoughts:
These two are from chris custren:
These two are from poorlad:
This one is from pH:
That's it so far. If you've got any comments or suggestions about them, leave them here. Here's what came up from a technical/practical perspective: As I've mentioned, gradients are good. It is also very good if you can do things in grayscale (as poorlad did for one of his images, but even the blue scale can be programmatically generated) since it saves on expensive bitmap data. On using the Apple logo, here's what we're willing to do. We're willing to accept a logo with an original, unaltered Apple logo OR a logo created from scratch that resembles the Apple trademark. We cannot accept logos that modifies copyrighted Apple materials. The rationale for using Apple trademarks is because this is merely for identification purposes. If their lawyers have any problems with that, we will respect any requests to take it down.
NAND FTL
So the big news yesterday (other than Obama winning the presidency!) is that we have enough of a low-level NAND driver now that we're able to read from NAND! It was epic win. There turns out to be not as much hardware voodoo as, say, Merlot, so that's pretty good news. It seems to work (albeit slowly) and I even wrote the ECC routines today (and those seem to work as well).
Unfortunately, in the course of this, we discovered several unfortunate things. First, I can't seem to find anything that might write to NAND. It's probably not much more complicated and probably reuses a lot of the stuff we've been doing, but it means that we might have to look in the kernel for that code, which sort of bites (a lot of the kernel is in C++ and not as friendly to reverse).
The second thing is the realization that all of Samsung's proprietary FTL code is in this thing. Without being able to understand it, we can't actually map sectors to data and we can't make sense of the NAND data or write new data to it in a useful way. Unfortunately, this code is liable to be ridiculously complex, since it's basically their SDK they ship to everyone. Without it, we can still proceed, but the iPhone can't read Linux's data and Linux can't read iPhone's data. In the worst case, we can't even have both OSes on the NAND at once.
Still, being able to dump NAND through USB is a substantial accomplishment, and we're well on our way.
Monday, July 27, 2009
BOOT MENU ART
I think the best way to handle this is for anyone interested to submit a proposal via e-mail to me about the boot menu. Then, I can put up the pictures on the blog for people to comment and have an opinion about. We can then figure out which one to use or maybe some combination of proposals or in any case, figure it out in a collaborative community style process.
I don't really have an opinion on what the logo should look like, whether it should be cartoony or not. I only think it should look good. =P
There are very few technical constraints on the boot menu. I'm willing to figure out whatever technical solution there needs be in order to get things to display properly. One thing to keep in mind is that space on the NOR is at a significant premium, and raw pixel data is expensive but procedurally generated stuff like gradients are possible. The only two current menu options are the iPhone OS and the openiboot console, but eventually a Linux option will be added. I can try animation as well, but again, you'd have to have an idea of how it can be done without using up a lot of NOR space.
But yeah, make us pretty!
Some progress on the NAND: Thanks to a huge amount of initial grunt work by CPICH, the NAND project is off the ground. We already have enough to get the proper drive geometries, and I've written and tested the DMA routines that are near the heart of the problem today. Hopefully, we can dump the raw NAND soon and take a peek at what kind of wear leveling data structures we're dealing with.
INSTALLATION, THE PMU
While I was waiting for CPICH to finish the first bits of the NAND FTL reverse engineering work, I've been trying to fill in some of the gaps we had in other places, such as the PMU. As promised, there is also now an easy way to install openiboot onto the iPhone. This is great because it will eventually lead to an even leaner and easier QuickPwn in the future.
One of the annoying parts about iBoot in recovery mode is that the thing refuses to charge the iPhone while sitting in recovery mode. The battery just eventually entirely drains. With the new PMU code, openiboot now recharges the battery, so programmers using it (read: me) can just have it sit on the console screen indefinitely. You can also do neat things like check the current battery voltage and check the power supply type the phone is charging from.
The "installation code" consists of porting over my knowledge of reading and modifying img3 files from working on the jailbreaks. I was too lazy to port over the entire xpwn framework, but I wrote up a "diet" version that is sufficient to read and modify img3 files in a limited fashion. img3 files are sort of the new native format of the main part of the NOR (just a bunch of img3 files concatenated together). The upshot is that you can load openiboot as an img3 through iBoot (just like sending an iBEC image) and then type "install" at the console and openiboot will be a permanent stage in your bootloader chain. =P
You can, of course, keep booting up to the iPhone OS as you always do by selecting the option in the boot menu. Installing openiboot isn't very useful except for hackers wanting to hack openiboot.
I also figured out how to parse and modify the NVRAM banks (storing environment variables like "auto-boot", etc.), which was actually pointless complicated (in my opinion). They have two banks consisting of a bunch of partitions with these headers that Apple uses a pointless one-byte custom checksum on. The entire bank is also checksumed with adler32. When NVRAM is modified, the oldest bank is overwritten with the data and becomes the newest bank (which is tracked by an epoch number on each bank). This is so if one bank becomes corrupted, the other can be used as a backup. However, NVRAM hardly contains anything high value so the value of all this trouble is doubtful. Being able to write to NVRAM, though, makes it possible to set auto-boot on and off within openiboot so that we can easily control whether or not to enter iBoot's recovery mode.
Someone asked me how "safe" it was to do the installation, etc. Well, I've been doing it every time I make an update these days, so it's fairly safe. The worst that can happen in the usual case is that you may be forced into a DFU mode restore. Everything will be undone with a restore. Early on, I did have bugs that really screwed things up so that a DFU mode restore was no longer possible, but even that was recoverable. I'll just go over how briefly:
The important thing is to have a backup of the NOR. As I described in a previous posting, it's possible to really screw things up if you erase the SysCfg section of the NOR. If you do that, the iPhone OS will refuse to boot at all since iBoot cannot properly populate the device tree for the kernel. Since restore ramdisks rely on XNU booting, this is Bad News Bears. In addition, the SysCfg section is device specific, so if you do not have a backup, it will be difficult to ever completely recover from erasing it.
Therefore, before you proceed, MAKE A BACKUP OF YOUR NOR. openiboot can do this for you (and subsequently restore your backup if things go wrong).
Load openiboot via loadibec and select the console. Connect with the oibc client. Type in: nor_read 0x09000000 0x0 0x100000
This will read all of NOR into memory. Then type: ~nordump.bin:0x100000
This will transfer the dump over USB onto your computer and save it as nordump.bin.
Supposing you filled the entire NOR with garbage somehow and are unable to boot. You have to get into openiboot to restore the NOR. The problem is that openiboot is only designed to operate in a post-LLB or post-Recovery Mode context, so it cannot be directly booted from DFU mode. Basically, you've got to load a pwned WTF, then a pwned iBSS, and then a pwned iBEC (all of which is available from a custom IPSW). After that, you can use loadibec to load openiboot. Then, you can restore the NOR thus:
!nordump.bin
nor_write 0x09000000 0x0 0x100000
After that, you can reboot and everything should be normal.
Also, I received a few responses for people volunteering to do the art. I'm not sure what the best thing would be, since I don't want anyone putting in effort for nothing, but we do want the best possible results. So, I'll be getting back to you guys about that.
PORTING AN OS
I've been getting a lot of questions from people that seem to reflect a basic misunderstanding of what it takes to port an operating system onto a new platform. People seem to think that just by writing, say, a boot menu, means that we can stick Android or Windows or whatever onto a device because we can have a menu option for it.
Here's what it takes for an operating system to run on a device:
- The code must be designed for the right CPU. (x86, ARM, PPC)
- The code must be able to interact with the hardware in the way it expects.
Because the code cannot interact with the hardware! That is, there are no Linux drivers or Windows Mobile drivers for the hardware that's on the iPhone. We're not even talking about things like the wi-fi won't work or anything silly like that. We're talking about big things, like not being able to start because it doesn't uncompress itself into RAM properly. We're talking about freezing the first time it has to wait for something to happen because it doesn't know how to run the hardware clocks and timers (which is CRITICAL for computers) and doesn't know when to start again.
Thus , if I tried to take some distribution of Linux or Windows or whatever, stick it in memory and start it, absolutely nothing will happen. That's right: nothing. There will be no output because it doesn't know how to run the display, or the USB, or serial. It probably won't even get to the first line of code that tells it to output something because so many things are broken.
So how can we get Linux to boot on the iPhone?
By teaching it how to run the hardware. We take the knowledge gained from getting that boot menu to display and graft it into the Linux kernel. It took an unbelievable amount of devices just to get the boot menu display: clock, timer, vic, mmu, spi, i2c, gpio, system controller, pmu, nor, uart, usb, lcd, buttons. Some of those may seem obvious to you, some work in the background to support the other devices. But all of those had to be reverse engineered and all of them will have to transplanted into the Linux kernel to even get something half-assed booting.
If all of those devices were required to get something as simple as boot menu up, can you imagine what would happen if you tried to boot an operating system that did not know how to run ANY of those devices?
We cannot modify the Windows Mobile kernel because it's closed source, and so there's no way to get it to run on the iPhone.
The critical misunderstanding, I think, is that people think somehow that the OS "sits on top" of the boot menu, and talks to the hardware through the boot menu. Therefore, you can have an "emulation layer" that lets Windows or Linux or whatever talk to the hardware, without having to alter Windows or Linux itself. This is completely false. An operating system, by definition, has direct access to the hardware. Nothing sits between it and the hardware. Once iBoot has loaded the iPhone OS, you can go ahead and wipe it clean from the NOR and the OS will keep running as usual. It's not "running", it's not used or loaded in any way except during the boot process.
The iPhone will never run Windows Mobile directly (virtualization would be possible albeit it would crawl on the iPhone). It will run Linux once we write the drivers for it based on our knowledge of the hardware. Android uses the Linux kernel, though they do modify it to a certain extent. Since the only really hardware dependent parts of an OS is in the kernel, presumably once we install the necessary drivers, Android will run just as well as Linux runs. However, not having even looked at Android's source yet, I really don't have a truly educated opinion at the moment, but let's just say that it's one of this project's primary goals.
Sorry this is so long, but intelligent explanations tend to be long.
P.S. Another question people ask a lot is how long will it take. I can't truly give a good answer to that, because it's sort of dependent on the schedules of the people who work on it, and it also depends on how fast it'll take to write the Linux drivers, and how many unexpected problems crop up. It could go really unexpectedly fast, or we could hit a roadblock. I think outside observers, just reading the commit logs and reading the blog has as much information as I do on how fast things are progressing, so you're free to come up with your own conclusions on how long it will take.
BOOT MENU DONE!
Well, that was quick. See, I can actually get things done pretty quickly when it doesn't consisting of banging my head against machine code until it starts making sense. When I actually have the drivers, things like this are easy.
You can use the Hold button to toggle between the menu items (and the option will be highlighted). You can choose the home button to select it. The "openiboot console" option takes you to the command-line interface similar to the one I demonstrated in the last post (you do have to be plugged in via USB and using the openiboot client to talk to it). The "iPhone OS" option chainloads a copy of iBoot stored in NOR under another identifier ('ibot' becomes openiboot and 'ibox' becomes the actual iBoot). I got that set up with a slightly modified version of the QuickPwn ramdisk, but in the future an installer made from a modified version of LogoMe can be run from userland to install openiboot. It's also possible to get openiboot to install openiboot (much like the way GRUB can do it); I'll probably work on that next.
So if anyone likes living on the bleeding edge, they could do that. =P
Most of the hard part was me failing at GIMP putting together the boot menu graphics. I appealed to you blog readers for graphics before, but basically no one responded. Now that there is a working model of what I sort of want, I hope there will be more of a response.
So, please please please redesign the boot menu for me. And possibly come up with a logo for the project we can stick on there. If you're good at this sort of thing, or know someone who is, please put them in touch. This stuff will obviously get a lot of attention in the future and we need nice eye-candy. Thanks!
BOOT MENU PROJECT IS A GO!
After a huge amount of effort and in-situ experimentation with iBoot (basically a binary massive binary search through the code, disabling some functions to see if I could figure out why my LCD driver wasn't working properly), I managed to get it fully working. The problem was two-fold: first, I forgot to write the first and last bytes of my gamma tables: oops, but easily fixed. The second problem was that apparently iBoot changes the SDIV of the clock in the middle of the initialization process. I'm not even sure yet how many devices the change in clock frequency affects. It certainly affected the LCD, because before there was all sorts of flickering scanline weirdness as one would expect from a misconfigured clock.
Anyway, I reversed the routine that changed the SDIV and implemented it. Seems to work fine now. It's been ages since I looked into the clock speed stuff (pretty much right when I first started this) so I can't say for certain, but I'm pretty sure doing this increases the clock speed (which would make sense).
The LCD driver worked after those fixes and I went onto write a simple framebuffer in a couple of hours, so we can finally get text-mode output on the iPhone screen. It was pretty important to me to get the screen working because even if we can boot a kernel, I wanted the layman to feel like a full-fledged OS was running on the device, and that means display and I/O of some sort.
For a final hurrah, I also wrote some code that lets us detect when the physical buttons (Home, Hold, etc.) were being pressed down. From these pieces, it will be possible to construct a graphical boot menu controlled by those buttons. You could have one option to boot into the iPhone OS, and one option to go into openiboot command-line mode with that text-mode display.
The photo I posted is the current development snapshot running on a first generation iPhone, with oibc (openiboot client) connected and running on my desktop computer. If you have a 2G iPhone or a first-gen iPod touch, you can try it out yourself by checking out the code from Github and compiling it (It's only designed to be built on a Linux machine. You'll be missing some Linux headers otherwise). I wrote some basic notes on how to get it running inside the source tree, but this is not something you're expected to work with unless you're a fairly experience programmer yourself.
OPENIBOOT BOOTING!
Well, it's booting. Sort of.
I had some trouble getting the flashed version of it to work because for some reason, 0x0 was not mapped to 0x18000000 when openiboot was loaded. Since all the exception vectors are at 0x18000000, bad ones were being called whenever there was any sort of interrupt. Basically, I just said screw it and rebased the whole program into 0x0. It will basically overwrite whatever exception vector is currently running without worrying about the MMU and such. However, this basically does imply that I don't really understand how the MMU works, so that will have to be fixed.
The end result is what you see above.
The other major roadblock is that the gamma tables remain broken. Even after I chainload iBEC or iBoot over openiboot (as I have done there). The OS boots and everything... just with some really psychadelic colors. =P
So LCD remains a big problem and so does the MMU. But hey, it boots and works (sort of).
Update: LCD now partially fixed. I still need to figure out how to turn the backlight on, but at least chainloaded iPhone OS has normal colors now. =P
Sunday, July 26, 2009
LCD DRIVER DONE?
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.
USB FIXES
Just a post to indicate things are inching forward slightly. I've been working on debugging USB communications and it seems a lot more stable now. I was basically forced to because my old code only works on computers without usb 2.0, so that ruled out being able to easily work on this project with anything approaching a modern computer. The problem was that I avoided reading the official USB specs (those things are usually overly locutious) and tried to learn instead from sites such as USB in a Nutshell. Unfortunately the driver then failed to properly respond to the device qualifier descriptor which led to epic fail in USB 2.0. The embarrassing thing is iBoot does send this descriptor, but I figured it must be a vendor specific one at the time.
Cmw made me a cable that let's me do serial and USB comm at the same time, which helped a lot in working out the bugs. I'd say it's fairly reliable now; enough for other developers without a serial cable to come in. So how about it, guys?
I've also started to scratch the surface of the NAND driver. Unfortunately, even the lowest level functions are enormously complex. The higher level wear leveling code and data structures even aside. A great deal of it seems to belong to Samsung, since I've found some creepily similar C code lurking around online. Unfortunately, I can't find a complete enough copy of it.
And yes, I'm aware of Android and their source release and yes, I know what you're thinking.
SIMILARITIES AND DIFFERENCES BETWEEN QUICKPWN AND ZIPHONE
Similarities
Jailbreak
Both utilities jailbreak.
Payload medium
Primary jailbreak payload is placed into iPhone memory for both jailbreaks
Differences
Technique
ZiPhone 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.
Longevity
ZiPhone 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.
Elegance
ZiPhone 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 note
Zibri 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.
ANGLER
When it's mature, the male angler's digestive system degenerates, making him incapable of feeding independently. His sensitive olfactory organs help him sniff out a female anglerfish. When he finds one, he bites into her skin, and releases an enzyme that digests the skin of his mouth and her body, fusing the pair down to the blood-vessel level. He then atrophies into nothing more than a pair of gonads, which releases sperm in response to hormones indicating egg release. This extreme sexual dimorphism ensures that, when the female is ready to spawn, she has a mate immediately available.
[She knows who her baby's Daddy is.]
WHEN THE BOOTLOADER IS NOT THE BOOTLOADER...
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.
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. :)
Saturday, July 25, 2009
MY NIECE'S CONTRIBUTION
Once again, I'm gonna step aside from posting my fodder and pridefully promote my Sister's daughters talent:
Hallelujah
Subscribe to:
Posts (Atom)