3

数日前、商用アプリケーションの C++ 実行可能ファイルを誤って Notepad++ で開いたところ、元のソース コードに関する情報が非常に多く、実行可能ファイルに保存されていることがわかりました。

実行可能ファイル内には、ファイル名 (app.c、dlgstat.c、...)、関数名 (、、...)、GetTickCountおよびDispatchMessageAソース コードの小さな断片 (主に条件 ( szChar != TEXT('\0')、iRow < XTGetRows( hwndList ))) が含まれています。その後、別の QT 実行可能ファイルをチェックして、はい、ソース ファイル名とメソッド シグネチャを再度チェックしました。

そのため、C/C++ 実行可能ファイル (QT や MinGW を使用してコンパイルされたものなど) に実際にどのくらいのソース コード情報が格納されているのか疑問に思っています。これはおそらく、元のソースをまだ含んでいるある種のデバッグ ビルドですか? この情報は、いくつかのリフレクションに使用されますか? パブリッシャーがこのようなものを削除しない理由はありますか?

4

3 に答える 3

11

C/C++ 実行可能ファイルには、実際にどのくらいのソース コード情報が格納されていますか?

実際には、それほど多くはありません。実行時にソース コードは必要ありません。名前を付ける文字列は、次の 2 つのことに由来します。

  • 関数名 (例: GetTickCount) は、他のモジュールからインポートされた関数の名前です。関数は動的に (GetProcAddress関数名で呼び出すことによって) 解決されるため、名前は実行時に必要です。

  • 条件はアサーションである可能性があります。assertマクロは引数を文字列化するため、起動時にどの条件が満たされていないかがわかります。

DLL をビルドすると、DLL がエクスポートするすべての関数の名前も含まれるため、実行時に解決できます (他の共有オブジェクト形式についても同様です)。

デバッグ シンボルが使用する形式にもよりますが、デバッグ シンボルには元のソース コードの一部が含まれている場合もあります。これらのシンボルは、バイナリ自体または補助ファイル (Windows で使用される .pdb ファイルなど) に含まれている場合があります。

于 2012-09-26T22:10:27.167 に答える
2

Windows 関数名: 動的にアクセスされているという理由だけで、おそらくそこに存在します。プログラムのどこかにGetProcAddress、アドレスを取得するための があります。それでも、心配する必要はありません。すべてのアプリケーションは WinAPI を使用するため、その情報から実行可能ファイルについて発見できることはあまりありません。

条件: おそらく何かのassertようなマクロから。それらはassert、失敗したアサーションを引き起こした失敗した条件を出力できるようにするために含まれています。とにかく、リリースモードではアサーションは自動的に削除されるべきです。

ソース ファイル名とメソッド シグネチャ: おそらく__FILE__and__func__マクロの使用によるものです。おそらく、再び、からassert。

プログラムの内部構造に関するその他の情報源は RTTI です。RTTI は、typeid作業する可能性のあるすべての型に対してなんらかの表現を提供する必要があります。その機能が必要ない場合は、無効にすることができます (ただし、Qt プロジェクトでそれが可能かどうかはわかりません)。

于 2012-09-26T22:12:39.263 に答える
0

C++ アプリのバイナリに混在すると、ほとんどのグローバル シンボル (およびコンパイラで有効になっている場合はデバッグ シンボル) の名前が見つかりますが、シンボルが関数またはメソッドである場合は、シンボルの呼び出しシグネチャをエンコードする追加の「装飾テキスト」が含まれます。 . 同様に、文字列のリテラルは平文に埋め込まれます。しかし、バイナリ実行可能ファイルを作成するためにコンパイラが使用した実際のソース コードのようなものはどこにもありません。その情報はコンパイル プロセス中に失われ、ビルドに C++ テンプレートが使用されている場合、リバース エンジニアリングは特に困難です。

于 2012-09-26T22:13:55.507 に答える