On 22/12/2007, MsTiFtS <[EMAIL PROTECTED]> wrote: > 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 > http://www.linux4nano.org >
The error I did was to first subscribe to this list, then mail, and after that confirm my subscribtion... But now that's fixed... But I'm afraid I'm only going to be slightly better than those who run away after their first post... I'm very bad with hardware, and I only got one of these new 3g nanos, which has the flash built in, so I cannot look at it.... Another thing I thought of now, if we can read the flash of old ipods, it should contain the decryption algorithm somewhere? If we can get that, and then run it in an emulator, we should be able to decrypt our data with that. Is this right? But now to another thing, I want you to have an updated todo list for you to put put on the website. Does this look good? * Decrypt the firmware files __* Get hold of decrypted data or the decryption algorithm on the flash ____* Get to the data of the flash ______* Run some code on the flash that extracts it ________* Find some bug in the hardware/software ________* Write your own memmory dumping game ______* Find the JTAG pin and use it ______* Extract the flash chip and read it manualy ____* Get the data of an old flash (which doesn't encrypt the osos.fw) Also, I read in your files that you tried to set the checksum value to all 0xFs, and then it would read the data unencrypted, but I didn't find any follow ups.... Did anyone try it? And did it work? I can se the problem of actually finding some code to run if it's possible, but that way shouldn't we be able to somehow read the flash that way, and then maybe find some way to store it or output it to some pins? Niklas Ulvinge _______________________________________________ Linux4nano-dev mailing list [email protected] https://mail.gna.org/listinfo/linux4nano-dev http://www.linux4nano.org
