none
C++で作成したdllに対するDUMPBINコマンド実行結果の一部が文字化け RRS feed

  • 質問

  • お世話になっております。

    C++で作成したdllファイルに対し、DUMPBINコマンドを実行して出力された逆アセンブルの結果を確認しています。

    複数の異なるdllファイルに対し同一のコマンドを実行しているのですが、dllファイルによっては、下記のように逆アセンブル結果が一部文字化けしてしまいます。

    どなたか、この文字化けの原因を御存知でしたら、ご教授ください。

    【実行コマンド】

    DUMPBIN /DISASM test.dll > C:\test.asm

    【文字化けの内容】

      1000100B: CC CC CC CC CC                                   フフフフフ
    ??0CBase64EncodeBuf@@QAE@QAEK@Z:

    【文字化けしなかった場合】

      1000100B: CC                 int         3
      1000100C: CC                 int         3
      1000100D: CC                 int         3
      1000100E: CC                 int         3
      1000100F: CC                 int         3

    2017年2月6日 2:45

回答

  • Visual Studio 2015のこちらの環境で確認できたのは、プロジェクトのプロパティで「構成プロパティ」→「リンカー」→「デバッグ」→「デバッグ情報の生成」が「いいえ」ではない場合、出力モジュールを DUMPBIN /DISASM した結果で「フフ」という文字が現れるようでした。

    ただ、「デバッグ情報の生成」が「いいえ」であっても「構成プロパティ」→「C/C++」→「コード生成」→「基本ランタイム チェック」の設定しだいで、実際の動作で、未初期化状態の変数領域がCCCCCCCCなどで初期化されるようです。

    また、「構成プロパティ」→「リンカー」→「全般」→「インクリメンタルリンクを有効にする」が「はい」の場合、出力モジュールに「データが埋め込まれる」ため、インクリメンタルリンクを有効にしなかった場合に比べてCCCCCCCCが出現する頻度が高くなりました。

    参考サイト:

    https://msdn.microsoft.com/en-us/library/aa260966.aspx

    https://msdn.microsoft.com/ja-jp/library/4khtbfyf.aspx?f=255&MSPPError=-2147217396

    2017年2月6日 4:42
  • なぜ、このように出力方が異なるのかご存知でしたら、教えて頂けますでしょうか。

    Intelプロセッサーの場合、命令が可変長のため、1バイトずれると全く異なる命令と解釈され、更にその命令長はまた異なる長さとなるため、ひとたびずれると簡単には復元できません。

    そのため、指定したアドレスがコードなのかデータなのかの判定は簡単に変化してしまいます。質問の場合、データと判断されると前者の出力、コードと判断されると後者の出力になります。

    2017年2月6日 7:05

