Freigeben über

  • Artikel

[Newsletter-Archiv ^] [< Band 2, Nummer 4] [Band 3, Nummer 1 >]

Systems Internals-Newsletter Band 2, Nummer 5

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

30. November 2000 – In dieser Ausgabe:

  1. LEITARTIKEL

  2. NEUIGKEITEN BEI 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, dritte Auflage
    • November- und Winter-Ausgaben des Windows 2000-Magazins
    • Sysinternals bei Microsoft
    • Sysinternals-Lizenzierung

  3. INTERNALS-INFORMATIONEN

    • NFI
    • Versteckte Win9x-Registrierungsschlüssel

  4. BALD VERFÜGBAR

    • Neue Whistler-Systemaufrufe

SPONSOR: WINTERNALS SOFTWARE

Der Sysinternals-Newsletter wird von Winternals Software gesponsert (im Web unter www.winternals.com). Winternals Software ist der führende Entwickler und Anbieter von erweiterten Systemtools für Windows NT/2K. Zu den Produkten von Winternals Software zählen FAT32 für Windows NT 4.0, NTFSDOS Professional Edition (ein NTFS-Treiber mit Lese-/Schreibzugriff für DOS) und Remote Recover.

Der in allen Versionen von Windows 9x und Windows NT/2000 enthaltene Befehl „netstat“ zeigt, welche TCP/IP-Ports auf Ihrem System geöffnet sind, aber nicht, von welchem Prozess ein Port geöffnet wurde. TCPView Pro, das neueste Überwachungstool von Winternals, verfügt nicht nur über ein mit „netstat“ vergleichbares Befehlszeilentool (Tcpvstat), das zeigt, von welchem Prozess die einzelnen Ports geöffnet wurden, sondern auch über eine grafische Benutzeroberfläche, auf der die gleichen Informationen sowie eine Echtzeitablaufverfolgung der TCP/IP-Aktivität angezeigt werden. Die Echtzeitablaufverfolgung zeigt die Anwendung, die einen Netzwerkzugriff vornimmt, die lokalen und Remote-IP-Adressen des Zugriffs mit optionaler DNS-Namensauflösung, die Art des Zugriffs, den Erfolg des Zugriffs und die Menge übertragener Daten. TCPView Pro ist für nur 69 US-Dollar erhältlich. Laden Sie die 14-tägige voll funktionsfähige Testversion von TCPView Pro noch heute auf www.winternals.com/products/monitoringtools/tcpviewpro.shtml herunter.

Guten Tag,

Willkommen beim Sysinternals-Newsletter. Der Newsletter hat aktuell 28.000 Abonnenten.

Einer der Vorteile der Umstellung von Windows NT auf Windows 2000 ist die deutlich verbesserte Zuverlässigkeit. Ich habe in mehreren Artikeln über die Gründe für die Verbesserungen geschrieben, und sie sind in erster Linie das Ergebnis eines Tools namens Driver Verifier (Treiberüberprüfung). Sie können den Verifier (geben Sie zum Starten dieses Tools im Dialogfeld „Ausführen“ des Startmenüs „verifier“ ein) konfigurieren, um die Ausführung bestimmter Gerätetreiber genau zu überwachen und nach Verstößen gegen eine von mehreren Treiberprogrammierungsregeln zu suchen. Der Verifier geht einen Schritt weiter als die passive Überwachung, verschärft jedoch auch potenzielle Fehlerbedingungen, z. B. durch die Zuweisung von Speicherblöcken für den Treiber, die sich über ungültige Bereiche erstrecken, und die Nullsetzung bestimmter Felder in Datenstrukturen, die an den Treiber übergeben werden. Wenn Sie es genau wissen möchten, können Sie den Verifier Bedingungen mit unzureichendem Arbeitsspeicher simulieren lassen.

Microsoft nutzt den Verifier über sein Treibersignierungsprogramm, das erfordert, dass jeder von Microsoft digital signierte Treiber strenge Treiberüberprüfungstests bestehen muss. Wenn ein Treiber installiert wird, überprüft der Hardware-Assistent, ob der Treiber signiert ist. Wenn dies nicht der Fall ist, werden Sie entweder gewarnt oder die Installation des Treibers schlägt fehl, je nachdem, welche Einstellungen Sie im Dialogfeld mit den Optionen für das Signieren von Treibern eingegeben haben (auf dieses Dialogfeld können Sie über die Seite „Hardware“ des Applets „System“ in der Systemsteuerung zugreifen).

Die Tatsache, dass die Standardrichtlinie für das Signieren von Treibern Endbenutzer*innen vor nicht signierten Treibern warnt, reicht aus, um die meisten Hardwareanbieter*innen dazu zu bringen, ihre Treiber stabil zu machen und signieren zu lassen. Gerätetreiber können sich jedoch unentdeckt von der Richtlinie für das Signieren von Treibern in Ihr System einschleichen. Nur Treiber, die mithilfe von INF-Dateien (Treiberinstallationsdateien, die mit der Erweiterung „.inf“ enden) installiert werden, werden auf Signaturen überprüft. Setupanwendungen können Treiber manuell installieren, indem sie die Setup-APIs direkt verwenden oder die Registrierungseinstellungen des Treibers manuell konfigurieren. Sysinternals-Anwendungen sind hervorragende Beispiele für Filemon, Regmon und andere Sysinternals-Tools, bei denen Treiberkomponenten manuell installiert werden, weshalb Sie nicht gewarnt werden, dass sie nicht von Microsoft signiert sind.

Zu Treibern, die im Allgemeinen nicht mit INF-Dateien installiert werden, zählen Virenscanner, Verschlüsselungssoftware und CD-ROM-Brennsoftware. Dies schließt jedoch nicht aus, dass hardwarebezogene Treiber durch die Kontrollen schlüpfen. Der Ctrl2cap-Treiber für Windows 2000 von Sysinternals (www.sysinternals.com/ctrl2cap.htm) ist ein Beispiel für einen hardwarebezogenen Treiber, der in einer Weise installiert wird, dass die Überprüfungen der Treibersignatur umgangen werden. Diese Lücke führt dazu, dass nicht überprüfte Treiber auf Ihrem System vorhanden sind, was die Systemstabilität beeinträchtigen kann (ich prüfe alle Sysinternals-Treiber mit den höchsten Einstellungen). Microsoft sollte die Signaturprüfung für alle Treiber erzwingen, nicht nur für diejenigen, die mit INF-Dateien installiert werden.

