Hi Community,

Hatte auf meinem Windows 8.1 x64 vor einiger Zeit etwas mit unmöglichen Dateipfaden und -Namen herumgespielt.
Herausgekommen sind unlöschbare Ordner, nicht zu öffnende Dateien und Abstürze vom Windows-Explorer und Dateidialogen.

Nun wollte ich einen gewöhnlichen Virenscan (mit direktem Festplattenzugriff) durchführen, und musste
im Zuge dessen feststellen, dass alle drei Tools über die komischen Dateipfade stolperten.

Zuerst wollte ich den Scan ganz normal mit Emsisoft (unter Verwendung direkten Festplattenzugriffs)
durchführen, wobei mir der Scanner aus dem EEK nach einiger Zeit abstürzte. Nach einigen weiteren Abstürzen war klar, dass dafür
nur die verbogenen Dateipfade in Frage kommen.
Um den Scan dennoch durchführen zu können, schloss ich den (die)
betreffenden Dateipfad(e) in Emsisoft aus. Da das Tool nach wie vor abstürzte, versuchte ich die Probleme mit BlitzBlank aus dem Weg zu schaffen.
Dabei verlangte das Tool einen Neustart, den ich gewährte, und blieb dann für unendliche Zeit hängen, bevor ich? es abstürzte.

Den Neustart führte ich danach manuell aus, wonach aber trotzdem kein einziger der problematischen Pfade beseitigt worden war.
Mit der Fix-Funktion von FRST64 versuchte ich dann die betreffenden Ordner manuell zu löschen.
Die Ordner mit der Tiefe von ~16000 Unterverzeichnissen konnte FRST64 noch problemlos verschieben (wie löscht man die Quarantäne dann eigentlich?),
interessanter wurde es dann bei einem Pfad des Typs "C:\ \(weitere Unterordner)\".

In der Fixlist stand "C:\ \" (ohne Anführungszeichen). FRST64 interpretierte dies wohl irgendwie komisch und begann daraufhin
meinen Desktop zu löschen (verschieben), bis ich es merkte und den PC abstürzte.
Ich benannte den ersten Ordner "C:\ \" mit einem Spezialtool um, wonach FRST64 ihn endlich löschen konnte.
Das Ausschliessen von C:\FRST brachte im EEK aber nur wenig, der Scanner stürzte immer noch ab.
Dass die Probleme vom Dateisystem und nicht von anderen Komponenten kamen, zeigte sich am problemlosen Scannen mit genau gleichen Einstellungen von nur "C:\Windows" alleine.
Ich vermutete daher, dass der Emsisoftscanner auch über die ebenfalls in C: liegenden Dateien
mit Namen wie ".YncrèdybleFile " (teilweise inkl. ADS) stolperte und versuchte die Dateien mit FRST64 zu löschen.

Dies schlug jedes Mal fehl, egal ob mit oder ohne Anführungszeichen, mit oder ohne vorangestelltes \??\ und trotz Zulassen von Neustarts.
Ein weiterer Löschversuch von C:\ \gmer.log zeigte, dass FRST64 offenbar Probleme mit Leerzeichen an unerwarteten Stellen hat.
Die Datei liess sich dann auch mittels Neustart nicht entfernen.
Nun setzte ich das neueste Malwarebytes Antimalware inkl. Updates auf den C:\FRST-Quarantäneordner mit den unmöglichen Pfaden darin an.
Einstellungen waren Standard + Rootkit.
Malwarebytes blieb nach kurzer Zeit ebenfalls hängen und schien mehr als 7 Minuten an einer Textdatei herum zu scannen, bevor ich es abstürzte.

Offensichtlich rühren die Probleme daher, dass ich Pfade erzeugt habe, die für die normale Win32-API ungültig sind, und folglich reagieren die Tools seltsam oder unerwartet.
Da stellt sich jetzt natürlich die Frage: Muss das so bzw. ist das Problem bekannt, oder mache ich etwas grundsätzlich verkehrt?


Grüsse - Microwave

wie löscht man die Quarantäne dann eigentlich?

einfach C:\FRST löschen. Sollte das mal scheitern gibt es nen Schalter um die Quarantäne vorab zu löschen.

soviel vorab, mehr wenn ich mehr zeit hab

Für "unsere" Tools gibt es delfix

Die Reihenfolge ist hier entscheidend.

1. Falls Defogger benutzt wurde: Defogger nochmal starten und auf re-enable klicken.
2. Falls Combofix benutzt wurde: (Alternativ in uninstall.exe umbenennen und starten)
   • Windowstaste + R > Combofix /Uninstall (eingeben) > OK
   • Alternative: Combofix.exe in uninstall.exe umbenennen und starten
   • Combofix wird jetzt starten, sich evtl updaten und dann alle Reste von sich selbst entfernen.
