Zydis reads x86 without malloc and without libc

No malloc and no libc, which is the whole design

Zydis is a decoder library, not a tool that prints listings. That distinction shows up in how the project is built. There is no dynamic memory allocation anywhere in the library, and no third-party dependencies, not even libc. It should compile anywhere a working C11 compiler exists.

The audience that cares about those two facts is not hobbyists. Debuggers, browser engines and kernel-mode code need to decode instructions in places where a heap allocator is either absent or a bug waiting to happen. The README names x64dbg, Mozilla Firefox and WebKit among the open-source projects that embed it. Each of those has a good reason to want a decoder that hands back a struct and leaves every allocation to the caller.

Thread safety by design is the third constraint that follows from the same place. The README lists it as thread-safe by design.

The README also lists a very small file-size overhead compared to other common disassembler libraries, alongside support for all x86 and x86-64 instructions and extensions.

From bytes to a decoded form, formatted on demand

Decoding produces structured data. The example program in the repository takes a memory buffer, walks it instruction by instruction and prints each result. The output the README shows is a listing, but that listing is a rendering of what the decoder returned, not the decoder's only product:

48 C7 C0 37 13 00 00

That block is what the encoder example prints, the byte sequence for a single move instruction. One side of the library turns bytes into structure, the other turns a requested instruction into bytes, and the formatter sits between them. The repository carries several Formatter examples and a RewriteCode example, which is the case that matters when you are rewriting machine code rather than reading it.

This split is why a debugger can change how an instruction is rendered without re-decoding, and why a patcher can emit a new encoding without knowing anything about text output. The ZydisInfo command-line tool exists to inspect what the library knows about an instruction, which is the fastest way to see the actual shape of the decoded form.

If you need the fields rather than the text, this is the part of the library worth studying before you commit. If you only need a listing, the split buys you nothing.

The amalgamated build sidesteps submodules entirely

There are several ways to get Zydis onto a machine, and they have different costs. The CMake route is the full one, for Windows, macOS, Linux and the BSDs:

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

Note the recursive flag. The repository Makefile makes the reason explicit: its configure target depends on dependencies/zycore/CMakeLists.txt, and that path is produced by git submodule update --init --recursive. Without the submodules present, the Makefile runs git submodule update --init --recursive, and only if git is missing does it stop with an error telling you to install git or to place all dependencies in their respective paths by hand. A plain tarball of the source tree is therefore not a build tree.

The amalgamated distribution avoids all of it. The published archive zydis-amalgamated.tar.gz carries a single header and a single source file generated by assets/amalgamate.py. Copy those two files into a project and the build system question disappears. That is the shortest path to a first decode, and for embedding inside another codebase it is often the only path worth taking.

Package repositories split the library from the tools

Pre-built headers, shared libraries and executables are published through several package managers, and the packages are not interchangeable. Some split the development library from the command-line tools:

apt-get install libzydis-dev zydis-tools

That split matters when you script a build. Installing only the library package gives you headers and the shared object, without ZydisInfo. Other repositories fold everything into one name:

pacman -S zydis

brew install zydis

vcpkg install zydis

nix-shell -p zydis

On Windows, a hand-maintained Visual Studio 2022 project is kept alongside the CMake logic, and CMake can also be asked to generate a Visual Studio project for other versions. The README does not say which branch any of these package builds was cut from, so if you are pinning a version for a reproducible build, verify the package contents against the branch you intend to build from.

Bindings exist for Rust and Python 3, maintained in separate repositories, which matters if the host language of your tool is not C.

The decoded struct is the API you have to re-audit

The guarantees are narrow, and they are stated as narrow. Stability covers the API, and ABI stability holds only between patch-level updates. Anything that crosses a minor or major boundary in your own binary is on you.

The branch layout is where a reader who skims will get hurt. master holds the bleeding-edge code of the next, not-yet-tagged version, with more bugs expected and no API stability outside tagged commits. maintenance/v4 carries the current v4 code and receives feature updates. maintenance/v3 receives no feature updates and its security updates end in 2025. maintenance/v2 is past end of life and gets nothing further.

The distance between those branches is wider than the names imply. The last push landed on 2026-11-02, while the newest tag is v4.1.1 from 2025-02-16. A fresh clone is therefore not what a distributor shipped, and a distribution package is not what master contains. Pick the branch deliberately rather than accepting the default.

Zydis is the decoder; zasm is the assembler front-end

The repository includes encoder examples such as examples/EncodeFromScratch.c, and the README points elsewhere for a front-end: if you want an asmjit-style assembler front-end for the encoder, the answer is zasm, which also ships an idiomatic C++ wrapper around the decoder and formatter interface.

That is the real difference in approach. Zydis exposes a low-level C surface where the caller supplies memory, chooses the machine mode and reads decoded fields out of a filled structure. zasm wraps that surface in a C++ layer shaped like an assembler. If you are writing a patcher or a code generator and care about the instruction you emit, that layering matters more than raw speed.

An API-stable library that still costs you at every major bump

The failure mode here is not a bug, it is an upgrade. Because ABI stability covers patch versions only, an upgrade from v4 to the next major version means recompiling every consumer and re-auditing code that pokes at the decoded struct. Projects that embed Zydis across a version boundary carry that cost on a schedule they do not control.

Check the support status of the specific branch you pin: v2 is end-of-life, while the README lists security support for v3 through 2025.

Two further limits are worth stating. The library covers x86 and x86-64 and their extensions through generated tables, but the project offers no non-x86 path, so an architecture-portable tool cannot lean on it. And with no dynamic allocation, memory for output is the caller's to supply; a caller who wants to keep many decoded instructions alive has to own that storage explicitly, which is a feature in a debugger and an inconvenience in a batch tool.

Editorial conclusion

Adopt Zydis when your tool needs machine-readable instruction data inside a kernel, a loader, a browser engine or any other allocation-sensitive host, and when you can live with owning the memory for decoded output yourself. Skip it when your architecture is not x86. If you are emitting instructions rather than reading them, compare the C encoder surface with zasm before committing. Verify first which branch you actually compile, because master and the maintenance branches do not come with the same update guarantees.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. zyantific/zydis on GitHub