Yes, it is bionic's libc.<br>This is what readelf says about the header:<br>$ readelf -h /system/lib/libc.so<br>ELF Header:<br>  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 <br>  Class:                             ELF32<br>

  Data:                              2's complement, little endian<br>  Version:                           1 (current)<br>  OS/ABI:                            UNIX - System V<br>  ABI Version:                       0<br>

  Type:                              DYN (Shared object file)<br>  Machine:                           ARM<br>  Version:                           0x1<br>  Entry point address:               0x0<br>  Start of program headers:          52 (bytes into file)<br>

  Start of section headers:          273024 (bytes into file)<br>  Flags:                             0x5000000, Version5 EABI<br>  Size of this header:               52 (bytes)<br>  Size of program headers:           32 (bytes)<br>

  Number of program headers:         6<br>  Size of section headers:           40 (bytes)<br>  Number of section headers:         22<br>  Section header string table index: 21<br><br>therefore, We can conclude<br>1. its a proper library for ARM EABI<br>

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).<br>3. its a ucLibC thing.<br><br>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 (<a href="http://few.vu.nl/~earlence">http://few.vu.nl/~earlence</a>)<br>

<br><a href="http://pastebin.com/JTUbLjcz">http://pastebin.com/JTUbLjcz</a><br>That is the GingerBreak exploit that I'm trying to compile.<br><br>-Earlence<br><br><div class="gmail_quote">On Sat, Jul 16, 2011 at 8:18 PM, Rob Landley <span dir="ltr"><<a href="mailto:rob@landley.net">rob@landley.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">On 07/16/2011 12:59 PM, Earlence Fernandes wrote:<br>
> Thank you for the reply.<br>
><br>
> 1. gb is custom software (sorry I should have made a note of that).<br>
> 2. I rewrote a simple program with one line<br>
><br>
> void *dlh = dlopen("/system/lib/libc.so", RTLD_NOW);<br>
<br>
</div>Um, question: is that bionic's libc you're attempting to dlopen?  (It's<br>
an ELF binary, right?  What does readelf -a say about it?  Note that<br>
attemting to dlopen() a linker script may not end well.)<br>
<br>
Have you tried to dlopen() one of the other shared libraries that comes<br>
with uClibc just to make sure that the issue is dlopen() and not it<br>
being really confused by that particular library?<br>
<div class="im"><br>
> I tried it on my build - same problem. seg fault.<br>
> I tried it with the build you sent me, same problem - seg faults again.<br>
><br>
> Is it possible to write a program precompiled with Android's dynamic<br>
> linker that will bootstrap the uclibc version? (I know going off topic<br>
> here).<br>
<br>
</div>I don't understand what you're trying to do there, could you explain?<br>
(You can exec one program from another, if that's what you mean by<br>
boostrap.)<br>
<div class="im"><br>
> Or would it be possible to link the program against android ldl.a in the<br>
> first place?<br>
<br>
</div>I expect it's possible to link it, whether the result would work<br>
involves knowing more about android than I do.<br>
<br>
> -Earlence<br>
<font color="#888888"><br>
Rob<br>
</font></blockquote></div><br>