Emmanuel Fleury schrieb: > Hi, > > MsTiFtS wrote: > >> I got my nano 2G 8GB about a week ago and since then have been quite >> busy playing around with it. >> For instance I removed the AUPD and RSRC file from the firmware >> partition, relocated a bunch of stuff (even the directory structure IS >> relocatable, the pointer in the first block IS still used, although >> somebody keeps telling the contrary, I think I read that somewhere in >> the iPL wiki), shrunk down my firmware partition to ~6MiB and >> repartitioned the whole thing to make about 124MiB more space for music. >> Since then, my nano reboots every time I remove it from my PC, so the >> auto-update reboot is probably triggered by writing something to the >> first 94MiB of flash. >> > > This is extremely interesting to me. Actually, how far can you push the > modifications you do. Did you ever have an 'invalid firmware' on which > you cannot boot ? And what kind of modifications are definitevely NOT > allowed. > Oh, I had a lot of invalid firmware. One little fault and everything breaks ;) But that's what disk mode is good for. Invalid firmwares (independent of what was wrong with them, see below) always brought up the iPod restore screen. The only way to get it into an endless reboot loop was by damaging the iTunesDB. What I did was basically pushing everything as near as possible to the start of the partition and then shrinking that partition. The following things trigger the restore screen: - Offset to directory structure is 0, you seem to need at lease 1 block of space between the ]ih[ block and the directory block, probably because it thinks 0 means non-existant or corrupt or something - Remove any of the files (but reducing their size to 0, remapping their location and overwriting their content worked for everything except OSOS) What defininitely doesn't trigger any reaction is fiddling around with the checksums in the directory structure, they seem to be never used. > I really would like to understand which parts of the firmware is CRCed, > where is located the CRC and how is computed the CRC. > If there's a checksum, it is either inside the compressed data or in that preceding security block, but definitely nowhere in the file system. Looks pretty bad :-/ I'll try further fiddling around with it, but as far as I read in numerous places changing one single bit anywhere in the firmware breaks it, so the whole firmware seems to be checked. (With firmware I refer to OSOS, not the filesystem thing and the other files.) > It would help to inject some code in it. > > As far as I know from my own investigations, the filesystem is totally > free of CRC. You can modify it at will (thus make it smaller), but the > binaries part is highly kept secured. > > But I might have missed something !!! > That's exactly how it looks to me, but only for OSOS, the RSRC seems to be never checked (well, maybe if you have a nikepod) and the AUPD seems only to be checked when it is actually used. As long as you don't tell it to update it's boot loader, nothing will be checked there. > >> By the way, the backlight is turned on as one of the last things during >> bootup, the OSOS is doing a lot of other work before turning it on. So >> the firmware loading and decryption may need at most around 10 seconds. >> I found that out by making my nano reboot in an endless loop because of >> a stale iTunesDB (master playlist without master bit set), which >> happened by accident during the development of an iTunesDB modification >> tool. >> I meanwhile have managed to write a pretty stable Java implementation of >> such a thing, allowing me to do some peeks and pokes on the DB. (But >> it's really ugly code) >> > > If it's working, you should ship it ! ;) > It could be a good basis for the work of others. > > We can offer you a branch in you SVN > (http://svn.gna.org/viewcvs/linux4nano/trunk/). > Well, meanwhile this has grown to an iPod tracks and playlist management tool, which is working with the 2g nano with firmware 1.1.3, I don't know whether it will work with other iPods/firmwares (especially older ones), so try it on your own risk ;) The iTunesDB object in there somehow resembles all the objects in the database, to intentionally corrupt a database to get an endless reboot loop, you just need to set iTunesDB.playlistList.masterPlaylist.master=0; It's just one bit you need to flip. If you ask me to, I'll describe a way to find that bit in a hex editor, but this case seems to be handled rather gracefully (looks like an intentional reboot, not like a buffer overflow). There are definitely better ways to make this thing crash. > >> Just in case you have any questions on the iTunesDB or firmware >> partition layout/relocation thing, feel free to ask me. >> If you should manage to get your fingers on some other corrupted >> iTunesDBs that cause nanos to do strange things, just send them over and >> I'll have a look what's going on with them and how one could possibly >> exploit it. >> > > Unfortunately, I'm a bit overwhelmed with work now... but your stuff is > definitely interesting ! > > Regards > I'll have pretty much spare time until 2007/10/10. I don't know anything yet about how much spare time I will have after that date.
After reading the list archive, I'm a little confused. So you are pretty sure that the same key is used for all the firmwares, you can rule out a stream cipher, and I think I can rule out a plain block cipher. If you search for multiple occurrences of the same 2 bytes at all 2 byte boundaries in the firmware, you'll get about 80 hits at best. If this would be a block cipher, and because there is definitely some zero/ff padding in the file, there must be some blocks occurring multiple times. If I search for blocks of 4 bytes length, I get 2 occurrences at most. Doesn't really look like a block cipher to me. If it's a block cipher, they have either done something really strange to it or it's indeed compressed. A block cipher would have been pretty easy to break that way. _______________________________________________ Linux4nano-dev mailing list [email protected] https://mail.gna.org/listinfo/linux4nano-dev http://www.linux4nano.org
