yashsingh1/xdaforums huggingface dataset:
[G2 and Desire Z Android Development] hendusoone:
I've already tried that... after the message about "adb connection will be reset" it posted a line about spawning children, and then it just sat there for a while, didn't really see it doing anything. Was still able to connect with adb shell, but it didn't give a root prompt.

EDIT: After running rageagainstthecage through terminal emulator on the device, and connecting via adb shell, I did a ps. It lists out a couple thousand rageagainstthecage zombie processes. Still not a root shell, though. I wonder if I might be trying a different version of rage than others? I got it from a...

HOLY **** GUYS. I have a root prompt on the device in the terminal emulator. I need to figure out how the hell I got this...
[G2 and Desire Z Android Development] dyndragon:
Last i checked, terminal emulator doesn't allow you to run chmod or the rageagainstthecage binary. I get operation not permitted..so...

lol. as the interwebs say, pics or it didn't happen :-)

seriously though, breakthrough right here if true!
[G2 and Desire Z Android Development] rp1783:
Send me your gtalk let's collaborate on this.
[G2 and Desire Z Android Development] ace42588:
This thread is sorely lacking in direction. Collaboration is worthless without set goals and delegation. A check list of achieving root is in order. It should be highly abstracted so that no one gets bogged down by a preconceived set of limitations. Existing exploits are great for demonstrating attack vectors, but let us remember this is a different beast and the technical aspects of the exploits are likely going to require some tweaks.

Step one: Achieve access

-possible vector: adb

Elaborate.
[G2 and Desire Z Android Development] rp1783:
if hendusoone is correct, he has root. I disagree that collaboration is useless.

@hendusoone please pm me with your gtalk and we'll get this cracked.
[G2 and Desire Z Android Development] hendusoone:
I'm working on reproducing it right now, will post instructions once I've got it reliable.
[G2 and Desire Z Android Development] hendusoone:
Double post for reproducible instructions.

On PC:

adb push rageagainstthecage-arm5.bin /data/local/tmp

adb shell

cd /data/local/tmp

chmod 0755 rageagainstthecage-arm5.bin

exit

On G2:

Open terminal emulator

cd /data/local/tmp

./rageagainstthecage-arm5.bin

Wait a bit for it to say "Forked #### childs." Then hit enter. Should have a $ prompt.

Try running "ps" - should say Cannot fork.

Exit terminal emulator with back button, launch an app (I launched Twidroid from my home screen, this step might not be necessary)

Launch Terminal Emulator again - it will force close, hit Force Close

Launch Terminal Emulator a second time and you have a root shell

I used the rageagainstthecage binary from the download in this blog post: http://c-skills.blogspot.com/2010/08/droid2.html
[G2 and Desire Z Android Development] teferi:
I can confirm that this works. No /system/bin/cp, but I'll find a way to get a suid sh binary now that I have root. Thanks, hendusoone!
[G2 and Desire Z Android Development] gariak:
Confirmed! This works!
[G2 and Desire Z Android Development] tubaking182:
See if you can start adbd from term as root, then adb shell back in and see if you still have root there
[G2 and Desire Z Android Development] hendusoone:
If you then adb push busybox to /data/local/tmp and chmod 0755 it, you can then ./busybox cp whatever you want from Terminal Emulator. Now if I could remember the damn command to re-mount system as rw...
[G2 and Desire Z Android Development] ace42588:
I think launching the other app is key, in conjuction with the force close, it kills atleast one process, allowing room for the adbd to relaunch
[G2 and Desire Z Android Development] gariak:
mount -o rw,remount -t ext3 /dev/block/mmcblk0p25 /system
[G2 and Desire Z Android Development] gariak:
Can't get root from terminal, but I was able to busybox cp su into the system/bin.
[G2 and Desire Z Android Development] Bavilo:
Did you also copy SuperUser.apk to /system/app?
[G2 and Desire Z Android Development] gariak:
Yes, and busybox to /system/bin. And chmod 4755 to all 3. I think I'm good to go.

Yes! Su works in ADB now!
[G2 and Desire Z Android Development] teferi:
Changes to /system don't seem to be sticking across reboot (remount system rw, make a suid binary, remount ro, sync, reboot); is there something I'm missing?
[G2 and Desire Z Android Development] hendusoone:
Same problem here... after rebooting the phone, busybox and su were missing from /system/bin and Superuser.apk was missing from /system/app. Dunno what to do about that yet...
[G2 and Desire Z Android Development] lbcoder:
Start simple with root -- no need to go right to the superuser.apk....

