Merry Christmas to you all too. I think that the flash direct read is the best way to go. It's basically part of what a guy did for iPod touch. They are selling defected ipod nanos in ebay. About 20$ max. Buy one and try and get the flash rom out of it and read it. I'm willing to donate 10$ for this if someone knows a bit and wants to try...
On Dec 23, 2007 1:01 PM, <[EMAIL PROTECTED]> wrote: > Send Linux4nano-dev mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.gna.org/listinfo/linux4nano-dev > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Linux4nano-dev digest..." > > > Today's Topics: > > 1. Summing up and confirming => a todo list (Niklas Ulvinge) > 2. Re: Summing up and confirming => a todo list (Emmanuel Fleury) > 3. Re: Summing up and confirming => a todo list (MsTiFtS) > 4. Re: Summing up and confirming (Niklas Ulvinge) > 5. Re: Summing up and confirming (MsTiFtS) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 22 Dec 2007 14:03:14 +0100 > From: "Niklas Ulvinge" <[EMAIL PROTECTED]> > Subject: [Linux4nano-dev] Summing up and confirming => a todo list > Cc: [email protected] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > 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. > > === 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. > > === 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. > > === 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. > > === 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? > > Niklas Ulvinge > > > > ------------------------------ > > Message: 2 > Date: Sat, 22 Dec 2007 15:31:49 +0100 > From: Emmanuel Fleury <[EMAIL PROTECTED]> > Subject: Re: [Linux4nano-dev] Summing up and confirming => a todo list > To: "Hardware and developpement mailing list." > <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > 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 > > > > ------------------------------ > > Message: 3 > Date: Sat, 22 Dec 2007 15:50:24 +0100 > From: MsTiFtS <[EMAIL PROTECTED]> > Subject: Re: [Linux4nano-dev] Summing up and confirming => a todo list > To: "Hardware and developpement mailing list." > <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > 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 > > > > > > > > > ------------------------------ > > Message: 4 > Date: Sat, 22 Dec 2007 18:17:34 +0100 > From: "Niklas Ulvinge" <[EMAIL PROTECTED]> > Subject: Re: [Linux4nano-dev] Summing up and confirming > To: [email protected] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > I think I did something wrong when posting to this list the first > time, but now it should be right... > > Great reply both of you! > > Emmanuel Fleury: > > I don't get what you mean here... Are talking about second and third > > generation iPods ? > > Yes. aupd.fw contains the decryption program, and although it is > encrypted, it needs > to be decrypted before loading it to the flash. If we can use an old > ipod with linux on it > to read it's flash memmory, we could get the output. > When that's done we got the input and output and should be able to > crack the encryption right? > I'm not a crypto guy.... > > Then we can use the same method and meybe key to uncrypt our aupd > > MsTiFtS: > > > > One main problem is that they changed the kind of processors they use. > > > > I didn't know that, and that clearly complicates things... > > > > > 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. > > > > Hmm, that's an intresting approach. > > Shouldn't it be possible somehow power the pins of the flash and then > read directly from it? > > I had a look at how the flash looks like: > > http://www.datasheet4u.com/html/S/S/T/SST39WF800A_SiliconStorageTechnology.pdf.html > and I observed that the pins aren't visible, so one have to remove it > from the board to read it. > > Niklas Ulvinge wishes you Happy Hacking and Merry Christmas. > > > > ------------------------------ > > Message: 5 > Date: Sat, 22 Dec 2007 20:34:27 +0100 > From: MsTiFtS <[EMAIL PROTECTED]> > Subject: Re: [Linux4nano-dev] Summing up and confirming > To: "Hardware and developpement mailing list." > <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Niklas Ulvinge schrieb: > > I think I did something wrong when posting to this list the first > > time, but now it should be right... > > > > Great reply both of you! > > > I don't think that you did something wrong. Most people posting for the > first time ask silly questions, they probably didn't even read even one > mail from the archive. You have obviously digged through that first, and > asked then, which is the right way to go. :-) One can impossibly know > everything we already worked out when posting the first time, and asking > questions isn't such a bad thing, at least as long as you don't just ask > stupid questions like "Where can I download iPodLinux for Nano2G?" > > Emmanuel Fleury: > > > >> I don't get what you mean here... Are talking about second and third > >> generation iPods ? > >> > > > > Yes. aupd.fw contains the decryption program, and although it is > > encrypted, it needs > > to be decrypted before loading it to the flash. If we can use an old > > ipod with linux on it > > to read it's flash memmory, we could get the output. > > When that's done we got the input and output and should be able to > > crack the encryption right? > > I'm not a crypto guy.... > > > > Then we can use the same method and meybe key to uncrypt our aupd > > > Im not a crypto expert either. The question is, whether it's possible to > restore the key from both ciphertext and plaintext. I neither know > whether that's possible with AES, nor am I sure that they used AES, even > though it seems pretty straightforward. > > MsTiFtS: > > > >> One main problem is that they changed the kind of processors they use. > >> > >> > > > > I didn't know that, and that clearly complicates things... > > > > > >> 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. > >> > >> > > > > Hmm, that's an intresting approach. > > > > Shouldn't it be possible somehow power the pins of the flash and then > > read directly from it? > > > > I had a look at how the flash looks like: > > > http://www.datasheet4u.com/html/S/S/T/SST39WF800A_SiliconStorageTechnology.pdf.html > > and I observed that the pins aren't visible, so one have to remove it > > >from the board to read it. > > > Well, if you manage to rip this thing off the board without breaking it? > Then you just need to be a soldering expert and have the appropriate > tools to connect some pretty thin enamelled wire to it's surface, and of > course you need some kind of microprocessor to read it out. If you > manage to do that (or manage to make someone do that) it would be pretty > cool and helpful. > > Niklas Ulvinge wishes you Happy Hacking and Merry Christmas. > > > Of course I also wish everybody around here on the list Merry Christmas! > > > > ------------------------------ > > _______________________________________________ > Linux4nano-dev mailing list > [email protected] > https://mail.gna.org/listinfo/linux4nano-dev > > > End of Linux4nano-dev Digest, Vol 11, Issue 1 > ********************************************* >
_______________________________________________ Linux4nano-dev mailing list [email protected] https://mail.gna.org/listinfo/linux4nano-dev http://www.linux4nano.org
