Bahattin TOZYILMAZ wrote: > ...or BLACK color in logo ... LOGO because it is small, > and contains an exact image we know.
What exactly do we know about the encoding? Is it the same as in unencrypted firmwares? What format did they use earlier? tof wrote: > hello everybody > > i'm still there ;) great! > i will probably need 2 months to achieve a working thing, > however i will need the help of ASM specialists, to write and compile the little parts of ARM code... Well, I'm an x86 assembly specialist, but not ARM. But in case there is nobody else who would do it, I would happily read through some ARM docs to help you out. I'll need to do that anyway to be able to participate in disassembling the appleOS and writing drivers etc. once we get some code to boot. By the way, I found an interesting firmware bug. No idea whether we could use that to exploit something, but obviously the FAT driver of the iPods firmware is not really FAT32 aware. I was just debugging a weird issue that the iPod just refuses to store play counts, and found out the following: - When the iPod tries to create a play countall clusters below number 65536 are used, the cluster number stored in the directory entry for that file wraps. The upper word is always stored as zero. The data of that file are placed in the correct location somewhere near ~7GB, but the directory entry points to somewhere near ~178MB. However, for some reason, the iPod deletes that directory entry again before I connect it to my PC, so no data corruption will occur. While tracing this, I also noticed that the iPod creates an iTunesLock file which is normally used by iTunes and some 3rd party iPod managers to ensure exclusive access to the iTunesDB file. But why does the iPod create and afterwards delete that file? As long as it isn't connected via USB it should know that it has exclusive access... And it does create and delete an empty file called $$TestFile$$ in the root directory. What the heck ist that one good for? Are there any news from the hardware approach? We're so close! Let's hope they used the same encryption again on Nano4G ;) Regards TheSeven _______________________________________________ Linux4nano-dev mailing list [email protected] https://mail.gna.org/listinfo/linux4nano-dev http://www.linux4nano.org
