yashsingh1/xdaforums huggingface dataset:
[Click Android Development] mainfram3:
Yup, I remounted it rw, but I still can't write anything. I always get a "no memory left" error. I even removed some mp3 ringtones and I always get 0 free bytes in /system. Preety weird.

And for bad news, I haven't been able to launch the exploit successfully in the past hours. My last guess is that there may be some kind of cpu throttling on low battery that was helping in the race condition. I had nearly 10% battery left when I started and now, with a full battery, I can't get the exploit to produce a root shell. I'm going to drain the battery and get some sleep.
[Click Android Development] HTCDevil:
Thanks for your hard work mainfram3, we all count on you..doesn't matter how long it will takes to have a root....we all are with you and appreciate your efforts very much. ;)
[Click Android Development] elvisior:
Reading this thread has taught me so much. I even went out and bought a tattoo just so I could have some fun too. :)

I've noticed that if I ring the tattoo phone while running m6 it seems to speed up the hack. Doesn't happen every time I ring it but more often than not.

Once you've got a # I do the following to make the commands work:

export LD_LIBRARY_PATH=/system/lib

export PATH=/system/bin

Edited .. forgot to say thanks for all your awesome work... I hope this leads to 2.1 on the tattoo..
[Click Android Development] mainfram3:
Elvisior,

Are you getting a root shell ?
[Click Android Development] elvisior:
sure looks like a root shell to me (and the id command) but i haven't managed to run anything yet that proves without a doubt that i have root priviledges.. i'm trying to echo things into /proc and see if they take effect (specifically around the /proc/mounts area)
[Click Android Development] mainfram3:
If id is giving you uid=0 then you're root :)

I've started to setup a script to help take control over the Tattoo, after we get a root shell.

It remounts /, /system and /data as rw. I don't know why but having a setuid sh binary doesn't spawn a root shell. I get a # as prompt but uid is still 2000.

I think one of the older test RUUs had a su binary in there and I'm currently looking for it. [EDIT: id reports uid as 2000 but I can go anywhere and do anything, so it's definitely a root shell.]

Also, let me just say that you getting a root shell makes me very happy. I'm not alone anymore! :D

----------------------

After a reboot the system cleans itself up really well. I thought /init.rc was permanent and modified it to provide a easy root shell after a reboot (so that I don't have to wait one hour for the exploit to work), but after the reset I lost all my modifications :S
[Click Android Development] -bm-:
No, you are not alone!

I've got a root-shell to :-)

Some about su: I took an su-binary from the sdk and pushed it on the tattoo. As root i can launch the su-binary and my GROUP-id which was shell before I think also changes to root. I remounted everything with rw and without nosuid, but i wasn't able to set the suid-bit for su in my root shell. I get:

# chmod u+s ./su
Bad mode

What am I doing wrong?

Here is the su-binary:

edit: Forgot the link:

http://www.fileuploadx.de/45656

Bastian
[Click Android Development] mainfram3:
"reboot -h", yup, I though I could ask a little help from reboot :D :D

Insertion is at 0xb0000100. I only remember noticing it once at a different address and the injection did not work.

Picture is related.
[Click Android Development] mainfram3:
There was moment, last night, that I started to wonder if I had imagined getting a root shell :D

The shell from the Android is preety dumb. Use chmod 4755 instead of chmod u+s.
[Click Android Development] -bm-:
Okay, that is working. I should have known that. Sorry for slowing you down by asking dump questions ;-)

So for everyone who doesn't want to run the exploit everytime to get root (you have to run it only one time sucessfully):

Take this su binary and push it in your tatto: http://www.fileuploadx.de/45656

adb push su /data/local/bin/su

You have to run the exploit until you get root and then run this as root:

# remount -o rw,remount /dev/block/mtdblock3 /data

(remount /data without the nosuid-option)

# chown root.root /data/local/bin/su
# chmod 4755 /data/local/bin/su