Warum ich darüber schimpfe? Meine CD-ROM-Brennsoftware, die die beliebteste Software dieses Typs auf dem Markt ist, hat einen Treiber, der reproduzierbare Abstürze meines Windows 2000 SP1-Systems verursacht. Wenn ich den Driver Verifier zum Überprüfen des Treibers konfiguriere, schließt das System nicht einmal die Startphase ab, bevor der Verifier den ersten Verstoß des Treibers erkennt und das System abstürzen lässt. Der Treiber wurde ohne INF-Datei installiert, sodass ich nicht gewarnt wurde, dass er nicht signiert war. Ich garantiere, dass es sich der*die Hersteller*in zweimal überlegen würde, bevor er*sie einen nicht signierten (und fehlerhaften) Treiber liefert, wenn die Richtlinie von Microsoft strenger wäre.

Bitte leiten Sie den Newsletter an alle Personen weiter, für die diese Informationen von Interesse sein könnten.

Vielen Dank!

– Mark

NEUIGKEITEN BEI SYSINTERNALS

PSLOGGEDON V1.2

Neben einer offensichtlichen Namensänderung von LoggedOn zu PsLoggedOn bietet dieses Befehlszeilentool, mit dem Sie die Benutzer*innen anzeigen können, die lokal und über Ressourcenfreigaben auf dem lokalen oder einem Remotesystem angemeldet sind, einige neue Features. Das erste neue Feature ist der Befehlszeilenschalter „-l“, der auf Benutzerfeedback zurückgeht. Viele Benutzer*innen verwenden PsLoggedOn, um festzustellen, ob ein Konto lokal bei ihren Servern angemeldet ist. Es kann z. B. Benutzer*innen geben, die über Dateifreigaben angemeldet sind, aber das ist nicht relevant für die Entscheidung, wann ein Konto aktualisiert oder der Server remote verwaltet werden kann.

Das zweite neue Feature von PsLoggedOn zeigt Ihnen nicht nur, wer angemeldet ist, sondern auch den Zeitpunkt der Anmeldung. Das Tool PsLoggedOn ruft die Anmeldezeiten für Anmeldungen über Ressourcenfreigaben kostenlos ab, wenn es eine Win32-API, NetSessionEnum, zum Aufzählen von Ressourcenfreigabeanmeldungen verwendet (der Net-Befehlszeilenbefehl verwendet ebenfalls NetSessionEnum, um Sitzungen aufzulisten). Es gibt jedoch keine Win32-API, die Ihnen mitteilt, wer lokal bei einem System angemeldet ist, geschweige denn, zu welchem Zeitpunkt die Anmeldung erfolgt ist.

Um zu ermitteln, wer lokal bei einem System angemeldet ist, zählt PsLoggedOn die Sicherheits-IDs (SIDs) auf, die sich unter dem Registrierungsschlüssel HKEY_USERS eines Computers befinden. Wenn sich Benutzer*innen lokal bei einem Computer anmelden, entweder über die Konsole oder über einen Dienst, wird ihr Profil in den Schlüssel HKEY_USERS geladen. Anwendungen können über den Schlüssel HKEY_CURRENT_USER auf die Registrierungseinstellungen ihres Profils zugreifen, da das System diesen Schlüssel als symbolische Verknüpfung zu ihrem jeweiligen Profil unter HKEY_USERS behandelt. So kann das Tool PsLoggedOn feststellen, wer lokal angemeldet ist, indem es die SIDs, die es im Schlüssel HKEY_USERS eines Computers findet, in den entsprechenden Benutzernamen übersetzt. PsLoggedOn verwendet RegConnectKey, um eine Verbindung mit der Registrierung eines Remotecomputers herzustellen, wenn Sie das Tool anweisen, die bei einem Remotesystem angemeldeten Benutzer*innen aufzulisten.

Mit einem ähnlichen Trick können Sie herausfinden, wann sich Benutzer*innen angemeldet haben. Wenn der WinLogon-Prozess das Profil von Benutzer*innen nach deren Anmeldung in HKEY_USERS lädt, erstellt WinLogon einen flüchtigen (nicht im Profil auf dem Datenträger gespeicherten) Unterschlüssel namens „Volatile Environment“ in ihrem Profil. Die Registrierung speichert die Zeitstempel der letzten Änderung für Registrierungsschlüssel, und da das System die Unterschlüssel „Volatile Environment“ nach ihrer Erstellung nicht ändert, kann PsLoggedOn ermitteln, wann sich Benutzer*innen angemeldet haben, indem es den Zeitstempel des Unterschlüssels „Volatile Environment“ abruft.

Sie können PsLoggedOn v1.2 mit dem vollständigen Quellcode unter der folgenden Adresse herunterladen:
www.sysinternals.com/psloggedon.htm.

PSSHUTDOWN V1.0

Wenn Sie jemals ein lokales oder Windows NT-/2000-Remotesystem herunterfahren oder neu starten mussten, sollten Sie PsShutdown herunterladen. PsShutdown ist ein Klon des Windows NT/2000 Resource Kit-Tools „Herunterfahren“. Das Tool verwendet die gleichen Befehlszeilenargumente, mit denen Sie eine Verzögerung vor dem Herunterfahren, ob ein Neustart durchgeführt werden soll, eine optionale Meldung, die für alle derzeit beim System angemeldeten Benutzer*innen angezeigt wird, und den Namen des Computers, der heruntergefahren oder neu gestartet werden soll, angeben können.

Sie können PsShutdown v1.0 unter www.sysinternals.com/psshutdn.htm herunterladen.

PSTOOLS V1.1

Wahrscheinlich haben Sie die zunehmende Anzahl von Tools bei Sysinternals bemerkt, deren Namen mit dem Präfix „Ps“ beginnen. Das erste dieser Tools war PsList, ein Befehlszeilentool, das Informationen zu den aktiven Prozessen auf dem lokalen oder einem Windows NT-/2000-Remotesystem auflistet. Ich habe dem Tool den Namen PsList gegeben, weil das standardmäßige UNIX-Befehlszeilentool für Prozessinformationen „ps“ heißt. Das nächste Tool, das zum Abrufen des Präfixes dient, war PsKill, ein Befehlszeilenprogramm, mit dem Sie Prozesse beenden können, die auf lokalen oder Windows NT-/2000-Remotesystemen ausgeführt werden. PsKill habe ich das Präfix „Ps“ hinzugefügt, weil es so eine perfekte Ergänzung für PsList ist.

