Many malicious samples try to detect sandbox environment and to do so they use an avalanche of tricks that are either generic (f.ex. checking a number of processors) or very specific (f.ex. VMWare backdoor). One of the environments they try to detect using specific tricks is Wine.

The Wine detection is simple: check if kernel32.dll or ntdll.dll exports one of internal Wine APIs.

Looking at the data obtained from sandboxing of many samples, I noticed that the combos (not necessarily correct) that are used to detect the Wine environment are as follows:

• kernel32.dll!wine_get_unix_file_name
• ntdll.dll!wine_get_unix_file_name
• ntdll.dll!wine_get_version
• ntdll.dll!wine_nt_to_unix_file_name
• ntdll.dll!wine_server_call

This made me think that there may be more possibilities and to confirm that I downloaded the latest snapshot of Wine source code.

Turns out that there are actually more internal functions available.

Grepping all *.spec files for the ‘# Wine.*?extensions’ regex gives us the following list of candidates:

dlls\gdi32\gdi32.spec

################################################################
# Wine extensions: Win16 functions that are needed by other dlls
#
@ stdcall GetDCHook(long ptr)
@ stdcall SetDCHook(long ptr long)
@ stdcall SetHookFlags(long long)

################################################################
# Wine internal extensions
#
# All functions must be prefixed with '__wine_' (for internal functions)
# or 'wine_' (for user-visible functions) to avoid namespace conflicts.

# GDI objects
@ cdecl __wine_make_gdi_object_system(long long)
@ cdecl __wine_set_visible_region(long long ptr ptr ptr)

# Graphics drivers
@ cdecl __wine_set_display_driver(long)

# OpenGL
@ cdecl __wine_get_wgl_driver(long long)

dlls\imm32\imm32.spec

################################################################
# Wine internal extensions
@ stdcall __wine_get_ui_window(ptr)

dlls\kernel32\kernel32.spec

################################################################
# Wine internal extensions
#
# All functions must be prefixed with '__wine_' (for internal functions)
# or 'wine_' (for user-visible functions) to avoid namespace conflicts.

# 16-bit relays (for backwards compatibility)
@ cdecl -i386 -private __wine_dll_register_16(ptr str)
@ cdecl -i386 -private __wine_dll_unregister_16(ptr)
@ stub -i386 __wine_call_from_16_regs

# Unix files
@ cdecl wine_get_unix_file_name(wstr)
@ cdecl wine_get_dos_file_name(str)

# Init code
@ cdecl __wine_kernel_init()

dlls\krnl386.exe16\krnl386.exe16.spec

################################################################
# Wine internal extensions
#
# All functions must be prefixed with '__wine_' (for internal functions)
# or 'wine_' (for user-visible functions) to avoid namespace conflicts.

# DOS support
@ cdecl -arch=win32 __wine_call_int_handler(ptr long)
@ cdecl -arch=win32 __wine_load_dos_exe(str str)

# VxDs
@ cdecl -arch=win32 -private __wine_vxd_open(wstr long ptr)
@ cdecl -arch=win32 -private __wine_vxd_get_proc(long)

dlls\ntdll\ntdll.spec

##################
# Wine extensions
#
# All functions must be prefixed with '__wine_' (for internal functions)
# or 'wine_' (for user-visible functions) to avoid namespace conflicts.

# Relays
@ cdecl -i386 __wine_enter_vm86(ptr)

# Server interface
@ cdecl -norelay wine_server_call(ptr)
@ cdecl wine_server_fd_to_handle(long long long ptr)
@ cdecl wine_server_handle_to_fd(long long ptr ptr)
@ cdecl wine_server_release_fd(long long)
@ cdecl wine_server_send_fd(long)
@ cdecl __wine_make_process_system()

# Version
@ cdecl wine_get_version() NTDLL_wine_get_version
@ cdecl wine_get_build_id() NTDLL_wine_get_build_id
@ cdecl wine_get_host_version(ptr ptr) NTDLL_wine_get_host_version

# Codepages
@ cdecl __wine_init_codepages(ptr ptr ptr)

# signal handling
@ cdecl __wine_set_signal_handler(long ptr)

# Filesystem
@ cdecl wine_nt_to_unix_file_name(ptr ptr long long)
@ cdecl wine_unix_to_nt_file_name(ptr ptr)
@ cdecl __wine_init_windows_dir(wstr wstr)

dlls\ntoskrnl.exe\ntoskrnl.exe.spec

################################################################
# Wine internal extensions
#
# All functions must be prefixed with '__wine_' (for internal functions)
# or 'wine_' (for user-visible functions) to avoid namespace conflicts.

@ cdecl wine_ntoskrnl_main_loop(long)

dlls\user32\user32.spec

################################################################
# Wine internal extensions
#
# All functions must be prefixed with '__wine_' (for internal functions)
# or 'wine_' (for user-visible functions) to avoid namespace conflicts.
#
@ cdecl __wine_send_input(long ptr)
@ cdecl __wine_set_pixel_format(long long)

Now that we have a list of all internal functions, we can create a simple program that will try to detect Wine by attempting to resolve these API names.

Running it on Win7 we get the following results:

Running it on Wine under Ubuntu gives us the following result:

So, it looks like we have quite a lot of combos to use!

• kernel32.dll!__wine_dll_register_16
• kernel32.dll!__wine_dll_unregister_16
• kernel32.dll!__wine_call_from_16_regs
• kernel32.dll!wine_get_unix_file_name
• kernel32.dll!wine_get_dos_file_name
• kernel32.dll!__wine_kernel_init
• ntdll.dll!__wine_enter_vm86
• ntdll.dll!wine_server_call
• ntdll.dll!wine_server_fd_to_handle
• ntdll.dll!wine_server_handle_to_fd
• ntdll.dll!wine_server_release_fd
• ntdll.dll!wine_server_send_fd
• ntdll.dll!__wine_make_process_system
• ntdll.dll!wine_get_version
• ntdll.dll!wine_get_build_id
• ntdll.dll!wine_get_host_version
• ntdll.dll!__wine_init_codepages
• ntdll.dll!__wine_set_signal_handler
• ntdll.dll!wine_nt_to_unix_file_name
• ntdll.dll!wine_unix_to_nt_file_name
• ntdll.dll!__wine_init_windows_dir

The title of this post refers to both internal and legacy APIs.

Here’s a thing – there exist APIs that used to be present in the old versions of Windows but have been removed and are no longer exported by the OS libraries. Yet, Wine continues to offer them as an export – most likely for compatibility reasons.

A perfect example of such API are RegisterServiceProcess and OpenVxDHandle that used to be exported by kernel32.dll on Windows 9x/ME, but are not present on the NT/2000/XP/Vista/Win7/8/10.

Yup. This fact alone allows us to leverage them for the detection of Wine (and potentially other sandboxes).

This is obviously a tip of an iceberg – many other APIs like this can be found all over the place.

You can download the test tool here.