Is hooking really evil ?

NTFSD
1

I decided I have ambitions to become a fashion hero as well, and the ever
ongoing discussions with the topic
‘is hooking evil ?’ have inspired me to write a great hooking analysis tool
for the paranoid among us.

It is called RootKit Hook Analyzer and it shows all kernel system services
with name, address, the responsible
kernel driver along with company name, product and description.

You can download it for free from
http://www.resplendence.com/hookanalyzer

Wishing you a feeling of security,

Daniel Terhell
Resplendence Software Projects

2

Daniel,

It is called RootKit Hook Analyzer and it shows all kernel system
services with name, address, the responsible
kernel driver along with company name, product and description.
Have you considered "cavity infection", jumptables in nonpaged pool
(untagged ;), jumptables in K-Mode DLLs as well? What about inline hooks?

Regards,

Oliver

--

May the source be with you, stranger :wink:

ICQ: #281645
URL: http://assarbad.net

3

On Nov 13, 2005, at 2:59 PM, Oliver Schneider wrote:

> It is called RootKit Hook Analyzer and it shows all kernel system
> services with name, address, the responsible
> kernel driver along with company name, product and description.
Have you considered “cavity infection”, jumptables in nonpaged pool
(untagged ;), jumptables in K-Mode DLLs as well? What about inline
hooks?

Good idea - while you’re at it, I just dealt with some commercial
software that ***modifies functions in the middle*** - couldya do
something about that too while you’re at it? :wink:

Steve Dispensa
MVP - Windows DDK
www.kernelmustard.com

4

“Oliver Schneider” wrote in message
news:xxxxx@ntfsd…
> Daniel,
>
>> It is called RootKit Hook Analyzer and it shows all kernel system
>> services with name, address, the responsible
>> kernel driver along with company name, product and description.
> Have you considered “cavity infection”, jumptables in nonpaged pool
> (untagged ;), jumptables in K-Mode DLLs as well? What about inline hooks?
>

It is just an ordinary dumper of the SSDT which checks the function
addresses and finds which modules are responsible for handling them. But I
think still better than the stuff out there which dumps registry hives to a
file and compares the results to the functioning of an API.

/Daniel

5

“Steve Dispensa” wrote in message
news:xxxxx@ntfsd…
> On Nov 13, 2005, at 2:59 PM, Oliver Schneider wrote:
>>> It is called RootKit Hook Analyzer and it shows all kernel system
>>> services with name, address, the responsible
>>> kernel driver along with company name, product and description.
>> Have you considered “cavity infection”, jumptables in nonpaged pool
>> (untagged ;), jumptables in K-Mode DLLs as well? What about inline
>> hooks?
>
> Good idea - while you’re at it, I just dealt with some commercial
> software that modifies functions in the middle - couldya do
> something about that too while you’re at it? :wink:
>

Thanks, tell me all about it.

/Daniel

6

Hooking isn’t really evil, MS does it!!! (waiting for obnoxious responses ;)) Unless someone can justify another reason for prefixing most OS functions (even non-exported ones) with mov edi, edi besides a five byte placeholder for a future call or jmp instruction, it appears as if MS is using inline hooks in its own flagship product, for a (somewhat) legitimate use

From: Steve Dispensa
> Date: 2005/11/13 Sun PM 04:23:02 EST
> To: “Windows File Systems Devs Interest List”
> Subject: Re: [ntfsd] Is hooking really evil ?
>
> On Nov 13, 2005, at 2:59 PM, Oliver Schneider wrote:
> >> It is called RootKit Hook Analyzer and it shows all kernel system
> >> services with name, address, the responsible
> >> kernel driver along with company name, product and description.
> > Have you considered “cavity infection”, jumptables in nonpaged pool
> > (untagged ;), jumptables in K-Mode DLLs as well? What about inline
> > hooks?
>
> Good idea - while you’re at it, I just dealt with some commercial
> software that modifies functions in the middle - couldya do
> something about that too while you’re at it? :wink:
>
>
>
> ----------------------------------
> Steve Dispensa
> MVP - Windows DDK
> www.kernelmustard.com
>
>
>
> —
> Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@ainfosec.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