3. Downloade Dir bitte auf jeden Fall DelFix auf deinen Desktop:
   • Schließe alle offenen Programme.
   • Starte die delfix.exe mit einem Doppelklick.
   • Setze vor jede Funktion ein Häkchen.
   • Klicke auf Start.
   • Hinweis: DelFix entfernt u. a. alle verwendeten Programme, die Quarantäne unserer Scanner, den Java-Cache und löscht sich abschließend selbst.
   • Starte deinen Rechner abschließend neu.
4. Sollten jetzt noch Programme aus unserer Bereinigung übrig sein kannst du sie bedenkenlos löschen.

Danke für die Antworten erst mal:
Habe versucht den Quarantäneordner zu löschen mit FRST64, diversen Spezialtools (u.a. Gmer) und mit Delfix.

Ergebnisse:
- FRST64 stürzt nach einiger Zeit wegen eines Stackoverflows ab
- Gmer und einige Spezialtools tun so, als würden sie den Ordner löschen, nach Neustart der Tools ist der Ordner allerdings nach wie vor vorhanden,
- Delfix löscht den Ordner laut Liste, im Explorer ist er aber nach wie vor zu sehen.

Jetziger Stand: Nur der Quarantäneordner mit den ungültigen Pfaden ist noch immer vorhanden, sonst wurde alles entfernt.

Ich glaube, dass das Problem an der gewaltigen Ordnertiefe kombiniert mit den Leerschlägen im Dateinamen liegt.
Momentan sind mir die Ideen daher gerade etwas ausgegangen - das Problem lässt sich vermutlich einzig und alleine mit direktem NTFS-Zugriff beheben, wenn keine Neuinstallation erfolgen soll.
Bin zur Zeit allerdings ziemlich ausgelastet, und es ist ja auch nicht wirklich dringlich.


Grüsse - Microwave

P.S. Ein weiterer Scan mit Hitman Pro x64 ergab, dass auch dieses Tool alle Viere von sich streckt.
Da ist also offensichtlich etwas gröber verbogen, ich werde wohl mal chkdsk ausprobieren, ob das etwas meldet/repariert.
Das wiederum wäre allerdings ziemlich interessant, wenn man sich mit einem Usermode-Programm (mit dem ich ja diese unmöglichen Dateipfade erzeugt habe) das Dateisystem vermurksen könnte...

P.P.S. Thread kann gerne in Rubrik "Windows" verschoben werden, da es sich vielleicht doch nur vermeintlich um Kinderkrankheiten der Antimalware-Tools handelt.

Hast du denn diese ungültigen Ordner und Dateien unter Windows erzeugt bzw. ist das möglich? Wenn nein, wird auch Malware das nicht können und deshalb haben Suchprogramme es auch nicht nötig, solche Dinge löschen zu können.
Wenn doch, zweite Frage: Kannst du/kann man ungültig benannte Ordner/Dateien erzeugen, die sich aber unter Windows korrekt benutzen lassen? Wenn nein, sind diese wiederum nicht von Interesse, denn auch Malware muss funktionieren, um zu funktionieren.