cat `which sh` >/somewhere/writable/mysu

chown root.root /somewhere/writable/mysu

chmod 4755 /somewhere/writable/mysu

And there you should have a working su command (or actually "mysu" ;0).

If you can't write to anywhere in the PATH, doesn't matter -- you can still run

/somewhere/writable/mysu

and it shouldn't complain.

In fact, because this is a dangerous command, putting it in the PATH and naming it "su" would be ill-advised. The main objective is to have a usable command that will elevate the privileges to root as needed.

*** NOTE: You do NOT need to put the su command in your /system partition!!!! You can put it in /data/fartypants!
[G2 and Desire Z Android Development] gariak:
Doh, same here. Argh. I even remounted the system partition as read only before reboot.
[G2 and Desire Z Android Development] teferi:
lbcoder, it doesn't just have to be writable, it has to be not mounted nosuid, which, say, /data is
[G2 and Desire Z Android Development] lbcoder:
I'm thinking, I'm thinking... that the /system partition is ro with a ramdisk or other sort of wipe-on-boot above it to suck all your changes into the blackhole.
[G2 and Desire Z Android Development] lbcoder:
Hmm, that's not nice of them ....

Somebody post the output of "mount".
[G2 and Desire Z Android Development] teferi:
It's entirely possible that the bootloader locks down the /system partition before booting Linux. Other Android devices behave like this, no?

Here's 'mount' output (with /system/bin mounted "rw"):

rootfs / rootfs ro,relatime 0 0

tmpfs /dev tmpfs rw,relatime,mode=755 0 0

devpts /dev/pts devpts rw,relatime,mode=600 0 0

proc /proc proc rw,relatime 0 0

sysfs /sys sysfs rw,relatime 0 0

/dev/block/mmcblk0p25 /system ext3 rw,relatime,errors=continue,data=ordered 0 0

/dev/block/mmcblk0p26 /data ext3 rw,nosuid,nodev,relatime,errors=continue,data=ordered 0 0

/dev/block/mmcblk0p27 /cache ext3 rw,nosuid,nodev,relatime,errors=continue,data=ordered 0 0

/dev/block/mmcblk0p28 /devlog ext3 rw,nosuid,nodev,relatime,errors=continue,data=ordered 0 0

none /acct cgroup rw,relatime,cpuacct 0 0

tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0

none /dev/cpuctl cgroup rw,relatime,cpu 0 0

/dev/block/vold/179:33 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0

/dev/block/vold/179:33 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0

tmpfs /mnt/sdcard/.android_secure tmpfs ro,relatime,size=0k,mode=000 0 0
[G2 and Desire Z Android Development] notxel21:
Once we get root all packaged up and 100% it seems like we have a treat in store!

http://twitter.com/PaulOBrien/status/26109824654
[G2 and Desire Z Android Development] gariak:
$ mount

rootfs / rootfs ro,relatime 0 0

tmpfs /dev tmpfs rw,relatime,mode=755 0 0

devpts /dev/pts devpts rw,relatime,mode=600 0 0

proc /proc proc rw,relatime 0 0

sysfs /sys sysfs rw,relatime 0 0

/dev/block/mmcblk0p25 /system ext3 ro,relatime,errors=continue,data=ordered 0 0

/dev/block/mmcblk0p26 /data ext3 rw,nosuid,nodev,relatime,errors=continue,data=ordered 0 0

/dev/block/mmcblk0p27 /cache ext3 rw,nosuid,nodev,relatime,errors=continue,data=ordered 0 0

/dev/block/mmcblk0p28 /devlog ext3 rw,nosuid,nodev,relatime,errors=continue,data=ordered 0 0

none /acct cgroup rw,relatime,cpuacct 0 0

tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0

none /dev/cpuctl cgroup rw,relatime,cpu 0 0

/dev/block/vold/179:33 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0

/dev/block/vold/179:33 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0

tmpfs /mnt/sdcard/.android_secure tmpfs ro,relatime,size=0k,mode=000 0 0

/dev/block/dm-0 /mnt/asec/com.coupons.GroceryIQ-1 vfat ro,dirsync,nosuid,nodev,noexec,relatime,uid=1000,fmask=0222,dmask=0222,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0

/dev/block/dm-1 /mnt/asec/com.rovio.angrybirds_lite-1 vfat ro,dirsync,nosuid,nodev,noexec,relatime,uid=1000,fmask=0222,dmask=0222,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0

