2017-12-30 44 views
3

に私は逆アセンブラ(SmartDec:http://decompilation.info/)を使用していますし、生成された解体中の命令の多くは次のようになり:不明意味(:)アセンブリ命令

mov rax, [rip + 0x32b5]:64 

私は不慣れですこの命令の一部に:64が含まれています。どういう意味ですか?

その他の例:

cmp [rcx + r8 * 0x8]:64, 0x0 
mov eax, [rip + 0x592a]:32 
jmp [rip + 0x6bad]:64 

この逆アセンブラは、対応するマシンコードが表示されないので、私はバイナリエディタを使用して、この命令がでたと述べたアドレス見上げ:

1665: mov rax, [rip + 0x19a4]:64 

これは、リトルエンディアンで、そこに16バイトの価値があったものです。

54 00 00 49 89 E8 FF 15 DC 5F 00 00 E9 57 FF FF 
+0

SmartDecはディスアセンブラです、http://decompilation.info/ – SeanRamey

+0

私はあなたがその命令のための正しい16進バイトを持っているとは思わないです。マシンコードに 'a4'または' 19'バイトがどこにもありません。おそらくあなたの逆アセンブラはRIP +を意味するものではなく、実際に絶対アドレスがRIPに関連して '0x19a4 'であることを意味します。しかし、とにかく、 '54'は' mov'のオペコードではありません。 REX.W = 1 'mov r/m64、r64'(ストア)](https://github.com/HJLebbink/asm-dude/wiki/MOV)ですが、これらのバイト別の命令の一部である(開始ではない)。私は将来の比較のために別の逆アセンブラ( 'objdump -drwC -Mintel'のような)を使うことをお勧めします。 –

答えて

8

それはSIです何らかの理由で印刷されたメモリオペランドのze。私はexample on the SmartDec home pageから推測しました。これはmovzx edx, [ecx]:16となります。これは他のアセンブラではmovzx edx, word [ecx](またはword ptr)の場合と同じです。こののように、他のオペランドからサイズを推測できない場合にのみ有効です。 SmartDecは毎回それを表示しているようです。質問のあなたの例のために、mov rax, [rip + 0x32b5]:64はサイズが64ビットであることは明らかですので、あまり役に立ちません。

+0

ありがとう!なぜ彼らはよく受け入れられた方法の代わりにそのようにすることを決めたのだろうか? – SeanRamey

+1

@SeanRameyは私には最短の方法( ':16'対'単語 ')を見せてくれて、私にとってはまだ読みやすく、コロンもビットカウントやビット操作と一緒に使うことが多いので、私には全く衝撃的ではありません。私が関心を持つ限り、私はこの新しい(私のための)記法に気付かない(私が見たような他のスタントに反し、asmGoと思う、そういうもののように)。 ...とにかく "なぜ" => "なぜではない?" x86アセンブリの標準が決して強すぎることはありませんでしたが、インテルはこれを文書でいくらか整合性を保ちますが、そのままソースを書くのには使えず、アセンブラは常に欠けている部分を定義し続けました。 – Ped7g