0

I'm working on a program that has lots of checks, and I've decided to start by disabling their anti-kernel mode, as it'd surely be more easy to isolate than normal anti-debugging. After poking around a little, I found that ntdll.zwquerysysteminformation runs in a loop in the main thread called by several .vmp addresses. Since I can't make memory changes, even in DLLs (or debug it normally), I was thinking about setting up kernel mode breakpoints until I have a bit more to go off of, but to do that, I'd need the offset from the base structure containing the byte. Microsoft doesn't seem to provide this, so would anyone happen to know? Or maybe have general pointers on getting past kernel mode detection in obfuscated targets? I know this is pretty broad, but I'm pretty sure they'd only have used the most basic of methods.

Improve this question
2
  • What is being detected by the check you're trying to disable? Sorry, your question seems a bit unclear about this. Also, when you say "the base structure" and "the byte", what base structure and what byte are you referring to?
    – higaki
    May 23, 2015 at 20:04
  • The check I'm trying to disable detects the presence of kernel mode debuggers. I hope to patch it by patching ZWQuerySystemInformation and I'm not sure how
    – asd
    May 23, 2015 at 21:13

1 Answer 1

Reset to default
0

I think the check you're talking about (NtQuerySystemInformation with SystemKernelDebuggerInformation) simply checks KdDebuggerEnabled and KdDebuggerNotPresent under the hood (both are single bytes exported from ntoskrnl.exe). You could simply patch those two to get past that particular check. Alternatively, you could go for hooking NtQuerySystemInformation either in usermode (you've mentioned that you can't make memory changes, but that's usually not true - if a memory change at some location is detected, then make the change somewhere else) or in kernelmode (requiring a PatchGuard bypass on 64-bit systems).

However, your kernel debugger might still be detected by its window/driver name.

Improve this answer
2
  • Sorry for not knowing much about this, but what offsets are those bytes from the structure returned? Their integrity checker uses dynamic regions including a few DLLs, so making edits REALLY isn't favorable and certainly isn't future proof based on the growth of security in the last few months. I've changed the driver name after enabling unsigned drivers and patched all threads that use GetWindowText(A), so I think it should be realistically impossible to see its presence with the patching of the bytes.
    – asd
    May 24, 2015 at 20:33
  • If you try calling NtQuerySystemInformation with SystemKernelDebuggerInformation and a 0-byte buffer, the function will tell you that it needs exactly 2 bytes for its output (ie. the returned structure has a size of 2), so we can infer that those two bytes are KdDebuggerEnabled and KdDebuggerNotPresent. An answer at stackoverflow.com/questions/14791901 confirms that this is the correct order. Also, you may want to take care of FindWindow and EnumWindows as well.
    – higaki
    May 24, 2015 at 22:15

Not the answer you're looking for? Browse other questions tagged or ask your own question.