Archos 605wifi hacked (604wifi too probably)

[Proteus93]

I'd just be eager to see if Flash in the browser can be updated through all of this. It'd be nice to be able to run sites like Hulu out to the television.

Great efforts so far, though, guys. My capacity for doing anything with Linux filesystems is basically nil.

[Hadakajime]

Ok, dissecting the modules, here are my guesses:

• hdpwrd ?????

harddisk power demon

i wouldve thought that was something like harddisk password but thats me. this is so interesting!

3am here...

[kitsonk]

Ok... here are the hexdumps of the *.secure files...

Code: Select all

$ hexdump -C -n 192 cpio.secure

Code: Select all

00000000  f0 89 e5 da 00 04 00 00  10 99 d3 d7 82 11 c5 92  |................|
00000010  0d 8c 08 28 1c ac b6 48  01 e6 28 7a fe f2 7b 8e  |...(...H..(z..{.|
00000020  6c 15 b7 18 ca 38 30 f7  6e 14 3c fc 58 be 55 53  |l....80.n.<.X.US|
00000030  68 c0 eb 40 5d 19 ed 33  62 54 72 66 eb b3 0c 71  |[email protected]]..3bTrf...q|
00000040  ff ef e2 4a fa ef d7 4a  9c 8c 11 67 0e b8 cc 78  |...J...J...g...x|
00000050  da e5 72 e2 b0 70 de a3  53 2d 05 b0 2c cb 2f 14  |..r..p..S-..,./.|
00000060  79 52 87 a6 96 f2 a5 40  42 ce 57 ad ef 8d cd 55  |[email protected]|
00000070  1d 61 2e 6b 20 66 64 a6  0e ba 41 ce 40 5e f3 a0  |.a.k [email protected]^..|
00000080  59 fc e4 ef 70 1d d2 7f  00 00 00 00 90 30 17 00  |Y...p........0..|
00000090  00 01 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

Code: Select all

$ hexdump -C -n 192 rootfs.cramfs.secure

Code: Select all

00000000  d5 84 c2 d3 00 04 00 00  14 81 56 94 de c7 ed ec  |..........V.....|
00000010  ee 9f f1 05 05 24 28 5e  aa f8 fe ac 40 7f 32 41  |.....$(^[email protected]|
00000020  4a 15 52 ca 8c 1d fd 50  66 0f de 6b f8 6a a4 3d  |J.R....Pf..k.j.=|
00000030  17 56 14 d1 08 a3 1e 8a  f6 3a 4c 45 63 31 2b 9e  |.V.......:LEc1+.|
00000040  8f 78 d2 33 6d 1b c6 a8  85 c4 63 62 9c f0 f3 cd  |.x.3m.....cb....|
00000050  5a c6 dc a8 dd 20 05 e3  7b 73 c6 c3 d4 87 78 90  |Z.... ..{s....x.|
00000060  e6 53 85 7d 9e 8f c9 59  cc bd e5 6d 61 ea c8 c7  |.S.}...Y...ma...|
00000070  eb 4d 03 80 9a 11 a5 d0  9e 33 b2 26 e9 a9 7c de  |.M.......3.&..|.|
00000080  8f 28 de 1e 41 ea 8d 99  00 00 00 00 00 b1 fc 00  |.(..A...........|
00000090  00 01 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

Code: Select all

$ hexdump -C -n 192 optfs.cramfs.secure

Code: Select all

00000000  d5 84 c2 d3 00 04 00 00  07 e7 d5 51 ac b2 e0 1f  |...........Q....|
00000010  09 18 fe 45 ef 8d 34 08  01 35 52 43 cc 06 6a 27  |...E..4..5RC..j'|
00000020  15 22 a5 23 d4 a5 c6 d5  57 6f cd 34 a6 3a 36 1e  |.".#....Wo.4.:6.|
00000030  d7 05 47 96 98 6e e8 b6  6b 0c d1 12 87 ab 85 6e  |..G..n..k......n|
00000040  33 ce 7f 2e 11 53 08 8f  21 f1 5d 20 24 dc 55 81  |3....S..!.] $.U.|
00000050  c6 4b ed fd 98 0b ac 12  fa 4a 7a cc f9 63 6b f9  |.K.......Jz..ck.|
00000060  9b 62 9a 4a 47 ab e1 c6  92 e2 f4 a0 f7 57 46 97  |.b.JG........WF.|
00000070  3a f5 1e 73 42 45 63 e4  a8 0e db 65 4c be aa a2  |:..sBEc....eL...|
00000080  e4 4d 67 dc 50 26 c1 1b  00 00 00 00 00 d0 c5 00  |.Mg.P&..........|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

Code: Select all

$ hexdump -C -n 192 posfs.cramfs.secure

Code: Select all

00000000  d5 84 c2 d3 00 04 00 00  2f a2 bd 8e 7c 76 c0 15  |......../...|v..|
00000010  4f 08 f6 93 7a 37 7e 4c  17 0c 5b 47 47 c4 bd d7  |O...z7~L..[GG...|
00000020  84 6b 3e 3b 31 bb 59 d1  6b 5d 09 44 7f cf 7e 89  |.k>;1.Y.k].D..~.|
00000030  e4 6e e4 ef 82 85 8a c1  9d 37 5b 23 5a 4c ee ad  |.n.......7[#ZL..|
00000040  71 08 f6 0f eb 28 c6 18  55 ac 0c ee 87 2b 41 1e  |q....(..U....+A.|
00000050  e9 31 c7 e7 df 7d cc f3  cf 2c b2 f0 6d f7 83 09  |.1...}...,..m...|
00000060  55 2a 61 fd 73 d9 7d d1  99 cf c1 99 0b a3 55 66  |U*a.s.}.......Uf|
00000070  e1 6f 4c a5 90 32 a5 a4  ec d0 b3 a6 25 43 67 41  |.oL..2......%CgA|
00000080  76 e0 09 16 db 8e 7f 9b  00 00 00 00 00 90 8f 00  |v...............|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

[grond]

Ok, dissecting the modules, here are my guesses:
hdpwrd ?????

harddisk power demon

i wouldve thought that was something like harddisk password but thats me.

Also a valid guess. Is there a size attached to "hdpwrd"? I.e., is the list gathered from a list of loaded modules or from the list of kernel modules in /lib/modules?

I know they have a kind of power management thread in the PMA harddisk driver (which was mostly disfunctional) because I have spent a lot of time with the PMA harddisk driver and only recently added a better working power management. However, this thread would occupy only very little kernel space.

Coming to think of the hdd protection which was introduced to keep traders from upgrading the low-capacity models prior to selling them to the public and cashing in on this instead of Archos selling the high-capacity models, the protection should reside in the bootloader and not in the kernel. At least, I cannot imagine the system booting with the new larger harddisk and then telling you that it cannot run from the harddisk. Also, AFAIK the harddisks aren't password protected because you can swap two 30G drives from two 30G models without any of the two complaining about it.

[kitsonk]

I know they have a kind of power management thread in the PMA harddisk driver (which was mostly disfunctional) because I have spent a lot of time with the PMA harddisk driver and only recently added a better working power management. However, this thread would occupy only very little kernel space.

Coming to think of the hdd protection which was introduced to keep traders from upgrading the low-capacity models prior to selling them to the public and cashing in on this instead of Archos selling the high-capacity models, the protection should reside in the bootloader and not in the kernel. At least, I cannot imagine the system booting with the new larger harddisk and then telling you that it cannot run from the harddisk. Also, AFAIK the harddisks aren't password protected because you can swap two 30G drives from two 30G models without any of the two complaining about it.

lsmod...

Size is 2269 and the module in the files system is hdpwrd.ko with a file size of 6544

[grond]

Ok... here are the hexdumps of the *.secure files...

Looking at these won't take you anywhere. These files are cryptographically protected and without knowing the private key you won't be able to ever create a file that will be accepted by the bootloader/kernel. It was like this on the PMA and hacking of the PMA relied on the check of the signature being disabled, however, on the 605 you cannot simply insert a hombrew kernel module into the kernel that will read out and write back the bootloader from/to flash as you could with the PMA... :(

[layzee]

# HDD power management
insmod /lib/modules/hdpwrd.ko

[kitsonk]

Ok... here are the hexdumps of the *.secure files...

Looking at these won't take you anywhere. These files are cryptographically protected and without knowing the private key you won't be able to ever create a file that will be accepted by the bootloader/kernel. It was like this on the PMA and hacking of the PMA relied on the check of the signature being disabled, however, on the 605 you cannot simply insert a hombrew kernel module into the kernel that will read out and write back the bootloader from/to flash as you could with the PMA...

Appreciated. I guess the question is, rootfs is obviously loaded by the bootloader while the other two fs are loaded by the kernel. I guess the question is, the mechanism between those two is different. Looking at things running, even while AVOS may "load" the optfs.cramfs.secure, when it is actually mounted, it is showing up as a normal cramfs. That means they must have modified the cramfs code, but from what I understand, they didn't release it. Is that logical thinking?

[grond]

That means they must have modified the cramfs code, but from what I understand, they didn't release it. Is that logical thinking?

I don't know whether they have released the code, but:

1. they could release the code without us being able to take advantage of it because the *code* will not include the private key used to sign the image-files nor does it have to include the public key used to check its validity (could include a pointer to a place in flash where the public key resides).

2. they could well have put everything dealing with encryption into a closed-source kernel module and the kernel code loading the cramfs in optfs simply calls some function in the closed-source kernel module which will check the cramfs prior to mouting it. Then, we wouldn't even have the code that does the checking...

[Hadakajime]

can u possibly put a normal version of shell on it via usb then run it?

[pwright8]

can u possibly put a normal version of shell on it via usb then run it?

I'm not sure what Hadakajime means, but it does prompt me to ask:
-Can I run anything useful at this point? an xterm on my display would be all i ask for
- I'm quite happy with ArchOS (or whatever it's called), but would like run different software. Is that a different project from what Fiat is doing ? (ok, ideally I'd like to dual boot Archos and OpenPMA)
- I think it would be great to have a vmware image of the 605, so is that a third project?

[grond]

-Can I run anything useful at this point? an xterm on my display would be all i ask for

AFAIK dm8tbr has succeeded in running Qtopia programs on the 605 by replacing the optfs with a custom made loop-mounted /opt including all the necessary libraries and binaries.

- I'm quite happy with ArchOS (or whatever it's called), but would like run different software. Is that a different project from what Fiat is doing ? (ok, ideally I'd like to dual boot Archos and OpenPMA)

As things are, there won't be dual boot because it appears doubtful whether the original system started by the bootloader can be changed. Thus, anything new will have to sit on top of the archos 605 firmware. You will possibly be able to use the hack found by fiat to run a script that will fire up a Qtopia-breed as used in the PMA.

- I think it would be great to have a vmware image of the 605, so is that a third project?

Sounds impossible to me. The 605 is not a PC and includes a heap load of special (and mostly undocumented) hardware.

[kitsonk]

1. they could release the code without us being able to take advantage of it because the *code* will not include the private key used to sign the image-files nor does it have to include the public key used to check its validity (could include a pointer to a place in flash where the public key resides).

I agree that the private key not be included. I am looking at the GPL source right now. There are two patches to the software. Neither of them seem to be anything to do with "passing" the file through something to validate it. I can see the build options to create the rootfs and the optfs, etc.

2. they could well have put everything dealing with encryption into a closed-source kernel module and the kernel code loading the cramfs in optfs simply calls some function in the closed-source kernel module which will check the cramfs prior to mouting it. Then, we wouldn't even have the code that does the checking...

Yes, but after layzee pointed me to the init.d directory, all of the modules are accounted for. None of them seem to be handling this from what I can see, though I maybe wrong.

So my big question is, which I guess I will have to try, is if I replace the optfs.cramfs.secure with a non-signed version, will it work... As long as I back it up, I guess I won't brick it. No messing with the rootfs right now.

[grond]

Yes, but after layzee pointed me to the init.d directory, all of the modules are accounted for. None of them seem to be handling this from what I can see, though I maybe wrong.

What about keystore.so?

So my big question is, which I guess I will have to try, is if I replace the optfs.cramfs.secure with a non-signed version, will it work... As long as I back it up, I guess I won't brick it. No messing with the rootfs right now.

I would first try to umount /opt, then hexedit a bit in optfs.cramfs.secure and see if I can still mount it to /opt...

[kitsonk]

What about keystore.so?

Hmmm... good point, but that isn't a kernal module...

I would first try to umount /opt, then hexedit a bit in optfs.cramfs.secure and see if I can still mount it to /opt...

Too late, what I did was

Code: Select all

#umount /opt
#cd /mnt/system
#mv optfs.cramfs.secure optfs.cramfs.old
#cp /mnt/data/Data/opt.cramfs optfs.cramfs.secure
#mount /opt

It worked like a charm... I created the opt.cramfs by creating a mkcramfs on the directory on my host machine. The original filesize is for optfs.cramfs.secure is 12963840 and my new one is 12951552.

Just to make sure I am going to add something to the fs and go through the process again, but I am pretty sure it work. I will also do a hard reset on the system.

[grond]

I will also do a hard reset on the system.

Good luck...

[Fuse314]

Too late, what I did was

Code: Select all

#umount /opt
#cd /mnt/system
#mv optfs.cramfs.secure optfs.cramfs.old
#cp /mnt/data/Data/opt.cramfs optfs.cramfs.secure
#mount /opt

It worked like a charm... I created the opt.cramfs by creating a mkcramfs on the directory on my host machine. The original filesize is for optfs.cramfs.secure is 12963840 and my new one is 12951552.

Just to make sure I am going to add something to the fs and go through the process again, but I am pretty sure it work. I will also do a hard reset on the system.

Try restarting (Power-Cycle) the Player - I assume you will get some error code when trying to start the player again (with the modified cramfs file)... - In the avos binary, there are functions hinting the check of the cramfs files. I believe that avos checks the mounted cramfs files when it is being executed and it displays the error dialog if the signatures do not match.


Is there maybe a way to replace the public key (stored in the flash memory?) with another public key making us able to produce "valid" cramfs.secure Files? (but maybe this key is checked on boot-time by the bios)
This would make it possible to replace for example apdf with our own "homebrew" executable...

[FLORIAN37]

The Archos website is down !!! :http://www.archos.com/
CAUTION!!!

Finished...

[grond]

In the avos binary, there are functions hinting the check of the cramfs files. I believe that avos checks the mounted cramfs files when it is being executed and it displays the error dialog if the signatures do not match.

AVOS itself resides in the rootfs, right? Since we can't change that, we could only put a hacked version of AVOS into a loop-mounted optfs. This, however, wouldn't have a real advantage over simply umounting /opt and mounting a modified /opt instead...

Is there maybe a way to replace the public key (stored in the flash memory?) with another public key making us able to produce "valid" cramfs.secure Files?

Theoretically, yes. However, first we would have to know the precise encryption mechanism. Then, you won't be able to temper with the flash memory easily, I'm afraid...

This would make it possible to replace for example apdf with our own "homebrew" executable...

This is already possible but you have to apply the "hack" every time you boot the device which unfortunately is not a very nice solution and requires an access point nearby.

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...

[kitsonk]

Try restarting (Power-Cycle) the Player - I assume you will get some error code when trying to start the player again (with the modified cramfs file)... - In the avos binary, there are functions hinting the check of the cramfs files. I believe that avos checks the mounted cramfs files when it is being executed and it displays the error dialog if the signatures do not match.


Is there maybe a way to replace the public key (stored in the flash memory?) with another public key making us able to produce "valid" cramfs.secure Files? (but maybe this key is checked on boot-time by the bios)
This would make it possible to replace for example apdf with our own "homebrew" executable...

Well, I didn't get an error. Everything came back as normal, except of course the arcwelder. Now though when I try the start arcwelder again, I don't get anywhere, though I had perfectly fine Opera.

I finally did a reset of the device, which I think only reformats the /mnt/data and tried to start arcwelder again from scratch, restoring my .aos file licenses to get Opera back. The device seems fully functional again, except for the fact that trying several times to start arcwelder via GFT is not any good... I even tried dumping my output files, but nothing is getting created. I will have to try something else.

Update
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. I did finally get back to dmesg soon after the restart. Before it had gotten loaded up with a bunch of processor throttling messages, now I see several entries like this:

Code: Select all

fuse distribution version: 2.5.3
signature keyid: 2916424e660b08aa ver=3
ksign: Signature check succeeded

Is that standard stuff?