Notify when system time changes

NTDEV
1

Hello, I want my driver to get notified as soon as the system time changed.
I have successfully hooked ZwSetSystemTime using KeServiceDescriptorTable.
But now I read this technique is deprecated !

Microsoft has only provided callbacks for process creation, thread creation,
binary image loading but not for system settings changes. There is no filter
driver I can use for this purpose or any user mode solution.

And what about all those many other events that a programmer may want to
trap ? System call or interrupt hooking is a very fundamental principle
which has existed on every platform I have ever worked on. Why now
deprecated ? Writing a filter driver is very laborious and achieves only one
single goal. What if you need to monitor monitor system, file, registry,
network and more ? End up with a large bunch of filter drivers and five
callback routines ?

Am I really missing something here ? I personally think Microsoft is closing
an eye on this, otherwise why would they publish the KeServiceDescriptor
Table symbol it in ntoskrnl.exe ? I think Microsoft would do a very good job
in documenting this and should have provided a good interface many years
ago.

I read system call hooking should never be used in a commercial product,
does this mean we have to leave the unwritable apps up to MS ?

Thanks for the help

Daniel Terhell

2

Now, I don’t know what you’re trying to achieve, but I believe that it would
be fairly trivial to do something like:

{
GetCurrentTime(&time1);
Sleep_One_Second();
GetCurrentTime(&time2);
if (time1 - time2 < 0 || time1 - time2 > ((12 * OneSecond) / 10))
{
TimeHasChanged();
}
}

Some of the problem with system call hooking is:

  1. It’s hard to uninstall (what if you uninstall while another function is
    currently executing the code, esp. on multiprocessor machines).
  2. It makes unpredictable changes to system calls, because some flavours of
    the OS may do things
    different than others, and MS may have different solutions to corner cases
    or strange parameters than the hooked function, and this all causes
    problems.

–
Mats

-----Original Message-----
From: Daniel Terhell [mailto:xxxxx@resplendence.com]
Sent: Tuesday, June 15, 2004 12:04 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Notify when system time changes

Hello, I want my driver to get notified as soon as the system
time changed.
I have successfully hooked ZwSetSystemTime using
KeServiceDescriptorTable.
But now I read this technique is deprecated !

Microsoft has only provided callbacks for process creation,
thread creation,
binary image loading but not for system settings changes.
There is no filter
driver I can use for this purpose or any user mode solution.

And what about all those many other events that a programmer
may want to
trap ? System call or interrupt hooking is a very fundamental
principle
which has existed on every platform I have ever worked on. Why now
deprecated ? Writing a filter driver is very laborious and
achieves only one
single goal. What if you need to monitor monitor system,
file, registry,
network and more ? End up with a large bunch of filter
drivers and five
callback routines ?

Am I really missing something here ? I personally think
Microsoft is closing
an eye on this, otherwise why would they publish the
KeServiceDescriptor
Table symbol it in ntoskrnl.exe ? I think Microsoft would do
a very good job
in documenting this and should have provided a good interface
many years
ago.

I read system call hooking should never be used in a
commercial product,
does this mean we have to leave the unwritable apps up to MS ?

Thanks for the help

Daniel Terhell

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Thanks a lot for your answer. However do you mean I have to constantly check
the system time using a timer and check if the system time did not change
more than the probable interval ? Would you recommend system setting and
file and registry monitoring in the same manner ? One drawback I can mention
is that you are chasing after events and do not trap them in time and
another that it introduces complexity of programming as well as a use up of
system resources.

Can the uninstall problem not be solved by using a spinlock while accessing
the system call table ? Note that if you use ‘official’ create process
notify callbackroutines then your driver also must remain loaded until the
system shuts down. About your second anwer I think you are right but
Microsoft would do a good job publishing and documenting its entire kernel
library and make sure it the functions remain fully backward compatible as
well consistency in they way parameters are used.

/Daniel

wrote in message news:xxxxx@ntdev…
> Now, I don’t know what you’re trying to achieve, but I believe that it
would
> be fairly trivial to do something like:
>
> {
> GetCurrentTime(&time1);
> Sleep_One_Second();
> GetCurrentTime(&time2);
> if (time1 - time2 < 0 || time1 - time2 > ((12 * OneSecond) / 10))
> {
> TimeHasChanged();
> }
> }
>
> Some of the problem with system call hooking is:
> 1. It’s hard to uninstall (what if you uninstall while another function is
> currently executing the code, esp. on multiprocessor machines).
> 2. It makes unpredictable changes to system calls, because some flavours
of
> the OS may do things
> different than others, and MS may have different solutions to corner cases
> or strange parameters than the hooked function, and this all causes
> problems.
>

4

> Thanks a lot for your answer. However do you mean I have to

constantly check
the system time using a timer and check if the system time
did not change
more than the probable interval ? Would you recommend system
setting and
file and registry monitoring in the same manner ? One
drawback I can mention
is that you are chasing after events and do not trap them in time and
another that it introduces complexity of programming as well
as a use up of
system resources.

I was suggesting that you’d check the time that way, and yes, you wouldn’t
catch the fact that someone is changing the time WHEN that happens, but
afterwards. Since you didn’t explain WHY you would be interested in the
change of time in the system, it was not possible to predict that you wanted
to know about it and prevent it from happening (for instance).

Further to that, have you considered the fact that the time can also be
changed by the BIOS setup screen, which is accessible without control from
Windows. I would have thought having a time server set up and a client
application that frequently asks the time server for the current time and
updates the time would be a preferred way. That way you always have a
currently correct time (and consistent for a bunch of machines, if within a
company).

I believe there are standard methods for detecting registry changes (but I
could be wrong, I don’t do those sort of things, I do graphics drivers). For
file changes, that’s exactly why there is a concept of file system filter
drivers, unless I’ve completley misunderstood the concept.

Can the uninstall problem not be solved by using a spinlock
while accessing
the system call table ? Note that if you use ‘official’ create process
notify callbackroutines then your driver also must remain
loaded until the
system shuts down. About your second anwer I think you are right but
Microsoft would do a good job publishing and documenting its
entire kernel
library and make sure it the functions remain fully backward
compatible as
well consistency in they way parameters are used.

If MS really wanted us to add functions on top of the existing system call
table, they would have a way of modifying it in a “legal way”. Then there
would be a “safe way to remove” a override too.

Regarding the documentation: One of the big problems in system development
(whether it be MS or Linux or some other product) is that the more you
document exactly how something works internally, the less flexibility you
get to change it later on. This may not be a problem with the particular
examples you’ve been looking at, but I’m certainly aware that there can be
problems when the internal architecture of the function is changes. For
example, say someone is relying on a HANDLE always being a pointer, and the
OS start using it as a numeric index per process instead, then the hash
function that ignores the lower 5 bits of the handle will cause a BIG
problem. [Silly example maybe, but you get the idea].

–
Mats

/Daniel

