Edit
  • Article

[Newsletters Archive ^] [< Volume 6, Number 2] [Volume 7, Special Announcement >]

The Systems Internals Newsletter Volume 7, Number 1

http://www.sysinternals.com
Copyright (C) 2005 Mark Russinovich

January 5, 2005 - In this issue:

  1. EDITORIAL

    • Got DEP?

  2. WINDOWS INTERNALS, 4TH EDITION

  3. WHAT'S NEW AT SYSINTERNALS

    • November Statistics
    • Sysinternals Magazine Articles
    • Sysinternals RSS Feed
    • Mark is a Microsoft MVP
    • Autoruns v6.01
    • Process Explorer v8.61
    • Sigcheck v1.0
    • Bginfo v4.07
    • Regjump v1.0
    • Hex2dec v1.0
    • Tcpvcon v2.34
    • PsTools Updates
    • Sysinternals at Microsoft

  4. INTERNALS INFORMATION

    • Internet Browsing
    • Using LiveKd to troubleshoot sick systems
    • CreekSide?
    • ChkReg Registry Fixer
    • Windows Memory Diagnostic
    • Researching undocumented interfaces

  5. INTERNALS TRAINING

    • Windows Connections in San Francisco
    • Hands-on Windows Internals/Sysinternals Classes by Mark Russinovich & David Solomon

The Sysinternals Newsletter is sponsored by Winternals Software, on the Web at http://www.winternals.com. Winternals Software is the leading developer and provider of advanced systems tools for Windows NT/2000/XP/2003.

Winternals is pleased to announce the upcoming release of Administrator's Pak 5.0 with a comprehensive update including ERD Commander 2005.

New features in ERD Commander 2005 include:

  • Crash Analyzer: Quickly and easily diagnose the driver responsible for a Windows crash - even if the system won't boot
  • DiskWipe - Securely erase hard disks or volumes; Autoruns: See which applications are starting at Windows setup and user logon - useful for diagnosing system resource issues and finding potential malware
  • FireFox Web Browser: download hotfixes, driver updates, search for help in the Microsoft Knowledge Base - all on the system you are trying to repair
  • Hotfix Uninstall Wizard, which allows you to remove hotfixes and service packs on an unbootable system
  • System File Repair, which checks Windows system files for integrity.

These features, numerous improvements and usability enhancements to ERD Commander 2005, and a new easier to build and use Remote Recover client based on Windows PE are all included in the new Administrator's Pak 5.0, available in late January 2005. To sign up for an evaluation of the Administrator's Pak 5.0 when it is released, visit http://www.winternals.com/ap5preview/.

EDITORIAL

Hello everyone,

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

The rising tide of malware, including spyware and viruses, has everyone concerned about security. Good security measures include keeping up with operating system and application patches, installing and configuring firewall, antivirus, and spyware removal tools, and exercising judgment when downloading from the Internet or opening e-mail attachments. Despite thorough measures, however, malware can still find ways to sneak by defenses and infect a computer. The most common loophole in a system's defenses is the buffer overflow vulnerability, and that's why you should be familiar with Windows XP Service Pack 2's Data Execution Prevention (DEP) feature.

A buffer overflow is a programming error that malicious programs can take advantage of to take control of the thread that executes the coding error. Buffer overflows are usually stack-based, meaning that an attacker gives the program more data than will fit into a buffer stored on the stack. The data is crafted in such a way that when the function with the overflow tries to return to the function from which it was invoked, it instead returns to a location in the data.

Unfortunately, buffer overflow errors can plague even the best-tested and reviewed software. Multiple buffer overflows are announced for Windows and its component software on a monthly basis (Linux and its applications are not immune, with a number of buffer overflow on par with Windows). A common theme for most buffer overflow exploits is that they result in execution of code placed in memory regions that should contain only data.

While the Intel Itanium processor has supported no-execute protection from its release, it was not until Windows XP SP2 (and the upcoming Windows Server 2003 SP1) that Windows actually makes use of this hardware support, for example marking thread stacks and heap memory as non-executable. Other processors that support no-execute hardware protection include the 64-bit AMD64 Opteron and Athlon 64 and Intel's clone called EM64T-now available on Xeon and Pentium 4 processors. AMD and Intel recently introduced 32-bit processors with no-execute support: the AMD Sempron and the Pentium 4 "J" family (such as the 520J, 540J, etc).

