Ok, i will try to give you a “compelling need”:
I have written an API monitor dll that gets injected
into registered applications in order to give them access
rights (via a service) to specific files. These files
may not be accessed by the user in any other way.
I don’t have control over the source code of all the
registered apps. In order to guarantee that all file
accesses will be intercepted, i don’t see any other
way than detecting the very moment of the process
start so that the API monitor will be injected before
the primary thread starts.
If you got a solution for this without hooking any
kernel calls, please let me know 
Cheers,
Holger
-----Ursprungliche Nachricht-----
Von: Ntdev Reader [mailto:xxxxx@yahoo.com]
Gesendet: Mittwoch, 5. Dezember 2001 05:38
An: NT Developers Interest List
Betreff: [ntdev] Re: AW: RE: application start detection
NT has security mechanisms built into it. So, the vast majority of the
app launch restrictions can be implemented by system administrator.
I don’t know without research if its access controls can provide for
time frames. Even if not, it is probably possible to write a service
that would change access control flags on files/directories/registry
according to “certain conditions”. Restriction on the number of app
instanses looks like a duty of the app manufacturer. Of course, it is
always possible to come up with a reason why a feature is needed, but,
as usual, it is not possible to serve for every imaginable need when
creating system interfaces. So, I must restate my assertion and say
“there is probably no compelling need” for this feature
— Peter Viscarola wrote:
>> “Ntdev Reader” wrote in message
news:xxxxx@ntdev…
> >
> > You guys can’t find a documented way to prevent a program
> > from starting, maybe there is none because there is no need.
> > Who can explain why would anybody ever want to stop a program
> > at start?
> >
>
> I can think of several reasons for wanting to prevent a program from
> starting. License management applications are a major one (i.e. only n
> instances of a given program can be active at one time). Secure
> environments provide another (i.e. only certain programs can be run by
> certain users, either ever or at certain times or under certain
conditions).
> Those are off the top of my head.
>
> Having said all that, I agree that hooking APIs isn’t typically a very
good
> idea. But, there ARE those times, or at least there may be, when the
risks
> justify the benefits within a particular, specific, environment.
>
> Peter
> OSR
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@yahoo.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
__________________________________________________
Do You Yahoo!?
Buy the perfect holiday gifts at Yahoo! Shopping.
http://shopping.yahoo.com
—
You are currently subscribed to ntdev as: xxxxx@david-gmbh.de
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
The only registry supported way i know is that you can
inject a dll into a process using the
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs
key. However, this only works for processes that link to user32.dll, and,
worse,
the dll gets injected into ALL processes that link to user32.dll.
Holger
-----Urspr?ngliche Nachricht-----
Von: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Gesendet: Mittwoch, 5. Dezember 2001 00:27
An: NT Developers Interest List
Betreff: [ntdev] Re: AW: RE: application start detection
IIRC there was a way using registry to inject your DLL to ALL
processes in the OS.
At least all Win32 processes.
Use the DllMain of this DLL to check the EXE’s MD5sum.
Max
----- Original Message -----
From: “Marcos Balreira de Souza”
>To: “NT Developers Interest List”
>Sent: Tuesday, December 04, 2001 9:12 PM
>Subject: [ntdev] Re: AW: RE: application start detection
>
>
>>
>> >You guys can’t find a documented way to prevent a program
>> >from starting, maybe there is none because there is no need.
>> >Who can explain why would anybody ever want to stop a program
>> >at start?
>>
>> Yes, there is. Suppose you want to develop some utility to
>prevent users
>> from running unauthorized/corrupt/infected software. Then, prior to
>> executing, all executable files would be checked against a database
>> containing the CRCs or MD5 hashes of all “authorized”
>executables on a
>> particular system. If the check fails, the utility will not start.
>>
>> Marcos
>>
>>
>>
>>
>> —
>> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
>> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>>
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@david-gmbh.de
>To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
I thought we were talking about compelling need to have an
“interface for stopping programs at their start”. There are
interfaces to “kill” programs.
As to a general-purpose mechanism for hooking APIs, it would
create too much restrictions on MS. They would have to force all
of their and third-party components to go through the APIs.
This was indeed the case for VxD services which were explicitly
hookable, but never in NT. They made their decision and now it
is too late to change anything.
So, your setup is something like you have a directory with
.bmp-files and you want people to only view them through some
“read-only” paint.exe and never be able to make a copy? And you
make the files not accessible to the user and you have
a service that makes files accessible when paint.exe is being
started, by request from your hook? Will not this make the
files accessible to other programs while paint.exe is using them?
— Holger Thiele wrote:
> Ok, i will try to give you a “compelling need”:
> I have written an API monitor dll that gets injected
> into registered applications in order to give them access
> rights (via a service) to specific files. These files
> may not be accessed by the user in any other way.
> I don’t have control over the source code of all the
> registered apps. In order to guarantee that all file
> accesses will be intercepted, i don’t see any other
> way than detecting the very moment of the process
> start so that the API monitor will be injected before
> the primary thread starts.
> If you got a solution for this without hooking any
> kernel calls, please let me know
>
> Cheers,
>
> Holger
>
> >-----Ursprungliche Nachricht-----
> >Von: Ntdev Reader [mailto:xxxxx@yahoo.com]
> >Gesendet: Mittwoch, 5. Dezember 2001 05:38
> >An: NT Developers Interest List
> >Betreff: [ntdev] Re: AW: RE: application start detection
> >
> >
> >NT has security mechanisms built into it. So, the vast majority of the
> >app launch restrictions can be implemented by system administrator.
> >I don’t know without research if its access controls can provide for
> >time frames. Even if not, it is probably possible to write a service
> >that would change access control flags on files/directories/registry
> >according to “certain conditions”. Restriction on the number of app
> >instanses looks like a duty of the app manufacturer. Of course, it is
> >always possible to come up with a reason why a feature is needed, but,
> >as usual, it is not possible to serve for every imaginable need when
> >creating system interfaces. So, I must restate my assertion and say
> >“there is probably no compelling need” for this feature
> >
> >— Peter Viscarola wrote:
> >> “Ntdev Reader” wrote in message
> news:xxxxx@ntdev…
> > >
> > > You guys can’t find a documented way to prevent a program
> > > from starting, maybe there is none because there is no need.
> > > Who can explain why would anybody ever want to stop a program
> > > at start?
> > >
> >
> > I can think of several reasons for wanting to prevent a program from
> > starting. License management applications are a major one (i.e. only n
> > instances of a given program can be active at one time). Secure
> > environments provide another (i.e. only certain programs can be run by
> > certain users, either ever or at certain times or under certain
> conditions).
> > Those are off the top of my head.
> >
> > Having said all that, I agree that hooking APIs isn’t typically a very
> good
> > idea. But, there ARE those times, or at least there may be, when the
> risks
> > justify the benefits within a particular, specific, environment.
> >
> > Peter
> > OSR
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@yahoo.com
> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
>
> Do You Yahoo!?
> Buy the perfect holiday gifts at Yahoo! Shopping.
> http://shopping.yahoo.com
>
> —
> You are currently subscribed to ntdev as: xxxxx@david-gmbh.de
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntdev as: xxxxx@yahoo.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Replies inline.
-----Ursprungliche Nachricht-----
Von: Ntdev Reader [mailto:xxxxx@yahoo.com]
Gesendet: Mittwoch, 5. Dezember 2001 22:40
An: NT Developers Interest List
Betreff: [ntdev] Re: AW: Re: AW: RE: application start detection
I thought we were talking about compelling need to have an
“interface for stopping programs at their start”. There are
interfaces to “kill” programs.
As to a general-purpose mechanism for hooking APIs, it would
create too much restrictions on MS. They would have to force all
of their and third-party components to go through the APIs.
This was indeed the case for VxD services which were explicitly
hookable, but never in NT. They made their decision and now it
is too late to change anything.
Yeah, that’s the way it is 
However, the point is that i believe you shouldn’t go ahead
and say something like
“Don’t do it if MS doesn’t want you to”
as a general statement. There are times when using undoc’ed
features is the only solution.
So, your setup is something like you have a directory with
.bmp-files and you want people to only view them through some
“read-only” paint.exe and never be able to make a copy? And you
make the files not accessible to the user and you have
a service that makes files accessible when paint.exe is being
started, by request from your hook?
Yes, the scenario is similar to what you desribed: actually
it is a protection mechanism for files on folders shared
across a network.
Will not this make the
files accessible to other programs while paint.exe is using them?
nope
Cheers,
Holger
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> “Don’t do it if MS doesn’t want you to”
as a general statement. There are times when using undoc’ed
features is the only solution.
Depends of what features. If some Ccxxx or FsRtlxxx function MS forget to expose - then yes.
But calling user mode from kernel mode is bad.
Max
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com