Hello and welcome on our mailing list. Thanks for summing up all these things, pretty good work. I've added a few comments into the quote below.
Niklas Ulvinge schrieb: > 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. > Well, we first thought that, but it seems like we would have to first hack the firmware in order to get that game installed, so I think we're out of luck here. > === Cipher === > You've concluded that it doesn't use a stream cipher becouse of the xor attack > (or what it's called). > Thus it's a block cipher, which is very hard to crack. > Probably a pretty disappointing truth... > === 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. > > 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. > > So it can be the key, or garbage. > Also, we don't know why there are two 20 byte fields. > First the facts: The firmware must be somehow encrypted, as we cannot find any structured data in the image. Also there must be some kind of checksum, because if we change something, it will immediately complain and tell us to use iTunes to restore the firmware. Now the guesses and conclusions: So to install a custom firmware, we need to first get our image encrypted with the same key, so that the iPod can understand it. Additionally we will have to calculate a correct checksum and place it at the right position in order to make the iPod boot it. We doubt that the key is anywhere in the firmware image, it is probably in the boot loader. But who knows? There is definitely some kind of checksum, probably in the header, but maybe somewhere else. So an interesting question would be what we could modify in the header section without making it refuse to boot. We are pretty sure that that is - if it is at all - possible only in the header section, not in the image section. By proceeding that way, we can probably rule out some of the fields, which are reserved for future expansion etc. > === Itunes === > Itunes only downloads the firware, 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. > Well, to be correct, we think it is some kind of supplementary Flash, not EPROM. To my knowledge, the boot loader update process you described is correct. > === EPROM === > Can't we load linux on an older ipod, read the eprom, and then compare > it against > the aupd.fw file? > Wouldn't that give us the input, and the output (asuming that it's > using the same cipher). > 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?process you described is > One main problem is that they changed the kind of processors they use. The old iPods all used PortalPlayer CPUs, the Nano2G (and some others) use ARM CPUs. One could maybe attack the update cipher that way, it's quite an interesting thought. If the first few bytes match in the decrypted AUPD, we could maybe somehow get the key out that way, but I don't know which ciphers are vulnerable to this. We do not need to assume that they used the same cipher / key, because if we can decrypt AUPD, we can also decrypt the main firmware, because it's AUPD's (the bootloader's) job to do that. I think one should have a look into this, but this requires a not very sophisticated cipher, and we need to successfully guess which cipher they used. The most promising approach by now is to try to find the JTAG pins on the baseboard and then try to somehow read out the supplementary flash through them. > Niklas Ulvinge > > _______________________________________________ > Linux4nano-dev mailing list > [email protected] > https://mail.gna.org/listinfo/linux4nano-dev > http://www.linux4nano.org > > _______________________________________________ Linux4nano-dev mailing list [email protected] https://mail.gna.org/listinfo/linux4nano-dev http://www.linux4nano.org
