Cutter: edit > instruction gives wrong bytes on x64 (also differs from rasm2)

[vincent-gmd]

Environment information

• Operating System: ubuntu 19.10
• Cutter version: 1.10.0
• File format: elf64
  
  
  
  • Arch: x86
  
  
  • Type: EXEC (Executable file)
  
  

Describe the bug
when editing several instructions (ex:pop) using new registers (r8 to r15) give incorrect bytes

To Reproduce

1. open an elf64 file in write mode
2. go to disassembly tab
3. right click an address/instruction
4. click edit > instruction
5. type pop r14
6. window gives "5f" actual instruction is "415e"
7. if ok is pressed the incorrect bytes are persisted
8. on console type rasm2 -a x86 -b 64 "pop r14" for correct bytes

Expected behavior
bytes on edit window mach bytes given by rasm2

Screenshots

Additional context
perhaps 32 interpretation is taking precedence over 64 ?
as a workaround you can use rasm2 on console and use edit bytes
affected instructions(will add as i see) :
sub
pop
test

[vincent-gmd]

found out that you can solve this by setting a diferent assembler like this:
e asm.assembler =x86.as

[ITAYC0HEN]

Thank you for reporting! That's still an issue though. We can't expect the user to change the assembler :)
I'll re-open this

[vincent-gmd]

yeah also i found instructons that dont work regadles of asembler such as
movsx rcx, byte [rbx + rdx]
on deafult asembler: 0fbe0b
nasm as and nz report as invalid

rasm2 gives correct byes
rasm2 -a x86 -b64 "movsx rcx, byte [rbx + rdx]"
480fbe0c13

[ITAYC0HEN]

Thank you for these examples!
Do you have experience with radare2? If so, can you try to reproduce each of the behaviors you experience using radare2? When you do, we can transfer this issue to the r2 repository to pass it to the radare2 devs to check.

[ITAYC0HEN]

Hi @vincent-gmd, just in case you missed the previous comment. It would be very helpful if you'll be able to reproduce it using radare2. You can even try with the integrated console from Cutter.
Thank you!

[vincent-dafre]

I'm not sure i understand what you mean by reproducing on radare !
using the integrated console from Cutter and using radare2's asm (aka rasm2) gives correct byes as i described
rasm2 -a x86 -b64 "movsx rcx, byte [rbx + rdx]"
480fbe0c13
so as far as I can tell this is a cutter only issue
if you want my take on it what is probably happening is an code completion issue where my input is first passed to an code completion function that does not recognize the new registers and replaces it with what it assumes to be the correct instruction.
see on the picture how it stops complaining even tough the instruction is not complete

if i put :
rasm2 -a x86 -b64 "movsx rcx, byte [r"
on the console i still get an error :
Cannot assemble 'movsx rcx, byte [r' at line 3
but on the edit window i suddenly receive bytes :0fbeff
if i continue typing to the the end it gives :0fbe0b
which equates to :movsx ecx, byte [rbx]
so i believe something is tampering with the string before it gets to rasm2 in cutter

[vincent-dafre]

i think a quick fix without losing functionality would be to first to send input to rasm2 and only if it complains send to the auto complete module and then back to rasm2
this wouldn't fix the problem that autocomplete is out of date/out of sync with rasm2 but at least would keep it from propagating to valid inputs

[vincent-dafre]

I have no idea what the autocomplete modules or commands from radare2 would be or even if they exist or are cutter only if some one would clue me in i could try to reproduce on radare2