Hello,
how can I permanently set the KdEnteredDebugger flag to 0 when beeing attached with the kernel debugger? I used the fill command to set it to 0 but after a while it is 1 again, so it updates from somewhere. Any ideas?
First why do you think that setting KdEnteredDebugger is going to
disable the debugger? Second, what is the poor smuck who installs your
driver going to do when the system messes up (or he is just trying to
find out why your driver and his have problems) if you do figure out a
way to block the debugger.
You can take the approach that causes some of the anti-virus firms to be
soundly hated, or unloading your driver in the presence of a debugger,
this will work, but expect lousy reviews.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@web.de” wrote in message
news:xxxxx@ntdev:
> Hello,
> how can I permanently set the KdEnteredDebugger flag to 0 when beeing attached with the kernel debugger? I used the fill command to set it to 0 but after a while it is 1 again, so it updates from somewhere. Any ideas?
Hello,
thanks for your answer. However I did not describe clear enough:
I want to set them to 0 because I want to hide my kernel debugger from drivers, I know it is not disabling the kernel debugger.
‘Kernel debugger,’ as in dbgeng based?
Mm
On Dec 31, 2010 11:35 AM, wrote:
> Hello,
> thanks for your answer. However I did not describe clear enough:
> I want to set them to 0 because I want to hide my kernel debugger from
drivers, I know it is not disabling the kernel debugger.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
I am using WinDbg
OK so that doesn’t make a whole lot of sense, but the debug engine in
the kernel will reset this value periodically if it thinks a debugger
is attached and enabled.
This value appears to be of interest to malware, so perhaps you would
like to explain exactly why you think you need to hide the debugger
from other drivers?
Mark Roddy
On Sun, Jan 2, 2011 at 5:07 PM, wrote:
> I am using WinDbg
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
I too am confused at this point: I’m not sure what you’re trying to do
exactly and I don’t understand why you’re interested in this variable for
the purposes of ‘hiding the debugger.’
What I was getting at was how are you implementing your ‘kernel debugger?’
Is it just a (a) host side dbgeng application like windbg/kd; or (b) are you
doing something a little more off the beaten path, like
SoftICE/smm/vmx/jtag/other/none of the above?
If you’re going the (a) route, my guess would be that messing with this
variable will not work at all well. It’s been a while since I’ve looked at
something around this area, but if I recall correctly, it at least used to
be involved in watchdog functionality. I’m not sure at this point if that’s
true anymore or for that matter even if I’m remembering correctly, but the
salient feature here is that it is exported for a reason - other parts of
the kernel use it. Messing with it is potentially problematic, and given
that there lots of other ways to determine if a kernel debugger is present
or not (like looking at the boot options in the registry, for a simple
example), it would seem to feature in my opinion not the greatest
risk/reward.
Achieving this in the general case will be very hard, because a lot of
Antipiracy/antire/antiforensics/packing/encryption/licensing R&D dollars go
into determining if a debugger/vm/simulation is/are present.
If you’re going the (b) route, then please explain your setup a little more.
So, I guess that I echo Mark’s sentiment - what are you trying to do
exactly?
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Monday, January 03, 2011 7:04 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] KdEnteredDebugger to 0
OK so that doesn’t make a whole lot of sense, but the debug engine in
the kernel will reset this value periodically if it thinks a debugger
is attached and enabled.
This value appears to be of interest to malware, so perhaps you would
like to explain exactly why you think you need to hide the debugger
from other drivers?
Mark Roddy
On Sun, Jan 2, 2011 at 5:07 PM, wrote:
> I am using WinDbg
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Are there drivers that actually care if a debugger is in use? Just curious
why this is an issue.
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@web.de
Sent: Friday, December 31, 2010 11:37 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KdEnteredDebugger to 0
Hello,
thanks for your answer. However I did not describe clear enough:
I want to set them to 0 because I want to hide my kernel debugger from
drivers, I know it is not disabling the kernel debugger.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.
Actually I worked on a ‘chipset’ driver that did actually have to be
concerned if a debugger was attached or not as that difference was
critical to some of the stuff this driver had to do, but this was
wildly platform specific and it would have totally sucked if some
idiot was extemporaneously mucking with it.
Mark Roddy
On Mon, Jan 3, 2011 at 5:27 PM, Joseph M. Newcomer
wrote:
> Are there drivers that actually care if a debugger is in use? ?Just curious
> why this is an issue.
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?joe
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@web.de
> Sent: Friday, December 31, 2010 11:37 AM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] KdEnteredDebugger to 0
>
> Hello,
> thanks for your answer. However I did not describe clear enough:
> I want to set them to 0 because I want to hide my kernel debugger from
> drivers, I know it is not disabling the kernel debugger.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> –
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
Joseph M. Newcomer wrote:
Are there drivers that actually care if a debugger is in use? Just curious
why this is an issue.
Absolutely. Nero, for one, distributed a driver with their CD burning
toolkit that would kill a DirectShow graph if the kernel debugger was
attached. I’m sure it was a brain-dead attempt at a security scheme,
but since the DShow graph builder tries essentially every filter in
order to make an intelligent connection, the net effect was to render
DirectShow completely useless.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Since KdEnteredDebugger is an exported symbol you could try hooking the IAT
of the driver that you want to covertly debug. Set a load image notify
routine using PsSetLoadImageNotifyRoutine and hook the IAT in your notify
routine. This assumes that the target driver (or other code) is actually
loaded using the OS loader. It also assumes that the target driver actually
uses KdEnteredDebugger (and only that) to determine that it is being
debugged. The only reference I see to KdEnteredDebugger is in the
non-exported symbol KdEnterDebugger. Depending on your requirements you
also could try NOP-ing out the instruction which sets this variable in the
kernel. Patchguard will need to be disabled, which already should be the
case if you booted in the debugger. Since your purpose is to covertly debug
some code I also assume that you do not intend to do this in a production
setting. No need to explain why you want to do this. 
Regards,
Rossetoecioccolato.
wrote in message news:xxxxx@ntdev…
> Hello,
> how can I permanently set the KdEnteredDebugger flag to 0 when beeing
> attached with the kernel debugger? I used the fill command to set it to 0
> but after a while it is 1 again, so it updates from somewhere. Any ideas?
>
OK, let me rephrase that: are there *intelligently designed* drivers that
deliberately look for the debugger presence, for other than performance
reasons?
As pointed out for one response, if a debugger is present and its presence
would hose the driver because of performance glitches, claiming it is not
present would be a disaster. (Without a debugger, a DebugPrint from the ISR
can be used as a substitute for destroying performance).
But the “homebrewed” ideas of looking for a debugger as a way to enforce
some kind of IP protection are always the work of amateurs (the few
exceptions are so small that classifying 100% of such solutions being
brain-dead is a good enough approximation for ordinary use). Professional
systems rarely try this kind of nonsense. In user space, I once had a
program that refused to run if any of the sysinternals tools had ever been
run on the machine, when I called the vendor and gave them the error message
they asked if I was running a kernel debugger. I said “no”. Then they
asked if I’d run any sysinternals tools, and I had. Needless to say, I will
never again buy any version of that program, and I told them at that phone
call that they had lost a customer forever. So clearing the debug bit seems
to serve two purposes and perhaps three: disabling IP detection in kernel
space, disabling IP protection in user space, and just possibly causing
time-critical drivers to malfunction. All this strikes me as not among the
best of ideas.
Note that IDAPro can make a good substitute for discovering what the code
looks like, without the clumsiness of running a debugger. But hey, IP
design by amateurs fixates on weird special cases without actually
addressing the problem!
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Monday, January 03, 2011 6:00 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] KdEnteredDebugger to 0
Joseph M. Newcomer wrote:
Are there drivers that actually care if a debugger is in use? Just
curious why this is an issue.
Absolutely. Nero, for one, distributed a driver with their CD burning
toolkit that would kill a DirectShow graph if the kernel debugger was
attached. I’m sure it was a brain-dead attempt at a security scheme, but
since the DShow graph builder tries essentially every filter in order to
make an intelligent connection, the net effect was to render DirectShow
completely useless.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
“Joseph M. Newcomer” wrote in message news:xxxxx@ntdev…
Note that IDAPro can make a good substitute for discovering what the code
looks like, without the clumsiness of running a debugger. But hey, IP
design by amateurs fixates on weird special cases without actually
addressing the problem!
The non-amateurs are well aware of this and do a good job trying to prevent
(packing, virtual machines) or obfuscate static analysis. Disabling the
kernel debugger is pretty much kid stuff at this point and just one of many,
many things that the folks that write this kind of software do.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
Hope to see you at the next OSR kernel debugging class February 14th in
Columbia, MD!
Joseph M. Newcomer wrote:
OK, let me rephrase that: are there *intelligently designed* drivers that
deliberately look for the debugger presence, for other than performance
reasons?
Well stated. I have never encountered one.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Indeed.
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Tuesday, January 04, 2011 7:01 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] KdEnteredDebugger to 0
“Joseph M. Newcomer” wrote in message news:xxxxx@ntdev…
Note that IDAPro can make a good substitute for discovering what the code
looks like, without the clumsiness of running a debugger. But hey, IP
design by amateurs fixates on weird special cases without actually
addressing the problem!
The non-amateurs are well aware of this and do a good job trying to prevent
(packing, virtual machines) or obfuscate static analysis. Disabling the
kernel debugger is pretty much kid stuff at this point and just one of many,
many things that the folks that write this kind of software do.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
Hope to see you at the next OSR kernel debugging class February 14th in
Columbia, MD!
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
> But the “homebrewed” ideas of looking for a debugger as a way to enforce some kind of IP
protection are always the work of amateurs (the few exceptions are so small that classifying
100% of such solutions being brain-dead is a good enough approximation for ordinary use).
Professional systems rarely try this kind of nonsense.
Well, this is not “nonsense” in itself, but professionals tend to realize that this measure per se is simply
insufficient, because it is too easy to disable it. However, if you combine it with the other techniques (for example, do it in context of a code that executes some imaginary virtual instruction set), the whole thing seems to be OK. It is understandable that all these protection schemes make sense only in the userland - doing something like that in a driver seems to be just a total non-brainer…
Anton Bassov