(change the owner to root and set the suid-bit

Now you don't have to run the exploit again, just open a normal shell and run

$ /data/local/bin/su

Now you should be root!

Attention: If you reboot your phone, you have to run the exploit and the mount command again because /data will be mounted nosuid again!

Bastian
[Click Android Development] mainfram3:
2 hours later, and I still haven't succeeded with the exploit. This is really driving me crazy.

elvisior,-bm-, have you guys, by any chance, found any way to improve the success rate ?
[Click Android Development] leon1984:
I've tried copying the file m6 and running from a terminal of the tattoo, not from a computer, the result is the same, I get the root, the first executions, I think the problem is that system variables are changed. If you look out the numbers that you are getting high.

One might test the idea of Modaco, once we have root permissions and we managed to run commands?

http://android.modaco.com/content/h...9976/13-jan-1-2-superboot-rooting-the-tattoo/

thx
[Click Android Development] -bm-:
For me it didn't take a long time until the exploit succeeded. You definitely should do some multitasking and occupy the CPU. I started dolphin and killed it with the "ES Task Manager" (the kill semes to bring the success) one or two times and it was done.

I will start a separate thread where I will keep track of what we have got so far so that not anybody has to read this whole thread and keep checking it.

By the way: Congratulations to all the devs who did that hard work. I'm very sorry for the brave Eris-guys who spent much time and brain just to bring us the success and to realize that it won't work on their device.

But this is a perfect example how open development should work and even my little part in the story is it to. I found the original exploit for x86 somewhere over the internet, the real work was done by others and they should get the glory, but it also shows that even non-developers like me could help a little bit by spending time.

How we will go on now? What road to take to custom roms?

Bastian
[Click Android Development] elvisior:
-bm- thanks for the su .. makes life much easier as I found I was dropping out of my root shell occasionally when a command would fail which was slowing me down heaps.

I haven't had a chance to try anything for a few hours but I just tried the exploit again with a 'while true; do; /data/local/bin/m6; done' and then rang the phone and I got a root shell the second it rang.. pretty cool.

I've just noticed there is a 'dd' binary there .. that's gotta be useful.. :)

Is there a simulator for these devices where I could dd the /system /cache and /data partitions and then reconstruct them there and try modifying them without fear of bricking the phone?

I'm off to do some reading about what the yaffs2 filesystem is...
[Click Android Development] zipredictive:
so we are few steps from the root?
[Click Android Development] mainfram3:
No. We already have root :cool:
[Click Android Development] Coburn64:
Looks like it.

BTW, sorry if I missed something, I have the su binary in this post. In that post, it says something about the exploit. What's this m6 exploit, and what post can I downlaod it from?

I'm just happy we're getting somewhere with root... Oh the joy of freedom! :D :D :D
[Click Android Development] zipredictive:
OMG guys...

I LOVE YOU​
[Click Android Development] -bm-:
I started a new thread where I count up everything we have got so far and where I will try to keep track of the ongoing development. There is also a howto-Root :-)

http://xdaforums.com/showthread.php?p=5676850

So I think this thread here should be reserved for the ongoing development. For to find out the status quo use the link above :-)

-bm-
[Click Android Development] -bm-:
Whats next?

I hope that all the experts don't leave after the first work is done ;-)

I think we have got 3 things to think about:

1. How to make the root-hack work for more people.

Maybe packing the exploit in a small one-button gui-app that could be installed as an apk?

2. How to make the root-hack permanent?

The problem: When we reboot, /data-partition is mounted with nosuid again. I think there is no fstab, the initrd must be modified - right? Anyone with knowledge about that?

3. From beeing root to flashing custom roms: I think the way isn't trivial, isn't it?

Any comments?

-bm-
[Click Android Development] BeerGood:
With regards to point one:

1. How to make the root-hack work for more people.

