# Zydis: an x86/x86-64 disassembler and code generator for C projects

> Zydis is a C11 disassembler and encoder for x86 and x86-64 with no dynamic allocation and no third-party dependencies, including libc. It suits projects that need to decode or emit machine code inside a process they do not control, and it is a poor fit for anything that needs a documented stable ABI across minor releases.

**zyantific/zydis** — Fast and lightweight x86/x86-64 disassembler and code generation library

- Repository: https://github.com/zyantific/zydis
- Website: https://zydis.re
- Stars: 4,379 · Forks: 513
- Language: C
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/zyantific-zydis

## The problem Zydis solves, and who is asking

Decoding x86 is not a parsing exercise. Prefixes stack, the ModRM and SIB bytes change operand meaning, and the instruction set keeps growing with extensions. Zydis exists so that a program can turn a byte buffer into structured instruction data without writing that decoder itself. The README lists the intended audience indirectly: the projects it names as users are x64dbg, Mozilla Firefox and WebKit, all of which need to read or emit machine code inside a larger runtime. That is the shape of the problem. You have bytes at an address, you want to know what they mean and how long they are, and you want that answer inside a hot loop or inside kernel code where allocation is not available. A standalone disassembler binary, the kind you run from a shell on an object file, solves a different problem and is not what this library is for.

## How the decoder, encoder and formatter fit together

The library is split into three cooperating pieces. The decoder consumes a buffer plus a runtime address and produces a decoded instruction; the encoder goes the other way, taking a requested instruction and writing bytes; the formatter turns a decoded instruction into text. The README's disassembler example prints an address column and a mnemonic column, which is the formatter's output, not the decoder's. That separation matters in practice, because you can decode without formatting, which is what a JIT or a sandbox would do, and you can format without ever touching the encoder. The encoder is a separate capability, not a side effect of decoding: the EncodeMov example emits the bytes 48 C7 C0 37 13 00 00 for a move, which is a real encoding decision, not a round trip through a disassembly string. The features list states there is no dynamic memory allocation, no third-party dependency at all, and that the code is thread-safe by design. Those three claims are the architecture. A decoder that never calls malloc can be used in kernel mode and in UEFI, and the README says exactly that: tested on Windows, macOS, FreeBSD, Linux and UEFI, in both user and kernel mode.

## Installing Zydis and disassembling your first buffer

There are three routes. If you are on a distribution with a package, the README's table gives the command directly. On Debian or Ubuntu the package pair is libzydis-dev and zydis-tools; on Arch it is pacman -S zydis; on macOS it is brew install zydis; vcpkg users run vcpkg install zydis. If you want to build from source, the README uses CMake and the repository ships a Makefile wrapper whose configure target runs cmake with tests enabled:

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

The --recursive flag is not optional. The Makefile has an explicit target for dependencies/zycore/CMakeLists.txt that runs git submodule update --init --recursive, and it fails with an error message if git is missing, telling you to place the dependencies manually. Zycore is the submodule; a plain clone without it will not configure.

If you cannot or will not add a build dependency, the amalgamated distribution is the alternative. The README describes it as an auto-generated single header and single source file, published on the release page as zydis-amalgamated.tar.gz and generated by assets/amalgamate.py. Copying two files into your project is the whole integration. For a first real use, the simplest path is the ZydisInfo command-line tool, which the README says can inspect essentially all information Zydis provides about an instruction. The examples directory holds DisassembleSimple.c, and the README shows its output as an address column followed by mnemonics such as push rcx and lea eax, [rbp-0x01]. Build the examples with the CMake build and run that binary against your own bytes before writing any integration code; it tells you whether the decode you expect is the decode you get.

## The ABI boundary is the sharpest limitation

