I've been given a program that emulates the Windows API. I'm attempting to find flaws in this emulator where it either:

  1. Always returns a constant value, regardless of the host system (Useful for fingerprinting)
    • For example, calls to get the username in this emulator return various random strings. But calls to get the free disk space always returns the same number, regardless of the actual value on the host system.
  2. Returns the real value from bare metal (Emulator leaking real information)
    • For example, calls to get the MAC address return the value from the host system.

Instead of writing functions to test the return values from various functions in the Windows API, I'm looking for a way to automate code generation (preferably in C/C++) to query a large number of functions provided by the WinAPI . Is anything like this possible or has it been done for other projects that I could leverage?

  • This should be on the StackOverflow, as it is a software engineering question.
    – Stolas
    Commented Sep 18, 2013 at 6:36
  • I'm not sure I agree with Stolas' comment as the question is strongly related to reversing, see Rolf's answer.
    – ekse
    Commented Sep 18, 2013 at 15:30
  • @ekse, it is related to Assembly not reverse engineering. Or maybe Security when you try to write a FUD-Virus (or something like that). Nevertheless the subject is interesting ;)
    – Stolas
    Commented Sep 19, 2013 at 6:35

2 Answers 2


I've done this same exercise with anti-virus engines on a number of occasions. Generally the steps I use are:

  1. Identify the CPU/Windows emulator. This is generally the hardest part. Look at filenames, and also grep the disassembly for large switch statements. Find the switches that have 200 or more cases and examine them individually. At least one of them will be related to decoding the single-byte X86 opcodes.
  2. Find the dispatcher for the CALL instruction. Usually it has special processing to determine whether a fixed address is being called. If this approach yields no fruit, look at the strings in the surrounding modules to see anything that is obviously related to some Windows API.
  3. Game over. AV engines differ from the real processor and a genuine copy of Windows in many easily-discernible ways. Things to inspect: pass bogus arguments to the APIs and see if they handle erroneous conditions correctly (they never do). See if your emulator models the AF flag. Look up the exception behavior of a complex instruction and see if your emulator implements it properly. Look at the implementations of GetTickCount and GetLastError specifically as these are usually miserably broken.

Previous answer is good. I would say this depends on machine and emulator. There are many more tricks to recognize emulators.

You might look at the environment, is there an emultor in the file system? Is the number of running applications indicating a virtual application?

Ask the operating system whether the application is debugged; different methods exist, most are easily defeated.

I have a program which measures the execution time between close instructions. If the machine does not have hardware support for emulation, this is pretty reliable.

Use google for anti-debug

Chris Jacobi

  • This is more a comment than an answer. You do not give any effective way to detect emulation... Try to give at least some technicalities about emulation detection to improve your answer.
    – perror
    Commented Dec 27, 2013 at 7:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.