My goal of this blog is to generally post undocumented details of the Windows operating system. By details I mean topics that would interest both software reverse-engineers and malware analysts alike. One of those topics to me is a lot more prominent then the rest, and that is mechanisms that attempt to detect or evade debugging. Whether it be DRM or actual malware, I'd have to say it's my favorite topic.
What were going to discuss today has probably already been discussed elsewhere, however out of all the methods used to detect if a kernel debugger is attached to the system, I think this one is hardly used or mentioned. Therefore I think it warrants a quick discussion today.
As you probably already know, KeLoaderBlock is the first argument to KiSystemStartup. Among a plethora of other details this structure contains the boot flags from the current BCD entries corresponding our current boot. For instance boot option selection timeout, test-signing, NX opt in or opt out, /debug flags for the kernel debugger etc.
KeLoaderBlock is not accessible from user-mode, but I'm always surprised that many are unaware that during initialization, the startup flags are written to the following registry fields.
HKLM\System\CurrentControlSet\Control - SystemStartOptions
From these flags the software can easily find out if the system was booted with /TESTSIGNING or /DEBUG ON
This method we discussed as you can see is very simple. So simple that it's often overlooked.
Nice find, but you have to be aware of its false positives for example a machine booted up with "DEBUGPORT=COM3" that found no kernel debugger connection and continued booting normally.
ReplyDelete