Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x64: error in parsing some MOVHPS opcodes #96

Open
LRGH opened this issue Mar 2, 2024 · 1 comment
Open

x64: error in parsing some MOVHPS opcodes #96

LRGH opened this issue Mar 2, 2024 · 1 comment

Comments

@LRGH
Copy link
Contributor

LRGH commented Mar 2, 2024

from amoco.arch.x64 import cpu_x64 as cpu
i = cpu.disassemble(b'\x41\x0f\x16\x45\x68\x00\x00')
assert i.length==5
assert i.mnemonic=='MOVHPS'
assert str(i) == 'movhps      xmm0, qword ptr [r13+0x68]'

Fails because i.length is 6.

The hack at LRGH@5609706 solves the issue, but there should be a better fix.

@bdcht
Copy link
Owner

bdcht commented Mar 4, 2024

This is a good one! Actually, the MOVHPS has the exact same decoder spec as the MOVLHPS...except that when the ModRM is decoded the later requires a register ref whereas MOVHPS operates on memory.

With the current way these instructions are defined, amoco first tries to decode MOVLHPS which raises an InstructionError because the operand is not a reg, and then triggers MOVHPS decoder. However, since there is a REX prefix, the disassembler is stateful in the sense that the 'obj' passed to any triggered @iSpec is the "current" partially decoded instruction (containing prefixes/REX). In such case, when an InstructionError is raised the current state must be correctly reverted. This was not the case for exception raised after a getModRM (only SSE was affected).

Fixed by 5bdc6ba.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants