i give you: moldy cheese

Special Developer Edition Firmwares and Hacking on Archos 5 IT, 5/7 IMT, 605/705, with Android, ├àngstr├Âm and other Linux
soviet123
Archos Expert
Archos Expert
Posts: 209
Joined: Sun Sep 13, 2009 2:53 am
Location: Parmi les Quebecois

Re: i give you: moldy cheese

Post by soviet123 »

He changed some of the files wrong, and now they are being listed as plug-ins.
A7-320 v1.7.02
cyclonezephyrxz7
Archos User
Archos User
Posts: 90
Joined: Sat Dec 29, 2007 5:00 pm

Re: i give you: moldy cheese

Post by cyclonezephyrxz7 »

Ok, I can understand that. however, in the uname thread, the guy who had unlocked the plugins on (i believe this is what Grond Said) the later firmware (by bringing that kernel into the hacked 1.7.13 kernel) had a plugin called Screen,( and maybe one called core?) and it was mentioned it was for screenshots. I can believe that 31, 29, and 32 are just errors... Basically i would just like to know what the DEV one is, what the CORE one does, and how the SCREENSHOT one works (commands?).

@archilles: I realized you said earlier that the kernel was slightly unstable in this 'release' and you also mentioned that you removed the HDD Lock, and since I installed your [awesome] hack, i haven't been able to hook my Archos up to my Computer under "PC Hard Drive" mode ... It seems to lock up and on my computer i get a new drive (Drive L: in my case) which is totally empty. Will this be fixed in a later release?
grond
Archos Guru
Archos Guru
Posts: 627
Joined: Thu Nov 23, 2006 10:37 pm
Location: Berlin
Contact:

Re: i give you: moldy cheese

Post by grond »

cyclonezephyrxz7 wrote:Basically i would just like to know what the DEV one is


No idea, could be one of the erroneous ones.


what the CORE one does


It produces core dumps (which are unfortunately useless). If you don't know what a core dump is, you don't want to know more about this.


and how the SCREENSHOT one works (commands?).


Never found out.
openAOS
alsutton

Re: i give you: moldy cheese

Post by alsutton »

grond wrote:
cyclonezephyrxz7 wrote:Basically i would just like to know what the DEV one is


No idea, could be one of the erroneous ones.


I've developed for embedded systems before and it wouldn't surprise me if there was a dongle the Archos R&D has which attaches to the device and provides a method for getting debug information from the device and uploading test code to it without signing.

I'd suggest the dev plugin is for interacting with this dongle and is only suppose to be used by Archos R&D.
grond
Archos Guru
Archos Guru
Posts: 627
Joined: Thu Nov 23, 2006 10:37 pm
Location: Berlin
Contact:

Re: i give you: moldy cheese

Post by grond »

alsutton wrote:I've developed for embedded systems before and it wouldn't surprise me if there was a dongle the Archos R&D has which attaches to the device and provides a method for getting debug information from the device and uploading test code to it without signing.


There is a public rsa1024 key called "DevMPK", so I'd guess that even if your theory was true, the code would probably be signed.
openAOS
alsutton

Re: i give you: moldy cheese

Post by alsutton »

grond wrote:There is a public rsa1024 key called "DevMPK", so I'd guess that even if your theory was true, the code would probably be signed.


Bummer, I had hoped that the dev plugin might shine a light on a way to get unsigned code running.
cyclonezephyrxz7
Archos User
Archos User
Posts: 90
Joined: Sat Dec 29, 2007 5:00 pm

Re: i give you: moldy cheese

Post by cyclonezephyrxz7 »