Interessant, dass das immer noch ein Problem ist. Ich hab neulich ein Interview mit einem Adware-Programmierer gefunden, der damit schon Mitte der 2000er-Jahre seinen Schrott in der Registry festsetzte (Win NT Unicode-Schlüssel mit null-Bytes, die in der Win32 API mit 8-Bit Zeichensätzen unmöglich waren und mit Regedit nicht gelöscht werden konnten.

philosecurity.org/2009/01/12/interview-with-an-adware-author

Ich hätte eigentlich erwartet, dass die Anti-Malware-Programme mit sowas umgehen können. Vielleicht kommen da auch die Boot-CDs á la Desinfec't (die mit Linux starten) besser mit klar.

Jan 12th, 2009 by sherri

Anfang 2009 ist für dich "Mitte der 2000er Jahre"?

ch hätte eigentlich erwartet, dass die Anti-Malware-Programme mit sowas umgehen können.

Vllt ist das Betriebssystem broken by Design?
Hast du mal über den Tellerrand geschaut was gerade an aktuellen Diskussionen zu systemd und debian ist?
Der Vorteil bisher war doch immer dass systenmlogs nicht in binären Formaten, Datenbanken oder whatever gespeichert wird.

Vielleicht kommen da auch die Boot-CDs á la Desinfec't (die mit Linux starten) besser mit klar.

Vllt glaubst du auch an den Weihnachtsmann?

@Fragerin: Ja, ich habe die Dateien und Pfade rekursiv erzeugt (einschlägige NtXxx-Aufrufe)und ja es gibt drei Typen von Dateien,
die Windows nicht so gerne mag: Dateien mit Leerschlägen am Ende, Dateien mit einem Punkt am Ende und Dateien mit einer Dateinamenlänge von 255 Zeichen, die sich in einem tieferen Verzeichnis als bloss C:\ befinden.

Zur zweiten Frage kann ich sagen, jein das geht (nicht). Es kommt immer darauf an, was du mit Windows meinst.
Mit den NtXxx-Systemaufrufen lassen sich ungültige Dateien erzeugen, mit denen das Windows-GUI nichts anfangen kann.
Dies bedeutet in der Tat, dass auch Windows-Malware, die "dokumentierte" Dinge tut, wie z.B. den Run-Key benutzen, schöne sichtbare GUIs anzeigen, und den Zugriff auf den Desktop blocken (vgl. GEMA-Trojaner), sich nicht mittels derartiger Dateien verankern kann.
Wesentlich typischer ist es allerdings für schädliche Software, so undokumentierte Dinge wie möglich zu tun, und da wird auch vor speziellen Systemaufrufen nicht halt gemacht.
Wie du siehst, könnte Malware somit dennoch schwerlöschbare Ordner und Dateien anlegen, einfach nicht über's GUI.

Interessanter ist jedoch die Tatsache, dass Dienste vom Typ "Systemstart" und "Bootstart" ebenfalls von Pfaden geladen werden können, mit denen das UI nichts anfangen kann, da dazu intern ebenfalls native Aufrufe verwendet werden.
Das macht es also möglich, eine ".YncrèdybleFile " im C: abzulegen, die zwar in den Systemkern geladen wird, aber nicht so ohne Weiteres entfernt werden kann.
Mittels 16000 Verzeichnisse tiefem Ordnersystem, das den Namen " " trägt, könnte der Virenscanner dann gerade noch endgültig zum Abstürzen gebracht werden.
Ist in der Theorie also durchaus möglich.
Desweiteren ist es ganz einfach, den kaum verwendeten Treibereintrag "system32\drivers\parport.sys" auf "system32\drivers\parport.sys "
umzubiegen, und nachher auch wirklich eine "parport.sys " ins Verzeichnis zu kopieren.
Ergebnis: Jeglicher Zugriff auf "parport.sys " endet auf "parport.sys" (man markiert "parport.sys " und will sie
löschen, Windows fragt aber, ob man "parport.sys" löschen möchte), der Kernel lädt aber dennoch die "parport.sys ".
Der Schleier fällt erst, wenn die parallele Schnittstelle spinnt, weil der Eintrag auf "parport.sys " verweist, aber der theoretisch erforderliche Treiber "parport.sys" wäre.

Ich hatte das vor einiger Zeit mal ausprobiert und wie erwartet hat FRST64 0.00% gemeckert, obwohl schön jedes Mal die falsche parport.sys ("parport.sys ") geladen wurde.
Windows hat auf die Anfrage von FRST64 "Hey Windows, trägt die Datei "parport.sys "" eine gültige digitale Signatur?" nämlich einfach geantwortet: "Ja, selbstverständlich ist "parport.sys" gültig signiert!", wonach die Datei gewhitelisted wurde.
Die falsche "parport.sys " hat sich dann noch selber versteckt (Treiberobjekt von den Laufwerken umgebogen), womit die Welt in Ordnung zu sein schien.
In diesem Falle erkannte Malwarebytes das Ganze allerdings als "Rootkit.Driver", die Entfernung klappte ebenfalls.
Spannend wäre es im Nachhinein gewesen, wenn man einen tiefen Ordner " " ebenfalls im Drivers-Verzeichnis platziert hätte, womit MBAM jedes Mal abgestürzt wäre und der falsche Treiber unendeckt geblieben wäre.. das nur nebenbei.
Einfach aber höchst wirkungsvoll ist auch der Trick, Dateien im C:\$Extend-Verzeichnis zu platzieren, denn dieses - oh Überraschung - ist unsichtbar ohne Verwendung von Spezialmitteln, und auch der Zugriff darauf gestaltet sich eher schwierig.

@bbi2014, der Nullzeichen-Trick ist alt, ja. FRST64 kann damit nicht umgehen, Gmer hingegen zeigt einen "Hidden Service" an, wenn man versucht, auf diese Weise einen Treibereintrag zu verstecken.
Es gibt allerdings weitere offline funktionierende Möglichkeiten (man benötigt keine auffälligen oder verbotenen(->PatchGuard) Hooks), um zumindest
vor Regedit Treibereinträge zu verstecken, die auch GMER nicht dazu veranlassen, Alarm zu schlagen.


Offenbar sind alle diese Modifikationen nicht an geladene Malware gebunden, die Offline-Enfernung dürfte die Tools also mindestens vor die selben Probleme wie bei der Online-Entfernung stellen...


Grüsse - Microwave