8

I'm sure many of you are familiar with this classic antidebug trick accomplished by calling ZwSetInformationThread with ThreadInformationClass set to 0x11. Although many OllyDbg modules exist for the purposes of revealing the existence of threads hidden with this method, I haven't been able to find any information on the canonical technique employed to unhide these threads in OllyDbg.

Is the function generally hooked in user mode (e.g SetWindowsHookEx), or is it more pragmatic to patch instructions that either call the NTDLL function directly or system calls which indirectly invoke it?

zetavolt
  • 1,213
  • 11
  • 12

1 Answers1

6

SetWindowsHookEx isn't really used for this sort of hooking as far as I'm aware.

You could hook NtSetInformationThread in the import of the binary you want to analyze and make it always return success on ThreadHideFromDebugger but not forward the call to the actual function. This would be weak since GetProcAddress or manual imports would bypass it.

You could hook the NtSetInformationThread function by inserting a call to your own function in the function prologue and then ignore ThreadHideFromDebugger while forwarding the rest to the original function.

I strong advice against it but for the sake of completeness, you could also hook NtSetInformationThread in the system service dispatch table. There's a good dump of the table for different Windows versions here. If you want to get the index in the table yourself you can just disassemble the NtSetInformationThread export from ntdll.dll.

If you're interested in more anti-debugging techniques strongly recommend reading Peter Ferrie's awesome anti-debugging reference.

Peter Andersson
  • 5,701
  • 1
  • 32
  • 49