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 Mon Sep 01, 2014 8:32 am

All times are UTC + 1 hour



Post new topic  Reply to topic  [ 75 posts ]  Go to page Previous  1, 2, 3, 4
Author Message
 Post subject:
PostPosted: Sat Mar 03, 2007 3:11 pm 
Offline
Archos Novice
Archos Novice

Joined: Fri Jan 19, 2007 4:23 pm
Posts: 21
Location: La Coru├▒a
Pingmeister wrote:

Perhaps I'm cynical but it seems crazy when you're in the business of making gadgets to make one so upgradeable that you'll never buy another.

They are much better off having you buy a 504 then 604 then 704.


---------hardware will break down finally ---- I had an Archos MMJB 20G which I tried used for recording DJ sets - but the line-in level was screwed and never worked right -------

So here I go.. thinking that the 504 will do a better job... Turns out I have to buy the travel adapter to record (MMJB would record on the line-in minijack directly)

OK, so I spend the money but now playlists/archlibrary/tags dont work..


What I am saying is that I will never trust Archos again NOT because it is not upgradeable simply because IT DOES NOT WORK from the very first day...

It may be great hardware (at times) but, as I see it, they will end up serving a market for only a few Techies who want to spend days and days fiddling with the hard/software before it even works..

sorry... I admit being a very disapointed user

[/quote]


Top
   
 
 Post subject:
PostPosted: Sat Mar 10, 2007 5:50 pm 
Offline
Archos Novice
Archos Novice

Joined: Sat Jan 13, 2007 7:00 pm
Posts: 16
Rich16 wrote:
Pingmeister wrote:

What I am saying is that I will never trust Archos again NOT because it is not upgradeable simply because IT DOES NOT WORK from the very first day...

It may be great hardware (at times) but, as I see it, they will end up serving a market for only a few Techies who want to spend days and days fiddling with the hard/software before it even works..



This is the most curious part -- the unit seems designed for techies but they lock techies out of using it as they really want to.

It's like the "free to air" satellite receiver market. Companies like Pansat know very well that people are hacking their BIOS, that's why units are flying off the shelves.

If Archos would only admit it has niche products (because they're finicky) but powerful products (appealing to tech heads), they'd give us a back door.

Until they do, the 604 Wifi will be my first and last Archos product.


Top
   
 
 Post subject:
PostPosted: Sun Apr 08, 2007 1:43 pm 
Offline
Archos Novice
Archos Novice

Joined: Sun Apr 08, 2007 1:13 pm
Posts: 8
Man i just don't get why they don't understand that they would sell al lot more if a alternative open linux version would be aviable, and how much people would by a new version of their product beause of more speed. at least a development or plugin system would be great (a simple "exe" ending support for linux executables) with multi thread support for background stuff like file copy ftp and stuff ssh .....


but i think they think that they would make MORE MONEY with plugins and thats WRONG because they simply cant port ALL Linux apps ftps servers stuff like a fully opensource device could so theier product will be behind the others in this point and this is a great point because there are a lots of freaks out there who buy products simply to tweak them (like me)


Top
   
 
 Post subject:
PostPosted: Sun Apr 08, 2007 1:52 pm 
Offline
Archos User
Archos User

Joined: Wed Jan 17, 2007 4:24 am
Posts: 61
I agree.
Stop selling and supporting your software and just sell the damn hardware.
If you are only selling the hardware you don't have to support it.
Less software staff and less support staff.
Hmmm.

WIN - WIN isn't it?


Top
   
 
 Post subject:
PostPosted: Sun Apr 08, 2007 3:20 pm 
Offline
Archos Novice
Archos Novice

Joined: Sun Apr 08, 2007 1:13 pm
Posts: 8
off corse it is a win win situation but only big companys like HP IBM ect are not afraid to do this step with enought backbone, small companys are afraid about DRM cracking ect but this is just so fucking wrong because if you buy hardware you should also have the right to control your own hardware (and as long as our world stays physical there is ALWAYS a WAY to control things with or without DRM)

i think i will buy some adater i try to compile my own little terminal into the existing os... and then my own ftp client and stuff ssh ect i really need that shit without i wouldn't be ale to organize my network and stream the video files over samba without access to my server ;) (or i would be forced to write for EVERYTHING a http remote controler including admin files acces and that would be auwfull in a WIFI network )


Top
   
 
 Post subject:
PostPosted: Sun May 06, 2007 10:40 am 
Kurtis wrote:
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.

i just thought that the words "Archos Novice" under his name were funny.


Top
   
 
 Post subject:
PostPosted: Sun Aug 05, 2007 1:48 am 
Offline
Archos Novice
Archos Novice

Joined: Fri May 04, 2007 8:26 pm
Posts: 18
I wonder how Archos checks that the hd has not been replaced post firmware 1.5 - if it uses the same SHA coding on the hd id as it does on file checksums then, if there is a way of modding the hd id it uses, then possibly the scheme of retrofitting firmware 1.4 then upgrading firmware (which presumeably produces a signed file somewhere - possibly in the ext2 portion) might be a way in, by setting the hd id to the modded firmware checksum and then getting the needed SHA encoding.


Top
   
 
PostPosted: Sun Aug 05, 2007 2:45 pm 
Offline
Archos Guru
Archos Guru

Joined: Thu Nov 23, 2006 3:44 pm
Posts: 524
Location: openaos.org
Frances wrote:
possibly the scheme of retrofitting firmware 1.4 then upgrading firmware (which presumeably produces a signed file somewhere - possibly in the ext2 portion) might be a way in, by setting the hd id to the modded firmware checksum and then getting the needed SHA encoding.

Nice approach, but you have to keep in mind that a part of that firmware is also stored in the flash-ROM. So to circumvent the hdd-lock you'd have to downgrade the firmware, yes. So either interface the flash (tricky or impossible), the CPU (the needed via was left out, you'd need to drill a 0,2mm hole through the pcb...) or find a loophole in the firmware and go all the way through circumventing all security measures they might have taken to prevent reading and writing to the flash.

