605 v1.7 Disk Image

[thethirdmoose]

It's a bit-for-bit copy of the hidden partition. The formatting system is ext3. It is a direct copy, using dd. This is a hackable firmware. It's compressed using bz2 to ~90MB, the uncompressed size is ~200MB.

http://www.sendspace.com/file/b713p2

[scott16]

Anyone have one for a 604 (non-wifi) I'm trying to replace the HDD (which is broken).

[roylovelock]

im pretty sure that wont work, once you have gone past the 1.7 firmware it wont recognise the drive unless installed by archos.
hopefully im wrong and someone will correct me here, but im sure this is correct.
roy

[Uru Wolf]

Hi there, I have been wanting to install something better onto my archos 605, but I have the version 1.5.05 firmware. Could someone please give me a quick tutorial on how to use the image above to "downgrade" the firmware? I am running Ubuntu linux on my main pc and have no problems using bash.

[CoolhandLuke]

which program is DD?

[Uru Wolf]

which program is DD?

DD is a bash (linux cmd) command

[raverx3m]

so has anyone tried this?

[Olimatou]

I'm trying to replace the 2.1.04 partition with this one... I will send there feedback on my progress shortly... Of course, I will use same trick I used to investigate 2.1.04 firmware as discussed here : http://forum.archosfans.com/viewtopic.p ... &sk=t&sd=d

[CheBuzz]

Copying this file will get you back to a 1.7.13 rootfs, which of course reenables GFT. The interesting thing is that the flash still contains 2.1.04. But since the 1.7.13 rootfs.crams.secure and optfs.cramfs.secure were signed with Archos private key, they are valid files and the bootloader loads and runs them just fine.

[kb]

I presume that if you have a post 1.7.13 firmware, the only way to apply this change is to take the hard disk out and install it in a different Linux machine? If you already have a way to run dd on your 605, you don't need this, right?

Is your image from an HD or SSD unit? They have different firmware, no? Doing this on the wrong kind of unit would probably break it, I think.

It would be interesting to know how many people want to go back to 1.7.13, simply to get access to the GFT hack.

[CheBuzz]

This image is from a HDD unit. All HDD units have the same firmware, regardless of size. So all HDD units can "reenable" GFT, but it does involve pulling out the disk, mounting it to a computer, and copying over rootfs.cramfs.secure, cpio.secure, and optfs.cramfs.secure.

[kb]

It's good to know this works. But I'm a bit uncertain how many people will be interested in downgrading their 605s to 1.7.13 to get access to the GFT hack -- especially as it involves dismantling the unit. I appreciate that it's possible, in theory, to get access to features from later firmwares if you go back to 1.7.13 and then fiddle around with the the bootloader, etc. But this process is pretty arduous, and rather risky.

Do you think people are going to want to? In a sense, now is a goot time to try, because we aren't going to be seeing any new firmware from Archos for the 605. Except the one they will now release immediately to make your suggestion impossible

[kb]

Another thought occurs to me --

Replacing the system partition may give you access to 1.7.13 hacks, but it won't make the flash writeable, or will it? My understanding is that the read-only switch on the flash gets thrown fairly early on in the boot sequence with firmware > 2.0. So, if I understanding correctly, reverting to 1.7.13 this way won't provide a step along the way to replacing any bits of flash (to get a more permanent hack, for example).

Or have I misunderstood?

[Olimatou]

I confirm !!! AVOS Firmware is 1.7.13 now !!! U're a Wiz !!!

But I suppose that the Flash is NOT in 2.1.04 !!! I think that they use the same loader in rom for each A605 but the only thing is that AVOS do a control check on update files before copying on the ext3 partition the cramfs files...

Thanks for the image file !!!

[grond]

Replacing the system partition may give you access to 1.7.13 hacks, but it won't make the flash writeable, or will it?

It will not, you are right.

[b0hoon]

Replacing the system partition may give you access to 1.7.13 hacks, but it won't make the flash writeable, or will it? My understanding is that the read-only switch on the flash gets thrown fairly early on in the boot sequence with firmware > 2.0. So, if I understanding correctly, reverting to 1.7.13 this way won't provide a step along the way to replacing any bits of flash (to get a more permanent hack, for example).

Yes, that's the main problem in all of this... No software solution after locking down the flash memory.

[kb]

That's what I thought -- the GFT hack was a great idea for initially getting into the 605, and full credit to the person who worked it out. But it was never going to be a long-term solution to the problem of running code on the 605.

It's terrific that people can get the GFT hack back if they want, but unless that can be used to investigate other possible, more permanent, hacks, we're still not where we need to be :/

[grond]

but unless that can be used to investigate other possible, more permanent, hacks, we're still not where we need to be :/

Well, it can be used for all that but that doesn't help much either as there seems to be no possibility of hacking the locked bootloader. A hacked bootloader is a very handy thing if you want to run avos inside a debugger to look for further exploitable bugs.

[Logik]

can the flash chip still be read though, or have they locked out both read and write?

i presume they still have a way to rewrite the chip with updates, since they would have shot them selves a gaping big hole in the foot if someone was to somehow obtain/leak the private key .

also how does the lock operate, software function call, or some software to hardware connection (ie SOME_INTEL_FN(lock); hooks Pin X to ground?)





PS appolagies to most of those about my outburst earlier this morning.

[kb]

I don't think you can lock the flash against reading. I don't know how the lock operates -- it is applied at the block level and is, I think, an irreversible software operation. That is, once you've thrown the switch (in software), the flash is coded (in hardware) to disallow writes until the next power-on. Something like that, anyway.

I suspect you can run AVOS in a debugger without hacking the bootloader, at least with 1.7.13. Kill the script that restarts AVOS, then kill AVOS. The start it however you like. If you just kill AVOS, the script will restart it. In 1.7.13, as I recall, there's no mechanism for the AVOS launcher script to be restarted if you kill it.

But perhaps you've tried it and found otherwise?