On 23/12/2007, MsTiFtS <[EMAIL PROTECTED]> wrote: > Niklas Ulvinge schrieb: > > 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.
I think I've read on multiple locations that on the older models, the aupd was encrypted, but osos wasn't. It was on the new one's that osos got encrypted too, and thus leaving us no entry to run our own code. Isn't this true? And, someone with authorization could maybe put this todo list on the website if it's good enough? === TODO LIST === * 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 __ * Crypto attacks > > > > 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) Ah, ok, to bad... > > 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. Hmm, interesting... > 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. LaTeX doesn't seem to be very well known... but IMO it's the best format at document editing. Niklas Ulvinge _______________________________________________ Linux4nano-dev mailing list [email protected] https://mail.gna.org/listinfo/linux4nano-dev http://www.linux4nano.org
