Archos 605wifi hacked (604wifi too probably)

[dm8tbr]

Bah, just get a wiki and update it often.

As already mentioned in this thread: openPMA-ng wiki and there is quite some activity on #x04 on irc.freenode.net
(I'd add this to my signature but this forum only allows for a ridiculously short signature...)

[grond]

Other information, the confirmation of the use of regular lock method to secure the flash. I have just disassembled the flashrw.ko module with IDA.
The INTEL_FLASH_lock looks like:

// 1st flash command : lock block (0x60 0x01)

// 2d flash command : Read Device Identifier (0x90)

According to the table on page 48 of the Intel-pdf you are right. I can't believe it... :)

[kitsonk]

Wonderful news!!!!!!!

I was able to swap roots on the device without a reboot!!!!!

So, this is what I did:

• Created an new rootfs.ext3
  Extracted the rootfs.cramfs.secure into it
  Added the new things from my buildroot (mainly chroot, vi, fdisk for now)
  Copied the new rootfs.ext3 to the device
  Created an install script that essentially pivot_root'ed the system and remounted everything back to its original position as well as re-installed arcwelder.
  Used the GFT method to run the script.
  After a rather lengthy pause, the "sharing" message came back on the device.
  The wireless seemed a little messed up, I might have to "restart" it in the future, but a suspend, using the power button, brought it back and I went in via ssh to verify the changes

Here is what my mount looks like now:

Code: Select all

/dev/ram0 on /old_root type cramfs (ro)
/proc on /old_root/proc type proc (rw,nodiratime)
devpts on /old_root/dev/pts type devpts (rw)
tmpfs on /old_root/tmp type tmpfs (rw)
sysfs on /old_root/sys type sysfs (rw)
/dev/hda1 on /old_root/mnt/data type vfat (rw,noatime,nodiratime,gid=66,fmask=0000,dmask=0000,shortname=mixed,utf8)
/dev/hda2 on /old_root/mnt/system type ext3 (rw,noatime,data=ordered)
/dev/loop0 on /old_root/opt type cramfs (ro)
/dev/loop1 on / type ext3 (rw,data=ordered)
none on /proc type proc (rw,nodiratime)
none on /sys type sysfs (rw)
none on /dev/pts type devpts (rw)
none on /tmp type tmpfs (rw)
tmpfs on /tmp type tmpfs (rw)
/dev/hda1 on /mnt/data type vfat (rw,noatime,nodiratime,gid=66,fmask=0000,dmask=0000,shortname=mixed,utf8)
/dev/hda2 on /mnt/system type ext3 (rw,noatime,data=ordered)

I realise I need to clean up my mounts... Hmmm... interesting.[/list]

[sideways]

Wouldn't it be better to convert to ext3, cramfs is read-only.

What edit did you apply to the busybox config to get vi?

Ok, I don't know how (yet) to mount an ext3 from a file. We don't have a spare partition and don't have sufficient free RAM to create another ram disk. I will look into some way of doing it.

As far as busybox... I don't *know* if it is the right way, but after my first build, I removed the cramfs files and decended into build_arm_nofpu/busybox-1.01 from the buildroot and did a make menuconfig. There I got all the rules I needed. Then I rm'ed my busybox binary, went back up to the buildroot and make'd again. I also needed a rout point which I changed by going into build_arm_nofpu/root.

You're right! If you run make menuconfig from /buildroot/build_arm_nofpu/busybox-1.01 you get a menu which allows sophisticated configuration of busybox - I was trying to do it manually (duh!)
Vi is under the Editors section. Thanks! (You then run 'make clean' & 'make' while still in that directory, then change back to /buildroot and run make again, if you now mount the compiled rootfs.*.cramfs, the modified busybox is in /bin, and there will be a vi link there too)

As for mounting an ext3 file - I showed how to do this for /opt in a post on page 8 (about half way down the page) - the /opt partition is the only one we can umount in a live session and then remount with rw permissions. (As long as things like opera, apdf, wireless file server aren't running, basically you have to be quick, since the wifi shuts down after a minute or so if you don't start up opera again)

(I also noticed that under the 'Linux Systems Utilities' section there is an option for 'forced filesystem unmounting' in umount)

EDIT just saw your post above on successfully remounting / on ext3 - well done!

[dm8tbr]

Wonderful news!!!!!!!

I was able to swap roots on the device without a reboot!!!!!

</snip>

Very nice indeed! One step further than the /opt approach!

Hmm, did you restart avos? Restarting the AVOS might add some interesting twist, but might not be that easy to accomplish.

Cheers

Thomas

PS: Could you document your approach somewhere in the openPMA-ng wiki please? Maybe just create a new page.

[bubu]

restarting avos is very easy jst following what I told in that forums some times ago...

just replacing the /sbin/reboot script by a script that does restart avos...

when this is done just killall -9 avos... and avos will restart without rebooting...

you have to shutdown some stuff.. (ifconfig eth0 down...) probably also rmmod some modules so your wifi works correctly again...

BuBU

[kitsonk]

restarting avos is very easy jst following what I told in that forums some times ago...

just replacing the /sbin/reboot script by a script that does restart avos...

when this is done just killall -9 avos... and avos will restart without rebooting...

you have to shutdown some stuff.. (ifconfig eth0 down...) probably also rmmod some modules so your wifi works correctly again...

BuBU

Yes, I know you mentioned that before. Now though, I can edit the avos_helper.sh to be whatever I want. I might try playing around with it...

My biggest problem is I can't remount /opt right now because I am out of loop devices. I can in theory make more now, but I am not exactly sure how.

[bubu]

why do u need more than 8 loop devices ?

1 additional is enough....

and then use things like

mount /mnt/system/newroot/opt /opt -o bind

to add things where u want...

[kitsonk]

why do u need more than 8 loop devices ?

1 additional is enough....

and then use things like

mount /mnt/system/newroot/opt /opt -o bind

to add things where u want...

There aren't actually 8 in /dev... there is only two created. I am not sure how to add more, though the kernel supports 8. Someone in the thread pointed out that the busybox mount doesn't have all the flexability necessary to mount to something that isn't in /dev.

Either way, it is becoming irrelivant, because I am experimenting and finding out the right things that I can kill and in what order that allows me to free up the old root /opt so I can mount it under my new root /opt. The biggest problem is killing avos just right and the wireless...

[bubu]

ok so best way to add more loop devices shoud be (limited to :

mkdir -p /mnt/system/newroot
cp -a /dev /mnt/system/newroot
mount /mnt/system/newroot/dev /dev -o bind

then mknod /dev/loop2 b 7 2
and so on...

of course make this match your new root fs

[kitsonk]

ok so best way to add more loop devices shoud be (limited to :

mkdir -p /mnt/system/newroot
cp -a /dev /mnt/system/newroot
mount /mnt/system/newroot/dev /dev -o bind

then mknod /dev/loop2 b 7 2
and so on...

of course make this match your new root fs

ok... now I have a loop2 that is part of my new rootfs.ext3. Now I am getting into problems where I lose wireless after pivot_root and avos doesn't realise it. I have to suspend avos and bring it back. But now, everytime I run Opera it crashes and reboots itself. I think I know what is going on, I have to get everything just right I think and now I think I can restart avos. I will update later after I get some lunch.

[sideways]

Also note that /dev/loop0 get freed when you umount /opt, so opt can just be remounted on the same loop device

(Note though that /opt can't be umounted while the smbpasswd screen is active, so putting that bit in an initialising script using GFT hack may be tricky (a forced umount might work, but the supplied umount in busybox doesn't support forced umounts so you'd need to compile one with that option set))

[grond]

Note though that /opt can't be umounted while the smbpasswd screen is active, so putting that bit in an initialising script using GFT hack may be tricky

Shouldn't that be possible with a background process started from the script which will comprise a periodic check whether /opt can be umounted (i.e. smbpasswd screen has closed) and, if yes, will mount the custom loop image instead? This is similar to what Coderjoe did for the epromtool-hack for the older 1.3 firmware.

[kitsonk]

Also note that /dev/loop0 get freed when you umount /opt, so opt can just be remounted on the same loop device

(Note though that /opt can't be umounted while the smbpasswd screen is active, so putting that bit in an initialising script using GFT hack may be tricky (a forced umount might work, but the supplied umount in busybox doesn't support forced umounts so you'd need to compile one with that option set))

It seems like avos doesn't really like me mounting /opt without it knowing about it. So my current theory is once I have re-esablished wireless, doing a suspend, I will then kill off everything useless, unmount /old_root/opt and start avos off again.

[xengren]

Is there access to /dev/mem?

[s0crate]

Is there access to /dev/mem?

On archos gen4 (/dev/mem, /dev/kmem) but not for gen5

[kitsonk]

Ok, I sucessfully got a replacement root file system. I had to do it in two stages, which I think grond might be right in that there is another way to set off a watching process to do the rest of the dirty work.

So this is essentially what I did:

• Took the rootfs.cramfs.secure and stripped it of it signature
  Extracted the rootfs.cramfs to old_root on another box using cramfsck
  Created a new rootfs.ext3 from dd'ing out 80mb of /dev/zero
  Turned it into ext3 using mkfs.ext3
  Mounted the rootfs.ext3 on my PC as new_root
  Moved the files from new_root
  Extracted my rootfs.cramfs from my modified buildroot to build_root
  Moved what I wanted from build_root to new_root (assuming it was better to keep as much of the original as possible)
  Created an old_root directory in the new_root (for pivot_root later on)
  Unmounted my rootfs.ext3
  Created an install script that did the following:
  • mounted my rootfs.ext3 to /mnt/data/Data/arcroot/new_root
    cd to /mnt/data/Data/arcroot/new_root
    pivot_root'ed between old_root and .
    mounted proc, sys, dev/pts, tmp
    did a mount -a
    moved everything from /old_root/tmp/* to /tmp (this is the key to keeping the wireless and other things stable)
    kill'ed sshd if it was running
    did the normal arcwelder install
  I created a second half install script that did the following:
  • kill'ed the avos_helper.sh
    killed any downloadd
    killed any upnpd
    killed any wpa_supplicant
    killed any udhcpc
    un-mounted /old_root/opt
    executed the avos_helper.sh
  I copied the install scripts and the rootfs.ext3 to my device in Data/arcroot as well as create the new_root directory for mounting
  Using GFT ran the first install script
  Once done, I ssh'ed into the device and ran the second install script

Once done, I still had to go a standby to get the wireless back. Still don't understand that, because I don't have to do it now after the re-root and moving the tmp files.

I guess the question now is what's next? I think we need to look into ioctl'ing the /dev/flashrw, right?[/list]

[grond]

I guess the question now is what's next? I think we need to look into ioctl'ing the /dev/flashrw, right?

Great work! Actually, this is the point were some people can start implementing a new environment e.g. qtopia-based which could be started on the 605 using the exploit. At the same time looking into the flash issue appears to be the best way to get complete control of the device. Also very helpful would be an exploit to start your scripts without need to find an access point and therefore make changes quasi-persistent (and make the non-wifi people join the bunch). However, everybody should be a bit paranoid about publishing the results as Archos is watching...

[bubu]

something important I think is not using /mnt/data to store the new rootfs img or something... else u will have pb to use the device as USB... or problems to restore from USB mode...

the problem is /mnt/system maybe too small...

so to me I will say next step is to find a way to have most of needed things into /mnt/system (or try to resize it using parted (like we did in openPMA)) and rootfs from there...

and find a way to intercept things to go from normal to USB mode and USB mode to normal, so things can be done the cleanest way... else u will have problems...

thx

[kitsonk]

For me, all I want is Ogg Vorbis support. A simple request, one I am even willing to pay for. That is my simple motivation. So if Archos is watching, you could easily solve this problem for me.

Also very helpful would be an exploit to start your scripts without need to find an access point and therefore make changes quasi-persistent (and make the non-wifi people join the bunch).

That I think we might have a hard time with. We can comb through what is there again and again, but there is very little that avos depends on. Oh well, enough thinking for today.