wrote in message news:xxxxx@ntdev…
> > Now, I don’t know what you’re trying to achieve, but I
> believe that it
> would
> > be fairly trivial to do something like:
> >
> > {
> > GetCurrentTime(&time1);
> > Sleep_One_Second();
> > GetCurrentTime(&time2);
> > if (time1 - time2 < 0 || time1 - time2 > ((12 * OneSecond) / 10))
> > {
> > TimeHasChanged();
> > }
> > }
> >
> > Some of the problem with system call hooking is:
> > 1. It’s hard to uninstall (what if you uninstall while
> another function is
> > currently executing the code, esp. on multiprocessor machines).
> > 2. It makes unpredictable changes to system calls, because
> some flavours
> of
> > the OS may do things
> > different than others, and MS may have different solutions
> to corner cases
> > or strange parameters than the hooked function, and this all causes
> > problems.
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

Actually they do and it is documented, read the DDK on ExCreateCallback and
in particular about “\Callback\SetSystemTime” which does what you want.
This has been available since Windows 2000, so you should have been able to
find it.

As far as system call hooking being a fundemental principle, I know a number
of systems that detected this and took action with a vengenance. At least
one minicomputer company disabled the product, then logged the data on the
product, their system support people would get the log, and send a letter to
all customers saying you thirty days to remove all products from that firm
or have your warranty voided!

Microsoft is providing mechanisms for ones they see needs for, and yes they
are sympathethic to requests for additional ones, so if you have more needs
tell them.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting

“Daniel Terhell” wrote in message
news:xxxxx@ntdev…
> Hello, I want my driver to get notified as soon as the system time
changed.
> I have successfully hooked ZwSetSystemTime using KeServiceDescriptorTable.
> But now I read this technique is deprecated !
>
> Microsoft has only provided callbacks for process creation, thread
creation,
> binary image loading but not for system settings changes. There is no
filter
> driver I can use for this purpose or any user mode solution.
>
> And what about all those many other events that a programmer may want to
> trap ? System call or interrupt hooking is a very fundamental principle
> which has existed on every platform I have ever worked on. Why now
> deprecated ? Writing a filter driver is very laborious and achieves only
one
> single goal. What if you need to monitor monitor system, file, registry,
> network and more ? End up with a large bunch of filter drivers and five
> callback routines ?
>
> Am I really missing something here ? I personally think Microsoft is
closing
> an eye on this, otherwise why would they publish the KeServiceDescriptor
> Table symbol it in ntoskrnl.exe ? I think Microsoft would do a very good
job
> in documenting this and should have provided a good interface many years
> ago.
>
> I read system call hooking should never be used in a commercial product,
> does this mean we have to leave the unwritable apps up to MS ?
>
> Thanks for the help
>
> Daniel Terhell
>
>
>

6

What about when the user boots to DOS on a floppy disk and changes the
time?

Chuck

----- Original Message -----
From: “Daniel Terhell”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Tuesday, June 15, 2004 6:04 PM
Subject: [ntdev] Notify when system time changes

> Hello, I want my driver to get notified as soon as the system time
changed.
> I have successfully hooked ZwSetSystemTime using
KeServiceDescriptorTable.
> But now I read this technique is deprecated !
>
> Microsoft has only provided callbacks for process creation, thread
creation,
> binary image loading but not for system settings changes. There is no
filter
> driver I can use for this purpose or any user mode solution.
>
> And what about all those many other events that a programmer may want
to
> trap ? System call or interrupt hooking is a very fundamental
principle
> which has existed on every platform I have ever worked on. Why now
> deprecated ? Writing a filter driver is very laborious and achieves
only one
> single goal. What if you need to monitor monitor system, file,
registry,
> network and more ? End up with a large bunch of filter drivers and
five
> callback routines ?
>
> Am I really missing something here ? I personally think Microsoft is
closing
> an eye on this, otherwise why would they publish the
KeServiceDescriptor
> Table symbol it in ntoskrnl.exe ? I think Microsoft would do a very
good job
> in documenting this and should have provided a good interface many
years
> ago.
>
> I read system call hooking should never be used in a commercial
product,
> does this mean we have to leave the unwritable apps up to MS ?
>
> Thanks for the help
>
> Daniel Terhell
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@cbatson.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

7

Thanks, I really should not have missed that one. However I think there is
still a long way to go before they really can say there is no more need for
system call hooking and scrap it. I really hope they do it in the far
future after AMD64 support and LongHorn.

For example I think it should be possible to trap if applications are
setting user mode hooks. There is something like a WH_DEBUG hook to monitor
other hooks but it does not see the low level ones. I would like to create
an application for internet cafes that can guarantee the visitors that no
keyboard loggers are installed in any way. I can check what devices are
attached to the keyboard device but in order to detect the user mode hooks I
need to use the load image notify routine to see what DLLs get injected in
what processes which is very messy. I think there should come a callback
for when DLLs are injected into running processes as well as one for user
mode hooks. My best ideas so far are hooking ZwLockVirtualMemory,
ZwProtectVirtualMemory, ZwWriteVirtualMemory and ZwFlushInstructionCache.
For the low level hook functions, they do not inject anything but all call
some undocumented system call function with a high number which is not
exported by NTDLL.

I would very much like to create a list of callbacks which would make it
possible to develop applications which are currently impossible to write or
without the need of undocumented funtions. Do you think it’s a good idea to
post them here or should I use the DDK feedback ?

Regards, Daniel

“Don Burn” wrote in message news:xxxxx@ntdev…
> Actually they do and it is documented, read the DDK on ExCreateCallback
and
> in particular about “\Callback\SetSystemTime” which does what you want.
> This has been available since Windows 2000, so you should have been able
to
> find it.
>
> As far as system call hooking being a fundemental principle, I know a
number
> of systems that detected this and took action with a vengenance. At least
> one minicomputer company disabled the product, then logged the data on the
> product, their system support people would get the log, and send a letter
to
> all customers saying you thirty days to remove all products from that firm
> or have your warranty voided!
>
> Microsoft is providing mechanisms for ones they see needs for, and yes
they
> are sympathethic to requests for additional ones, so if you have more
needs
> tell them.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>

8

Comments inline:

“Daniel Terhell” wrote in message
news:xxxxx@ntdev…
> Thanks, I really should not have missed that one. However I think there is
> still a long way to go before they really can say there is no more need
for
> system call hooking and scrap it. I really hope they do it in the far
> future after AMD64 support and LongHorn.

I have heard discussions that they may make it very hard with Longhorn.

>
> I would very much like to create a list of callbacks which would make it
> possible to develop applications which are currently impossible to write
or
> without the need of undocumented funtions. Do you think it’s a good idea
to
> post them here or should I use the DDK feedback ?
>
I would post them here first, there may be techiniques to work around them,
or refinements to your ideas may be suggested. Once something is well
thrashed out definitely send it to the DDK feedback alias.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting

9

> For example I think it should be possible to trap if applications are

setting user mode hooks.