It might seem obvious to you that Windows should by default enforce no-execute protection for stacks and application heap memory to prevent buffer overflow exploits, but there are hundreds of thousands of existing applications, some of which that might actually rely on the setting not being enforced for correct operation. Therefore, Windows XP SP2, the first release of Windows that enforces no-execute protection, gives an administrator control over what processes get protected and which ones don't. First, in a decision aimed at improving security in the future, the 64-bit version of Windows always enforces no-execute flags for all 64-bit processes. If a software vendor wants to release a 64-bit application they need to make sure that they don't execute code from non-executable regions of memory (they can mark a data region as executable if they generate code on-the-fly, as Java and .NET applications often do).

Second, since buffer overflow exploits are most commonly aimed at operating system components, 32-bit Windows XP and Windows Server 2003 by default protect core operating system images. However, for 32-bit applications (running on either 32-bit Windows or 64-bit Windows), Windows XP defaults to an "opt-in" strategy (applications are not protected by default) while Windows Server 2003 defaults to "opt-out" (applications are protected by default but specific applications can be excluded). This makes sense because security is typically of higher priority on server systems. You can change the opt-in or opt-out settings in the DEP configuration dialog that you access through the Settings button in the Performance section of the Advanced page of the System control panel applet.

As I mentioned earlier, with the exception of the relatively new AMD Sempron and Pentium 4 "J" processors, all x86 compatible chips released to date lack no-execute support. However, Windows XP and Windows Server 2003 implement a limited form of DEP on those processors called "software DEP". Because the operating system gains control of a thread when the thread generates a fault, it can ensure that the fault handler it will execute is one that is statically registered by the program's code. This prevents an exploit that redirects a thread's fault handler to execute malicious code in an overflowed stack buffer, which is what the CodeRed virus caused IIS to do when it was released in 2001.

Despite its relative simplicity, DEP is one of the strongest defenses the operating system offers in its shield against self-propagating malware. Sadly, three things limit its power: lack of hardware support in most currently-deployed processors for the no-execute setting, the default opt-in setting in Windows XP such that only core operating system processes are protected, and lack of awareness. Software DEP is limited in its scope and so DEP is only marginally effective unless you are running Windows on hardware that supports no-execute. The fact that Windows XP defaults to opt-in means that even when users run Windows on no-execute hardware the only processes that get DEP protection are those of the operating system - if there's a buffer overflow in you're third-party firewall, Web browser, e-mail reader, or other network-enabled application, you're still vulnerable. In fact, some of the applications most-exploited by malware, IIS and Outlook, aren't protected under the opt-in setting. Finally, because most people aren't aware of its default behavior, or even DEP at all, systems will for the most part remain at risk for buffer-overflow problems.

