Archos 605wifi hacked (604wifi too probably)

[fiat]

If anyone has a copy of the 1.7.13 firmware laying around, could they md5 it so we know if archos makes changes to it without changing the revision number.

I got this covered.

[bmn]

you think Archos might have implemented a backdoor, the possibility to "push" updates or patches on the device once it's online without the users consent ?

maybe the wlan communication should be checked with a packet sniffer ?

just a (paranoid ) idea...

[sideways]

If anyone has a copy of the 1.7.13 firmware laying around, could they md5 it so we know if archos makes changes to it without changing the revision number.

(Run from Fedora 8 )

Code: Select all

[[email protected]]# ls -l firmware_a605.aos 
-rw-r--r-- 1 root root 44292936 2008-01-02 19:12 firmware_a605.aos
[[email protected] data]# md5sum firmware_a605.aos
f8ce8e068c45e6763526a322dcb112fd  firmware_a605.aos
[[email protected]]# 

[ethilbert]

BTW: from reading through the archos pages about the 605 I remember reading something about password protected notes. Is the password input for that by chance as broken as the one for the access points? Then we would have a way of performing the hack without having to connect to an access point which in addition would make people not having the wifi version be able to join the party...

Is it possible to use the password option for content found under settings instead of an access point. Just a thought.

[grond]

Hmmmm... It seems like it might not have remounted properly on cold restart. I had to flash the whole firmware again with the .aos file. That rewrote the cramfs.secure files and now they match the originals.

This is very interesting and during our first thoughts about hacking the x04 we decided that the update process is an interesting target. Obviously, the flash can be written to after boot which is good news because if the update process does so, so can we (the flash chip comprises a security function which makes it 100% read-only after boot if the bootloader sets a specific bit in the flash; if this is done early during the boot process, there is no way of hacking the bootloader, however, archos have chosen to not do so). Also obviously, the update files will be checked prior to performing the update. Perhaps there is a slim chance that the program doing the update can be extracted, modified to not abort when the signature check has failed and put into a custom-made /opt from where it could be started. Then, if the structure of the firmware and the bootloader is understood well enough (hardest bit), the modified update program could be used to flash the bootloader to load any custom firmware. Hey, we only need the guys who hacked the Xbox360 to help us on this... ;(

[fiat]

A couple notes:

1) If you examine the kernel from the GNU buildroot tree that is provided in the Archos GPL tarball, you can find out an amazing amount about how the Archos works, even in just looking at the config file used to build the Archos. For instance, as a previous poster mentioned, the cramfs.secure files aren't encrypted, they're simply signed -- meaning that since the GPG keys are on the disk, it could be possible to just replace them and sign your own cramfs filesystems

2) There's a lot of good information in the linux/davinci usenet forums, people who do this professionally posting their techniques and problems, especially stuff regarding the flash area and how it works. From it I've been able to better understand how the board works. Obviously this would be dangerous without testing, but, that's how they do it. What I don't know/understand currently is how they could recover from bricking it, either there's some way to flash it via USB using tool or something else

3) Unconfirmed, the Davinci ships with 10/100 ethernet capabilities, potentially there could be pins on the board to connect a cable, if this were the case it may be possible to get it to tftp/bootp off the network, which would be the ideal method for homebrew hacking since you could reset it in the case of a failed boot up

4) The board includes a serial port, if you're a dock-station owner you'll notice the headphone jack on the back of the device -- this could be an alternative way of gaining access if you had the cable. It's probably configured as a serial controller for set-top boxes -- I'm curious to see what the differences in the running system are when attached to the docking station, haven't explored this yet..

http://focus.ti.com/paramsearch/docs/pa ... amilyId=44

My current tasks are:

* Trying to figure out the code signing stuff, possibly going to try intercepting a firmware upgrade to get the contents of the archive

* Complete cross-compile environment, do a complete package build and see what I can move over and have work (rsync, syslog, etc)

* Disassemble Archos, take pictures of board and see what may exist on the circuit board that could aid the efforts

* Upgrading 30gb to larger size HDD

[serag]

* Disassemble Archos, take pictures of board and see what may exist on the circuit board that could aid the efforts

Here's a thread where someone already partially disassembled the 30gig Archos
http://forum.archosfans.com/viewtopic.php?t=10826

