Anti-* | Hexacorn

Software development is quite easy today. There is no longer a need to write your own libraries for everything (a mouse handler, a proprietary database, a graphics library, or your own search and caching algorithms, etc.). What’s more, a very complex functionality can be now delivered with just a few lines of script.

Yup. We are indeed very lucky.

While we depend on these modules to do the hard work we happily focus on the business logic and simply getting things done. But yes, of course, this privilege relies heavily on a tremendous work of other programmers who developed and tested modules which we use every day. Modules that are the foundation of Windows as we see it today have been written over a few decades (maybe with the exception of telemetry modules ;)) and it’s not a surprise that many of them contain legacy code, vulnerabilities, and… dummy, retired, or unfinished code.

In this post I will focus on the latter – the APIs that are pretty much doing nothing, but returning an error or a predictable constant value (I will talk about 32-bit Windows, but same applies to 64-bit version). Either indicating that the function is not implemented yet, or is just a dummy function kept for compatibility reasons, or perhaps for some other reason. I won’t cover all of them, but will show a few examples of how these could be used.

Probably the best known function that returns a constant value is kernel32.dll!GetCurrentProcess. It simply returns -1 (0xFFFFFFFF on win32). For this reason many programmers hard-code this value in their programs (one API call less).
Its close cousin, kernel32.dll!GetCurrentThread always returns -2. Same, some coders hard-code it to avoid superfluous API calls.
crypt32.dll!DbgPrintf always returns 0. So does imm32.dll!CtfImmIsTextFrameServiceDisabled. And tones of other APIs. A nice ‘obfuscated’ replacement for the worn out ‘xor eax, eax’.
gdi32.dll!GdiSupportsFontChangeEvent always returns 1. So does kernel32.dll!LZStart. And again, lots of other APIs.
GdiPlus.dll!GdipCreateStreamOnFile aways returns 6.
rasman.dll!RasRpcUnloadDll always returns 50.
atl.dll!AtlGetVersion returns 768 on Win10..
Many unimplemented APIs return ERROR_INVALID_PARAMETER which is equal to 87 f.ex. dnsapi.dll!DnsUpdate and dnsapi.dll!Dns_UpdateLibEx.

This can be obviously extended to COM and its methods that do nothing, but returning ‘not implemented’ constants.

The other variants of this technique can utilize fully implemented APIs which are called with incorrect arguments producing a predictable last error value.

There are a number of potential tricks we can pull using APIs returning predictable, or very specific values, or behaving in a predictable way:

anti-emulation tricks
- initialization of register values – if an emulator fails to emulate the function it may not get the proper value into the eax register and as such a code dependent on it may fail (f.ex. a decryption routine, a routine using the return value as an index to a lookup table, etc.)
- passing data by storing it inside the internal OS structures f.ex. SetLastError/ SetLastErrorEx / GetLastError combo
detecting the version of OS
- historically, some APIs changed the behavior and newer versions may simply return a constant f.ex. TRUE (1); a simple example is GdiSetAttrs (probably not very practical example as its behavior changed long time ago, but always…)
- new APIs can help to detect OS version w/o using ‘traditional’ APIs (f.ex. Get Version, etc.) – relatively new ole32.dll’s CoBuildVersion function could be used to determine the version of ole32.dll (and indirectly, OS version); same goes for UrlMkBuildVersion exported by urlmon.dll
anti-debugging tricks
- if the function does nothing, but calling DebugBreak (int 3), it may fool some analysts by triggering the exception handler w/o them noticing it (lame, but always)
perhaps others…

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.

Hexacorn