Get a Complete Set of Logs with Andy Log

The importance of proper logging is undeniable. No, we’re not talking about lumberjack work. … more

Try Some Android Lollipop Applications on Your Device

Android 5.0 Lollipop has been officially announced and lucky users of Google Nexus 5 … more

AutoCon Manages Your Connections to Perserve Battery Life

As we’ve talked about in the past, battery life is still somewhat of a sore … more

How to Unlock and Root a Nexus Device – XDA TV

It is official–Google has released the Nexus 6 and the Nexus 9. The Nexus family … more
Thread Closed

[DISCUSSION][SOLVED] ROOTING G2 Vision T-mobile

OP tubaking182

1st October 2010, 10:01 PM   |  #141  
sino8r's Avatar
Senior Member
Flag Birmingham, Alabama
Thanks Meter: 542
 
3,314 posts
Join Date:Joined: Sep 2006
More
Quote:
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...
1st October 2010, 10:10 PM   |  #142  
Junior Member
Thanks Meter: 6
 
28 posts
Join Date:Joined: Oct 2010
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.
1st October 2010, 10:23 PM   |  #143  
Junior Member
Thanks Meter: 6
 
28 posts
Join Date:Joined: Oct 2010
...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)
1st October 2010, 10:23 PM   |  #144  
Member
Thanks Meter: 13
 
45 posts
Join Date:Joined: May 2009
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.
Last edited by gariak; 2nd October 2010 at 12:25 AM. Reason: Added last line
1st October 2010, 10:48 PM   |  #145  
ultma75's Avatar
Senior Member
Flag Houston, Texas
Thanks Meter: 75
 
710 posts
Join Date:Joined: Jun 2009
More
Quote:
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
1st October 2010, 10:53 PM   |  #146  
Junior Member
Thanks Meter: 6
 
28 posts
Join Date:Joined: Oct 2010
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.
1st October 2010, 10:59 PM   |  #147  
Junior Member
Thanks Meter: 0
 
10 posts
Join Date:Joined: Aug 2010
I'll try it on Monday, when I get the phone. But hopefully there should be enough confirmation by then.

Cheers!
1st October 2010, 11:03 PM   |  #148  
Member
Thanks Meter: 13
 
45 posts
Join Date:Joined: May 2009
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"
1st October 2010, 11:30 PM   |  #149  
sino8r's Avatar
Senior Member
Flag Birmingham, Alabama
Thanks Meter: 542
 
3,314 posts
Join Date:Joined: Sep 2006
More
Quote:
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?
1st October 2010, 11:43 PM   |  #150  
Junior Member
Thanks Meter: 0
 
25 posts
Join Date:Joined: May 2009
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.

Thread Closed Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Top Threads in G2 and Desire Z Android Development by ThreadRank