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?