問題タブ [ld-preload]

LD_PRELOAD を使用して so をロードするときに、いくつかの問題が発生しました。

手順は次のとおりです。

1. libtest.c:

   /li>

2. gcc -o libtest.so libtest.c -fPIC --shared

3. export LD_PRELOAD= pwd/libtest.so

4. main.c

   extern void fun(); void main() { fun() }

5. gcc -o メイン -L。main.c -ltest

6. それでldd main

   ldd main linux-vdso.so.1=>(0x00007ffff7ffd000) /home/shiyanlou/Code/libtest.so(0x00007ffff7df9000) libtest.so=>not found libc.so.6=>/lib/x86_64-linux-gnu/libc.so.6 (0x00007ffffa29000) /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)

7. 促進する main を実行./main します: 共有ライブラリのロード中にエラーが発生しました: libtest.so。共有オブジェクト ファイルを開けません: そのようなファイルまたはディレクトリはありません。

LD_PRELOAD変数をエクスポートした後、libtest.soが見つからないというプロンプトが表示されるのはなぜだろうか。ただし、LD_PRELOAD を使用して別の共有ライブラリ (「libc.so」ではない) を指定し、malloc 関数を挿入しようとしましたが、うまくいきました。リンク時に使用されなかった共有ライブラリに対してのみ LD_PRELOAD が機能するのはなぜですか???

ソフトウェアを 32 ビットから 64 ビットにアップグレードした後、コンパイル済みのバイナリが次のエラーで失敗し始めます。

mycommand/usr/bin/mycommand にあるプリコンパイル済みバイナリです。LD_PRELOAD としてライブラリが必要です。

明らかに、ファイル /opt/xyz/lib/mylib.so が存在することを確認しました。

このエラー以外に抽出できるデバッグ情報はありますか? mylib.so を単に削除してもしなくても、エラーは同じままです。ライブラリをプリロードできないのか、それともライブラリが見つからないのかを言うのはちょっと難しいです。

LD_PRELOAD が機能するために必要な環境変数やライブラリは他にありますか?

mycommand バイナリーのソース・コードのバージョンを取得して再コンパイルすることは、私には不可欠のように思えます。ただし、それを行うには、実際になぜ今失敗するのかを確認することがおそらく役立つと思います。

他のアプリでメモリ リークを検出する小さな高速アプリを作成しています。私は LD_PRELOAD をデフォルトのオーバーライドに使用mallocし、これをプログラム内の呼び出しごとにメモリに保存しmallocます。問題は、C の一部のライブラリ関数も使用するmallocことです。さらに、割り当てられたメモリを解放しないライブラリ関数があります。デモしましょう:
MyApp.cpp

そしてtest.c。(最初はソース コードがなく、プログラムしかないとします。)

プログラム./testを実行して、次を確認します。

しかし、私は見たい：

mallocアプリでライブラリ関数のコールを回避したい。しかし、私はそれを行う方法がわかりません。
どの関数がそれを呼び出しているかを見つけることができmallocますか: ライブラリまたは独自のものですか? mallocまたは、ライブラリ関数でオーバーライドではなくデフォルトを呼び出すようにすることはできますか? または、他の何か？
PS 下手な英語で申し訳ありません。

私のシステムで open() syscall のラッパーとして以下を使用しています...これを .so ファイルにコンパイルしました....そして /etc/ld.so.preload に入れました。それはうまく機能しているようです...

すべてのバイナリで機能します... vim、touch、cat、less、headなど....例外... "ls"コマンド!!

理由がわかりません。

「sudo ls」を使用すると、ラッパーが再び正しく使用されてしまいます....

では、共有ライブラリ ローダーが open() ラッパー関数をスキップできると判断する「ls」の特別な点は何ですか?

リンクされていることがわかります（私のリンクはlibtracing.soと呼ばれる2番目のものです）。

これは、sudoを実行するかどうかに関係なく、他のコマンドでは発生しません。それらはすべて機能しているようです。

これは libselinux のおかげで何か特別なことですか? 誰か考えがありますか？

GNU C 標準ライブラリのソースを見ると、system関数呼び出しの実装が表示されます__fork()。独自のラッパー__forkとLD_PRELOADテクニックでその呼び出しをインターセプトする必要があります。

私は使用方法を知っていると思いますLD_PRELOAD：

