kitsonk wrote:You are just being too realistic... ;)
Sorry, I just know that archos r&d invested quite some work into making the x04/x05 pretty hard to hack. They even hired a new developer just for the task.
Last summer, dm8tbr, me and some guys from the archopen project spent some time analysing the x04 and concluded that it probably wasn't easy to hack (we didn't have the root shell at the time, though). IIRC we found an avi that made the PMA freeze and the x04 reboot. So we thought that perhaps AVOS could be exploited using that. dm8tbr surely remembers better as he found the broken/breaking avi...
So, where are we... We know that the flashrw module is instructed during boot to lock down most if not all of the flash.
Everything from 0x0 to 0x10000 and from 0x30000 to 0x200000. That is the first two megabytes of the flash apart from a tiny hole between 0x10000 and 0x30000 which is 128K large (if my mental arithmetic doesn't fail me).
We suspect only signed modules can be insmod'ed into the kernel, though we aren't sure.
Somebody should make sure. I haven't got a 605...
We need to figure out how the / gets mounted, because it wouldn't get mounted by avos. I didn't see in those startup details where / got mounted. I only see the two physical partitions.
Hm, since linuxrc is used for init IIRC and it resides somewhere on the harddisk, the kernel should mount / during kernel init. Not sure whether this leaves a trace in dmesg but it probably should.
nonsense. On the PMA the linuxrc was in the cramfs which was loaded to RAM by the bootloader before the kernel init was started. So the kernel found its root device at a predefined (at compile time) place in RAM. Not sure how it is done in the 605. Perhaps the hidden second partition is used as /
If we ever get hold of the bootloader binary (it probably can be read out completely), there might be a slight chance to trick the bootloader to branch into a part that is not protected (e.g. by damaging the partition table in a certain way that the bootloader bails out with an error), the hopefully unprotected code that is executed in the error case could be made to continue loading the (modified) rootfs. This is only a very academic possibility, though. It would be nice to know what resides in the 128K that are left unprotected. Probably the background image during boot... ;)