Mnemonic of kernel instructions as NOP DWORD about distormx

[gdabah]

Hi @colbacc8
Thanks for the detail submission, however if I don't have the actual disassembled bytes I can't help you.
If you can please share them with me, then I will be able to cross check with the documentation and distorm's results and learn if it's legit result or not.

Thanks

[gdabah]

@colbacc8 bumping. Requiring more info please.

[colbacc8]

Hi gdabah, sorry for the late reply...
I noticed several NOP DWORD in the execution trace translated by distorm3, sometimes are correct sometimes seem not...

1. working correctly case:
   Disassebling with objdump the executed binary, this is an instruction correctly translated in NOP DWORD

output of trace information + distorm3 (fields are: 1)physical address, 2) virtual address, 3) instruction size, 4) opcode, 5) coreid 6)mnemonics + operand (output of distorm3)

2. The translation seems different in case of a kernel instruction.
   This is the instructions disassembled from the used linux kernel image, which is a callq to the "rcu_irq_enter" syscall
   

the mnemonic and operand output in the distorm3 is the following:

as you can see, the callq is translated with NOP DWORD.
What I noticed is that also the opcode differs...

I followed the trace and the objdump output of the linux kernel instruction by instruction and at the point of the NOP DWORD should be exactly the callq to the syscall...

[gdabah]

Hi I am closing this ticket as there’s no bug. The opcodes are totally different and so the mnemonics and instructions are different and that’s alright. Notice also the virtual address is different. Perhaps I should warn that distorm runs linearly on code unlike objdump. So I am not sure why you decided it’s the same address/code. Anyway there’s no bug in distorm but perhaps the way you use it. Also be sure you decode in 64 bits. Thanks and good luck

…

On Fri, Jan 8, 2021 at 13:48 colbacc8 ***@***.***> wrote: Hi gdabah, sorry for the late reply... I noticed several NOP DWORD in the execution trace translated by distorm3, sometimes are correct sometimes seems not... 1. working correctly case: Disassebling with objdump the executed binary, this is an instruction correctly translated in NOP DWORD output of trace information + distorm3 (fields are: 1)physical address, 2) virtual address, 3) instruction size, 4) opcode, 5) coreid 6)mnemonics + operand (output of distorm3) The translation seems different in case of a kernel instruction. This is the instructions disassembled from the used linux kernel image, which is a callq to the "rcu_irq_enter" syscall [image: image] <https://user-images.githubusercontent.com/8047760/104011823-09c58b80-51af-11eb-9a4b-08128d6c4e6d.png> the mnemonic and operand output in the distorm3 is the following: [image: image] <https://user-images.githubusercontent.com/8047760/104011980-4c876380-51af-11eb-9e08-d118d731f56e.png> as you can see, the callq is translated with NOP DWORD. What I noticed is that also the opcode differs... I followed the trace and the objdump output of the linux kernel instruction by instruction and at the point of the NOP DWORD should be exactly the callq to the syscall... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADMEWTYFCARIVAUVFUBRYDSY3WIXANCNFSM4VFP5GZA> .

[colbacc8]

sorry, it was a mistake in linking the screenshot...I updated my previous answer...
the virtual addresses are now equal (second field of the output trace)

yes, I'm decoding in 64 bits mode.

I'm controlling also if the problem depends on the relocation...

[gdabah]

It doesn’t matter if the virtual addresses happen to be correct if the actual bytes disassembled are not! Means it’s a different instruction.

make sure you start disassembling from a fixed known address like the start of the function and even then if there’s data in between distorm doesn’t know it - it reads everything linearly nevertheless so you can get different stuff. Comparison must be done correctly using same bytes only. In case of different addresses something is wrong with your file-memory offsets or usage as explained.
Thanks and good luck