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...
[DISCUSSION][SOLVED] ROOTING G2 Vision T-mobile
- Thread starter tubaking182
- Start date
- Status
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.
#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.
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.
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.
Last edited:
This explains some of the trouble with other methods...
http://android.git.kernel.org/?p=platform/bootable/recovery.git;a=commit;h=ecc76ba5516d62a886f9c290906e0ca50702c9ab
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"
http://android.git.kernel.org/?p=platform/bootable/recovery.git;a=commit;h=ecc76ba5516d62a886f9c290906e0ca50702c9ab
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"
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.
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.
That might explain why they have all those weird partitions. But the sizes aren't adding up.
The guy who rooted the MTS, eugene, must know how to get the custom recovery built. Can anyone contact him on twitter and link it to this page? I would but I don't have a twitter account...
The G2 /Desire Z/ Desire HD will have the same NAND protection as the EVO/Desire ect. so the only way to make permanent changes to the /system block is to unlock the NAND and flash a coustom recovery. Then you can edit any file from recovery but not while booted.
Has anyone tried this....
http://android.modaco.com/content/h...unching-recovery-on-your-device-without-a-pc/
http://android.modaco.com/content/h...unching-recovery-on-your-device-without-a-pc/
+1, this worked for me! Now testing android-wifi-tether, will post back with results
g2 is not what i expected
i got my g2 on sept 30th... and it does not have thethering or hotspot which pisses me off.... however i am sure there will be mods for it and hopefully soon.. i can not wait til i can hack this phone and use it full potential then i could put the nexus one for good and use the g2....
i got my g2 on sept 30th... and it does not have thethering or hotspot which pisses me off.... however i am sure there will be mods for it and hopefully soon.. i can not wait til i can hack this phone and use it full potential then i could put the nexus one for good and use the g2....
kennethpenn
Retired Forum Mod / Retired Recognized Developer
No, the script still does not yield permanent root. You have to go through the process every boot. Permanent root is blocked on finding a way to either disable the hardware's flash translation layer's write protection or flash and boot into a custom recovery so that we can write to flash from there.
For what it's worth, here are the boot and recovery images from my G2, if anyone needs them. I'm trying to teach myself how to work with them, but I'm out of time for tonight.
Boot and Recovery
Boot and Recovery
- Status
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
1Has anyone considered the possibility of a system.img that's being unpacked on boot? The root filesystem on our phones is unpacked from boot.img every time the phone is booted which is why there's trouble with the SGS and people rooting it by placing the su binary in /sbin...
Back on topic, the root filesystem can be changed at runtime, but reboot, and it all goes away. That's what sounds like is going on with the G2, but I don't have one to mess with.