7

Heh, this kinda looks like a prettier version of my last ‘don’t get bored on the plane’ project :wink:

There are public tools with and without source that do rootkit detection using more advanced methods than SSDT scanning. VICE is one which will check the first x bytes of each exported function in the main modules. Its far from perfect, but if you are seriously looking into this, its a start. In addition, there is also patchfinder for win2k, which does execution path analysis (and should detect modifying functions in the middle, which btw, is really really dumb unless you’ve done your homework on the function to be modified) I am also working on a more academic version of the EPA technique, which has the potential to catch malicious logic that can be executed without a hook into the OS.

Theres a lot out there, and its a very interesting field

From: “Daniel Terhell”
> Date: 2005/11/13 Sun PM 04:33:24 EST
> To: “Windows File Systems Devs Interest List”
> Subject: Re:[ntfsd] Is hooking really evil ?
>
>

8

wrote in message news:xxxxx@ntfsd…
> Hooking isn’t really evil, MS does it!!! (waiting for obnoxious responses
> ;)) Unless someone can justify another reason for prefixing most OS
> functions (even non-exported ones) with mov edi, edi besides a five byte
> placeholder for a future call or jmp instruction, it appears as if MS is
> using inline hooks in its own flagship product, for a (somewhat)
> legitimate use

Sound like we are getting there slowly. To me the new Win64 policy not
allowing hooking thus making impossible a whole class of development tools
and security products is nothing but a form of competition distortion.
Meanwhile it looks as if there are some evangelists on this list who are
getting paid to advocate these axis of evil conspiracy theories.

/Daniel

9

>>Meanwhile it looks as if there are some evangelists on this list who are

>getting paid to advocate these axis of evil conspiracy theories.

Keep your acusations for yourself, and dont talk whithout thinking.
If you have serious evidence ppl are payed to advocate whatever
thories, bring it forth. If not, shut up. I dont want to hear your
innuendos. You are damaging the reputation of some ppl.

Dan

----- Original Message -----
From: “Daniel Terhell”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Monday, November 14, 2005 3:42 PM
Subject: Re:[ntfsd] Re: Is hooking really evil ?

> wrote in message news:xxxxx@ntfsd…
>> Hooking isn’t really evil, MS does it!!! (waiting for obnoxious responses
>> ;)) Unless someone can justify another reason for prefixing most OS
>> functions (even non-exported ones) with mov edi, edi besides a five byte
>> placeholder for a future call or jmp instruction, it appears as if MS is
>> using inline hooks in its own flagship product, for a (somewhat)
>> legitimate use
>
> Sound like we are getting there slowly. To me the new Win64 policy not
> allowing hooking thus making impossible a whole class of development tools
> and security products is nothing but a form of competition distortion.
> Meanwhile it looks as if there are some evangelists on this list who are
> getting paid to advocate these axis of evil conspiracy theories.
>
> /Daniel
>
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to xxxxx@lists.osr.com

10

Just out of curiosity, who is advocating what axis of evil conspiracy theories?

Is it that this thread is populated mostly by Dans???

