Forum.ArchosFans.com
Archos 80 G9 1.5Ghz 1GB RAM ICS 8GB: Buy now (free shipping)
Archos 80 G9 1.5Ghz 1GB RAM ICS 250GB: Buy now (free shipping)
Archos 101 G9 1.5Ghz 1GB RAM ICS 8GB: Buy now (free shipping)
Archos 101 G9 1.5Ghz 1GB RAM ICS 250GB: Buy now (free shipping)
 * Register    * Login 

It is currently Thu Jul 24, 2014 11:41 am

All times are UTC + 1 hour



Post new topic  Reply to topic  [ 75 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
 Post subject:
PostPosted: Thu Feb 15, 2007 3:48 am 
Offline
Archos Novice
Archos Novice

Joined: Sun Jan 28, 2007 4:12 am
Posts: 19
I can't do this right now (busy tonight) but they've added DSA code to the kernel in crypto/signature... somebody could take their public key in there and use OpenSSL to verify that that's what they're using to sign things.

If not, I'll try to get to it soon.


Top
   
 
PostPosted: Thu Feb 15, 2007 4:55 am 
Offline
Archos Novice
Archos Novice

Joined: Wed Dec 27, 2006 12:07 am
Posts: 33
I try to follow everything on here as much as I can, but I am just not as tech-savvy as most on here. What exactly does this new update do and what will it allow me to do now (in my lesser language)?

I thank everyone very much. I am learning and do not want to get behind on what I can do with my 604 wifi. I just kind of feel that the basic tech person would have a hard time keeping up with this. If anyone knows of some sort of website that explains these terms, it would be great.

Now, back to being my dumb self.


Top
   
 
 Post subject:
PostPosted: Thu Feb 15, 2007 6:11 pm 
Offline
Archos Novice
Archos Novice

Joined: Thu Feb 15, 2007 6:08 pm
Posts: 3
I haven't had a chance to take a look at the code yet but, how do we compile this code and have it transfered back to the 604?

You really can't compile x86 code (what most PCs and new Macs run on) and expect it to run on the Archos..


Top
   
 
 Post subject:
PostPosted: Thu Feb 15, 2007 7:01 pm 
Offline
Archos Novice
Archos Novice

Joined: Thu Dec 28, 2006 3:33 am
Posts: 35
The news reached at least some major tech blogs like Engadget:
http://www.engadget.com/2007/02/15/arch ... 4-devices/

Anyways, great move by Archos! If they do release the full code giving the community the ability to mod/hack and reinstall it, Archos series 4 might become unbeatable among PVRs.

I mean, I already think it's the best solution for PVPs (I have an Archos 604).
Only thing that bugs me is that it seems there's so much more that the device could do...
Processor power seems to be good enough to take some pretty dirty jobs.

Can I start dreaming of having some Opera with Flash plugins and stuff now? XD


Top
   
 
 Post subject:
PostPosted: Thu Feb 15, 2007 7:10 pm 
Offline
Archos Novice
Archos Novice

Joined: Sun Jan 28, 2007 4:12 am
Posts: 19
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.


Top
   
 
 Post subject:
PostPosted: Thu Feb 15, 2007 7:42 pm 
Offline
Archos Guru
Archos Guru

Joined: Fri Dec 29, 2006 1:13 pm
Posts: 281
whew - Kurtis, you be da man!


Top
   
 
 Post subject:
PostPosted: Thu Feb 15, 2007 7:56 pm 
Offline
Archos Expert
Archos Expert

Joined: Fri Nov 17, 2006 8:19 pm
Posts: 194
Great post, Kurtis! As a retired software engineer who started out with COBOL on IBM mainframes and ended up with C/C++ on UNIX workstations and PC's (alas with no experience on embedded systems), I fall somewhere in the middle of the technical knowledge continuum. At least now I have a pretty clear understanding of the nature of the task at hand and, while it is more complicated than I had hoped, I feel confident knowing that there are people such as yourself rolling up their sleeves and stocking the fridge with caffeine-loaded beverages. While I may not be of much help on the cracking effort, I would be more than happy to assist with the coding / debugging tasks that will follow after. Thanks again for the detailed info, and good luck!

-Sam


Top
   
 
 Post subject:
PostPosted: Thu Feb 15, 2007 9:13 pm 
Offline
Archos User
Archos User

Joined: Sat Dec 30, 2006 5:00 pm
Posts: 79
Location: Southern California
Excellent job, Kurtis!

Moderators, maybe could you split Kurtis' post out and make it a sticky or part of a "hacking faq" or something.


Top
   
 
 Post subject:
PostPosted: Thu Feb 15, 2007 9:35 pm 
Offline
Archos User
Archos User

Joined: Fri Feb 02, 2007 1:06 am
Posts: 51
Yeah, excellent post.

As a software engineer who has had zero experience with embedded systems, I don't know how much help I could be on this either. However, if anyone comes up with any kinda of project schedule (basic tasks that need to be completed), a road map if you will, I would be more than happy to try and find an area where I could help out. I just don't know what to do at this point (as I said, no hardware experience).

That said, I like experimenting and learning... so, more guidance would be appreciated.


Top
   
 
 Post subject:
PostPosted: Thu Feb 15, 2007 10:21 pm 
Offline
Archos Novice
Archos Novice

Joined: Sun Jan 28, 2007 4:12 am
Posts: 19
You know, given that I just posted this morning and have already had two replies from software engineers, maybe I should propose option:

(4) We just appeal to Archos to open the device. Somebody (me?) could offer to go on contract with them and create a way to load unsigned code on the device in a way that they would be okay with (i.e. that they think wouldn't jeopardize their trade secrets or agreements with other companies for technology like Microsoft's Plays for Sure.)

If there is enough *public* interest, it is possible that they'll say yes. Who knows? It's worth a try.

If somebody wants to set up a web petition and a cutoff date (say, a month) we could appeal the company directly to open up a way to load unsigned code onto the device. There are, just from this post, at least three software engineers who would look into developing other capabilities for their device if they just opened their device to outsiders.


Top
   
 
 Post subject:
PostPosted: Thu Feb 15, 2007 11:16 pm 
Offline
Archos Novice
Archos Novice

Joined: Sun Jan 28, 2007 4:12 am
Posts: 19
So, I took apart my 504. After dropping several screws too tiny to really be called screws, I got inside, looked around, then put it back together. I would've taken pictures, but my digital camera isn't handy.

Thankfully, the 504 survived the experience. :-)

Anyway, I didn't see anything in there that screamed at me, "hey look! I'm a big EPROM!" so I'm wondering if they're running almost everything from software and all that is actually embedded is the tiny ROM inside the DaVinci chip (8K, I think?)

If so, then the kernel should be on the hard drive somewhere too. Seems like a good time to start scanning around in that space at the end of the drive. I wonder if there's a kernel near the end?


Top
   
 
 Post subject:
PostPosted: Thu Feb 15, 2007 11:49 pm 
Nice (and much) information.

But unfortunately my knowledge about linux and embedded systems is not that big.
But like 'closer' ive got a Master in software development / engineering, so if theres anything to develop in C / C++ (or any other high level language) please tell me. I really would like to help !!!

T


Top
   
 
PostPosted: Fri Feb 16, 2007 12:22 am 
Offline
Archos Novice
Archos Novice

Joined: Sun Dec 24, 2006 2:45 am
Posts: 43
In the "need helpf for possible archos hack", I listed the flash chip used:

Intel 28F160C3 flash memory - Features software AND hardware block protection.

It's a BGA, so you ain't going to be able to get that thing off and reprogrammed...

I once took-out and re-soldered my brother's laptop's ATI Graphics chipset. It took me a month just to figure out a methadology that would reliabily work before I risked doing it. While I was suiccesfull, I'd give the odds at 50% of breaking it while re-soldering it. It involves using a metal template to re-create the solder bumps and a whole lot of user skill...

