Confirm SP2 installed

[Guest]

Hey all!

Before esatblishing a remote connection into our office network, we are able
to carry out client integrity checks of clients PCs in our users homes.

The checks are pretty basic - We can check if a file exists in a particular
location, we can check if a registry key exists and has the correct
information and we can MD5 hash files to check for integrity.

I want to ensure that our users are running XP with SP2 installed.
1. What registry key/data will confirm this to me?
2. Is there a particular executable that will be the same (XP home and Pro)
that I could check integrity with a hash?
3. Is there a better newsgroup to post this in?

Thanks

Ron

 

[Michael Chambers]

Before esatblishing a remote connection into our office network, we are
able
to carry out client integrity checks of clients PCs in our users homes.

The checks are pretty basic - We can check if a file exists in a
particular
location, we can check if a registry key exists and has the correct
information and we can MD5 hash files to check for integrity.

I want to ensure that our users are running XP with SP2 installed.
1. What registry key/data will confirm this to me?
2. Is there a particular executable that will be the same (XP home and
Pro)
that I could check integrity with a hash?
3. Is there a better newsgroup to post this in?

Can you write your own software to do this? If so then see
http://windowssdk.msdn.microsoft.com/en-us/library/ms724451.aspx .There are
references here for doing it remotely as well though I've never tried it
outside of the local intranet. Note that doing it by checking some registry
key or a file may be possible (protected Windows files in particular) but
it's not really a good idea unless you have no choice. I'm not sure what
MSFT would have to say about it (you can try contacting them) but I
seriously doubt they would recommend it. Using an official function from the
Windows API is normally the proper way to do it (note that I'm a very
experienced software developer)

 

[Guest]

Hi Michael,

Sadly, I am net admins, not a programmer At the time of connection there
is a piece of software that is downloaded to the client. I am able to use
command line inputs to get this program to return a TRUE or FALSE result to
the specific check being done.

Unless anyone knows of the registry keys or files to check, I will have to
throw it back to the developers of our endpoint who might find your linked
article helpful.

Thank you for your assistance Michael. Have a good day!

Anyone else???

 

[Guest]

Hi Michael. Many thanks again for your reply and efforts. I think I will be
passing this back to the developers as I think the programatical way is going
to be the correct way to do it.

Thanks again.

 

[Michael Chambers]

Sadly, I am net admins, not a programmer At the time of connection

there
is a piece of software that is downloaded to the client. I am able to use
command line inputs to get this program to return a TRUE or FALSE result
to
the specific check being done.

Unless anyone knows of the registry keys or files to check, I will have to
throw it back to the developers of our endpoint who might find your linked
article helpful.

Thank you for your assistance Michael. Have a good day!

Well, there are different things you can try but it's unlikely that any is
completely reliable. Registry entries and file versions can vary across
different versions of the OS (home versus professional version of XP for
instance, Server 2003, etc.) and even within the same version. Other times
the info may be a little flaky or not officially documented by MSFT. If
you're not overly concerned about it then you can try investigating
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion" for
instance which should be set to "5.1" for WinXP. This registry key is
officially documented by MSFT as I recall (you should double check) but
again, it might not be for all current versions of Windows (home version for
instance - you'll need to check). Note that "CSDVersion" will also be set to
"Service Pack 2".under the same key (for an English version of the OS
anyway), but again, I don't know how reliable this is. Other registry keys
also likely exist but you'll have to dig for them (as I'm sure you already
have - MSFT does document their registry keys but the info is sometimes
scattered, incomplete, or difficult to pin down depending on the OS). If you
want to try checking some file version, you would likely have to investigate
a "protected" file such as "kernel32.dll" which is guaranteed to exist on
all versions (there are many other protected files but "kernel32,dll" is
among an elite club that will always be present). It's very unlikely you'll
find any file that can pinpoint the exact version and SP however. A minimum
version is all you can usually guarantee but determining whether it's XP
(home or professional) versus Win2000 for instance (or others) may prove
difficult. Note that MSFT does have an online search facility to find all OS
files and their versions (plus related info) but I don't have the link with
me offhand. It's not completely reliable anyway based on my experience
(since they have countless thousands of files going back years). In any
case, note that you can also run "ver" from the command prompt and redirect
the output to a file which can then be searched using, say, "find.exe" for
instance (there's also a GUI version called "winver.exe" but you'ld have to
screen scrape the results). No service pack info is provded by "ver" however
(unlike "WinVer.exe") and the format of the version string isn't officially
documented. IMO your best bet is to simply bite the bullet and find a
programmer to write the necessary code. It will be faster than the search
you're now conducting and reliable in theory (since the link I previously
provided is the de facto way of doing it - I've used it on the local
intranet under many different (language) versions of Windows and it's always
proved reliable). It should also be doable very quickly since the code
involved is extremely tiny once they investigate how to do it remotely (the
investgiation and testing will take longer than the code itself which can be
written in an hour or less). Anway, good luck.

 

[M. Burnett]

Ron, there are many ways you can get this information.

From the command line:

C:\>systeminfo | find "Service Pack"
or
c:\>wmic OS GET CSDVersion


or using WMI from a script:

Win32_OperatingSystem
http://windowssdk.msdn.microsoft.com/en-us/library/aa394239.aspx

From the Registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
CSDVersion

You could even check to see if certain files exist:
C:\windows\System32\Driver Cache\i386\Sp2.cab
C:\Windows\System32\dllcache\SP2.cat
C:\windows\system32\xpsp2res.dll


Mark Burnett

 

[Michael Chambers]

C:\>systeminfo | find "Service Pack"

or
c:\>wmic OS GET CSDVersion

Format is undocumented (possibly from version-to-version of the same app,
between different versions of Windows itself, and in different language
versions of Windows), file isn't protected ("systeminfo.exe" anyway) and
could therefore be missing or may not even be available in all versions or
even in the same location (the "Path" environment variable should normally
locate it but there are no guarantees)

or using WMI from a script:

Win32_OperatingSystem
http://windowssdk.msdn.microsoft.com/en-us/library/aa394239.aspx

WMI isn't installed by default in all environments (e.g., Win2003 Server).
VBScript is one possible alternative however (not my specialty) but at least
it's still going the programmatic route

From the Registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
CSDVersion

Already suggested that but he needs to verify that it's reliably available
and consistently formatted on all systems (not easy to verify)

You could even check to see if certain files exist:
C:\windows\System32\Driver Cache\i386\Sp2.cab
C:\Windows\System32\dllcache\SP2.cat
C:\windows\system32\xpsp2res.dll

Totally unreliable. How do you know for instance that any of these files
will remain when the next SP is released or that they're even installed on
all SP2 versions of XP (they could in fact be installed on other versions of
Windows as well - MSFT sometimes relies on the same file names).

Note BTW that security can also rear its ugly head in practice for some of
these ideas (potentially anyway - accessing HKLM alone is often a security
issue)

 

[M. Burnett]

Michael, I don't think the requirements are as stringent as you are
making them out to be. They just want to know if Sp2 is installed on an
XP box. Sure, you could find something to break any one of these
methods, but remember that we're only talking about one SP, one OS, and
likely one language. And since he said he wasn't a programmer, I offered
alternatives that met the basic capabilities they had.

Having said that, I always enjoy doing a little extra analysis:

Format is undocumented (possibly from version-to-version of the same app,
between different versions of Windows itself, and in different language
versions of Windows), file isn't protected ("systeminfo.exe" anyway) and
could therefore be missing or may not even be available in all versions or
even in the same location (the "Path" environment variable should normally
locate it but there are no guarantees)

Systeminfo is indeed a protected file and installed by default to
%SystemRoot%\System32 on XP and above. It is also enough of a part of
the OS that it shows up when you do Help at a command prompt. Yes, the
actual format could have minor changes in the future, but surely you'd
still be able to find the string "Service Pack" ok.

WMI isn't installed by default in all environments (e.g., Win2003 Server).
VBScript is one possible alternative however (not my specialty) but at least
it's still going the programmatic route

The nice thing about WMI is that you can so easily use it to query a
remote system, therefore you don't even need any extra software
installed on that system. Even WMIC works remotely. It's interesting to
note that SystemInfo.exe that I mentioned above actually uses WMI
Win32_OperatingSystem class to gather the info it needs.

Already suggested that but he needs to verify that it's reliably available
and consistently formatted on all systems (not easy to verify)

This key, in its exact location, has actually been in use at least since
NT4 SP5. It is hard-coded throughout many portions of the OS and is
documented in the Windows SDK (regstr.h), so it is quite reliable. The
only key possible more reliable than this is
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Windows\CSDVersion,
which is what the OS uses for building the "official" version string,
but I still prefer the string version.

Totally unreliable. How do you know for instance that any of these files
will remain when the next SP is released or that they're even installed on
all SP2 versions of XP (they could in fact be installed on other versions of
Windows as well - MSFT sometimes relies on the same file names).

Sure, these might not be perfectly reliable, but something that might be
reliable enough and require very little work to implement. They could
also be used as a second check that, when combined with one of the other
checks, could be quite reliable.

Of course, the API is a great solution and probably the most
conservative approach. But it might not be necessary in this particular
situation.


Mark

 

[Michael Chambers]

Michael, I don't think the requirements are as stringent as you are making

them out to be. They just want to know if Sp2 is installed on an XP box.
Sure, you could find something to break any one of these methods, but
remember that we're only talking about one SP, one OS, and likely one
language. And since he said he wasn't a programmer, I offered alternatives
that met the basic capabilities they had.

Having said that, I always enjoy doing a little extra analysis:

In my judgment there's no point in performing what he calls an "integrity"
check if it's going to fail or provide erroneous results. Why even go
through the exercise if you can't trust the outcome. The methods you
suggested are potentially problematic or otherwise hacks. They're bound to
fail because there really is no clean way to do it without turning to an
official API (assuming MSFT can't offer some official alternative which is
unlikely). I can all but guarantee he's going to have more problems in the
long term by not going through official channels. That includes irritated
users if they can't connect or otherwise complain about software requiring
unacceptable security rights on their home computers (and then of course his
boss complaining about the substandard methods he adopted).