Its time that Microsoft makes users pay the compatibility price in exchange for better security or users are going to end up paying a much higher price at the hand of viruses - and they will in turn pass the bill onto Microsoft. In the meantime, I strongly recommend you upgrade to Windows XP SP2 (Windows XP 64-bit Edition and Windows Server 2003 SP1 also have support for no-execute), switch to opt-in, and upgrade to a processor with no-execute support (sadly, I won't get a commission).

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

Thanks!

-Mark

WINDOWS INTERNALS, 4TH EDITION

The official Microsoft book on the internals of Windows Server 2003, Windows 2000 and Windows XP, which I coauthored with Dave Solomon, is now available in book stores. Dave and I expanded the coverage of the previous edition by about 25%, adding new material not only on Windows Server 2003 and XP changes, but on troubleshooting tools and techniques. You'll find advanced tips on using Process Explorer, Filemon and Regmon, and there's an entire new chapter on Windows crash dump analysis.

Learn more about the book's content and order on-line at

http://www.sysinternals.com/windowsinternals.shtml

WHAT'S NEW AT SYSINTERNALS

SYSINTERNALS RSS FEED

I got the request to add a new-posting notification mechanism to Sysinternals so often that I finally followed the web-wide trend and added an RSS feed (if you're not familiar with RSS feeds, here's a good primer: http://rss.softwaregarden.com/aboutrss.html). The feed also gives me the opportunity to notify you of minor bug fixes and updates that don't warrant a full listing on the front page. It already looks like the preferred way for people to learn of updates based on the number of hits the feed gets per day.

Access the Sysinternals RSS feed at:

http://www.sysinternals.com/sysinternals.xml

SYSINTERNALS MAGAZINE ARTICLES

About six months ago I started authoring a semi-monthly column in Windows IT Pro Magazine (formerly Windows and .NET Magazine) on Sysinternals tools. Each column describes a different tool, providing tips on advanced usage and information on how they work.

Of the three that have been published, listed below, the first two are accessible on-line by non-subscribers and the third will be soon:

Autoruns: http://www.win2000mag.com/Windows/Article/ArticleID/44089/44089.html

Pslist and Pskill: http://www.winnetmag.com/Windows/Article/ArticleID/43569/43569.html

PsExec: http://www.winnetmag.com/Windows/Issues/IssueID/714/Index.html

MARK IS A MICROSOFT MVP

The Platform SDK Microsoft Most Valuable Professional (MVP) lead has named me an MVP for 2005. I'm grateful to him and Microsoft for this official acknowledgment of the contributions I've made to Microsoft customers with Sysinternals.

NOVEMBER STATISTICS

I finally got a decent web traffic analysis program for Sysinternals and have analyzed the log files for the month of November. The magnitude of the numbers amazed even me. Here are some highlights:

  • 3.6 million page views
  • 775,000 unique visitors
  • 1.2 million utility downloads
  • 200,000 downloads of Process Explorer, the #1 download

AUTORUNS V6.01

Autoruns has evolved a lot in the last several months with two major version number updates. The latest release of Autoruns displays auto-start locations in addition to the standard Run key and startup folders, including Winlogon notification DLLs, Explorer toolbars, namespace extensions and browser helper objects, and auto-initialization DLLs. Another new feature, the Google menu item (borrowed from Process Explorer) helps you identify unknown images by opening a browser and initiating a search of the selected image name.

Another new feature, image signing verification, can help you distinguish between malware and system components or trusted applications. Microsoft generally includes hashes of operating system files that are signed with Microsoft's private signing key. Windows cryptographic functions decrypt the signed hashes with Microsoft's public signing key and Autoruns validates the images on your system by comparing their hashes with the decrypted versions, prefixing the image's company name with "(Verified)" when there's a match. If an image has been tampered with, corrupted, replaced, or has a hash signed by a publisher that is not trusted by your system, Autoruns reports the company name for the image as "(Not Verified)".

As a systems administrator you may want to check the auto-starting images in accounts other than the one you're logged-in as, so Autoruns now includes a User menu with selections for each account that has a profile stored on the computer.

Finally, there's now a command-line equivalent of the Autoruns GUI, called Autorunsc, that lists autoruns information to the console. Its ability to format the output as CSV, when combined with Sysinternals' PsExec utility, makes it easy for you to generate inventories of the configured auto-starting images for computers throughout your network.

Download Autoruns at
http://www.sysinternals.com/ntw2k/freeware/autoruns.shtml

PROCESS EXPLORER V8.61

Once again, Process Explorer, a tool that replaces Task Manager as an advanced process management utility, has been the tool on which I've focused the most, and that's because I get so much feedback for it. Since the last newsletter Process Explorer has gone from version 8.4 to 8.6. A slew of new features mark these two releases, including a Google menu item that initiates a search for information about a selected process, a strings tab in the process properties dialog that lists the ASCII and Unicode strings present in a process image file, a strings menu entry that lists strings in a selected DLL image file, and the name of the most CPU-consuming process in the tooltip that shows when you hover the mouse over the Process Explorer tray icon.

Many people requested features that they missed when switching from Task Manager, such as the Task Manager Applications tab. The Applications tab shows a list of top-level windows on the interactive desktop along with the status of the thread that owns each window: "Running" if the thread is currently waiting to receive a windows message or has processed a windows message within the last five seconds, and "not responding" otherwise (ironically, this generally means that "running" indicates the thread is waiting and "not responding" that its off running). You can now get this same information with Process Explorer by adding the "Window Title" and "Window Status" columns to the process view.

Process Explorer has had features targeted at.NET processes for some time, including highlighting for .NET processes and a .NET Performance tab in the process properties dialog of .NET processes. A .NET process is one that has loaded and registered with the .NET runtime. If a process registers sometime after it starts up Process Explorer may not realize that it's a .NET process, but the latest release rechecks processes for .NET status and job object membership when you manually refresh the display, either by pressing the refresh toolbar button, F5 key, or selecting the Refresh menu item.

For situations when you're not sure what process owns a window you can use the new window-finder toolbar button to identify it. Simply drag the toolbar button, which looks like a target, off the toolbar and over the window in question and Process Explorer selects the owning process in the process view.

An addition that will be immediately obvious to you is the mini-CPU graph that displays near the toolbar. This graph shows the CPU usage history of the system, and like the expanded version you get when you click on it to open the Process Explorer System Information dialog, presents a tooltip that includes the timestamp and highest CPU consuming process for the point in the graph over which you move the mouse. You can move the graph to anywhere in the toolbar area, even onto its one row so that it stretches across the width of the Process Explorer window.

Two security-related features are image-signing verification and data execution protection (DEP) status. When you enable the image signing option Process Explorer will check to see if a process image has been digitally signed by trusted signer and, like Autoruns, prefix the company name in the process properties dialog with "Verified" or "Not Verified". The option is disabled by default because the image signing check can take several seconds as the check goes to web sites to verify the validity of signing certificates.

DEP, which I describe in this newsletter's introduction, is something that you should enable on Windows XP SP2 for enhanced protection against buffer overflow exploits. You can check the DEP status of a process either by adding the "DEP Status" column to the process view or by checking the "DEP status" field on the image page of the process properties dialog.

Finally, Process Explorer now lists the drivers loaded on the system in the DLL view of the System process, which is the process associated with kernel and device driver worker threads. The same information is available for each driver as for DLLs listed for other processes, including version, company name, full path, and load address in the system address space.

Download Process Explorer at
http://www.sysinternals.com/ntw2k/freeware/procexp.shtml

SIGCHECK V1.0

Many of Sysinternals tools are adopting features that help users identify malware and Sigcheck is a command-line utility focused almost exclusively on that goal. It uses the same image signing verification functionality included in Autoruns and Process Explorer to tell you whether or not a file has been digitally signed by a trusted publisher. In addition, it reports file version information for the image or images you specify, including the product name, description, company name, and version. This information is similar to that which the Filever tool that ships with Windows XP and Windows Server 2003 reports, but Sigcheck also reports the timestamp when the file was originally "linked" or created for unsigned images, and the timestamp of the image signing for ones that signed. Finally, most signed hashes are signed with keys that themselves have been signed, a sequence that forms what's called a certificate signing chain. Sigcheck supports a command-line option that directs it to print the signing chain with information about each of the signers in the chain.

One of the potential security-related uses of Sigcheck is to investigate any unsigned .exe .dll or .sys images in any of the directories under the root of your Windows installation (typically \Windows). You can easily identify unsigned .exe images by running Sigcheck with this command-line, for example:

sigcheck -s -u c:\windows\*.exe

All Microsoft images should include valid signatures, but the above command will sadly reveal that many don't, resulting in files that can be potentially exploited to hide malware.

Download Sigcheck at
http://www.sysinternals.com/ntw2k/source/misc.shtml

BGINFO V4.07

This minor update to Bginfo, a tool that displays the information you configure on the desktop of the computer on which you run it for easy viewing, has better support for bitmaps that it must stretch to fit the size you specify, CPU detection enhancements, support for MySQL, and improved multi-monitor display compatibility.

Download Bginfo at
http://www.sysinternals.com/ntw2k/freeware/bginfo.shtml

REGJUMP V1.0

If you've ever wanted to create Explorer shortcuts to specific Registry keys or to simply enter a key's path and have Regedit open to the target location then you'll find Regjump useful. Regjump is a command-line utility that uses the same Registry "jump-to" technology we pioneered in Regmon. Give Regjump a Registry path as its command-line argument and Regedit will open and navigate to the specified key or value.

Download Regjump at
http://www.sysinternals.com/ntw2k/source/misc.shtml

HEX2DEC V1.0

Working with debuggers and disassembly I often find myself having to convert hexadecimal to decimal and vice versa. I finally got tired of opening Calc, entering a number, and then switching the base to see the conversion and so I wrote a tiny command-line conversion utility. Hex2dec converts in either direction and conveniently identifies input as hexadecimal if it has a "0x" or "x" prefix or includes the letters 'a'-'f' (its case insensitive).

Download Hex2dec at
http://www.sysinternals.com/ntw2k/source/misc.shtml

TCPVCON V2.34

Netstat is a command-line utility built into Windows NT and higher that shows you the currently active TCP and UDP endpoints on the system. The version Microsoft introduced with Windows XP includes a useful piece of information: the process identifier (PID) of the process that opened each endpoint. However, to determine the name of the process or any other information about it you have to open a process listing tool and find the process with that PID.

TCPView is a Sysinternals GUI application that shows the same active endpoint information, but much more conveniently than Netstat, because it includes the name of the process, quickly switches between DNS names and raw IP addresses, and highlights with colors new and deleted endpoints. TCPView's download now includes TCPVCon, a console version of TCPView, for those of you that like to use command-line interfaces. Unlike Netstat, TCPVCon displays the full path of the process associated with each endpoint and includes a switch that dumps output in CSV format.

Download Tcpvcon at
http://www.sysinternals.com/ntw2k/source/tcpview.shtml

PSTOOLS UPDATES

PsKill and PsLoglist are the two PsTools that have gained enhancements in the last few months. PsKill, a command-line utility that terminates processes on the local or a remote system, now supports a -t switch so that you can end an entire tree of processes. A number of people asked for this option to make it easy to clean up runaway trees of batch scripts.

PsLoglist is a command-line tool that dumps event logs on local or remote systems. Recent updates have added 5 options to its already lengthy list of command-line qualifiers. The new arguments allow you to exclude specified event types or event sources from the output or only dump events from the last few minutes or hours. It now also supports an event log monitoring mode where it runs until you terminate it, printing event log records as they generate.

Download PsTools, including PsKill and PsLoglist, at
http://www.sysinternals.com/ntw2k/freeware/pstools.shtml

SYSINTERNALS AT WWW.MICROSOFT.COM

Here's the latest installment of Sysinternals references in Microsoft Knowledge Base (KB) articles released since the last newsletter. This brings to 63 the total number of public KB references to Sysinternals.

  • FIX: Windows Media Player 9 Series for Windows frequently accesses the registry and may affect performance http://support.microsoft.com/?kbid=886423

  • GDI+ 1.0 Security Update Overview http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/gdiplus10security.asp

  • Registry Editing http://support.microsoft.com/default.aspx?scid=kb;en-gb;835818

  • You receive a "There is no information to display in this view" error message when you try to access a Project View http://support.microsoft.com/default.aspx?scid=kb;en-us;810596

INTERNALS INFORMATION

INTERNET BROWSING

About a year ago I announced that I had switched from IE to Mozilla because IE lacked the features considered mandatory for a decent Internet browser, like popup blocking, tabbed browsing, automatic form filling, and advertisement filtering. Not long afterward someone pointed me at Avant Browser, a small download that uses IE (it is not its own browser) to give it all that and more. Mozilla's clunky UI and lack of compatibility with certain sites I frequent made the decision to switch easy. While the new FireFox release is better in both respects, there are still some incompatible sites (like Windows Update, for instance) and so I haven't been compelled to switch again.

Microsoft's slow of progress improving IE, even in light of IE's modest Windows XP SP2 enhancements, should shame them into buying Avant Browser and building it into the next version of IE.

Download Avant Browser at: http://www.avantbrowser.com

USING LIVEKD TO TROUBLESHOOT SICK SYSTEMS

LiveKd is a utility that I wrote for the 3rd edition of Inside Windows 2000 (it's now a freeware tool on Sysinternals). It lets you use Windbg or Kd of the Microsoft Debugging Tools for Windows package to execute debugging commands normally used to investigate crash dumps and frozen systems on a system that's on-line and active. Microsoft introduced a similar capability, called "local kernel debugging", for the debugging tools when running on Windows XP and higher. There are several things you can do with LiveKd, however, that you can't with local kernel debugging. For example, you can't look at kernel-mode thread stacks with local kernel debugging and the list-kernel modules command, lm k, lists only the operating system kernel and not the other load drivers when executed in local kernel debugging. Both commands work inside of LiveKd.

Another command that doesn't work in local kernel debugging, but that does in LiveKd, is .dump. I learned from a Microsoft Product Support Services (PSS) engineer that the .dump command can be useful for troubleshooting a sick system. A computer that is experiencing problems, but delivering services such as web or database, may not be a candidate for rebooting or traditional debugging where the system is paused during the investigation. Running LiveKd and executing .dump results in a crash-dump formatted file that contains the contents of the system's physical memory. You can take the dump file to another machine and analyze the state of the operating system and service applications by loading the dump file into WinDbg or Kd, thus avoiding an outage while you look into the cause of a problem.

Download LiveKd at
http://www.sysinternals.com/ntw2k/freeware/livekd.shtml

CREEKSIDE?

I was recently investigating the initialization of Windows XP Service Pack 2 version of Winlogon, the system process responsible for presenting the logon user interface, when I came across code in the disassembly where Winlogon checks for the presence of a DLL named ediskeer.dll in the \Windows\System32 directory, ensures that its digitally signed by a trusted signer if it exists, and then loads it and calls an unnamed function exported by the DLL. The Winlogon code that executes when someone logs onto the system also calls into the DLL if it was loaded during initialization.

I looked for the DLL on my system and didn't find it, and it's also not present on the Service Pack 2 CD. So what is the DLL? Using the debug symbols that Microsoft ships for the operating system I could see Winlogon configure a variable named "Creekside" if ediskeer.dll is present and signed and then I realized that "ediskeer" consists of the last 8 letters of "creekside" in reverse order. I'm still not sure what Creekside refers to, but I strongly suspect that the DLL is one that ships only with Windows XP Starter Edition, the low-cost version of Windows XP that Microsoft recently introduced for developing countries. Starter Edition is based on the same operating system core as Windows XP Professional and Home Editions, but it imposes limits on the number of applications a user can have concurrently running. If I'm correct, Winlogon loads the DLL to enforce that limit, activating it every time a new user logs on.

CHKREG REGISTRY FIXER

Over the years Bryce and I have gotten numerous requests for a Registry-analogy for Chkdsk, the file system consistency checking utility. We've never written one because we've felt the audience for one is too small to justify the effort. About a year ago Microsoft released the little-known Chkreg, a Chkdsk for the Registry that fixes many types of Registry corruption.

Unfortunately, Chkreg is only supported on Windows 2000 (it may also work on Windows NT 4 and Windows XP Registries) and is implemented as a "native" application that uses the native API instead of the Windows API and so it won't run under Windows. When you download it you'll have to install it to a set of six Windows setup boot floppies, a tedious and time-consuming affair. We've contacted the developers of Chkreg and encouraged them to publicly release the Windows version that we've learned that Microsoft Product Support Services (PSS) is using in-house, but have no word on when or if they will release it.

You can download Chkreg at
http://www.microsoft.com/downloads/details.aspx?FamilyID=56D3C201-2C68-4DE8-9229-CA494362419C&displaylang=en

WINDOWS MEMORY DIAGNOSTIC

One of the most frustrating experiences for a Windows user is a crashing system. In most cases the fault is a buggy 3rd-party device driver, which you can remedy by disabling the driver or updating to a version with a fix. About 10% of crashes reported to Microsoft Online Crash Analysis (OCA) are caused by hardware problems, the majority of which are disk and memory-related.

If you get crashes that OCA is unable to diagnose or you suspect a memory problem then you should spend a few minutes with the Microsoft Windows Memory Diagnostic (WMD), a memory checking tool Microsoft recently released. The installer for WMD asks for a floppy disk or CD to which it saves the WMD program. When you boot a machine from the floppy or CD you created WMD runs and performs a thorough test of the computer's memory, reporting its progress and any problems to the screen. If you have memory errors WMD can save you the frustration endless of Windows crashes.

You can download the Windows Memory Diagnostic at http://www.microsoft.com/downloads/details.aspx?FamilyID=56D3C201-2C68-4DE8-9229-CA494362419C&displaylang=en

RESEARCHING UNDOCUMENTED INTERFACES

The DEP status feature I describe in the section on Process Explorer enhancements earlier in the newsletter relies on an undocumented function. I thought many of you would be interested in learning how I discovered, without access to Windows source code (Dave Solomon, my coauthor for Windows Internals, has access, but I don't), the function and its proper usage.

The first step in my analysis process was to hypothesize that a DEP status query for a process would route through the NtQueryInformationProcess API. Many Windows API functions that retrieve information about a process use the NtQueryInformationProcess interface to obtain the information. This function, which is prototyped in the Ntddk.h file of the Windows Driver Development Kit (DDK), is accessible from user-mode through the "native API" system call interface:

NTSYSAPI
NTSTATUS
NTAPI
NtQueryInformationProcess(
    IN HANDLE ProcessHandle,
    IN PROCESSINFOCLASS ProcessInformationClass,
    OUT PVOID ProcessInformation,
    IN ULONG ProcessInformationLength,
    OUT PULONG ReturnLength OPTIONAL
);

Its first two arguments are a handle to a process and a "process information class". The PROCESSINFOCLASS enumeration, the first few of definitions of which are shown below, is also included in NTDDK.H:

typedef enum _PROCESSINFOCLASS {
    ProcessBasicInformation,
    ProcessQuotaLimits,
    ProcessIoCounters,
    ProcessVmCounters,
    ProcessTimes,
//...

Since DEP was introduced in Windows XP SP2 I didn't expect the information class for DEP queries to be listed in the Windows XP or Windows Server 2003 versions of Ntddk.h, and a quick check confirmed its absence. I therefore had to investigate a disassembly of SP 2's Ntoskrnl.exe, the image where NtQueryInformationProcess is implemented, to see if I could determine the DEP query information class empirically.

A disassembler takes an executable image and lists the assembly language instructions that make up its code. Assembly language instructions map directly to the instructions executed by a processor. The disassembler that I use is IDA Pro from http://www.datarescue.com since it understands Microsoft's debug information files and will integrate the information into the assembly language output. In the disassembly I discovered the convoluted sequence of instructions at the start of NtQueryInformationProcess that take the process information class parameter and executes code specific to each class. Since I knew that the information class was new, I could skip over the execution of the classes for which I saw definitions in Ntddk's PROCESSINFOCLASS enumeration. This narrowed my investigation to the roughly 3 or 4 new classes introduced since Windows XP's release.

One of the classes, the one that corresponds to a ProcessInformationClass value of 0x22, took me through a code path into a function named MmGetExecuteOptions, the start of which is shown here:

PAGE:0054D7CC ; __stdcall MmGetExecuteOptions(x)
PAGE:0054D7CC _MmGetExecuteOptions@4 proc near ; CODE XREF:
NtQueryInformationPro0063ess(x,x,x,x,x)+251C p
PAGE:0054D7CC
PAGE:0054D7CC arg_4 = dword ptr 8
PAGE:0054D7CC
PAGE:0054D7CC mov edi, edi
PAGE:0054D7CE push ebp
PAGE:0054D7CF mov ebp, esp
PAGE:0054D7D1 mov eax, large fs:124h
PAGE:0054D7D7 mov eax, [eax+44h]
PAGE:0054D7DA mov cl, [eax+6Bh]
PAGE:0054D7DD mov eax, [ebp+arg_4]
PAGE:0054D7E0 and dword ptr [eax], 0
PAGE:0054D7E3 xor edx, edx
PAGE:0054D7E5 inc edx
PAGE:0054D7E6 test dl, cl
PAGE:0054D7E8 jz short loc_54D7EC
PAGE:0054D7EA mov [eax], edx
PAGE:0054D7EC
PAGE:0054D7EC loc_54D7EC: ; CODE XREF:
MmGetExecuteOptions(x)+1C j
PAGE:0054D7EC test cl, 2
PAGE:0054D7EF jz short loc_54D7F4
PAGE:0054D7F1 or dword ptr [eax], 2
PAGE:0054D7F4
PAGE:0054D7F4 loc_54D7F4: ; CODE XREF:
MmGetExecuteOptions(x)+23 j
PAGE:0054D7F4 test cl, 4
PAGE:0054D7F7 jz short loc_54D7FC
PAGE:0054D7F9 or dword ptr [eax], 4
PAGE:0054D7FC

IDA Pro showed me on the first line in the above output that the function accepts one argument, which I suspected to be a pointer to a variable that receives the DEP settings. I've spent enough time looking through disassemblies of the Windows kernel to recognize the instruction sequence mov eax, large fs:124h; mov eax,[eax+44h] as a read of the current thread _KTHREAD data structure in the processor control region (PCR) structure followed by a reference of the KPROCESS field at offset 0x44 in the _KTHREAD structure. The instructions following those read individual bits in the byte at offset 0x6B in the _KPROCESS structure.

Not knowing off hand what's at offset 0x6B in a _KPROCESS I launched Windbg in local-kernel debugging mode and executed the command dt _kprocess, which reported this:

+0x06b Flags : _KEXECUTE_OPTIONS

Looking at that structure with another dt command showed the bit definitions:

+0x000 ExecuteDisable : Pos 0, 1 Bit
+0x000 ExecuteEnable : Pos 1, 1 Bit
+0x000 DisableThunkEmulation : Pos 2, 1 Bit
+0x000 Permanent : Pos 3, 1 Bit
+0x000 ExecuteDispatchEnable : Pos 4, 1 Bit
+0x000 ImageDispatchEnable : Pos 5, 1 Bit
+0x000 Spare : Pos 6, 2 Bits

Sure enough, these bits relate to DEP and it appears that MmGetExecuteOptions copies them from that structure to the corresponding bits in the memory location passed as the ProcessInformation argument to NtQueryInformationProcess. I had therefore determined that I could query the DEP status of a process by calling NtQueryInformationProcess with a ProcessInformationClass of 0x22, the address of a DWORD (4-byte integer), and a length of 4. It appears that MmGetExecuteOptions returns the flags for the current process only and ignores the ProcessHandle parameter (Process Explorer queries the DEP status of other processes by having its helper driver switch into them via the KeAttachProcess API).

I was done except for a couple of subtle differences on the 64-bit version of Windows, since I make available a 64-bit version of Process Explorer. On 64-bit Windows MmGetExecuteOptions requires that ProcessHandle be -1 and it returns a STATUS_INVALID_PARAMETER error if the current process is a 64-bit process, since DEP is always on for 64-bit processes. I used Windbg to disassemble the 64-bit version of Ntoskrnl.exe, though since then have obtained the version of IDA Pro that supports AMD64 image disassembly.

INTERNALS TRAINING

WINDOWS CONNECTIONS IN SAN FRANCISCO

I'm delivering two sessions at the Windows Connections conference, which is run by Windows IT Pro Magazine and taking place April 17-20 in San Francisco. One is a general session called "Understanding and Fighting Malware: Viruses, Spyware, and Rootkits" where I describe how malware exploits vulnerabilities to propagate and bypass security measures, how they hide using sophisticated techniques called "rootkits" and how to detect them and clean them from your system.

The other session is "Troubleshooting Windows Memory Problems" where I show you how to answer the age old "what are the meaning of the values I see in Task Manager", "what's using my memory", and "how big should I make the paging file" questions.

Download the conference brochure and register at
http://www.devconnections.com/shows/win/default.asp?s=60#

HANDS-ON WINDOWS INTERNALS/SYSINTERNALS CLASSES BY MARK RUSSINOVICH

Spend 5 days with Mark Russinovich and David Solomon, authors of the new book Windows Internals 4th edition, learning advanced troubleshooting techniques while delving into the internals of the Windows NT/2000/XP/2003 operating system kernel. If you're an IT professional deploying and supporting Windows servers and workstations, you need to be able to dig beneath the surface when things go wrong. Having understanding of the internals of the Windows operating system and knowing how to use advanced troubleshooting tools will help you deal with such problems and understand system performance issues more effectively. Understanding the internals can help programmers to better take advantage of the Windows platform, as well as provide advanced debugging techniques. And because the course was developed with full access to the Windows kernel source code AND developers, you know you're getting the real story.

Upcoming dates include:

  • JUNE 6-10, ORLANDO, FLORIDA
  • JULY 11-15, MUNICH, GERMANY
  • SEPTEMBER 19-23, SAN FRANCISCO, CALIFORNIA
  • DECEMBER 5-9, AUSTIN, TEXAS

NOTE: This is a hands-on class--each attendee must bring their own laptop (configuration instructions will be sent ahead of time).

You'll gain an in-depth understanding of the kernel architecture of Windows NT/2000/XP/2003, including the internals of processes, thread scheduling, memory management, I/O, services, security, the registry, and the boot process. Also covered are advanced troubleshooting techniques such as malware disinfection, crash dump (blue screen) analysis, and getting past boot problems. You'll also learn advanced tips on using the key tools from www.sysinternals.com (such as Filemon, Regmon, & Process Explorer) to troubleshoot a range of system and application issues, such as slow computers, virus detection, DLL conflicts, permission problems, and registry issues. These tools are used on a daily basis by Microsoft Product Support and have been used effectively to solve a wide variety of desktop and server issues, so being familiar with their operation and application will assist you in dealing with different problems on Windows. Real world examples will be given that show successful application of these tools to solve real problems.

To register, visit http://www.sysinternals.com/troubleshoot.shtml

Thank you for reading the Sysinternals Newsletter.

Published Wednesday, January 05, 2005 4:36 PM by ottoh

[Newsletters Archive ^] [< Volume 6, Number 2] [Volume 7, Special Announcement >]