Root filesystem image.

zelch · Dec 8, 2010

Alright, so the root filesystem image is in /mnt/system/androidmerged.squashfs.secure

So do a temp root, copy to /mnt/storage, and then a adb pull gets it over.

The squashfs itself is offset by 256 bytes, so:

losetup -o 256 /dev/loop0 ./androidmerged.squashfs.secure

At this point, the FS can be mounted or unsquashfs can be used to extract it.

So, what's the first 256 bytes? The secure implies some type of signature, but what kind, and what else is in all those bytes?

I'm not feeling brave enough to try just grabbing the first 256 bytes and appending a modified squashfs image to it on my device just yet, but if others try please report back. (On both if it works, and if not what it takes to recover the unit.)

chrulri · Dec 8, 2010

how big is it? can you upload it somewhere? (or would this be illegal?)

damm.. i need my 101!

krohnjw · Dec 8, 2010

chulri said:
how big is it? can you upload it somewhere? (or would this be illegal?)

damm.. i need my 101!

75 MB - uploading now

Edit: And up: http://hotfile.com/dl/88050103/f99f306/androidmerged.squashfs.secure.html

chrulri · Dec 8, 2010

thx!

chrulri · Dec 8, 2010

how would you replace the root fs image on the device?

zelch · Dec 8, 2010

chulri said:
how would you replace the root fs image on the device?

Connect via ADB, do a temproot, put the file in /mnt/storage, then copy it into /mnt/system overwriting the existing file. /mnt/storage is an ext3 filesystem mounted read/write, however I simply do not know if it will be possible to recover the unit if there is some kind of signature verification and we fail due to a modified image.

Again, someone braver then I should make this attempt and let us know how it goes.

The source did not give all that many hints, but I need to dig through in some more detail.

krohnjw · Dec 8, 2010

zelch said:
Connect via ADB, do a temproot, put the file in /mnt/storage, then copy it into /mnt/system overwriting the existing file. /mnt/storage is an ext3 filesystem mounted read/write, however I simply do not know if it will be possible to recover the unit if there is some kind of signature verification and we fail due to a modified image.

Again, someone braver then I should make this attempt and let us know how it goes.

The source did not give all that many hints, but I need to dig through in some more detail.

If the unit will still boot to recovery could a full wipe and reinstall of the base AOS over USB get it back up and running?

kenyu73 · Dec 8, 2010

krohnjw said:
If the unit will still boot to recovery could a full wipe and reinstall of the base AOS over USB get it back up and running?

Recovery shouldn't be part of the FS so at worst, you'd have to do a format/firmware install.

L0$t$0ul · Dec 8, 2010

You can do a full system wipe/format from recovery. it's not in any damageable storage by us without flashing a new recovery image.

Interesting about the front 256 bytes. It must be a signature. Not sure what good rebuilding the squashfs will do as it'll still be read only but it's a start. We could at least update the system properly and install the appropriate apps. Maybe in make some of the system dirs symlinks to writable locations possibly.

zelch · Dec 8, 2010

Permroot, giving us a filesystem mounted RW and not no-suid.

Ideally, I'd like to have decent support for the internal storage being ext3 without nosuid, but first we need to be able to replace the root filesystem image.

Other notes..

Looking at the hexdumps, the 256 byte chunk does not contain the start of the md5, sha1, sha224, sha256, sha384, or sha512 checksums.

The most troubling option which comes to mind is that it is the right size for a RSA 2048 bit block, hopefully not.

Anyone have ideas on how to find the initramfs image that the bootloader is feeding the kernel?

For that matter, has anyone tried taking apart the OS update images?

chrulri · Dec 8, 2010

zelch said:
For that matter, has anyone tried taking apart the OS update images?

I think the aos file or the responsible installer/updater should give us a lot of information about how this stuff can be updated.

zelch · Dec 9, 2010

chulri said:
I think the aos file or the responsible installer/updater should give us a lot of information about how this stuff can be updated.

Agreed.

It looks like usr/bin/abcbox in the root filesystem has something to do with the update process.

zelch · Dec 9, 2010

zelch said:
Agreed.

It looks like usr/bin/abcbox in the root filesystem has something to do with the update process.

And it definitely is!

On a rooted device:

Code:

/usr/bin # PATH=$PATH:/tmp
/usr/bin # ln -s /usr/bin/abcbox /tmp/cramfschecker
/usr/bin # cramfschecker
USAGE: cramfschecker FILENAME
/usr/bin # cramfschecker /mnt/system/androidmerged.squashfs.secure
cramfschecker : check against 2.0.54

cramfschecker verification OK

Anyone with some ARM disassembly skills feeling up to taking abcbox apart to see how it's doing the signature check?

zelch · Dec 9, 2010

And so I've been digging into this, and it turns out that this is really quite similar to how the Gen 7 Archos 5 IT is locked.

The signature there is a RSA + MD5 signature, which is really the worst case as that means a 2048 bit RSA key, so we're kinda screwed there.

http://strazzere.com/blog/?p=320 has a good description of the situation on the 5IT. Getting a flash_unlock binary should be fairly trivial, so perhaps we can tamper with the key store to add additional keys.

chrulri · Dec 9, 2010

ah zelch, this is good stuff.

i'm gonna diff the archos gpl kernel, looking for changes at mtd stuff. maybe we can build a kernel module which enables r/w access to stage1

edit: or do we already have r/w access?

Hexidecimal · Dec 9, 2010

This stuff is all pretty interesting to read, but if I'm reading this correctly (and it is entirely possible I'm not) it looks kind of like this device is going to be a total pain in the ass to root, and it may take a considerable amount of time for us to get there.

Can someone who is more knowledgeable on this sort of thing verify that? Thanks for all your hard work guys. It's appreciated.

chrulri · Dec 9, 2010

its definitly not going to be that easy as other android devices were

but would it be so interesting if it wouldn't be so hard to root?

Hexidecimal · Dec 9, 2010

While that's true, it will make it a bigger triumph when it is finally rooted, the tinkerer in me is dying to mess with roms on this device and see what it can really do once it's cracked open. Keep up the great work guys, I'm following with baited breath.

zelch · Dec 9, 2010

Write to stage1 appears to exist, and indeed looking at /proc/mounts /mnt/rawfs is mounted rw. Looking at the kernel source, write support should Just Work.

So, looking through /mnt/rawfs avboot is clearly the boot loader which verifies stuff, but we lack source for it.

I have absolutely no knowledge of ARM asm, and screwing this up will absolutely brick your device, quite possibly beyond repair. (And I wouldn't bet on ArchOS being willing to replace it either, I sure wouldn't.)

So, anyone with the right background willing to step in here?

I'll keep digging, perhaps we can still find the answers.

Note: avboot has some strings which reference a development kernel, this bears some additional hunting.

chrulri · Dec 9, 2010

I still haven't got my A101, but its finally on its way to my home.
can you please upload these files and give me kind of a tree of the folder structure?

Root filesystem image.

Member

Senior Member

Inactive Recognized Developer

Senior Member

Senior Member

Member

Inactive Recognized Developer

Senior Member

Member

Member

Senior Member

Member

Member

Member

Senior Member

Senior Member

Senior Member

Senior Member

Member

Senior Member

Similar threads

Top Liked Posts