Moldy Cheese for 4 GB and 160 GB 605s

[tlhIngan]

Is this offer still open? I do have a spare 605-160GB that I don't mind bricking. (It's a spare and it's got an extended warranty, so...)

I've done the GFT hack way back when (arcwelder, too). Just need the binaries to dump the flash.

[generic_username]

is there a different firmware version for the 160g version?? its less clear to me why the 160 hack doesn't work than the 4gbFlash because I know the 4 has a different firmware version

on the 4gb front:

from the archutil(thanks che,grond and analias!) we are able to unpack an aos firmware, from that a couple folders, the cpio stuff etc are produced

the one that seems to be relevant to MC'ing the 4gb is the FLSH folder

here i have uploaded a hd version and a 4gbFlash verson:
http://rapidshare.com/files/323735503/fVSh.zip.html

if we examine the source for MC.2 we discover that the henripalooza.c searches for and then patches two sets of hex values in the boot flash boot0 and boot1

the values that it searches for are:

Code: Select all

memcmp(memory+736,"\x8a\x01\x00\xeb", 4) != 0 )

8a0100eb
file:0x000000
offset:0x02e0
beforeMC:

Code: Select all

BL SUB 910 
CMP R0, #0

afterMC:

Code: Select all

MOV R0, #0
CMP R0, #0

and

Code: Select all

memcmp(memory+34804,"\xf0\x41\x2d\xe9\x01\x60\xa0\xe1", 8) != 0 )

f0412de90160a0e1
file:0x030000(?)
offset:0x87f4
edit: on re-reading the first mc post this seems to be the cpiocheck


these values can be easily searched for and found in a program such as winhex to locate the places that are patched(edit or just convert the memory+ from dec to hex for the offset)

from there i think it is a matter of looking for similar opcodes in the F flsh folder, but i haven't really started searching, except to see that the bootflash is indeed quite different between the two (but hopefully the MC relevant parts arent)

http://www.arm.com/miscPDFs/9658.pdf

[tlhIngan]

The 160GB is very similar to the other hard drive units. However, the flash code is oh-so-slightly different because it's a PATA drive being used in LBA48 mode to get to the >128GB area.

I'm not sure why Archos didn't make one flash code to rule them all (at least, the hard drive ones) (since LBA48 can be detected on hard drive detection), but so far, all the moldy cheese details says non-4GB, non-160GB units.

I should probably look at an update firmware to see if there are two FLSH blocks (one for <128GB and one for >128GB) to see how it's handled...

[grond]

is there a different firmware version for the 160g version?? its less clear to me why the 160 hack doesn't work

Well, I don't really see a reason why it wouldn't work. It's the same firmware, the only problem is that the bootloader can't boot from harddisk and thus you need to flash the modified kernel image to the bootrom. This means quite a risk (think about the problems with archilles' early bootloader hacks) because if you produce a broken kernel, you get a brick (well, unless you get a smaller disk which enables the bootloader to boot from harddisk such that you can put a hacked kernel image on the harddisk).

[generic_username]

in the 4gb/FLSH firmware at the same 0x02e0 offset we find:

Code: Select all

BL SUB_910
CMP R0, #0

seems to be the same check as the HD firmware, same offset even

so:

1. file: 0x000000 hex: 8a0100eb
@ offset 0x02e0 :

Code: Select all

8a0100eb

is patched to:

Code: Select all

0000a0e3

2. file: 0x030000 hex: f0412de90160a0e1
this string of bytes also occurs in the 0x030000 file, but on the 4gbF version afaik it seems to appear in a different location:

@ offset 0x87bc :

Code: Select all

f0412de90160a0e1

by mc(4f?) is patched to:

Code: Select all

0000a0e31eff2fe1

(vs 0x87f4 for the harddrive firmware)

k there u go 4gb owners. who wants to brick their shiz?

[grond]

Ahem, you should really know what you are doing. Removing the two checks in the first two bootloader stages won't give you much because there is still the rootfs signature check in the kernel init. The 4G can only boot from flash and you need to flash the hacked kernel (without the cramfschecker that checks the rootfs signature) to the bootrom. If for some reason the kernel doesn't boot, you'll have a digital photo frame showing "Entertainment your way" all the time.

[generic_username]

^^ good advice. i don't have a 4g so even if i wanted i couldn't test a kernel image, just tryin to help out the few out there that have been left out so far

[generic_username]

is this the check? http://archos.g3nius.org/index.php?titl ... file%28%29

or are there several?

[grond]

is this the check? http://archos.g3nius.org/index.php?titl ... file%28%29

That's dummy code for the check on firmware files (.aos files).

[generic_username]

is the check your referring to written up in psuedo-code on archos docs tho? or no

[tlhIngan]

Looking at the 160GB would be your best bet, since that one is similar to the other 605's that mouldy cheese works on. The flash one is a bit trickier since the flash code is different between accessing the flash and accessing the hard drive.

You have to start at the bootloader so it can load an unsigned kernel, then hack the kernel so it can load an unsigned rootfs.cramfs.secure.

[generic_username]

i don't have either 160g or 4g to test, so i've done what i can with the 4g bootflash

the way i understand the 160 is already solved it just needs to be written to flash instead of HD

anyone know what the check for the kernel looks like?

im feeling lazy and don't really wanna mount like four cramFS's extract the files and reverse and diff all of them...

edit:@tlh ps the 4g boot flash code that needs to be modified is already identified, i think just the kernel business needs to be taken care of now (is a modified cpio needed too? haven't really looked)

also: moldy/mOUldy same thing?

[grond]

the way i understand the 160 is already solved it just needs to be written to flash instead of HD

Yes.

anyone know what the check for the kernel looks like?

Yes, it's a lot of binary code. Are you asking for the check on the kernel or the check in the kernel (that checks the rootfs)?

edit:@tlh ps the 4g boot flash code that needs to be modified is already identified, i think just the kernel business needs to be taken care of now (is a modified cpio needed too? haven't really looked)

Yes, a modified cpio is needed, too. And that's really a tricky task because you really only get one try to have a booting and fully operative kernel/OS. I'm pretty sure I could do it (in fact I prepared a hack once that no openPMA member dared test...) but it is more complicated than archilles' original hack because using any kernel other than that which Archos use is a risk. So you need to take Archos' kernel, splice it apart, eliminate the cramfs check and put it all back together (the last part being the most difficult).