The README's versioning section is unusually blunt. Semantic versioning applies, but the stability guarantee covers the API only, and ABI stability is provided only between patch versions. That means 4.1.0 to 4.1.1 is safe to swap as a shared library, while 4.1.1 to 4.2.0 is not, even though both are minor releases under semver. If you ship a shared object and something else links against it, you have to pin the exact minor version or rebuild both sides together. This is a real constraint for distributions and for plugin hosts. The second constraint is the branch policy. The README states that master holds the bleeding edge of the next unreleased version, that increased amounts of bugs and issues must be expected, and that API stability is not guaranteed outside tagged commits. Anyone building from a git checkout of master is opting into that. The third is scope: this is x86 and x86-64 only. If your target is ARM64, RISC-V or a bytecode format, nothing here applies. And the language bindings are a short list, Rust and Python 3, both described as official. If your host language is not on that list, you are writing FFI yourself.

## Zydis versus Capstone, and versus a full assembler front-end

The natural comparison is Capstone, the other widely used disassembly library in this space. The difference in approach shows up in the dependency and allocation story. Zydis states it has absolutely no third party dependencies, not even libc, and performs no dynamic memory allocation. Capstone's design is built around a handle-based API with a richer set of supported architectures, which is a different trade: broader target coverage in exchange for a runtime that allocates and links against a C library. If you need to disassemble ARM and x86 in the same binary, Zydis is the wrong tool and Capstone is the obvious one. If you need to decode inside a kernel, a UEFI application or a process where allocation is forbidden, Zydis is the one whose README makes that claim explicitly. There is also a second comparison inside the Zydis ecosystem rather than outside it. The README points to zasm as an asmjit-style assembler front-end for the encoder, and describes it as also providing an idiomatic C++ wrapper around the decoder and formatter. So if you want to write assembly-like code in C++ rather than construct instruction structs by hand, zasm is the layer above this library, not a competitor to it. Choosing between them is choosing how much of the instruction construction you want to do yourself.

## Licence, maintenance and what an upgrade actually costs

The licence is MIT, per the repository and the badge in the README. That is permissive and imposes no source disclosure on your own code; the usual obligation is preserving the copyright and permission notice, and this is a description of the licence text, not legal advice. The practical upgrade cost follows from the versioning rules rather than the licence. Patch upgrades are the cheap ones. Minor upgrades can break the ABI, so a shared-library consumer has to rebuild. Major upgrades are the ones that break the API, and the release history shows how far apart they are: v4.0.0 landed in November 2022, v4.1.0 in February 2024, v4.1.1 in February 2025. That is a slow cadence, which cuts both ways. You will not be chasing churn, and you will not get frequent fixes either. The repository was last pushed on 2026-07-27, so it is not dormant, but the gap between the most recent tagged release and the most recent commit means master and the release are not the same thing. The amalgamated distribution adds one more cost to track: it is regenerated by assets/amalgamate.py, so if you vendor the two files, you own refreshing them yourself.

## Conclusion

Adopt Zydis if you are writing a debugger, a JIT, a profiler or a sandbox in C or C++ and you want decoding that does not call malloc and does not drag in libc. Skip it if you need a stable ABI across minor versions, or if you are working in a language whose official binding does not exist yet. Before you commit, read include/Zydis/Generated/EnumISAExt.h to confirm the instruction extensions you care about are covered, and check whether you are building from master or from a tag, because master is explicitly documented as unstable.

## FAQ

### How do I install Zydis on Debian or Ubuntu?

The README's package table gives apt-get install libzydis-dev zydis-tools for both Debian and Ubuntu. The first package provides the headers and library, the second the command-line tools.

### How do I use Zydis to disassemble a buffer?

The README's disassembler example decodes a memory buffer and prints an address column followed by mnemonics. The full source is in examples/DisassembleSimple.c, and the ZydisInfo tool can inspect the same information from the command line.

### What is Zydis used for?

It is an x86 and x86-64 disassembler and code generation library. The README names x64dbg, Mozilla Firefox and WebKit as projects that use it.

## Sources

- [License: MIT](https://github.com/zyantific/zydis/blob/master/LICENSE)
- [Project website](https://zydis.re)
- [README](https://github.com/zyantific/zydis/blob/master/README.md)
- [Releases](https://github.com/zyantific/zydis/releases)
- [zyantific/zydis on GitHub](https://github.com/zyantific/zydis)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zyantific-zydis
