Intro to writing kernel hooks
lnu...@gmail.com
driver to intercept filesystem calls. I'm well versed in VC++, but am
not sure where to begin writing a kernel hook. I know that the code
needs to run in Ring 0, which would indicate a device driver. This will
be a 32 bit program, so Vista's PatchGuard won't be a factor. Are there
any examples of kernel-level hooks and/or device drivers?
Don Burn
file system filters are designed to do, and then you have code that will
work on 64 bit and which will not show up a MALWARE on most spyware
scanners. Get the WDK which contains the IFS kit and samples, since this
is free and works on all systems from Windows 2000 to present.
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
<lnu...@gmail.com> wrote in message
news:1164843050.6...@n67g2000cwd.googlegroups.com...
lnu...@gmail.com
the fly" from a USB Disk, and from that point on, all user activity
(program installation, etc..) gets saved to the USB Disk, leaving
windows "untouched" except for the kernel driver. A user profile gets
loaded from the USB Disk (probably using the fast user switching). I
thought that to do this without windows freaking out, you need to do it
at the kernel level, instead of a user-mode level?
Don Burn
meaning in the kernel, and it is a programming practice that many people
are trying to abolish. The IFS kit will give you sample device drivers for
interacting with file system calls, in a blessed manor. You are probably
also going to have to catch registry calls, there is a function available
CmRegisterCallbacks that will allow you to catch registry operations.
Be aware this is a big project. First file systems work in general is
complex, second you need to interpose on a lot of operations to get things
correct.
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
<lnu...@gmail.com> wrote in message
news:1164893161....@l12g2000cwl.googlegroups.com...
anton bassov
> Be aware this is a big project. First file systems work in general is
> complex, second you need to interpose on a lot of operations to get things
> correct.
This is the main reason why people go for kernel hooking....
In fact, there are 2 possibilities why someone may consider doing it:
1. Necessity. Some things just cannot be done with FS filters. For
example, let's say you want to control section creation/access, and
your actions depend on *WHO* does it. Once fast IO FS operations go via
the Memory Manager, which works synchronously, you are more than likely
to lose the requestor's context by the time when your callback gets
invoked, so that FS filter is of no help here. Therefore, in order to
be sure that you don't lose the requestor's context, you may want to
hook API calls and do everything well before the request goes anywhere
close to the FS
2. "Convenience" - sometimes people may just want to avoid the
complexity of well-written
FS filter (in fact, they may just lack skills to write FS filter).
Unfortunately, in most cases the motivation for hooking is latter,
rather than the former - this is why hooking earned so bad
reputation......
Anton Bassov
Don Burn
"anton bassov" <soviet...@hotmail.com> wrote in message
> In fact, there are 2 possibilities why someone may consider doing it:
>
> 1. Necessity. Some things just cannot be done with FS filters. For
> example, let's say you want to control section creation/access, and
> your actions depend on *WHO* does it. Once fast IO FS operations go via
> the Memory Manager, which works synchronously, you are more than likely
> to lose the requestor's context by the time when your callback gets
> invoked, so that FS filter is of no help here. Therefore, in order to
> be sure that you don't lose the requestor's context, you may want to
> hook API calls and do everything well before the request goes anywhere
> close to the FS
>
> 2. "Convenience" - sometimes people may just want to avoid the
> complexity of well-written
> FS filter (in fact, they may just lack skills to write FS filter).
>
validation is so complex that using a mini-filter is easier. Any of the
currently available hooking examples open security holes that at least make
crashing the system trivial, and most allow buffer overflow attacks that
open the system to viruses.
As far as the "Necessity" argument this is true but in most cases if people
step back and look at the overall goals there are ways to handle this.
The problem is that people come up with development models then make them
requirements.
Pavel A.
> The problem is that people come up with development models then make them requirements.
A great observation. Thanks.
--PA
anton bassov
> And unfortunately the "convience" is bogus,
Fully agree with you -as you must have noticed, I had used this word in
quotation marks in my previous post. This is nothing more than just a
perceived convenience, which directly stems from the unwillingness to
do some extra job.
> Any of the currently available hooking examples open security holes
that at least make
> crashing the system trivial, and most allow buffer overflow attacks that
> open the system to viruses.
If someone is just too lazy to write a proper driver, and goes for
some "easier" way instead, would you expect this person to do a proper
validation???? As I have said in my previous post, in most cases
"convenience" is the reason why people use hooking - this is why the
technique in itself has, unfortunately, earned so bad reputation.
BTW, have you ever tried CISCO Secure Desktop? Please let me know if
you have any complaints about it - after all, this is also "an
available hooking example", at least
in the part that deals with detecting keyloggers
> As far as the "Necessity" argument this is true but in most cases if people
> step back and look at the overall goals there are ways to handle this.
Well, quite often people introduce some features to their products that
users could easily live
without. Therefore, this is just the question of how much some
particular feature is needed...
Anton Bassov
Don Burn
>> people
>> step back and look at the overall goals there are ways to handle this.
>
> Well, quite often people introduce some features to their products that
> users could easily live
> without. Therefore, this is just the question of how much some
> particular feature is needed...
>
putting implementation into goals. A classic on this is many anti-virus
products have as a goal "A virus will not run on this computer",
unfortunately this forces hooking, where the equally valid "A virus will be
terminated before any damage to the computer and its data", does not
require hooking. Unfortunately, the bozo's require the first one, and we
get crap.
anton bassov
>A classic on this is many anti-virus
> products have as a goal "A virus will not run on this computer",
> unfortunately this forces hooking, where the equally valid "A virus will be
> terminated before any damage to the computer and its data", does not
> require hooking.
If you mean prevention of execution of unauthrorized programs........
well, to be honest,
at this point I am already not so sure that hooking is the only
possible solution, at least under XP and above. Once we can achieve
everything solely by controlling/blocking section creation, and are not
concerned about the caller's identity, probably, we can get away with a
normal FS filter (namely, with PreAcquireForSectionSynchronization
callback). At this point I am not sure about the issues involved, but,
probably, it will work - I have to do some experimentation
Anton Bassov