Good idea :slight_smile: setting a hook to prevent hooks :slight_smile: the hooking nightmare :slight_smile:

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

10

> I would very much like to create a list of callbacks which

would make it
possible to develop applications which are currently
impossible to write or
without the need of undocumented funtions. Do you think it’s
a good idea to
post them here or should I use the DDK feedback ?

I’d suggest you post them here AND use the DDK feedback. One doesn’t replace
the other in this instance. And others on this list could benefit from
seeing what your ideas are, and maybe add their views.

–
Mats

Regards, Daniel

“Don Burn” wrote in message news:xxxxx@ntdev…
> > Actually they do and it is documented, read the DDK on
> ExCreateCallback
> and
> > in particular about “\Callback\SetSystemTime” which does
> what you want.
> > This has been available since Windows 2000, so you should
> have been able
> to
> > find it.
> >
> > As far as system call hooking being a fundemental
> principle, I know a
> number
> > of systems that detected this and took action with a
> vengenance. At least
> > one minicomputer company disabled the product, then logged
> the data on the
> > product, their system support people would get the log, and
> send a letter
> to
> > all customers saying you thirty days to remove all products
> from that firm
> > or have your warranty voided!
> >
> > Microsoft is providing mechanisms for ones they see needs
> for, and yes
> they
> > are sympathethic to requests for additional ones, so if you
> have more
> needs
> > tell them.
> >
> >
> > –
> > Don Burn (MVP, Windows DDK)
> > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

11

There was already such a thing, it’s called a WH_DEBUG hook. The idea was
good but it’s nightmare is that it does only half a job.

/Daniel

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
> > For example I think it should be possible to trap if applications are
> > setting user mode hooks.
>
> Good idea :slight_smile: setting a hook to prevent hooks :slight_smile: the hooking nightmare
:slight_smile:
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>

12

The only way to solve problems like this is with hardware support, which
is where NGSCB comes in.

The problem with your scheme is that any facility that you have access
to is also accessible by the hackers. So you end up in an arms race that
reduces overall stability without providing any benefit.

For example, if you install some hook that allows finding out whether
there is a keyboard hook installed, what prevents someone from hooking
after your hook? Aha, you say, I’ll just check at run time. What
prevents them from hooking the function you use to check for hooks and
not reporting themselves as being present?

You can chase this down forever, but the fundamental problem is that the
hacker only has to break existing detection schemes, which they can
analyze at their leisure, whereas you have to somehow anticipate all
possible hacks. It’s not a solvable problem unless you have true
hardware support with software attestation done in the hardware and true
process isolation.

The more fundamental problem with system hooks is hook conflicts. Even
if MS documents all that they do, they can’t possibly document
everything that every hook out there might do, and so it’s impossible to
have a stable interface by definition. This is why people say it’s only
acceptable for a non-commercial environment. If you have complete
control over all the hooks installed, you can ensure/test for their
compatibility. If it’s a commercial product, there’s no way to do this.

People that want system hooking typically are only thinking short term,
and only of themselves/their application. I don’t see any reason to
encourage them.

Daniel Terhell wrote:

Thanks, I really should not have missed that one. However I think there is
still a long way to go before they really can say there is no more need for
system call hooking and scrap it. I really hope they do it in the far
future after AMD64 support and LongHorn.

For example I think it should be possible to trap if applications are
setting user mode hooks. There is something like a WH_DEBUG hook to monitor
other hooks but it does not see the low level ones. I would like to create
an application for internet cafes that can guarantee the visitors that no
keyboard loggers are installed in any way. I can check what devices are
attached to the keyboard device but in order to detect the user mode hooks I
need to use the load image notify routine to see what DLLs get injected in
what processes which is very messy. I think there should come a callback
for when DLLs are injected into running processes as well as one for user
mode hooks. My best ideas so far are hooking ZwLockVirtualMemory,
ZwProtectVirtualMemory, ZwWriteVirtualMemory and ZwFlushInstructionCache.
For the low level hook functions, they do not inject anything but all call
some undocumented system call function with a high number which is not
exported by NTDLL.

I would very much like to create a list of callbacks which would make it
possible to develop applications which are currently impossible to write or
without the need of undocumented funtions. Do you think it’s a good idea to
post them here or should I use the DDK feedback ?

Regards, Daniel

“Don Burn” wrote in message news:xxxxx@ntdev…
>
>>Actually they do and it is documented, read the DDK on ExCreateCallback
>
> and
>
>>in particular about “\Callback\SetSystemTime” which does what you want.
>>This has been available since Windows 2000, so you should have been able
>
> to
>
>>find it.
>>
>>As far as system call hooking being a fundemental principle, I know a
>
> number
>
>>of systems that detected this and took action with a vengenance. At least
>>one minicomputer company disabled the product, then logged the data on the
>>product, their system support people would get the log, and send a letter
>
> to
>
>>all customers saying you thirty days to remove all products from that firm
>>or have your warranty voided!
>>
>>Microsoft is providing mechanisms for ones they see needs for, and yes
>
> they
>
>>are sympathethic to requests for additional ones, so if you have more
>
> needs
>
>>tell them.
>>
>>
>>–
>>Don Burn (MVP, Windows DDK)
>>Windows 2k/XP/2k3 Filesystem and Driver Consulting
>>
>
>
>
>

–
…/ray..

Please remove “.spamblock” from my email address if you need to contact
me outside the newsgroup.

13

There’s an additional problem with hooks that we don’t talk about as
much, and that has to do with extending an API.

