HI all,
almost all of us know about filemon. I have a question.
Is it not possible to replicate this tool without an FSFD?
If I need to display file names being opened, closed, deleted etc, is there
no other way of achieving this?
Bedanto
There is no way other than a file system filter that will not destabilize
the system, and cause you to be despised in the Windows community.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
“Bedanto” wrote in message news:xxxxx@ntdev…
HI all,
almost all of us know about filemon. I have a question.
Is it not possible to replicate this tool without an FSFD?
If I need to display file names being opened, closed, deleted etc, is there
no other way of achieving this?
Bedanto
Don,
Thanks for the suggestion. I was myself inclined towards the same. You have
always advices against hooking, I have read your posts regarding the same
and with my limited knowledge and understanging, I do understand the
pitfalls. You have told many a times, that microsoft is trying to stop
people from hooking, however, if I am not mistaken, debuggers also work in
the same principle, how are they then going to function?
Bedanto
The only debugger that uses hooking is SoftIce (which some could argue does
not function anyway). While I argue against hooking, this is one of those
things you have to make a decision on based on your customers and product.
Debugging tools are a different category than a general commercial product.
For instance IrpTracker hooks things, but most of us realize there are risks
in its use, but the value of the tool is worth it.
What I do take exception with, are the folks who hook things because they
are too lazy to do it right. With the PsSetXXXNotifyRoutine functions for
processes and threads, the CmRegisterCallback for registry functions, and
filter drivers for many other cases, much of the hooking is because people
won’t bother to do it right, or do not think about the problem so insist
they have to hook.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
“Bedanto” wrote in message news:xxxxx@ntdev…
Don,
Thanks for the suggestion. I was myself inclined towards the same. You have
always advices against hooking, I have read your posts regarding the same
and with my limited knowledge and understanging, I do understand the
pitfalls. You have told many a times, that microsoft is trying to stop
people from hooking, however, if I am not mistaken, debuggers also work in
the same principle, how are they then going to function?
Bedanto
>For instance IrpTracker hooks things, but most of us realize there are
risks
in its use, but the value of the tool is worth it.
Don, just a few hours ago in another thread it was posted by daniel that the
latest irp tracker doesn’t use hooking at all. Can you through some light as
to how else it is possible??? For your reference, here is the original post.
One way to do this is to hook system calls such as ZwDeviceIoControlFile,
ZwReadFile and ZwWriteFile however this will not catch communication
between
drivers like those calling IoCallDriver. Also there must be more elegant
ways to achieve this, I noticed that v1.30 of IrpTracker never used any
type
of system call hooking at all.
amitr0
>The only debugger that uses hooking is SoftIce.
Sir, I have very limited knowledge, apologies for the same, then how does
Windbg and visual studio debuggers work, how do they connect to an
application that is running, or open an exe and load it.
Debugging tools are a different category than a general commercial product.
Well, if microsoft has deviced a way of disallowing hooking, then how does
one write such an application?
bedanto
IrpTracker has never used system call hooking AFAIK. It does hook some
system service routines like IoCallDriver, remember there are many types of
hooking.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
“amitr0” wrote in message news:xxxxx@ntdev…
>For instance IrpTracker hooks things, but most of us realize there are
risks
>in its use, but the value of the tool is worth it.
Don, just a few hours ago in another thread it was posted by daniel that the
latest irp tracker doesn’t use hooking at all. Can you through some light as
to how else it is possible??? For your reference, here is the original post.
>One way to do this is to hook system calls such as ZwDeviceIoControlFile,
>ZwReadFile and ZwWriteFile however this will not catch communication
between
>drivers like those calling IoCallDriver. Also there must be more elegant
>ways to achieve this, I noticed that v1.30 of IrpTracker never used any
type
>of system call hooking at all.
amitr0
There are API’s for debugging user processes, this is how VS works. The
kernel debugger uses interfaces that Microsoft designed for itself (note:
most kernels do this). As far as writing your own kernel debugging tools,
if you work hard enough you can hook.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
“Bedanto” wrote in message news:xxxxx@ntdev…
>The only debugger that uses hooking is SoftIce.
Sir, I have very limited knowledge, apologies for the same, then how does
Windbg and visual studio debuggers work, how do they connect to an
application that is running, or open an exe and load it.
>Debugging tools are a different category than a general commercial product.
Well, if microsoft has deviced a way of disallowing hooking, then how does
one write such an application?
bedanto
well, then probably the original poster is probably mistaken.
Thanks again don.
Just wondering…
In api hooking, we always try to hook the IAT of the DLLs. This means that
we essentially patch only the calls made by the hooked process. What if i
want to hook into a dll system wide from user land. Can I use EAT of the
original dll (say ntdll.dll) for this purpose, so that who so ever loads
that dll will actually get the addresses of my functions.
ofcourse, there has to be a way of loading my patcher before any such calls,
and keep it resident in memory, but this beiing a theoritical situation
(never to be implemented by me) this aspect doesnt matter. I think, if this
is possible, then it would make hooked code cleaner and easier to maintian
also.
I rarely pop into user space, and then only for things like test programs,
DLL and services to support my kernel drivers. Hopefully someone else on
the list can answer this.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
“Bedanto” wrote in message news:xxxxx@ntdev…
Thanks again don.
Just wondering…
In api hooking, we always try to hook the IAT of the DLLs. This means that
we essentially patch only the calls made by the hooked process. What if i
want to hook into a dll system wide from user land. Can I use EAT of the
original dll (say ntdll.dll) for this purpose, so that who so ever loads
that dll will actually get the addresses of my functions.
ofcourse, there has to be a way of loading my patcher before any such calls,
and keep it resident in memory, but this beiing a theoritical situation
(never to be implemented by me) this aspect doesnt matter. I think, if this
is possible, then it would make hooked code cleaner and easier to maintian
also.
I have 3 words for you: Copy on Write. Read about them. Is definievly possible to do global hooking in user mode, but beware of copy on write.
Dan
----- Original Message -----
From: Bedanto
To: Windows System Software Devs Interest List
Sent: Friday, December 23, 2005 4:18 PM
Subject: Re: [ntdev] filemon tool
Thanks again don.
Just wondering…
In api hooking, we always try to hook the IAT of the DLLs. This means that we essentially patch only the calls made by the hooked process. What if i want to hook into a dll system wide from user land. Can I use EAT of the original dll (say ntdll.dll) for this purpose, so that who so ever loads that dll will actually get the addresses of my functions.
ofcourse, there has to be a way of loading my patcher before any such calls, and keep it resident in memory, but this beiing a theoritical situation (never to be implemented by me) this aspect doesnt matter. I think, if this is possible, then it would make hooked code cleaner and easier to maintian also.
— Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank email to xxxxx@lists.osr.com
>While I argue against hooking, this is one of those
things you have to make a decision on based on your customers and product.
Debugging tools are a different category than a general commercial product.
Sir Don,
does this mean, that microsoft will never stop hooking, as there will always
be some need to do some “holy” work through them?
amitr0
You are in the kernel, so you have access to almost everything. Microsoft
has made it harder to hook and I am sure will continue to do so, but it is
too much to expect with the current architecture to stop hooking completely.
Hopefully, Microsoft will work with the developer community and provide ways
to support debugging capabilites.
But just because you can, does not mean you should.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
“amitr0” wrote in message news:xxxxx@ntdev…
>While I argue against hooking, this is one of those
>things you have to make a decision on based on your customers and product.
>Debugging tools are a different category than a general commercial product.
Sir Don,
does this mean, that microsoft will never stop hooking, as there will always
be some need to do some “holy” work through them?
amitr0
Bedanto,
Thanks again don.
Just wondering…
In api hooking, we always try to hook the IAT of the DLLs. This means that
we essentially patch >only the calls made by the hooked process. What if i
want to hook into a dll system wide from user
land. Can I use EAT of the original dll (say ntdll.dll) for this purpose,
so that who so ever loads that
dll will actually get the addresses of my functions.
ofcourse, there has to be a way of loading my patcher before any such
calls, and keep it resident in
memory, but this beiing a theoritical situation (never to be implemented by
me) this aspect doesnt
matter. I think, if this is possible, then it would make hooked code
cleaner and easier to maintian >also.
It certainly looks simpler to implement, no doubt. Patching the export table
is not very difficult and brings some interesting results: All new linkings
(both static and dynamic - unlike IAT hooking, where you have you use
Ritcher’s technique to achieve dynamic linking) to the patched API will
automatically be bound to your callback function instead of to the original
function. That’s very nice! Well, but unfortunately patching an export table
has absolutely NO effect on already existing API linkings (e.g. static
bindings of already loaded DLLs). So using export table patching alone is
only of quite restricted use. Besides, undoing the patch has again no effect
on past bindings. So you can’t really undo an API hook which was established
by export table patching.
You should not patch the export table of DLLs which are loaded in the shared
area of win9x. Also you should not patch the export table of DLLs, which are
not loaded there, but have a shared export table nevertheless. If you do
that, you risk system stability again.
These are all observations of my own, I am sure experts in this group will
be able to guide you better. I would still recommend to do away with hooks
if you can.
amitr0
wow amitr0, that was good…but why doesn’t IAT hooking work for dynamic
linking?
bedanto
>wow amitr0, that was good…but why doesn’t IAT hooking work for dynamic
linking?
because only the statically linked API calls go through the import table.
Dynamically linked API calls (GetProcAddress) are not caught by this method
at all. It is quite probable that you’ll miss some API calls when using this
method.
To reduce this, you need to patch the import table of the application’s
module & also the import tables of each and every DLL that is loaded by the
application. However, you must not patch the import tables of win9x shared
DLLs, because this could eventually make other processes crash.
Also some DLLs have a shared import table, even though they are not located
in the shared area. Eg. “winspool.drv”.
There are some ways to make “Import Table Patching” catch more APIs. You can
hook the API “LoadLibrary” to be notified about when new DLLs are loaded.
This is what ritcher does, then you can right away patch those DLLs, too. If
you don’t do that, you won’t catch API calls that are made from DLLs, which
are loaded after you did install the hook.
Another extension is to hook the API “GetProcAddress” and then when called
not return the real API address, but the address of your callback function
instead. This way you would also get those API calls, that are dynamically
linked after you’ve installed your hook. Unfortunately if you do this, you
can’t unhook such calls, anymore.
good luck
amitr0
Don,
Sir, so much so said about the evils and goods of hooking. I have a question
to ask to you and to all experienced people out here.
FOrgetting everything else, and just considering plain performance, if I can
get a job done either by hooking or by writing a filter driver, which one is
better?
Eg. I can get the file names opened by an app through IRPs and well as
hooking CreateFile api in user mode. Is there a way I can measure the
performance of these two techniques peoperly to find out which one works
better. Or if some one already knows it, can you pleae tell me.
Thanks and regards
Amitr0
PS:- WIsh all of you a very very merry X-mas in advance…
I’m sure someone will argue differently, but I have found the performance
difference in the noise level. Yes, even though I speak out against
hooking, I have done one of the biggest hooking drivers out there, so I have
been there.
Now with performance being essentially the same, you have to ask why would
you hook when:
- Once you hook you can never unhook.
- Many of the calls are undocumented, or have undocumented flags or
options. - Any good Anti-MALWARE tool will list you forever as something to
avoid at all costs. - Microsoft will never give you support for hooking.
These are just a few highlights, there are many more.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
“amitr0” wrote in message news:xxxxx@ntdev…
Don,
Sir, so much so said about the evils and goods of hooking. I have a question
to ask to you and to all experienced people out here.
FOrgetting everything else, and just considering plain performance, if I can
get a job done either by hooking or by writing a filter driver, which one is
better?
Eg. I can get the file names opened by an app through IRPs and well as
hooking CreateFile api in user mode. Is there a way I can measure the
performance of these two techniques peoperly to find out which one works
better. Or if some one already knows it, can you pleae tell me.
Thanks and regards
Amitr0
PS:- WIsh all of you a very very merry X-mas in advance…
This guy was asking about user mode hooks, patching import tables and that
stuff, not kernel hooks. As for anti-malware tools that does not allow for
system call hooking, my rootkit hook analyzer shows it is very difficult to
find any antivirus tool that doesn’t do it itself.
happy christmas,
/Daniel
“Don Burn” wrote in message news:xxxxx@ntdev…
> I’m sure someone will argue differently, but I have found the performance
> difference in the noise level. Yes, even though I speak out against
> hooking, I have done one of the biggest hooking drivers out there, so I
> have been there.
>
> Now with performance being essentially the same, you have to ask why would
> you hook when:
>
> 1. Once you hook you can never unhook.
> 2. Many of the calls are undocumented, or have undocumented flags or
> options.
> 3. Any good Anti-MALWARE tool will list you forever as something to
> avoid at all costs.
> 4. Microsoft will never give you support for hooking.