問題タブ [portable-executable]

私は用語を少し混乱させています。

リンカーへの入力として与えられるファイルはObject Fileと呼ばれます。リンカーはイメージ ファイルを生成し、それはローダーによって入力として使用されます。

「MS PE&COFF仕様書」より頂きました。

Q1. Binary Image画像ファイルは、Binary Fileまたは単にとも呼ばれますBinary。右？

Q2. したがって、上記の用語によると、PE/ELF/COFF はイメージ ファイルの形式であり、オブジェクト ファイルではありません。右？しかしhttp://www.sco.com/developers/gabi/latest/ch4.intro.htmlは言う

この章では、ELF (Executable and Linking Format) と呼ばれるオブジェクト ファイル形式について説明します。オブジェクト ファイルには、主に 3 つのタイプがあります。

• 再配置可能ファイルには、他のオブジェクト ファイルとリンクして実行可能ファイルまたは共有オブジェクト ファイルを作成するのに適したコードとデータが含まれています。

• 実行可能ファイルには、実行に適したプログラムが含まれています。このファイルは、exec(BA_OS) がプログラムのプロセス イメージを作成する方法を指定します。

• 共有オブジェクト ファイルには、2 つのコンテキストでのリンクに適したコードとデータが含まれています。まず、リンク エディタ [ld(BA_OS) を参照] は、共有オブジェクト ファイルを他の再配置可能共有オブジェクト ファイルと一緒に処理して、別のオブジェクト ファイルを作成します。次に、ダイナミック リンカーは、プロセス イメージを実行可能ファイルやその他の共有オブジェクトと組み合わせて、プロセス イメージを作成します。

矛盾して、彼はオブジェクト ファイルとイメージ ファイルの両方が ELF 形式であると言っています。彼はオブジェクト ファイルとイメージ ファイルをまったく区別しておらず、一般的にオブジェクト ファイルと呼んでいます。それは間違っていませんか？

Q3. PEはCOFFから派生したものだと知っています。しかし、なぜ Microsoft の PE フォーマットの仕様は、Microsoft Portable Executable および Common Object File Format Specification と名付けられたのでしょうか。彼らはまだCOFFをサポートしていますか? もしそうなら、どのOSで？PE はずっと前に COFF に完全に取って代わったと思っていました。

リンカへの入力として与えられるファイルは、オブジェクトファイルと呼ばれます。リンカは画像ファイルを生成し、それがローダーによる入力として使用されます。

「MicrosoftPortableExecutableand Common ObjectFileFormatSpecification 」の宣伝文

RVA（相対仮想アドレス）。画像ファイルにおいて、メモリにロードされた後のアイテムのアドレス。画像ファイルのベースアドレスが差し引かれます。アイテムのRVAは、ほとんどの場合、ディスク上のファイル内の位置（ファイルポインター）とは異なります。

オブジェクトファイルでは、メモリ位置が割り当てられていないため、RVAはあまり意味がありません。この場合、RVAはセクション（この表の後半で説明）内のアドレスであり、後でリンク中に再配置が適用されます。簡単にするために、コンパイラは各セクションの最初のRVAをゼロに設定する必要があります。

VA（仮想アドレス）。イメージファイルのベースアドレスが減算されないことを除いて、RVAと同じです。Windowsは、物理メモリとは関係なく、プロセスごとに個別のVAスペースを作成するため、このアドレスは「VA」と呼ばれます。ほとんどすべての目的で、VAは単なるアドレスと見なす必要があります。ローダーがイメージを優先位置にロードしない可能性があるため、VAはRVAほど予測可能ではありません。

これを読んだ後でも、私はまだそれを理解していません。たくさん質問があります。誰でも実際的な方法でそれを説明できますか？Object File記載されているように＆の用語に固執してくださいImage File。

私が住所について知っているのはそれだけです

• オブジェクトファイルでも画像ファイルでも、正確なメモリ位置がわからないので、
• オブジェクトファイルの生成中のアセンブラは、セクション.data＆.text（関数名の場合）に関連するアドレスを計算します。
• 複数のオブジェクトファイルを入力として受け取るリンカーは、1つの画像ファイルを生成します。生成中に、最初に各オブジェクトファイルのすべてのセクションをマージし、マージ中に、各セクションに関連するアドレスオフセットを再計算します。そして、グローバルオフセットのようなものはありません。

私が知っていることに何か問題がある場合は、私を訂正してください。

編集：

フランソワ1世の答えを読んだ後、私は物理アドレス、VA、RVAとは何か、そしてそれらの間の関係は何かについて明確になりました。

すべての変数とメソッドのRVAは、再配置中にリンカーによって計算される必要があります。したがって、（メソッド/変数のRVAの値）==（ファイルの先頭からのオフセット）？真実でなければなりません。しかし、驚くべきことに、そうではありません。なぜそうなのか？

PEView を使用してこれを確認したc:\WINDOWS\system32\kernel32.dllところ、次のことがわかりました。

