Debugger/application freeze on resume

[rokups]

Issue itself is when i run any target (32/64bit) and attempt to hide debugger through either x64dbg plugin or TitanHideGUI.exe - both debugger and target freeze. It is impossible to kill these processes. The only way to get rid of them is to reboot.

OS: Windows 10 Enterprise 2016 LTSB x64 build 14393
TitanHide.log:

[TITANHIDE] FileSize of ntdll.dll is 001CCCB0!
[TITANHIDE] UndocumentedInit() was successful!
[TITANHIDE] Device \Device\TitanHide created successfully!
[TITANHIDE] Symbolic link \DosDevices\TitanHide->\Device\TitanHide created!
[TITANHIDE] Range: 0xFFFFF803CAD6A250-0xFFFFF803DAD6A24F
[TITANHIDE] CodeStart: 0xFFFFF803CAE57000, CodeSize: 0x313600
[TITANHIDE] Range: 0xFFFFF803CAE57000-0xFFFFF803CB16A600
[TITANHIDE] CaveAddress: 0xFFFFF803CAE68E14
[TITANHIDE] hook(0xFFFFF803CAE68E14, 0xFFFFF805356D1A80)
[TITANHIDE] SSDThook(NtQueryInformationProcess:0x00000000014B0101, 0x0000000000FEBC41)
[TITANHIDE] CaveAddress: 0xFFFFF803CAE68EA1
[TITANHIDE] hook(0xFFFFF803CAE68EA1, 0xFFFFF805356D1BB4)
[TITANHIDE] SSDThook(NtQueryObject:0x0000000001072501, 0x0000000000FEC511)
[TITANHIDE] CaveAddress: 0xFFFFF803CAE6B283
[TITANHIDE] hook(0xFFFFF803CAE6B283, 0xFFFFF805356D1D6C)
[TITANHIDE] SSDThook(NtQuerySystemInformation:0x00000000011AA600, 0x0000000001010330)
[TITANHIDE] CaveAddress: 0xFFFFF803CAE6C712
[TITANHIDE] hook(0xFFFFF803CAE6C712, 0xFFFFF805356D1EE8)
[TITANHIDE] SSDThook(NtSetInformationThread:0x0000000001495200, 0x0000000001024C20)
[TITANHIDE] CaveAddress: 0xFFFFF803CAE6F072
[TITANHIDE] hook(0xFFFFF803CAE6F072, 0xFFFFF805356D19CC)
[TITANHIDE] SSDThook(NtClose:0x0000000001853100, 0x000000000104E220)
[TITANHIDE] CaveAddress: 0xFFFFF803CAE6F1E2
[TITANHIDE] hook(0xFFFFF803CAE6F1E2, 0xFFFFF805356D1E04)
[TITANHIDE] SSDThook(NtSetContextThread:0x0000000003907CC0, 0x000000000104F920)
[TITANHIDE] CaveAddress: 0xFFFFF803CAE6F672
[TITANHIDE] hook(0xFFFFF803CAE6F672, 0xFFFFF805356D1FAC)
[TITANHIDE] SSDThook(NtSystemDebugControl:0x0000000001A72102, 0x0000000001054222)
[TITANHIDE] Hooks::Initialize() hooked 7 functions
[TITANHIDE] HiderProcessData OK!
[TITANHIDE] ProcessDebugPort by 4920

P.S. Is readme still accurate? Log does not indicate any failures so it seems hardcoding SSDT address is no longer necessary on W10 right?

[mrexodia]

Windows 10 Enterprise 2016 LTSB x64 build 14393

Try something old like Windows 7

[rokups]

It runs fine on older OSes, i know. Still be great if at some point w10 worked as well

[mrexodia]

Older versions of Windows 10 used to work fine, but Microsoft is breaking everything, probably this is another variant of patchguard or something. I don't use TitanHide (or windows 10 for that matter) so it's unlikely you'll see a fix from me anytime soon...

[rokups]

Same thing happens on windows 8.1 x64. Maybe we could expect fix for 8.1 then? It is not a moving target like w10 is. I would use win7 but it is missing some required features that make it unfeasible..

Edit:
Log from w8.1 VM:

