Antinomie and other sandboxes

Dynamic analysis tools differ mainly in where the observer sits. That one choice decides what a tool can see, what a sample can do about it, and what it costs to run. This page compares the approaches, with well-known open-source tools as examples. It is a design comparison, not a benchmark: the other tools’ details are their own, so check their documentation for the version you use.

Four places to observe from

Approach	Observer	Examples
Agent in the guest	An agent process in the VM starts the sample and injects a monitor that hooks library or API calls in the sample’s process	Cuckoo Sandbox, CAPEv2
Hypervisor introspection (VMI)	The hypervisor reads and traps the guest’s memory and execution from outside the VM	DRAKVUF (on Xen)
Emulation	The sample runs in a CPU emulator that implements the operating system’s interface itself	Qiling (on Unicorn)
Kernel recorder in the guest	The guest’s own kernel, patched to record every system call and its data	Antinomie

What each approach sees and misses

Agent and API hooks

A monitor inside the sample’s process sees calls at the level of libraries and APIs, with their meaning attached (a registry write, a crypto call), which is rich for Windows malware where much behaviour goes through documented APIs. The trade-offs follow from living in the sample’s address space and next to an agent process: a program that makes system calls directly, or removes or detects the hooks, can step around them, and the agent, the injected code and the hooks are artefacts a sample can look for. Cuckoo and CAPEv2 are built around Windows guests; check their documentation for the state of their Linux support.

Hypervisor introspection

Observing from the hypervisor leaves no agent in the guest, and the guest kernel cannot easily tamper with an observer that is outside it. The cost is the semantic gap: the observer has to rebuild processes, files and arguments from raw guest memory, which needs knowledge of the guest kernel’s layout, and trapping execution from outside adds overhead. DRAKVUF runs on the Xen hypervisor rather than a stock desktop setup.

Emulation

An emulator controls every instruction, can run code for many architectures on one host, and can hook anything without a VM. It sees only as much of the operating system as the emulator implements: an unimplemented system call or an emulation difference changes the sample’s behaviour or tells it where it is, and it does not run a whole guest system with its services and network stack. It suits code snippets, shellcode and firmware for other architectures.

Kernel recorder in the guest (Antinomie)

Every system call of the traced programs passes through the recorder, whether it came through libc, a static binary, a Go runtime or a raw syscall instruction, so nothing at user level can step around it, and its arguments and data are recorded by the kernel that serves them. No agent process, injected code or ptrace exists in the guest, and the debugger works without ptrace too. The guest is a real Linux system under QEMU and KVM, with real services and a real network stack, and packets are captured outside it.

What it misses follows from the same design:

Work that makes no system call is invisible: computation, CPUID and RDTSC checks, and stores to memory (writes through shared file mappings are caught when the kernel writes them back, from a revision-18 base).
Guest root or a guest kernel exploit puts the sample at the recorder’s level: it can stop, blind or falsify what that guest reports. A hypervisor-level observer is better placed against that.
The kernel is the project’s own build. Stealth profiles hide much of what gives a VM or the recorder away, but not everything; the app lists what remains visible for each profile.
Linux x86-64 guests only. It does not analyse Windows programs.

When to use which

Your question	A good fit
What does this Windows executable do, through its API calls?	An agent-based sandbox such as CAPEv2
What does this Linux ELF, script or dropper do on a real Linux system, down to every system call, file write and packet?	Antinomie
The sample may own the guest kernel, and you need an observer it cannot reach from inside	Hypervisor introspection such as DRAKVUF
A snippet, shellcode or firmware for ARM, MIPS or another architecture, without a VM	An emulator such as Qiling

The approaches complement each other. A sample that detects one environment may behave in another, and the same sample seen through API hooks and through system calls gives two views of one behaviour.