zyantific/zydis

Fast and lightweight x86/x86-64 disassembler and code generation library

Fast and lightweight x86/x86-64 disassembler and code generation library.

Features

• Supports all x86 and x86-64 (AMD64) instructions and extensions
• Optimized for high performance
• No dynamic memory allocation ("malloc")
• Thread-safe by design
• Very small file-size overhead compared to other common disassembler libraries
• Complete doxygen documentation
• Trusted by many major open-source projects
  • Examples include x64dbg, Mozilla Firefox and Webkit
• Absolutely no third party dependencies — not even libc
  • Should compile on any platform with a working C11 compiler
  • Tested on Windows, macOS, FreeBSD, Linux and UEFI, both user and kernel mode

Examples

Disassembler

The following example program uses Zydis to disassemble a given memory buffer and prints the output to the console.

zydis/examples/DisassembleSimple.c

Lines 38 to 63 in 214536a

	ZyanU8 data[] =
	{
	0x51, 0x8D, 0x45, 0xFF, 0x50, 0xFF, 0x75, 0x0C, 0xFF, 0x75,
	0x08, 0xFF, 0x15, 0xA0, 0xA5, 0x48, 0x76, 0x85, 0xC0, 0x0F,
	0x88, 0xFC, 0xDA, 0x02, 0x00
	};
	// The runtime address (instruction pointer) was chosen arbitrarily here in order to better
	// visualize relative addressing. In your actual program, set this to e.g. the memory address
	// that the code being disassembled was read from.
	ZyanU64 runtime_address = 0x007FFFFFFF400000;
	// Loop over the instructions in our buffer.
	ZyanUSize offset = 0;
	ZydisDisassembledInstruction instruction;
	while (ZYAN_SUCCESS(ZydisDisassembleIntel(
	/* machine_mode: */ ZYDIS_MACHINE_MODE_LONG_64,
	/* runtime_address: */ runtime_address,
	/* buffer: */ data + offset,
	/* length: */ sizeof(data) - offset,
	/* instruction: */ &instruction
	))) {
	printf("%016" PRIX64 " %s\n", runtime_address, instruction.text);
	offset += instruction.info.length;
	runtime_address += instruction.info.length;
	}

The above example program generates the following output:

007FFFFFFF400000   push rcx
007FFFFFFF400001   lea eax, [rbp-0x01]
007FFFFFFF400004   push rax
007FFFFFFF400005   push qword ptr [rbp+0x0C]
007FFFFFFF400008   push qword ptr [rbp+0x08]
007FFFFFFF40000B   call [0x008000007588A5B1]
007FFFFFFF400011   test eax, eax
007FFFFFFF400013   js 0x007FFFFFFF42DB15

Encoder

zydis/examples/EncodeMov.c

Lines 39 to 62 in b37076e

	ZydisEncoderRequest req;
	memset(&req, 0, sizeof(req));
	req.mnemonic = ZYDIS_MNEMONIC_MOV;
	req.machine_mode = ZYDIS_MACHINE_MODE_LONG_64;
	req.operand_count = 2;
	req.operands[0].type = ZYDIS_OPERAND_TYPE_REGISTER;
	req.operands[0].reg.value = ZYDIS_REGISTER_RAX;
	req.operands[1].type = ZYDIS_OPERAND_TYPE_IMMEDIATE;
	req.operands[1].imm.u = 0x1337;
	ZyanU8 encoded_instruction[ZYDIS_MAX_INSTRUCTION_LENGTH];
	ZyanUSize encoded_length = sizeof(encoded_instruction);
	if (ZYAN_FAILED(ZydisEncoderEncodeInstruction(&req, encoded_instruction, &encoded_length)))
	{
	puts("Failed to encode instruction");
	return 1;
	}
	for (ZyanUSize i = 0; i < encoded_length; ++i)
	{
	printf("%02X ", encoded_instruction[i]);
	}

The above example program generates the following output:

48 C7 C0 37 13 00 00

More Examples

More examples can be found in the examples directory of this repository.

Build

There are many ways to make Zydis available on your system. The following sub-sections list commonly used options.

CMake Build

Platforms: Windows, macOS, Linux, BSDs

You can use CMake to build Zydis on all supported platforms. Instructions on how to install CMake can be found here.

git clone --recursive 'https://github.com/zyantific/zydis.git'
cd zydis
cmake -B build
cmake --build build -j4

Visual Studio 2022 project

Platforms: Windows

We manually maintain a Visual Studio 2022 project in addition to the CMake build logic.

CMake generated VS project

Platforms: Windows

CMake can be instructed to generate a Visual Studio project for pretty much any VS version. A video guide describing how to use the CMake GUI to generate such project files is available here. Don't be confused by the apparent use of macOS in the video: Windows is simply running in a virtual machine.

Amalgamated distribution

Platforms: any platform with a working C11 compiler

We provide an auto-generated single header & single source file variant of Zydis. To use this variant of Zydis in your project, all you need to do is to copy these two files into your project. The amalgamated builds can be found on our release page as zydis-amalgamated.tar.gz.

These files are generated with the amalgamate.py script.

Package managers

Platforms: Windows, macOS, Linux, FreeBSD

Pre-built headers, shared libraries and executables are available through a variety of package managers.

Zydis version in various package repositories

Repository	Install command
Arch Linux	pacman -S zydis
Debian	apt-get install libzydis-dev zydis-tools
Homebrew	brew install zydis
NixOS	nix-shell -p zydis
Ubuntu	apt-get install libzydis-dev zydis-tools
vcpkg	vcpkg install zydis

Using Zydis in a CMake project

An example on how to use Zydis in your own CMake based project can be found in this repo.

ZydisInfo tool

The ZydisInfo command-line tool can be used to inspect essentially all information that Zydis provides about an instruction.

Bindings

Official bindings exist for a selection of languages:

• Rust
• Python 3

asmjit-style C++ front-end

If you're looking for an asmjit-style assembler front-end for the encoder, check out zasm. zasm also provides an idiomatic C++ wrapper around the decoder and formatter interface.

Versions

Scheme

Versions follow the semantic versioning scheme. All stability guarantees apply to the API only. ABI stability is provided only between patch versions.

Branches & Tags

• master holds the bleeding edge code of the next, unreleased Zydis version. Increased amounts of bugs and issues must be expected and API stability is not guaranteed outside of tagged commits.
• Stable and preview versions are annotated with git tags
  • beta and other preview versions have -beta, -rc, etc. suffixes
• maintenance/v4 points to the code of the latest release of v4
  • v4 is the latest stable major version and receives feature updates