Does anybody know if this exploit works with the 2.6.27 kernel? I have a HTC Magic (it's the Canadian version of MyTouch). We've recently been screwed with a forced update that has a perfect SPL (1.76.0010).

I've tried the m6 executable and it looks promising but I always get:

usage: reboot [-n] [-p] [rebootcommand]

usage: reboot [-n] [-p] [rebootcommand]

usage: reboot [-n] [-p] [rebootcommand]

usage: reboot [-n] [-p] [rebootcommand]

reroc/5353/cmdline[ WIN! 5353

Wrote shellcode 9ab8 line 0

Wrote shellcode 9abc line 4

Wrote shellcode 9ac0 line 8

...

Wrote shellcode 9bc4 line 268

Wrote shellcode 9bc8 line 272

Wrote shellcode 9bcc line 276

[ Overwritten 0xb0000100

It just hangs there... I hit ctrl-c and run the exploit again but I never get a shell.

Am I beating a dead horse?
[Click Android Development] jamezelle:
You need to edit the init.rc to mount everything rw
[Click Android Development] elvisior:
This works for both mtd1 and mtd2 .. and based on this 'cat /proc/mtd' .. mtd2 is the one we want.

# cat /proc/mtd

dev: size erasesize name

mtd0: 000a0000 00020000 "misc"

mtd1: 00500000 00020000 "recovery"

mtd2: 00280000 00020000 "boot"

mtd3: 09600000 00020000 "system"

mtd4: 09600000 00020000 "cache"

mtd5: 0a520000 00020000 "userdata"

I've gotten a tiny little bit further (hopefully this helps someone with more clue than me):

From within adb (as root):

cat /dev/mtd/mtd2 > /sdcard/mtd2.img

From my mac (but it'll work on pretty much anything with perl):

adb pull /sdcard/mtd2.img /tmp/mtd2.img

Then grab this perl script to split the image:

http: //android-dls.com/files/linux/split_bootimg.zip (I'm new so can't post links)

Unzip it to get the split_bootimg.pl

Assuming you've put split_bootimg.pl and mtd2.img in /tmp:

cd /tmp

./split_bootimg.pl mtd2.img

Page size: 2048 (0x00000800)

Kernel size: 1900300 (0x001cff0c)

Ramdisk size: 160952 (0x000274b8)

Second size: 0 (0x00000000)

Board name:

Command line: no_console_suspend=1 console=null

Writing mtd2.img-kernel ... complete.

Writing mtd2.img-ramdisk.gz ... complete.

Now to see what's in the ramdisk.. :)

On my mac (or your linux box/etc) ...

cat mtd2.img-ramdisk.gz | gunzip -c | cpio -i

Then an 'ls' shows the following:

data init.bahamas.rc proc

default.prop init.goldfish.rc sbin

dev init.rc sys

init logo.rle system

So cool.. I've modified the line in init.rc from:

#mount yaffs2 mtd@userdata /data nosuid nodev

To:

mount yaffs2 mtd@userdata /data suid nodev

Now to work out how to repack it and get it back on to mtd2 and try it out.

Edit ... The page here helped me get this far:

http ://android-dls.com/wiki/index.php?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images (still cant post links)
[Click Android Development] jamezelle:
great post and how to i was going to post a how to but i was on my eris earlier.....now you guys need to unlock fastboot so you can load new kernels that provide permanent root.
[Click Android Development] elvisior:
Ok, I think I'm stuck...

When I try and prepare the boot partition for my new img (with the modified init.rc) I find it's not writable.. (I tried doing a flash_image to boot as well but that didn't work either).. Anyone got any ideas?

# cat /dev/zero > /dev/mtd/mtd2

cat: write error: Input/output error

Edit.. anyone know where i can get a copy of mtd-utils for the tattoo?
[Click Android Development] mainfram3:
Heya :)

I had the feeling that we were trying to go in to soon but your analisys is much more scientific ;)

I'll try to get some time off tonight to fine tune the exploit, based on your ideas.

Thanks for your continued interest in this.
[Click Android Development] chusen:
Thanks for your work, i crossed my fingers ;)
[Click Android Development] -bm-:
I'm totally out of time the next few days. I think this could be adjusted to compile mtd-utils in the android sdk:

