[Aboriginal] Using native-build.sh for An Android native C compiler
earlenceferns at gmail.com
Sat Jul 16 12:16:36 PDT 2011
note that I modify PATH and LD_LIBRARY_PATH to _include_ the bin/ and lib/
of the native compiler.
otherwise, the executable does not run.
and I specify an absolute path in dlopen, so I dont see how it can get
On Sat, Jul 16, 2011 at 9:05 PM, Earlence Fernandes <earlenceferns at gmail.com
> >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
> 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
>> 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)
>> That is the GingerBreak exploit that I'm trying to compile.
>> 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
>>> > Or would it be possible to link the program against android ldl.a in
>>> > first place?
>>> I expect it's possible to link it, whether the result would work
>>> involves knowing more about android than I do.
>>> > -Earlence
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Aboriginal