Hi,

I did think a bit about the objectives of the project lately. I would
like to share my view in hope to get a deal with all of you (and maybe
clear the view of all of us).

First of all, we would like to be able to disable the ciphering process
when the firmware is loaded in the RAM.

If we think about what the Apple's engineers had in mind when building
the cipher around the firmware it was more or less to prevent any
intruder to introduce some malware/trojan in the Apple's firmware.

And actually the system does its job very well. Moreover, it's not our
job to find weaknesses in this system (except if we need to).

What we really need is the magic combination that prevent the booting
sequence to run the deciphering algorithm on the firmware.

I can bet ten bucks that it's probably triggered through one or several
fields of the header of the firmware files. Maybe a brute force attack
trying all the combinations of each field and a reliable test that can
tell us if the ciphering algorithm has been called or not would make it.

Second, we need to get information on the boot process to code a proper
boot sequence for the iPod. For this, either we manage to capture a dump
of the RAM at runtime, or we have to break the key (which much more
difficult and would be also bad for Apple). At last, if someone can get
the documentation of the boot system we will jst use it (we won't ask
where it comes from, trust me).

Third, write the specification of the boot sequence and let another team
code the boot loader (it's usual to proceed like this in reverse
engineering for legal reasons).

So, in brief:
1) Disable the cipher algorithm;
2) Get the unciphered boot loader;
3) Write it's specification.

Any comments on these thoughts ?

That's all for tonight, folks ! :)
-- 
Emmanuel Fleury              | Office: 211
Associate Professor,         | Phone: +33 (0)5 40 00 35 24
LaBRI, Domaine Universitaire | Fax:   +33 (0)5 40 00 66 69
351, Cours de la Libération  | email: [EMAIL PROTECTED]
33405 Talence Cedex, France  | URL: http://www.labri.fr/~fleury

_______________________________________________
Linux4nano-dev mailing list
[email protected]
https://mail.gna.org/listinfo/linux4nano-dev
http://www.linux4nano.org

Reply via email to