2

By analyzing a piece of assembly code of a Trojan, I found a string "ZwQueryInformationThread". I assume that it is an anti-debugging technique because the process terminates after hitting that line.

But, I could not find any good explanation for "ZwQueryInformationThread" stopping the process. For me, the purpose is clear: it tries to make my work harder, but I would like to get more information about that.

So, my question would be:

Is there someone who can tell me what "ZwQueryInformationThread" does?

3 Answers 3

1

I believe what you are seeing is the NtSetInformationThread detection of anti-anti-debug tools. The technique is documented at https://ntquery.wordpress.com/2014/03/29/anti-debug-ntsetinformationthread/#more-6.

We call NtSetInformationThread two times with wrong parameters and this will reveal most anti-anti-debug plugins. Since Vista it is possible to use NtQueryInformationThread and this makes it much more powerful. Currently no anti-anti-debug plugin is hooking NtQueryInformationThread to prevent this check.

1

its one of those 'multipurpose' api queries, where the parameters dictate what information you want (for example, thread exit code, thread entrypoint, if a thread is debuggable and so on)..

http://msdn.microsoft.com/en-us/library/windows/desktop/ms684283%28v=vs.85%29.aspx

the threadinfoclass is the 'key' parameter, which isnt documented too well, so like all good reversers, we hope that reactos has a reference.. and.. it does

http://doxygen.reactos.org/d8/dfb/xdk_2pstypes_8h_ae45f91e457cfd1075daa9a900902a16d.html

so all you then need to figure out is the size of ThreadInformationLength required for the threadinfoclass you want is, so you just do it in the usual fashion of calling it with a small buffer, then checking the return value from the call (if it worked, its NT_SUCCESS which is zero), otherwise it'll be another value, typically one indicating the buffer was too small (in which case allocate a buffer of size of the (ReturnLength) parameter you passed and call again...

hope that helps

edit : just remembered this...

ThreadHideFromDebugger is a commonly used anti debug, it has one caveat however, (parameter passed is a pointer to a TRUE (dword)...), once this is done, passing false etc.. will NOT work.. ie: once the call is successful for that thread, the hide from debugger can not be undone)

1

ZwQueryInformationThread is low-level API with deals with querying information about threads. Malware related you can hide from a debugger just like evlncrn8 said. You could also use this to hide a thread like a rootkit would by hooking the API.

How about you set a breakpoint on all the common exit APIs and look back to what actually calls the exit so you can work your way back to what's actually happening? There no point just looking at ZwQueryInformationThread and guessing it's that API.

Breakpoint the following:

  • ExitProcess
  • TerminateProcess
  • NtTerminateProcess
  • LdrShutdownProcess
  • ExitThread
  • TerminateThread
  • NtTerminateThread
  • LdrShutdownThread
  • SetThreadContext/ NtSetContextThread setting EIP/RIP to 0.

Soon as it exits you'll able to follow it all back to whats actually closing the program.

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.