Skip to main content

State Management

Sogen provides comprehensive state management capabilities, allowing you to save complete emulator state to disk and restore it later, or create fast in-memory snapshots for rapid state restoration.

Overview

Sogen supports two types of state management:
  1. Full Serialization: Complete emulator state saved to disk in a compressed format
  2. In-Memory Snapshots: Fast snapshots for rapid state restoration (used by the fuzzer)
Both approaches capture the entire state of the Windows emulator including:
  • CPU registers and flags
  • Memory contents (all committed regions)
  • Loaded modules and their state
  • Thread contexts
  • File handles and I/O state
  • Registry state

Snapshot Files

Creating Snapshots

Create a snapshot of the current emulator state:

Snapshot File Format

Snapshots use a custom binary format with compression:
The file structure:
  1. 8-byte header (magic + version)
  2. ZSTD-compressed emulator state

Creating Snapshots

The create_emulator_snapshot() function serializes and compresses state:

Writing to Disk

Snapshots are automatically named with timestamp:
Example filenames:
  • notepad-1701234567.snap
  • malware-1701234890.snap

Loading Snapshots

From File

Load a snapshot from disk:

From Memory

Load from a buffer:

Implementation

Compression

ZSTD Compression

Snapshots use ZSTD compression for optimal size/speed ratio:
Decompression:
ZSTD provides:
  • Fast compression/decompression
  • High compression ratio (typically 70-90% size reduction)
  • Deterministic output

Validation

Header Validation

Snapshots are validated before loading:
This prevents:
  • Loading corrupt files
  • Loading incompatible snapshot versions
  • Loading non-snapshot files

Serialization Interface

Emulator Serialization

The windows_emulator class implements serialization:
These methods save/restore:
  • All CPU state (registers, flags)
  • Memory manager state
  • Module manager (loaded DLLs, exports, imports)
  • Process context (threads, handles)
  • File system state
  • Registry modifications
  • Network socket state

Application Settings

Application configuration is also serialized:

In-Memory Snapshots

Fast Snapshot API

For performance-critical scenarios (like fuzzing), use in-memory snapshots:
These provide:
  • Extremely fast save/restore (microseconds vs milliseconds)
  • No disk I/O
  • Perfect for repeated state restoration

Fuzzing Use Case

The fuzzer uses in-memory snapshots for performance:
For each fuzzing iteration:
  1. Restore snapshot (microseconds)
  2. Inject new input
  3. Run emulation
  4. Repeat
This is much faster than full deserialization for each iteration.

Use Cases

1. Malware Analysis

Save state before detonating malware:

2. Debugging

Save state at interesting points:

3. Testing

Test different code paths from same starting point:

4. Fuzzing

The fuzzer uses snapshots for performance:

Performance Considerations

Snapshot Size

Snapshot size depends on:
  • Number of loaded modules
  • Amount of committed memory
  • Thread count
  • Open handles
Typical sizes:
  • Simple executable: 1-5 MB compressed
  • Complex application: 10-50 MB compressed
  • Game/large app: 100+ MB compressed

Compression Ratio

ZSTD typically achieves 70-90% compression:
  • 100 MB uncompressed → 10-30 MB compressed
  • Memory contains many zeros (uncommitted pages are excluded)
  • Code sections compress very well

Save/Restore Time

Full serialization (disk):
  • Save: 10-100ms depending on size
  • Load: 10-100ms depending on size
  • Dominated by compression and I/O
In-memory snapshots:
  • Save: <1ms (memory copy)
  • Restore: <1ms (memory copy)
  • Perfect for tight loops

Best Practices

1. Snapshot Naming

Use descriptive names:

2. Verify Snapshots

Check that snapshots load correctly:

3. Clean Up Old Snapshots

Snapshots can consume significant disk space:

4. Use In-Memory for Hot Paths

If repeatedly restoring state:

Troubleshooting

”Snapshot is too small”

File is corrupt or truncated. Ensure:
  • Full write completed before reading
  • File wasn’t modified externally

”Invalid snapshot”

File doesn’t have the correct magic bytes. Ensure:
  • File is actually a Sogen snapshot
  • File wasn’t corrupted

”Unsupported snapshot version”

Snapshot was created with a different version of Sogen. Snapshots are not backward/forward compatible across versions. Solution: Recreate snapshot with current Sogen version.

Large Snapshot Files

If snapshots are unexpectedly large:
  • Application may have allocated significant memory
  • Check for memory leaks in target application
  • Consider snapshotting earlier in execution

Source Code Reference

Key files:
  • src/analyzer/snapshot.hpp - Public snapshot API
  • src/analyzer/snapshot.cpp - Snapshot implementation
  • src/windows-emulator/windows_emulator.hpp - Serialization interface (lines 166-170)

Next Steps