20
An update on the Archos 5 Android rooting…
Penguin inside ;)

Penguin inside ;)

Progress has been quiet slow as of lately, albeit progress none the less though. As normal, I figured I’d attempt to document this so that anyone attempting to root devices in the future that might be similar to the Archos might have an easier time :)

Thus far when rooting phones we have been coming in contact with less protection. After gaining root we have been able to remount the partitions and edit them directly – making the changes persistent immediately. Though there is a fundamental difference with the Archos that comes into play. The Archos stores everything on a (maybe two or three?) flash chips. The partitions of the chips are like normal phones and mounted as read-only. The problem comes into play since what is mounted is not a filesystem, but a cramfs file. This cramfs file is what needs to be modified to create any changes to the system files.

So just modify the cramfs file, right? Nope – Archos caught you on this one. Simply modifying the cramfs, which is actually a “cramfs.secure” file will lead to a bad signature error. What the heck is that all about? Essentially when Archos creates a firmware update and flashes a new ‘androidroot.cramfs.secure‘ to the device. This file is signed with a signature of itself. Sadly we cannot recreate the signature for the file since it’s an RSA/MD5 signature of the contents. This means that they basically run a program after the have a androidroot.cramfs to append the signature like the following:

secure = RSA(MD5(cramfsFile)) + cramfsFile;

The RSA function uses a private key that we do not, and most likely will never have. Essentially in the bootloader there is a program called cramfschecker that does something like the following pseudo code:

if(RSADecrypt(signature) == MD5(file)) ? return goodFile : return badFile;

The RSADecrypt function uses a public key that we have found, but is no help to us.

Alright, know that we know what files need to get modified and how we are locked out of them, how do we actually get past this? This is where we have to get into modifying the kernel and boot loader. The flash memory is a little tricky but essentially is mapped out like the following:
[code]
mtd device – name —– nickname – description
mtd0 ——- stage1 — boot0 —- bootloader part 1, also contains keystore
mtd1 ——- stage2 — boot1 —- bootloader part 2, also contains boot image
mtd2 ——- recovery – recovery – recovery kernel and recovery.cpio (filesystem)
mtd3 ——- init —– init —– init (main) kernel and init.cpio (filesystem)
[/code]
Now here is where the cool stuff comes into play. Stage1, among other things, checks the signature of stage2 to verify that it has not been modified. When stage2 begins it performs the same type of check on recovery and init. Inside recovery and init a program called cramfschecker is called, which checks the actual cramfs.secure files that we want to change. So the chain of trust is as follows:
Stage1 -> Stage2 -> recovery/init -> cramfs.secure
We need to modify Stage1 to accept any stage2, stage2 to accept any recovery/init and then remove the cramfschecker call so we can execute anything we’d like without worrying about if it is signed or not.

Now we know everything that needs to be done, so lets do it! Well, it’s sadly not that easy. We know how and can modify the cramfs files, that’s not hard. We can flash new a recovery/init, and even flash a new stage2. The problem is that we cannot currently flash a stage1 since it is marked as read-only after boot by the kernel. Yes, it is marked read-only, not locked – which if it where we could simply use a ‘flash_unlock‘ tool on it.

Currently I’ve been diving into the init kernel, which is at the beginning part of the init section, gzipped. This has been pretty tough trudging and I’ve enlisted the help of EiNSTeiN_. This is still pretty ugly stuff to look through though – we are basically looking for a small struct that make uses the kernel module to set the partition to read-only. The struct should look something like this:

Though this should all be GPLed code – since it is the kernel! Ah hah! That could make things so much easier. Sadly Archos has not yet posted the GPLed kernel source code for the Gen7 devices (which the Android model is).

After about two to three weeks of trying to track down someone, anyone with an Archos contact, or even just someone at Archos who isn’t outsourced technical support I finally got an answer! Prior to reaching this person I mainly got the run around, saying it will be up soon or that it is already posted. For some reason it also kept getting lost in the translation that I was requesting the GPLed *kernel* source code from the Archos 5 Android model. Someone in France apparently kept seeing “Android” and said “NO! It’s Apache, we don’t have to release that, Google hosts the source, goto them!” Finally I got a response, rather promptly I might add, from a USA Archos representative saying that Google hosts the code. After exchanging a few more emails they finally understood that I was requesting the Gen7 kernel source code, which is under the GPL license – NOT the Android source code which is under Apache. PHEW!