1. __fork()アプリケーションで自分自身を呼び出すと、正しくインターセプトされます。__fork()ということは、原則 として傍受できるということです。
2. 標準ライブラリの実装に変更__fork()し、標準ライブラリを再コンパイルして使用すると、傍受されます。fork()system()fork()

ただし、__fork()標準ライブラリでは傍受されません-私のラッパーは呼び出されません。

どうして？？

LD_PRELOAD を、64 ビットまたは 32 ビットのアプリケーションを実行できる共有ライブラリを指すように設定したいと考えています。共有ライブラリと実行可能ファイルのビット数が一致している必要があることは明らかです。

ここで、hello32 は 32 ビット アプリケーションです。世界には、私ができるはずだと言っているページがいくつかあります。

$LIB は、アプリケーションが 32 ビットか 64 ビットかに応じて、lib と lib64 を自動的に切り替えます。しかし、明らかにこれは機能しません。

これを機能させるためのトリックはありますか？LD_PRELOAD_32、LD_PRELOAD_64? ありがとう！

スクリプトで次のようなことをすると

私はいつも次のようなものを手に入れます

そのファイルは完全に存在し、rlwrap を削除しても問題なく動作しますが。

LD_PRELOAD を rlwrap に入れるにはどうすればよいですか? command基本的に、mylib.so を自分の ' ' のみに適用したいと考えています。

LD_PRELOAD=mylib.sorlwrap から入れてみましたが、動作しますが、LD_PRELOAD が思い通りに適用さcommandれませんでした。

ls などの通常のネイティブ アプリで LD_PRELOAD を使用できます。

いくつか検索した後、次のようなプロパティを設定することで、Java アプリで使用することもできました。

ただし、メディアサーバープロセスで LD_PRELOAD を使用することに興味があります。バックグラウンドで常に動作するため、これは注意が必要です。強制終了すると、自動的に再起動されます。次のコマンドで「2 番目のインスタンス」を開始できます。

「2番目のインスタンス」はどの再生にも使用されませんが、ライブラリをロードします。常に元のメディアサーバーがメディア操作を処理します。デバイス上のinit.rcファイルを変更せずにメディアサーバーでLD_PRELOADを使用する方法はありますか?

免責事項、私はこのhttps://blog.gopheracademy.com/advent-2015/libc-hooking-go-shared-libraries/の基礎として次の記事を使用したため、Golang は初めてです。

OpenSSL ライブラリの SSL_read および SSL_write への呼び出しをインターセプトする LD_PRELOAD ライブラリを作成しようとしています。

これは私がこれまでに思いついたコードです:

私はこの方法でコードをコンパイルしています：

そして、openssl s_client でテストします:

ただし、これは原因となっているエラーです。

SSL_read 関数でバッファにアクセスする適切な方法は何ですか。試みましunsafe.Pointerたが、タイプを値にバインドできませんというエラーが発生しました。

アップデート：

SSL 構造体は、openssl.h で定義されています。そのインポートを追加すると、機能と競合しSSL_readます。

純粋な C コードでは、単純なvoid*ポインターを使用するだけで十分です。これを SSL およびバッファー用に置き換えるとunsafe.Pointer、次のエラーが発生します。

次のように、共有ライブラリが存在しない場合はロードをトリガーせずdlopen()に、以前の呼び出しを使用して共有ライブラリがプロセスにロードされているかどうかを確認するために使用することに慣れています。dlopen()

私は最近、同じパターンを適用して、一握りの共有ライブラリの 1 つが LD_PRELOAD を使用してプロセス空間にロードされているかどうかを判断しようとしました。ただし、すべての場合において、上記の呼び出しは をdlopen()返しますNULL。

基本的に、このコマンドラインを使用してプロセスを開始すると

次に、mycoolprocess.c のコードで次のチェックを実行します。

への呼び出しは、共有ライブラリが LD_PRELOAD を使用してロードされているかどうかに関係なく、dlopen()常に戻ります。NULL以下の Andrew Henle のコメントに基づいてdlopen、リロードされた共有オブジェクトの 1 つへの絶対パスを使用して呼び出しも試みましたがdlopen、この場合、共有オブジェクトがプリロードされているにもかかわらず NULL を返します。

だから私の質問は2つあります：

1. 上記のパターンは、LD_PRELOAD を使用してロードされたライブラリに対して機能する必要がありますか?
2. 特定の共有ライブラリがプリロードされているかどうかをプロセスに判断させる別の方法はありますか?