X64dbg: x32dbg: analysis triggers breakpoint in Zydis::operator[]

[Mattiwatti]

Debugger version: current git (Oct 9 2017)
OS version: Windows 7 through 10 (XP not tested)
Bitness:: x86 only (meaning x32dbg - the OS can be either)

Description
A DebugBreak() is issued in Zydis::operator[]

Reproduction steps

• Open any executable, e.g. x32dbg.exe itself, and wait for the initial (system or entry) breakpoint.
• Enter the "anal" command.
• An int 3 breakpoint will trigger.

Example stacktrace (sorry for the WinDbg-ness, I just happened to have a kernel debugger attached and didn't want to detach it for other reasons):

Note: xAnalyzer is in the above stacktrace, but it is only executing DbgCmdExecDirect("anal"). I later removed the plugin and reproduced the crash again by entering the same command manually.

As you can see the break conditions are

if(!Success() || index < 0 || index >= OpCount())
  DebugBreak();

The first two evaluate to false, but index and OpCount() are both 0 meaning the latter triggers the breakpoint. Since OpCount() returns mVisibleOpCount, there is a condition where mSuccess = true but mVisibleOpCount = 0 (presumably they are mutually exclusive?).

Zydis::Disassemble(size_t addr, const unsigned char* data, int size) can produce the above scenario if the operand visibility is ZYDIS_OPERAND_VISIBILITY_HIDDEN for all operand(s), since this will set mSuccess to true and make the function return true, but leave mVisibleOpCount set to 0. My stab in the dark (since I don't even know the exact instruction) is that Disassemble() should simply set mSuccess to false and return false if there are no visible operands. Doing this fixed the crash for me at least. But maybe there's an additional underlying issue meaning the instruction is disassembled incorrectly. Is ZYDIS_OPERAND_VISIBILITY_HIDDEN supposed to be true for instructions with no operands (nop, hlt, ...), or is it something else entirely?

[mrexodia]

ping @athre0z

[athre0z]

Thanks for the extensive report! The issue is unrelated to visibility of operands, it was something I messed up in the progress of porting from Capstone to Zydis. #1751 fixes the issue.

[Mattiwatti]

Thanks! I'll verify the fix and close the issue as soon as the PR gets merged. (Not doubting the fix works - it's just that any git command involving more than fetch or pull, especially with more than one remote, tends to somehow destroy my hard drive. I swear it's not me that's incompentent, it's git.)