My friend ArcAce2112 had been just looking at the Hardware to the DVR Station Dock (you can look at pix here http://drop.io/Archos_Quick_Pix5074 or the thread here http://forum.archosfans.com/viewtopic.php?f=34&t=24957). He looked a bit at the connections to USB and the SERIAL Connection on the back. I dont believe there was ever a set answer on what the Serial port was for, but from the circuitry it appeared to go straight into the Archos 605 unit. Could this be the 'entry point' for debugging and testing [potentially unsigned] code?
grond
Archos Guru
Archos Guru
Posts: 627
Joined: Thu Nov 23, 2006 10:37 pm
Location: Berlin
Contact:

Re: i give you: moldy cheese

Post by grond »

cyclonezephyrxz7 wrote:He looked a bit at the connections to USB and the SERIAL Connection on the back. I dont believe there was ever a set answer on what the Serial port was for, but from the circuitry it appeared to go straight into the Archos 605 unit. Could this be the 'entry point' for debugging and testing [potentially unsigned] code?


There is one serial port for the IR-blaster (the tiny thing you connect to the IR-eye of your set-top-box such that the 605 may control it for recordings).
openAOS
cyclonezephyrxz7
Archos User
Archos User
Posts: 90
Joined: Sat Dec 29, 2007 5:00 pm

Re: i give you: moldy cheese

Post by cyclonezephyrxz7 »

grond wrote:There is one serial port for the IR-blaster (the tiny thing you connect to the IR-eye of your set-top-box such that the 605 may control it for recordings).


Sorry, I am not familiar with the "IR-Blaster"... was that designed to work with the Archos Docking Station (Gen 5 in this case)?

Also, i forgot to mention the SW port that is back there aswell, which may be also for this "IR-Blaster"....i'm not sure...
serag
Archos User
Archos User
Posts: 70
Joined: Wed Oct 17, 2007 7:21 pm
Location: Canuckistan

Re: i give you: moldy cheese

Post by serag »

cyclonezephyrxz7 wrote:
grond wrote:There is one serial port for the IR-blaster (the tiny thing you connect to the IR-eye of your set-top-box such that the 605 may control it for recordings).


Sorry, I am not familiar with the "IR-Blaster"... was that designed to work with the Archos Docking Station (Gen 5 in this case)?

dvr station can remotely control tv/cablebox/sat receiver by using an IR blaster on the front. IR blaster is just a infrared led/resistor connected to a wire that plugs into the back of dvr station to move the ir blaster signal so that it's closer/best angle.
Junior
Archos Guru
Archos Guru
Posts: 369
Joined: Wed Feb 20, 2008 2:42 am
Contact:

Re: i give you: moldy cheese

Post by Junior »

Were any of you speaking English here? :) :lol:
niasork
Archos Novice
Archos Novice
Posts: 7
Joined: Mon May 04, 2009 9:22 pm

Re: i give you: moldy cheese

Post by niasork »

@archilles : it seems that, with your kernel, we cannot use the archos file explorer in order to move/copy/delete files. Do you know why? Or is my FS corrupted?
Chewyu
Archos Novice
Archos Novice
Posts: 36
Joined: Fri Dec 05, 2008 3:19 am

Re: i give you: moldy cheese

Post by Chewyu »

Which firmware version does this work for?
Chewyu
Archos Novice
Archos Novice
Posts: 36
Joined: Fri Dec 05, 2008 3:19 am

Re: i give you: moldy cheese

Post by Chewyu »

Was i fool for upgrading to 2.1 firmware as most post are for the older firmware? Why Me :evil:
Cuchulainn
Archos Novice
Archos Novice
Posts: 2
Joined: Sun Dec 16, 2007 4:55 pm

Re: i give you: moldy cheese

Post by Cuchulainn »

After switching I cannot transfer files anymore. Is it possible to switch back to the original firmware?
Omega Frost
Archos Novice
Archos Novice
Posts: 20
Joined: Fri Oct 09, 2009 10:36 am

Re: i give you: moldy cheese

Post by Omega Frost »

Now with moldy cheese is possible to find the RSA key from 605 gen., decrypt the .AOS file and modify an update to disable the bootloader lock and/or downgrade?
cyclonezephyrxz7
Archos User
Archos User
Posts: 90
Joined: Sat Dec 29, 2007 5:00 pm

Re: i give you: moldy cheese

Post by cyclonezephyrxz7 »

Omega Frost wrote:Now with moldy cheese is possible to find the RSA key from 605 gen., decrypt the .AOS file and modify an update to disable the bootloader lock and/or downgrade?


I believe that they key is still private and hidden beyond any sort of computer decryption power (discussed alot in another thread)...however what is the use of modifying the update file when with this we can just install our own custom kernel and linux distrobution. Essentially, this hack tells the RSA key and checker "You're done, i've bypassed you!" (haha)
L0wt3ch
Archos User
Archos User
Posts: 100
Joined: Thu Jan 17, 2008 7:42 am

Re: i give you: moldy cheese

Post by L0wt3ch »

Nice work, Archilles!

Nice to see someone with the brains and the balls to do what they said they were going to do. (Whatever happened to those other losers, anyway? :^o )

Now if only we could transfer files and use the file manager... 8)
idontknow
Archos Novice
Archos Novice
Posts: 12
Joined: Mon Sep 01, 2008 6:59 pm

Re: i give you: moldy cheese

Post by idontknow »

archilles wrote:cpio.secure from harddrive will not load on 160gb units. don't know why. works fine in flash. this hack will not work 'out of the box' for 160gb units. that will be coming very shortly.


Hi everybody!

First, let me also congratulate Archilles. Very nice job! I was also working on this in order to be able to replace my HDD in case of failure, and thanks of your precious help i've been able to replace it right now. That's a great relief: now i'm sure i will be able to keep using my Archos in the future!

