Emmanuel Fleury wrote: > Emmanuel Fleury wrote: >> Hi all, >> >> Several interesting ideas and informations can be found in this talk: >> http://video.google.fr/videoplay?docid=713763707060529304&ei=ypFYSZ-5IpSw2QLn77XhDg&q=25c3 >> >> Even thought, this is mostly targeting iPhone and not iPods, it is >> clearly drawing a picture of what Apple security is on its embedded devices. > > After looking in details at the video, it unveils quite a lot of things > about the software vault inside the iPods, iTouchs and iPhones firmware. > > Anybody who is interested in the iPod should really dig this video (and > I definitely would prefer comments about this video than seeing you > writing your wishlist to Santa-Claus on this mailing-list...). > > Regards
After watching this video, I have the impression, that it could well be the case, that the IVT hacking approach could work, and that they probably reused everything up to Nano4G. That would be nice. Somebody with access to a Nano3G/Nano4G/Classic could do a quick check about this signature buffer overflow thing. Detecting whether it's present should be easy. However, in order to exploit it, we probably need an unencrypted firmware. The other things in the video were quite some information about apple's strategies in software security, but nothing directly applicable to our target, since the OSX boot sequence is quite different. However, there may be similarities up to the iBoot stage. In order to check that, we need images of the iPhone/iPod touch's NOR/NAND flashes. Our best bet still seems to be the IVT approach. However, this one needs hardware work. Who is capable of doing that and has the appropriate equipment? tof? Somebody else? What is going on @tof? Any progress in hooking up the iPod to an FPGA? Once we got that mask ROM image, we'll be able to quickly decrypt all the other stuff using emulators and such. My approach would be the following: - Remove the NOR flash from an iPod - Hook up an FPGA and an SRAM to it in place of it The FPGA will emulate the flash using data in the SRAM and log accesses to it. - Load the SRAM with the NOR flash image - Boot the thing to see if it works - Rewrite the first instruction to a jump to 0x22000000 - Check that it locks up - Rewrite the first instruction to a jump to 0x2400003C - Inject some code at offset 0x0000003c in the flash - In order to test whether that exploit works, inject code that writes 0x000000A5 to 0x3C500030, that should force the chip into a reset loop - If it failed to lock up above, try disabling the watchdog by injecting a write of 0x00000AA5 to 0x3C800000 before going into an endless loop - Once this works, read out the contents of 0x20000000 to 0x2000C7FF and 0x22000000 to 0x2203FFFF by dumping it via the address bus. The range 0x20000000 to 0x2000C7FF is the mask ROM, which contains the routines and the key for decrypting the NOR flash. Somewhere between 0x22000000 and 0x2203FFFF there should be a decrypted copy of the range 0x00008000 to 0x00028000 of the NOR flash, which contains the firmware decryption stuff, which is what we ultimately need to modify the firmware. Once we get that done, a lot of people like me can start playing around with the images and their own iPods, which means that we'll probably get something bootable rather quickly. It's just that bunch of hardware work, which is currently blocking our progress. Are there any other exploiting concepts that are neither covered above nor ruled out because they can't work for some reason? Any further ideas what we could try? Regards TheSeven _______________________________________________ Linux4nano-dev mailing list [email protected] https://mail.gna.org/listinfo/linux4nano-dev http://www.linux4nano.org
