There are much better resources out on the net to explain this, but I'll do a quick summary and answer the questions people have already asked here.
1. What is in the package?
The package includes buildroot, which is "a set of Makefiles and patches that makes it easy generate a cross-compilation toolchain and root filesystem for your target Linux system using the uClibc C library" according to its website (
http://buildroot.uclibc.org/). Basically this lets you build a linux based unix environment that is optimized for very very small size by using busybox (another package) for most system tools and uClibc (a C library much smaller than glibc) for dynamic linking to C programs. It also includes config scripts for buildroot for the Archos 4th Gen products, and modifications to any package that buildroot includes. It also includes a handful of other tools (the pdf viewer, the linux kernel) that are GPL that run on the Archos.
Some people have asked about cross compilation problems and the like; buildroot takes care of everything. Just follow the directions in the docs subdirectory, and it will build for you a <yourhostsystem>-to-arm cross compiler and compile all of the relevant source for you. One "make" and you end up with the two cramfs files. You actually need to know very little about cross compilation or embedded devices to build the source.
2. Is this everything on the Archos x04?
Not by a long shot. The root filesystem after building is around 1.5MB IIRC, while the rootfs.cramfs.secure that we've pulled off of functional Archos drives is closer to 7MB. What's missing are non-GPLed items, probably mostly internally developed at Archos, like /usr/bin/avos (the main executable), the fonts, graphics, and codecs in /usr/share, and some other things.
3. Now that we have the source, we can modify the Archos however we want, right?
Nope. There are several steps left (I'll outline them below) and some important pieces that are still closed source which we'll have to work around.
4. Can I get this code on the Archos?
Right now, you can't. The build produces the GPLed code from 1.6.10. We know that to run 1.6.10 on the device the bootloader loads rootfs.cramfs.secure and optfs.cramfs.secure from an unmarked "partition" at the end of the drive that is actually ext2/3 (not sure which). These are two cramfs files with what appear to be digital signatures tacked on the front. Attempts to modify the cramfs files and load them on to Archos devices has resulted in the machine claiming the disk was bad and offering to reformat.
5. What are our options at this point?
The most important concept in a secure system like this is what's often called the "chain of trust". Closing a system like the Archos involves making sure every step from power on to running application only passes control from one step to the next if it can trust that next step. More or less, our guess about the chain of trust on the Archos looks like this:
a) boot rom code - flashed onto the device (possibly with each firmware upgrade... possibly only at the factory)
b) Linux kernel
c) some rootfs (probably an initrd or similar... more on this below) with init
d) the rootfs.cramfs.secure linuxrc (which is just a link to busybox init)
e) the /etc/inittab in rootfs.cramfs.secure
f) /usr/bin/avos - the Archos application
This is similar to the way the TiVo does it. You can learn a lot by reading the dealdatabase.com forums about the TiVo to understand how this chain of trust works, but here is my guess:
a) The boot rom code is mostly frozen at the factory when the Archos is built (it may even be unflashable.) I guess this because if you put a completely blank hard drive in the Archos, you still have a little app that offers to do some formatting and mount the drive as a usb device (and why bother to leave this if you're locking the drive using the prom?) If that's the case, then Archos can "trust" this code because they're the only ones who can put it on the device, and then it's not modifiable after that.
b) The kernel is probably also loaded from flash or rom since we haven't found it on the hard drive. Unlike the boot loader, this is probably in flash because if there was a security or crashing problem in the linux kernel, I think Archos would want to be able to push out an update. Archos can trust it even in flash because all the firmwares they distribute appear to be digitally signed, so updating the flash in their supported way requires knowledge of a private signing key they don't release.
c) Some rootfs other than rootfs.cramfs.secure is loaded. This is entirely a guess on my part; they certainly could go straight to the rootfs we've found. The reason I don't think so is GPL related: if they go straight to the rootfs, then they have to verify the signatures on the cramfs files in the kernel code which they would then have to release (assuming they modified the cramfs code.) This code isn't in their kernel release, so either: (1) they're still in volation (not likely), (2) they use a kernel patch module (there are several binary hooks in their kernel in mvl_patches that they could use to overwrite various parts of the kernel, but it would be ugly since the way they'd call into it from the cramfs code is non-obvious), (3) they use a initrd or other flash based rootfs that only runs and check the signatures on the rootfs and optfs files in the drive area, and it is responsible for pivoting the root to the rootfs. I think they go with option 3, so we're looking for a tiny rootfs in their firmware somewhere. Again, this is trusted because it's in the firmware.
d,e,f) rootfs.cramfs.secure is loaded, and its linuxrc is called, which runs inittab stuff which runs avos. This is trusted because it's signed, and the theoretical code in step (c) can verify the signature to make sure it hasn't been tampered with.
So, where are the weaknesses in this chain of trust? Almost certainly compromising the box to actually run non-trusted Archos code can only happen in three places:
(1) We successfully cryptanalyze their digital signature protocol, allowing us to generate a rootfs.cramfs.secure that the box will recognize as signed. This isn't as hard as it might sound. Since they use DSA, they are signing a hash of their firmware, not the whole file. Likely they'll use SHA-1, so what we need to do is exploit weaknesses in SHA1 to generate a rootfs.cramfs that has the same SHA1 hash. Then we can probably just tack the same signature on the front, and it will verify. We don't HAVE to break PKI... just the hash. SHA1 is pretty good, but I think I read some stuff recently about some weaknesses??
(2) We successfully find a security hole in one of the applications on the device. For instance, if their PDF reader or MPEG4 codec has a bug that overwrites the stack, we could put our code to execute inside a PDF or MPEG4 wrapper that will cause the bug, then instead of crashing will load our code instead. I don't know how this works on the ARM, if they use some kind of read-but-no-exec protection on the stack or anything, but if not this should work. This is likely the easiest vector of attack, but it involves somebody who knows how to write this kind of stack exploit, which I don't (at least, not yet.)
(3) We reflash the rom. If we crack it with (2) we'll almost certainly do (3) so that we don't have to keep doing (2) every time we boot the device, but there are other ways to accomplish (3) without (2). The dealdatabase group, for instance, socketed their PROMs before a hack of kind (2) was found (and in fact, some still do). We could do this: the idea would involve desoldering the flash from the board, putting it in a programmer, and looking at it or modifying it directly. This is probably the hardest exploit, unless you're really good at soldering.
6. ACK! This is a lot of information, Kurtis! I don't understand it; what can I do to help?
Well, for starters, if you don't know a lot about linux boot procedures or exploiting boxes, you probably can't help much yet. Educate yourself starting with what I've said above and other net resources on potential stack exploits. Look for bugs in the Archos that cause the machine to reboot or hang reliably, and find out if they are stack overwrites crashing the machine. Wait until someone else has an exploit they think works, then offer to do the testing for them.
If you do understand everything I've said above, then you already know how to help.
7. I thought once we had the source code we'd be home free. Why aren't we?
That's the beauty of public-key cryptography. Your adversary (us, in this case) can know everything about how you secure/sign your messages and still be powerless to act. Almost certainly, cracking the box will involve one of the protocol weaknesses outlined above, instead of sucessfully getting Archos's private key.
Unless, of course, one of the Archos employees quietly leaks it to us. I, myself, don't see what advantage they have in not doing so, since their proprietary secrets on the device (like /usr/bin/avos) aren't open sourced and thus mostly protected anyway.
They could, if they wanted, let the box run unsigned code with the warning "this is unsigned" or the like (in essence, putting a seperate non-root user on the box that is only allowed to do stuff at the end of that chain of trust outlined above... that's the way standard unix security would work) but my guess is that they're just paranoid in the usual corporate way about their boxes.
Sorry this was a long post. Hopefully it was informative. Admins and others, you can reprint any of this information without attribution anywhere you want: I put it in the public domain.
