Niklas Ulvinge schrieb: > [...] > 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.... > Well, at least you're discussing all this stuff which can be also quite helpful. I don't want to rip my iPod just to get the flash out either, but I'm examining how the boot process works by hacking around with the firmware partition and proposing ways to attack the hardware. > 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? > That's what we're going to do as soon as we get our hands on either a decrypted firmware or a decrypted bootloader. That thing will get disassembled and will reveal how the other one is encrypted. Then we can do the same thing the other way round and we're done. The problem is just, that it's both crypted, so we need some kind of hardware hack to get it out. Using the flash of older iPods will probably fail because they didn't use encrypted firmware and thus probably don't even support it, so they won't have any decryption algorithm in their flash. > 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) > That looks pretty good. The last point probably won't work, and you forgot the crypto side of attacks, such as attacking the cipher using two firmware versions which are encrypted using the same key and comparing them. I don't know much about that either, but it should be added to the list, maybe just a headline calles "Crypto attacks", so that some crypto expert can fill in more detail. > > 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? > These 0xFFs just look like padding for non-encrypted files. The iPod doesn't seem to determine whether a file is encrypted or not by reading this, it just seems to "know" which files are encrypted. (As documented in the blackbox synthesis, section 2.3.3)
What also looks pretty interesting is the connector picture coming up when aupd and osos are exchanged. (See blackbox synthesis, section 2.3.2.2 and figure 2.3) That somehow invalidates our assumption that the firmware is responsible for updating the boot loader. If they are swapped, there can't possibly be a working firmware. And the iPod nevertheless tries to flash the boot loader? (The connector picture means that it wants to be connected to power in order to perform a boot loader update) That implies several other things: - The bootloader must be copied to RAM in order to be able to update itself - The bootloader must check for bootloader updates BEFORE booting the firmware. - Either osos and aupd are encrypted with the same key AND same checksumming algorithm, or it asks for power before decrypting and validating the AUPD image How does it behave with a completely bogus aupd? Does it fail before or after asking for power? BEWARE: If you connect your iPod to power with osos and aupd flipped, that may be one of the very rare possibilities to indeed break it's software! So please at least try it with something completely bogus first, because that will probably rejected. If that happens after asking for power, you can HOPE that it will refuse with the swapped files also. If it refuses to install a bogus aupd BEFORE asking for power, I think we have proof that the encryption and checksumming is the same on both files, and that there ar no sanity checks for AUPD file size, as OSOS will never fit into the boot loader flash. > 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? > If we manage to get some code running on the iPod, the rest will be relatively easy. We'll either need to write 100% location independent code or somehow work out where the code will be when it's executed. And we will of course have to find out how to access the boot loader flash. But dumping RAM may also be pretty helpful. The main problem is finding a way to smuggle our own code into RAM and make the iPod execute it. > Niklas Ulvinge > By the way: Why wasn't pdfLaTeX used for the blackbox and crypto synthesis? The pdfLaTeX-generated links and bookmarks in the hardware synthesis help navigating a lot. _______________________________________________ Linux4nano-dev mailing list [email protected] https://mail.gna.org/listinfo/linux4nano-dev http://www.linux4nano.org
