10

--strip-debugまたは--strip-unneededを実行すると、.koすべての関数名がでリストされます。実行すると、ロードを拒否するカーネルモジュールがあります。nmstrip foo.ko

モジュールのロードに必要のないすべてのシンボルを削除して、APIを簡単にリバースエンジニアリングできないようにする簡単なショートカットを知っている人はいますか？

PS：あなたがたすべてのオープンソースの大物宣教師のために。これは一般の人々が決して使用しないものなので、質問をGPLの炎上戦争に変える必要はありません。

4

7 に答える 7

8

私の以前の質問に対する回答はありませんが、いくつかの手がかりになる可能性のあるいくつかの推測と、回答へのステップを次に示します。

私の記憶では、.ko は、ソース モジュールによって生成されたすべての .o ファイルをマージし、.modinfo セクションを追加した結果の .o ファイルに他なりません。Makefile をビルドする .ko の最後には、LD 呼び出しがあります。私の記憶では、ld は -r オプションで呼び出されます。これにより、Makefile が .ko を呼び出す .o ファイルが作成されます。この結果のファイルは、アーカイブまたはオブジェクト ライブラリ (.a ファイル) と混同しないでください。これは、複数の .o ファイルを 1 つとしてアーカイブ/パッケージ化する形式です。マージされたオブジェクトは、さらに別の .o を生成するリンクの結果です。 module: しかし、結果のモジュールでは、マージできるすべてのセクションがあり、解決できるすべてのパブリック/外部ペアがそれらのセクション内にあります。したがって、すべての「ローカル」extern 定義を含む .ko ファイルになると仮定します。

  • .ko 内の .o モジュールを介して呼び出すために使用されるため、extern になっているもの (ただし、.ko の外部から呼び出されることは想定されていないため、もう必要ありません)。

  • .ko モジュールがローダーおよびカーネルと適切に通信する必要があるもの。

前者はマージ中に ld によって既に解決されている可能性が高いですが、.ko の外部からも呼び出し可能にするつもりかどうかを ld が知る方法はありません。

したがって、表示される不要なシンボルは、各 .o ファイルの extern であるシンボルですが、結果の .ko の extern としては必要ありません。そして、あなたが探しているのは、それらだけを取り除く方法です。

この最後の段落は、削除したいシンボルを適切に説明していますか?

于 2010-06-04T09:35:07.207 に答える
7

これはまさに私たちがここで話していることだと思います。

OK、1 つの解決策は無関係なシンボルを「手動で」削除することです。「strip」ユーティリティでは、シンボルを個別に削除 (または保持) できるように見えるため、--strip-allと--keep-symbol=の小さな束を使用する必要があります。--wildcardも少し役立つかもしれないことに注意してください。もちろん、逆に、最も便利なものに応じて、すべてを個別に削除することもできます。

クロスモジュール リンク用にモジュールで明示的に定義した、表示したくないすべてのシンボルを削除することから始めるとよいでしょう。init や exit などの明らかな有用なものだけを残します。また、カーネル開発ソフトウェア インフラストラクチャによって生成されたものや、カーネル開発ソフトウェア インフラストラクチャに属するものには触れないでください。次に、適切なレシピが見つかるまで試行錯誤します...実際、EXPORT_SYMBOLとして明示的に定義したもの（もちろん、init / exit）を除いて、独自のシンボルはすべて削除できると思います。

幸運を！:)

PS:

実際、必要なストリッピングを自動的に実行するために、すべての .ko プロジェクトに必要なソース情報が存在するようです。何かが欠けていない限り、EXPORT_SYMBOL ではないもの、またはビルド ソフトウェアによって明示的に挿入されたものは、理論的にはデフォルトでストリッピングされる可能性があるようです。 .ko ビルドを終了する「ld -r」時間の最後。ツールチェーン（コンパイラ/リンカ）には、再配置可能なリンク/マージのために「ストリップまたはキープ」シンボリックを個別に指定するためのプロビジョニング/ディレクティブ/オプションがあるとは思わないだけです。それ以外の場合は、EXPORT_SYMBOL マクロと他のいくつかの場所を変更すると、おそらく目的の結果が得られ、Linux システムのほとんどの .ko ファイルから数バイトが削減される可能性があります。

于 2010-06-05T17:33:41.697 に答える
7

カーネル構成でデバッグ シンボルが有効になっていることに気付かずにカーネルをビルドしたので、結果のモジュールのサイズが非常に大きくなりました。これは私のために働いた：

# du -sh /lib/modules/3.1.0/
1.9G    /lib/modules/3.1.0/
# find /lib/modules/3.1.0/ -iname "*.ko" -exec strip --strip-debug {} \;
# du -sh /lib/modules/3.1.0/
134M    /lib/modules/3.1.0/

/lib/modules/3.1.0named内のすべてのファイルを検索し、それぞれに対して*.ko実行strip --strip-debugします。

于 2011-10-26T14:16:12.663 に答える
3

問題が実際に何であるかを理解しているかどうかはわかりません: .ko を開発するとき、次のようなものを明示的に追加しないと

ccflags-y += -ggdb -O0 -Wall

私のMakefileに、私はシンボルを取得しませんが、私が公開したものまたは外部参照を自分で取得します。いくつかの正当な理由により、他のシンボルを取得していないと確信しています。

  • 結果の .ko ファイルはかなり小さくなります。
  • ファイルをダンプして ELF を分析すると、テーブルが存在しないことが示されます。
  • kgdb のシンボルを表示したりアクセスしたりできません。

だから私はあなたの質問に少し困惑しています..あなたの .ko に表示されている (そして表示したくない) 記号は何ですか? ソースファイルでどのように宣言されていますか? 最終的にどの ELF セクションに入るのですか? そして (申し訳ありませんが、ばかげた質問です): 自分のモジュールの外で見る必要のないすべてのものを静的に定義しましたか?

于 2010-05-27T09:20:28.063 に答える
1

filofelの投稿に加えて：

ユーザースペース共有ライブラリを削除すると機能が維持される理由は、エクスポートされたシンボルが.dynsym削除されないセクションにあるためです。.koただし、ファイルはdynsymを使用しません。

于 2010-11-21T14:11:57.737 に答える
1

人々は成功を報告しています

strip --strip-unneeded
于 2011-07-14T20:24:45.307 に答える
0

strip -g XXX.

あなたが起こったことのような私の以前の問題は、組み込みデバイスのこのコマンドによって解決されますLinux Kernel 3.0.8。

于 2016-04-10T08:45:23.570 に答える