So the latest update is that we are essentially in a holding pattern, waiting for next week to come. I’ve been promised that the GPLed source code for the kernel will be posted by the end of next week, though I shouldn’t hold my breath until Friday. If it doesn’t appear on the site by Friday evening EST then I can start calling and complaining again… This time someone can actually be help responsible though, so I feel like it will actually happen. Once we get this code, it’s only a matter of time before EiNSTeiN_ and myself track down the right code which should help us in creating a program to patch the mtd partitions into being read/writable.

If you feel like you can help us with this, feel free to post here, email me or send a reply on twitter. Also if you just want to get the most updated information, I’d recommend you follow me on twitter @timstrazz.

Tim
18 Comments
  1. Hello I’m the owner of AllDroid. We are a forum for anything Android powered and would love for you to post and keep updating a post in our forum and possibly others can help. Email me back if you’d like more info

  2. Hey man amazing work!

    Looks like they released the Gen7 GPL Source, so whats the status?

  3. When we install apks on the 5IT, they are stored on the system partition right? So there is 2 possibilities : The 5IT can modify the CramFS OR there is another hidden partition on the HDD/SD card no? And what about the settings? And the database? I noticed that if we format the HDD, we loose all of them… So I think some of the data is stored on the HDD… but where…?

  4. @GCSX

    Ah, great comment — I actually forgot to mention how this works.

    Essentially there is a read/write flash chip that gets the /data folder of the Android system mounted to it. This holds the apk files, their local settings and databases. So the cramfs file is not actually being changed and resigned. This also keeps it off the hard drive so that the drive isn’t be accessed all the time (thus killing the battery).

  5. @Tim

    /mnt/system looks like read-write enabled partition. It also seems like good place to put a *su* executable if you had your root at least once. Or am I missing something.

    Can you describe how to get a root access in details?

  6. @jlg

    /mnt/system is actually on the harddrive — so it wouldn’t be good to have an executable running off of the harddrive — we want it to run from the flash memory.

    Also — if you notice your $PATH variable does not have /mnt/system included, so we would need to actually modify some things on the flash system to get this to function properly — which brings us back to having to patch the boot loader.

    I will be releasing the root method once everything is figured out and I have the patching done also.

  7. Hello, on Archos.com we have GPL GEN7 code source ?

    It is same kernel source you need or not ?

  8. @Vartan

    Yes, approximately a week after I posted this Archos posted the information along with placing a call to me to inform me it was up :)

  9. Hey Tim,
    What’s the status on this? Any luck with the patching? are you still planning to post the (temporary) root method you used? The word is the SDE for the A5IT is “imminent”:
    http://forum.archosfans.com/viewtopic.php?f=34&t=28881&p=193071#p193071

    Does that help your cause?

  10. Hi, just thought I’d let you know that the firmware update 1.6.08 (which was briefly out for about a day before Christmas and then pulled by Archos) turns out to be a development build. It lets you get root on the tablet through ADB. Perhaps this might be helpful in your efforts. You can get the firmware from here: http://www.theweeklycynic.com/misc/a5a.htm

  11. @soupdog
    No real updates yet, I haven’t gotten around to getting a crosscompiling environment working yet. Between work, holidays and enjoying my own (very little) free time I had a computer melt down that was my main dev machine — not fun! :) I also hardly use the Archos anymore… I will attempt to get it out before the SDE release, which if released should be an even better solution than mine.

    @googatrix
    Yes I saw the firmware and looking in it and saw it was a dev firmware, another good way to get root :)

  12. If I’m not mistaken, the kernel source code is available on Archos’s site..

  13. @sphantom

    Yeap, if you look at the date of this post, and the comments – you will see this has been pointed out already ;)

  14. Doh, sorry. Forgive me, I’m a wee bit anxious to root my A5IT =)

    Thanks for your contributions thus far.

  15. Hi,
    I saw that the first donut firmware 1.6.08 was published with Root access (true ?). Archos removed it after some hours but it can be download on forums. Is this version could help you to make a Root access for the new 1.7. 33 firmware ?

  16. Looking for a coder.

    I need a coder to create a simple extract of reviews for my apps so I can store it internally.

    Let me know if you are interested.

    Carl

  17. @Boosti

    I have a few root methods – though the most foolproof way to get root was to use their 1.6.08 version. I can’t guarantee people will be able to get root on 1.7+.

    In order to get root and KEEP it, you need to be on a rootable firmware version then patch the bootloader, which is what i’m working on now.

Your Name Email Website