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

[Rob Landley]

On 07/16/2011 01:49 PM, Earlence Fernandes 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

Alas, you're asking uClibc questions, which need to be asked on the
uClibc mailing list.

It's reasonably straightforward to drop the bionic libraries in place of
the uClibc libraries, the compiler itself should have no dependencies on
uClibc (with the possible exception of libgcc.so, but you can just
delete that and ccwrap will use libgcc.a and libgcc_eh.a instead).

A good start would be reading the ccwrap.c source, it's reasonably small
and overrides all of gcc's path logic that I could find.

Rob

 1310862822.0