[TITANHIDE] FileSize of ntdll.dll is 001A8380!
[TITANHIDE] UndocumentedInit() was successful!
[TITANHIDE] Device \Device\TitanHide created successfully!
[TITANHIDE] Symbolic link \DosDevices\TitanHide->\Device\TitanHide created!
[TITANHIDE] Range: 0xFFFFF80248B67B00-0xFFFFF80258B67AFF
[TITANHIDE] CodeStart: 0xFFFFF80248D9D000, CodeSize: 0x2DEA00
[TITANHIDE] Range: 0xFFFFF80248D9D000-0xFFFFF8024907BA00
[TITANHIDE] CaveAddress: 0xFFFFF80248DAE132
[TITANHIDE] hook(0xFFFFF80248DAE132, 0xFFFFF80169A72A80)
[TITANHIDE] SSDThook(NtQueryInformationProcess:0x0000000004B25DC1, 0x0000000002466321)
[TITANHIDE] CaveAddress: 0xFFFFF80248DC2ED1
[TITANHIDE] hook(0xFFFFF80248DC2ED1, 0xFFFFF80169A72BB4)
[TITANHIDE] SSDThook(NtQueryObject:0x0000000002839781, 0x00000000025B3D11)
[TITANHIDE] CaveAddress: 0xFFFFF80248DC3162
[TITANHIDE] hook(0xFFFFF80248DC3162, 0xFFFFF80169A72D6C)
[TITANHIDE] SSDThook(NtQuerySystemInformation:0x00000000026EFEC0, 0x00000000025B6620)
[TITANHIDE] CaveAddress: 0xFFFFF80248DC3402
[TITANHIDE] hook(0xFFFFF80248DC3402, 0xFFFFF80169A72EE8)
[TITANHIDE] SSDThook(NtSetInformationThread:0x000000000274B580, 0x00000000025B9020)
[TITANHIDE] CaveAddress: 0xFFFFF80248DC36F2
[TITANHIDE] hook(0xFFFFF80248DC36F2, 0xFFFFF80169A729CC)
[TITANHIDE] SSDThook(NtClose:0x0000000002712400, 0x00000000025BBF20)
[TITANHIDE] CaveAddress: 0xFFFFF80248DC59E2
[TITANHIDE] hook(0xFFFFF80248DC59E2, 0xFFFFF80169A72E04)
[TITANHIDE] SSDThook(NtSetContextThread:0x0000000004B96DC0, 0x00000000025DEE20)
[TITANHIDE] CaveAddress: 0xFFFFF80248DC5FE1
[TITANHIDE] hook(0xFFFFF80248DC5FE1, 0xFFFFF80169A72FAC)
[TITANHIDE] SSDThook(NtSystemDebugControl:0x0000000004F70D02, 0x00000000025E4E12)
[TITANHIDE] Hooks::Initialize() hooked 7 functions
[TITANHIDE] HiderProcessData OK!
[TITANHIDE] ProcessDebugPort by 4728
[TITANHIDE] ProcessDebugPort by 4728
[TITANHIDE] ProcessDebugPort by 4728
[TITANHIDE] ProcessDebugPort by 4728
[TITANHIDE] ProcessDebugFlags by 4728
[TITANHIDE] ProcessDebugPort by 4728
[TITANHIDE] ProcessDebugPort by 4728
[TITANHIDE] ProcessDebugPort by 4728
<...>
[TITANHIDE] ProcessDebugPort by 4728

[Mattiwatti]

I don't know if you still need/are interested in this, but I just tried to reproduce the hang and failed on both 8.1 and 10.0.17134.228 (i.e. everything just worked). However, I did find:

1. A super embarrassing bug in NtQueryInformationProcess(ProcessDebugObjectHandle) where a handle was not closed (this bug is present in ScyllaHide too). If I run the test exe for a few minutes, I can sort of reproduce the hang (can't pause the debuggee, etc.) due to the x64dbg.exe handle table having tens of thousands of debug object handles. But I can still kill x64dbg with Process Hacker after this, while you say you have to reboot. So I'm not certain this is the same issue.
2. A minor problem with the NtClose hook that could lead to a hang due to using a fast mutex which will deadlock if acquired recursively. But this is mostly a theoretical issue and I have never seen it happen, let alone in a reproducible way.
3. An even less interesting bug: kernel mode callers are considered for hooking in HookNtSetContextThread, which should never be allowed because the Nt and Zw versions of this syscall are not really even the same function at all. This also is not a real issue since nobody is stupid enough to call ZwSetContextThread from kernel mode. If they were, you would have got a BSOD, not a process hang.

Edit: I said 'x64dbg.exe handle table' above - this should of course be the handle table of ScyllaTest_x64.exe (or whichever process you are debugging), since that is the process that's receiving the debug port handle.

[mrexodia]

Thanks @Mattiwatti I merged all three pull requests. Also gave you commit access to the repo ❤️

[Mattiwatti]

Cool, cheers!

I can't promise I'll make a lot of use of it, since I (like you) don't use TH very often myself.

I do have an unfinished private project on my HDD that was intended to be more or less a "TitanHide v2", with a much more aggressive default policy that hooks all functions in all processes by default, except for "redpilled" processes (i.e. known trusted debuggers). This would negate most of the issues raised in #17 w.r.t. protectors executing in different process contexts to detect discrepancies. The exception of course would be executing in a debugger process context, but there are a fair number of ways to make this impossible from ring 0 (lame example: make the debugger a protected process). Also, the SSDT hooking code has been rewritten so that it passes Driver Verifier on a checked build of Windows 10, which TH currently does not... spectacularly 😛

I might make a new branch to add this stuff at some point, but I'm currently very busy with work so atm this may be anywhere between 'next month' and 'never'...

[mrexodia]

That sounds like an interesting project ^^ but I just gave you access in case you ever need it, not to let you maintain the project 😀

…

On Sun, 2 Sep 2018 at 03:09, Matthijs Lavrijsen ***@***.***> wrote: Cool, cheers! I can't promise I'll make a lot of use of it, since I (like you) don't use TH very often myself. I do have an unfinished private project on my HDD that was intended to be more or less a "TitanHide v2", with a much more aggressive default policy that hooks all functions in all processes by default, except for "redpilled" processes (i.e. known trusted debuggers). This would negate most of the issues raised in #17 <#17> w.r.t. protectors executing in different process contexts to detect discrepancies. The exception of course would be executing in a debugger process context, but there are a fair number of ways to make this impossible from ring 0 (lame example: make the debugger a protected process). Also, the SSDT hooking code has been rewritten so that it passes Driver Verifier on a checked build of Windows 10, which TH currently does not... spectacularly 😛 I might make a new branch to add this stuff at some point, but I'm currently very busy with work so atm this may be anywhere between 'next month' and 'never'... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#29 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACWCmb-_w0iSLalRfISlZOMZPqan1IThks5uWy_VgaJpZM4REnPr> .

[Mattiwatti]

Wait, so does that mean I can't even wipe the repo from GitHub irreversibly? Or any other special superpowers like that? Lame...

Anyway, no worries, I only mentioned it because it came to mind that I still had that stuff lying around. And tbh I'd rather merge changes into this repo (assuming they are approved by The Maintainer(TM) obviously) than create a fork and have to deal with all the 'WHY I GET BSOD' tickets myself 😄