NtSetDebugFilterState anti-debug

[mrexodia]

Originally reported by: Duncan (Bitbucket: mrexodia, GitHub: mrexodia)

---

see attached file for more information

---

• Bitbucket: https://bitbucket.org/mrexodia/titanhide/issue/3

[Mattiwatti]

Hello 5 year old issue...

I thought I'd add this feature since it's pretty simple, but then after looking at the ScyllaHide source I came to the conclusion that the hook as is in ScyllaHide is essentially useless since it is a subset of the remove debug privileges option.

There are two possible scenarios:

• The process has debug privileges. In this case a call to NtSetDebugFilterState returns success.
• The process doesn't have debug privileges. In this case a call to NtSetDebugFilterState returns STATUS_ACCESS_DENIED.

The anti-debug 'trick' is to call NtSetDebugFilterState, and if it succeeds, you know that you have debug privileges, which isn't the same thing as knowing if you're being debugged. But you can also just query your process token and find out if you have debug privileges. So the 'naive' hook (return STATUS_ACCESS_DENIED) would actually make it possible to detect TH by enabling debug privileges and seeing the incorrect return value, and this used to be true for SH too.

SH does this a bit better now because I fixed this a while ago, but it makes the hook basically useless since it just returns what the kernel would have returned anyway. The real problem is a process having debug privileges when it shouldn't. So should we add an option for that instead?

[mrexodia]

I think generally a process doesn’t have debug privs while under x64dbg?

…

On Sun, 10 Mar 2019 at 22:07, Matthijs Lavrijsen ***@***.***> wrote: Hello 5 year old issue... I thought I'd add this feature since it's pretty simple, but then after looking at the ScyllaHide source I came to the conclusion that the hook as is in ScyllaHide is essentially useless since it is a subset of the remove debug privileges option. There are two possible scenarios: - The process has debug privileges. In this case a call to NtSetDebugFilterState returns success. - The process doesn't have debug privileges. In this case a call to NtSetDebugFilterState returns STATUS_ACCESS_DENIED. The anti-debug 'trick' is to call NtSetDebugFilterState, and if it succeeds, you know that you have debug privileges, which isn't the same thing as knowing if you're being debugged. But you can also just query your process token and find out if you have debug privileges. So the 'naive' hook (return STATUS_ACCESS_DENIED) would actually make it possible to detect TH by enabling debug privileges and seeing the incorrect return value, and this used to be true for SH too. SH does this a bit better now because I fixed this a while ago, but it makes the hook basically useless since it just returns what the kernel would have returned anyway. The real problem is a process having debug privileges when it shouldn't. So should we add an option for that instead? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACWCmRsKJlS2BytE20cH4CeylpVG4kzlks5vVXQkgaJpZM4bngQj> .

[Mattiwatti]

Not in x64dbg, no. Some other debuggers I tried (VS2017 and WinDbg) do let the process inherit debug privileges. So there is a point to be made for just calling it a bug in the debugger 😛 To be fair inheriting enabled process privileges is the default Windows behaviour I think.

[mrexodia]

So can we simply give the privilege away again from within the process?

…

On Sun, 10 Mar 2019 at 22:12, Matthijs Lavrijsen ***@***.***> wrote: Not in x64dbg, no. Some other debuggers I tried (VS2017 and WinDbg) do let the process inherit debug privileges. So there is a point to be made for just calling it a bug in the debugger 😛 To be fair inheriting enabled process privileges is the default Windows behaviour I think. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACWCmWuYDwPqPFNKZFiSi2v_QrSerFlSks5vVXUhgaJpZM4bngQj> .

[Mattiwatti]

Yeah. You don't actually need to be in the process address space to do it from kernel mode, so it could be applied without having to KeStackAttachProcess or wait for the process to set off some hook. It's basically PsReferencePrimaryToken with the EPROCESS to get its PACCESS_TOKEN, ObOpenObjectByPointer that to convert it to a handle, dereference object, NtAdjustPrivilegesToken on the handle to set the desired privileges, close handle.