Niklas Ulvinge wrote: > First of all, Hi to all of you. > > I got an new ipod, and thought it would be cool to have linux on it, > so I investigated and ended up here. > > I've read the late part of your mailing list, and this is what you've > come up with > (added with some of my own conclusions of what you and the ipodlinux > site have written): > (Please correct everything that's wrong) > > === Game === > It could be possible to make a game that extracts the ram, > which somehow makes it possible to get the encryption.
If you can do that we will be really happy with it ! :) > === Cipher === > You've concluded that it doesn't use a stream cipher because of the xor attack > (or what it's called). > Thus it's a block cipher, which is very hard to crack. This is very likely to be AES (quite difficult to break without the key. But the key doesn't change (this is a point in our favor). > === The key === > There's some kind of key or checksum at the start of each firmware file. > It could be the key of the cipher, but that could again mean it's a stream > cipher, but it could as well be a block cipher. Based on our investigation, the firmware is composed of three files, namely aupd.fw, osos.fw and fsfs.fw. fsfs.fw is the filesystem and is not ciphered (usual vfat file system). On the contrary, aupd.fw and osos.fw are ciphered in the very same way and are layered as follow: http://www.labri.fr/perso/fleury/download/ipodnano/firmware_layout.png The headers of aupd and osos themselves are layered as follow: http://www.labri.fr/perso/fleury/download/ipodnano/IN2G_firmware_aupd_header.png http://www.labri.fr/perso/fleury/download/ipodnano/IN2G_firmware_osos_header.png My personal guess is that headers themselves are composed of a clear text part (from 0x000 to 0x02f) and then a ciphered one (from 0x030 to 0x1ff). We know that 0x000-0x02f is not ciphered because we found the size of the ciphered firmware written in little-endian at 0x014-0x017. Then the pink part (which change for each firmware release) is probably a checksum. The second part (0x030-0x1ff) is probably xored with a stream cipher algorithm and the pink part is also probably a checksum (but xored with the stream cipher algorithm). When comparing several version of the aupd.fw files and focusing only on the encrypted firmware part (leaving the header out), we can find the following: http://www.labri.fr/perso/fleury/download/ipodnano/IN2G_cipher_aupd_diffs.png As you see it seems that when a difference is introduced on one line (one assembly instruction) then the following strongly differs which is typical for a block-cipher algorithm (a stream-cipher algorithm would have differ only on the difference and not after). Moreover, we did do some statistical attacks based on the reused key attack (http://en.wikipedia.org/wiki/Stream_cipher_attack) and it appears that none of the expected statistical properties hold (but we did this knowing that it wouldn't work, so we might have been bad at making it properly). So we have some strong clues telling us that it's a block-cipher. As I told you before, AES is very likely used here as it is already in use in many MacOS X scheme to protect binaries. > It could also be a checksum, but if I remember correctly what someone wrote on > the documentation, someone changed some data in a file, and it still booted. > If that is true, then it can't be a checksum. There are some parts that can be modified with no impact on the boot process, but modifying the header or the ciphered part of aupd.fw or osos.fw will end-up with the iPod telling that the firmware image has been altered and the iPod will refuse to go further. On these iPod the scheme to load firmware is extremely stable and reliable (unfortunately a bit too much for us ;)), so you can try out few things with a firmware image and an hexadecimal editor. We never did ends-up in a dead-end with this (even if we did try crazy things, believe me). > === Itunes === > Itunes only downloads the firwmare, writes it to the ipod when > upgrading firmware. > The ipod then loads the aupd.fw file, decrypts it and stores it in the EPROM. > This is true for all ipods. Right. It is also to say that iTunes load the audio files on the iPod, and theses audio files are TRUSTED by the embedded softwares... It's something that we could take advantage (we have several firmwares with known bugs that might be exploited). > === EPROM === > Can't we load linux on an older ipod, read the eprom, and then compare > it against the aupd.fw file? I don't get what you mean here... Are talking about second and third generation iPods ? > Wouldn't that give us the input, and the output (asuming that it's > using the same cipher). We never did such experiments, so I have no data, nor hypothesis about this. Maybe it could be interesting to dig (but I'm not sure I understand what you mean). > And if the it is the key we got in the header of the file, > then it's only the cipher type that's missing... > > Is the cipher type hard to find? I never tried to identify a cipher-algorithm just based on ciphered material. I should read a bit about this topic. If somebody has some interest or some experience in this on this list, just speak-up. :) Regards -- Emmanuel Fleury Writing in C or C++ is like running a chain saw with all the safety guards removed. -- Bob Gray _______________________________________________ Linux4nano-dev mailing list [email protected] https://mail.gna.org/listinfo/linux4nano-dev http://www.linux4nano.org
