The ultimate stealth method

The last described method does not work if the application uses an “unsupported” antidebugging trick. For example, if the application directly checks the PEB field instead of calling the IsDebuggerPresent function, the method will fail. Or the application could use something else, something from the future…

I will show you the “ultimate stealth method” which will work against the future antidebugging tricks too. We will unpack an application and create a database with clean unpacked code. This time we will use as a sample packer, say, telock but the packer does not really matter. Here is our original sample file and here is the packed file.
The application tries to detect the debugger and the debugger tries to hide itself. Now we will play the game differently: instead of hiding the debugger, we will completely remove it! The application refuses to run with debugger? Fine, let it run without! After all, we are interested in the unpacked code, not the in unpacker code.
Se we need to suspend the application when it unpacks itself. If we let the application run without any modifications, it will not suspend. We will modify it to suspend itself.
The idea: we will patch a Windows API function to suspend our application. As soon as the unpacked code calls it, the application will be suspended. For our sample program we know that the CreateWindowExA function is called. It looks like this:

We patch it to call the SuspendThread function instead of creating a window:

The next step is to let the application run without the debugger. We use the Debugger, Detach from process. The unpacker will do its job and the application will suspend itself before creating any windows, so nothing will happen on the screen. But if we check the task list, we will see our application (Debugger, Attach to process):

The application has been unpacked and is ready to be analyzed! Open the program segmentation, find the application name (sample_telocked.exe in our case) and you will see clean code.
In short, the ultimate stealth method consists of the following sequence:
Patch system dlls – Detach – Attach
What to do if we do not know what Window API functions are used by the application? We could try to patch as many functions as we want. We should not patch functions used by the unpacker since it will prevent the unpacker from doing its job. If we are really out of ideas, even ExitProcess or similar function can be patched. The application will be suspended at the exit time but we will have an opportunity to see the original import table which will give us the list of API functions to consider.
We could also patch API functions in other ways. Instead of calling SuspendThread we could write 0xCC, or invalid opcodes, or even zeroes. The application would crash and we could attach to it with IDA (turn on Debugger, Debugger options, Set as just-in-time debugger before using this method).

7 thoughts on “The ultimate stealth method”

  1. Just a comment on the last paragraph… FYI, patching the Windows APIs with 0xCC will not work with telock in particular, as it checks all of the imports for 0xCC – a fairly weak (but effective) anti-debugging trick. The other suggestions are good, though.

  2. Thanks for the comment, Joe!
    One way of fighting against this would be patching bytes in the middle of Windows API functions. There are some unpackers which jump to the second or third instruction of a Windows API instead of calling them directly. If we patch bytes in the middle, these unpackers would be defeated too.

  3. if some funcs that i wanted to patch has not been loaded in to process memory,When start the debugger,how we solve it?
    ie. some packer use “Loadlibrary” to load dll when it unpacked the segment

  4. You can path the LoadLibrary function to suspend the process after loading the library. Ideally the patch would check the library name and suspend the process only if the interesting library got loaded.
    When the application suspends itself, you can attach to the application and add more stealth breakpoints and continue…

Comments are closed.