[Aboriginal] Using native-build.sh for An Android native C compiler

[Earlence Fernandes]

>Have you tried to dlopen() one of the other shared libraries that comes
>with uClibc just to make sure that the issue is dlopen() and not it
>being really confused by that particular library?

I tried it with libm.a shipped with my native compiler. It worked ok!!

strange that is doesn't open /system/lib/libc.so
Thoughts?

-Earlence

On Sat, Jul 16, 2011 at 8:49 PM, Earlence Fernandes <earlenceferns at gmail.com
> wrote:

> Yes, it is bionic's libc.
> This is what readelf says about the header:
> $ readelf -h /system/lib/libc.so
> ELF Header:
>   Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
>   Class:                             ELF32
>   Data:                              2's complement, little endian
>   Version:                           1 (current)
>   OS/ABI:                            UNIX - System V
>   ABI Version:                       0
>   Type:                              DYN (Shared object file)
>   Machine:                           ARM
>   Version:                           0x1
>   Entry point address:               0x0
>   Start of program headers:          52 (bytes into file)
>   Start of section headers:          273024 (bytes into file)
>   Flags:                             0x5000000, Version5 EABI
>   Size of this header:               52 (bytes)
>   Size of program headers:           32 (bytes)
>   Number of program headers:         6
>   Size of section headers:           40 (bytes)
>   Number of section headers:         22
>   Section header string table index: 21
>
> therefore, We can conclude
> 1. its a proper library for ARM EABI
> 2. its no an issue specific to my build (bcoz of the simple program I wrote
> to read this libc.so and the result of running it with multiple builds).
> 3. its a ucLibC thing.
>
> What I'm trying to do is basically compile and execute one of the root
> exploits directly on the device. No! I'm not a malware writer, but we are
> security researchers (http://few.vu.nl/~earlence)
>
> http://pastebin.com/JTUbLjcz
> That is the GingerBreak exploit that I'm trying to compile.
>
> -Earlence
>
>
> On Sat, Jul 16, 2011 at 8:18 PM, Rob Landley <rob at landley.net> wrote:
>
>> On 07/16/2011 12:59 PM, Earlence Fernandes wrote:
>> > Thank you for the reply.
>> >
>> > 1. gb is custom software (sorry I should have made a note of that).
>> > 2. I rewrote a simple program with one line
>> >
>> > void *dlh = dlopen("/system/lib/libc.so", RTLD_NOW);
>>
>> Um, question: is that bionic's libc you're attempting to dlopen?  (It's
>> an ELF binary, right?  What does readelf -a say about it?  Note that
>> attemting to dlopen() a linker script may not end well.)
>>
>> Have you tried to dlopen() one of the other shared libraries that comes
>> with uClibc just to make sure that the issue is dlopen() and not it
>> being really confused by that particular library?
>>
>> > I tried it on my build - same problem. seg fault.
>> > I tried it with the build you sent me, same problem - seg faults again.
>> >
>> > Is it possible to write a program precompiled with Android's dynamic
>> > linker that will bootstrap the uclibc version? (I know going off topic
>> > here).
>>
>> I don't understand what you're trying to do there, could you explain?
>> (You can exec one program from another, if that's what you mean by
>> boostrap.)
>>
>> > Or would it be possible to link the program against android ldl.a in the
>> > first place?
>>
>> I expect it's possible to link it, whether the result would work
>> involves knowing more about android than I do.
>>
>> > -Earlence
>>
>> Rob
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/aboriginal-landley.net/attachments/20110716/0dc46146/attachment-0003.htm>