Working with Wine

• Working with Wine
  • Important: Wine Is Not a Sandbox
  • Installation
  • Wine Prefixes
  • Basic Usage
    • wine64 is gone, and so is WINEARCH=win32
  • Winetricks
  • Observing Behavior Under Wine
    • System Call Tracing
    • Network Capture
    • Filesystem Monitoring
    • Registry Changes
  • Limitations for Malware Analysis
  • Useful Wine Environment Variables
  • Further Reading

Wine (Wine Is Not an Emulator) is a compatibility layer that translates Windows API calls into POSIX system calls, allowing Windows executables to run on Linux without a Windows installation. For malware analysis on REMnux, Wine lets you execute and observe Windows PE samples without needing a separate Windows VM.

Important: Wine Is Not a Sandbox

Wine provides no isolation. Malware running under Wine can read and write your home directory, make network connections, and in some cases escape to the host system entirely. Always run Wine inside your REMnux VM (not on your host machine), and take a snapshot before executing any sample.

Never run malware under Wine without:

1. A clean VM snapshot to revert to
2. The network adapter disabled or isolated
3. A dedicated Wine prefix (see below) to contain registry and filesystem changes

Installation

REMnux may already include Wine. Check first:

$ wine --version

If not installed, add it:

$ sudo dpkg --add-architecture i386
$ sudo apt update
$ sudo apt install wine wine32 wine64 winetricks

The i386 architecture is required because most Windows malware targets 32-bit x86.

On an Apple Silicon Mac this is the detail that decides your setup: wine32:i386 installs cleanly under Rosetta but cannot execute, so 32-bit samples need a fully emulated x86-64 guest. See Running x86-64 Linux on Apple Silicon.

Wine Prefixes

A Wine prefix is an isolated directory that acts as a fake Windows installation — it contains a synthetic C:\ drive, registry hives, and installed components. Using a dedicated prefix per sample keeps analysis contained and makes cleanup easy.

# Create a fresh prefix for a sample
$ WINEPREFIX=~/.wine-analysis wineboot --init

# Run a binary inside that prefix
$ WINEPREFIX=~/.wine-analysis wine sample.exe

# Blow it away and start clean
$ rm -rf ~/.wine-analysis

Set WINEPREFIX for every command or export it for the session:

$ export WINEPREFIX=~/.wine-$(date +%Y%m%d)-sample_a

Basic Usage

# Run a PE -- 32-bit or 64-bit, the loader picks from the file
$ wine sample.exe

# Run with arguments
$ wine sample.exe /silent /install

# Check what Windows version Wine reports
$ wine winver

Wine creates a synthetic C:\ drive at $WINEPREFIX/drive_c/. Files the malware drops there are visible at that path on your Linux filesystem.

wine64 is gone, and so is WINEARCH=win32

Wine 11.0 completed the new WoW64 mode: the separate wine64 loader was removed in favour of a single wine binary that selects 32- or 64-bit from the PE you hand it, and pure 32-bit prefixes were deprecated. Older guides — and older editions of this page — tell you to run wine64 sample.exe and to create 32-bit prefixes with WINEARCH=win32. Neither works on a current build:

$ wine --version
wine-11.17
$ command -v wine64
$ WINEPREFIX=/tmp/wp32 WINEARCH=win32 wineboot --init
wine: WINEARCH is set to 'win32' but this is not supported in wow64 mode.

No prefix is created. Which behaviour you get depends on how your distribution built Wine, not on the sample:

Check with wine --version and command -v wine64 before trusting any 32-bit-prefix instructions, including the ones on this page. On a new WoW64 build you do not need a 32-bit prefix: a 64-bit prefix runs 32-bit PEs.

Winetricks

winetricks installs Windows runtime components that malware may depend on (Visual C++ runtimes, .NET Framework, DirectX, etc.):

# Install common runtimes
$ WINEPREFIX=~/.wine-analysis winetricks vcrun2019 dotnet48

# List available packages
$ winetricks list-all | grep vcrun

If a sample exits immediately without doing anything, it may be checking for a runtime dependency. Check the Wine output for error messages about missing DLLs.

Observing Behavior Under Wine

System Call Tracing

Use strace to trace system calls made by the Wine process:

$ strace -f -e trace=network,file wine sample.exe 2>&1 | tee strace.log

The -f flag follows child processes, which is important because Wine spawns helper processes.

Network Capture

Wine uses the host network stack, so Wireshark captures all Wine traffic normally:

$ sudo wireshark &
$ WINEPREFIX=~/.wine-analysis wine sample.exe

Disable the VM’s network adapter before running samples that should not reach the internet, or use INetSim/FakeNet to intercept and log DNS and HTTP.

Filesystem Monitoring

Watch for files created or modified during execution:

# Before execution: snapshot the prefix
$ cp -r $WINEPREFIX $WINEPREFIX.before

# Run the sample
$ WINEPREFIX=~/.wine-analysis wine sample.exe

# After execution: diff to see what changed
$ diff -rq $WINEPREFIX.before $WINEPREFIX

Registry Changes

The Wine registry lives in $WINEPREFIX/system.reg and $WINEPREFIX/user.reg. Diff them before and after:

$ cp $WINEPREFIX/system.reg system.reg.before
$ wine sample.exe
$ diff system.reg.before $WINEPREFIX/system.reg

Persistence mechanisms commonly write to:

• HKCU\Software\Microsoft\Windows\CurrentVersion\Run
• HKLM\Software\Microsoft\Windows\CurrentVersion\Run

Limitations for Malware Analysis

Wine is best suited for observing initial behavior — network callbacks, dropped files, registry writes — rather than full execution of sophisticated malware. For complete execution fidelity, use a Windows VM.

Useful Wine Environment Variables

Example combining several:

$ WINEPREFIX=~/.wine-sample WINEDEBUG=fixme-all wine sample.exe

Further Reading

• Dynamic Analysis of Windows Malware from Linux — using Wine as an analysis tool: relay API tracing, prefix diffing, and where emulation or a Windows VM is the better choice
• WineHQ
• Wine documentation
• Winetricks