Blogs

Volume 2, Number 5

  • Comments 1
  • Likes
**********************************************************
THE SYSINTERNALS NEWSLETTER
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.

Comments