Bionicとlibcのスタブの実装

Question

アンドロイド以外のLinuxマシンでapkから取得したx86共有ライブラリを実行したいとします。

これはアンドロイドのlibcとリンクしていますので、アンドロイドのndkからlibc.soを手に入れました。 はしばらくの間、セグメンテーション違反をデバッグした後、私はlibc.soは「不正行為」と多くのライブラリ関数の唯一のNOPの実装が含まれていることを考え出し：

$ objdump -d libc.so | grep memalign -A 8 
0000bf82 <memalign>: 
    bf82:  55      push %ebp 
    bf83:  89 e5     mov %esp,%ebp 
    bf85:  5d      pop %ebp 
    bf86:  c3      ret  

今NDKは、これらの機能の実際の実装が含まれているlibc.aが含まれていますが、どのようにこれらをロードし、libc.soのnop機能をオーバーライドするプロセスを手に入れますか？ また、アンドロイドがこのトリックをやっている理由と、オーバーライドがそこでどのように機能しているかについて、さらに多くのコンテキストに興味があります。

Answer 1

NDKから取られたlibc.soはスタブだけを含んでいます。その目的は、共有ライブラリや実行可能ファイルを作成する際にリンカに必要な情報を提供することにあります。ここにはスタブライブラリが必要な理由のnice explanationがあります。

あなたは本当のlibc.soバイナリを必要とするのであれば - 二つの選択肢があります：

1. Androidデバイスから直接それをつかむ：お使いのデバイスの

   $ adb pull /system/lib/libc.so <local_destination> 
   

2. ダウンロード工場出荷時のROMイメージを、それを解凍は、ローカルのファイルシステムにsystem.imgをマウントしてから、マウントしたパーティションの/system/libから再度コピーしてください。

しかし、あなたは適切なバイナリを取得する場合でも、本当に痛いexersizeである - それはあなたのデスクトップLinux上で操作できるようにします。少なくとも2つの理由があります：

1. AndroidおよびデスクトップLinux ELFには、異なるインタープリターが必要です。あなたはreadelfでそれを確認することができます。

   $ readelf --all <android_binary> | grep interpreter 
   [Requesting program interpreter: /system/bin/linker] 
   $ readelf --all <linux_x64_binary> | grep interpreter 
   [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] 
   

   （通訳は、あなたのバイナリの実際のロードを実行し、カーネルによってロードされる小さなプログラムです）もちろんLinuxシステムには/system/bin/linkerを持っていないと、カーネルは、そのようなバイナリの読み込みを拒否します。したがって、セクションを適切にロードし、すべての依存関係を自分で解決する必要があります。

2. Androidカーネルはデスクトップと同じではありません。libc.soが依存しているため、ELFをロードしても何らかの形でまだカーネルと互換性がなく、確かに問題が発生します。それを先頭に

：彼らが同じハードウェアアーキテクチャをターゲットにしている場合でも、デスクトップGNU/Linux上でアンドロイドバイナリを再利用することは事実上不可能です。