Originally Posted by lbcoder

.... ??
How about some crazy thing like....
mkdir /craziness
mount -t ext3 /dev/block/mmcblk0p49 /craziness
copy files into /craziness, sync, and reboot before it blows up.

Hahaha! Cute... yeah I saw all those crzy partitions last night while looking for the disk size.

I didn't realize you were trying through ext3...

Why if heck are all those partitions in there to begin with? I've never seen that many...

It looks like the busybox binary I grabbed will revert to your real uid (not effective uid), so you can't do anything useful with if if you've made a SUID shell and launched it from an unprivileged adb prompt. If you're in a similar situation, the following short program may be useful:

#include <sys/types.h>
#include <unistd.h>

int main() {
setreuid(0,0);
execl("/system/bin/sh","sh");
return 1;
}

Compile and statically link it with a compiler targeting Linux armel and run it from a setuid shell, it'll set your real uid to 0 and busybox will let you do things privileged (including running 'busybox ash', which has history and some minimal line editing!)

Not a step forward in getting root to stick, but it's sure easier to explore on a real keyboard via adb shell rather than the phone one.

...or you could just copy Superuser.apk and its su into the appropriate places and set their permissions properly, which will be a lot easier (while still also not yet persisting across reboots)

To sum up so far:

At your command prompt on your computer:

adb push Superuser.apk /sdcard/Superuser.apk
adb push su /sdcard/su
adb push busybox /sdcard/busybox
adb push rageagainstthecage-arm5.bin /data/local/tmp/rageagainstthecage-arm5.bin

Open terminal program

$ cd data/local/tmp
$ chmod 0755 rageagainstthecage-arm5.bin
$ ./rageagainstthecage-arm5.bin

Let the process run until "Forked..." message
Hit enter

$ ./rageagainstthecage-arm5.bin

See unable to fork message
Hit Menu button and Reset Terminal
Re-open terminal program
You should have a # prompt instead of $

(I've created a script that does the following)

# /data/local/tmp/busybox killall rageagainstthecage-arm5.bin
# mount -o rw,remount -t ext3 /dev/block/mmcblk0p25 /system
# /data/local/tmp/busybox cp /sdcard/Superuser.apk /system/app/Superuser.apk
# /data/local/tmp/busybox cp /sdcard/su /system/bin/su
# /data/local/tmp/busybox cp /sdcard/busybox /system/bin/busybox
# chmod 4755 /system/bin/su
# chmod 4755 /system/bin/busybox
# mount -o ro,remount -t ext3 /dev/block/mmcblk0p25 /system

After this, I can run su in the adb shell and get root via adb.
NOTE: if you exit adb and rerun it, you lose root (via adb, not in the terminal) and I haven't figured out a way to get it back, short of starting from the beginning again.

Originally Posted by gariak

To sum up so far:

At your command prompt on your computer:

adb push Superuser.apk /sdcard/Superuser.apk
adb push su /sdcard/su
adb push busybox /sdcard/busybox
adb push rageagainstthecage-arm5.bin /data/local/tmp/rageagainstthecage-arm5.bin

Open terminal program

$ cd data/local/tmp
$ chmod 0755 rageagainstthecage-arm5.bin
$ ./rageagainstthecage-arm5.bin

Let the process run until "Forked..." message
Hit enter

$ ./rageagainstthecage-arm5.bin

See unable to fork message
Hit Menu button and Reset Terminal
Re-open terminal program
You should have a # prompt instead of $

(I've created a script that does the following)

# /data/local/tmp/busybox killall rageagainstthecage-arm5.bin
# mount -o rw,remount -t ext3 /dev/block/mmcblk0p25 /system
# /data/local/tmp/busybox cp /sdcard/Superuser.apk /system/app/Superuser.apk
# /data/local/tmp/busybox cp /sdcard/su /system/bin/su
# /data/local/tmp/busybox cp /sdcard/busybox /system/bin/busybox
# chmod 4755 /system/bin/su
# chmod 4755 /system/bin/busybox
# mount -o ro,remount -t ext3 /dev/block/mmcblk0p25 /system

After this, I can run su in the adb shell and get root via adb.

anyone try this? waiting on g2

Off topic: Looks like they didn't try very hard to disable tethering...iptables and the usb ethernet gadget driver are still in the kernel and the iptables and dnsmasq binaries are present. Shouldn't be too hard to bring that up.

I'll try it on Monday, when I get the phone. But hopefully there should be enough confirmation by then.

Cheers!

This explains some of the trouble with other methods...

http://android.git.kernel.org/?p=pla...6e0ca50702c9ab

So what needs to be done to get a custom recovery made/adapted?

Perhaps this will be useful? I'm learning as I go...

cat /proc/emmc
dev: size erasesize name
mmcblk0p17: 00040000 00000200 "misc"
mmcblk0p21: 0087f400 00000200 "recovery"
mmcblk0p22: 00400000 00000200 "boot"
mmcblk0p25: 19fbfa00 00000200 "system"
mmcblk0p27: 0cccce00 00000200 "cache"
mmcblk0p26: 53200200 00000200 "userdata"
mmcblk0p28: 01400000 00000200 "devlog"

Originally Posted by gariak

This explains some of the trouble with other methods...

http://android.git.kernel.org/?p=pla...6e0ca50702c9ab

So what needs to be done to get a custom recovery made/adapted?

Perhaps this will be useful? I'm learning as I go...

cat /proc/emmc
dev: size erasesize name
mmcblk0p17: 00040000 00000200 "misc"
mmcblk0p21: 0087f400 00000200 "recovery"
mmcblk0p22: 00400000 00000200 "boot"
mmcblk0p25: 19fbfa00 00000200 "system"
mmcblk0p27: 0cccce00 00000200 "cache"
mmcblk0p26: 53200200 00000200 "userdata"
mmcblk0p28: 01400000 00000200 "devlog"

what about contacting koush or amon_ra to make a recovery or edit of theirs?

If the NAND is being presented as mmc type device, perhaps the baseband ("radio") processor is performing mmc to nand conversion, and also acting as a gatekeeper? Don't the baseband processors often perform other interfacing functions in other devices?

This might also be relevant to the ~2.1GB mmc size weirdness - there are of course not going to be non-power-of-two NAND devices so all these ~2.1GB devices must have 4GB of space but may show up with an odd number of sectors due to gatekeeping by the baseband processor.

The baseband processor might simply discard any writes to certain sectors not being performed in an approved fashion (perhaps using special IPC calls or by first authenticating with it to enable write through). Perhaps it caches writes in the "rest" of the NAND space, until the next reboot?

Perhaps there is some kind of dual partition set up like a Tivo for the system partitions, so you write your OS update to the other partition set (through whatever nonstandard methods are used), write config someplace indicating to use the other partition set, reboot, bootloader tries booting and if things don't check out, revert to previous partition set.