PANDA: record, replay and analyse whole-system execution across CPU architectures

What PANDA solves, and who ends up using it

A debugger sees one process. A hypervisor sees a machine. PANDA is built on the QEMU whole system emulator, so an analysis has access to all code executing in the guest and all data, as the README puts it. That is the problem it addresses: observing a full system, including the kernel, drivers and firmware paths that a process-level tool never reaches.

The second problem is repetition. PANDA records an execution and replays it, and the README states that replay log files are compact and shareable, which makes experiments repeatable. The example given is a nine billion instruction boot of FreeBSD represented by only a few hundred MB. If you have ever tried to reproduce a race that only fires on one machine, that number is the point of the project.

The audience follows from that. Reverse engineers working on firmware or embedded images, malware analysts who need the kernel in view, and academic groups publishing traces alongside a paper. The README says development happens with MIT Lincoln Laboratory, NYU and Northeastern University, which tells you the centre of gravity is research rather than a commercial product team.

QEMU, TCG, LLVM IR and the plugin architecture

PANDA is a QEMU fork, and the repository layout makes that plain: cpu-exec.c, cputlb.c, exec.c, block/, chardev/ and a configure script sit at the top level, alongside a Makefile whose header still reads "Makefile for QEMU" and which defines BUILD_DIR, SRC_PATH and config-host.mak in the usual QEMU way. The default branch is dev, and there is a stable branch for versioned releases. The README recommends stable if you plan to fork and later pull updates.

The mechanism that makes analyses portable is the translation layer. PANDA uses the LLVM architecture from the S2E project to translate the TCG intermediate representation that QEMU produces into LLVM IR. TCG is architecture-specific; LLVM IR is not. The README states that QEMU supports thirteen CPU architectures and that this design lets a single dynamic taint analysis support many CPUs precisely. The taint2 plugin is the example given, and the S2E files behind it have been updated for LLVM 14.

On top of that sits a plugin architecture with a mechanism for sharing functionality between plugins. The stated goal is code re-use and simpler development of complex analyses. In practice this means an analysis is a plugin, and a plugin can call into another rather than duplicating its bookkeeping. That is a real design commitment, and it is why the project can ship one taint implementation instead of one per target.

PyPANDA is the Python side. The README describes it as the Python interface to PANDA, installable on its own, and the Docker image named panda ships PANDA and PyPANDA together with runtime dependencies. For most analysis work, the Python layer is where you will actually live.

Installing PANDA with Docker and running a first guest

Docker is the shortest path and the README presents it as the quickstart. The panda container has PANDA and PyPANDA plus runtime dependencies, and deliberately omits build artifacts and source to keep the image small. Pull it and ask a binary for help:

docker pull pandare/panda
docker run --rm pandare/panda panda-system-i386 --help

You should get the QEMU-style option listing for the i386 system emulator. To build the same target from a checkout instead, the README gives this pair:

DOCKER_BUILDKIT=1 docker build --target=panda -t panda .
docker run --rm panda panda-system-i386 --help

If you intend to modify PANDA itself, use the developer container, which carries the source and build artifacts under /panda:

docker pull pandare/pandadev
docker run --rm pandare/pandadev /panda/build/panda-system-i386 --help

For Python-only work, pip is enough. The README says pip3 install pandare installs everything needed for python-based analyses, but not stand-alone PANDA binaries:

pip3 install pandare

Once a binary is on your PATH, running a guest looks like QEMU. The README's own example boots an image with 2G of memory and a monitor on stdio:

panda-system-i386 -m 2G -hda guest.img -monitor stdio

The distributed binaries are only tested on 64-bit Ubuntu 22.04, so treat other platforms as untested. Debian and Ubuntu users can also install from the debian packages attached to the releases, and the build steps are encoded in install_ubuntu.sh. Arch has a contributed install_arch.sh, tested only on Arch Linux 4.17.5-1-MANJARO. macOS has install_osx.sh, which uses homebrew, and the README warns that homebrew deprecates old packages quickly, so expect it to break.