Since i have a 160GB unit, i can confirm that the cpio.secure file is not read from HDD. For the moment, i've replaced the HDD with a 80GB one to have this hack working. And i'm investigating the reason why it doesn't work.

Since it works with smaller HDD, it seems pretty obvious that it should be the infamous 137.4GB limit issue because of the use of 28-bit only LBA instead of 48-bit one.

This is confirmed by analyzing the boot1 assembly. Note: since boot1 is copied from Flash to RAM and executed from RAM, i will give both FLASH (including offset) and RAM addresses.
- In sub 0x20382C4 (0x820071FC): HDD geometry/properties are retrieved ("Identify Drive" 0xEC command) and stored in RAM starting at 0x82E01004. The first 4 double words stored are: number of logical heads, number of logical sectors per logical track, number of cylinders, number of user addressable sectors (LBA mode). Then there's a word containing the number of sectors per mutiple R/W command, and finally 2 bytes: containing either 0x20/0xC4 and 0x30/0xC5. The interesting parts here are:
* The "number of user addressable sectors" for LBA mode: 32 bits = 4294967296 sectors, with 512 bytes/sector = 2 TB max. This is enough for a while i believe ;-) So the problem is not here.
* The last 2 bytes are in fact the codes of Read or Write commands that will be used later. If Multiple R/W mode is not available, simple Read (0x20) or Write (0x30) command will be used. If multiple R/W mode available: 0xC4 (Read Multiple) and 0xC5 (Write Multiple) commands will be used.
- In sub 0x2038084 (0x82006FBC): This function reads sectors. Around 0x803211C (0x82007054), HDD is set to LBA mode. Then starting from 0x2038194 (0x820070CC), the start sector address is stored in registers 0x1C661F3 to F6: Bits 7:0 to LBA Low, 15:8 to LBA Mid, 23:16 to LBA High and 27:24 to Device Register. Then the previously stored read command code is retrieved from memory, i.e. 0xC4 which is "Read Multiple" command. According to ATA standard (http://www.t10.org/t13/project/d1410r3a-ATA-ATAPI-6.pdf) p.188, and as we can see, only 28-bit LBA is used here, so we can address no more than 137.4GB (2^28 * 512)!

That's why cpio.secure file is not read from 160GB drives, since hidden partition is located at the very end of the disk, below the 137.4GB limit!

According to the ATA standard, p.191, we should use instead "Read Multiple Ext" command (code 0x29) which used a 48-bit LBA. But, if i understand well the standard, this command uses the same registers but in 2 passes:
- First pass to write LBA bits 31:24, 39:32, 47:40 to LBA Low, Mid and High
- Second pass to write LBA bits 7:0, 15:8, 23:16 to LBA Low, Mid and High
2 passes are also used to extend the sector count from 8 to 16-bit, but i don't think we need to read so much sectors in our case ;-)
Device register is no more used for LBA, but only indicates which device is addressed and define LBA mode.

So we should be able to overcome the issue by using 0x29 command instead of 0xC4, but for that we need to write 2 times to the registers were the original code write only once. So we can't simply patch the aread, since we need more space to add a second pass.

We could create a subroutine in an unused space. Boot0 copies Flash memory zone 0x20310C8 to 0x20450C7 (= Boot1) to RAM (0x82000000). It seems to me that the space 0x020431C8 (0x82012100) to 0x020450C3 (0x82013FFB) is empty and unused, so we could probably use it.

So the solution could be:
- Patch sub 0x20382C4 (0x820071FC) to store command code 0x29 instead of 0xC4
- Patch sub 0x2038084 (0x82006FBC), replacing the portion of code starting at 0x2038194 (0x820070CC) by a BL to a new subroutine in the unused space.
- Add a new subroutine in the unused space with code to fill the 48-bit LBA in registers in 2 passes

Despite the write command code is also stored in memory, i've not found any other subroutine that could write to disk in boot1. Since boot1 just load and boot the kernel from cpio.secure, i believe that the kernel is able to handle big HDD correctly.

Since modifying the Flash is always a risky operation, I would appreciate if our great gurus out there could check my assumptions and confirm that the proposed solution is OK. Thanks in advance!

Best regards.
grond
Archos Guru
Archos Guru
Posts: 627
Joined: Thu Nov 23, 2006 10:37 pm
Location: Berlin
Contact:

Re: i give you: moldy cheese

Post by grond »

idontknow wrote:Since modifying the Flash is always a risky operation, I would appreciate if our great gurus out there could check my assumptions and confirm that the proposed solution is OK. Thanks in advance!


I think it will be much easier to just also flash the cpio to the bootrom where it is loaded from in your case. That is, once there is a stable "moldy cheese". The copy in the bootrom is used for the recovery operation so it should be made sure that it actually runs well for obvious reasons.
openAOS
Post Reply

Return to “Open Development”