[Newsletters Archive ^] [< Volume 2, Number 4] [Volume 3, Number 1 >]

The Systems Internals Newsletter Volume 2, Number 5

www.sysinternals.com
Copyright (c) 2000 Mark Russinovich

November 30, 2000 - In this issue:

1. EDITORIAL

2. WHAT'S NEW AT SYSINTERNALS

   • PsLoggedOn v1.2
   • PsShutdown v1.0
   • PsTools v1.1
   • BgInfo v1.1
   • Tokenmon v1.0
   • Filemon v4.32
   • Regmon v4.32
   • Inside Windows 2000, 3rd Ed.
   • November and Winter Windows 2000 Magazine
   • Sysinternals at Microsoft
   • Sysinternals Licensing

3. INTERNALS INFORMATION

   • NFI
   • Hidden Win9x Registry keys

4. WHAT'S COMING UP

   • New Whistler System Calls

SPONSOR: WINTERNALS SOFTWARE

The Sysinternals Newsletter is sponsored by Winternals Software, on the Web at www.winternals.com. Winternals Software is the leading developer and provider of advanced systems tools for Windows NT/2K. Winternals Software products include FAT32 for Windows NT 4.0, NTFSDOS Professional Edition (a read/write NTFS driver for DOS), and Remote Recover.

The netstat command, which comes with all versions of Windows 9x and Windows NT/2000, shows you what TCP/IP ports are open on your system, however it does not show you what process has the port open. TCPView Pro, Winternals’ latest monitoring tool, not only comes with a netstat-equivalent command-line tool, Tcpvstat, that shows you which process has each port open, but includes a GUI that shows the same information plus a real-time trace of TCP/IP activity. The real-time trace reveals the application making a network access, the local and remote IP addresses of the access with optional DNS name resolution, the type of access, the success of the access, and the amount of data transferred. TCPView Pro is only $69. Download the 14-day fully functional trial version of TCPView Pro today at www.winternals.com/products/monitoringtools/tcpviewpro.shtml.

Hello everyone,

Welcome to the Sysinternals newsletter. The newsletter currently has 28,000 subscribers.

One of the benefits of moving from Windows NT to Windows 2000 is the greatly improved reliability. I’ve written about the reasons for the improvements in several articles, and they are primarily the result of a tool called the Driver Verifier. You can configure the Verifier, which you launch by typing "verifier" in the Start menu’s Run dialog box, to closely watch the execution of specific device drivers, looking for violation of any of several driver programming rules. The Verifier goes one step further than passively monitoring, however – it also exacerbates potential; error conditions by, for example, allocating memory blocks for the driver that are straddled with invalid regions, and zeroing specific fields in data structures that are passed to the driver. If you really want to get tough, you can have the Verifier simulate low memory conditions for the driver.

Microsoft leverages the Verifier through its driver signing program, which requires that any driver that is digitally signed by Microsoft to pass strict Driver Verifier testing. When a driver installs, the hardware wizard checks to see if the driver is signed. If its not, then it will either warn you or fail to install the driver, depending on the settings you’ve entered in the Driver Signing Options dialog, which is accessible from the Hardware page of the System applet in the Control Panel.

The fact that the default driver-signing policy warns end users about unsigned drivers is enough to make most hardware vendors go to the trouble of making their drivers robust and getting them signed. However, device drivers can sneak onto your system undetected by the driver-signing policy. Only drivers that are installed using INF files (driver installation files that end in the .inf extension) get checked for signatures. Setup applications can manually install drivers either by using Setup APIs directly, or by manually configuring the driver’s Registry settings. Sysinternals applications are great examples of this: Filemon, Regmon, and other Sysinternals tools that have driver components install their drivers manually, which is the reason you don’t get warned that they aren’t signed by Microsoft.