From: “Dan Partelly”
> Date: 2005/11/14 Mon AM 08:56:18 EST
> To: “Windows File Systems Devs Interest List”
> Subject: Re: Re:[ntfsd] Re: Is hooking really evil ?
>
> >>Meanwhile it looks as if there are some evangelists on this list who are
> >>getting paid to advocate these axis of evil conspiracy theories.
>
> Keep your acusations for yourself, and dont talk whithout thinking.
> If you have serious evidence ppl are payed to advocate whatever
> thories, bring it forth. If not, shut up. I dont want to hear your
> innuendos. You are damaging the reputation of some ppl.
>
> Dan
>
>
>
> ----- Original Message -----
> From: “Daniel Terhell”
> Newsgroups: ntfsd
> To: “Windows File Systems Devs Interest List”
> Sent: Monday, November 14, 2005 3:42 PM
> Subject: Re:[ntfsd] Re: Is hooking really evil ?
>
>
> > wrote in message news:xxxxx@ntfsd…
> >> Hooking isn’t really evil, MS does it!!! (waiting for obnoxious responses
> >> ;)) Unless someone can justify another reason for prefixing most OS
> >> functions (even non-exported ones) with mov edi, edi besides a five byte
> >> placeholder for a future call or jmp instruction, it appears as if MS is
> >> using inline hooks in its own flagship product, for a (somewhat)
> >> legitimate use
> >
> > Sound like we are getting there slowly. To me the new Win64 policy not
> > allowing hooking thus making impossible a whole class of development tools
> > and security products is nothing but a form of competition distortion.
> > Meanwhile it looks as if there are some evangelists on this list who are
> > getting paid to advocate these axis of evil conspiracy theories.
> >
> > /Daniel
> >
> >
> >
> >
> >
> > —
> > Questions? First check the IFS FAQ at
> > https://www.osronline.com/article.cfm?id=17
> >
> > You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@ainfosec.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

11

On Nov 14, 2005, at 7:25 AM,
wrote:

> Hooking isn’t really evil, MS does it!!! (waiting for obnoxious
> responses ;)) Unless someone can justify another reason for
> prefixing most OS functions (even non-exported ones) with mov edi,
> edi besides a five byte placeholder for a future call or jmp
> instruction, it appears as if MS is using inline hooks in its own
> flagship product, for a (somewhat) legitimate use

You mean hot patching?

http://msmvps.com/kernelmustard/archive/2005/04/25/44413.aspx

----------------------------------
Steve Dispensa
MVP - Windows DDK
www.kernelmustard.com

12

> Unless someone can justify another reason for prefixing most OS

functions (even non-exported ones) with mov edi, edi besides a
five byte placeholder for a future call or jmp instruction, it appears
as if MS is using inline hooks
Yes, it’s exactly what I was asking myself: why go to extremes?
Always “no” or always “yes” - why?

Take any other potential security threat, ActiveX or even ANY
software at all; the end user knows what’s going on (“Do you
want <…> to be installed?” plus “Signed by ABC, Inc.” plus
“No personal info will be sent” etc.

“It’s hard to predict, especially the future” (M.Twain). It is true
that to close the hooking hole completely might be better that
keeping it completely open, but IMHO the best solution is
somewhere in between: just (a) let the user know, and (b)
state your responsibility in some appropriate form.

As of now, you can install the user mode hooks [technically a
different kind of beast altogether, but the security considerations
apply] , including the kbd ones, through SetWindowsHook[Ex],
and there is no API to find out what UM hooks are currently installed.

I’d allow hooking, winpump or detour styled, but only along with
broadcasting any hook-install event and making all hooks
listable at all times.

----- Original Message -----
From:
To: “Windows File Systems Devs Interest List”
Sent: Monday, November 14, 2005 8:25 AM
Subject: Re: Re: [ntfsd] Is hooking really evil ?

> Hooking isn’t really evil, MS does it!!! (waiting for obnoxious responses
> ;)) Unless someone can justify another reason for prefixing most OS
> functions (even non-exported ones) with mov edi, edi besides a five byte
> placeholder for a future call or jmp instruction, it appears as if MS is
> using inline hooks in its own flagship product, for a (somewhat)
> legitimate use
>>
>> From: Steve Dispensa
>> Date: 2005/11/13 Sun PM 04:23:02 EST
>> To: “Windows File Systems Devs Interest List”
>> Subject: Re: [ntfsd] Is hooking really evil ?
>>
>> On Nov 13, 2005, at 2:59 PM, Oliver Schneider wrote:
>> >> It is called RootKit Hook Analyzer and it shows all kernel system
>> >> services with name, address, the responsible
>> >> kernel driver along with company name, product and description.
>> > Have you considered “cavity infection”, jumptables in nonpaged pool
>> > (untagged ;), jumptables in K-Mode DLLs as well? What about inline
>> > hooks?
>>
>> Good idea - while you’re at it, I just dealt with some commercial
>> software that modifies functions in the middle - couldya do
>> something about that too while you’re at it? :wink:
>>
>>
>>
>> ----------------------------------
>> Steve Dispensa
>> MVP - Windows DDK
>> www.kernelmustard.com
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@ainfosec.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@bellsouth.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