Oh and at all those points you could easily brick your 300+ Ôé¼ unit...

I'd love to hack that unit but this has to be done with great caution...

_________________
openAOS


Top
   
 
 Post subject:
PostPosted: Sun Aug 05, 2007 6:45 pm 
Offline
Archos Novice
Archos Novice

Joined: Fri May 04, 2007 8:26 pm
Posts: 18
but if you can get the archos to provide a signed version of any arbitary string (aka hd id) then you don't need to reflash merely use the update facility to add program to read a file contents then write back a signed string - after this you can sign any program since all it appears to use is the checksum for that program - archos will not be issuing any more updates from now on anyway.


Top
   
 
 Post subject:
PostPosted: Sun Aug 05, 2007 10:51 pm 
Offline
Archos Guru
Archos Guru

Joined: Thu Nov 23, 2006 3:44 pm
Posts: 524
Location: openaos.org
Frances wrote:
but if you can get the archos to provide a signed version of any arbitary string (aka hd id) then you don't need to reflash merely use the update facility to add program to read a file contents then write back a signed string - after this you can sign any program since all it appears to use is the checksum for that program - archos will not be issuing any more updates from now on anyway.


Though I'm not sure I can follow your idea completely - I think I can make out a problem:

The unit itself does not sign anything in the firmware in my opinion. It only verifies signatures based on hashes. It would be foolish to place a secret cryptographic key inside the unit, that if compromised would allow to produce valid binaries for all generation 4 units on earth.

In case of the hard drive my guess is that the boot-loader compares the serial number of the drive against a string stored in the flash. No cryptography involved in this process.
The hard drive lock-in was probably done while the upgrade file to 1.5 was processed. Simply by writing something that uniquely identifies the drive to some permanent storage: most probably the flash-ROM.

Cheers

Thomas

PS: There are far more promising approaches. Anyone skilled in exploiting user-space-applications on Linux? - preferably ARCH=arm

_________________
openAOS


Top
   
 
 Post subject:
PostPosted: Mon Aug 06, 2007 6:09 am 
Offline
Archos Novice
Archos Novice

Joined: Sun May 20, 2007 9:31 pm
Posts: 10
Man you fellas might as well be speaking Klingon or Epseranto. I cannot understand one damn thing you are talking about.

Me likey Archos. Me pushy button. Thingy show movie.


Top
   
 
 Post subject:
PostPosted: Mon Aug 06, 2007 8:30 pm 
Offline
Archos User
Archos User

Joined: Thu Apr 12, 2007 6:22 pm
Posts: 92
Location: Crystal Lake, IL
glad to hear that talks are still going on but i don't think any progress has been made, bummer.

_________________
Bring the NOISE


Top
   
 
 Post subject:
PostPosted: Tue Aug 07, 2007 1:54 am 
Offline
Archos Novice
Archos Novice

Joined: Sun Jul 22, 2007 8:53 pm
Posts: 16
Location: New York
I'm far from being skilled in this area, but it sounds like the same issues with the psp firmware. If you are able to reload the old firmware . 1.5 you are able to get the process further along?


Top
   
 
 Post subject:
PostPosted: Thu Aug 23, 2007 3:29 pm 
I'm not a programmer, so I really don't know if this is an applicable suggestion. However, we all know that a big amount of x04 owners are gettin' hungry about low volume issue, especially when devices are connected to all but earphones. Is there a chance to build a patch against the original firmware which removes the volume lock starting from the sources' package? I know that something similar has been done for several ipod devices, so I hope that now this would be possible also for our archos' devices since we can now study the os structure.

P.S. Yes, that's my first post. I know that the "volume issue" is one masterpiece of this forum, w/o a good solution imho, but the sources' release sound me like the beginning of the right way to solve that annoying trouble.


Top
   
 
 Post subject:
PostPosted: Thu Aug 23, 2007 3:48 pm 
Offline
Archos Guru
Archos Guru

Joined: Thu Nov 23, 2006 3:44 pm
Posts: 524
Location: openaos.org
albatros_la wrote:
I'm not a programmer, so I really don't know if this is an applicable suggestion.
<snip>
Might be possible but you're two steps ahead from where we are. There is no possiblity to run own code or let alone firmware on the x04 or x05 hardware. So no-way-for-now.

Thomas

_________________
openAOS


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

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 6 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™