httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Tip for 2.0 Win32 Service code.
Date Thu, 15 Jun 2000 22:20:46 GMT

In a message dated 00-06-15 15:46:16 EDT, William Rowe writes...

> not a service
>  >  RCTPDW.C  @00238:main():lpsi->dwFlags         = 0
>  is a service
>  >  RCTPDW.C  @00238:main():lpsi->dwFlags         = 128
>  Low and behold, only the NT SCM really cares that a process starts
>  with STARTF_FORCEOFFFEEDBACK.  I've tested every combination of
>  NET START, apache -k start, and the SCM control panel applet.  Even
>  with the Allow Service to Interact flag set, we are in business!
>  So now, thanks to your hints, we have the ability to spawn Apache
>  hidden without inferring that the SCM has started the process :)
>  Bill


You should be able to depend on that since CreateProcess() offers
only one way for a person to 'set' that specific flag one way or the
other and most people launching a background job never bother to set
it... but they CAN if they want.

Anyone calling CreateProcess() could try to get 'creative' and set
that flag in the 'lpStartupInfo' pointer passed by CreateProcess().

The reason I didn't mention it is because if someone DOES
decide to start monkeying with those flags in their own call
to 'CreateProcess()' with DETACHED_PROCESS specified
then you might get a false positive.

What are the chances that someone just trying to run Apache
as a background job with no console would care about the
'cursor feedback mode' for their background job and do that?
Slim to none... but you never know these days.

The 'tests' in the code examples sent work for us because we do
NOT allow 'total background' execution with no console at all
unless there is no user logged in and the service was started
remotely, which is determined by other means.

See discussion of 'NetServiceXXXX()' API calls below.

I still think the best 'way to go' if you are now so inclined
is to simply be SURE the SCM is calling you and not even some
other program using DETACHED_PROCESS that might 'look'
like the SCM.

As said before... the best way to do that is either find out
exactly who/what your 'Process Group' is and who your parent
process is but since the code to do that differs a LOT betwixt
versions of Win32 then perhaps the REAL way is to just ASK
the process if it belongs to the SCM using 'NetServiceXXXX()'
API calls which are avaliable in ALL versions of MS Windows.

That's right... use 'NetServiceXXXX()' calls and NOT
'ServiceXXXX()' calls.

If the 'process' that's being created is actually now part
of the MS Lan Manager Service environment then the
NetServiceXXX() API calls should be able to tell you that.

The NetServiceEnum() call can give you the PIDS of everything
that belongs to the 'real' SCM and if the current caller
isn't on the list then he doesn't get to join the party.

The odds that someone has used CreateProcess() with the
DETACHED_PROCESS flag might make them 'look' like the
MS SCM but I really doubt they will ever be able to
actually 'fool' anyone into thinking they are the
actual Service Control parent process.

It's possible, of course, but now we are talking about someone
who is purposely trying to 'fake you out' by registering
false PIDS with the NetServiceInstall() API before they call you.

Not likely.

If you look at the exports for C:\WINNT\SYSTEM32\NETAPI32.DLL
you see the following...

0001A72E   166  NetServiceControl
0001A7DD   167  NetServiceEnum
00007A2E   168  NetServiceGetInfo
0001A864   169  NetServiceInstall

These are carryovers from OS/2 Lan Manager ( which became
Microsoft Lan Manager after IBM and Microsoft divorced in
the early 1990's. )

They are the actual NET functions that deal with Services.

The MS documentation says that these calls are 'obsolete'
and should not be used for anything but backwards compatibility
with 16 bit Windows 3.1 programs that use these calls
( Windows for WorkGroups stuff ) but that is not the case.

They have been carried right over into all Win32 versions
and still remain essential NetXXXXX() API calls.

The MS 'ServiceXXXXX()' API's are actually still just brown
wrappers on calls to these NetServiceXXXXX() API calls.

The 'NET whatever' command line calls don't call the
'ServiceXXXX()' brown wrappers... they call call the
'original' OS/2 Lan Manager NetServiceXXXX() API's

That's because the code for the 'NET.EXE' command program
that comes with Microsoft Lan Manager is still pretty much
identical to the original OS/2 program.

How do I know this?

I helped write parts of the original OS/2 Lan Manager including
some of the NET.EXE program while working with IBM some 
years ago when Microsoft and IBM will still joint-developing
the PC multiprocessing operating system called 'DOS 6m'.

When Bill Gates pulled all of his people out one weekend
after someone from IBM pissed him off the code went with
them ( legally ) and became Microsoft Lan Manager. Actually
the ENTIRE code base went with them, kernel included.

This is still referred to as 'the divorce' when the project
called DOS 6m split into 2 camps. At IBM it continued on
to become something called OS/2 and at Microsoft the
same code base became something called 'Windows NT'.

Windows NT is still essentially OS/2, you know.

MS has added to it since 'the divorce' and called it 'NT' but
most of it is identical to the original OS/2 2.0 source code.

If you don't believe me then just look at this...

WHENEVER the Microsoft Service Control Manager 'calls' an
exectuable to start the Service the 'home' directory will
show up as the '%SystemRoot%' and the CMD.EXE environment
will contain a few interesting strings...

@00120:main():Command line parameters...
@00121:main():argc = 1
@00130:main():envp[014]=[PROCESSOR_IDENTIFIER=x86 Family 5 Model 4 Stepping 
3, GenuineIntel]
@00130:main():envp[019]=[USERPROFILE=C:\WINNT\Profiles\Default User]

Check out these 3 relevant entries...


Gee... that's funny...

The MS Service Manager is taking pains to say that the
COMMAND SHELL is definitely Windows NT cmd.exe and that
OS=Windows_NT but there it is setting a DLL library path
to something called...


Windows NT using OS2 DLLs? Is it possible?

You betcha.

Here is what's in the OS2 dirs that are created on Windows NT
when you install the Microsoft networking stuff...

Volume in drive C has no label.
Volume Serial Number is D845-2F2F

Directory of C:\WINNT\SYSTEM32\OS2\DLL

08/09/96  01:30a  247,860 netapi.dll
08/09/96  01:30a   12,646 doscalls.dll

Well shivver me timbers... OS2 NETAPI DLL's being used
by Microsoft Windows NT as extensions to their own
NETAPI32.DLL... whoda thunk it.

Actually... this ENVIRONMENT check would probably work
just as well as NetServiceEnum().

Unless someone is TRYING to fool you into thinking they
are the MS Service Control Manager then I really doubt
they will ever 'accidentally' run CreateProcess() with
a special environment that sets up a path to OS2 DLL's.

If you see those OS/2 strings... you can be sure it's the
Windows SCM calling on any Win32 platform otherwise someone
is REALLY making an 'effort' to 'fake you out'.


Kevin Kiley
CTO, Remote Communications, Inc. - Online Internet Content Compression Server.

View raw message