http://elinux.org/CompilingMTDUtils

Hope somebody has got the time and knowledge to do.

-bm-
[Click Android Development] yash08:
I have been following this thread and others almost everyday since their creation. I held back posting because of my lack of knowladge in this area. I just want to say a big thanks to all the devs involved for their huge work.
[Click Android Development] bftb0:
Since the delay is quite long (in the Eris case) - I'm guessing somewhere around 14 milliseconds, it may be sufficient to just do something simple like usleep(14000); in between the fork() and the ptrace(). I refrained from trying that on the assumption that putting a system call in between the two could change the way that the kernel schedules pre-emption on the parent process. You will need to experiment with it to figure out what works best with the Tattoo... but trials on the Eris suggest the success rate can be improved greatly, and the peak is quite broad, so it should be robust for lots of different folks' Tattoos, even if they are operating with different process loads.

With the user-land simple loop (an integer add inside the loop), once I got close to the sweet spot, the peaking in successful attachments (with a "quiet" phone) is fairly broad. I ran a couple of trials with the different (total) delay loop counts, and here is what the sample results looked like on the Eris (number of successful attaches out of 500 attempts):

Delay #
LoopCnt Success
20,000 2
100,000 19
112,500 33
125,000 32
137,500 29
150,000 26
175,000 17
200,000 10
300,000 3

Having these discussions with you folks has proved very useful. I was just writing something about why I thought I was at a dead end with the Eris... and thought I would double check something to avoid writing some BS. When I went back and checked, I noticed something a little peculiar... something that provides a little glimmer of hope.

Stay tuned, but don't get your hopes up; it might be nothing

bftb0
[Click Android Development] mainfram3:
I've run lots of variations of your code (I have it reading the loopdelay from the command line): I find that with a delay of around ~97000 ops I can get a success rate of 1/5. But, if I insert the same delay in the exploit, I'm not seeing a greater success rate.

Your code runs the fork() inside a loop and I think this is altering the results, since we don't have the overhead of launching the exploit...

I've since gone a different route in trying to automate the exploit in a way that it can be left to run unattended for a few hours, trying to root and create a suid shell by itself.
[Click Android Development] bftb0:
Hi elvisior,

Just curious - what error messages did "flash_image" give you?

Seems kind of odd - flash_image must be on there to do exactly what you are trying - the only place it could be launched is from within a booted system (not from the bootloader, for instance). Did it complain about a signature check or something?

Here's an unrelated question, I hope you don't mind.

Could you report what 'cat /proc/cmdline' gives you?

bftb0
[Click Android Development] bftb0:
I doubt you made this mistake, since it seems you are quite familiar with the turf involved, but make sure that the compiler doesn't optimize away the loop. You might be right though - looping over the fork() changes the system load characteristics, and pretty much everything on the phone has a chance to affect the race window.

Good luck!

bftb0
[Click Android Development] mainfram3:
Where did you get flash_image from ? I can't seem to find this binary in any of the Tattoo rom images I got lying around :(

You do realize that if the command above had worked you'd have erased your boot partition, right ? :D

EDIT: Found flash_image, from cyanogen, at http://wiki.cyanogenmod.com/index.php/RE-recovery-img
[Click Android Development] bftb0:
Whoops - my question to elvisior must have caused some confusion - on the Eris, it ships from HTC in /system/bin/flash_image. I just assumed that it shipped on the Tattoo as well.

In the Eris 1.16.605.1 RUU, it looks like this:

ubuntu$ adb shell /system/bin/ls -l /system/bin/flash_image

-rwxr-xr-x root shell 9640 2009-11-17 06:07 flash_image