Where PANDA is the wrong tool

The LLVM path has a hard dependency. If you want the LLVM features, mainly the dynamic taint system, you need LLVM 14 from OS packages or built from source. On Ubuntu install_ubuntu.sh handles it, but on anything else you are arranging that yourself. Without it, taint2 is not available and a large part of the project's value is out of reach.

Record and replay is the other soft spot. The README's limitations section begins a discussion of cross-architecture record/replay and states that great effort is put into keeping the PANDA trace format stable. A format that requires effort to keep stable is a format that has changed, and the section is where you should look before assuming a trace recorded by one version will replay under another. The documentation does not promise that it will.

Building is also not portable in the way the architecture-neutral pitch might suggest. The README vouches for buildability only on the latest Debian stable and Ubuntu LTS, and welcomes pull requests for other distributions. The macOS script is described as less well-tested and expected to break. If your team runs Fedora or Alpine, you are translating apt-get lines yourself.

Finally, 32-bit builds. The README strongly recommends building PANDA only as a 64-bit binary and says a 32-bit build should be possible but is best avoided. If your environment forces 32-bit, this is not your tool.

PANDA against plain QEMU and against userland tracers

The obvious alternative is upstream QEMU. QEMU gives you the same emulation and the same guest visibility, and PANDA inherits that. The difference is what has been added on top: record and replay with shareable logs, the TCG-to-LLVM IR translation that makes a single analysis work across targets, and a plugin architecture with inter-plugin sharing. If you only need to boot an image, upstream QEMU is smaller, better packaged and does not carry the LLVM 14 requirement. If you need to replay an execution deterministically or instrument every basic block through LLVM IR, you are in PANDA's territory.

Against userland dynamic tracers, the difference is scope rather than features. A tracer attached to a process sees syscalls and library calls; PANDA sees the guest kernel and everything below the process boundary, because it is emulating the machine. That also means PANDA is heavier. You are booting an operating system, not launching a binary, and the trace is a whole-system artifact.

The trade-off is honest: PANDA buys coverage and reproducibility at the cost of build complexity, a Linux-first support matrix, and a trace format you should version alongside your replays.

Maintenance, releases and the GPLv2 question

The repository is not archived, and the last push was on 2026-09-24. Releases are frequent and versioned: v1.8.85 and v1.8.84 both landed on 2026-06-09, and v1.8.83 on 2026-02-03, all tagged on the dev branch. The dev branch is where resources such as docker containers and documentation are based, while stable carries versioned releases. That split matters for upgrades: pulling from dev means tracking a moving target, and the README explicitly suggests stable if you intend to fork and later pull in updates.

Upgrade cost is dominated by two things. First, the trace format, discussed above. Second, the LLVM version, currently pinned at 14. Neither is something you can absorb silently in a dependency bump.

On licensing, the README states PANDA is released under the GPLv2 license, and the repository carries LICENSE, COPYING and COPYING.LIB files. QEMU-derived codebases commonly mix GPLv2 and LGPL components, and the presence of COPYING.LIB alongside COPYING is consistent with that. Which terms attach to a given file is a question for the file headers and for your own counsel; this is not legal advice, and the distinction matters if you plan to ship PANDA inside a proprietary product rather than use it internally for analysis.

Editorial conclusion

Adopt PANDA if you need whole-system record and replay across several CPU architectures, or if you want to write analyses against a Python interface rather than patching QEMU. Do not adopt it for single-process userland tracing, for a 32-bit build, or if you are not prepared to work on Ubuntu 22.04 or Debian stable. Before committing, verify that the debian package for your release exists, that LLVM 14 is available if you intend to use taint2, and that the trace format of the version you pick is the one your existing replays were recorded with.

Frequently asked questions

Official sources

1. Issues
2. panda-re/panda on GitHub
3. Project website
4. README
5. Releases