• maintenance/v3 points to the code of the latest release of v3
  • v3 won't get any feature updates but will receive security updates until 2025
• maintenance/v2 points to the code of the last legacy release of v2
  • v2 is has reached end-of-life and won't receive any security updates

Credits

• Intel (for open-sourcing XED, allowing for automatic comparison of our tables against theirs, improving both)
• LLVM (for providing pretty solid instruction data as well)
• Christian Ludloff (https://sandpile.org, insanely helpful)
• LekoArts (for creating the project logo)
• Our contributors on GitHub

Troubleshooting

-fPIC for shared library builds

/usr/bin/ld: ./libfoo.a(foo.c.o): relocation R_X86_64_PC32 against symbol `bar' can not be used when making a shared object; recompile with -fPIC

Under some circumstances (e.g. when building Zydis as a static library using CMake and then using Makefiles to manually link it into a shared library), CMake might fail to detect that relocation information must be emitted. This can be forced by passing -DCMAKE_POSITION_INDEPENDENT_CODE=ON to the CMake invocation.

Consulting and Business Support

We offer consulting services and professional business support for Zydis. If you need a custom extension, require help in integrating Zydis into your product or simply want contractually guaranteed updates and turnaround times, we are happy to assist with that! Please contact us at [email protected].

Donations

Donations are collected and distributed using flobernd's account.

License

Zydis is licensed under the MIT license.

zydis's Issues

When the data is long enough,Please automatically skip data that cannot be parsed.

test.c

int main() {
	HMODULE hdll = LoadLibraryW("test.dll");
	// Initialize decoder context.
	ZydisDecoder decoder;
	ZydisDecoderInit(
		&decoder ,
		ZYDIS_MACHINE_MODE_LONG_COMPAT_32 ,
		ZYDIS_ADDRESS_WIDTH_32);

	// Initialize formatter. Only required when you actually plan to
	// do instruction formatting ("disassembling"), like we do here.
	ZydisFormatter formatter;
	ZydisFormatterInit(&formatter , ZYDIS_FORMATTER_STYLE_INTEL);

	// Loop over the instructions in our buffer.
	// The IP is chosen arbitrary here in order to better visualize
	// relative addressing.
	uint64_t instructionPointer = hdll;  //--------- dll imagebase-----------
	size_t offset = 0;
	size_t length = 0xe000;  //-------- SizeOfImage ----------
	ZydisDecodedInstruction instruction;
	while (ZYDIS_SUCCESS(ZydisDecoderDecodeBuffer(
		&decoder , (uint8_t *)hdll + offset , length - offset ,
		instructionPointer , &instruction))) {
		// Print current instruction pointer.
		printf("%016" PRIX64 "  " , instructionPointer);

		// Format & print the binary instruction
		// structure to human readable format.
		char buffer[256];
		ZydisFormatterFormatInstruction(
			&formatter , &instruction , buffer , sizeof(buffer));
		puts(buffer);

		offset += instruction.length;
		instructionPointer += instruction.length;
	}
}

Any plan to fix it？

ZydisEncoderEncodeInstruction Error 15

use develop branch:

struct InstructionInfo
{
	ZydisDecodedInstruction Decode;
	ZydisEncoderRequest Encode;
	string Disassembled;
	uint8_t Address;
};

BYTE ShellTest[] =
{
	0x90, 0x90, 0xEB, 0x07, 0xB8, 0x14, 0x00, 0x00, 0x00, 0xC3, 0x90, 0x90, 0x90, 0xE8, 0x07, 0x00,
	0x00, 0x00, 0xEB, 0xF0, 0x90, 0x90, 0x90, 0x90, 0x90, 0xB8, 0x10, 0x00, 0x00, 0x00, 0xBB, 0x32,
	0x00, 0x00, 0x00, 0xC3
};

void DisassembleCode( PVOID pCode , SIZE_T SizeCode , ZydisMachineMode Mode , ZydisAddressWidths Widths , vector<InstructionInfo>& OutInstr )
{
	ZydisDecoder decoder;
	ZydisDecoderInit( &decoder , Mode , Widths );

	ZydisFormatter formatter;
	ZydisFormatterInit( &formatter , ZYDIS_FORMATTER_STYLE_INTEL );

	uint8_t instructionPointer = 0x0;
	uint8_t* readPointer = (uint8_t*)pCode;
	SIZE_T length = SizeCode;

	ZydisDecodedInstruction Decodeinstruction;

	while ( ZYDIS_SUCCESS( ZydisDecoderDecodeBuffer( &decoder , readPointer , length , instructionPointer , &Decodeinstruction ) ) )
	{
		InstructionInfo Info;

		char buffer[256] = { 0 };

		ZydisFormatterFormatInstruction( &formatter , &Decodeinstruction , buffer , sizeof( buffer ) );
		ZydisEncoderDecodedInstructionToRequest( &Decodeinstruction , &Info.Encode );

		Info.Decode = Decodeinstruction;
		Info.Disassembled = buffer;
		Info.Address = instructionPointer;

		readPointer += Decodeinstruction.length;
		length -= Decodeinstruction.length;
		instructionPointer += Decodeinstruction.length;

		OutInstr.push_back( Info );
	}
}

void AssembleCode( vector<InstructionInfo>& DisassembledCode )
{ 
	for ( auto Instr : DisassembledCode )
	{
		char OutBuffer[16] = { 0 };
		size_t OutBufferLen = sizeof( OutBuffer );

		ZydisStatus Status = ZydisEncoderEncodeInstruction( OutBuffer , &OutBufferLen , &Instr.Encode );
		
		if ( Status != ZYDIS_STATUS_SUCCESS )
		{
			printf( "Error: %i (%s)\n" , Status , Instr.Disassembled.c_str() );
			break;
		}
		else
			printf( "Success: %i (%s)\n" , Status , Instr.Disassembled.c_str() );
	}
}

int main( int argc , char** argv )
{
	vector<InstructionInfo> DisassembledCode;

	DisassembleCode( ShellTest , sizeof( ShellTest ) , ZYDIS_MACHINE_MODE_LONG_64 , ZYDIS_ADDRESS_WIDTH_64 , DisassembledCode );

	for ( auto Instr : DisassembledCode )
		printf( "%p | %s\n" , (PVOID)Instr.Address , Instr.Disassembled.c_str() );
	
	AssembleCode( DisassembledCode );

	getchar();
	return 0;
}

Output:
0000000000000000 | nop
0000000000000001 | nop
0000000000000002 | jmp 0x000000000000000B
0000000000000004 | mov eax, 0x14
0000000000000009 | ret
000000000000000A | nop
000000000000000B | nop
000000000000000C | nop
000000000000000D | call 0x0000000000000019
0000000000000012 | jmp 0x0000000000000004
0000000000000014 | nop
0000000000000015 | nop
0000000000000016 | nop
0000000000000017 | nop
0000000000000018 | nop
0000000000000019 | mov eax, 0x10
000000000000001E | mov ebx, 0x32
0000000000000023 | ret
Success: 0 (nop)
Success: 0 (nop)
Success: 0 (jmp 0x000000000000000B)
Error: 15 (mov eax, 0x14)

Addresses leading zeros

Hi. Is there a way to remove leading zeros without hooking?

how did you build .obj in zydis-pascal & small question

i try to search for how to generate .obj file from msvc or mingw but nothing
all i found is convert .lib to .obj coff

but it's not working cuz the output of build is .dll or .lib

can you please tell me how you do it ?

---

and i'm working on CPU Emulator dedicated only for x86

and i want to know if it possible to make a generic code to handle all "mov" instructions cases

for example if i have

mov dword ptr ds:[esi], eax

== [ OPERANDS ] ============================================================================================
##       TYPE  VISIBILITY  ACTION      ENCODING   SIZE  NELEM  ELEMSZ  ELEMTYPE                        VALUE
--  ---------  ----------  ------  ------------   ----  -----  ------  --------  ---------------------------
 0     MEMORY    EXPLICIT       W      MODRM_RM     32      1      32       INT  TYPE  =                 MEM
                                                                                 SEG   =                  ds
                                                                                 BASE  =                 esi
                                                                                 INDEX =                none
                                                                                 SCALE =                   0
                                                                                 DISP  =  0x0000000000000000
 1   REGISTER    EXPLICIT       R     MODRM_REG     32      1      32       INT                          eax
--  ---------  ----------  ------  ------------   ----  -----  ------  --------  ---------------------------

and

mov eax, dword ptr ds:[esi]

== [ OPERANDS ] ============================================================================================
##       TYPE  VISIBILITY  ACTION      ENCODING   SIZE  NELEM  ELEMSZ  ELEMTYPE                        VALUE
--  ---------  ----------  ------  ------------   ----  -----  ------  --------  ---------------------------
 0   REGISTER    EXPLICIT       W     MODRM_REG     32      1      32       INT                          eax
 1     MEMORY    EXPLICIT       R      MODRM_RM     32      1      32       INT  TYPE  =                 MEM
                                                                                 SEG   =                  ds
                                                                                 BASE  =                 esi
                                                                                 INDEX =                none
                                                                                 SCALE =                   0
                                                                                 DISP  =  0x0000000000000000
--  ---------  ----------  ------  ------------   ----  -----  ------  --------  ---------------------------

how can i know which oprande is distance and which is source
should i do every case in it's own or is there a way to handle multi cases for one instruction

thanks

Unknown CMake command "zyan_set_common_flags" on MacOS

cmake version : 3.12.1

it gives this error

Coldzer0 @ build $cmake ..
-- The C compiler identification is AppleClang 9.0.0.9000037
-- The CXX compiler identification is AppleClang 9.0.0.9000037
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at CMakeLists.txt:48 (add_subdirectory):
  The source directory

    zydis/dependencies/zycore

  does not contain a CMakeLists.txt file.


CMake Error at CMakeLists.txt:60 (zyan_set_common_flags):
  Unknown CMake command "zyan_set_common_flags".


-- Configuring incomplete, errors occurred!
See also "CMakeFiles/CMakeOutput.log".

INVALID when disassembling insertps

Tried to disassemble this 32-bit buffer in the SimpleDemo.cpp sample:

{ 0x66, 0x0F, 0x3A, 0x21, 0xD0, 0xF0, 0x33, 0xC0 }

Zydis fails to find the correct instruction:

insertps xmm2, xmm0, 0F0h

Also tested with Udis86 and it failed as well.

Debugged a little, and it fails in InstructionDecoder::decodeOperands function, which is inside InstructionDecoder::decodeOpcode.

In the above case, it managed to correctly disassemble the next instruction (xor eax, eax):

77091852 db 66
77091853 db 0F
77091854 cmp ah, [ecx]
77091856 shl al, 01
77091858 xor eax, eax

But I was wondering if it's better to skip the entire insertps instruction instead of skipping only 1 byte and trying to disassemble it. For that, you would need to get at least the insertps instruction length correctly.

Use of angle brackets around file names for include statements

Would you like to replace any double quotes by angle brackets around file names for include statements?

Getting unresolved external symbol

So I've gone through and done Cmake, built, and added all the files where I believe they should go, but I keep getting Unresolved external symbol for the following:

Error LNK2001 unresolved external symbol ZydisDecoderInit thesisBitMapper Code\thesisBitMapper\thesisBitMapper\thesisBitMapper.obj 1
Error LNK2001 unresolved external symbol ZydisFormatterInit thesisBitMapper Code\thesisBitMapper\thesisBitMapper\thesisBitMapper.obj 1
Error LNK2001 unresolved external symbol ZydisFormatterFormatInstruction thesisBitMapper Code\thesisBitMapper\thesisBitMapper\thesisBitMapper.obj 1
Error LNK2001 unresolved external symbol ZydisDecoderDecodeBuffer thesisBitMapper Code\thesisBitMapper\thesisBitMapper\thesisBitMapper.obj 1

Failure to compile in FreeBSD due to unsupported platform in examples

Hi,

examples/ZydisPerfTest.c only supports Windows/Apple/Linux and default CMake will fail to build on latest FreeBSD (both master and develop branches).

Fixed it by not compiling the examples in the CMake file:
option(ZYDIS_BUILD_EXAMPLES
"Build examples"
OFF)

FreeBSD freebsd 11.2-RELEASE FreeBSD 11.2-RELEASE #0 r335510: Fri Jun 22 04:32:14 UTC 2018 [email protected]:/usr/obj/usr/src/sys/GENERIC amd64

Do you want me to try to fix the examples to support FreeBSD and make a pull request?

Best way to print a single operand?

Hi,

I need to have a string output of the second operand of a given instruction. What is the best way to achieve this? Installing a hook at ZYDIS_FORMATTER_HOOK_FORMAT_INSTRUCTION seems the right way but looking at ZydisFormatInstrIntel() code it depends on some internal functions?

I need the operand to easily reassemble into another instruction using Keystone engine.

Thanks,
fG!

Only x86, x64?

Hi,

Is it possible that someday you'll add other platforms that the Capstone supports?

I want to know that a general register is the same, just different width.

I want to know that a general register is the same, just different width.
like this:
ZYDIS_REGISTER_AL
ZYDIS_REGISTER_AX
ZYDIS_REGISTER_EAX
ZYDIS_REGISTER_RAX

They are different values, but they are actually the same register.

Because I want to know if the registers in an instruction are overwritten.
like this:
mov rax,[rax + rdx]

So I implemented this function myself.

ZydisI16 ZydisRegisterGpr8Id[] =
{
0,1,2,3,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
};
ZydisI16 zydis_get_general_register_id(ZydisRegister reg)
{
ZydisRegisterClass reg_class = ZydisRegisterGetClass(reg);

if (ZYDIS_REGCLASS_GPR8 == reg_class)
{
	ZydisI16 regid = ZydisRegisterGetId(reg);
	return ZydisRegisterGpr8Id[regid];
}
else if (ZYDIS_REGCLASS_GPR16 == reg_class ||
	ZYDIS_REGCLASS_GPR32 == reg_class ||
	ZYDIS_REGCLASS_GPR64 == reg_class)
{
	return (reg - ZYDIS_REGISTER_AX) % 16;
}

return -1;

}
ZydisBool zydis_is_same_general_register(ZydisRegister reg1, ZydisRegister reg2)
{
ZydisI16 regid_1 = zydis_get_general_register_id(reg1);
ZydisI16 regid_2 = zydis_get_general_register_id(reg2);

if (regid_1 != -1)
{
	if (regid_1 == regid_2)
	{
		return ZYDIS_TRUE;
	}
}

return ZYDIS_FALSE;

}

Invalid decoding of jmp cs:0x1122334455667788

I have a bug with decoding this machine code (x64):
FF 25 00 00 00 00 11 22 33 44 55 66 77 88
Zydis decodes only first part (FF 25 00 00 00 00) as jmp cs:RelativeOffset32 (and second part with 8-bytes address as junk - another instructions). But it should be a single instruction with absolute 8-byte address -jmp cs:AbsoluteAddress64.

CMake 3.7.1 - Unknown CMake command "zyan_set_common_flags" [Windows 10 x64]

Thanks for any help.

Calling conventions of Zydis funcs on gcc x32

Hi, guys!
I try to use libZydis in Linux kernel module and have a calling convetion problem.
CMake generates an empty ZYDIS_EXPORT definition in ZydisExportConfig.h:
#define ZYDIS_EXPORT
But with this definition (I've include ZydisExportConfig.h into my sources) GCC generates this code to call a functions from libZydis:

mov ecx, arg3
mov edx, arg2
mov eax, arg1
call ZydisExportedFunction

but as I can see, function in libZydis uses cdecl-convention with regparm(0) (all arguments passes through the stack), so we crashes.

But if I change ZYDIS_EXPORT definition in ZydisExportConfig.h included into my sources to this:
#define ZYDIS_EXPORT __attribute__((used, cdecl, regparm(0)))
gcc generated this code:

push arg3
push arg2
push arg1
call ZydisExportedFunction

BUT! It doesn't repair the stack after calling (I think it generates stdcall instead of cdecl - I really don't know, why).
So ok, we crashes too, but I think I can fix this if try to compile libZydis with redefined ZYDIS_EXPORT (I want to set it to cdecl manually). But cmake rewrites ZydisExportConfig.h.

What can I do to fix this?

Conditional writes for CPU flags

Some instructions will only conditionally modify a CPU flag. I think most instructions do so unconditionally.

Zydis exposes conditional reads and writes for operands.

Should it do the same for CPU flags?

Example: (conditional carry flag write)

rol eax, 0 ; Value of CF will be preserved
rol eax, 1 ; Value of CF will be modified

Here are a few others:

RCL/RCR/ROL/ROR--Rotate
"If the masked count is 0, the flags are not affected. If the masked count is 1, then the OF flag is affected, otherwise (masked count is greater than 1) the OF flag is undefined. The CF flag is affected when the masked count is non-zero."

DAA/DAS
"The CF and AF flags are set if the adjustment of the value results in a decimal [carry/borrow] in either digit of the result.."

CLI/STI
"Either the IF flag or the VIF flag is [cleared/set] to [0/1]."

SAL/SAR/SHL/SHR--Shift
"If the count is 0, the flags are not affected."

SHLD/SHRD
"If the count operand is 0, the flags are not affected."

./ZydisInfo -64 5d doesn't show the implicit memory reads and register writes

All that I get is:

$ ./ZydisInfo -64 5d
== [    BASIC ] ============================================================================================
   MNEMONIC: pop [ENC: DEFAULT, MAP: DEFAULT, OPC: 5D]
     LENGTH:  1
        SSZ: 64
       EOSZ: 64
       EASZ: 64
   CATEGORY: POP
    ISA-SET: BASE
    ISA-EXT: I86
 EXCEPTIONS: NONE

== [ OPERANDS ] ============================================================================================
##       TYPE  VISIBILITY  ACTION      ENCODING   SIZE  NELEM  ELEMSZ  ELEMTYPE                        VALUE
--  ---------  ----------  ------  ------------   ----  -----  ------  --------  ---------------------------
 0   REGISTER    EXPLICIT       W        OPCODE     64      1      64       INT                          rbp
--  ---------  ----------  ------  ------------   ----  -----  ------  --------  ---------------------------

== [   DISASM ] ============================================================================================
  pop rbp

compared to xed's

$ $ ./xed-ex1 -64 5d
Attempting to decode: 5d
iclass POP	category POP	ISA-extension BASE	ISA-set I86
instruction-length 1
operand-width 64
effective-operand-width 64
effective-address-width 64
stack-address-width 64
iform-enum-name POP_GPRv_58
iform-enum-name-dispatch (zero based) 3
iclass-max-iform-dispatch 8
Operands
#   TYPE               DETAILS        VIS  RW       OC2 BITS BYTES NELEM ELEMSZ   ELEMTYPE   REGCLASS
#   ====               =======        ===  ==       === ==== ===== ===== ======   ========   ========
0   REG0              REG0=RBP   EXPLICIT   W         V   64     8     1     64        INT        GPR
1   REG1         REG1=STACKPOP SUPPRESSED   R       SPW   64     8     1     64        INT     PSEUDO
2   MEM0           (see below) SUPPRESSED   R       SPW   64     8     1     64        INT    INVALID
3  BASE0             BASE0=RSP SUPPRESSED  RW       SSZ   64     8     1     64        INT        GPR
Memory Operands
  0    read BASE= RSP/GPR  ASZ0=64
  MemopBytes = 8
ATTRIBUTES: FIXED_BASE0 SCALABLE STACKPOP0
ISA SET: [I86]

Grouping bytes of opcode

x64dbg users are expecting the bytes of opcode can be grouped like Ollydbg. For example, B8 00 00 00 00 (mov eax,0) can be displayed as B8 00000000 and C7 86 11 11 11 11 22 22 22 22 (mov dword ptr ds:[esi+11111111],22222222) can be displayed as C786 11111111 22222222. It will be very helpful if such information can be available with zydis. Thank you.

Build without KNC and AVX512 is broken on Clang

Building with

cmake -DZYDIS_FEATURE_AVX512=OFF -DZYDIS_FEATURE_KNC=OFF ..

fails with

/tmp/stuff/zydis/src/Generated/InstructionDefinitions.inc:3761:7: error: unknown type name 'ZydisInstructionDefinitionEVEX'; did you
      mean 'ZydisInstructionDefinitionVEX'?
const ZydisInstructionDefinitionEVEX ISTR_DEFINITIONS_EVEX[] =
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      ZydisInstructionDefinitionVEX
/tmp/stuff/zydis/include/Zydis/Internal/SharedData.h:815:3: note: 'ZydisInstructionDefinitionVEX' declared here
} ZydisInstructionDefinitionVEX;
  ^
In file included from /tmp/stuff/zydis/src/SharedData.c:43:
/tmp/stuff/zydis/src/Generated/InstructionDefinitions.inc:3763:565: warning: excess elements in struct initializer
  ...ZYDIS_REG_CONSTRAINTS_NONE, ZYAN_FALSE ZYDIS_NOTMIN(ZYDIS_IVECTOR_LENGTH_DEFAULT) ZYDIS_NOTMIN(ZYDIS_TUPLETYPE_T1_4X) ZYDIS_NO...
                                                                                                    ^~~~~~~~~~~~~~~~~~~~~
/tmp/stuff/zydis/src/SharedData.c:40:30: note: expanded from macro 'ZYDIS_NOTMIN'
#   define ZYDIS_NOTMIN(x) , x

with the latter warning being repeated a few thousand times.

I imagine that while MSVC seems to be eating it (judging from the PR #71), this might result in corrupted tables and thus incorrect output (due to shifting etc).

Compile error when building dev mode twice

Version: 805f5e9
Steps to reproduce:

git clone --recursive https://github.com/zyantific/zydis.git
cd zydis && mkdir build && cd build
cmake -DCMAKE_C_COMPILER=gcc-8 -DZYAN_DEV_MODE=ON .. && make
cmake -DCMAKE_C_COMPILER=gcc-8 -DZYAN_DEV_MODE=ON .. && make

Output (abridged for brevity):

In file included from /home/ceeac/Projects/code/zydis/dependencies/zycore/include/Zycore/Vector.h:37,
                 from /home/ceeac/Projects/code/zydis/dependencies/zycore/include/Zycore/String.h:39,
                 from /home/ceeac/Projects/code/zydis/dependencies/zycore/include/Zycore/Format.h:37,
                 from /home/ceeac/Projects/code/zydis/dependencies/zycore/src/Format.c:27:
/home/ceeac/Projects/code/zydis/dependencies/zycore/include/Zycore/Comparison.h:123:71: error: ISO C does not allow extra ‘;’ outside of a function [-Werror=pedantic]
 ZYAN_INLINE ZYAN_DECLARE_EQUALITY_COMPARISON(ZyanEqualsBool, ZyanBool);

This happens for both clang and GCC, so this is not compiler specific.

Mnemonic RSM formatted as ret?

Hi, I was writing some code to check whether an instruction is some kind of return opcode and I noticed that ZydisMnemonicGetStaticString(ZYDIS_MNEMONIC_RSM) == "ret". Why does it not return "rsm"?

reserved identifier violation

I would like to point out that identifiers like "_ZYDIS_HPP_" and "_ZydisInstructionFlags" do not fit to the expected naming convention of the C++ language standard.
Would you like to adjust your selection for unique names?

Wrong mnemonic for MOVSS

Tried to get the mnemonic for the following instruction (32-bit):

{0xF3, 0x0F, 0x10, 0x05, 0x58, 0xF4, 0xD0, 0x00}

Zydis gave me:

movsd xmm0, [D0F458]

But the correct mnemonic is:

movss xmm0, [D0F458]

switch to the develop branch as default

Currently it is very confusing that the master uses C++14 and develop uses C99. Maybe it's a good idea to switch to the develop as the default branch.

Incorrect register class of instruction pointer register

$ ZydisInfo -64 488b05b6310500
...
== [ OPERANDS ] ============================================================================================
##       TYPE  VISIBILITY  ACTION      ENCODING   SIZE  NELEM  ELEMSZ  ELEMTYPE                        VALUE
--  ---------  ----------  ------  ------------   ----  -----  ------  --------  ---------------------------
 0   REGISTER    EXPLICIT       W     MODRM_REG     64      1      64       INT                          rax
 1     MEMORY    EXPLICIT       R      MODRM_RM     64      1      64       INT  TYPE  =                 MEM
                                                                                 SEG   =                  ds
                                                                                 BASE  =                 rip
                                                                                 INDEX =                none
                                                                                 SCALE =                   0
                                                                                 DISP  =  0x00000000000531B6

Here this instruction's memory operand uses %rip as its base register. If I modify ZydisInfo to print the register class, as in ZydisRegisterGetClass(instruction->operands[i].mem.base), I get ZYDIS_REGCLASS_INVALID, which seems incorrect. I expect ZYDIS_REGCLASS_IP.

Support formatting immediates in decimal

It should be possible to set ZYDIS_FORMATTER_PROP_IMM_FORMAT to something like ZYDIS_IMM_FORMAT_DEC_{SIGNED|UNSIGNED|AUTO}. Since that would also duplicate some options regarding the signedness it might be better to instead have something like ZYDIS_FORMATTER_PROP_IMM_BASE which can be set to either DEC or HEX and ZYDIS_FORMATTER_PROP_IMM_SIGNEDNESS which can be set to AUTO, SIGNED or UNSIGNED.

bug in printing addresses

In Formatter.c:ZydisFormatterPrintAddressIntel in 32 and 64 bit mode addresses will be incorrectly printed if they sign-extend to a negative integer. I'm still trying to figure out why this happens.

rasm2 -a x86.zyan -b 32 -d E8FFFFFFFF
call 0xFFFFFFFFFFFFFFFF

difference or advantage over capstone ?

Operand Effective Width

Is there a way to read the number of bytes an instruction is effectively reading?

Let's say movaps [rsp+30],xmm6, [rsp+30] is accessing 16 bytes.

or movsd xmm6,[code.dll+148830] is accessing 8 bytes.

I am looking at here:

https://zyantific.com/doc/zydis/struct_zydis_decoded_instruction__.html

Thanks

ZydisInfo tool [FLAGS]

does not display operation flags

c:\zydis>ZydisInfo -64 48 03 84 98 00 01 00 00
== [    BASIC ] ============================================================================================
   MNEMONIC: add [ENC: DEFAULT, MAP: DEFAULT, OPC: 03]
     LENGTH:  8
        SSZ: 64
       EOSZ: 64
       EASZ: 64
   CATEGORY: BINARY
    ISA-SET: BASE
    ISA-EXT: I86
 EXCEPTIONS: NONE
 ATTRIBUTES: HAS_MODRM HAS_SIB HAS_REX ACCEPTS_SEGMENT

== [ OPERANDS ] ============================================================================================
##       TYPE  VISIBILITY  ACTION      ENCODING   SIZE  NELEM  ELEMSZ  ELEMTYPE                        VALUE
--  ---------  ----------  ------  ------------   ----  -----  ------  --------  ---------------------------
 0   REGISTER    EXPLICIT      RW     MODRM_REG     64      1      64       INT                          rax
 1     MEMORY    EXPLICIT       R      MODRM_RM     64      1      64       INT  TYPE  =                 MEM
                                                                                 SEG   =                  ds
                                                                                 BASE  =                 rax
                                                                                 INDEX =                 rbx
                                                                                 SCALE =                   4
                                                                                 DISP  =  0x0000000000000100
 2   REGISTER      HIDDEN       W          NONE     64      1      64       INT                       rflags
--  ---------  ----------  ------  ------------   ----  -----  ------  --------  ---------------------------

== [   DISASM ] ============================================================================================
  add rax, qword ptr ds:[rax+rbx*4+0x100]

c:\zydis>

Errors while using Zydis.lib in windows driver

Quick fixes for:

• stdint.h not found -> just add a copy from visual studio
• unresolved external symbol __imp_wassert: redefine ZYDIS_ASSERT and ZYDIS_UNREACHABLE to ;
• unresolved external symbol __imp___stdio_common_vsprintf: use winkernel_mm.* from capstone
• missing DriverEntry / ALIGN errors -> see this issue
• unresolved external symbol __imp___stdio_common_vsprintf: add /D _NO_CRT_STDIO_INLINE to cl options in Zydis project

Assert causing crash with invalid instruction bytes

Hello,

Today someone reported a bug to me where x64dbg was crashing and it turns out there is an assert in Zydis that causes this. ODA gives this as an invalid instruction, but it might just be too new for it...

To reproduce I use ZydisInfo. On master:

>zydisinfo -64 62B1F80D1831
Assertion failed: instruction->operandCount >= 2, file c:\codeblocks\zydis\src\decoder.c, line 2006

On develop:

>zydisinfo -64 62B1F80D1831
== [    BASIC ] ============================================================================================
   MNEMONIC: vprefetche1 [ENC: MVEX, MAP: 0F, OPC: 18]
     LENGTH:  6
        SSZ: 64
       EOSZ: 64
       EASZ: 64
   CATEGORY: PREFETCH
    ISA-SET: KNCE
    ISA-EXT: KNCE
 EXCEPTIONS: NONE
 ATTRIBUTES: HAS_MODRM HAS_MVEX

== [ OPERANDS ] ============================================================================================
##       TYPE  VISIBILITY  ACTION      ENCODING   SIZE  NELEM  ELEMSZ  ELEMTYPE                        VALUE
--  ---------  ----------  ------  ------------   ----  -----  ------  --------  ---------------------------
 0     MEMORY    EXPLICIT       R      MODRM_RM      8      0      64       INT  TYPE  =                 MEM
                                                                                 SEG   =                  ds
                                                                                 BASE  =                 rcx
                                                                                 INDEX =                none
                                                                                 SCALE =                   0
                                                                                 DISP  =  0x0000000000000000
--  ---------  ----------  ------  ------------   ----  -----  ------  --------  ---------------------------

== [      AVX ] ============================================================================================
  VECTORLEN: 512
  BROADCAST: NONE
   ROUNDING: DEFAULT
        SAE: N
       MASK: k5 [MERGE]
         EH: N
    SWIZZLE: NONE
    CONVERT: NONE

== [   DISASM ] ============================================================================================
  vprefetche1 byte ptr ds:[rcx]

On future:

>zydisinfo -64 62B1F80D1831
== [    BASIC ] ============================================================================================
   MNEMONIC: vprefetche1 [ENC: MVEX, MAP: 0F, OPC: 18]
     LENGTH:  6
        SSZ: 64
       EOSZ: 64
       EASZ: 64
   CATEGORY: PREFETCH
    ISA-SET: KNCE
    ISA-EXT: KNCE
 EXCEPTIONS: NONE
 ATTRIBUTES: HAS_MODRM HAS_MVEX

== [ OPERANDS ] ============================================================================================
##       TYPE  VISIBILITY  ACTION      ENCODING   SIZE  NELEM  ELEMSZ  ELEMTYPE                        VALUE
--  ---------  ----------  ------  ------------   ----  -----  ------  --------  ---------------------------
 0     MEMORY    EXPLICIT       R      MODRM_RM      8      0      64       INT  TYPE  =                 MEM
                                                                                 SEG   =                  ds
                                                                                 BASE  =                 rcx
                                                                                 INDEX =                none
                                                                                 SCALE =                   0
                                                                                 DISP  =  0x0000000000000000
--  ---------  ----------  ------  ------------   ----  -----  ------  --------  ---------------------------

== [      AVX ] ============================================================================================
  VECTORLEN: 512
  BROADCAST: NONE
   ROUNDING: DEFAULT
        SAE: N
       MASK: k5 [MERGE]
         EH: N
    SWIZZLE: NONE
    CONVERT: NONE

== [   DISASM ] ============================================================================================
  vprefetche1 byte ptr ds:[rcx]

Optable generator marked as todo

Looking at the code, it seems your optable is generated from an xml document, however the optable generator main function is marked as todo. Did you complete this part (I assume so since you have a complete optable in the main library), and would you consider uploading the generator too? I would be realy interested to study that part. Thanks.

Bad format of instructions with relative address

In disassembling 0f b7 05 1e 28 00 00, I have received the following result:

movzx eax, word ptr ds:[0x0000000000002825]

while it is actually of relative address with base rip. Indeed, ZydisInfo shows correct information:

./ZydisInfo -64 0f b7 05 1e 28 00 00
== [    BASIC ] ============================================================================================
   MNEMONIC: movzx [ENC: DEFAULT, MAP: 0F, OPC: B7]
     LENGTH:  7
        SSZ: 64
       EOSZ: 32
       EASZ: 64
   CATEGORY: DATAXFER
    ISA-SET: BASE
    ISA-EXT: I386
 EXCEPTIONS: NONE
 ATTRIBUTES: HAS_MODRM IS_RELATIVE ACCEPTS_SEGMENT 

== [ OPERANDS ] ============================================================================================
##       TYPE  VISIBILITY  ACTION      ENCODING   SIZE  NELEM  ELEMSZ  ELEMTYPE                        VALUE
--  ---------  ----------  ------  ------------   ----  -----  ------  --------  ---------------------------
 0   REGISTER    EXPLICIT       W     MODRM_REG     32      1      32       INT                          eax
 1     MEMORY    EXPLICIT       R      MODRM_RM     16      1      16       INT  TYPE  =                 MEM
                                                                                 SEG   =                  ds
                                                                                 BASE  =                 rip
                                                                                 INDEX =                none
                                                                                 SCALE =                   0
                                                                                 DISP  =  0x000000000000281E
--  ---------  ----------  ------  ------------   ----  -----  ------  --------  ---------------------------

== [   DISASM ] ============================================================================================
  movzx eax, word ptr ds:[0x0000000000002825]

I think the problem might come from a check in Formatter.c where

if ((formatter->formatAddress == ZYDIS_ADDR_FORMAT_ABSOLUTE) ||
(operand->mem.base == ZYDIS_REGISTER_NONE))
{
    ...
}

should be replaced by:

if ((formatter->formatAddress == ZYDIS_ADDR_FORMAT_ABSOLUTE) &&
(operand->mem.base == ZYDIS_REGISTER_NONE))
{
    ...
}

and with this fix, zydis shows correct disassembling result:

movzx eax, word ptr ds:[rip+0x281E]

Add flag for instructions that might write all registers

Some instructions like XRSTOR can write pretty much any register in the CPU simultaneously. It'd be poor design to list all >200 registers for those instructions in ZydisDecodedInstruction::operands (it would require to significantly increase the struct size in order to stay malloc free). Instead, we should add an attribute indicating that all registers and CPU states might be written by the instruction to allow correct taint tracking in optimizers and static code analyzers. We might also want so differentiate between full CPU state change and X87 only state updates (e.g. FRSTOR) using another attribute.

It could also be set for interrupt and syscall style instruction, although this will require further consideration.

Failure to compile on Red Hat Enterprise/CentOS

Hi,

CentOS 7 and equivalent Red Hat Enterprise still ship very old GCC on default install and Zydis fails to compile. Essentially the -std=c99 option is required, which is set on Zydis Cmake files for the debug build but not default one. You might want to pass that option by default or detect RH/CentOS and set it.

Other than newer Cmake version and that option it compiles and works fine there.

Best,
Pedro

Compile error: a label can only be part of a statement

I had compilation error when build the master branch. My GCC version is "cc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609". Below is the error message.

[ 22%] Building C object CMakeFiles/Zydis.dir/src/Utils.c.o
In file included from /home/nature/Software/zydis/include/Zydis/Utils.h:35:0,
from /home/nature/Software/zydis/src/Utils.c:28:
/home/nature/Software/zydis/src/Utils.c: In function ‘ZydisGetInstructionSegments’:
/home/nature/Software/zydis/dependencies/zycore/include/Zycore/Defines.h:192:29: error: a label can only be part of a statement and a declaration is not a statement
define ZYAN_FALLTHROUGH attribute ((fallthrough))
^
/home/nature/Software/zydis/src/Utils.c:251:13: note: in expansion of macro ‘ZYAN_FALLTHROUGH’
ZYAN_FALLTHROUGH;
^
/home/nature/Software/zydis/src/Utils.c:251:13: warning: empty declaration
In file included from /home/nature/Software/zydis/include/Zydis/Utils.h:35:0,
from /home/nature/Software/zydis/src/Utils.c:28:
/home/nature/Software/zydis/dependencies/zycore/include/Zycore/Defines.h:192:29: error: a label can only be part of a statement and a declaration is not a statement
define ZYAN_FALLTHROUGH attribute ((fallthrough))
^
/home/nature/Software/zydis/src/Utils.c:253:13: note: in expansion of macro ‘ZYAN_FALLTHROUGH’
ZYAN_FALLTHROUGH;

Generated tables?

Hi,
I'd like to know how the tables in src/Generated were, well, generated. Care to share a bit more about the process? Do you have a PDF parser for the Intel manuals (or the AMD ones)? Are they copied and modified from some other project? Where they even "generated" by hand?

Cheers,

Christian

Go bindings for Zydis

Hello folks,

Any plans to support go bindings in the future ?

Thank you.

NOP and assertion

Hi,

Thanks for your work on this, always great to have another disassembler library.

I'm a regular Capstone and diStorm user and was trying to test Zydis to see how well it compares with those two.

I'm having an issue with a specific assert on the following bytes:
F3 66 66 66 66 66 66 2E 0F 1F 84 00 00 00 00 00

IDA interprets this as a REP NOP with a few unknown bytes. Capstone is unable to disassemble this. And Zydis asserts here:
Assertion failed: (0), function ZydisCheckErrorConditions, file /Users/reverser/Projects/Sentinel/research/macho analyser/lib_macho_analyser/external_libs/zydis/src/Decoder.c, line 4101. (this is on latest develop branch available)

Capstone tries to disassemble the whole buffer while Zydis disassembles each instruction. In my use case I'm linearly disassembling each function to retrieve some information about it (Mach-O binaries make this easy) so I will end up trying to disassemble some of the alignment bytes at the end.

My question is more about library design. Are these asserts to be kept in final version? I rather have the disassembler telling me it failed to disassemble the current bytes then just exploding on me, so I am just curious about your design decisions here.

Thanks and keep up the good work!
fG!

Some registers do not have register classes

Just reviewing the table of register classes, the following are missing:

// Table registers
ZYDIS_REGISTER_GDTR,   ZYDIS_REGISTER_LDTR,   ZYDIS_REGISTER_IDTR,  ZYDIS_REGISTER_TR,
// Bound registers
ZYDIS_REGISTER_BNDCFG, ZYDIS_REGISTER_BNDSTATUS,
// Misc registers
ZYDIS_REGISTER_MXCSR,  ZYDIS_REGISTER_PKRU,   ZYDIS_REGISTER_XCR0,

-fPIC missing on FreeBSD

Hi,

FreeBSD clang doesn't seem to like the built libZydis.a due to missing -fPIC option while compiling.
/usr/bin/ld: /usr/local/lib/libZydis.a(Decoder.c.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/libZydis.a: could not read symbols: Bad value
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Fixing it by adding
target_compile_options("${target}" PRIVATE "-fPIC")
to function (_set_common_flags target) in CMakeLists.txt.

It seems FreeBSD specific issue so maybe detect FreeBSD and add the flag to compiler options?

$ uname -an
FreeBSD freebsd 11.2-RELEASE FreeBSD 11.2-RELEASE #0 r335510: Fri Jun 22 04:32:14 UTC 2018 [email protected]:/usr/obj/usr/src/sys/GENERIC amd64
$ clang -v
FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0)
Target: x86_64-unknown-freebsd11.2
Thread model: posix
InstalledDir: /usr/bin

Fix gitter link in README.md

Currently the link given there leads to nonexistent page (404 error)

WinDDK is not supported.

hi:
When I use C:\WinDDK\7600.16385.1 to build this, I will encounter many problems.

like this:

case ZYDIS_REG_ENCODING_OPCODE:
{
ZYDIS_ASSERT((registerClass == ZYDIS_REGCLASS_GPR8) ||
(registerClass == ZYDIS_REGCLASS_GPR16) ||
(registerClass == ZYDIS_REGCLASS_GPR32) ||
(registerClass == ZYDIS_REGCLASS_GPR64));
ZydisU8 value = (instruction->opcode & 0x0F); << faild!
if (value > 7)
{
value = value - 8;
}
return value;
}

or

static ZydisStatus ZydisDecodeOperandMemory(ZydisDecoderContext* context,
ZydisDecodedInstruction* instruction, ZydisDecodedOperand* operand,
ZydisRegisterClass vidxRegisterClass)
{
ZYDIS_ASSERT(context);
ZYDIS_ASSERT(instruction);
ZYDIS_ASSERT(operand);
ZYDIS_ASSERT(instruction->raw.modrm.isDecoded);
ZYDIS_ASSERT(instruction->raw.modrm.mod != 3);
ZYDIS_ASSERT(!vidxRegisterClass || ((instruction->raw.modrm.rm == 4) &&
((instruction->addressWidth == 32) || (instruction->addressWidth == 64))));
operand->type = ZYDIS_OPERAND_TYPE_MEMORY;
operand->mem.type = ZYDIS_MEMOP_TYPE_MEM;
const ZydisU8 modrm_rm = instruction->raw.modrm.rm; << faild!
ZydisU8 displacementSize = 0; << faild!

The problem is that the location of the variable is not declared in the first line.

Question about ZydisCPUFlagAction

Hello,

I am trying to get information about which flags a decoded instruction is accessing. The ZydisDecodedInstruction.accessedFlags[ZYDIS_CPUFLAG_CF].action appears to give me how the CF flag is affected by the instruction.

I am confused about the meaning of ZYDIS_CPUFLAG_ACTION_MODIFIED. For the ADC and SBB instructions the CF flag is both tested and modified. Does this mean that modified can implicitly mean tested as well, or is this a missing action?

Thanks,

Duncan

Bad instruction and asserts

Hi,

Getting an assert on the following bytes: 64 62 b1 f8 0d 18 31
Assertion failed: (instruction->operandCount >= 2), function ZydisDecodeOperands, file /Users/xxxxx/zydis/src/Decoder.c, line 2006. A few variations of the last byte also produce the same result.

The core question is if asserts are to stay in the code base or they will be removed in the near future? The reason is that I am mass analysing potentially hostile binaries and getting into weird decodings like this and that will crash my daemon, unless I write something to intercept those assertions and recover from them.

Are these kind of instructions interesting to you to return proper errors? I'll probably land into a bunch of them on my side.

Best,
Pedro

P.S.: sort of ignore the asserts as development feature since I just saw I asked that long time ago in another bug. In this particular case I fixed the assert into a test for operandCount < 2 and return a ZYDIS_STATUS_DECODING_ERROR if true. Might be better than the assert but didn't really check the EVX instructions to see if it's the best solution.

Comment error

/**
* @brief A pointer to the @c ZydisInstructionDecoder instance.
/
const ZydisDecoder decoder;

How to use zydis as an external dependency in a CMake project?

What's the cleanest way to build a hello world program that links to zydis using CMake?

Since zydis doesn't seem to offer the typical Find* routines, I had to manually add the include directory and the built static library as a dependency. However, when doing so, I get a compiler error saying that ZydisExportConfig.h couldn't be found. Turns out, this file is generated and put into the root directory of the build directory. In the meantime I can work around this by manually adding above file as a CMake variable, but it seems hack-ish? What would be the preferred way to make this scenario work?

Thanks!

ZydisDecodedInstruction operandCount

Calling ZydisDecodedInstruction on for example: 4C 8B DC 53 41 56 41 57 48 81 EC C0 00 00 00

or equivalent to:

code.dll+139BF0 - 4C 8B DC - mov r11,rsp
code.dll+139BF3 - 53 - push rbx
code.dll+139BF4 - 41 56 - push r14
code.dll+139BF6 - 41 57 - push r15
code.dll+139BF8 - 48 81 EC C0000000 - sub rsp,000000C0

provides wrong operandCount. Decoding 53 (push rbx), ZydisDecodedInstruction gives an operandCount of 3, being the first rbx.

What am I doing wrong? Shouldn't be 1?

Thanks

fatal error: 'ZydisExportConfig.h' file not found

Hi,

The build went well on OSX High Sierra, when trying to compile one of the examples iv'e noticed that
the install creates additional "include" under:

"/usr/local/include/".

When copying "Zydis" headers under "/usr/local/include" manually it fails with ZydisExportConfig.h

fatal error: 'ZydisExportConfig.h' file not found, did you ever encountered such an issue ?

That indeed fixed the problem, the next issue is:

When trying to compile one of your example, please see bellow:

Cheers,

/usr/local/include/Zydis/Defines.h:35:10: fatal error: 'ZydisExportConfig.h' file not found
#include <ZydisExportConfig.h>
^~~~~~~~~~~~~~~~~~~~~
1 error generated.