ubuntu$ adb pull /system/bin/flash_image flash_image

112 KB/s (9640 bytes in 0.083s)

ubuntu$ md5sum flash_image

16559f2c27d08ff1ddfcaca05fbf10fb flash_image

There is a version of the sources for flash_image under ./bootable/recovery/mtdutils/ in the Android/Cupcake source tree.

I just checked... I previously built from the sources the entire Cupcake (not Donut) Android tree, and the md5sum signature of the "flash_image" binary that I built is identical to the one that shipped on the Eris.

Don't know if that is relevant for the Tattoo; maybe yes, maybe no. But it is sort of good news, though: I don't remember specifically configuring the generic Android source tree to do a build which was any more specific than just "arm" architecture... so that suggests that "flash_image" has no hardware-specific dependencies: it relies on all that stuff being present in the kernel/drivers for the phone it runs on.

bftb0
[Click Android Development] mainfram3:
This is what I get from cyanogen's compiled flash_image:

$ md5sum.exe flash_image
8d99ef03593ca1143880b37c71376661 *flash_image

I took a very brief look at flash_image.c and it relies on the library from mtdtools, ie, it's not doing any direct funky stuff, so it _should_ work without problems on the Tattoo.

One thing I noticed is that the Tattoo's /system seems cleaned up. No debug/dev tools anywhere. I guess that with the evolution of Android this is more of a production build, not justifying the need for any dev tools.

I'm going to take a look at building Donut from source, to see what other goodies we have there :cool:
[Click Android Development] -bm-:
I build 1.6 from source a week or two ago. This is what is in /system/bin

am dumpcrash kill printenv setprop
applypatch dumpstate linker ps sh
applypatch_static dumpsys ln qemud showlease
app_process dvz log qemu-props sleep
bmgr flash_image logcat racoon smd
bootanimation fsck_msdos logwrapper radiooptions start
bugreport gdbserver ls reboot stop
cat getevent lsmod recovery surfaceflinger
check_prereq getprop mediaserver renice svc
chmod gzip mkdir rild sync
chown hd monkey rm system_server
cmp id mount rmdir toolbox
dalvikvm ifconfig mtpd rmmod top
date iftop mv route umount
dbus-daemon ime netcfg schedtest updater
dd input netstat schedtop vmstat
debuggerd insmod newfs_msdos sdutil vold
dexopt installd notify sendevent watchprops
df ioctl ping service wipe
dhcpcd iptables pm servicemanager
dmesg keystore pppd setconsole

I put all of these bins in a zip: http://www.fileuploadx.de/766983

They should be ready-to-run on the Tattoo.

Edit: There is also a folder /symbols/system/bin (I don't get what it is) but there are some different bins in it.

add-property-tag netperf
angeles netserver
applypatch opcontrol
applypatch_static openssl
app_process oprofiled
AudioHardwareRecord perm_checker
AudioHardwareRecordLoop ping
AudioInRecord pppd
backup_helper_test procmem
bootanimation procrank
btool qemud
check-lost+found qemu-props
check_prereq racoon
cpueater radiooptions
crasher recovery
daemonize rild
dalvikvm safe_iop_test
dbus-daemon schedtest
dbus-monitor scp
dbus-send sdutil
debuggerd service
dexdump servicemanager
dexopt sh
dhcpcd showlease
dumpstate showmap
dumpsys showslab
dvz sound
flash_image sqlite3
fsck_msdos SRecTest
gpustate SRecTestAudio
gzip ssh
icache strace
installd su
iptables surfaceflinger
ip-up-vpn system_server
keystore tcpdump
latencytop test-fb-refresh
librank test-fb-simple
libsqlite3_phone_number_utils_test test-opengl-codegen
libsqlite3_phonetic_string_utils_test test-opengl-filter
linker test-opengl-finish
logcat test-opengl-textures
logwrapper test-opengl-tritex
mediaserver timeinfo
memtest toolbox
mtpd updater
nc vold
netcfg wbxmltest

First look: Nothing I find to be interesting, but in case is it usefull here is the zip: http://www.fileuploadx.de/307399

-bm-
[Click Android Development] Coburn64:
As for the exploit, how easy would it be to do something like this to help us get root faster:

1) User Runs Exploit. (while 'true'; do /data/local/bin/m6; done)

