Nach Ansicht der Verbände der Rechteinhaber in den USA sollen DRM-Systeme auch dann nicht umgangen werden dürfen, wenn sie Menschenleben in Gefahr bringen könnten.
Alle drei Jahre überprüft die für das Copyright zuständige Behörde in den USA, das Copyright-Office, für welche Zwecke technische Schutzmaßnahmen legal umgangen werden dürfen. Zwei der eingereichten Vorschläge sahen für solche Fälle Ausnahmen vor, in denen DRM-Systeme die Sicherheit und Privatsphäre von Anwendern gefährden beziehungsweise „kritische Infrastrukturen bedrohen und möglicherweise Menschenleben in Gefahr bringen“. Vor kurzem waren Sicherheitslücken in DRM-Software bekannt geworden, die entsprechende Befürchtungen geweckt und selbst das US-Heimatschutzministerium auf den Plan gerufen hatten.
Nun haben sich die Verbände der Rechteinhaber – darunter Verleger, Autorenvereinigung, Business Software Alliance (BSA), der Verband der Filmindustrie (MPAA), der Verband der Musikindustrie (
RIAA) – strikt dagegen ausgesprochen, Anwendern das Recht zum Selbstschutz einzuräumen. Das berichtet der prominente Sicherheitsexperte Edward Felten, der selbst Antragsteller in dem Verfahren ist.
Ausnahmen ausgeschlossen
Die Industrievertreter rechtfertigen sich mit der Verunsicherung, die möglicherweise durch gesetzliche Ausnahmen hervorgerufenen werden könnte: „Diese Unsicherheit wäre noch größer, sollten die Formulierungen aus den Vorschlägen 2 (worin die Begriffe ‚Privatspäre oder Sicherheit’) oder 8 (nach der Grenzen dort zu ziehen wären, wo Systeme zur Zugriffskontrolle ‚kritische Infrastrukturen bedrohen und möglicherweise Menschenleben in Gefahr bringen’) verwendet werden.“ Der Schutz des Eigentums der Rechteinhaber sei vorrangig: „[K]einer der unterbreiteten Vorschläge rechtfertigt eine gesetzliche Ausnahme; keiner sollte angenommen werden.“
Robert A. Gehring für
irights.info
Eingetragen unter: Technik
March 13th, 2006
Da es - wie ich hoffe - doch einige User ernsthaft interessiert, einmal hinter das Geheimnis eines Bluescreens zu schauen, habe ich mich entschlossen, ein How-To betreffs Bluescreens und ihrer Analyse zu schreiben. Das Material lehnt sich dicht an einen Artikel aus einer c’t des Jahres 2004 an, indem die gesamte Vorgehensweise sehr gut beschrieben wird.
Zuallererst sollte man sich von dem Gedanken freimachen, ein BSOD sei etwas schlechtes. Erscheint ein Bluescreen, dann heisst das, das das Betriebssystem festgestellt hat, das es sich momentan in einem Zustand befindet, in dem es nicht mehr sicher weiterarbeiten kann. Jede noch folgende Aktion könnte größeren Schaden nach sich ziehen, weshalb das System sich folgerichtig kontrolliert selbst herunter fährt.
Ich empfehle deshalb auch im Fall eines völligen Einfrierens des Systems selbst einen Bluescreen hervorzurufen, anstatt per Reset-Schalter oder ähnlichen Experimenten das System noch mehr zu schädigen.
Die Voraussetzungen dafür sind ganz einfach einzurichten:
- in der Registry zum Schlüssel
HKEY_LOCAL_MACHINE\SYSTEMCurrentControlSet\Services\i8042prt\Parameters
navigieren
- dort einen neuen DWORD-Wert mit dem Namen CrashOnCtrlScroll einrichten und diesem den Wert 1 zuweisen
-Neustart
Nach dem Neustart kann jederzeit ein Bluescreen ausgelöst werden, indem man die rechte Strg-Taste gedrückt hält und zweimal auf Rollen drückt (die mittlere Taste in der Dreiergruppe über dem Cursor-Block, die auch manchmal mit Scroll oder ScrlLock beschriftet ist.
User, die noch keinen Bluescreen zu Gesicht bekommen haben, sich aber über einen manchmal aus heiterem Himmel erfolgenden Neustart des Systems wundern, sind (unwissentlich) Microsofts honigsüßen Worten auf den Leim gekrochen, das es unter XP keine Bluescreens mehr gäbe.
Diese Aussage ist insofern korrekt, als das die Bluescreens einfach versteckt wurden. Sollte ein Ereignis wie ein plötzlicher scheinbar unmotivierter Neustart auftreten, dann sollte man unter folgendem Pfad nachschauen und wenn man an einer Bluescreen-Analyse interessiert ist, die Optionen wie folgt einstellen
Rechtsklick auf Arbeitsplatz/Eigenschaften/Erweitert/Starten und Wiederherstellen/Einstellungen/Systemfehler
Hier gibt es drei wichtige Optionen:
"Automatisch Neustart durchführen" - sollte deaktiviert sein.
(Ist es aktiviert, kommt es eben zu einem Neustart, ohne dass ein Bluescreen gezeigt und die CPU angehalten wird)
"Debuginformatioen speichern" - hier ist standardmäßig das "kleine Speicherabbild" ausgewählt, was jedoch für eine Analyse des BSOD nicht ausreicht. Hier sollte "Kernelspeicherabbild" eingestellt werden. Ein "vollständiges Hauptspeicherabbild" ist so groß wie der komplette Hauptspeicher plus ein paar zusätzliche MB, bringt jedoch keine Vorteile.
"Vorhandene Dateien überschreiben" - sollte aktiviert sein, da andernfalls Windows einfach kein Speicherabbild schreibt, wodurch man den Fehler dann auch nicht analysieren kann. Resultierend daraus sollte man nach einem BSOD und dem Neustart des Systems den erstellten Memory-Dump entweder umbenennen oder durch Kopieren sichern.
Damit ist der erste Teil der Analyse-Vorbereitung abgeschlossen.
Zur Sicherheitsarchitektur von XP gehört es, dass ein x-beliebiges Programm Windows nicht zum Absturz bringen kann, da dieses im sogenannten User-Mode (auch "Ring 3") genannt in einem eigenen virtuellen Adressraum läuft und nicht auf den Adressraum anderer Programme oder gar der Hardware zugreifen kann.
Ein Bluescreen kann nur entstehen, wenn Code im Kernel-Mode (auch "Ring 0" genannt) etwas tut, was er nicht darf.Das können Gerätetreiber, oder der Mikrokernel selbst sein. Im "Ring 0" teilen sich alle Treiber einen gemeinsamen Adressraum und können sich deshalb auch gegenseitig Schwierigkeiten machen.
Soviel zur Theorie.
Zeigt das System nun einen Bluescreen, bekommt man schon ein paar wichtige Informationen geliefert, die man allerdings interpretieren muss.
(dieser Bluescreen gehört nicht zur später folgenden Analyse. Ich habe ihn nur benutzt, um die nächsten Zeilen besser darstellen zu können)
Jeder Bluescreen liefert eine Zeile, die mit STOP beginnt, worauf sich eine
achtstelllige Hexadezimal-Zahl anschließt. Diese Zahl gibt einen ersten Hinweis auf den Fehler, wenn sie richtig interpretiert wird.
Oft steht ausserdem noch eine Zeile in der Art
BAD_POOL_HEADER
IRQL_NOT_LESS_OR_EQUAL
oder ähnliches dabei. In vielen Fällen kann man mit dieser Zeile und etwas Googelei (besser ist Scroogelei) schon im Netz Hinweise auf den Übeltäter und Lösungsvorschläge finden.
Oft hat man allerdings auch Pech.
Genau dann brauchen wir das beim BSOD erstellte Speicherabbild, das normalerweise unterhalb WINDOWS als MEMORY.DMP erstellt wurde.
Microsoft bietet uns nun ein Werkzeug an, um das Speicherabbild zu analysieren - den Debugger WinDbg (ca. 15,8 MB), der von Microsoft heruntergeladen werden kann. Allerdings nützt der Debugger allein wenig, man braucht auch noch so genannte Symboldateien, die jedoch im vollen Umfang ca. 195 MB groß sind. Die sind allerdings nicht zwingend komplett notwendig, vereinfachen aber das Verfahren, wenn sie komplett auf der Platte liegen, was bei ordentlichen DSL-Anschlüssen kein größeres Download-Problem darstellen dürfte. Allerdings erkennt der Debugger mitunter nach der Installation der Symboldateien diese nicht richtig und bringt ständig eine Fehlermeldung; deshalb bevorzuge ich auch eher die Methode des selektiven Downloads bei Bedarf wie folgt.
Wer die Symbole nicht komplett downloaden will, kann den Debugger so einrichten, dass er nur die Symboldateien aus dem Netz lädt, die gerade gebraucht werden. Das funktioniert folgendermaßen:
- WinDbg installieren
- irgendwo nach Belieben einen neuen Ordner anlegen
- im WinDbg den Menübefehl File Symbol Path wählen und in das Eingabefeld eintragen:
SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols
wobei statt "C:\Symbols" der neu erstellte Ordner eingetragen werden muss. Dort speichert WinDbg die heruntergeladenen Symbole. Ich nehme dafür WINDOWS\SYMBOLS, wie man sieht.
Jetzt lädt man das beim Bluescreen erstellte Speicherabbild mit File/Open Crash Dump, woraufhin sich zwei Fenster mit den Titelzeilen Command und Disassembly öffnen. Das letztere kann man gleich wieder schließen, da es uns nichts nützt. In neueren Versionen des WinDbg öffnet sich dieses Fenster in der Regel nicht mehr mit, bei älteren Versionen war das jedoch der Fall.
Im Command-Fenstersind jetzt schon ein paar wichtige Informationen zu sehen:
- die Zeile, die mit Probably caused by: beginnt (was soviel heisst wie: "vermutlich verursacht von:") meldet einen Dateinamen, der in den meisten Fällen schon ein Treffer ist. Handelt es sich hier um eine Datei mit der Endung .sys dann lohnt es sich, zu untersuchen, woher sie stammt. (Wir nehmen hier im Beispiel mal an, es ist eine Datei namens i8042prt.sys)
- die zweite interessante Zeile beginnt mit BugCheck und enthält eine Hexadezimalzahl und weitere kryptische Angaben in Klammern. Und siehe da - es handelt sich hier um dieselbe Zahl, die nach dem STOP-Befehl auf dem Bluescreen auftauchte.
Wir sind also auf dem richtigen Weg und müssen jetzt in Erfahrung bringen, was uns diese Zahlen eigentlich sagen wollen.
Nächster Schritt:
- unten im Comand-Fenster hinter "kd>" den Befehl
!analyze -v
eingeben. Es erscheint eine Menge an Informationen, wobei wir uns auf die ersten Zeilen konzentrieren.Die Art des aufgetretenen Fehlers wird durch einen aus Großbuchsataben und Unterstrichen gebildeten Namen wie MANUALLY_INITIATED_CRASH angezeigt, verbunden mit einer (zu) kurzen Beschreibung des Fehlers. Um dazu ausführlichere Informationen zu erhalten, kopieren wir diesen Namen und fügen ihn in der Eingabezeile hinter dem Befehl ".hh" wieder ein, was dann so aussieht:
.hh MANUALLY_INITIATED_CRASH
Dieser Befehl startet die WinDbg-Hilfe, in der der Name automatisch gesucht und ausführlichere Angaben dazu angezeigt werden. Sehr oft findet man hier auch Lösungsansätze und Tipps wie der Fehler zu eliminieren ist. Steht dort, dass defekte Hardware die häufigste Fehlerursache ist, dann sollte man das Ernst nehmen.
Bei den Informationen, die der "!analyze -v"-Befehl ausgibt interessieren uns ausserdem noch die Zeilen unter der Überschrift STACK_TEXT:.
Dort steht eine umgekehrt chronologische Liste der Funktionen, die sich kurz vor dem Crash gegenseitig aufgerufen haben. In der letzten Spalte der jeweiligen zeile steht der Name des zuständigen Moduls und dahinter, durch ein + oder ! abgetrennt die Adresse innerhalb des Moduls. Wenn hier in den ersten paar Zeilen ein anderer Modulname als nt steht, dann ist dieses Modul zumindest schon mal schwer verdächtig.
mit dem Befehl
!thread
bekommt man eine weitere Ausgabe. Enthält diese die Überschrift IRP List, dann nimmt man die Adressen aus der ersten Spalte der Liste und gibt sie mit dem Befehl !irp ein. Das sieht dann z. B. so aus:
!irp ffabccd8
Daraufhin erhält man weitere Verdächtige, nämlich den Inhalt des so genannten I/O Request Packets, das an dieser Adresse im Speicher liegt. Das Packet enthält immer auch die Namen der an dieser Ein/Ausgabe beteiligten Treiber.
Weiter gehts. Wir sind fast fertig.
Den weiter oben zuerst herausgekitzelten Modul-Namen, in der Zeile, die mit Probably caused by: beginnt (i8042prt.sys), benutzen wir nun für die End-Analyse.
Wir geben den Befehl lm v ein, gefolgt vom Modulnamen ohne die Endung .sys, dafür hängen wir jedoch ein m davor. Das Ganze sieht dann so aus:
lm v mi8042prt
Jetzt sollten wir in der Ausgabe den kompletten Dateinamen mit Pfad der Treiberdatei und Herstellernamen bekommen. Ist das nicht der Fall, dann probieren wir den Befehl
!devnode 0 1
der uns eine Liste aller geladenen Gerätetreiber ausgibt. In dieser Liste suchen wir wieder den Modulnamen (ohne Endung) (über die Funktion Edit/Find in der Menüleiste)
In dem Eintrag, in dem er hinter Service Name erscheint, interessiert uns der Instance Path. Diesen notieren wir uns.
Und damit hat die schwere Geburt fast ihr Ende gefunden.
Wir starten wieder regedit und gehen in den Pfad
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum
und von dort aus weiter genau entlang des eben notierten Pfades.Und hier verrät uns endlich der Eintrag DeviceDesc, um was für ein Gerät oder Treiber es sich bei dem wahren Übeltäter handelt.
Fertig!
Hat man die den Fehler auslösende Komponente dann identifiziert, sollte man sich z. B. im Gerätemanager noch ein paar weitere Infos zum Treiber besorgen, wie Hersteller, Versionsnummer usw. und sich dann auf die Suche nach einem neuen Treiber machen. Manchmal hilft auch eine einfache Neuinstallation des bewußten Treibers, bzw. eine Systemwiederherstellung oder das Zurückspielen eines vorher angelegten Images, um den früheren Zustand vor der Veränderung, die den Fehler ausgelöst hat, wieder herzustellen. Natürlich kann man sich - mit diesen gesammelten Angaben bewaffnet - auch auf in die Weiten des Netzes begeben, um eine intensive Internet-Recherche zur Fehlerbeseitigung zu betreiben. Sollte es sich um defekte Hardware handeln, dann wäre wohl ein Austausch das passende Procedere.
Ich gebe zu, das Ganze ist kein Kinderkram, aber einen richtigen Computerfreak sollte es schon mal reizen, solche Geheimnisse zu erforschen und zu entdecken, anstatt nur mit den Schultern zu zucken, wenn ein BSOD auftaucht.
Übrigens, wer keinen Bluescreen mehr sehen will, kann auch die Farbe ändern und hat dann eben einen RSOD oder GSOD.
Dazu braucht nur folgendes:
- im WINDOWS-Ordner zur SYSTEM.INI navigieren und diese wie folgt editieren:
Nach [386Enh] folgende Einträge hinzufügen:
MessageTextCOLOR=X
MessageBackCOLOR=X
Das X einfach durch die Nummer der gewünschten Farbe ersetzen:
Black = 0
Blue = 1
Green = 2
Cyan = 3
Red = 4
Magenta = 5
Yellow/Brown = 6
White = 7
Grey = 8
Bright Blue = 9
Bright Green = A
Bright Cyan = B
Bright Red = C
Bright Magenta = D
Bright Yellow = E
Bright White = F
Wobei ich 7 und F nicht ernsthaft in Erwägung ziehenn würde. Denn weisse Schrift auf weissem Grund, das erinnert mich irgendwie an die ostfriesische Nationalflagge…
Viel Spaß und gutes Gelingen.
Eingetragen unter: Software, Technik
June 5th, 2007