$
[G2 and Desire Z Android Development] lbcoder:
There don't appear to be any weird mounts going on... and that includes ramdisks -- which begs the question, when you copy files into the /system partition, WHERE ARE THEY GOING?

They have to be *somewhere*. If there's no ramdisk over it, then they *must* be going to nand.

OR... this may not be a typical nand chip.

Its using MMC drivers, not MTD like previous HTC phones... There could be a cache on the disk!

And they way you force a cache to synchronize to the disk is by overflowing it!

So try making a simple su binary, and then make a big dump of /dev/zero into some file like /system/diebufferdie until it stops, then sync, remount ro, reboot.
[G2 and Desire Z Android Development] lbcoder:
I could also use the output of "fdisk -l" for the mmcblk0 device (requires busybox).
[G2 and Desire Z Android Development] gariak:
To free up processes, I ran ./busybox killall rageagainstthecage-arm5.bin

For what it's worth.
[G2 and Desire Z Android Development] teferi:
Sure seems to me that the hardware's flash translation layer (that presents the MMC interface to Linux) is just ignoring writes to /system and that what we're seeing is either stuff in the page cache or stuff in an internal cache the FTL has. There's no reason to suppose that filling the FTL cache will cause changes to be written instead of thrown away.
[G2 and Desire Z Android Development] lbcoder:
Throwing writes away has the downside of making everything crash. Holding them off is typical behavior of caches and is much more likely.

However, there is another interesting though you prompted... disable some caching. If its using any......

First, get the output of "free", then write a 100 MB file to /system, then get the output of "free" again. We're looking for any major changes to the value of "buffers" or "cache". If these go up linearly with writes, then (1) overflowing the cache WILL force a write (unless it is write protected at a hardware level), or (2) can simply disable this behavior with a sysctl (though I forget which...)
[G2 and Desire Z Android Development] teferi:
It has the downside of making everything crash, unless it's expected that there will be no writes to begin with.
[G2 and Desire Z Android Development] teferi:
OK, it's not just stuff sticking in the page cache, writes to /system persist across echo 3 > /proc/sys/vm/drop_caches. So, definitely something in the underlying hardware (or something the underlying hardware has been told to do by the bootloader before jumping to the kernel)
[G2 and Desire Z Android Development] lbcoder:
Try writing tons to /system.

1 of 3 things *will* happen;

1) RAM usage will rise with the data you write,

2) The thing will crash hard,

3) It will finally actually write the data.
[G2 and Desire Z Android Development] sino8r:
Good progress guys. I was thinking it might be like the MTS recovery where the /system folder is ro unless mounted in recovery first. But I might be like 40 steps behind you... if that's the case... disregard this post, please.
[G2 and Desire Z Android Development] lbcoder:
Holy motherf***er! There's some magical insanity going on in there....

The extended partitions appear to be duplicated.

How many are there in total (look in /dev/block)?
[G2 and Desire Z Android Development] 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.
[G2 and Desire Z Android Development] gariak:
Output from ls in /dev/block:

dm-1

dm-0

vold

mmcblk1p3

mmcblk1p2

mmcblk1p1

mmcblk1

loop7

loop6

loop5

loop4

loop3

loop2

loop1

loop0

ram7

ram6

ram5

ram4

ram3

ram2

ram1

ram0

mmcblk0p28

mmcblk0p27

mmcblk0p26

mmcblk0p25

mmcblk0p24

mmcblk0p23

mmcblk0p22

mmcblk0p21

mmcblk0p20

mmcblk0p19

mmcblk0p18

mmcblk0p17

mmcblk0p16

mmcblk0p15

mmcblk0p14

mmcblk0p13

mmcblk0p12

mmcblk0p11

mmcblk0p10

mmcblk0p9

mmcblk0p8

mmcblk0p7

mmcblk0p6

mmcblk0p5

mmcblk0p4

mmcblk0p3

mmcblk0p2

mmcblk0p1

mmcblk0
[G2 and Desire Z Android Development] teferi:
lbcoder, no joy on the cache-overflow attack
[G2 and Desire Z Android Development] tubaking182:
i remember finding a build for the vision with security off SPL, would we be able to use the flash_image command to flash the bootloader and allow read/write access?
[G2 and Desire Z Android Development] sino8r:
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...
[G2 and Desire Z Android Development] teferi:
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.
[G2 and Desire Z Android Development] teferi:
...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)
[G2 and Desire Z Android Development] 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.

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.
[G2 and Desire Z Android Development] ultma75:
anyone try this? waiting on g2
[G2 and Desire Z Android Development] teferi:
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.
[G2 and Desire Z Android Development] logicsans:
I'll try it on Monday, when I get the phone. But hopefully there should be enough confirmation by then.

