Sogen: A Windows and Linux Userspace Emulator with Real System DLL Support

What Sogen Does and Who It Is For

Running a Windows binary outside of Windows typically involves either a compatibility layer like Wine, which reimplements the Windows API from scratch, or a full virtual machine that boots an actual Windows installation. Sogen takes a different approach: it emulates at the CPU and syscall level and loads the real Windows system DLLs (ntdll, kernel32, user32) instead of reimplementing their behavior.

The result is that program behavior closely matches real Windows execution without requiring a full Windows installation. Every instruction, memory access, and API call can be hooked, intercepted, or rewritten at the emulator level. Execution is fully deterministic: given the same binary and inputs, every run produces the same instruction trace. The entire emulator state can be snapshotted and restored.

Sogen targets security researchers who need to analyze malware or obfuscated code in a controlled environment, developers who need to run Windows binaries on Linux or macOS, and game modders who want to instrument game binaries. The last push was on 2026-09-22. The license is GPL-2.0.

CPU Backends and Platform Support

Sogen supports five CPU backends, selectable at build time. Unicorn Engine provides software emulation of x86-64 and ARM64 instruction sets. icicle-emu is an alternative software emulation backend. Hyper-V (WHP) uses Windows Hypervisor Platform to execute code natively on the CPU under Windows, which is significantly faster than software emulation for CPU-bound workloads. KVM provides equivalent native execution on Linux. FEX is a fifth option.

The choice of backend matters for performance. The Hyper-V backend runs code natively on the host CPU, which is why the README states it is fast enough for games. The software backends (Unicorn, icicle-emu) are slower but work on any platform. GPU paravirtualization bridges Direct3D calls from the emulated program to the host GPU, with Direct3D 8 through 11 titles running through DXVK, which translates Direct3D to Vulkan on top of the GPU bridge.

Sogen runs on Windows, Linux, macOS, Android, iOS, and in the browser, on both x86-64 and arm64 host architectures.

Installing and Using the Python Bindings

Python bindings for Sogen are available on PyPI:

pip install sogen

The Python bindings require an emulation root: a directory containing the real Windows system DLLs and supporting files. A ready-made root is downloadable from sogen.dev/root.zip. The wiki at github.com/momo5502/sogen/wiki documents how to create one from a Windows installation.

Here is the example from the README that runs a Windows binary and hooks its entry point:

import sogen

emu = sogen.windows.create_application("c:/test-sample.exe", emulation_root="./root")

def on_module_load(module):
    if module.name.lower() == "test-sample.exe":
        emu.hooks.memory_execution_at(module.entry_point, lambda address: print(f"hit entry point: 0x{address:x}"))

emu.callbacks.on_module_load = on_module_load
emu.start()
print(emu.process.exit_status)

This code creates an emulated Windows application, registers a callback that fires on each module load, and hooks the entry point of the target binary. The hook is a Python lambda that receives the address when execution reaches that point. The emulator state is controlled from Python through the emu object.

Building Sogen from Source on Windows

For the full C++ build on Windows with Visual Studio, clone the repository with submodules:

git clone --recurse-submodules https://github.com/momo5502/sogen.git

Generate the Visual Studio solution:

cmake --preset=vs2022

Build the solution at build/vs2022/sogen.sln using Visual Studio. Create a registry dump by running src/tools/grab-registry.bat as administrator and place it in the artifacts folder next to analyzer.exe. Then run a target binary:

analyzer.exe C:\example.exe

The README notes that more detail on building and running on Windows, Linux, and macOS is in the project Wiki. The build system uses CMake presets defined in CMakePresets.json at the repository root.

Hooking, Snapshotting, and Deterministic Execution

Sogen's key capability is the ability to observe and modify execution at any level. Memory execution hooks fire when the emulator reaches a specific address, as shown in the Python example. Additional hook types cover memory reads, memory writes, syscall entry and exit, and API call entry and return. All of these can both observe and modify the values being read or written.

Snapshot and restore works at the full emulator state level, including register file, memory, and loaded DLL state. This enables workflows like: run to a specific point, take a snapshot, try one modification, restore, try another. In-memory snapshots are described as fast; full state serialization to disk is also supported, as is loading a minidump as an initial emulator state.

Determinism means that re-running the same binary with the same inputs produces exactly the same instruction trace. This property is valuable for differential analysis: run the same binary twice with a tiny input change and compare the traces to find divergence points.

Undetectable Debugging and GUI Application Support

Sogen exposes a GDB protocol server, allowing debuggers like IDA Pro and GDB to connect to the running emulator over the standard debugging protocol. Because the debugger connects to the emulator rather than to the process itself, it is invisible to anti-debugging checks inside the emulated binary. The README describes this as undetectable debugging from the perspective of the running code.

An in-browser debugger is also included, accessible through the sogen.dev interface. This allows basic debugging without installing a local debugger.

Native GUI applications run with working windows, dialogs, and controls because Sogen emulates the Win32 windowing subsystem through the real user32 DLL. Combined with GPU paravirtualization for Direct3D, this is how games can run through Sogen using the Hyper-V backend. The Dart bindings project (Wdestroier/sogen_dart) provides an unofficial third-party integration for Dart.

Limitations and Comparison with Wine

Sogen is a userspace emulator, not a kernel emulator. It emulates the Windows userspace environment by loading real DLLs, but it does not emulate Windows kernel internals or drivers. Binaries that rely on kernel drivers, kernel modules, or low-level Windows internals beyond what is exposed through the emulated DLL layer will not work.

The emulation root requirement is a practical barrier for new users. The ready-made root from sogen.dev is a convenient starting point, but it is a specific snapshot of a Windows system's DLL set. Binaries that require specific DLL versions or configurations not covered by that snapshot may behave differently than on a real Windows installation.

Wine is the most comparable alternative. Wine reimplements the Windows API from scratch without requiring real Windows DLLs. This means Wine's behavior is only as accurate as its API reimplementation, and obscure API behaviors may differ from real Windows. Sogen's use of real DLLs gives it higher fidelity for those edge cases, but at the cost of requiring a Windows DLL set to be available. Sogen's GPL-2.0 license and Wine's LGPL license have different implications for inclusion in proprietary software.

Editorial conclusion

Sogen is the right tool for security researchers, game modders, and platform engineers who need to run Windows binaries outside Windows with full instruction-level observability, deterministic replay, and the ability to hook or rewrite any memory access or API call. It is not a hypervisor or a compatibility layer for running production Windows workloads; it is a research and analysis tool under GPL-2.0. Before using it, obtain the emulation root (a directory of real system DLLs) from sogen.dev or build one yourself, since the emulator will not function without it.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. momo5502/sogen on GitHub
4. Project website
5. README