問題タブ [coff]

「PEヘッダーの要件」という同様の質問をすでにしましたが、その答えには本当に満足していません。

JavaSE1.6でアセンブラ/リンカを構築しています。PE / COFFヘッダーとファイル形式に関する5つの異なるドキュメント/仕様を読みましたが、問題が発生します。

生成されたファイルは無効です、とWindowsは言います：「Xは有効なWin32アプリケーションではありません。」私は何が間違っているのかわかりません。PEヘッダーとPEオプションヘッダーのすべてのエントリを再確認しましたが、すべて正しいようです。
私は3つのセクションを持っています：

• code（RVA 0x1000、ファイル0x400）
• data（RVA 0x2000、ファイル0x600）
• import（RVA 0x3000、ファイル0x800）

エントリポイントの値は0x1000（の先頭code）にあり、イメージベースは0x400000です。セクションの配置は0x1000で、ファイルの配置は0x200です。

ファイル全体を表示するには、この質問のリビジョンを参照してください。

つまり、有効なPEファイル（単純な「HelloWorld」メッセージボックスアプリケーション）を取得し、16進エディター（HxD）を使用して変更を開始しました。「Xは有効なWin32アプリケーションではありません」ではなく、さまざまなエラーメッセージが表示されました。

codeコンテンツが「有効な」コードではないことは承知していますが、テストしました。無効なコードを使用すると、アプリケーションのクラッシュエラーが発生します。

「HelloWorld」PEファイルのインポートセクションの内容が無効な場合、「[...]にプロシージャポイントが見つかりません」または「[..]dllが原因でアプリケーションを開始できませんでした」というエラーが表示されます。見つかりません。」、またはアプリケーションのクラッシュ。これらのエラーはすべて非常に便利です。それらはすべて私に何が悪かったのかについての手がかりを与えてくれます。

しかし、「Xは有効なWin32アプリケーションではありません。」というエラーが表示された私のPEファイルは、私を狂わせます。私のPEファイルの何が問題になっていますか？

ダンプビン出力：

IPが最初に指しているexeファイルポイントを取得するにはどうすればよいですか?? 常に .text セグメントの先頭を指していますか?

Microsoft Visual Studio 2003 ツールによって出力されたオブジェクト ファイルから奇妙な動作と思われるものを見ています。fileユーティリティは私に教えてくれます：

アセンブラーによって作成されたオブジェクトの場合、ただし C ファイルからのオブジェクトの場合は、次のようになります。

Microsoft のdumpbinユーティリティとobjdumpcygwin から取得した を使用して、アセンブリでビルドされたファイルを逆アセンブルできますが、C でビルドされたファイルについては、どちらのユーティリティからも有用な結果が得られません。

この違いに関連していくつか質問があります。

1. MSVC2003 コンパイラによって生成されるオブジェクト ファイルの形式は何ですか?
2. そのオブジェクト ファイルを逆アセンブルするにはどうすればよいですか?

AT&T 構文で逆アセンブリを取得することに特に関心があります。GCC で動作するように大規模なソース ベースの移植を行っています。事業。

編集：さらに情報を追加します。

これらのファイルのいずれかで実行するdumpbinと、結果が得られません。

を使用objdumpすると、次のようになります。

アセンブリからビルドされたファイルでは、妥当な結果が得られます。

再編集: コマンド ライン情報を追加します。

アセンブリ ファイルは、次のようなコマンド ラインでビルドされます。

ml単独で実行すると、次のように表示されます。

C ファイルは、次のコマンドでビルドされます。

と に渡される-Iとオプションがいくつかありますが、ここでは簡潔にするためにそれらを省略しました。オプションについては、こちらで説明しています。 -Dmlclcl

Microsoft PE / COFF SPEC（v8、セクション5.4.4）は、シンボルに次の場合があると述べています。

1. IMAGE_SYM_CLASS_EXTERNALのストレージクラス
2. そしてセクション番号0（IMAGE_SYM_UNDEFINED）

「サイズを示す」のは（シンボルテーブル内の）「値」フィールドです。

これは私を混乱させます。特に、「何の大きさを示しているのか」と思っています。

通常、IMAGE_SYM_CLASS_EXTERNALおよびIMAGE_SYM_UNDEFINEDはCL（visual C ++）によってexternを表すために使用されます。

リンカがシンボルのサイズを知る必要がある、または気にする必要があるのはなぜですか？名前を知っているだけでなく、それが外部であり、適切な再配置エントリが設定されている必要がありますか？これはどれもサイズに依存するべきではありません。確かに、コンパイラはこれを知る必要がありますが、オブジェクトファイルからではなく、ヘッダーファイルからその情報を取得します。

CLによってコンパイルされたexternの簡単な例を見てきましたが、Valueフィールドは常にゼロのようです。したがって、フィールドのサイズをエンコードするために使用されていないことは明らかです。

スペックが何の「サイズ」を指しているのか誰か知っていますか？Visual Studioリンカーがそのフィールドを使用する可能性があるシナリオはありますか、それとも仕様の宣伝文句は意味がありませんか？私の限られた脳はそのようなシナリオを考えることができません。

アップデート：

少なくとも常にではないが、シンボルのサイズであるとは限らないことに注意してください。私が観察した場合、値は常に0であるため、質問があります。

MPLAB IDE でコードを開発していますが、コンパイラによって生成された .COFF ファイルまたは .HEX ファイルを使用してチップをプログラムする方がよいかどうか疑問に思っていました。両者の違いはわかりませんが、どちらも同じ仕事をすると思います。

Microsoft Visual Studio で生成されたマップ ファイルがあります。__NULL_IMPORT_DESCRIPTOR という名前の比較的大きな領域が含まれています。これは何の役に立つのですか？リンクされたdllと関係がありますが、その正確な目的はわかりません。

OMF 16ビットオブジェクトファイル形式からCOFF32ビットオブジェクトファイル形式に変換する方法はありますか？

これは簡単な質問です。私は VA = RVA + PE のイメージベースであることを知っています。逆アセンブラで文字列を見つけようとしているところ、たまたま .text セクションの 0042720E に配置されています。

imagebase は 400000 で 2720E は RVA で、今のところ問題ありません。

しかし、デバッガーで exe をロードすると、命令がマップされているメモリが 0140720E になるのはなぜですか?

0140720E (RAM に表示されるもの) と 0042720E (VA) が FE0000 によって異なるのはなぜですか? 何か不足していますか？

互換性のある PE ファイル セクションをマージすることの欠点は何ですか?

私が理解している限りでは、Microsoft のポータブル実行可能形式の COFF シンボル テーブルは、エクスポート、インポート、およびデバッグ シンボルを格納するために使用されます。しかし、目的のために .edata、.idata、および .debug セクションが既にあるのに、なぜそのような別の構造が必要なのでしょうか?