1

プログラムのgdb逆アセンブルを見ていました

...
0x8048085: cmp    eax,ecx
0x8048087: je     0x804809f
0x8048089: mov    DWORD PTR [esp+0x4],0x21
0x8048091: mov    DWORD PTR [esp],0x8048160
0x8048098: jmp    0x8048157
0x804809d: mov    esi,0x115e8ba
0x80480a2: add    BYTE PTR [eax],al
...

2 番目の命令では、後の 2 つの命令の間にあるアドレス 0x...9f へのジャンプがあります。実行するアドレスをプロセッサに提供する限り、プロセッサは気にする必要がないため、理論的にはすべてが可能であることを理解していますが、それでも...誰かが説明できたら、ありがとう

更新 : アドレスに問題があるようです。しかし、これはより大きなコード (200 行) の一部です。「call 0x...」と書かれている場所を見て、それらをラベルに置き換えたところ、コードは次のようになりました。

func1:
   ...
   asm
   ...
   call func2
   ...
   ret
func2:
   ...
   asm
   ...
   ret
...

したがって、ある時点で逆アセンブリがアドレスで失敗したという事実を購入したいと思いますが、それはどこでもcall 0x ...、0x ...の前の命令であるという事実とは相関しません。 「レット」。アドレスのどこかにオフセットがある場合、これは当てはまりません

4

3 に答える 3

3

私の最初の推測では、 にパディング データが挿入されてい0x804809dます。そのセクションの逆アセンブルは で開始する必要があることを意味し0x804809fます。

リストされたアドレスに基づいて、プロセスの早い段階で逆アセンブリでオフセットが間違っていた可能性もあります。

于 2013-10-27T15:02:36.277 に答える
1

はい、それは可能ですが、ここでアラインメントの問題に言及する価値があります:なぜ x86 でコードを偶数アドレス境界にアラインする必要があるのですか?

なぜそれができたのか、いくつかの可能性があると思います:

  • 自己変更コード (開始後に実際の意味のある命令がそのアドレスに書き込まれる場合)
  • 1 つの命令のデータをオペコードとして解釈する (このようなもの)
  • 単純に間違ったジャンプ アドレス (コンパイラ エラーである可能性もありますが、必須ではありません)
于 2013-10-27T14:13:23.620 に答える
0

可変語長命令セットの逆アセンブルはトリッキーです。実際のコードを見ていないか、逆アセンブラーに問題があると思います。

于 2013-10-27T15:13:04.473 に答える