Re: Module level breakpoint filtering

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance



Hi Slava

Hooking IsDebuggerPresent() is not the best idea either, for the simple
reason that the target DLL does not necessarily have to call this routine
in order to realize that the process is being debugged - after all, it can
just check PEB, i.e. just re-implement it.

True, but highly unlikely.

Don't forget that we are speaking about the protection scheme, so that
there is a good chance that its designers took some steps to make this
scheme not-so-easy to neuralize. If they just call IsDebuggerPresent(),
the task of neutralizing the whole scheme is just trivial, especially
if they do it via IAT. However, if they provide their own
implementation of IsDebuggerPresent(), the task becomes much more
complex. If you take into consideration the fact that custom
implementation of IsDebuggerPresent() requires just 4(!!!) assembly
instructions (including RET), I hope you will agree that the above
mentioned scenario is much more likely than you originally thought

Your idea about __try/__except block is already better, although it
requires modifying the client code

I had no such ideas.


If you had no such ideas, could you please explain the statement below
- you are the one who made it:

///////
Another way how this DLL can work fine without a debugger is by
wrapping the
breakpoints in a __try/__except block, whose __except handler will
simply
dismiss the exception.
///////


Anton Bassov




Slava M. Usov wrote:
"anton bassov" <soviet_bloke@xxxxxxxxxxx> wrote in message
news:1152990472.898720.105870@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

[...]

Hooking IsDebuggerPresent() is not the best idea either, for the simple
reason that the target DLL does not necessarily have to call this routine
in order to realize that the process is being debugged - after all, it can
just check PEB, i.e. just re-implement it.

True, but highly unlikely.

Your idea about __try/__except block is already better, although it
requires modifying the client code

I had no such ideas.

S

.



Relevant Pages

  • Re: Module level breakpoint filtering
    ... reason that the target DLL does not necessarily have to call this routine ... requires modifying the client code ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Hidden Tables
    ... I was reading some code and it contained a 'DoCmd.TransferDatabase", ... However when I examined the server database I did not see the table that was ... This was my first time using the debugger and I found it to meet all my ... The most important reason for me to hide objects, ...
    (comp.databases.ms-access)
  • Re: Module level breakpoint filtering
    ... Sigh. ... sabotage this tool by littering it with hundreds of breakpoint designed ... What I actually meant is locating places in the target DLL where the ... Another way how this DLL can work fine without a debugger is by ...
    (microsoft.public.win32.programmer.kernel)
  • Re: real random
    ... The reason is because there is no way to keep the ... debugger out of a mainstream system -- i.e., ... By not showing the process that generates numbers? ...
    (comp.lang.c)
  • Re: Modifying the arguments to a function is a bad idea
    ... in the debugger you can go to the ... first line and restart the function to see how the crash happened ... For a small routine it can be a semi- ... converting to the more common form is trivial. ...
    (comp.lang.c)