実行前に「ブラウザプラグイン」ライブラリの依存関係を検出する方法

わかっているように、ライブラリの読み込みには2つの方法があります。実行前に「ブラウザプラグイン」ライブラリの依存関係を検出する方法

1）静的ライブラリ（.a）：アプリケーションにリンクされ、アプリケーションの一部となるオブジェクトコードのライブラリ。 2）動的にリンクされた共有オブジェクトライブラリ（.so）。アプリケーションの実行時にリンクし、2つの方法で使用できます。

a) Dynamically linked at run time but statically aware. 
b) Dynamically loaded/unloaded and linked during execution (i.e. browser plug-in) using the dynamic linking loader system functions.

コンパイル後、我々はタイプ ''

objdumpの-x USR/binに以下のように/ flashcp

.....

が

動的セクションのライブラリの依存関係を確認することができます：

NEEDED libc.so.6とlibgcc_s.so.1がNEEDED

私の質問は、タイプ 'b'ライブラリの依存関係をチェック/検出する方法ですか？実行前に検出する方法はありますか？

事前に感謝

サーウ

出典

2016-06-13 Thiru Shetty

これは純粋に動的なものです（理論的には、実行時にユーザーがdllの名前を入力する可能性があるため）、静的検査でこれをカバーする方法はわかりません。 –

私は通常、実行可能ファイルに対して 'ldd'コマンドを使います。これにより、リンクされたオブジェクトのリストが生成されます。しかし、Qtバイナリをデプロイするときに、プラグインが見つからないことがわかりました。私はリンクされたqtライブラリ（つまり2次リンク）からリンクされているので、私は迷っています... –

プラグインはリンクされておらず、実行時にロードされます。 lddや他のツールは、実行時に必要となるプラグインを知りません。オプションのものもあり、オンデマンドでロードするものもあります（SQLや画像形式のプラグインなど）。他のプラグインはプラットフォームプラグインではありません。あなたは必要なプラグインを意識して決定し、それに応じてそれらを配備する必要があります。または、それらのすべてをパッケージ化/展開します。また、プラグイン自体も依存関係がありますが、それらは通常リンクされており、プラグインの.soファイルに対してlddを実行することで識別できます。 –

一般的に、動的にロードされ、その機能は関数ポインタ経由で呼び出されているライブラリを確認する方法はありません。

特別な場合には、ハッキングとして、実行可能プログラムをリバースエンジニアリングするさまざまな方法を試すことができます。 Windows上のLoadLibraryとGetProcAddressへの呼び出しに関する静的解析コード。仮想マシンでコードを実行し、すべての呼び出しをLoadLibrary/dlopenに傍受する以外に、動作することは保証されていませんが、多くの実行可能ファイルで機能するヒューリスティックを導出できます。

出典

2016-06-13 14:03:01

彼はWindowsではなくLinuxです。 :-) –

@Kuba oberとJonがありがとうございました。 –

プラットフォームが何であるかは関係ありません： 'dlopen'がどのように呼び出されるのか理解しようとするのは、停止問題を解決することと同じです。あなたは推測することができ、コードを実行することなく非常に狭いケースを解決することができますが、それ以外のコードを実行して何ができるかを見ることはできません。 –

実行前に「ブラウザプラグイン」ライブラリの依存関係を検出する方法

答えて

関連する問題