Posted by George Hotz on under software hack, bootrom, gunlock, comex, dmg, bbupdater, tokens, hacks, crap, patches, checks, open source | 
Ok, here is where we stand right now.
ZiPhone seems to be the tool a lot of people are using. What it does is boot an unsigned ramdisk with a script to jailbreak, activate, and unlock. If you would like to view the ramdisk yourself, cut the first 0xCC2000 from the dat file and mount it as a dmg. The script is in /etc/profile. Also, Zibri, patch out the bootloader check from gunlock, it'll work with 3.9
ZiPhone is a wrapper for gunlock, which means with 4.6, it currently only unlocks 4.02.13 In order to unlock 4.03.13, right now you need bootloader 3.9
gbootloader will erase and downgrade your bootloader from software. I have checks in the program to prevent a bootloader without the bootrom locations blank from being uploaded, but if used properly, it will downgrade to 3.9, allowing 4.03.13 to be used.
4.6_GEOMOD is a modified bootloader I have with all secpack stuff patched out, hard coded IPSF style unlock(tokens always validate), full anywhere write access, no startup sig checks, and the bootrom locations blank. But the only 4.6 phone I have got bricked while I was trying to restore the seczone, and my bootloader software hack doesn't seem to work in 3.9 I guess I'll have to hw upgrade. Laziness...
Another problem comes with the release of the modified bootloader. It is copyrighted, and the patches are decently complex. What I'd really like to see is an open source, very well coded(the current compiler is crap), bootloader. Say written in assembly. I believe a full bootloader with all the functionality(minus the security) can fit in under 0x1000 bytes. It should continue to work with bbupdater, but have the crypto state machine fixed to validate everything possible. Maybe I'll get around to writing it. This is the ultimate in baseband hacks, and will put every other hack to rest, once you get the new bootloader on there. I'm sick of patching and trying to understand other peoples(badly written) code, when I can just write my own.
Tagi: software hack, bootrom, gunlock, comex, dmg, bbupdater, tokens, hacks, crap, patches, checks, open source
Posted by planetbeing on under large data structures, iphe, ftl, comex, iboot, redundancies, dev team, underbrush, pumpkin, pointers, insight, job |
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.
Tagi: large data structures, iphe, ftl, comex, iboot, redundancies, dev team, underbrush, pumpkin, pointers, insight, job
Posted by planetbeing on under iphe, realiti, comex, obama, oses, worst case, sdk, voodoo, kernel, presidency, sectors, samsung, linux, map |
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.
Tagi: iphe, realiti, comex, obama, oses, worst case, sdk, voodoo, kernel, presidency, sectors, samsung, linux, map
Posted by planetbeing on under th project, source release, comex, modern computer, serial cable, c code, iboot, android, descriptor, data structures, nutshell, comm, usb 2, bugs, samsung, developers |
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.
Tagi: th project, source release, comex, modern computer, serial cable, c code, iboot, android, descriptor, data structures, nutshell, comm, usb 2, bugs, samsung, developers
Posted by on under strata council, home improvements, comex, neighbours, townhouse, warmth, anita |
by Guest “It’s great to feel safe and warm in your own home.” Anita Poonawala knows what she’s talking about.
In 2008, she and her neighbours were looking forward to home improvements to their townhouse complex in Richmond that would provide them more warmth during the cold months.
The strata council had decided to replace the wood-burning fireplaces [...]
Tagi: strata council, home improvements, comex, neighbours, townhouse, warmth, anita
