Mnemonic of kernel instructions as NOP DWORD

[colbacc8]

Hi! I'm using the distorm3 tool in a simulator named COTSon and I noticed a possible bug of the distorm...or mybe I'm wrong in interpreting the output of the distorm.

In my execution environment, the instructions are executed inside a virtual machine Linux based named SimNow. The executed instructions are, then, passed to the COTSon simulator which disassembles the instructions through the distorm3 tool.

I print out an execution trace with all the information regarding the executed instruction (physical address, virtual address, opcode) adding also the distorm3 output (operands, mnemonic).

During the validation of the trace output, I noticed some kernel instructions with mnemonic name as "NOP DWORD", which seems not a x86_64 instruction.

So, I extracted the kernel image used during the experiment and I compared the objdump output with the output of distorm3 by using the virtual addresses. As result, I noticed that some of the NOP DWORD instructions interpreted by the distorm are actually named "callq" in the output of distorm.

Can be considered a wrong interpretation of the kernel instruction? Or the distorm3 has a "default" case when it cannot disassembles the mnemonic of an instruction?

[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