Say, for example, that you wanted to catch every read and write an
applications perform. So you hook NtCreateFile (so you can figure out
which handles are to files, NtReadFile and NtWriteFile (we’ll ignore the
problem of memory-mapped I/O for now) and NtClose (so you can cleanup
when the handle is closed). You’re now able to see every read & write
and you’re happy.

What happens to your scheme when we extend the IO NT APIs in the next
release (or service pack - we do sometimes enable new features there),
and provide something like Nt[Read|Write]FileScatterGather? Now there’s
a read/write path that you aren’t hooking. If you were just doing
logging that may be okay, but if you decided to provide data encryption
with a sys-call hooker then your customers are now screwed until you can
get an update together. Whereas if you were filtering above the file
system you would have seen a READ irp come through and could have
processed it.

In order to enable filtering, it has to be done at a point in the system
which will remain relatively stable over time. The IRP interface to
drivers is one such interface, in contrast with the NT or Win32 APIs
which tend to grow over time. The other reliable alternative is to
provide callbacks where we can to notify some third-party component of
changes in the kernel’s internal state - things like the process
creation callbacks. We can then make sure that we invoke the callbacks
where appropriate in the new system calls (or the code they call).

I doubt this is a windows only thing, but it’s been a long time since
I’ve looked at the source for any other OS so couldn’t really tell you
today. I don’t see hooking an evolving API as a stable long-term
solution to a problem.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ray Trent
Sent: Tuesday, June 15, 2004 11:12 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Notify when system time changes

The only way to solve problems like this is with hardware support, which
is where NGSCB comes in.

The problem with your scheme is that any facility that you have access
to is also accessible by the hackers. So you end up in an arms race that
reduces overall stability without providing any benefit.

For example, if you install some hook that allows finding out whether
there is a keyboard hook installed, what prevents someone from hooking
after your hook? Aha, you say, I’ll just check at run time. What
prevents them from hooking the function you use to check for hooks and
not reporting themselves as being present?

You can chase this down forever, but the fundamental problem is that the
hacker only has to break existing detection schemes, which they can
analyze at their leisure, whereas you have to somehow anticipate all
possible hacks. It’s not a solvable problem unless you have true
hardware support with software attestation done in the hardware and true
process isolation.

The more fundamental problem with system hooks is hook conflicts. Even
if MS documents all that they do, they can’t possibly document
everything that every hook out there might do, and so it’s impossible to
have a stable interface by definition. This is why people say it’s only
acceptable for a non-commercial environment. If you have complete
control over all the hooks installed, you can ensure/test for their
compatibility. If it’s a commercial product, there’s no way to do this.

People that want system hooking typically are only thinking short term,
and only of themselves/their application. I don’t see any reason to
encourage them.

Daniel Terhell wrote:

Thanks, I really should not have missed that one. However I think
there is still a long way to go before they really can say there is no

more need for system call hooking and scrap it. I really hope they do

it in the far future after AMD64 support and LongHorn.

For example I think it should be possible to trap if applications are
setting user mode hooks. There is something like a WH_DEBUG hook to
monitor other hooks but it does not see the low level ones. I would
like to create an application for internet cafes that can guarantee
the visitors that no keyboard loggers are installed in any way. I can
check what devices are attached to the keyboard device but in order to

detect the user mode hooks I need to use the load image notify routine

to see what DLLs get injected in what processes which is very messy.
I think there should come a callback for when DLLs are injected into
running processes as well as one for user mode hooks. My best ideas so

far are hooking ZwLockVirtualMemory, ZwProtectVirtualMemory,
ZwWriteVirtualMemory and ZwFlushInstructionCache.
For the low level hook functions, they do not inject anything but all
call some undocumented system call function with a high number which
is not exported by NTDLL.

I would very much like to create a list of callbacks which would make
it possible to develop applications which are currently impossible to
write or without the need of undocumented funtions. Do you think it’s
a good idea to post them here or should I use the DDK feedback ?

Regards, Daniel

“Don Burn” wrote in message news:xxxxx@ntdev…
>
>>Actually they do and it is documented, read the DDK on
>>ExCreateCallback
>
> and
>
>>in particular about “\Callback\SetSystemTime” which does what you
want.
>>This has been available since Windows 2000, so you should have been
>>able
>
> to
>
>>find it.
>>
>>As far as system call hooking being a fundemental principle, I know a
>
> number
>
>>of systems that detected this and took action with a vengenance. At
>>least one minicomputer company disabled the product, then logged the
>>data on the product, their system support people would get the log,
>>and send a letter
>
> to
>
>>all customers saying you thirty days to remove all products from that
>>firm or have your warranty voided!
>>
>>Microsoft is providing mechanisms for ones they see needs for, and yes
>
> they
>
>>are sympathethic to requests for additional ones, so if you have more
>
> needs
>
>>tell them.
>>
>>
>>–
>>Don Burn (MVP, Windows DDK)
>>Windows 2k/XP/2k3 Filesystem and Driver Consulting
>>
>
>
>
>

–
…/ray..

Please remove “.spamblock” from my email address if you need to contact
me outside the newsgroup.

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

14

Yet we have used hooking extensively for all of our tools, and they work
fine.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Peter Wieland
Sent: Tuesday, June 15, 2004 2:37 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Notify when system time changes

There’s an additional problem with hooks that we don’t talk about as
much, and that has to do with extending an API.

Say, for example, that you wanted to catch every read and write an
applications perform. So you hook NtCreateFile (so you can figure out
which handles are to files, NtReadFile and NtWriteFile (we’ll ignore the
problem of memory-mapped I/O for now) and NtClose (so you can cleanup
when the handle is closed). You’re now able to see every read & write
and you’re happy.

What happens to your scheme when we extend the IO NT APIs in the next
release (or service pack - we do sometimes enable new features there),
and provide something like Nt[Read|Write]FileScatterGather? Now there’s
a read/write path that you aren’t hooking. If you were just doing
logging that may be okay, but if you decided to provide data encryption
with a sys-call hooker then your customers are now screwed until you can
get an update together. Whereas if you were filtering above the file
system you would have seen a READ irp come through and could have
processed it.

In order to enable filtering, it has to be done at a point in the system
which will remain relatively stable over time. The IRP interface to
drivers is one such interface, in contrast with the NT or Win32 APIs
which tend to grow over time. The other reliable alternative is to
provide callbacks where we can to notify some third-party component of
changes in the kernel’s internal state - things like the process
creation callbacks. We can then make sure that we invoke the callbacks
where appropriate in the new system calls (or the code they call).

I doubt this is a windows only thing, but it’s been a long time since
I’ve looked at the source for any other OS so couldn’t really tell you
today. I don’t see hooking an evolving API as a stable long-term
solution to a problem.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ray Trent
Sent: Tuesday, June 15, 2004 11:12 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Notify when system time changes

The only way to solve problems like this is with hardware support, which
is where NGSCB comes in.

The problem with your scheme is that any facility that you have access
to is also accessible by the hackers. So you end up in an arms race that
reduces overall stability without providing any benefit.

For example, if you install some hook that allows finding out whether
there is a keyboard hook installed, what prevents someone from hooking
after your hook? Aha, you say, I’ll just check at run time. What
prevents them from hooking the function you use to check for hooks and
not reporting themselves as being present?

You can chase this down forever, but the fundamental problem is that the
hacker only has to break existing detection schemes, which they can
analyze at their leisure, whereas you have to somehow anticipate all
possible hacks. It’s not a solvable problem unless you have true
hardware support with software attestation done in the hardware and true
process isolation.

The more fundamental problem with system hooks is hook conflicts. Even
if MS documents all that they do, they can’t possibly document
everything that every hook out there might do, and so it’s impossible to
have a stable interface by definition. This is why people say it’s only
acceptable for a non-commercial environment. If you have complete
control over all the hooks installed, you can ensure/test for their
compatibility. If it’s a commercial product, there’s no way to do this.

People that want system hooking typically are only thinking short term,
and only of themselves/their application. I don’t see any reason to
encourage them.

Daniel Terhell wrote:

Thanks, I really should not have missed that one. However I think
there is still a long way to go before they really can say there is no

more need for system call hooking and scrap it. I really hope they do

it in the far future after AMD64 support and LongHorn.

For example I think it should be possible to trap if applications are
setting user mode hooks. There is something like a WH_DEBUG hook to
monitor other hooks but it does not see the low level ones. I would
like to create an application for internet cafes that can guarantee
the visitors that no keyboard loggers are installed in any way. I can
check what devices are attached to the keyboard device but in order to

detect the user mode hooks I need to use the load image notify routine

to see what DLLs get injected in what processes which is very messy.
I think there should come a callback for when DLLs are injected into
running processes as well as one for user mode hooks. My best ideas so

far are hooking ZwLockVirtualMemory, ZwProtectVirtualMemory,
ZwWriteVirtualMemory and ZwFlushInstructionCache.
For the low level hook functions, they do not inject anything but all
call some undocumented system call function with a high number which
is not exported by NTDLL.

I would very much like to create a list of callbacks which would make
it possible to develop applications which are currently impossible to
write or without the need of undocumented funtions. Do you think it’s
a good idea to post them here or should I use the DDK feedback ?

Regards, Daniel

“Don Burn” wrote in message news:xxxxx@ntdev…
>
>>Actually they do and it is documented, read the DDK on
>>ExCreateCallback
>
> and
>
>>in particular about “\Callback\SetSystemTime” which does what you
want.
>>This has been available since Windows 2000, so you should have been
>>able
>
> to
>
>>find it.
>>
>>As far as system call hooking being a fundemental principle, I know a
>
> number
>
>>of systems that detected this and took action with a vengenance. At
>>least one minicomputer company disabled the product, then logged the
>>data on the product, their system support people would get the log,
>>and send a letter
>
> to
>
>>all customers saying you thirty days to remove all products from that
>>firm or have your warranty voided!
>>
>>Microsoft is providing mechanisms for ones they see needs for, and yes
>
> they
>
>>are sympathethic to requests for additional ones, so if you have more
>
> needs
>
>>tell them.
>>
>>
>>–
>>Don Burn (MVP, Windows DDK)
>>Windows 2k/XP/2k3 Filesystem and Driver Consulting
>>
>
>
>
>

–
…/ray..

Please remove “.spamblock” from my email address if you need to contact
me outside the newsgroup.

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

15

This comment of Ray and others are very very interesting. I suppose the world was that easy:). But then there is nothing against to make it better !!!.

I’ve nothing agaist or for FOR HOOKING, since it is extreemly debateable, wherewe do if we do it at all…

While we are with conventional OS, it gets very deep how to control these possiblities for security,anti-hack,anti-debug, and what not.

I know it is by no means science, hence would/could have lot of debates about marketing/launching a product ontime, fixing later/may be never on and on and on when it comes down to secuirty, BUT ANYBODY READ “BEYOND FEAR” it is a very interesting book by Bruce Schineier, and I would surely like to know anyone’s thought about that discussion on the book …
-pro

16

Alberto,

Both of the following assertion(s) are wrong -

Hooking => product doesn’t work
NotHooking =>product work.

-pro

17

Yes - there are always exceptions to the rule. Of course soft-ice does
a lot of its hooking at the processor interface, which changes very
little between OS releases compared to, say, the NTAPI.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Moreira, Alberto
Sent: Tuesday, June 15, 2004 11:41 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Notify when system time changes

Yet we have used hooking extensively for all of our tools, and they work
fine.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Peter Wieland
Sent: Tuesday, June 15, 2004 2:37 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Notify when system time changes

There’s an additional problem with hooks that we don’t talk about as
much, and that has to do with extending an API.

Say, for example, that you wanted to catch every read and write an
applications perform. So you hook NtCreateFile (so you can figure out
which handles are to files, NtReadFile and NtWriteFile (we’ll ignore the
problem of memory-mapped I/O for now) and NtClose (so you can cleanup
when the handle is closed). You’re now able to see every read & write
and you’re happy.

What happens to your scheme when we extend the IO NT APIs in the next
release (or service pack - we do sometimes enable new features there),
and provide something like Nt[Read|Write]FileScatterGather? Now there’s
a read/write path that you aren’t hooking. If you were just doing
logging that may be okay, but if you decided to provide data encryption
with a sys-call hooker then your customers are now screwed until you can
get an update together. Whereas if you were filtering above the file
system you would have seen a READ irp come through and could have
processed it.

In order to enable filtering, it has to be done at a point in the system
which will remain relatively stable over time. The IRP interface to
drivers is one such interface, in contrast with the NT or Win32 APIs
which tend to grow over time. The other reliable alternative is to
provide callbacks where we can to notify some third-party component of
changes in the kernel’s internal state - things like the process
creation callbacks. We can then make sure that we invoke the callbacks
where appropriate in the new system calls (or the code they call).

I doubt this is a windows only thing, but it’s been a long time since
I’ve looked at the source for any other OS so couldn’t really tell you
today. I don’t see hooking an evolving API as a stable long-term
solution to a problem.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ray Trent
Sent: Tuesday, June 15, 2004 11:12 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Notify when system time changes

The only way to solve problems like this is with hardware support, which
is where NGSCB comes in.

The problem with your scheme is that any facility that you have access
to is also accessible by the hackers. So you end up in an arms race that
reduces overall stability without providing any benefit.

For example, if you install some hook that allows finding out whether
there is a keyboard hook installed, what prevents someone from hooking
after your hook? Aha, you say, I’ll just check at run time. What
prevents them from hooking the function you use to check for hooks and
not reporting themselves as being present?

You can chase this down forever, but the fundamental problem is that the
hacker only has to break existing detection schemes, which they can
analyze at their leisure, whereas you have to somehow anticipate all
possible hacks. It’s not a solvable problem unless you have true
hardware support with software attestation done in the hardware and true
process isolation.

The more fundamental problem with system hooks is hook conflicts. Even
if MS documents all that they do, they can’t possibly document
everything that every hook out there might do, and so it’s impossible to
have a stable interface by definition. This is why people say it’s only
acceptable for a non-commercial environment. If you have complete
control over all the hooks installed, you can ensure/test for their
compatibility. If it’s a commercial product, there’s no way to do this.

People that want system hooking typically are only thinking short term,
and only of themselves/their application. I don’t see any reason to
encourage them.

Daniel Terhell wrote:

Thanks, I really should not have missed that one. However I think
there is still a long way to go before they really can say there is no

more need for system call hooking and scrap it. I really hope they do

it in the far future after AMD64 support and LongHorn.

For example I think it should be possible to trap if applications are
setting user mode hooks. There is something like a WH_DEBUG hook to
monitor other hooks but it does not see the low level ones. I would
like to create an application for internet cafes that can guarantee
the visitors that no keyboard loggers are installed in any way. I can
check what devices are attached to the keyboard device but in order to

detect the user mode hooks I need to use the load image notify routine

to see what DLLs get injected in what processes which is very messy.
I think there should come a callback for when DLLs are injected into
running processes as well as one for user mode hooks. My best ideas so

far are hooking ZwLockVirtualMemory, ZwProtectVirtualMemory,
ZwWriteVirtualMemory and ZwFlushInstructionCache.
For the low level hook functions, they do not inject anything but all
call some undocumented system call function with a high number which
is not exported by NTDLL.

I would very much like to create a list of callbacks which would make
it possible to develop applications which are currently impossible to
write or without the need of undocumented funtions. Do you think it’s
a good idea to post them here or should I use the DDK feedback ?

Regards, Daniel

“Don Burn” wrote in message news:xxxxx@ntdev…
>
>>Actually they do and it is documented, read the DDK on
>>ExCreateCallback
>
> and
>
>>in particular about “\Callback\SetSystemTime” which does what you
want.
>>This has been available since Windows 2000, so you should have been
>>able
>
> to
>
>>find it.
>>
>>As far as system call hooking being a fundemental principle, I know a
>
> number
>
>>of systems that detected this and took action with a vengenance. At
>>least one minicomputer company disabled the product, then logged the
>>data on the product, their system support people would get the log,
>>and send a letter
>
> to
>
>>all customers saying you thirty days to remove all products from that
>>firm or have your warranty voided!
>>
>>Microsoft is providing mechanisms for ones they see needs for, and yes
>
> they
>
>>are sympathethic to requests for additional ones, so if you have more
>
> needs
>
>>tell them.
>>
>>
>>–
>>Don Burn (MVP, Windows DDK)
>>Windows 2k/XP/2k3 Filesystem and Driver Consulting
>>
>
>
>
>

–
…/ray..

Please remove “.spamblock” from my email address if you need to contact
me outside the newsgroup.

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the
named addressee or an authorized designee, you may not copy or use it,
or disclose it to anyone else. If you received it in error please notify
us immediately and then destroy it.

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

18

There is a large field of creating the software which will reload the CPU’s
GDT/IDT/TSS tables, thus “suspending” the NT OS and taking the 100% control
over CPU to itself, releasing it back to the OS sometimes.

The possible applications based on this are:

  • SoftICE-style debuggers
  • virtual machines
  • realtime toolkits for Windows
  • and so on

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Peter Wieland”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, June 15, 2004 11:07 PM
Subject: RE: [ntdev] Notify when system time changes

> Yes - there are always exceptions to the rule. Of course soft-ice does
> a lot of its hooking at the processor interface, which changes very
> little between OS releases compared to, say, the NTAPI.
>
> -p
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Moreira, Alberto
> Sent: Tuesday, June 15, 2004 11:41 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Notify when system time changes
>
> Yet we have used hooking extensively for all of our tools, and they work
> fine.
>
> Alberto.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Peter Wieland
> Sent: Tuesday, June 15, 2004 2:37 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Notify when system time changes
>
>
> There’s an additional problem with hooks that we don’t talk about as
> much, and that has to do with extending an API.
>
> Say, for example, that you wanted to catch every read and write an
> applications perform. So you hook NtCreateFile (so you can figure out
> which handles are to files, NtReadFile and NtWriteFile (we’ll ignore the
> problem of memory-mapped I/O for now) and NtClose (so you can cleanup
> when the handle is closed). You’re now able to see every read & write
> and you’re happy.
>
> What happens to your scheme when we extend the IO NT APIs in the next
> release (or service pack - we do sometimes enable new features there),
> and provide something like Nt[Read|Write]FileScatterGather? Now there’s
> a read/write path that you aren’t hooking. If you were just doing
> logging that may be okay, but if you decided to provide data encryption
> with a sys-call hooker then your customers are now screwed until you can
> get an update together. Whereas if you were filtering above the file
> system you would have seen a READ irp come through and could have
> processed it.
>
> In order to enable filtering, it has to be done at a point in the system
> which will remain relatively stable over time. The IRP interface to
> drivers is one such interface, in contrast with the NT or Win32 APIs
> which tend to grow over time. The other reliable alternative is to
> provide callbacks where we can to notify some third-party component of
> changes in the kernel’s internal state - things like the process
> creation callbacks. We can then make sure that we invoke the callbacks
> where appropriate in the new system calls (or the code they call).
>
> I doubt this is a windows only thing, but it’s been a long time since
> I’ve looked at the source for any other OS so couldn’t really tell you
> today. I don’t see hooking an evolving API as a stable long-term
> solution to a problem.
>
> -p
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Ray Trent
> Sent: Tuesday, June 15, 2004 11:12 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Notify when system time changes
>
> The only way to solve problems like this is with hardware support, which
> is where NGSCB comes in.
>
> The problem with your scheme is that any facility that you have access
> to is also accessible by the hackers. So you end up in an arms race that
> reduces overall stability without providing any benefit.
>
> For example, if you install some hook that allows finding out whether
> there is a keyboard hook installed, what prevents someone from hooking
> after your hook? Aha, you say, I’ll just check at run time. What
> prevents them from hooking the function you use to check for hooks and
> not reporting themselves as being present?
>
> You can chase this down forever, but the fundamental problem is that the
> hacker only has to break existing detection schemes, which they can
> analyze at their leisure, whereas you have to somehow anticipate all
> possible hacks. It’s not a solvable problem unless you have true
> hardware support with software attestation done in the hardware and true
> process isolation.
>
> The more fundamental problem with system hooks is hook conflicts. Even
> if MS documents all that they do, they can’t possibly document
> everything that every hook out there might do, and so it’s impossible to
> have a stable interface by definition. This is why people say it’s only
> acceptable for a non-commercial environment. If you have complete
> control over all the hooks installed, you can ensure/test for their
> compatibility. If it’s a commercial product, there’s no way to do this.
>
> People that want system hooking typically are only thinking short term,
> and only of themselves/their application. I don’t see any reason to
> encourage them.
>
> Daniel Terhell wrote:
>
> > Thanks, I really should not have missed that one. However I think
> > there is still a long way to go before they really can say there is no
>
> > more need for system call hooking and scrap it. I really hope they do
>
> > it in the far future after AMD64 support and LongHorn.
> >
> > For example I think it should be possible to trap if applications are
> > setting user mode hooks. There is something like a WH_DEBUG hook to
> > monitor other hooks but it does not see the low level ones. I would
> > like to create an application for internet cafes that can guarantee
> > the visitors that no keyboard loggers are installed in any way. I can
> > check what devices are attached to the keyboard device but in order to
>
> > detect the user mode hooks I need to use the load image notify routine
>
> > to see what DLLs get injected in what processes which is very messy.
> > I think there should come a callback for when DLLs are injected into
> > running processes as well as one for user mode hooks. My best ideas so
>
> > far are hooking ZwLockVirtualMemory, ZwProtectVirtualMemory,
> ZwWriteVirtualMemory and ZwFlushInstructionCache.
> > For the low level hook functions, they do not inject anything but all
> > call some undocumented system call function with a high number which
> > is not exported by NTDLL.
> >
> > I would very much like to create a list of callbacks which would make
> > it possible to develop applications which are currently impossible to
> > write or without the need of undocumented funtions. Do you think it’s
> > a good idea to post them here or should I use the DDK feedback ?
> >
> > Regards, Daniel
> >
> >
> >
> >
> > “Don Burn” wrote in message news:xxxxx@ntdev…
> >
> >>Actually they do and it is documented, read the DDK on
> >>ExCreateCallback
> >
> > and
> >
> >>in particular about “\Callback\SetSystemTime” which does what you
> want.
> >>This has been available since Windows 2000, so you should have been
> >>able
> >
> > to
> >
> >>find it.
> >>
> >>As far as system call hooking being a fundemental principle, I know a
> >
> > number
> >
> >>of systems that detected this and took action with a vengenance. At
> >>least one minicomputer company disabled the product, then logged the
> >>data on the product, their system support people would get the log,
> >>and send a letter
> >
> > to
> >
> >>all customers saying you thirty days to remove all products from that
> >>firm or have your warranty voided!
> >>
> >>Microsoft is providing mechanisms for ones they see needs for, and yes
> >
> > they
> >
> >>are sympathethic to requests for additional ones, so if you have more
> >
> > needs
> >
> >>tell them.
> >>
> >>
> >>–
> >>Don Burn (MVP, Windows DDK)
> >>Windows 2k/XP/2k3 Filesystem and Driver Consulting
> >>
> >
> >
> >
> >
>
> –
> …/ray..
>
> Please remove “.spamblock” from my email address if you need to contact
> me outside the newsgroup.
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@compuware.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> The contents of this e-mail are intended for the named addressee only.
> It contains information that may be confidential. Unless you are the
> named addressee or an authorized designee, you may not copy or use it,
> or disclose it to anyone else. If you received it in error please notify
> us immediately and then destroy it.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

19

Well, until a service pack comes out :-).

Moreira, Alberto wrote:

Yet we have used hooking extensively for all of our tools, and they work
fine.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Peter Wieland
Sent: Tuesday, June 15, 2004 2:37 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Notify when system time changes

There’s an additional problem with hooks that we don’t talk about as
much, and that has to do with extending an API.

Say, for example, that you wanted to catch every read and write an
applications perform. So you hook NtCreateFile (so you can figure out
which handles are to files, NtReadFile and NtWriteFile (we’ll ignore the
problem of memory-mapped I/O for now) and NtClose (so you can cleanup
when the handle is closed). You’re now able to see every read & write
and you’re happy.

What happens to your scheme when we extend the IO NT APIs in the next
release (or service pack - we do sometimes enable new features there),
and provide something like Nt[Read|Write]FileScatterGather? Now there’s
a read/write path that you aren’t hooking. If you were just doing
logging that may be okay, but if you decided to provide data encryption
with a sys-call hooker then your customers are now screwed until you can
get an update together. Whereas if you were filtering above the file
system you would have seen a READ irp come through and could have
processed it.

In order to enable filtering, it has to be done at a point in the system
which will remain relatively stable over time. The IRP interface to
drivers is one such interface, in contrast with the NT or Win32 APIs
which tend to grow over time. The other reliable alternative is to
provide callbacks where we can to notify some third-party component of
changes in the kernel’s internal state - things like the process
creation callbacks. We can then make sure that we invoke the callbacks
where appropriate in the new system calls (or the code they call).

I doubt this is a windows only thing, but it’s been a long time since
I’ve looked at the source for any other OS so couldn’t really tell you
today. I don’t see hooking an evolving API as a stable long-term
solution to a problem.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ray Trent
Sent: Tuesday, June 15, 2004 11:12 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Notify when system time changes

The only way to solve problems like this is with hardware support, which
is where NGSCB comes in.

The problem with your scheme is that any facility that you have access
to is also accessible by the hackers. So you end up in an arms race that
reduces overall stability without providing any benefit.

For example, if you install some hook that allows finding out whether
there is a keyboard hook installed, what prevents someone from hooking
after your hook? Aha, you say, I’ll just check at run time. What
prevents them from hooking the function you use to check for hooks and
not reporting themselves as being present?

You can chase this down forever, but the fundamental problem is that the
hacker only has to break existing detection schemes, which they can
analyze at their leisure, whereas you have to somehow anticipate all
possible hacks. It’s not a solvable problem unless you have true
hardware support with software attestation done in the hardware and true
process isolation.

The more fundamental problem with system hooks is hook conflicts. Even
if MS documents all that they do, they can’t possibly document
everything that every hook out there might do, and so it’s impossible to
have a stable interface by definition. This is why people say it’s only
acceptable for a non-commercial environment. If you have complete
control over all the hooks installed, you can ensure/test for their
compatibility. If it’s a commercial product, there’s no way to do this.

People that want system hooking typically are only thinking short term,
and only of themselves/their application. I don’t see any reason to
encourage them.

Daniel Terhell wrote:

>Thanks, I really should not have missed that one. However I think
>there is still a long way to go before they really can say there is no

>more need for system call hooking and scrap it. I really hope they do

>it in the far future after AMD64 support and LongHorn.
>
>For example I think it should be possible to trap if applications are
>setting user mode hooks. There is something like a WH_DEBUG hook to
>monitor other hooks but it does not see the low level ones. I would
>like to create an application for internet cafes that can guarantee
>the visitors that no keyboard loggers are installed in any way. I can
>check what devices are attached to the keyboard device but in order to

>detect the user mode hooks I need to use the load image notify routine

>to see what DLLs get injected in what processes which is very messy.
>I think there should come a callback for when DLLs are injected into
>running processes as well as one for user mode hooks. My best ideas so

>far are hooking ZwLockVirtualMemory, ZwProtectVirtualMemory,

ZwWriteVirtualMemory and ZwFlushInstructionCache.

>For the low level hook functions, they do not inject anything but all
>call some undocumented system call function with a high number which
>is not exported by NTDLL.
>
>I would very much like to create a list of callbacks which would make
>it possible to develop applications which are currently impossible to
>write or without the need of undocumented funtions. Do you think it’s
>a good idea to post them here or should I use the DDK feedback ?
>
>Regards, Daniel
>
>
>
>
>“Don Burn” wrote in message news:xxxxx@ntdev…
>>
>>
>>>Actually they do and it is documented, read the DDK on
>>>ExCreateCallback
>>
>>and
>>
>>
>>>in particular about “\Callback\SetSystemTime” which does what you
>
> want.
>
>>>This has been available since Windows 2000, so you should have been
>>>able
>>
>>to
>>
>>
>>>find it.
>>>
>>>As far as system call hooking being a fundemental principle, I know a
>>
>>number
>>
>>
>>>of systems that detected this and took action with a vengenance. At
>>>least one minicomputer company disabled the product, then logged the
>>>data on the product, their system support people would get the log,
>>>and send a letter
>>
>>to
>>
>>
>>>all customers saying you thirty days to remove all products from that
>>>firm or have your warranty voided!
>>>
>>>Microsoft is providing mechanisms for ones they see needs for, and yes
>>
>>they
>>
>>
>>>are sympathethic to requests for additional ones, so if you have more
>>
>>needs
>>
>>
>>>tell them.
>>>
>>>
>>>–
>>>Don Burn (MVP, Windows DDK)
>>>Windows 2k/XP/2k3 Filesystem and Driver Consulting
>>>
>>
>>
>>
>>
>
> –
> …/ray..
>
> Please remove “.spamblock” from my email address if you need to contact
> me outside the newsgroup.
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@compuware.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> The contents of this e-mail are intended for the named addressee only. It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or disclose
> it to anyone else. If you received it in error please notify us immediately
> and then destroy it.
>
>

–
…/ray..

Please remove “.spamblock” from my email address if you need to contact
me outside the newsgroup.

20

Actually we solved that problem too. All it takes is to add entries to a
table, and rebuild the system. It took some time for us to get there, but
most of that kind of updating is now as close to automatic as one can get.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Ray Trent
Sent: Tuesday, June 15, 2004 3:57 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Notify when system time changes

Well, until a service pack comes out :-).

Moreira, Alberto wrote:

Yet we have used hooking extensively for all of our tools, and they work
fine.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Peter Wieland
Sent: Tuesday, June 15, 2004 2:37 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Notify when system time changes

There’s an additional problem with hooks that we don’t talk about as
much, and that has to do with extending an API.

Say, for example, that you wanted to catch every read and write an
applications perform. So you hook NtCreateFile (so you can figure out
which handles are to files, NtReadFile and NtWriteFile (we’ll ignore the
problem of memory-mapped I/O for now) and NtClose (so you can cleanup
when the handle is closed). You’re now able to see every read & write
and you’re happy.

What happens to your scheme when we extend the IO NT APIs in the next
release (or service pack - we do sometimes enable new features there),
and provide something like Nt[Read|Write]FileScatterGather? Now there’s
a read/write path that you aren’t hooking. If you were just doing
logging that may be okay, but if you decided to provide data encryption
with a sys-call hooker then your customers are now screwed until you can
get an update together. Whereas if you were filtering above the file
system you would have seen a READ irp come through and could have
processed it.

In order to enable filtering, it has to be done at a point in the system
which will remain relatively stable over time. The IRP interface to
drivers is one such interface, in contrast with the NT or Win32 APIs
which tend to grow over time. The other reliable alternative is to
provide callbacks where we can to notify some third-party component of
changes in the kernel’s internal state - things like the process
creation callbacks. We can then make sure that we invoke the callbacks
where appropriate in the new system calls (or the code they call).

I doubt this is a windows only thing, but it’s been a long time since
I’ve looked at the source for any other OS so couldn’t really tell you
today. I don’t see hooking an evolving API as a stable long-term
solution to a problem.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ray Trent
Sent: Tuesday, June 15, 2004 11:12 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Notify when system time changes

The only way to solve problems like this is with hardware support, which
is where NGSCB comes in.

The problem with your scheme is that any facility that you have access
to is also accessible by the hackers. So you end up in an arms race that
reduces overall stability without providing any benefit.

For example, if you install some hook that allows finding out whether
there is a keyboard hook installed, what prevents someone from hooking
after your hook? Aha, you say, I’ll just check at run time. What
prevents them from hooking the function you use to check for hooks and
not reporting themselves as being present?

You can chase this down forever, but the fundamental problem is that the
hacker only has to break existing detection schemes, which they can
analyze at their leisure, whereas you have to somehow anticipate all
possible hacks. It’s not a solvable problem unless you have true
hardware support with software attestation done in the hardware and true
process isolation.

The more fundamental problem with system hooks is hook conflicts. Even
if MS documents all that they do, they can’t possibly document
everything that every hook out there might do, and so it’s impossible to
have a stable interface by definition. This is why people say it’s only
acceptable for a non-commercial environment. If you have complete
control over all the hooks installed, you can ensure/test for their
compatibility. If it’s a commercial product, there’s no way to do this.

People that want system hooking typically are only thinking short term,
and only of themselves/their application. I don’t see any reason to
encourage them.

Daniel Terhell wrote:

>Thanks, I really should not have missed that one. However I think
>there is still a long way to go before they really can say there is no

>more need for system call hooking and scrap it. I really hope they do

>it in the far future after AMD64 support and LongHorn.
>
>For example I think it should be possible to trap if applications are
>setting user mode hooks. There is something like a WH_DEBUG hook to
>monitor other hooks but it does not see the low level ones. I would
>like to create an application for internet cafes that can guarantee
>the visitors that no keyboard loggers are installed in any way. I can
>check what devices are attached to the keyboard device but in order to

>detect the user mode hooks I need to use the load image notify routine

>to see what DLLs get injected in what processes which is very messy.
>I think there should come a callback for when DLLs are injected into
>running processes as well as one for user mode hooks. My best ideas so

>far are hooking ZwLockVirtualMemory, ZwProtectVirtualMemory,

ZwWriteVirtualMemory and ZwFlushInstructionCache.

>For the low level hook functions, they do not inject anything but all
>call some undocumented system call function with a high number which
>is not exported by NTDLL.
>
>I would very much like to create a list of callbacks which would make
>it possible to develop applications which are currently impossible to
>write or without the need of undocumented funtions. Do you think it’s
>a good idea to post them here or should I use the DDK feedback ?
>
>Regards, Daniel
>
>
>
>
>“Don Burn” wrote in message news:xxxxx@ntdev…
>>
>>
>>>Actually they do and it is documented, read the DDK on
>>>ExCreateCallback
>>
>>and
>>
>>
>>>in particular about “\Callback\SetSystemTime” which does what you
>
> want.
>
>>>This has been available since Windows 2000, so you should have been
>>>able
>>
>>to
>>
>>
>>>find it.
>>>
>>>As far as system call hooking being a fundemental principle, I know a
>>
>>number
>>
>>
>>>of systems that detected this and took action with a vengenance. At
>>>least one minicomputer company disabled the product, then logged the
>>>data on the product, their system support people would get the log,
>>>and send a letter
>>
>>to
>>
>>
>>>all customers saying you thirty days to remove all products from that
>>>firm or have your warranty voided!
>>>
>>>Microsoft is providing mechanisms for ones they see needs for, and yes
>>
>>they
>>
>>
>>>are sympathethic to requests for additional ones, so if you have more
>>
>>needs
>>
>>
>>>tell them.
>>>
>>>
>>>–
>>>Don Burn (MVP, Windows DDK)
>>>Windows 2k/XP/2k3 Filesystem and Driver Consulting
>>>
>>
>>
>>
>>
>
> –
> …/ray..
>
> Please remove “.spamblock” from my email address if you need to contact
> me outside the newsgroup.
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@compuware.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> The contents of this e-mail are intended for the named addressee only. It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or
disclose
> it to anyone else. If you received it in error please notify us
immediately
> and then destroy it.
>
>

–
…/ray..

Please remove “.spamblock” from my email address if you need to contact
me outside the newsgroup.

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.