Root filesystem image.

---

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.)

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

damm.. i need my 101!

Originally Posted by chulri

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/f99f3...fs.secure.html

thx!

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

Originally Posted by chulri

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.

Originally Posted by zelch

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?

Originally Posted by krohnjw

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.

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.

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?