Cheers!
[G2 and Desire Z Android Development] gariak:
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"
[G2 and Desire Z Android Development] sino8r:
what about contacting koush or amon_ra to make a recovery or edit of theirs?
[G2 and Desire Z Android Development] biosehnsucht:
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.
[G2 and Desire Z Android Development] sino8r:
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...
[G2 and Desire Z Android Development] Bumble-Bee:
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.
[G2 and Desire Z Android Development] rp1783:
Has anyone tried this....

http://android.modaco.com/content/h...unching-recovery-on-your-device-without-a-pc/
[G2 and Desire Z Android Development] uplinked:
+1, this worked for me! Now testing android-wifi-tether, will post back with results
[G2 and Desire Z Android Development] pharmhand:
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....
[G2 and Desire Z Android Development] kennethpenn:
What does that method do? Is it permanent with that?
[G2 and Desire Z Android Development] teferi:
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.
[G2 and Desire Z Android Development] gariak:
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
[G2 and Desire Z Android Development] xalucardx:
kingklick92 twitted " G2 has #root ! "
[G2 and Desire Z Android Development] dcman008:
Root was found in this thread. But it does not last after reboot.
[G2 and Desire Z Android Development] sino8r:
please... no crap posts please!

sorry I'm kinda of grumpy tonight.
[G2 and Desire Z Android Development] joackie27:
The Evo was rooted by toastcfh using a leaked engineering rom. Maybe you guys can start from the leaked engineering rom of the G2? It's available for download here (http://shipped-roms.org/index.php?category=android&model=Vision).

Maybe the G2 would also require a 2 part root process just like the Evo. The 1st part will root it partially. It's just a partial root because you can not write to system or recovery while in android and also you can not flash a custom recovery that can be booted into by holding vol down and powering on. The last part will involve unlocking the NAND.

For reference purposes, here's the link for rooting the Evo

http://xdaforums.com/showthread.php?t=690762

and here's the link for unlocking the NAND protection on the Evo

http://xdaforums.com/showthread.php?t=701835

Here's a discussion of NAND unlocking as started by maejrep (AKA madcoder of TeamDouche)

http://xdaforums.com/showthread.php?t=694034
[G2 and Desire Z Android Development] nabzilla1990:
could any of those test roms maybe change the s-on to s-off how dangerous is it to flash also what do i rename it to to be able to flash it from the bootloader to get to the bootloader on the g2 you have to hold the track ball then hold the power button
[G2 and Desire Z Android Development] joackie27:
I'm guessing that to be able to flash the rom into the bootloader, you have to rename the test rom to PC10IMG.zip.
[G2 and Desire Z Android Development] gariak:
From the NAND unlock threads, it looks like they were working with a leaked recovery build that had adb enabled. I highly doubt that a Samsung recovery would work on an HTC phone with no modification other than renaming the file.
[G2 and Desire Z Android Development] joackie27:
What Samsung recovery are you talking about? The Evo was made by HTC. So it's an HTC phone. Also, nabzilla1990 was asking what filename the test rom needs to be in order for it to be flashed from the bootloader. My guess was PC10IMG.zip.
[G2 and Desire Z Android Development] unforgiven512:
Exactly...

UPDATE: Engineering build does not flash, though it does appear to verify...
[G2 and Desire Z Android Development] joackie27:
You've flashed it via bootloader right?

EDIT: The engineering build from Shipped-ROMs (PC10IMG_Vision_TMOUS_1.12.531.0_Radio_12.18.60.05P_26.01.00.17_M2_test_144460) contains 3 files (crc file, zip file, and an excel file). Did you extract the zip file first?
[G2 and Desire Z Android Development] gariak:
Whoops, getting my methods criss-crossed, my bad. Regardless, the engineering build is an older version, so won't overwrite the new one unless someone knows how to alter the version without screwing it up. It might make a good starting point though, for someone who knows more than I do.
[G2 and Desire Z Android Development] joackie27:
The leaked engineering build for the G2 has a bootloader with a version # 0.76.2000. That was the same version # for the Evo. We refer to that (0.76.2000) back in the Evo threads as the ENG-HBOOT.