13

It is weird when someone else seems to know what you are thinking !!

I feel the same way every once in a while on this NG. Supposing that,
that is true, then remember that evangelists typically are part of a
system and they have “their” people working for them so it would be hard
to take on the whole system. However the best thing that has worked for
me is to ignore.

Meanwhile imagine how performance data is collected or driver
verification happens without “evil” hooking. Is MS promising not to have
any hooking in their components ? Is MS promising to obviate the need to
hook ? At this point all this sounds very similar to arguments that make
a country “evil” because they want to develop nuclear weapons because
they believe they can and others who tell them they are “evil”, have
done it before them. In any case, once the “evil” country has it, they
become “good” and repeat the same BS to the next enterprising “evil”
country.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Daniel Terhell
Sent: Monday, November 14, 2005 5:42 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Re: Is hooking really evil ?


To me the new Win64 policy not allowing hooking thus making impossible a
whole class of development tools and security products is nothing but a
form of competition distortion.
Meanwhile it looks as if there are some evangelists on this list who are
getting paid to advocate these axis of evil conspiracy theories.

/Daniel

14

Just out of curiousity how much do THEY pay?

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@ainfosec.com
Sent: Monday, November 14, 2005 9:03 AM
To: Windows File Systems Devs Interest List
Subject: Re: Re:[ntfsd] Re: Is hooking really evil ?

Just out of curiosity, who is advocating what axis of evil
conspiracy theories?

Is it that this thread is populated mostly by Dans???
>
> From: “Dan Partelly”
> > Date: 2005/11/14 Mon AM 08:56:18 EST
> > To: “Windows File Systems Devs Interest List”
> > Subject: Re: Re:[ntfsd] Re: Is hooking really evil ?
> >
> > >>Meanwhile it looks as if there are some evangelists on
> this list who
> > >>are getting paid to advocate these axis of evil
> conspiracy theories.
> >
> > Keep your acusations for yourself, and dont talk whithout thinking.
> > If you have serious evidence ppl are payed to advocate whatever
> > thories, bring it forth. If not, shut up. I dont want to hear your
> > innuendos. You are damaging the reputation of some ppl.
> >
> > Dan
> >
> >
> >
> > ----- Original Message -----
> > From: “Daniel Terhell”
> > Newsgroups: ntfsd
> > To: “Windows File Systems Devs Interest List”
> > Sent: Monday, November 14, 2005 3:42 PM
> > Subject: Re:[ntfsd] Re: Is hooking really evil ?
> >
> >
> > > wrote in message news:xxxxx@ntfsd…
> > >> Hooking isn’t really evil, MS does it!!! (waiting for obnoxious
> > >> responses
> > >> ;)) Unless someone can justify another reason for
> prefixing most
> > >> OS functions (even non-exported ones) with mov edi, edi
> besides a
> > >> five byte placeholder for a future call or jmp instruction, it
> > >> appears as if MS is using inline hooks in its own
> flagship product,
> > >> for a (somewhat) legitimate use
> > >
> > > Sound like we are getting there slowly. To me the new
> Win64 policy
> > > not allowing hooking thus making impossible a whole class of
> > > development tools and security products is nothing but a
> form of competition distortion.
> > > Meanwhile it looks as if there are some evangelists on
> this list who
> > > are getting paid to advocate these axis of evil
> conspiracy theories.
> > >
> > > /Daniel
> > >
> > >
> > >
> > >
> > >
> > > —
> > > Questions? First check the IFS FAQ at
> > > https://www.osronline.com/article.cfm?id=17
> > >
> > > You are currently subscribed to ntfsd as:
> xxxxx@rdsor.ro To
> > > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> > —
> > Questions? First check the IFS FAQ at
> > https://www.osronline.com/article.cfm?id=17
> >
> > You are currently subscribed to ntfsd as: xxxxx@ainfosec.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as:
> xxxxx@hollistech.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>