The reason why 3g nano and classic games are not yet cracked is the encrypted firmware. It's a pretty sophisticated system.
tof schrieb: > MsTiFtS a écrit : > >> Well, I seriously doubt that. To my knowledge the 3G also has a utility >> flash, >> > i do not see any.... > http://insidetronics.blogspot.com/ > http://www.ifixit.com/Guide/iPod/iPod-Nano-3rd-Generation/ > > any source, not known to me ? > > > >> and the security issues seem to be very important to apple, as >> they not only prevent installing iPodLinux but only prevent you from >> cracking their music/games DRM scheme. They know what they are doing! >> >> > cracking DRMs has nothing to do with restraining boot on ipods. > DRMs will be surpassed by the music loader (i mean the soft which puts > the music on the pod...)... > and as far as i know, on other ipods/iphone devices, the crypting has > been easily cracked because of the easy reading of te boot (i did not > inform extensively, so please correct me...)... > > christoph > > > >> tof schrieb: >> >> >>> my idea is : >>> >>> on the 2G, there was a utility flash, because the chip was probably not >>> able to load from main memory. redesign of the chip was launched, but >>> far too slow to fit with the dev time of the nano. >>> on the 3G, the modified chip was ready, and the boot flash skipped. >>> >>> i doubt of security reasons being too important. >>> >>> the dissk manager within the bios will then map only a part to the usb, >>> which is anyway the case because of bad blocks and so on. >>> the only reason for what the biggest part of the firmware is within the >>> partition visible to the PS is to assure easy update, probably... >>> >>> >>> christoph >>> >>> >>> >>> >>> >>> MsTiFtS a écrit : >>> >>> >>> >>>> On the 2G there definitely is a utility flash. We can not tell for sure >>>> whether the loader is in there, but as the size of the update image >>>> roughly matches the size of the chip, I bet it is in there. >>>> As far as I know the ARM has only a few KB of internal RAM and no ROM at >>>> all. I think that's the same on the 3G, AFAIK there is also a utility >>>> flash. >>>> >>>> Don't ask me where the memory size difference comes from, but on my 2G >>>> 8GB I have 7744MiB, that's about 8120MB, of visible flash. >>>> I quickly flicked through your datasheet, but I didn't verify that these >>>> chips are indeed used in the nanos. >>>> So we have 4x 2048MiB + 64MiB redundant memory. I don't know whether the >>>> ARM can access the redundant area, but hiding a boot loader in there >>>> would be way too risky. >>>> So we have 8192MiB of usable space. That's roughly 8590MB. So we have >>>> about 470MB of hidden memory, 469762048 bytes to be exact, that's >>>> exactly 448MiB. >>>> I would guess that they are used as some kind of an additional >>>> redundancy, as that's way too large to just hold a bootloader, and what >>>> would the utility flash then be good for? >>>> >>>> tof wrote: >>>> >>>> >>>> >>>> >>>>> Hello boys (and girls) >>>>> >>>>> >>>>> >>>>> i m new here, but a lot of ENSEIRB people know me... >>>>> >>>>> >>>>> My theory is : why could the loader from the 3G not be in the user flash ? >>>>> >>>>> imagine designing the nano 3G. You have to put away the the boot flash >>>>> (obvious costs reasons) >>>>> two solutions : >>>>> >>>>> 1. Rom in the SOC >>>>> easy to realize if the chip maker has already this kind of solution. i >>>>> did not check whether this exists on the nano2G controller type (if doc >>>>> exists...) >>>>> if not, this is a complete redesign of the chip, which could take a very >>>>> long time, and huge effort, because 8 Mbit of flash is probably not so >>>>> easy to add on a process that was not used for flash memory. >>>>> mask rom is easier to do, but not very convenient. >>>>> remember : such a project is time tough because of the very short dev >>>>> time. >>>>> >>>>> 2. use the user FLASH >>>>> in my opinion, a good option because getting rid of another memory. >>>>> redesign of the chip perhaps necessary if it cannot already boot from >>>>> this memory. >>>>> >>>>> the drawback of security is probably less important than the unit cost. >>>>> >>>>> >>>>> i made some investigations on the flash size : >>>>> >>>>> http://insidetronics.blogspot.com/ >>>>> >> It is a 8GByte chip, with four 2GByte dies stacked. In the 4Gbyte >>>>> iphone version, the chip is the K9MCG08U1M, that is a 4GByte, dual die >>>>> part. >>>>> >>>>> http://218.22.45.5/misc/Books/K9LAG08U0M_0.7.pdf >>>>> here we see the organisation of the flash : >>>>> 4* 0x100 000 *(0x800+0x40) Bytes = 0x200 000 000 B + 0x10 000 000 B >>>>> (reserve for replacing bad blocks) >>>>> >>>>> >>>>> the spec gives also the max bad block rate (new chip, some can appear >>>>> later) : 4* 200(max bad blocks) * 256K (block size)= C8 * 4 * 0x40000 = >>>>> C 800 000 Bytes >>>>> >>>>> conclusion : total usable bytes is 0x200 000 000 + 0x10 000 000 - >>>>> 0xC800000 = 0x203 800 000 = 8 648 654 848 >>>>> a little over 8G. assume apple rounded the use to 0x200 000 000 due to >>>>> size reserved for the bad block table ;) >>>>> >>>>> on the other hand the visible size is a lot less: >>>>> on my ipod 3G 8gig, fdisk -l gives : >>>>> >>>>> >>Disque /dev/sdc: 7952 Mo, 7952142336 octets >>>>> >>217 heads, 32 sectors/track, 279 cylinders >>>>> >>Units = cylindres of 6944 * 4096 = 28442624 bytes >>>>> >>>>> 7952142336 Bytes = 0x1D9 FC1 000, less than the flash size >>>>> >>>>> the difference is : 0x 26 03F 000 = 637 792 256 bytes >>>>> >>>>> Please correct me if i made some error or misinterpretation.... >>>>> perhaps there is some space lost in the mounting process, etc... >>>>> >>>>> so nearly 600 meg are not in our view. this seems non negligible to me. >>>>> >>>>> >>>>> so what next ? >>>>> >>>>> a good idea could be to check if such a difference exists on the 2G. if >>>>> not, could be very good. (better to verify on the small size ones.) >>>>> then its relatively easy to desolder and read the flash. >>>>> >>>>> >>>>> Regards >>>>> >>>>> christoph(e) riehl >>>>> >>>>> >>>>> _______________________________________________ >>>>> Linux4nano-dev mailing list >>>>> [email protected] >>>>> https://mail.gna.org/listinfo/linux4nano-dev >>>>> http://www.linux4nano.org >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Linux4nano-dev mailing list >>>> [email protected] >>>> https://mail.gna.org/listinfo/linux4nano-dev >>>> http://www.linux4nano.org >>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Linux4nano-dev mailing list >>> [email protected] >>> https://mail.gna.org/listinfo/linux4nano-dev >>> http://www.linux4nano.org >>> >>> >>> >>> >> _______________________________________________ >> Linux4nano-dev mailing list >> [email protected] >> https://mail.gna.org/listinfo/linux4nano-dev >> http://www.linux4nano.org >> >> >> > > > _______________________________________________ > Linux4nano-dev mailing list > [email protected] > https://mail.gna.org/listinfo/linux4nano-dev > http://www.linux4nano.org > > _______________________________________________ Linux4nano-dev mailing list [email protected] https://mail.gna.org/listinfo/linux4nano-dev http://www.linux4nano.org