and to connect the 1.8 hd to a pc if needed
http://cgi.ebay.com/iPod-TOSHIBA-1-8-ZI ... dZViewItem

[kitsonk]

1) If you examine the kernel from the GNU buildroot tree that is provided in the Archos GPL tarball, you can find out an amazing amount about how the Archos works, even in just looking at the config file used to build the Archos. For instance, as a previous poster mentioned, the cramfs.secure files aren't encrypted, they're simply signed -- meaning that since the GPG keys are on the disk, it could be possible to just replace them and sign your own cramfs filesystems

Yes, I noticed this. The problem right now is that I see it make the bits that make the rootfs.cramfs and the optfs.cramfs but I don't see how it then transfers it to *.cramfs.secured. I think the keys that avos uses are either in the flash or in avos binary. Though I am hunting through that stuff now.

[grond]

meaning that since the GPG keys are on the disk, it could be possible to just replace them and sign your own cramfs filesystems

Why should the keys be on the disk? I'd rather expect them to reside in the flash...

2) There's a lot of good information in the linux/davinci usenet forums, people who do this professionally posting their techniques and problems, especially stuff regarding the flash area and how it works.

I know that Archos R&D used to write in linux-embedded newsgroups and developer forums when they were developing the PMA. Perhaps they are also present in the davinci forums... :)

What I don't know/understand currently is how they could recover from bricking it, either there's some way to flash it via USB using tool or something else