Im Laufe der Zeit habe ich andere Tools entwickelt, die wichtige Gemeinsamkeiten mit PsList und PsKill aufweisen: Sie sind befehlszeilenbasiert und funktionieren auf dem lokalen oder einem Windows NT-/2000-Remotesystem. Mit ElogList können Sie beispielsweise den Inhalt der Ereignisprotokolle eines Systems sichern, und GetSid zeigt Ihnen die SID eines Computers oder eines bestimmten Kontos. Vor Kurzem habe ich beschlossen, all diese Tools in einem Bündel zusammenzufassen, indem ich ihnen das Präfix „Ps“ hinzufügte und den Download als ein einzelnes Paket namens PsTools ermöglichte.

Das PsTools-Paket, das PsList, PsKill sowie die umbenannten Tools PsLogList und PsGetSid enthält, besteht aus insgesamt sieben Tools. Wenn Sie ein Sysinternals-Tool mit dem Präfix „Ps“ sehen, wissen Sie automatisch, dass es sich um ein Befehlszeilentool handelt, das sowohl lokal als auch remote funktioniert.

Sie können PsTools v1.1 unter www.sysinternals.com/pstools.htm herunterladen.

BGINFO V1.1

Aufgrund des umfangreichen Feedbacks von Benutzer*innen hat Bryce BgInfo aktualisiert, ein Hilfsprogramm, das einen Desktophintergrund festlegt, auf dem anpassbare Informationen zur Konfiguration eines Systems angezeigt werden. Standardmäßig zählt BgInfo zehn Sekunden herunter, bevor die im Dialogfeld angegebenen Einstellungen angewendet werden. Mit der neuen Befehlszeilenoption /timer können Sie den Countdown jedoch ändern oder ganz entfernen. Dadurch ist es einfacher, BgInfo in ein Anmeldeskript oder als Verknüpfung in den Ordner „Start“ eines Profils einzuschließen.

Version 1.1 enthält weitere neue Features, z. B. die Möglichkeit, beliebigen von Ihnen festgelegten Text und weitere vordefinierte Informationskategorien anzuzeigen. Die Desktop-Bitmap, die BgInfo v1.1 erstellt, ist im Allgemeinen auch kleiner, sodass der Arbeitsspeicherbedarf des BgInfo-Desktops minimiert wird.

Sie können BgInfo v1.1 unter www.sysinternals.com/bginfo.htm herunterladen.

TOKENMON V1.0

Tokenmon ist die neueste Ergänzung der vielfältigen Suite von Überwachungstools, die Sie von Sysinternals herunterladen können. Tokenmon, das dieselbe Benutzeroberfläche wie verwandte Tools wie Regmon und Filemon verwendet, überwacht wichtige sicherheitsbezogene Aktivitäten auf einem Windows NT-/2000-System. Was sind „wichtige“ sicherheitsbezogene Aktivitäten? Im Mittelpunkt der Sicherheit von Windows NT/2000 steht das Tokenobjekt, eine Datenstruktur, die eine Konto-SID, Gruppen-SIDs und Rechte enthält. Wenn ein Prozess versucht, auf ein gesichertes Objekt zuzugreifen, verwendet der Sicherheitsreferenzmonitor die SIDs in seinem Token als Teil der Zugriffsüberprüfung. Wenn ein Prozess versucht, einen eingeschränkten Vorgang auszuführen, z. B. das System neu zu starten, überprüft das System die entsprechenden Rechte im Prozesstoken.

Eines der leistungsstarken (und patentierten) Features des Windows NT-/2000-Sicherheitsmodells ist der Identitätswechsel. Mit dem Identitätswechsel kann ein Thread seine prozessbasierte Identität vorübergehend außer Kraft setzen und mithilfe eines Identitätswechseltokens eine alternative Identität annehmen. Serveranwendungen nutzen den Identitätswechsel, wenn sie im Namen eines Clients auf Ressourcen zugreifen und für die Dauer des Zugriffs die Identität des Clients annehmen.

Tokenmon installiert Systemaufrufhooks auf die gleiche Weise wie Regmon für Registrierungs-APIs vorgeht, um das Erstellen und Löschen von Token, das Aktivieren und Deaktivieren von Rechten und Identitätswechsel zu überwachen. Tokenmon verwendet auch vom NT-/2000-Kernel bereitgestellte Prozesserstellungshooks zum Überwachen der Erstellung und Löschung von Prozessen und anderen APIs, um zu bestimmen, wann sich Benutzer*innen an- und abmelden.

Der vollständige Quellcode für Tokenmon wurde bereitgestellt, und es lohnt sich, einige der interessanten Techniken zu besprechen, die der Code veranschaulicht. Tokenmon erkennt ein Anmeldeereignis, indem es einen Hook für den NtCreateToken-Systemaufruf aufruft, der von Anmeldebrokern wie WinLogon verwendet wird, um ein anfängliches Token für den ersten Prozess einer neuen Anmeldesitzung zu erstellen. Prozesse, die vom ersten Prozess erstellt werden, erben eine Kopie des ersten Tokens. Zum Erkennen von Abmeldungen registriert Tokenmon sich für die Abmeldungsbenachrichtigung über die Kernelmodusfunktion SeRegisterLogonSessionTerminatedRoutine, eine API für als Netzwerkredirector bezeichnete Dateisystemtreiber, die Anmeldesitzungsdaten zwischenspeichern und bei der Abmeldung von Benutzer*innen bereinigen. Netzwerkredirector implementieren die Clientseite von Client-/Serververbindungen für die Dateifreigabe.

Ein weiteres interessantes Implementierungsdetail von Tokenmon ist die Art und Weise, wie Tokenmon die überwachten APIs per Hook aufruft. Einige der APIs, die Tokenmon per Hook aufruft, werden nicht zur Verwendung durch Gerätetreiber exportiert, sondern in die Benutzermodusbibliothek NTDLL.DLL exportiert, damit sie von Anwendungen verwendet werden können, die die Win32-Entsprechungen nutzen. Alle Registrierungs-APIs, die Regmon per Hook aufruft, werden im Kernelmodus exportiert, sodass der Regmon-Gerätetreiber die Systemaufrufnummern abrufen und die Systemaufruftabelle entsprechend per Hook aufrufen kann. Für APIs, die nicht zur Verwendung durch Treiber exportiert werden, muss die grafische Benutzeroberfläche von Tokenmon die Aufrufnummern mithilfe der Exporte in NTDLL.DLL abrufen und dann die Nummern an den Treiber übergeben, damit dieser die Systemaufruftabelle per Hook aufrufen kann. Daher veranschaulicht Tokenmon, wie Systemaufrufe, die nicht im Kernelmodus exportiert werden, per Hook aufgerufen werden.

Sie können Tokenmon v1.0 mit dem vollständigen Quellcode unter www.sysinternals.com/tokenmon.htm herunterladen.

FILEMON V4.32

Dieses aktuelle Filemon-Update führt eine intuitivere und vollständigere Filterung, die Anzeige vollständiger UNC-Pfadnamen für den Zugriff auf Windows 9x-/Me-Netzwerkdateien und die Anzeige von NTFS-Metadatendateinamen ein.

In früheren Versionen von Filemon mussten Sie Filter mit obligatorischen Platzhaltern eingeben. Wenn Sie z. B. Zugriffe auf das Verzeichnis „Temp“ auf Laufwerk C: überwachen wollten, mussten Sie einen Filter wie den folgenden eingeben: „c:\temp\*“. Bei der neuen Filtersyntax sind Platzhalter optional. Der Beispielfilter würde funktionieren, „c:\temp“ hätte jedoch den gleichen Effekt. Darüber hinaus wendet Filemon die von Ihnen eingegebenen Filter jetzt auf alle Felder in der Anzeige an, einschließlich der Spalten „Prozessname“, „Anforderungstyp“, „Pfad“ und „Andere“. Dank dieser Flexibilität können Sie bestimmte Anforderungstypen oder Anforderungen mit spezifischen Daten in der Spalte „Andere“ überwachen, was bisher nicht möglich war.

Benutzer*innen, die Filemon auf Windows 9x-/Me-Systemen verwenden, sehen nun Filemon-Anzeigepfadnamen mit vollständiger UNC-Syntax, wenn sie auf Remoteressourcen zugreifen. Zuvor zeigte Filemon den Server- oder Freigabenamen für solche Zugriffe nicht an, was zu unvollständigen Pfadnamen führte.

Wenn Sie Filemon unter Windows NT/2000 verwendet haben, haben Sie zweifellos für viele Zugriffe den Text „DASD“ in der Spalte „Pfad“ gesehen. DASD ist die Abkürzung für Direct Access Storage Device (Direktzugriffsspeichergerät). Diesen Begriff verwendet Microsoft für Zugriffe auf ein Volume, die Dateisystemstrukturen umgehen. Für die meisten Aktivitäten auf NTFS-Volumes gehört DASD nun der Vergangenheit an. Stattdessen werden die Namen der NTFS-Metadatendateien angezeigt, die gelesen und geschrieben werden. Zuvor hätte die Aktualisierung eines MFT-Datensatzes beispielsweise zu einer Ausgabezeile mit dem Text „DASD“ geführt. Jetzt wird sie jedoch als Zugriff auf „$Mft“ angezeigt, den internen Metadatendateinamen der MFT.

Warum hat Filemon zuvor keine Metadatendateinamen angezeigt, und wie ruft das Tool diese Namen jetzt ab? Die Dateiobjekte, die NTFS-Metadatendateien darstellen, speichern keinen Dateinamen, sodass Filemon den Namen nicht aus dem Dateiobjekt extrahieren kann. Die alternative Methode, die Filemon zum Abrufen des Dateinamens verwendet – das Abfragen des Dateisystemtreibers –, funktioniert auch für NTFS-Metadatendateien nicht. Obwohl NTFS mit den Namen der Metadatendateien antwortet, verursacht NTFS unter NT 4 zufällige Abstürze, und NTFS unter Win2k bleibt beim Reagieren auf solche Abfragen gelegentlich hängen.

Filemon muss daher auf einen Trick zurückgreifen, um die Metadatendateinamen abzurufen. Wenn das Tool eine Anforderung erkennt, die an ein Dateiobjekt auf einem NTFS-Volume ohne Namen gerichtet ist, sendet es eine Abfrage für den Index der Datei an NTFS. Dies ist derselbe Index, den die Win32-Funktion GetFileInformationByHandle zurückgibt, und für Dateien auf NTFS-Volumes handelt es sich um den MFT-Index der Datei. Die ersten 16 Einträge in der MFT sind für bestimmte Metadatendateien reserviert, sodass Filemon bei einem Index in diesem Bereich einfach in seiner eigenen Tabelle nach dem Namen der Metadatendatei sucht.

Leider wird DASD weiterhin für Verzeichnismetadaten- und FAT-Zugriffe (File Allocation Table, Dateizuordnungstabelle) auf FAT-Volumes angezeigt, da FAT keine Namen für Verzeichnismetadatendateien oder FAT speichert. Sie werden überrascht sein, wie oft auf die NTFS-Protokolldatei ($LogFile) zugegriffen wird. Übrigens speichert NTFS unter Whistler die Namen für Metadatendateien, sodass der Trick dort nicht nötig ist.

Die letzte Filemon-Erweiterung ermöglicht Filemon das Anzeigen von Zeitstempeln für die Tageszeit mit Millisekundenauflösung. Diese Unterstützung erforderte aufgrund von Fehlern in einer Zeitsteuerungsfunktion im Windows 9x-/Me-Kernel hässliche Hacks im Filemon-Treiber für Windows 9x/Me. Weitere Informationen finden Sie im Quellcode.

Sie können Filemon v4.32 mit dem Quellcode unter www.sysinternals.com/filemon.htm herunterladen.

REGMON V4.32

Die Änderungen bei Regmon sind nicht so wesentlich wie die von Filemon. Regmon unterstützt jetzt jedoch die gleiche intuitivere Filtersyntax wie Filemon und wendet die Filter wie Filemon auf alle Felder an. Das Tool kann ebenfalls Zeitstempel mit Millisekundenauflösung anzeigen.

Diejenigen von Ihnen, die schon begonnen haben, Whistler (den Nachfolger von Windows 2000) Beta 1 auszuprobieren, haben möglicherweise bemerkt, dass frühere Versionen von Regmon beim Starten zu einem Absturz von Whistler führen. Dies liegt daran, dass Microsoft die Systemaufruftabelle, die Regmon zum Einfügen seiner Hooks ändert, im schreibgeschützten Speicher platziert hat. Regmon v4.32 umgeht dieses Problem mit einer Technik, für die ich auf Anfrage von Microsoft keinen Quellcode bereitgestellt habe, da die Technik im endgültigen Release von Whistler möglicherweise nicht funktioniert und Microsoft noch nach Möglichkeiten sucht, das Hooking von Systemaufrufen zu unterstützen. Windows NT wurde nicht zur Unterstützung des Hookings von Systemaufrufen entwickelt. Dies ist eine Funktion, die wir erstmals im ersten Release von Regmon Mitte 1996 eingeführt haben.

Hier ein nicht dokumentierter Tipp für Filemon/Regmon: Ich erhalte häufig E-Mails, in denen ich gefragt werde, wie Regmon oder Filemon unter Windows NT/2000 mit einem Nicht-Administratorkonto ausgeführt werden können. Es gibt viele Fälle, in denen eine bestimmte Anwendung ordnungsgemäß funktioniert, wenn sie unter dem Administratorkonto ausgeführt wird, aber nicht bei der Ausführung unter einem nicht privilegierten Konto. In diesen Fällen wären Regmon und Filemon nützlich, um zu ermitteln, warum die Ausführung der Anwendung fehlschlägt (in der Regel hängt das Problem mit den Sicherheitseinstellungen für eine Datei oder einen Registrierungsschlüssel zusammen). Die Ausführung von Regmon und Filemon unter einem nicht privilegierten Konto schlägt jedoch fehl, da sowohl Filemon als auch Regmon Gerätetreiber installieren, wozu Administratorrechte erforderlich sind.

Es gibt aber einen Trick, mit dem Sie dies umgehen können: Wenn Sie sich als Administrator*in anmelden und Filemon oder Regmon starten, können Sie die Tools anschließend mit nicht privilegierten Konten ausführen. Dies liegt daran, dass Filemon und Regmon bei der ersten Ausführung einen Treiber installieren und bei den folgenden Ausführungen auf den bereits geladenen Treiber zugreifen. Da ich keine Sicherheit im Treiber implementiere, können nicht privilegierte Benutzer*innen die Tools ausführen, nachdem der Treiber geladen wurde. Stellt dies ein Sicherheitsproblem dar? Ja. Da Filemon und Regmon aber als Problembehandlungstools vorgesehen sind, betrachten die Benutzer*innen, die sich nach der Ausführung der Hilfsprogramme unter nicht privilegierten Konten erkundigen, und ich dies als Feature.

Sie können Regmon v4.32 mit dem vollständigen Quellcode unter www.sysinternals.com/regmon.htm herunterladen.

DEBUGVIEW V4.02

Eine der Anwendungen, für die ich das meiste Benutzerfeedback erhalten habe, ist überraschenderweise DebugView. Diese neue Version verfügt über einige wichtige Erweiterungen, die viele der Feature- und Funktionsanforderungen erfüllen, die ich erhalten habe, und DebugView leistungsfähiger als je zuvor machen.

Am offensichtlichsten ist, dass DebugView jetzt bis zu fünf verschiedene Hervorhebungsfilter unterstützt, von denen jeder über eigene anpassbare Farben verfügt. Auf diese Weise können Sie gleichzeitig verschiedene Schlüsselwörter in Ihrer Debugausgabe verwenden und diese leicht unterscheiden. Darüber hinaus implementiert DebugView die gleiche neue Filtersyntax wie Filemon und Regmon, sodass die Platzhalter für den Abgleich von Teilzeichenfolgen optional sind.

Eine Beschwerde, die ich zu früheren Versionen von DebugView erhalten habe, ist, dass Sie, selbst wenn Sie nur die Win32-Debugausgabe erfassen wollten, zum Ausführen von DebugView Administratorrechte benötigten, da DebugView ohne Installation des Gerätetreibers nicht ausgeführt werden konnte. Diese neue Version kann auch unter Konten ausgeführt werden, die nicht über besondere Rechte verfügen. Wenn das Tool den Treiber nicht installieren oder nicht auf ihn zugreifen kann, deaktiviert es einfach die im Kernelmodus erfassten Menüelemente.

Zwei Features, die das Starten der automatischen Erfassung der Ausgabe durch DebugView bei der Anmeldung erleichtern, sind die Option zum Minimieren im Infobereich und die Unterstützung für Befehlszeilenschalter. Mithilfe von Befehlszeilenschaltern können Sie DebugView im Infobereich starten und die erfasste Ausgabe in einer Datei protokollieren, und nachdem Sie DebugView gestartet haben, können Sie das Verhalten der Schaltfläche „Minimieren“ mithilfe einer Menüoption zwischen normalem Minimieren und Minimieren im Infobereich umschalten.

Für Benutzer*innen, die DebugView in Remotesitzungen in Windows 2000-Terminaldiensten ausführen, erfasst DebugView jetzt die Win32-Ausgabe, die von Anwendungen generiert wird, die in der Remotesitzung ausgeführt werden, und optional aus der Konsolensitzung. Dies ist nützlich für das Remotedebuggen von COM-Servern und Win32-Diensten, da diese Programme in der Konsolensitzung ausgeführt werden.

DebugView funktioniert jetzt auch unter Whistler Beta 1, mit Unterstützung für die Erfassung der Ausgabe der verschiedenen neuen Whistler-Varianten der DbgPrint-Funktion im Kernelmodus.

Sie können DebugView v4.02 unter www.sysinternals.com/dbgview.htm herunterladen.

INSIDE WINDOWS 2000, DRITTE AUFLAGE

Das offizielle Buch zu den Interna von Windows 2000 ist jetzt verfügbar! Diese Ausgabe, die von David Solomon (www.solsem.com) und Mark Russinovich gemeinsam verfasst wurde, ist um mehr als 40 % umfangreicher als die vorherige und behandelt nun auch Netzwerke, Plug & Play, Energieverwaltung, Dienste, die Registrierung, die Windows-Verwaltungsinstrumentation (Windows Management Instrumentation, WMI), Start und Herunterfahren sowie Speicher. Es enthält auch eine CD mit mehreren leistungsstarken Tools zum Untersuchen der Windows 2000 Internals, die nirgendwo sonst verfügbar sind.

Eines der Tools, die ich speziell für das Buch entwickelt habe, ist LiveKd – ein Programm, mit dem Sie beide Microsoft-Kerneldebugger, i386kd und WinDbg, auf einem Livesystem ausführen können, als würden Sie sich ein Absturzabbild ansehen. Viele der im Buch vorgestellten Experimente funktionieren auf einem Livesystem, wenn sie mit LiveKd ausgeführt werden. LiveKd installiert einen Dateisystemfilter-Treiber, der den physischen Speicher des Computers als Absturzabbilddatei für den Microsoft-Debugger bereitstellt. LiveKd erstellt eine Pseudo-Speicherabbilddatei mit der Länge 0, und wenn der Debugger aus der Datei liest, gibt LiveKd Daten aus dem physischen Speicher zurück. Sehen Sie sich im Buch die Seite zu Fehlern und Updates für einen LiveKd-Patch an, der eine Inkompatibilität zwischen LiveKd v1.0 und mehreren Echtzeit-Virenscannern korrigiert.

Werfen Sie einen Blick auf das Inhaltsverzeichnis des Buchs, und bestellen Sie es gleich jetzt über www.sysinternals.com/insidew2k.htm.

NOVEMBER- UND WINTER-AUSGABEN DES WINDOWS 2000-MAGAZINS

Möchten Sie wissen, was genau sich zwischen NTFS v4 und NTFS v5 geändert hat? Wenn ja, sollten Sie meine zweiteilige Serie in den November- und Winter-Ausgaben des Windows 2000-Magazins lesen. Teil 1 beschreibt Analysepunkte, Verzeichnisverbindungen, Volumebereitstellungspunkte, Kontingentunterstützung und konsolidierte Sicherheitseinstellungen. Teil 2 schließt mit einer genauen Betrachtung der Verschlüsselung, von Streams, der Überwachung verteilter Links und dem Änderungsjournal ab. Beide Artikel ermöglichen Ihnen ein tieferes Verständnis der Änderungen auf dem Datenträger und des internen Verhaltens der neuen Features als andere Artikel zu diesem Thema.

Ein Punkt, den ich in den Artikeln nicht erwähne, ist, dass NTFS für Windows NT 4 nicht wirklich versionsspezifisch ist.

Links zu all unseren Publikationen finden Sie unter www.sysinternals.com/publ.htm.

SYSINTERNALS BEI WWW.MICROSOFT.COM

Sysinternals wurde seit dem letzten Newsletter in mehreren neuen Microsoft Knowledge Base-Artikeln (KB) erwähnt, und ich habe auch einige ältere KB-Artikel aufgestöbert, die sich auf Sysinternals beziehen.

  • Q260513 PRB: Fehler beim Installieren von Visual Studio-Produkten
    http://support.microsoft.com/support/kb/articles/Q260/5/13.ASP
    In diesem Artikel wird Leser*innen empfohlen, Filemon und Regmon zum Behandeln von Problemen bei der Installation von Microsoft Visual Studio zu verwenden.

  • Q202258 XADM: Das System kann den angegebenen Pfad nicht finden – ID-Nr.: 0cx002003
    http://support.microsoft.com/support/kb/articles/Q202/2/58.ASP
    Microsoft führt Benutzer*innen durch die Schritte zum Behandeln von Problemen beim Exchange 5.0 Service Pack-Upgrade mithilfe von Filemon, einschließlich einer Filemon-Beispielausgabezeile und Empfehlungen zum Einrichten von Filtern.

  • Q269383 PRB: Meldung „Fehler beim Zugriff auf die Systemregistrierung“ beim Anzeigen von VB-/VBA-Verweisen
    http://support.microsoft.com/support/kb/articles/Q269/3/83.ASP
    Regmon ruft die Empfehlung aus diesem Artikel ab, in dem erläutert wird, wie das Tool verwendet werden kann, um zu ermitteln, warum das Dialogfeld „Verweise“ in der integrierten Visual Basic-Entwicklungsumgebung (Integrated Development Environment, IDE) eine Meldung anzeigt, wenn es aufgrund eines Fehlers in Seagate Crystal Reports, durch den falsche Berechtigungen auf mehrere Schlüssel angewendet werden, nicht auf einen Registrierungsschlüssel zugreifen kann.

  • Q269251 BUG: Die Automatisierung von Windows Installer kann beim Aufzählen von Produkten hängen bleiben.
    http://support.microsoft.com/support/kb/articles/q269/2/51.asp
    Regmon wird auch in diesem Fall hervorgehoben, in dem es verwendet wird, um einen Windows Installer-Automatisierungsfehler aufzudecken.

  • Q276525: Ihr Computer reagiert möglicherweise nicht mehr, wenn Sie geöffnete Handles überwachen.
    http://support.microsoft.com/support/kb/articles/Q276/5/25.asp
    NtHandle ist für die Aufdeckung eines Fehlers in Windows NT 4 SP6a verantwortlich, bei dem der Kernel bei Verwendung von NtHandle unter bestimmten Bedingungen hängen bleibt. Microsoft hat mit mir zusammengearbeitet, um das Problem zu beheben, und einen Hotfix veröffentlicht. Wenn Ihr NT 4-System bei der Verwendung von NtHandle nicht mehr reagiert, sollten Sie dem Link zu diesem Artikel folgen.

  • Q160660: „Ntregmon.exe“ verursacht beim neuen Service Pack einen Fehler vom Typ „STOP 0x0000001E“.
    http://support.microsoft.com/support/kb/articles/Q160/6/60.asp
    Die folgende Information ist zwar nicht neu, aber noch immer relevant. Die erste Version von Regmon verwendete zum Patchen der Systemdiensttabelle hartcodierte Systemaufrufnummern, um Registrierungs-APIs per Hook aufzurufen. Da sich die Systemaufrufnummern manchmal zwischen Service Packs ändern, ist diese Technik ziemlich fragil, und ich hatte im Vorgriff darauf nicht defensiv codiert (gegen den Rat von Andrew Schulman, der befürchtete, dass Regmon nicht funktionieren würde). In SP3 wurden dann tatsächlich einige neue Systemaufrufe eingeführt, und Regmon würde einen Absturz des Systems verursachen, wenn es falsche Systemaufrufe per Hook aufruft. Das hat sicherlich einige Leute verärgert hat, doch ich wurde mit einem eigenen KB-Artikel belohnt.

SYSINTERNALS-LIZENZIERUNG

Obwohl die Software, die Sie von Sysinternals herunterladen, Freeware ist, was bedeutet, dass Sie sie ohne Gebühr verwenden können, ist es Ihnen nicht gestattet, sie weiterzuverbreiten oder Produkte, die Sie vertreiben, vom Sysinternals-Quellcode abzuleiten. Wenn Sie z. B. in einem Unternehmen arbeiten, in dem mehrere Benutzer*innen bestimmte Sysinternals-Tools nützlich finden, dürfen Sie die Tools nicht auf einer internen Freigabe oder Website bereitstellen. Platzieren Sie stattdessen auf Ihrer Website Links zur Startseite der jeweiligen Tools auf Sysinternals. Dadurch können Sie auch sicherstellen, dass Ihre Kolleg*innen immer die aktuellen Versionen herunterladen.

Wenn Sie Sysinternals-Tools intern mit einem kommerziellen Produkt oder auf einer Shareware-CD verteilen oder ein kommerzielles Produkt oder ein verteilbares Programm basierend auf dem Quellcode von Sysinternals erstellen möchten, senden Sie eine E-Mail, in der Sie die Details des gewünschten Verwendungszwecks erläutern, an licensing@....

INTERNALS-INFORMATIONEN

NFI

In einem der letzten Newsletter enthüllte ich die Existenz des DiskEdit-Tools, das Microsoft versehentlich auf der NT 4 SP4-CD ausgeliefert hat. DiskEdit ist ein sehr leistungsstarker, aber eigenartiger Dateisystemstruktur-Viewer, mit dem Sie NTFS- und FAT-Datenstrukturen auf dem Datenträger untersuchen können (obwohl hierbei insbesondere die NTFS-Unterstützung von Interesse ist). Wenn Sie die NT 4 SP 4-CD verpasst haben und NTFS-Strukturen auf Datenträgern erkunden möchten, müssen Sie trotzdem nicht vollkommen im Dunkeln tappen. Microsoft hat ein kostenloses Tool namens NFI (NTFS-Informationen) veröffentlicht, das die internen Strukturen von NTFS-Volumes versteht und sichern kann. Die Ausgabe des Tools ist zwar bei Weitem nicht so detailliert wie die von DiskEdit, aber sie ist interessant und aufschlussreich.

Sie können NFI als Teil der OEM-Supporttools unter http://support.microsoft.com/support/kb/articles/q253/0/66.asp. herunterladen. Wenn Sie NFI mit einem Dateinamen ausführen, wird der NTFS-MFT-Datensatz für diese Datei gesichert. Das folgende Beispiel zeigt, wie NFI den MFT-Datensatz für die Metadatendatei $Quota ausgibt, eine Datei, die nur vorhanden ist, wenn die Kontingentverwaltung für ein Volume aktiviert ist:

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

Die Ausgabe zeigt, dass die Datei den 24. Eintrag in der MFT belegt (Dateiindex 24) und dass sie vier Attribute enthält, einschließlich Standardinformationen, Dateiname und zwei Einträgen für den Indexstamm (der Index ist im Wesentlichen eine sortierte Liste von Einträgen, wie z. B. ein Verzeichnis). In meiner aktuellen Serie im Windows 2000-Magazin zu NTFS v5 beschreibe ich, wie NTFS die $Quota-Indizes verwendet.

Um alle Dateien auf einem Volume zu sichern, geben Sie den Laufwerkbuchstaben in der Befehlszeile von NFI ohne Dateinamen an, z. B. nfi c:. Es wird eine Liste mit jedem MFT-Eintrag angezeigt, einschließlich aller Metadatendateien.

NFI verfügt über einige andere besondere Funktionen, z. B. die Fähigkeit, eine Sektornummer in die Datei zu übersetzen, in der sich diese befindet. Möchten Sie wissen, in welchem Dateisektor 2345 sich auf dem Laufwerk C: befindet? Verwenden Sie den Befehl nfi c: 2345. Beachten Sie, dass dieser Vorgang auf Software-RAID-Volumes wie Volumesätzen und Stripesets fehlschlägt. NFI funktioniert sowohl unter NT 4 als auch unter Windows 2000.

VERSTECKTE WIN9X-REGISTRIERUNGSSCHLÜSSEL

Vor zwei Ausgaben schrieb ich, dass ich „versteckte bzw. ausgeblendete Win9x-Registrierungsschlüssel“ im folgenden Newsletter behandeln würde, und einige von Ihnen erinnerten mich daran, dass ich dies vergessen hatte. In diesem Monat werde ich also über versteckte Registrierungsschlüssel in Windows 9x schreiben.

Vor einigen Jahren habe ich eine Möglichkeit entdeckt, versteckte Registrierungsschlüssel in Windows NT zu erstellen. Mit „versteckt“ meine ich, dass Sie mit Regmon zwar die Schlüssel sehen können, auf die die Anwendung zugreift, von denen sie erstellt wurden, dass Sie aber weder ein Win32-Programm zum Anzeigen der Werte des Schlüssels schreiben noch die Schlüssel mit den Registrierungs-Editoren Regedit oder Regedt32 anzeigen können. Versteckte Schlüssel sind nützlich zum Speichern von Daten, die nicht von Endbenutzer*innen geändert werden sollen, z. B. das Ablaufdatum eines Testprodukts.

Auf den Trick, wie ein versteckter Registrierungsschlüssel erstellt werden kann, kam ich durch die Erkenntnis, dass die native NT-API, also die Systemaufrufschnittstelle, auf der die Win32-API basiert, die Angabe von Registrierungsschlüsseln als gezählte Unicode-Zeichenfolgen erfordert. Eine gezählte Unicode-Zeichenfolge ist eine Zeichenfolge, deren Länge durch ein Längenfeld angegeben wird, nicht durch das Vorhandensein eines NULL-Abschlusszeichens. Mit der nativen API können Sie daher Registrierungsschlüssel erstellen, die ein NULL-Zeichen wie "test\0test" enthalten. Da die Registrierungsschlüssel-API der Win32-API auf Zeichenfolgen mit dem NULL-Abschlusszeichen basiert, ist es nicht möglich, einen Registrierungsschlüssel, der ein NULL-Abschlusszeichen enthält, mithilfe der Win32-API zu öffnen. Wenn Sie versucht haben, den Schlüsselnamen aus dem obigen Beispiel an RegOpenKey oder RegCreateKey zu übergeben, wurde dieser als "test" behandelt, und die Zeichenfolge wurde am NULL-Zeichen abgeschnitten. Da alle vorhandenen Registrierungs-Editoren (einschließlich der mit Windows NT und Windows 2000 gebündelten Editoren) die Win32-API verwenden, erstellt eine Anwendung, die Namen mit eingebettetem NULL-Zeichen mithilfe der nativen API erstellt, effektiv versteckte Schlüssel.

Diese Methode funktioniert unter Windows NT, aber was ist mit Windows 9x? Ich dachte nicht, dass es eine Möglichkeit gibt, versteckte Registrierungsschlüssel unter Windows 9x zu erstellen, bis mir jemand eine E-Mail mit einer Regmon-Protokolldatei schickte, die zeigt, dass Internet Explorer (IE) auf Schlüssel zugreift, die nicht in Regedit angezeigt werden. Sie können sich dies selbst ansehen, indem Sie Regmon starten und den folgenden Einschlussfilter festlegen: „policydata“. Starten Sie dann IE (dies funktioniert für alle Versionen von IE 4 und IE 5), und besuchen Sie eine Website. Falls in Regmon keine Ausgabe angezeigt wird, wechseln Sie in IE zum Dialogfeld für die Konfiguration der Optionen, und stellen Sie sicher, dass der Inhaltsratgeber aktiviert ist.

Wenn der Inhaltsratgeber aktiviert ist oder schon einmal auf Ihrem System aktiviert wurde, werden Zugriffe auf den Schlüssel HKLM\PolicyData und die zugehörigen Unterschlüssel angezeigt. Sie werden in Regedit jedoch keinen PolicyData-Schlüssel unter HKEY_LOCAL_MACHINE finden. Nehmen Sie sich eine Minute Zeit, um die Vorgänge nachzuvollziehen und zu verstehen.

Die Antwort ist, dass IE dynamisch eine Registrierungsstruktur mit der Win32-API RegLoadKey lädt, die benötigten Werte liest und dann die Struktur mit RegUnloadKey entlädt. Die Struktur hat den Namen C:\Winows\System\Ratings.pol – die Datei ist ausgeblendet und schreibgeschützt, Sie können sie jedoch anzeigen, indem Sie attrib –r –h c:\windows\system\ratings.pol eingeben.

Die in Regmon angezeigten Ablaufverfolgungen zeigen Ihnen die Informationen, nach denen der Inhaltsratgeber in der Struktur sucht. Wenn Sie den Inhalt selbst untersuchen möchten, laden Sie mein Regload-Hilfsprogramm von www.sysinternals.com/regload.zip herunter, und führen Sie es mit der folgenden Syntax aus: regload test c:\windows\system\ratings.pol. Öffnen Sie dann Regedit, und durchsuchen Sie HKLM\test. Die angezeigten Werte entsprechen den Einstellungen, die Sie im Inhaltsratgeber angeben, und beziehen sich auf die Konfigurationsdatei, die im Wert Users\FileName0 in der Struktur angegeben ist. Der Wert verweist in der Regel auf die Datei C:\Windows\System\RSACi.rat, die von der Internet Content Rating Association (ICRA) definierte Bewertungsdatei. Mitunter sehen Sie in den Registrierungseinstellungen des Inhaltsratgebers vielleicht einen Wert mit dem recht witzigen Namen „PleaseMom“ (ein Beispiel finden Sie unter HKLM\Test\Users\Default). Dieser Wert geht auf das Kontrollkästchen „Supervisor kann durch Kennworteingabe Benutzern ermöglichen, Inhalte trotz Beschränkung anzuzeigen“ auf der Seite „Allgemein“ des Dialogfelds „Einstellungen“ des Inhaltsratgebers zurück.

Der Grund, warum Microsoft die Existenz dieser Registrierungswerte verschleiern will, ist offensichtlich. Im Entwurf von Microsoft gibt es jedoch eine ziemlich ernstzunehmende Schwäche. Beachten Sie, dass Sie beim Aktivieren des Inhaltsratgebers ein Kennwort angeben müssen, das das Einstellungsdialogfeld des Inhaltsratgebers schützt. Dieses Kennwort wird in HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Ratings\Key gespeichert. Wenn Sie diesen Wert löschen, können Sie sofort auf die Inhaltsratgeber-Einstellungen zugreifen, ohne ein Kennwort einzugeben. Wenn die IE-Entwickler*innen also vor dem Problem standen, die Inhaltsratgeber-Einstellungen verschleiern zu müssen, warum haben sie dann diese Hintertür offengelassen? Meiner Meinung nach liegt das an dem typischen Microsoft-Sicherheitskonzept. Zum Entladen des Schlüssels, den Sie mit Regload geladen haben, geben Sie übrigens einfach regload test ein.

BALD VERFÜGBAR

NEUE WHISTLER-SYSTEMAUFRUFE

Whistler ist eine inkrementelle Weiterentwicklung des Windows 2000-Betriebssystems mit dem Schwerpunkt auf erhöhter Zuverlässigkeit und einfacher Migration von Benutzer*innen von Windows 9x-Betriebssystemen. Es enthält jedoch einige Kerneländerungen. Die offensichtlichsten Änderungen sind eine Handvoll neuer Systemaufrufe und exportierter Kernelfunktionen (verfügbar für Gerätetreiber). Beim nächsten Mal gebe ich Ihnen eine Vorschau dieser neuen Kernel-APIs.

Vielen Dank, dass Sie den Sysinternals-Newsletter gelesen haben.

Veröffentlicht am Donnerstag, 30. November 2000 um 19:05 Uhr von ottoh

[Newsletter-Archiv ^] [< Band 2, Nummer 4] [Band 3, Nummer 1 >]