すべての返信

  • 0xCCはINT3と呼ばれる1バイト命令でデバッガー呼び出しを行います。つまり当該アドレスを実行しようとした場合は何等か問題がありプログラムを停止しデバッガーを呼び出すべきという意味で CC CC CC CC が埋め込まれています。また0xCCはShift-JISエンコーディングで半角の「フ」にあたります。

    ですので文字化けしているわけでもありませんし、当該アドレスを実行する意味もないので、逆アセンブル結果がどちらであっても本質的には問題ないはずです。

    その上で、質問者さんとしてはどうしたいのでしょうか?

    2017年2月6日 3:03
  • 間違っていましたらすみません。

    Visual Studio の Debug 構成で出力したモジュールではデバッグしやすいように、未初期化状態の変数領域は特定の値(CCCC)で埋め尽くされることがあるようです。

    文字列配列など、複数列続くものについて、

    1000100B: CC CC CC CC CC                                   フフフフフ

    というように、Shift-JIS(コードページ932)で表示すると文字化けのように見えてしまうのだと思います。


    2017年2月6日 3:04
  • 0xCCはINT3と呼ばれる1バイト命令でデバッガー呼び出しを行います。つまり当該アドレスを実行しようとした場合は何等か問題がありプログラムを停止しデバッガーを呼び出すべきという意味で CC CC CC CC が埋め込まれています。また0xCCはShift-JISエンコーディングで半角の「フ」にあたります。

    ですので文字化けしているわけでもありませんし、当該アドレスを実行する意味もないので、逆アセンブル結果がどちらであっても本質的には問題ないはずです。

    その上で、質問者さんとしてはどうしたいのでしょうか?

    佐祐理さん

    ご回答ありがとうございます。

    dllの逆アセンブリを行った理由は、下記①②のdllファイルが、同一のソースコードから生成されたものかどうかを確認するためです。

    ① 自分でビルドしたdllファイル

    ② ①と同一名称の、おそらく①と同一のソースコードから生成されていると思われるdllファイル

    ①②それぞれのdllファイルに対しDUMPBINコマンドを実行した結果、①の逆アセンブル結果の一部が本文中の「【文字化けの内容」」欄の通りに表示され、②の逆アセンブリ結果の一部は「【文字化けしなかった場合】」欄の通りに表示されました。

    ご回答頂いた内容によると、どちらの出力方でも同じ意味だと読み取れるのですが(間違っていたら申し訳ありません)、なぜ、このように出力方が異なるのかご存知でしたら、教えて頂けますでしょうか。

    2017年2月6日 3:44
  • 間違っていましたらすみません。

    Visual Studio の Debug 構成で出力したモジュールではデバッグしやすいように、未初期化状態の変数領域は特定の値(CCCC)で埋め尽くされることがあるようです。

    文字列配列など、複数列続くものについて、

    1000100B: CC CC CC CC CC                                   フフフフフ

    というように、Shift-JIS(コードページ932)で表示すると文字化けのように見えてしまうのだと思います。


    kenjinoteさん

    ご回答ありがとうございます。

    今回、対象のdllはリリース構成でビルドしたのですが、その場合でも未初期化状態の変数領域がCCCCで埋められることがあるのでしょうか?

    御存じでしたら、教えて下さい。

    2017年2月6日 4:18
  • Visual Studio 2015のこちらの環境で確認できたのは、プロジェクトのプロパティで「構成プロパティ」→「リンカー」→「デバッグ」→「デバッグ情報の生成」が「いいえ」ではない場合、出力モジュールを DUMPBIN /DISASM した結果で「フフ」という文字が現れるようでした。

    ただ、「デバッグ情報の生成」が「いいえ」であっても「構成プロパティ」→「C/C++」→「コード生成」→「基本ランタイム チェック」の設定しだいで、実際の動作で、未初期化状態の変数領域がCCCCCCCCなどで初期化されるようです。

    また、「構成プロパティ」→「リンカー」→「全般」→「インクリメンタルリンクを有効にする」が「はい」の場合、出力モジュールに「データが埋め込まれる」ため、インクリメンタルリンクを有効にしなかった場合に比べてCCCCCCCCが出現する頻度が高くなりました。

    参考サイト:

    https://msdn.microsoft.com/en-us/library/aa260966.aspx

    https://msdn.microsoft.com/ja-jp/library/4khtbfyf.aspx?f=255&MSPPError=-2147217396

    2017年2月6日 4:42
  • 回答ではありません。参考までに。

    リリースビルドであっても、
    「/RTC(ランタイム エラー チェック)」ないし
    「/GZ(スタック フレームのランタイム エラー チェックの有効化)」が
    「/Od」と共に用いられた場合は、
    未初期化のデータ領域がメモリーデバッグ用のわかりやすいコードで埋められるようですね。

    2017年2月6日 6:31
  • なぜ、このように出力方が異なるのかご存知でしたら、教えて頂けますでしょうか。

    Intelプロセッサーの場合、命令が可変長のため、1バイトずれると全く異なる命令と解釈され、更にその命令長はまた異なる長さとなるため、ひとたびずれると簡単には復元できません。

    そのため、指定したアドレスがコードなのかデータなのかの判定は簡単に変化してしまいます。質問の場合、データと判断されると前者の出力、コードと判断されると後者の出力になります。

    2017年2月6日 7:05
  • ちょっとURLを示せないのだけど、 2つのファイルが同じソースからコンパイルしたものかどうかは dumpbin /rawdata の適当なオプションでテキストにして比較すると見かけ、私はそうしていました。

    Jitta@わんくま同盟

    2017年2月6日 23:44
  • 皆様、情報提供頂き、ありがとうございました。

    DUMPBIN コマンドの出力結果については、ビルド時の構成プロパティの内容によって変化するようですね。

    dllの逆アセンブリ結果比較は完了しておりませんが、当初質問した内容についてはご回答頂きましたので、本質問はクローズとさせていただきます。

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

    2017年2月8日 2:36