AFAIK in the 604 all "surplus pins" are not connected through the PLB. Thus, it is impossible to connect to anything interesting... :(

* Upgrading 30gb to larger size HDD

There are surely people who are interested in that but remember that this is something that 3rd party people such as traders will exploit to convert cheap 30G models to higher capacity models. Archos put the protection in order to ensure that the price difference between the low-capacity and the high-capacity models goes into their pockets and not into that of traders. And I rather have Archos earn the extra money than people who buy a load of cheap models and a number of high-capacity harddisks...

[fiat]

Well, after poking around a bit the HD upgrade for the 30gb model seems like a non-starter -- 30gb 1.8" ZIF drive is 4mm high, anything larger is 8mm high, getting the back of the case on and off is tough enough as it is, so probably wouldn't work.

And, I doubt anyone would make money buying cheap ones and upgrading their drives, Archos gets the drives in bulk at wholesale, I suppose someone else could do the same but it'd be a significant investment to make it your business model.

Re: Keys are in flash, not disk, maybe so, but you can rewrite flash just the same. To put it simply, signed code is a non-issue, merely an inconvenience for the time being.

Update on the build environment, I tried CentOS5, ran into a bunch of GCC backwards computability issues regarding pedantic behavior on double defines on static variables, going to simplify things by going down to CentOS4.5 which is what I originally built my build-tree on. It looks like it'll be pretty big tho, but putting in all the important stuff for poking the Archos from Linux.. Hopefully will have this done tonight, but will probably have to bittorrent it.

[grond]

Re: Keys are in flash, not disk, maybe so, but you can rewrite flash just the same.

Will that be possible with a kernel which we can't take over (at least not by inserting custom-made and therefore unsigned kernel modules)? I assume that in order to write to flash you will have to get access to the kernel. Or trick the update program to write to the flash for you.

[kitsonk]

I can confirm the dc.dat is the "DEVCERT" that is required by MS DRM for their media.

UPDATE As well as sst.dat appears to be part of the MS DRM.

So other files that are part of /mnt/system:

• HDD_STORE00.HDS some sort of hard drive file storage cache used by AVOS
  NDX5.AVX Part of the avos cache of songs as well
  cpio.secure signed cpio file.
  dc.dat MS DRM Certificates
  etc/wpa_supplicant cache for wireless configs
  etc/ip_config cache for wireless networks
  lang_xx.alz language localisation files
  opera_home/* Opera stuff...
  optfs.cramfs.secure the signed /opt cramfs
  posfs.cramfs.secure the signed /pos cramfs
  providers.xml localised stores for Archos
  rootfs.cramfs.secure the signed / cramfs
  sc.dat part of the MS DRM
  sst.dat part of the MS DRM

So it doesn't seem the keys are on /mnt/system, which means they have to be in the flash somewhere. I tried to dd out the /dev/flashrw but dd said the device wasn't there.

So the problem is, how to inject something to watch avos as it begins to process an .aos file. It is a bit of a catch-22 in my mind. Can't modify the avos_helper.sh or avos without changing the rootfs, can't change the rootfs. So we need to find the way the OS interfaces with the flash. Right?

[fiat]

Re: Keys are in flash, not disk, maybe so, but you can rewrite flash just the same.

Will that be possible with a kernel which we can't take over (at least not by inserting custom-made and therefore unsigned kernel modules)? I assume that in order to write to flash you will have to get access to the kernel. Or trick the update program to write to the flash for you.

We've got root access, therefor full access to ring 0. There's no privilege separation or security stuff from what I can see. Flash is just another storage area in the device. You can write to it if you know how.

[grond]

We've got root access, therefor full access to ring 0. There's no privilege separation or security stuff from what I can see. Flash is just another storage area in the device. You can write to it if you know how.

Hm, I know that the PMA was hacked by inserting a kernel module which copied the flash to hdd and another one for writing back the bootloader to flash once it was hacked. My understanding was that the flash could only be accessed from kernel space. Even if root is privileged, root cannot just touch everything there is. And in the 605 the kernel is protected so that you can only insert signed modules. But I hope to be wrong.

[kitsonk]

Hm, I know that the PMA was hacked by inserting a kernel module which copied the flash to hdd and another one for writing back the bootloader to flash once it was hacked. My understanding was that the flash could only be accessed from kernel space. Even if root is privileged, root cannot just touch everything there is. And in the 605 the kernel is protected so that you can only insert signed modules. But I hope to be wrong.

I did insmod /lib/modules/flashrw.ko and was able to load the flashrw module. Don't know what that buys us... The device is now there but I can't dd it... it complains about it being an invalid argument.

Update
Ok, I was able to do a: mount /dev/flashrw /mnt/data/Data/flash -t ramfs. Again, don't know what that buys us. Off to read more about ramfs, I am learning a hell of a lot.

Update Again
Ooops... I realise how dumb that was now... DOH!!

Update 3
Ok, back to dd'ing the /dev/flashrw after the inmod. I tried increasing the bs, but ran out memory. Basically I continue to get an "Invalid argument" or a "memory exhausted" when trying to dd the /dev/flashrw. At least the device is there now, just don't know how to access it.

[fiat]

Added page on setting up cross-compiling environment:

http://code.google.com/p/arcwelder/wiki ... nvironment

Requires intermediate Linux knowledge, if you've never installed linux, you probably won't be able to use it. If you've installed Ubuntu once, you may be able to pull it off if you're comfortable in a shell.

[fiat]

We've got root access, therefor full access to ring 0. There's no privilege separation or security stuff from what I can see. Flash is just another storage area in the device. You can write to it if you know how.

Hm, I know that the PMA was hacked by inserting a kernel module which copied the flash to hdd and another one for writing back the bootloader to flash once it was hacked. My understanding was that the flash could only be accessed from kernel space. Even if root is privileged, root cannot just touch everything there is. And in the 605 the kernel is protected so that you can only insert signed modules. But I hope to be wrong.

Eh. Whatever security there is trivial. It's Linux. If you're root there's nothing you can't do at some point, either pre or post boot. I stand by my assertion that this is a non-issue. But if I'm wrong, I owe you a beer.


I'll go out on a limb and posit that once I get the flash writing tools compiled up they'll work in both read and write capacity without any jiggering. If they can update their firmware with software alone, so can we.

I've been in and around software development for a couple years now and the one thing I know is that people do the bare minimum to meet requirements documents, now imagine what they do when they're not getting paid.

That's Linux.

[fischju]

Wow, this is going quite fast. But I have a 4GB, which has an SD card. Does it have the same internal components? Will all of this work fine with it?

[sideways]

Added page on setting up cross-compiling environment:

http://code.google.com/p/arcwelder/wiki ... nvironment

Requires intermediate Linux knowledge, if you've never installed linux, you probably won't be able to use it. If you've installed Ubuntu once, you may be able to pull it off if you're comfortable in a shell.

Thanks for that fiat, I was too dumb to think of poking around make menuconfig for package selections (duh)

In some cases you can just copy the compiled binary to /mnt/data/Data and it will run if you specify the full path at the ssh command line (eg /mnt/data/Data/gawk) The binaries will be in /bin or /usr/bin if you mount the compiled rootfs.arm_nofpu.cramfs (using mount -o loop -t cramfs)

Many packages need fiddly library manipulation, since on the Archos LD_LIBRARY_PATH=/opt/usr/lib by default and this is read-only. eg nano & bash binaries need libncurses.so.5, this is created in the /lib directory of rootfs.arm_nofpu.cramfs, you can copy it to /mnt/data/Data and then execute 'export LD_LIBRARY_PATH=/opt/usr/lib/:/mnt/data/Data/' at the ssh prompt (or follow a previous discussion about making /opt writeable)


nano keeps giving an error about not being able to start xterm.

I would like to get vi working, but it's not included in the Archos GPL package, guess I will have to look at manually adding it.

Python compiles and runs but seems very limited.

Code: Select all

/ # ls /mnt/data/Data/
gawk    pgawk    dmesg.txt   igawk    mounts.txt    pgawk-3.1.5    bash   file_list.txt   libncurses.so.5    nano    python

/ # /mnt/data/Data/bash
/mnt/data/Data/bash: can't load library 'libncurses.so.5'

/ # export LD_LIBRARY_PATH=/opt/usr/lib/:/mnt/data/Data/

/ # /mnt/data/Data/bash
bash-3.00# help
GNU bash, version 3.00.16(1)-release (arm-unknown-linux-gnu)
These shell commands are defined internally.  Type `help' to see this list.
Type `help name' to find out more about the function `name'.
Use `info bash' to find out more about the shell in general.
Use `man -k' or `info' to find out more about commands not in this list.

A star (*) next to a name means that the command is disabled.

 %[DIGITS | WORD] [&]               (( expression ))
 . filename [arguments]             :
 [ arg... ]                         [[ expression ]]
 alias [-p] [name[=value] ... ]     bind [-lpvsPVS] [-m keymap] [-f fi
 break [n]                          builtin [shell-builtin [arg ...]]
 caller [EXPR]                      case WORD in [PATTERN [| PATTERN].
 cd [-L|-P] [dir]                   command [-pVv] command [arg ...]
 compgen [-abcdefgjksuv] [-o option complete [-abcdefgjksuv] [-pr] [-o
 continue [n]                       declare [-afFirtx] [-p] [name[=val
 dirs [-clpv] [+N] [-N]             echo [-neE] [arg ...]
 enable [-pnds] [-a] [-f filename]  eval [arg ...]
 exec [-cl] [-a name] file [redirec exit [n]
 export [-nf] [name[=value] ...] or false
 fc [-e ename] [-nlr] [first] [last for NAME [in WORDS ... ;] do COMMA
 for (( exp1; exp2; exp3 )); do COM function NAME { COMMANDS ; } or NA
 getopts optstring name [arg]       hash [-lr] [-p pathname] [-dt] [na
 help [-s] [pattern ...]            history [-c] [-d offset] [n] or hi
 if COMMANDS; then COMMANDS; [ elif kill [-s sigspec | -n signum | -si
 let arg [arg ...]                  local name[=value] ...
 logout                             popd [+N | -N] [-n]
 printf format [arguments]          pushd [dir | +N | -N] [-n]
 pwd [-PL]                          read [-ers] [-u fd] [-t timeout] [
 readonly [-af] [name[=value] ...]  return [n]
 select NAME [in WORDS ... ;] do CO set [--abefhkmnptuvxBCHP] [-o opti
 shift [n]                          shopt [-pqsu] [-o long-option] opt
 source filename [arguments]        test [expr]
 time [-p] PIPELINE                 times
 trap [-lp] [arg signal_spec ...]   true
 type [-afptP] name [name ...]      typeset [-afFirtx] [-p] name[=valu
 ulimit [-SHacdflmnpstuv] [limit]   umask [-p] [-S] [mode]
 unalias [-a] name [name ...]       unset [-f] [-v] [name ...]
 until COMMANDS; do COMMANDS; done  variables - Some variable names an
 wait [n]                           while COMMANDS; do COMMANDS; done
 { COMMANDS ; }                    
bash-3.00# exit

/ # /mnt/data/Data/nano /mnt/data/Data/mounts.txt 
Error opening terminal: xterm.

[fiat]

I haven't finished my buildroot yet, doing a kitchen sink build -- can you run the following in Python and paste the results?

(It needs to be in interactive mode..)


$ python
>>> help()
help> modules