1. RVAとFileOffsetは、セクションの先頭まで同じです（.textこのdllの最初のセクションです）。
2. の先頭から.text最後のセクションまで（.data）RVAとFileOffsetが異なります。また、最初のセクションの最初のバイトのRVAは、「常に」次のように表示されます。.rsrc.reloc0x1000
3. 興味深いのは、各セクションのバイトがFileOffsetで連続していることです。つまり、別のセクションは、セクションの最後のバイトの次のバイトから始まります。しかし、RVAで同じことを見ると、これらはセクションの最後のバイトと次のセクションの最初のバイトのRVAの間の大きなギャップです。

私の推測：

1. すべて、最初の（.textここの）セクションの前にあったデータのバイトは、実際にはプロセスのVAスペースにロードされません。これらのデータのバイトは、これらのセクションを見つけて説明するために使用されます。それらは「メタセクションデータ」と呼ぶことができます。

   プロセスのVAスペースにロードされていないため。RVA == FileOffsetRVAという用語の使用も無意味です。これがこれらのバイトの理由です。

2. 以来、

   • RVA用語は、VAスペースに実際にロードされるバイトに対してのみ有効です。
   • .text、、、.dataのバイト.rsrcは.relocそのようなバイトです。
   • RVAから開始する代わりに、0x00000PEViewソフトウェアはから開始し0x1000ます。

3. なぜ3回目の観測なのか理解できません。私は説明できません。

私は両方の16\32\64ビットシステムで実行されるはずの小さなユーティリティを書いています。私の古いユーティリティは、16ビットバージョンを32ビットに圧縮し、/stubVisual Studio 2008（/ STUB -MS-DOSスタブファイル名）でスイッチを適用することにより、32ビットと16ビットの両方で実行されていました。

64ビットの実行可能ファイルで同じことを行う方法を探しています。ターゲットの64ビットシステムはWinPE64ビットであり、WOW64がインストールされていません。

出来ますか？

EXE ヘッダーに奇妙な値が配置されているのを見ました

そこで何をしているのかわかりませんがA8、ゼロに置き換えるとプログラムが実行されません。

一言で言えば、それは何ですか？

また、完全な MS DOS ヘッダーへのリンクも教えていただけますか?

Portable-Exe では、インポートされたセクションと、インポートされたすべての dll 名 (インポート記述子を使用) を見つける可能性があります。ここでは、1 つのアプリケーション Exe に多くのインポートされた dll (kernel32、advapi、user、comctl32....など) があります。 ）、今、そのアプリのexe（インポートされたdll）のすべての依存関係を見つけたい..再帰関数呼び出しを使用してロジックを教えてください..

ここで、ex notepad.exe は、2 つの dll (advapi32、user32) を持っていると仮定します。これらの dll の詳細を取得できます。advapi と user32 のインポートされた dll を知りたいです....すべての依存関係を介して...与えることができますか?ロジックのみ、私にとって非常に役に立ちます....ありがとう

やあ！

アプリケーションで使用される古いプラグイン (バイナリ、dll) があります。WM2003用にビルドされました。Windows Mobile 6.1にロードすると、アプリがクラッシュします( WM5は正常に動作し、WM6も同様です)。

ソース コードは入手できず、開発者によるサポートも終了しています。そのため、 WM6.1用に再構築できません。

WM6.1で動作するようにバイナリにパッチを当てるか変換することはできますか? もしそうなら、どうすればこれを行うことができますか?

ありがとうございました。

編集:問題は PE loaderにあり、 WM6.1では同じように動作しないことがわかりました (WM6 以前と比較して)。

PE 実行可能ファイルをメモリにロードし、それを dos,nt ヘッダー構造に適合させ、その .text/code セグメントの実際の (VA ではない) オフセット + サイズを調べたいとします。.text 開始オフセットを見つけるための win32 API がありますか、それともそのセグメントの開始オフセットを指す構造体からのポインターですか?

ありがとう。

.exeデフォルトのアイコンを C/C++ の別のアイコンに変更したいと考えています。誰もそれを行う方法を知っていますか?

ELFファイル形式では、別名にAlignmentフィールドがあります。Segment Header TableProgram Header Table

Windows PE ファイル形式の場合、次のレベルに進みます。セクションには 2 つのアラインメント値があり、1 つはディスク ファイル内にあり、もう 1 つはメモリ内にあります。PE ファイルのヘッダーは、これらの値の両方を指定します。

私はこの配置について何も理解していませんでした。何のために必要ですか？どのように、どこで使用されますか? 繰り返しますが、バイナリ ファイル形式のコンテキストでアライメントとは何かわかりませんが、なぜそれが必要なのですか?

少しグーグルで検索してhttp://en.wikipedia.org/wiki/Portable_Executableを読みましたが、アドレステーブルのインポートアドレスが書き込まれるタイミングが見つからないようです。コンパイル時に発生しますか？または、実行可能ファイルが実行されたとき？