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…