Drivers that aren’t commonly installed with INF files include virus scanners, encryption software, and CD-ROM burning software. However, that doesn’t preclude hardware-related drivers from slipping through. The Sysinternals Ctrl2cap driver for Windows 2000 (www.sysinternals.com/ctrl2cap.htm is an example of a hardware-related driver that installs in a manner that bypasses driver signing checks. This loophole leads to the presence of drivers on your system that have not been verified, which can compromise system stability (I verify all the Sysinternals drivers on the highest settings). Microsoft should force all drivers, not just those that install with INF files, to go through the signing check.

Why am I on this rant? My CD-ROM burning software, which is the most popular of that type of software on the market, has a driver that will reproducibly crash my Windows 2000 SP1 system. If I configure the Driver Verifier to check it, the system doesn’t even finish booting before the Verifier detects the driver’s first violation and crashes the system. The driver installed without an INF file so I wasn’t warned that it was unsigned. I guarantee that if Microsoft’s policy was stricter that this vendor would think twice before shipping an unsigned (and buggy) driver.

Please pass the newsletter to friends you think might be interested in its content.

Thanks!

-Mark

WHAT'S NEW AT SYSINTERNALS

PSLOGGEDON V1.2

Besides an obvious name change from LoggedOn to PsLoggedOn, this command-line tool, which has the ability to show you who is logged in locally and via resource shares on the local or a remote system, has some new features. The first is the ‘-l’ command-line switch that has resulted from user feedback. Many people use PsLoggedOn to see if any account is logged on locally to their servers. There may be users logged on through file shares, for example, but that isn’t relevant when making a decision about when an account can be updated or the server can be remotely administered.

PsLoggedOn’s second new feature shows you not only who is logged on, but the time at which the logon took place. PsLoggedOn obtains logon times for logons from resource shares for free when it uses a Win32 API, NetSessionEnum, to enumerate resource-share logons (the command-line Net command also uses NetSessionEnum to enumerate sessions). However, there is no Win32 API that tells you who is logged on to a system locally, much less at what time they logged on.

To determine who’s logged on to a system locally, PsLoggedOn enumerates the Security IDs (SIDs) located under a computer’s HKEY_USERS Registry key. When someone logs on to a computer locally, either at the console or through a service, his or her profile is loaded into the HKEY_USERS key. Applications can access their profile’s Registry settings through the HKEY_CURRENT_USER key because the system treats that key as a symbolic link to their particular profile under HKEY_USERS. Thus, PsLoggedOn can know who is logged on locally by translating the SIDs it finds in a computer’s HKEY_USERS key into the corresponding user name. PsLoggedOn uses RegConnectKey to connect to a remote computer’s Registry when you direct it to list users logged on to a remote system.

Figuring out what time a user logged on works using a similar trick. When the WinLogon process loads a user’s profile into HKEY_USERS after they login, WinLogon creates a volatile (not saved to the profile on disk) subkey in their profile named, appropriately enough, Volatile Environment. The Registry stores last-modified timestamps for Registry keys, and because the system does not modify Volatile Environment subkeys subsequent to their creation, PsLoggedOn can determine when a user logged on by obtaining the timestamp of their Volatile Environment subkey.

Download PsLoggedOn v1.2 with full source at
www.sysinternals.com/psloggedon.htm.

PSSHUTDOWN V1.0

If you’ve ever needed to shutdown or reboot a local or remote Windows NT/2000 system, then you’ll want to download PsShutdown. PsShutdown is a clone of the Shutdown Windows NT/2000 Resource Kit tool. It takes the same command-line arguments that allow you to specify a delay before the shutdown, whether or not to reboot, an optional message to display to any user currently logged on to the system, and the name of the computer to shutdown or reboot.

Download PsShutdown v1.0 at www.sysinternals.com/psshutdn.htm.

PSTOOLS V1.1

You’ve probably noticed the increasing number of tools at Sysinternals that begin with the prefix "Ps". The first was PsList, a command-line tool that lists information about the active processes on the local or a remote Windows NT/2000 system. I gave PsList its name because the standard UNIX command-line process information tool is named "ps". The next tool to get the prefix was PsKill, a command-line utility that enables you to terminate processes running on local or remote Windows NT/2000 systems. I gave PsKill the "Ps" prefix because it made a perfect companion to PsList.

Over time I have developed other tools that shared the same defining characteristics as PsList and PsKill: they are command-line based and work on the local or a remote Windows NT/2000 system. For example, ElogList let you dump the contents of a system’s event logs, and GetSid showed you the SID of a computer or particular account. Recently, I decided to tie all of these tools together by giving them all the "Ps" prefix and making them downloadable as a single package named PsTools.

PsTools, which includes PsList, PsKill, as well as the renamed PsLogList and PsGetSid, consists of a total of seven tools. If you see a Sysinternals tool with the "Ps"-prefix, you automatically know that it’s a command-line tool that works locally as well as remotely.

Download PsTools v1.1 at www.sysinternals.com/pstools.htm.

BGINFO V1.1

As a result of tremendous user feedback, Bryce has updated BgInfo, a utility that sets desktop wallpaper to display customizable information about a system’s configuration, as a result of the user feedback he’s gotten. By default, BgInfo counts down for 10 seconds before applying the settings specified in its dialog box, but a new command-line option, /timer, allows you to change or eliminate the countdown altogether. This makes it more convenient to include BgInfo in a logon script, or as a shortcut in a profile’s Startup folder.

Version 1.1 includes other new features, such as the ability to display arbitrary text that you define, and more pre-defined information categories. The desktop bitmap BgInfo v1.1 creates is also generally smaller, minimizing the BgInfo’s desktop memory footprint.

Download BgInfo v1.1 at www.sysinternals.com/bginfo.htm.

TOKENMON V1.0

Tokenmon is the latest addition to the varied suite of monitoring tools you can download from Sysinternals. Tokenmon, which shares the same UI as that of its cousins like Regmon and Filemon, monitors significant security-related activity on a Windows NT/2000 system. Just what is "significant" security-related activity? At the heart of Windows NT/2000 security is the token object, a data structure that contains an account SID, group SIDs, and privileges. Whenever a process attempts to access a secured object, the Security Reference Monitor uses the SIDs in its token as part of the access validation. If a process attempts to perform a restricted operation, such as reboot the system, the system checks the appropriate privilege in the process’ token.

One of the powerful (and patented) features of the Windows NT/2000 security model is impersonation. Impersonation lets a thread temporarily override its process-based identity and adopt an alternate identity through the use of an impersonation token. Server applications take advantage of impersonation when accessing resources on behalf of a client, when they adopt the identity of the client for the duration of the access.

Tokenmon installs system call hooks in the same way that Regmon does for Registry APIs, in order to monitor the creation and deletion of tokens, the enabling and disabling of privileges, and impersonation. Tokenmon also uses process creation hooks provided by the NT/2000 kernel to monitor the creation and deletion of processes, and other APIs to determine when a user logs on and when they log off.

The full source code to Tokenmon is posted, and it’s worth discussing some of the interesting techniques the code demonstrates. Tokenmon detects a logon event by hooking the NtCreateToken system call, which is the one used by logon brokers such as WinLogon to create an initial token for the first process of a new logon session. Processes created by the first process inherit a copy of the first token. To detect logoff, Tokenmon registers for logoff notification via the kernel-mode SeRegisterLogonSessionTerminatedRoutine function, an API that exists for the benefit of file system drivers, called network redirectors, that cache logon-session data and wish to cleanup when a user logs off. Network redirectors implement the client side of file sharing client/server connections.

Another interesting Tokenmon implementation detail is the way that Tokenmon hooks the APIs it monitors. Some of the APIs that Tokenmon hooks are not exported for use by device drivers, but are exported in the user-mode NTDLL.DLL library for use by applications that use their Win32 equivalents. All of the Registry APIs that Regmon hooks are exported in kernel-mode, making is possible for the Regmon device driver to obtain their system call numbers, and to hook the system call table appropriately. For APIs not exported for use by drivers, the Tokenmon GUI must obtain the call numbers by using the exports in NTDLL.DLL, and then pass the numbers to the driver so that the driver can hook the system call table. Thus, Tokenmon demonstrates how to hook system calls that are not exported in kernel mode.

Download Tokenmon v1.0 with full source at www.sysinternals.com/tokenmon.htm.

FILEMON V4.32

This latest Filemon update introduces more intuitive and complete filtering, display of full UNC path names for Windows 9x/Me network file access, and display of NTFS metadata file names.

Previous versions of Filemon required you to enter filters with mandatory wildcards. For example, if you wanted to monitor accesses to the Temp directory on drive C:, you had to enter a filter like this: "c:\temp\*". With the new filtering syntax wildcards are optional, so while the example filter would work, "c:\temp" would achieve the same effect. In addition, Filemon now applies the filters you enter against all fields in the display, including the process name, request type, path, and "other" column. This flexibility allows you to watch for specific types of requests, or requests with certain data in the other column, something not previously possible.

Users of Filemon on Windows 9x/Me systems will now see Filemon display path names with full UNC syntax when they access remote resources. Filemon previously did not display the server or share name for such accesses, resulting in incomplete path names.

Finally, if you’ve used Filemon on Windows NT/2000 you’ve undoubtedly seen the text "DASD" in the path column for many accesses ("DASD" comes from "Direct Access Storage Device", a term that Microsoft uses to describe accesses to a volume that bypass file system structures). For most activity on NTFS volumes, DASD is now a thing of the past. Instead, you’ll see the names of the NTFS metadata files that are being read and written. For example, an update to an MFT record would have resulted in a DASD output line before, but now you’ll see it as an access to "$Mft", the MFT’s internal metadata file name.

Why didn’t Filemon show metadata file names before, and how does it obtain these names now? The file objects that represent NTFS metadata files do not store a file name, so Filemon cannot extract the name from the file object. Filemon’s alternative method for obtaining a file’s name, querying the file system driver, doesn’t work either for NTFS metadata files. While NTFS does respond with the names of metadata files, NTFS on NT 4 randomly cause crashes, and NTFS on Win2k occasionally hangs when responding to such queries.

Filemon has to therefore resort to a trick to obtain the metadata file names. When it sees a request directed at a file object on an NTFS volume with no name it sends NTFS a query for the file’s index. This is the same index that the Win32 function GetFileInformationByHandle returns, and for files on NTFS volumes the index is the file’s MFT index. The first 16 entries in the MFT are reserved for specific metadata files, so given an index in that range, Filemon simply looks up the metadata file name in its own table.

Unfortunately, you’ll still see DASD for directory metadata and file allocation table (FAT) accesses on FAT volumes, because FAT doesn’t store names for directory metadata files or the FAT. You’ll be surprised at how often the NTFS logfile ($LogFile) is accessed. Incidentally, NTFS on Whistler stores the names for metadata files, so the trick is unnecessary on Whistler.

The final Filemon enhancement enables Filemon to show time-of-day timestamps with millisecond resolution. This support required ugly hacks in the Windows 9x/Me Filemon driver because of bugs in a timing function in the Windows 9x/Me kernel. See the source code for more information.

Download Filemon v4.32 with source code at www.sysinternals.com/filemon.htm.

REGMON V4.32

Regmon’s changes aren’t as major as those of Filemon, but Regmon now supports the same more intuitive filtering syntax as Filemon, and like Filemon, applies the filters to all fields. It can also show millisecond resolution on timestamps.

Those of you that have started playing with Whistler (the successor to Windows 2000) Beta 1 might have noticed that previous versions of Regmon crash Whistler when started. This is because Microsoft has placed the system call table, which Regmon modifies to insert its hooks, in write-protected memory. Regmon v4.32 works around this by using a technique for which I have not provided source code at the request of Microsoft, because the technique may break in the final release of Whistler, and Microsoft is exploring ways to support system call hooking. Windows NT was not designed to support system call hooking, which is something that we pioneered with the first release of Regmon back in mid-1996.

Here’s an undocumented Filemon/Regmon tip. I often get e-mails that ask how to run Regmon or Filemon from a non-administrative account on Windows NT/2000 There are many cases when a certain application works properly when run from the administrator account, but not from that of an unprivileged user, where Regmon and Filemon would be useful for determining why the application fails (its usually an issue related to security settings on a file or Registry key). However, running Regmon and Filemon from an unprivileged account will fail because both Filemon and Regmon install device drivers, something that requires administrator privilege.

However, there’s a trick that let’s you work around this: If you log in as an administrator and start Filemon or Regmon, you’ll be able to subsequently run them from unprivileged accounts. This is because Filemon and Regmon install a driver on their first execution, and in following executions access the already loaded driver. Since I don’t implement any security in the driver, an unprivileged user can run the tools after the driver is loaded. Security problem? Yes, but Filemon and Regmon are intended to be troubleshooting tools so I, and the people that ask how to run the utilities from unprivileged accounts, view this as a feature.

Download Regmon v4.32 with full source code at www.sysinternals.com/regmon.htm.

DEBUGVIEW V4.02

One of the applications I’ve received the most user feedback for is, somewhat surprisingly, DebugView. This new version has some significant enhancements that address many of the feature and functionality requests that I’ve received, and make DebugView more powerful than ever.

Most visibly, DebugView now supports up to five different highlighting filters, each with its own customizable colors. This allows you to simultaneously home in on different keywords in your debug output and easily distinguish them. In addition, DebugView implements the same new filtering syntax as Filemon and Regmon, making the wildcards optional for substring matching.

A complaint I received about previous versions of DebugView is that, even if you just wanted to capture Win32 debug output, you still needed administrative privileges to run DebugView, because DebugView would not run if it could not install its device driver. This new version runs even from accounts that have no special privileges. If it cannot install or access its driver it simply disables its kernel-mode capture-related menu items.

Two features that make it easier to have DebugView start capturing output automatically when you login are its minimize-to-tray option and support for command-line switches. Using command-line switches, you can have DebugView start in the system tray and log output that it captures to a file, and after you’ve started DebugView you can use a menu option to toggle its minimize button behavior between minimizing normally, and minimizing to the system tray.

For users that run DebugView in remote sessions on Windows 2000 terminal services, DebugView now captures Win32 output generated by applications running in your remote session, and optionally, from the console session. This is useful for debugging COM servers and Win32 services remotely, since these types of programs run in the console session.

Lastly, DebugView now works on Whistler Beta 1, with support for capturing output from the several new Whistler variants on the kernel-mode DbgPrint function.

Download DebugView v4.02 at www.sysinternals.com/dbgview.htm.

INSIDE WINDOWS 2000, 3RD EDITION

The official book on the internals of Windows 2000 is now available! This edition, coauthored by David Solomon (www.solsem.com) and Mark Russinovich, is over 40% larger than the previous, with new coverage of networking, plug-and-play, power management, services, the Registry, WMI, boot and shutdown, and storage. It also includes a CD with several powerful tools, not available anywhere else, for investigating Windows 2000 internals.

One of the tools that I wrote specifically for the book is LiveKd, a program that let’s you run both of the Microsoft kernel debuggers, i386kd and WinDbg, on a live system as if you were looking at a crash dump. Many of the experiments presented in the book work on a live system when run using LiveKd. LiveKd works by installing a file system filter driver that presents the physical memory of the computer to the Microsoft debugger as if it were a crash dump file. LiveKd creates a pseudo dump file of 0 length, and when the debugger reads from the file, LiveKd returns data from physical memory. Check out the book’s errata and updates page for a LiveKd patch that corrects an incompatibility between LiveKd v1.0 and several on-access virus scanners.

See the book’s table of contents and order now through www.sysinternals.com/insidew2k.htm.

NOVEMBER AND WINTER WINDOWS 2000 MAGAZINE

Curious about what exactly changed between NTFS v4 and NTFS v5? If so, check out my two-part series in the November and Winter issues of Windows 2000 magazine. Part 1 describes reparse points, directory junctions, volume mount points, quota support, and consolidated security settings. Part 2 concludes with a close look at encryption, streams, distributed link tracking, and the change journal. Both articles take you deeper than others do, presenting the on-disk changes and internal behavior of these new features.

One thing I don’t talk about in the articles is how NTFS for Windows NT 4 isn’t really version

Find links to all our publications at www.sysinternals.com/publ.htm.

SYSINTERNALS AT WWW.MICROSOFT.COM

Sysinternals has made an appearance in several new Microsoft Knowledge Base (KB) articles since the last newsletter, and I’ve also tracked down some older KB articles that refer to Sysinternals.

• Q260513 PRB: An Error Occurs When You Install Visual Studio Products
  http://support.microsoft.com/support/kb/articles/Q260/5/13.ASP
  This article recommends readers use Filemon and Regmon to troubleshoot Microsoft Visual Studio installation problems.

• Q202258 XADM: The System Cannot Find the Path Specified - ID No: 0cx002003
  http://support.microsoft.com/support/kb/articles/Q202/2/58.ASP
  Microsoft actually walks users through using Filemon to troubleshoot Exchange 5.0 service pack upgrade problems, complete with a sample Filemon output line and recommendations on setting up filters.

• Q269383 PRB: 'Error Accessing the System Registry' Message When Displaying VB/VBA References
  http://support.microsoft.com/support/kb/articles/Q269/3/83.ASP
  Regmon gets the referral from this article, which discusses using it to determine why the References dialog in the Visual Basic IDE reports when it can’t access a Registry key as a result of a bug in Seagate Crystal Reports that applies incorrect permissions to several keys.

• Q269251 BUG: Automating Windows Installer May Hang When Enumerating Products
  http://support.microsoft.com/support/kb/articles/q269/2/51.asp
  Regmon is highlighted again here, where it’s used to reveal a Windows Installer automation bug.

• Q276525 Your Computer May Stop Responding When You Monitor Open Handles
  http://support.microsoft.com/support/kb/articles/Q276/5/25.asp
  NtHandle is responsible for revealing a bug in Windows NT 4 SP6a, where the kernel would hang under certain conditions when using NtHandle. Microsoft worked with me to resolve the problem and they have issued a hotfix. If your NT 4 system hangs when using NtHandle, you should get the follow the link to this article.

• Q160660 Ntregmon.exe causes STOP 0x0000001E with New Service Pack
  http://support.microsoft.com/support/kb/articles/Q160/6/60.asp
  This last one is an oldie, but goodie. The first version of Regmon used hard-coded system call numbers to patch the system service table in order to hook Registry APIs. Because system call numbers sometimes change between service packs, this technique is pretty fragile, and I hadn’t coded defensively in anticipation of this (against the advice of Andrew Schulman, who was afraid Regmon would break). Sure enough, SP3 introduced a few new system calls, and Regmon would crash the system when it hooked incorrect system calls. While this surely annoyed a few people, I did get my own KB article out of it!

SYSINTERNALS LICENSING

Even though the software you download from Sysinternals is freeware, meaning you can use it without paying a fee, you are not permitted to redistribute it, or to derive products that you distribute from Sysinternals source code. For instance, if you work at a company where multiple users find particular Sysinternals tools useful, you may not post the tools to an internal share or Web site. Instead, place a links on your site to each tool’s home on Sysinternals. This also helps to make sure that your coworkers always download the latest versions.

If you wish to redistribute Sysinternals tools internally, with a commercial product, or on a shareware CD, or you want to base a commercial product or redistributable program on Sysinternals source code, send an e-mail explaining the details of your desired use to licensing@....

INTERNALS INFORMATION

NFI

A few newsletters back I revealed the existence of the DiskEdit tool that Microsoft inadvertently shipped on the NT 4 SP4 CD. DiskEdit is a very powerful, though quirky, file system structure viewer that you can use to examine NTFS and FAT (though it’s the NTFS support that’s interesting) on-disk data structures. If you missed the NT 4 SP 4 CD and are interested in exploring NTFS on-disk structures you’re not totally out in the dark, though. Microsoft has released a free tool named NFI (NTFS Information) that understands and can dump the internal structures of NTFS volumes. While its output is not nearly as detailed as that of DiskEdit, it is interesting and revealing.

You can download NFI as part of the OEM Support Tools at http://support.microsoft.com/support/kb/articles/q253/0/66.asp. Running NFI with a file name dumps the NTFS MFT record for that file. The following example shows NFI dumping the MFT record for the $Quota metadata file, a file that only exists if you have quota management enabled on a volume:

C:\nfi c:\$extend\$quota
File 24
\$Extend\$Quota
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$INDEX_ROOT $O (resident)
$INDEX_ROOT $Q (resident)

The output shows that the file occupies the 24th entry in the MFT (its file index is 24), and that it contains four attributes, including standard-information, file name, and two index roots (and index is essentially a collated list of entries, like a directory). I describe how NTFS uses the $Quota indices in my latest Windows 2000 Magazine series on NTFS v5.

To dump all the files on a volume specify the drive letter on NFI’s command-line without a file name e.g. nfi c:. You’ll see a list of each MFT entry, including all the metadata files.

NFI has some other talents, like the ability to translate a sector number into the file in which it resides. Want to know what file sector 2345 on drive C: is in? Use the command nfi c: 2345. Note that this fails on software-RAID volumes like volume sets and stripe sets. NFI works on both NT 4 and Windows 2000.

HIDDEN WIN9X REGISTRY KEYS

Two issues ago I said that I would cover "hidden Win9x Registry keys" in the following newsletter, and several of you reminded me that I had forgotten. So this month I’ll tell you about hidden Registry keys in Windows 9x.

Several years ago I discovered a way to create hidden Registry keys in Windows NT. By hidden, I mean that, although you can see the keys being accessed by the application that creates them with Regmon, you can’t write a Win32 program to look at the key’s values, nor can you look at the keys with the Regedit or Regedt32 Registry editors. Hidden keys are useful for storing data that you don’t want end-users to be able to modify, such as a trial-product’s timeout date.

The trick to making a hidden Registry key was my realization that the native NT API, which is the system call interface upon which the Win32 API is built, requires that Registry keys be specified as counted Unicode strings. A counted Unicode string is one whose length is indicated by a length field, not the presence of a null terminator. Using the native API you can therefore create Registry keys that contain a null character, like "test\0test". Since the Win32 API’s Registry key API is based on null-terminated strings, there’s no way to open a Registry key that contains a null terminator using the Win32 API. If you tried passing the preceding example key name to RegOpenKey or RegCreateKey it would be treated as "test" , with the string truncated at the null character. Since all existing Registry editors, including those bundled with Windows NT and Windows 2000, use the Win32 API, an application that uses the native API to create null-character-embedded names effectively makes hidden keys.

This method works on Windows NT, but what about Windows 9x? I didn’t think there was a way to make hidden Registry keys on Windows 9x until someone e-mailed me with a Regmon log file that shows Internet Explorer (IE) accessing keys that don’t appear in Regedit. To see this for yourself, start Regmon and set the following include filter: "policydata". Then start IE (this works for all versions of IE 4 and IE 5) and visit a web site. If you don’t see any output in Regmon, go to IE’s options configuration dialog and ensure that the Content Advisor is enabled.

If the Content Advisor is enabled, or has ever been enabled on your system, you’ll see accesses to the HKLM\PolicyData key and its subkeys. However, you won’t find a PolicyData key under HKEY_LOCAL_MACHINE when you look in Regedit. Take a minute and see if you can figure out what’s going on.

The answer is that IE is dynamically loading a Registry hive using the RegLoadKey Win32 API, reading the values it needs, and then unloading the hive with RegUnloadKey. The hive is named C:\Winows\System\Ratings.pol – the file is hidden and read-only, but you can reveal it by typing attrib –r –h c:\windows\system\ratings.pol.

The traces that you see in Regmon show you the information that the Content Advisor is looking for in the hive. If you want to explore its contents yourself, download my Regload utility from www.sysinternals.com/regload.zip and run it with the following syntax: regload test c:\windows\system\ratings.pol. Then open Regedit and browse HKLM\test. The values you’ll find correspond to the settings you specify in the Content Advisor, and are related to the configuration file named in the Users\FileName0 value in the hive. The value typically points to C:\Windows\System\RSACi.rat, the ratings file defined by the Internet Content Rating Association. Incidentally, you might see a value with the somewhat humorous name of "PleaseMom" in the Content Advisor’s Registry settings, for example under HKLM\Test\Users\Default. This value derives from the "Supervisor can type a password to allow users to view restricted content" checkbox on the General page of the Content Advisor settings dialog.

The reason Microsoft would obfuscate the existence of these Registry values should be obvious. However, there’s a pretty serious weakness in their design. Note that when you enable the Content Advisor you must specify a password that protects the Content Advisor’s settings dialog. This password is stored in HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Ratings\Key. Delete that value and, presto, you can access the Content Advisor settings without entering a password! Now if the IE developers went to the trouble to obfuscate the Content Advisor settings, why do they leave this back door hanging out in the open? Typical Microsoft security design, I guess. By the way, to unload the key you loaded with Regload just type regload test.

WHAT'S COMING UP

NEW WHISTLER SYSTEM CALLS

Whistler is an incremental evolution of the Windows 2000 operating system with a focus on increased reliability and easy migration of users from Windows 9x operating systems. However, it does include some kernel changes. The most visible are the handful of new system calls and exported (available for use by device drivers) kernel functions. Next time I’ll give you a preview of these new kernel APIs.

Thank you for reading the Sysinternals Newsletter.

Published Thursday, November 30, 2000 7:05 PM by ottoh

[Newsletters Archive ^] [< Volume 2, Number 4] [Volume 3, Number 1 >]