Desoldering though is easy because you can just apply a heat gun. The problem is contacting the flash to onto a socket: you need an expensive pin-array of some sort.

My best guess is that they program the flash using some of the metal pads on the board, either through the standard JDAC serial protocol or a custom one. You still need an aligned pin-array to contact it, unless ofcourse you want to solder on tiny wires... But for that you'll need a stereo microscope to do reliabily (which I have but wouldn't attempt to do it unless I knew for sure I would get results).. <sigh>

Greg


Top
   
 
 Post subject:
PostPosted: Fri Feb 16, 2007 12:42 am 
Offline
Archos Novice
Archos Novice

Joined: Sun Jan 28, 2007 4:12 am
Posts: 19
Ick. I just looked and you're right. Ick and double ick.

I was hoping that it would be easy to get a dump of the flash to see if we actually could do anything useful with a reflash. If so, then there's more, um, motivation to do a software hack, since it might actually lead to an open device.

Well, let's sit on it for a while, and see if anybody gets brave enough to try. :-)


Top
   
 
 Post subject:
PostPosted: Fri Feb 16, 2007 1:34 am 
Offline
Archos Novice
Archos Novice

Joined: Fri Feb 16, 2007 1:24 am
Posts: 23
Kurtis wrote:
........ 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..........


Fast forward on a small AVI video file (640x480 mjpeg) created with my Canon camera consistently reboots my 604 WIFI.


Top
   
 
 Post subject:
PostPosted: Fri Feb 16, 2007 2:51 am 
Offline
Archos Novice
Archos Novice

Joined: Wed Oct 18, 2006 3:30 am
Posts: 42
A lot of us would be happy if someone could simply unlock the drives on the 504 and 604 so that the factory originals could be upgraded. That alone would be a wonderful development!


Top
   
 
 Post subject:
PostPosted: Fri Feb 16, 2007 3:55 am 
Offline
Archos User
Archos User

Joined: Tue Dec 05, 2006 1:56 am
Posts: 79
I found working opera (jpeg) vulnerabilities that caused opera to crash, details in another thread. If someone actually knew how to put in their own code, this might be useful.


Top
   
 
 Post subject:
PostPosted: Fri Feb 16, 2007 4:37 am 
Offline
Archos Novice
Archos Novice

Joined: Sat Oct 14, 2006 2:04 am
Posts: 10
Hi i now nothing about linux or the source code , with it beeing
released now , what features will the wifi be able to do now ?

can some one explan what can be done with the new source code?

thanks alot !


Top
   
 
 Post subject:
PostPosted: Fri Feb 16, 2007 6:21 am 
Offline
Archos Novice
Archos Novice

Joined: Tue Feb 06, 2007 1:52 pm
Posts: 24
I've found that trying to view "info" from the menu of an AVI created by VirtualDub 1.7.0 will reliably crash my Archos player.


Top
   
 
 Post subject:
PostPosted: Fri Feb 16, 2007 2:57 pm 
Offline
Archos Expert
Archos Expert

Joined: Sun Dec 03, 2006 8:16 pm
Posts: 223
archer242 wrote:
Hi i now nothing about linux or the source code , with it beeing
released now , what features will the wifi be able to do now ?

can some one explan what can be done with the new source code?

thanks alot !


What can be done is it can be looked at to see if there is any way to add code to the device that will allow us to disable the checksums on the firmware, so that software can be added by the user.

Right now, it's just an exercise in exploration, and someone who has looked at it notes that the software that adds the checksums is not there.

Perhaps a chink can be found in the armor, and we might have progress... but it wil probably take a while...


Top
   
 
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 75 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Hosted by Forumatic™