2) Exploit runs, wins the race, overwrites a pointer and executes the payload (shellcode).

3) The exploit, after it's finished, checks to see if a root shell has been spawned.

4) If the exploit has failed to spawn a shell, echo "Oh shi-" and relaunch itself, repeating point numbers 2 & 3.

5) Once the exploit successfully makes a root shell, it echoes a message "Here is your root :D" and the hash (#) prompt appears.

I'm sure this won't be too hard, it's just when you finish injecting the code, check if there's a sh owned by root, if not, rerun the code. That way we can leave it on overnight and see if we got root in the morning. A simple check should do the trick.

Of course, easier said than done.
[Click Android Development] mainfram3:
flash_image

flash_image is acting up :(

Compiled Droid from source, using my own binary, this is what I get when I tried to flash a new boot partition:

# ./flash_image boot /sdcard/mynewimage.img
./flash_image boot /sdcard/mynewimage.img
mtd: erase failure at 0x00000000 (I/O error)
mtd: erase failure at 0x00000000 (I/O error)
mtd: skipping write block at 0x00000000
mtd: erase failure at 0x00020000 (I/O error)
mtd: erase failure at 0x00020000 (I/O error)
mtd: skipping write block at 0x00020000
mtd: erase failure at 0x00040000 (I/O error)
mtd: erase failure at 0x00040000 (I/O error)
mtd: skipping write block at 0x00040000
mtd: erase failure at 0x00060000 (I/O error)
mtd: erase failure at 0x00060000 (I/O error)
mtd: skipping write block at 0x00060000
mtd: erase failure at 0x00080000 (I/O error)
mtd: erase failure at 0x00080000 (I/O error)
(.....)
mtd: erase failure at 0x00260000 (I/O error)
mtd: erase failure at 0x00260000 (I/O error)
mtd: skipping write block at 0x00260000
error writing boot: No space left on device

Tried to erase the partition:

# cat /dev/zero > /dev/mtd/mtd2
cat /dev/zero > /dev/mtd/mtd2
write: I/O error

:confused:
[Click Android Development] segway_:
Hi,

i dont know if these pages will help finding the solution, but i think that you can

check it:

wxw.androidiani.com/forum/htc-magic-modding/4429-problema-nel-flash-della-recovery-modificata.html

(italian use google translate)

wxw.androidoverdrive.com/viewtopic.php?f=12&t=440

(replace wxw with www)
[Click Android Development] leon1984:
you're referring to this, segway???

We need translation italian->english

"fai cosi:

fastboot boot [path e nome recovery file] (fai il boot con la nuova recovery)

Aspetta un paio di minuti cosi la sdcard viene montata

adb shell mount -a

(Ignora gli errori)

adb push [path e nome recovery file] /system/recovery.img

adb push [path e nome recovery file] /sdcard/recovery-RAv1.2.1H.img

adb shell flash_image recovery /sdcard/recovery-RAv1.2.1H.img

fai sapere se da altri errori. questa procedura ha funzionato per me. "
[Click Android Development] coolbho3000:
^ Not going to help us. HTC has made this phone hell to root...
[Click Android Development] mainfram3:
Thanks for the links.

I can read italian, nothing amazing there.

The 2nd one is interesting, altough I believe his problem is different from ours (mine?).
[Click Android Development] coolbho3000:
I tried using dd to write to build.prop and change ro.secure to 0. It looked like it worked, but a reboot cleared the changes. :mad: