HowTo - Delete 0-Byte Registry Keys
Wie man nicht löschbare Regkeys aus dem System entfernt; am Beispiel eines Keys der Software O&O Defrag
Wie man nicht löschbare Regkeys aus dem System entfernt; am Beispiel eines Keys der Software O&O Defrag
O&O Defrag ist ein wohlbekanntes Windows-Tool zum Defragmentieren von Festplatten. Es funktioniert recht gut, hat aber einen entschiedenen Nachteil - es setzt einen Regkey, der sich mit herkömmlichen Mitteln nicht einsehen oder löschen lässt. Es wäre nicht weiter tragisch, wenn man sich des Problems durch eine einfache Deinstallation des Programms entledigen könnte - aber leider, leider bleibt einem der Key auch danach noch erhalten, sozusagen als kleines Andenken an die Fähigkeiten der Programmierer (worauf man bestimmt gerne verzichten könnte).
Der betreffende Key ist:
Dieser lässt sich weder mit regedit.exe oder reg.exe noch mit anderen Scripts oder Tools lesen oder bearbeiten, die die Windows-API benutzen. Auch der Versuch, die Rechte zu setzen, mißlingt - sämtliche Zugriffsversuche quittiert das System mit der Fehlermeldung, daß entweder nicht zugegriffen werden kann oder der betreffende Key angeblich nicht existiert.
Der Grund dafür, daß er sich nicht lesen oder löschen lässt, ist ein unsichtbarer 0-Byte-Eintrag unterhalb des Zweigs. Eine Beschreibung dieser 0-Byte-Keys von Marc Russinovich (Sysinternals) zu finden.
Der Key wird über einen nativen Windows-API-Call generiert. Er lässt sich deshalb nicht löschen, weil alle heute verbreiteten Tools diese API nicht verwenden; sie benutzen stattdessen Aufrufe der Windows32-API. Diese interpretiert Strings als sog. null-terminiertes ANSI (8-bit) oder Wide Character (16-bit). In der nativen API-Schnittstelle hingegen werden Strings als "counted Unicode (16-bit)" definiert. (Quelle: www.sysinternals.com)
Man kann über beide Schnittstellen auf die Registry zugreifen. Native API bietet -anders als ANSI- über Unicode die Möglichkeit, Nullen (0) als Teil des Strings zu definieren. Beispiel hierfür: der String "Key\0" wird in Unicode als ein String mit 4 byte Länge definiert. (Quelle: www.sysinternals.com)
Greift man nun über die Win32-API auf die Registry zu, so wird der String nicht mit 4 byte Länge erkannt - stattdessen sieht Windows hier nur den String "Key". Der restliche Teil des Strings, also "\0" wird einfach abgeschnitten. Somit kann man auf diesen Key nicht mehr auf normalem Wege zugreifen. Es ergibt sich ein Problem, da, wie bereits erwähnt, sämtliche Registry-Werkzeuge die Win32-API verwenden. (Quelle: www.sysinternals.com)
Interessanterweise werden ähnliche Techniken zum Verschleiern von Registryeinträgen teilweise auch von Rootkits verwendet. Wie O&O dazu kommt, derlei Sachen in kommerziellen Softwareprodukten einzusetzen, bleibt ein Geheimnis der Firma und uns ein Rätsel. Der Key wird auch prompt von Rootkit-Detektoren bei einem Scan als fragwürdig gemeldet; z.B der bekannte Rootkit-Scanner "RootkitRevealer" von Sysinternals findet und listet ihn.
Genug Informationen, machen wir uns daran, den Key zu löschen. Wir wollen dies online am laufenden Rechner vornehmen, benötigt werden hierzu folgende Tools:
Schritt 1 - Sichern der Registry
Wir öffnen eine Dosbox und geben folgendes ein:
Dies legt ein Verzeichnis an, welches wir später zum Sichern der Registrydaten benötigen.
Weiterhin geben wir folgenden Befehl ein:
Hiermit wird die Registry in das vorher angelegte Verzeichnis gesichert. Regback meldet sich nun idealerweise mit folgendem oder ähnlichem Output:
Schritt 2 - Anpassen des gesicherten Registry-Hives
Nun starten wir den Hex Editor -ich verwende "Hex Workshop", einen gebräuchlichen und recht komfortablen Editor- und laden über Öffnen die folgende Datei in den Editor:
Wir rufen nun die Suchfunktion Über das Menü oder die Tastenkombination STRG-F auf und stellen in der daraufhin erscheinenden Box als Suchparameter "String" ein. Als Suchbegriff geben wir "OODEFRAG" ein und klicken auf "Suche". Der Wert wird gefunden und angezeigt.
Ewas oberhalb des gefundenen Strings befindet sich ein weiterer String namens "SYSTEM" - dieser String entspricht dem Regkey, den wir löschen wollen. Jetzt klicken wir in das Anzeigefeld und geben direkt hinter dem String "SYSTEM" folgendes ein:"X0"
Nun speichern wir die Datei ab - die Frage, ob man eine Sicherung anlegen möchte, bestätigen wir mit "Ja" und schließen den Hex Editor.
Schritt 3 - Löschen des Regkeys
Wir starten den Registry Editor (regedit.exe) und klicken in der linken Spalte auf den Hive HKEY_LOCAL_MACHINE. Daraufhin öffnen wir das Menü "Datei". Hier rufen wir den Punkt "Struktur laden" auf und öffnen dann das File
Bei der folgenden Abfrage-Box geben wir
Nachdem die Struktur geladen ist, findet man sie unterhalb des Zweiges
und sehen uns den Wert unterhalb des Keys an:
Nachdem wir uns satt gesehen haben, markieren wir jetzt den Key
ganz einfach in der linken Spalte und löschen ihn kurz und knackig.
Anschließend rufen wir das Menü "Datei" und hier den Punkt "Struktur entfernen" auf (WICHTIG!) und schließen dann den Registry Editor.
Schritt 4 - Import des geänderten Registry-Hives
Es folgt der letzte Schritt. Wir öffnen wiederum eine Dosbox, in der wir folgendes eingeben:
Nun kommt der wichtigste Schritt, das Zurückschreiben des geänderten Registry-Hives. Wir geben den folgenden Befehl in der Dosbox ein:
Eine Meldung erscheint:
Danach schließen wir alles und rebooten das System. Dieser Teil ist mit einem gewissen Nervenkitzel verbunden - aber keine Sorge; wenn alles wie oben angegeben durchgeführt wurde, dann sollten sich keinerlei Probleme ergeben.
Schlußendlich starten wir nach dem erfolgreichen Reboot noch einmal den Registry Editor und stellen fest, daß der Regkey nicht mehr vorhanden ist.
Ein herzliches Dankeschön an alle für die Hilfe bei der Suche und die Tipps
Weiterhin unbekannterweise ein Dank an Marc Russinovich für die sehr ausführliche Erläuterung der 0-Byte-Keys auf seinen Seiten - ich habe hier zur Erläuterung dieser Keys drei kleinere Absätze entnommen und ins Deutsche übersetzt.
Quellen:
Wie kann ich die Registry in W2K und XP offline bearbeiten ?
Regkey lässt sich nicht löschen
Verhindert Löschen von Registry-Eintrag
Registry Keys
Wie man nicht löschbare Regkeys aus dem System entfernt; am Beispiel eines Keys der Software O&O Defrag
O&O Defrag ist ein wohlbekanntes Windows-Tool zum Defragmentieren von Festplatten. Es funktioniert recht gut, hat aber einen entschiedenen Nachteil - es setzt einen Regkey, der sich mit herkömmlichen Mitteln nicht einsehen oder löschen lässt. Es wäre nicht weiter tragisch, wenn man sich des Problems durch eine einfache Deinstallation des Programms entledigen könnte - aber leider, leider bleibt einem der Key auch danach noch erhalten, sozusagen als kleines Andenken an die Fähigkeiten der Programmierer (worauf man bestimmt gerne verzichten könnte).
Der betreffende Key ist:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\System
Dieser lässt sich weder mit regedit.exe oder reg.exe noch mit anderen Scripts oder Tools lesen oder bearbeiten, die die Windows-API benutzen. Auch der Versuch, die Rechte zu setzen, mißlingt - sämtliche Zugriffsversuche quittiert das System mit der Fehlermeldung, daß entweder nicht zugegriffen werden kann oder der betreffende Key angeblich nicht existiert.
Der Grund dafür, daß er sich nicht lesen oder löschen lässt, ist ein unsichtbarer 0-Byte-Eintrag unterhalb des Zweigs. Eine Beschreibung dieser 0-Byte-Keys von Marc Russinovich (Sysinternals) zu finden.
Der Key wird über einen nativen Windows-API-Call generiert. Er lässt sich deshalb nicht löschen, weil alle heute verbreiteten Tools diese API nicht verwenden; sie benutzen stattdessen Aufrufe der Windows32-API. Diese interpretiert Strings als sog. null-terminiertes ANSI (8-bit) oder Wide Character (16-bit). In der nativen API-Schnittstelle hingegen werden Strings als "counted Unicode (16-bit)" definiert. (Quelle: www.sysinternals.com)
Man kann über beide Schnittstellen auf die Registry zugreifen. Native API bietet -anders als ANSI- über Unicode die Möglichkeit, Nullen (0) als Teil des Strings zu definieren. Beispiel hierfür: der String "Key\0" wird in Unicode als ein String mit 4 byte Länge definiert. (Quelle: www.sysinternals.com)
Greift man nun über die Win32-API auf die Registry zu, so wird der String nicht mit 4 byte Länge erkannt - stattdessen sieht Windows hier nur den String "Key". Der restliche Teil des Strings, also "\0" wird einfach abgeschnitten. Somit kann man auf diesen Key nicht mehr auf normalem Wege zugreifen. Es ergibt sich ein Problem, da, wie bereits erwähnt, sämtliche Registry-Werkzeuge die Win32-API verwenden. (Quelle: www.sysinternals.com)
Interessanterweise werden ähnliche Techniken zum Verschleiern von Registryeinträgen teilweise auch von Rootkits verwendet. Wie O&O dazu kommt, derlei Sachen in kommerziellen Softwareprodukten einzusetzen, bleibt ein Geheimnis der Firma und uns ein Rätsel. Der Key wird auch prompt von Rootkit-Detektoren bei einem Scan als fragwürdig gemeldet; z.B der bekannte Rootkit-Scanner "RootkitRevealer" von Sysinternals findet und listet ihn.
Genug Informationen, machen wir uns daran, den Key zu löschen. Wir wollen dies online am laufenden Rechner vornehmen, benötigt werden hierzu folgende Tools:
-regback.exe (NT Ressourcekit)
-regrest.exe (NT Ressourcekit)
-regedit.exe
-ein Hexeditor (z.B. HexWorkshop)
Schritt 1 - Sichern der Registry
Wir öffnen eine Dosbox und geben folgendes ein:
md c:\temp\reg_backup
Weiterhin geben wir folgenden Befehl ein:
regback c:\temp\reg_backup
saving SECURITY to c:\temp\reg_backup\SECURITY
saving SOFTWARE to c:\temp\reg_backup\software
saving SYSTEM to c:\temp\reg_backup\system
saving .DEFAULT to c:\temp\reg_backup\default
saving SAM to c:\temp\reg_backup\SAM
Schritt 2 - Anpassen des gesicherten Registry-Hives
Nun starten wir den Hex Editor -ich verwende "Hex Workshop", einen gebräuchlichen und recht komfortablen Editor- und laden über Öffnen die folgende Datei in den Editor:
c:\temp\reg_backup\software
Wir rufen nun die Suchfunktion Über das Menü oder die Tastenkombination STRG-F auf und stellen in der daraufhin erscheinenden Box als Suchparameter "String" ein. Als Suchbegriff geben wir "OODEFRAG" ein und klicken auf "Suche". Der Wert wird gefunden und angezeigt.
Ewas oberhalb des gefundenen Strings befindet sich ein weiterer String namens "SYSTEM" - dieser String entspricht dem Regkey, den wir löschen wollen. Jetzt klicken wir in das Anzeigefeld und geben direkt hinter dem String "SYSTEM" folgendes ein:"X0"
Nun speichern wir die Datei ab - die Frage, ob man eine Sicherung anlegen möchte, bestätigen wir mit "Ja" und schließen den Hex Editor.
Schritt 3 - Löschen des Regkeys
Wir starten den Registry Editor (regedit.exe) und klicken in der linken Spalte auf den Hive HKEY_LOCAL_MACHINE. Daraufhin öffnen wir das Menü "Datei". Hier rufen wir den Punkt "Struktur laden" auf und öffnen dann das File
c:\temp\reg_backup\software
, das wir vorher mit regbackup generiert haben.Bei der folgenden Abfrage-Box geben wir
xxxOODEFRAGxxx
oder etwas ähnlich sprechendes als Namen an -hier keinen existierenden Zweignamen angeben, sondern einen Wert, der noch nicht existiert- und klicken auf OK.Nachdem die Struktur geladen ist, findet man sie unterhalb des Zweiges
HKEY_LOCAL_MACHINE
. Wir navigieren jetzt zum Key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\System
und sehen uns den Wert unterhalb des Keys an:
OODEFRAGxxxxxxxxxx
Nachdem wir uns satt gesehen haben, markieren wir jetzt den Key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\System
ganz einfach in der linken Spalte und löschen ihn kurz und knackig.
Anschließend rufen wir das Menü "Datei" und hier den Punkt "Struktur entfernen" auf (WICHTIG!) und schließen dann den Registry Editor.
Schritt 4 - Import des geänderten Registry-Hives
Es folgt der letzte Schritt. Wir öffnen wiederum eine Dosbox, in der wir folgendes eingeben:
cd c:\temp\reg_backup
Nun kommt der wichtigste Schritt, das Zurückschreiben des geänderten Registry-Hives. Wir geben den folgenden Befehl in der Dosbox ein:
regrest C:\temp\reg_backup\software software.bku machine software
Eine Meldung erscheint:
replacing software with C:\temp\reg_backup\software You must reboot for changes to take effect.
Danach schließen wir alles und rebooten das System. Dieser Teil ist mit einem gewissen Nervenkitzel verbunden - aber keine Sorge; wenn alles wie oben angegeben durchgeführt wurde, dann sollten sich keinerlei Probleme ergeben.
Schlußendlich starten wir nach dem erfolgreichen Reboot noch einmal den Registry Editor und stellen fest, daß der Regkey nicht mehr vorhanden ist.
Ein herzliches Dankeschön an alle für die Hilfe bei der Suche und die Tipps
Weiterhin unbekannterweise ein Dank an Marc Russinovich für die sehr ausführliche Erläuterung der 0-Byte-Keys auf seinen Seiten - ich habe hier zur Erläuterung dieser Keys drei kleinere Absätze entnommen und ins Deutsche übersetzt.
Quellen:
Wie kann ich die Registry in W2K und XP offline bearbeiten ?
Regkey lässt sich nicht löschen
Verhindert Löschen von Registry-Eintrag
Registry Keys
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 8376
Url: https://administrator.de/tutorial/howto-delete-0-byte-registry-keys-8376.html
Ausgedruckt am: 22.12.2024 um 16:12 Uhr
32 Kommentare
Neuester Kommentar
Hallo,
leider hat dieses Beispiel des 0-Byte-Tricks Schule gemacht. Die Firma Haenlein Software bietet eine Testversion des Programms DVR-Studio-Pro an. Nach dem Deinstallieren bleibt ein Registry-Eintrag (HKEY_LOKAL_MACHINE\Software\Haenlein) übrig, der sich nicht löschen lässt. In diesem Eintrag ist offensichtlich das Datum der Erstinstallation gespeichert, so daß man die Demoversion nicht nochmal installieren kann.
Ich würde diesen Eintrag gerne loswerden, traue mich aber nicht, auf Gutglück in der Registry herum zu experimentieren. Wäre toll, wenn sich mal jemand ranwagt, der mehr Ahnung davon hat und die Beschreibung postet.
leider hat dieses Beispiel des 0-Byte-Tricks Schule gemacht. Die Firma Haenlein Software bietet eine Testversion des Programms DVR-Studio-Pro an. Nach dem Deinstallieren bleibt ein Registry-Eintrag (HKEY_LOKAL_MACHINE\Software\Haenlein) übrig, der sich nicht löschen lässt. In diesem Eintrag ist offensichtlich das Datum der Erstinstallation gespeichert, so daß man die Demoversion nicht nochmal installieren kann.
Ich würde diesen Eintrag gerne loswerden, traue mich aber nicht, auf Gutglück in der Registry herum zu experimentieren. Wäre toll, wenn sich mal jemand ranwagt, der mehr Ahnung davon hat und die Beschreibung postet.
Hallo,
ich habe eine gute Neuigkeit - Marc Russinovich hat es geschafft! Unter http://www.sysinternals.com könnt Ihr das Tool "regdelnull" runterladen und damit alle 0-Byte Registry Keys löschen.
Bei mir hat es funktioniert, obwohl es nicht den gewünschten Erfolg gebracht hat. Offensichtlich ist irgendwo noch auf meinem Rechner das Datum der Erstinstallation hinterlegt. Na ja, wenigstens bin ich jetzt diesen Key los. Falls jemand noch eine Idee hat, was ich machen kann, dann bitte melden.
ich habe eine gute Neuigkeit - Marc Russinovich hat es geschafft! Unter http://www.sysinternals.com könnt Ihr das Tool "regdelnull" runterladen und damit alle 0-Byte Registry Keys löschen.
Bei mir hat es funktioniert, obwohl es nicht den gewünschten Erfolg gebracht hat. Offensichtlich ist irgendwo noch auf meinem Rechner das Datum der Erstinstallation hinterlegt. Na ja, wenigstens bin ich jetzt diesen Key los. Falls jemand noch eine Idee hat, was ich machen kann, dann bitte melden.
Moin fritzo,
mal zwischendurch ein paar Rückmeldungen zu diesem allerbesten Sahne-Thread.
Erstmal vielen Dank für die Mühe, die Du Dir machst, hier mal ein paar Gegenmittel einzusetzen gegen die sich krebsartig ausbreitenden 0-Byte-Registry-Keys. Wie sich die auch ohne großartige Programmierkenntnisse erzeugen lassen, scheint sich ja auch schon in Scriptkiddie-Kreisen rumgesprochen zu haben..
Folgende Anmerkungen:
- in dem Reghide.c-Source sind Dir durch HTML-Tags die beiden Standard-Include-Dateien
windows.h und stdio.h verloren gegangen. Könntest Du noch mal editieren vielleicht.
- beim Link der ZipHidden.rar wird bei mir nur eine ZipHidden.exe entpackt, und die ist ist nicht sonderlich geschwätzig. Oder ist mein WinRar zu alt? Sollte da nicht Source dabei sein?
- die RegDelNull funktioniert bestens. Wurde auch bei mir gleich fündig.
- was ich in diesem Thread vermisse, ist noch mal der deutliche Hinweis, dass das ganze Elend mit diesen 0-Byte-Registry-Keys dadurch entstanden ist, dass M$ nur den unbedingt nötigen Bodensatz der native API-Calls nach außen dokumentiert hat... und ich wette eine Kiste Becks, dass die ersten 0-Byte-Registry-Keys "aus Versehen", durch falsche Parameter entstanden sind und nicht bei dem Versuch, einen "Installationsschutz" zu entwickeln. Wieder ein Fall mehr, wo wir Enduser diese M$-Selbstherrlichkeit ausbaden.
Umso schöner, da nun mal etwas Licht ins Dunkel zu bringen. Danke dafür.
Grüße Biber
mal zwischendurch ein paar Rückmeldungen zu diesem allerbesten Sahne-Thread.
Erstmal vielen Dank für die Mühe, die Du Dir machst, hier mal ein paar Gegenmittel einzusetzen gegen die sich krebsartig ausbreitenden 0-Byte-Registry-Keys. Wie sich die auch ohne großartige Programmierkenntnisse erzeugen lassen, scheint sich ja auch schon in Scriptkiddie-Kreisen rumgesprochen zu haben..
Folgende Anmerkungen:
- in dem Reghide.c-Source sind Dir durch HTML-Tags die beiden Standard-Include-Dateien
windows.h und stdio.h verloren gegangen. Könntest Du noch mal editieren vielleicht.
- beim Link der ZipHidden.rar wird bei mir nur eine ZipHidden.exe entpackt, und die ist ist nicht sonderlich geschwätzig. Oder ist mein WinRar zu alt? Sollte da nicht Source dabei sein?
- die RegDelNull funktioniert bestens. Wurde auch bei mir gleich fündig.
- was ich in diesem Thread vermisse, ist noch mal der deutliche Hinweis, dass das ganze Elend mit diesen 0-Byte-Registry-Keys dadurch entstanden ist, dass M$ nur den unbedingt nötigen Bodensatz der native API-Calls nach außen dokumentiert hat... und ich wette eine Kiste Becks, dass die ersten 0-Byte-Registry-Keys "aus Versehen", durch falsche Parameter entstanden sind und nicht bei dem Versuch, einen "Installationsschutz" zu entwickeln. Wieder ein Fall mehr, wo wir Enduser diese M$-Selbstherrlichkeit ausbaden.
Umso schöner, da nun mal etwas Licht ins Dunkel zu bringen. Danke dafür.
Grüße Biber
Hallo!
Zunächst Lob an diese Seite und an den Autor. Ich habe sie gefunden, nachdem ich auf meinem Rechner einen 0-Byte Schlüssel ausfindig gemacht habe.
Meine Frage an den Autor und an alle, die sie sich auskennen ist, wie gefährlich ist so ein 0-Byte Schlüssel von O&O Defrag. Ich habe dieses Programm als Testversion benutzt und es dann deinstalliert. Der Schlüssel ist natürlich geblieben. Allgemein gefragt, sind 0-Byte Schlüssel, sofern sie von normalen Programmen stammen und keine bösartigen Sachen verstecken, gefährlich ??? Muss man sie überhapt löschen??? Ist das notwendig???
Ihr siehr schon an den Fragen, ich habe absolut keine Ahnung, was die Tiefen des Betriebssystems angeht, aber die Fragen muss ich einfach stellen.
Grüsse an Alle!!!
Zunächst Lob an diese Seite und an den Autor. Ich habe sie gefunden, nachdem ich auf meinem Rechner einen 0-Byte Schlüssel ausfindig gemacht habe.
Meine Frage an den Autor und an alle, die sie sich auskennen ist, wie gefährlich ist so ein 0-Byte Schlüssel von O&O Defrag. Ich habe dieses Programm als Testversion benutzt und es dann deinstalliert. Der Schlüssel ist natürlich geblieben. Allgemein gefragt, sind 0-Byte Schlüssel, sofern sie von normalen Programmen stammen und keine bösartigen Sachen verstecken, gefährlich ??? Muss man sie überhapt löschen??? Ist das notwendig???
Ihr siehr schon an den Fragen, ich habe absolut keine Ahnung, was die Tiefen des Betriebssystems angeht, aber die Fragen muss ich einfach stellen.
Grüsse an Alle!!!
Moin demann2003,
Da muss man/frau sicherlich unterscheiden zwischen diesem konkreten O&O-Defrag-Schlüssel und anderen, die diese 0-Byte-Schlüssel-Mimik nutzen.
Der O&O-Eintrag war sicherlich nur als kleiner Insiderwitz des Entwicklerteams gedacht, bestenfalls noch als Installationsschutz gegen dauerhafte Shareware-Nutzung.
Der macht eigentlich nichts kaputt, stört nur diejenigen, die sogar in der Registry auf gewisse Ästhetik achten.
Aber, was ich zumindest fahrlässig finde an diesem kleinen Gag der O&O-Truppe: Keiner von denen hat sicherlich getestet, ob alle anderen Registry-Bearbeitungs-Utilities damit umgehen können.
Stell Dir vor, Du lässt einen der üblichen Registry-Cleaner oder sogar ein original M$-Tool zum Komprimieren/Sichern/Archivieren Deiner Registry laufen... und das Programm stürzt wegen dieses nicht vorgesehenen Eintrags ab.
Oder schlimmer - Du sicherst Deine Registry OHNE Fehlermeldung und Monate später, wenn Du sie mal brauchst, lässt sie sich nicht zurücksichern wegen dieses kleinen Gags.
Genau diesen mögliche Datenverlust oder ähnliche Seiteneffekte bin ich nicht bereit zu riskieren oder zu tolerieren.
So etwas tut man/frau einfach nicht - ich würde auch nie von anderen Programmen erwarten, dass sie so robust sind wie meine eigenen
...und ein anderes Programm so auf eine Mine laufen zu lassen, ist einfach kein guter Stil. (Ich hoffe, die O&O-Entwickler haben jetzt einen hochroten Kopf).
Und dazu kommt ja noch, das vielleicht die O&O-Hansels sauber programmiert haben - aber das kann ich nicht von den 13jährigen Skript-Kiddies erwarten, die so etwas auch in ihre zusammenkloppten Erstlings-Skripte einbauen.
Ich kann es nur vergleichen mit älteren Kopierschutzmechanismen, die frecherweise und ungefragt auf der Festplatte des Benutzers Sektoren als "ungültig" markiert haben, um ihre geheimen Lizenzdaten dort hineinzuschreiben, oder an die Spielchen mit ungültigen Zeichen im Dateinamen (was bei M$-Defrag zu einem "Berichtigen" aller untergeordneten Verzeichnisse führt) oder -aktuelleres Beispiel- ein Kopierschutz bei CDs, der dazu führt, dass legal gekaufte CDs nicht gelesen werden können, weil die Verzeichnisstruktur von "guten" Programmen als ungültig interpretiert wird.
Hoffe, es beantwortet Deine Frage
Biber
wie gefährlich ist so ein 0-Byte Schlüssel von O&O Defrag..
Der O&O-Eintrag war sicherlich nur als kleiner Insiderwitz des Entwicklerteams gedacht, bestenfalls noch als Installationsschutz gegen dauerhafte Shareware-Nutzung.
Der macht eigentlich nichts kaputt, stört nur diejenigen, die sogar in der Registry auf gewisse Ästhetik achten.
Aber, was ich zumindest fahrlässig finde an diesem kleinen Gag der O&O-Truppe: Keiner von denen hat sicherlich getestet, ob alle anderen Registry-Bearbeitungs-Utilities damit umgehen können.
Stell Dir vor, Du lässt einen der üblichen Registry-Cleaner oder sogar ein original M$-Tool zum Komprimieren/Sichern/Archivieren Deiner Registry laufen... und das Programm stürzt wegen dieses nicht vorgesehenen Eintrags ab.
Oder schlimmer - Du sicherst Deine Registry OHNE Fehlermeldung und Monate später, wenn Du sie mal brauchst, lässt sie sich nicht zurücksichern wegen dieses kleinen Gags.
Genau diesen mögliche Datenverlust oder ähnliche Seiteneffekte bin ich nicht bereit zu riskieren oder zu tolerieren.
So etwas tut man/frau einfach nicht - ich würde auch nie von anderen Programmen erwarten, dass sie so robust sind wie meine eigenen
...und ein anderes Programm so auf eine Mine laufen zu lassen, ist einfach kein guter Stil. (Ich hoffe, die O&O-Entwickler haben jetzt einen hochroten Kopf).
Und dazu kommt ja noch, das vielleicht die O&O-Hansels sauber programmiert haben - aber das kann ich nicht von den 13jährigen Skript-Kiddies erwarten, die so etwas auch in ihre zusammenkloppten Erstlings-Skripte einbauen.
Ich kann es nur vergleichen mit älteren Kopierschutzmechanismen, die frecherweise und ungefragt auf der Festplatte des Benutzers Sektoren als "ungültig" markiert haben, um ihre geheimen Lizenzdaten dort hineinzuschreiben, oder an die Spielchen mit ungültigen Zeichen im Dateinamen (was bei M$-Defrag zu einem "Berichtigen" aller untergeordneten Verzeichnisse führt) oder -aktuelleres Beispiel- ein Kopierschutz bei CDs, der dazu führt, dass legal gekaufte CDs nicht gelesen werden können, weil die Verzeichnisstruktur von "guten" Programmen als ungültig interpretiert wird.
Hoffe, es beantwortet Deine Frage
Biber
sysinternals wurde 2006 LEIDER (!!) von Microsoft geschluckt (oder annektiert, wie ihr wollt) und nun findet sich regdelnull hier:
http://technet.microsoft.com/de-de/sysinternals/bb897448(en-us).aspx
http://technet.microsoft.com/de-de/sysinternals/bb897448(en-us).aspx
schon besser... und es freut mich dass du beeindruckt bist.. -- bei archive.org sind sie wohl irgendwie am arbeiten.. am sonntag gab es noch mehrere kopien der seite, jetzt nur noch eine, (und diese (wie auch schon sonntag) muss älter als 2011 sein..). -- mein hinweis war auch mehr so an den ersteller der anleitung gerichtet.. bzw an den admin der ganzen seite, denn dann ist anzunehmen dass der zeichenfrass noch andere artikel betroffen hat. -- muss wohl ein PM schreiben?
gute Frage, ich sehe dich auch nur noch alle zwei Jahre hier . Aber schön zu wissen, dass du noch aktiv bist...hast mich anfangs durch viele Probleme geleitet. Aber kurz mal BTT :
Die Anleitung kam vor dem neuen Release, von daher ist es nicht verwunderlich, dass da /r /t und so flöten geht...oder auch die komplette Formatierung.
<<So, bin wieder zurück. Manchmal dauert's halt ein bißchen, ist halt ein asynchrones Medium. Anti Hackerz Book - wtf..? :D>>
kein Witz. Ich hab das Buch vor einigen Jahren gelesen und hier stehen. Zitat müsste ich raussuchen, aber DU bist definitiv gemeint ^^
Mit freundlichen Grüßen
Mitchell
Die Anleitung kam vor dem neuen Release, von daher ist es nicht verwunderlich, dass da /r /t und so flöten geht...oder auch die komplette Formatierung.
<<So, bin wieder zurück. Manchmal dauert's halt ein bißchen, ist halt ein asynchrones Medium. Anti Hackerz Book - wtf..? :D>>
kein Witz. Ich hab das Buch vor einigen Jahren gelesen und hier stehen. Zitat müsste ich raussuchen, aber DU bist definitiv gemeint ^^
Mit freundlichen Grüßen
Mitchell