'Wirklich' nicht sichtbare Verzeichnisse

[himitsu]

Auf LowLevel-Ebene arbeiten im Dateisystem und in der Registry viele Funktinen mit einem Strings die eine Längenangabe besitzen, anstatt dem abschließenden #0 ... drim kann man da wie beim Delphi-String auch ein #0 mitten im Namen haben, was dann bei Verwendung der höheren PChar-APIs den Namen abschneidet, also im Explorer und RegEdit nur die Hälfte anzeigt und den Zugriff nicht gewehrt.

"Bösartige" Trojaner/Viren hängen auch gern einen Filter zwischen die APIs und entfernen ihr Verzeichnis aus der Liste.

Tja, aber wer sowas macht, der gehört vollkommen zu Recht gelyncht.

[Alallart]

Da fällt mir gerade noch eine Methode ein, die sehr simpel umzusetzen ist, und die garantiert den Ordnerinhalt versteckt. Das Schlüsselwort ist: Benutzerrechte.

Dazu benötigt man mehrere Benutzerkonten, vorzugsweise ein Administratorkonto und ein normales Benutzerkonto, sowie ein NTFS-Dateisystem. Nehmen wir an wir haben die Benutzerkonten Administrator und Klaus. Wobei das Administratorkonto benötigt man eher nur für den Fall der Fälle, denn auch ein normaler Nutzer kann sich bestimmte Rechte einschränken und wieder geben. Sollte das mit dem wiedergeben nicht klappen, benötigt man dann die Administratorrechte. Oder man will einem anderen Konto die Rechte nehmen, und der soll sich die nicht selbst wiedergeben können. Aber will man sich selbst paar Rechte nehmen, klappt das auch alleine.

Wir sind als Benutzer Klaus angemeldet. Gehen wir jetzt davon aus, dass der Ordner "Test" vorhanden ist und Daten enthält. Jetzt gehen wir in den Daten-Explorer und rufen die Eigenschaften von dem Ordner "Test" auf. Anschließend das Register "Sicherheit" und dann den Button "Bearbeiten" anklickenden. Den Benutzer "Klaus" auswählen. Jetzt noch "Ordnerinhalt anzeigen" und "Lesen" verweigern und OK klicken. Ab jetzt kann man nicht mehr den Inhalt sehen oder lesen.

Da man sich selbst die Rechte genommen hat, kann man sich die selbst wieder geben.

Nur so nebenbei - das ist eine einfache Methode einen Schädling still zu legen, den man lokalisiert hat, ihn aber nicht vom System entfernen kann. Einfach "Lesen" und "Ausführen" Rechte nehmen. Nach dem Neustart kann er nicht mehr ausgeführt werden und kann gelöscht werden.

[Sherlock]

Es versteht sich doch von selbst, daß man einen Windows-Rechner, eigentlich egal welchen Rechner, nicht als root/Admin/Superuser ausführt....oder nicht? Damit sind dann ohnehin die allermeisten Probleme nicht mehr erwähnenswer.

Sherlock

[himitsu]

Man kann sich zur Laufzeit weitere Rechte aktivieren (wenn man das Recht dazu besitzt, oder die Logindaten eines Benutzers hat, der das darf)

und ein ordentliches Setup startet den Prozess nicht mit seinen eigenen vererbten Rechten und dem zum Starten verwendeten Benutzer (z.B. Administrator),
sondern es besorgt sich die Berechtigunen des eingeloggten Benutzers und startet damit das Programm in dessen Umgebung.

[Assarbad]

Also ohne Treiber, der basierend auf einem bspw. irgendwie registrierten Prozeß die Daten "unsichtbar" macht, kommen mir da nur Frickellösungen in den Sinn.

Beispielsweise könnte man die üblichen Beschränkungen für Pfadnamen im Win32-Subsystem umgehen, indem man die nativen Pfade benutzt. Oder man könnte Alternative Data Streams auf NTFS einsetzen. Aber das wäre dann halt NTFS-spezifisch. Allerdings kann man so auch Daten an einen Verzeichnisnamen tackern, ohne daß die als Datei im Verzeichnis erscheinen.

Beschränkungen die mir in den Sinn kämen wäre bspw. der Punkt am Ende eines Namens (egal ob Verzeichnis oder Datei). Allerdings zeigt Windows 10 das in aktuellen Ausgaben schon wieder ohne Probleme an (Explorer und Kommandozeile).

Beispiel:

1. Kommandozeile: echo foobar > \??\%USERPROFILE%\Desktop\Fass_mich_nicht_an.txt.
2. Danach per Notepad oder so die Datei öffnen. Die meisten Programme werden sich beschweren, daß die Datei nicht existiert, oder diese stillschweigend erstellen. Versuche ich bspw. die Datei danach wieder per Notepad zu öffnen kommt "The filename, directory name, or volume label syntax is incorrect." und Notepad++ bietet mir an sie zu erstellen, weil sie angeblich nicht existiert.

Zitat von Alallart:

Wir sind als Benutzer Klaus angemeldet. Gehen wir jetzt davon aus, dass der Ordner "Test" vorhanden ist und Daten enthält. Jetzt gehen wir in den Daten-Explorer und rufen die Eigenschaften von dem Ordner "Test" auf. Anschließend das Register "Sicherheit" und dann den Button "Bearbeiten" anklickenden. Den Benutzer "Klaus" auswählen. Jetzt noch "Ordnerinhalt anzeigen" und "Lesen" verweigern und OK klicken. Ab jetzt kann man nicht mehr den Inhalt sehen oder lesen.

Da man sich selbst die Rechte genommen hat, kann man sich die selbst wieder geben.

Holla die Waldfee, hier sind aber schon ein paar Stolperfallen versteckt.

Es ist semantisch ein kompletter Unterschied, ob man den ACE (Zugriffssteuerungseintrag, ACL = Zugriffsteuerungsliste) auf Zugriff soundso ist abwesend und Zugriff soundso ist explizit verweigert (Deny ACE), setzt. Da Deny-ACEs immer Vorrang genießen wird an der Stelle mit der Zugriffsüberprüfung abgeschlossen wo es einen Treffer gibt. Es gibt also ganz klar einen riesigen Unterschied ob ich explizit den Zugriff verweigere, oder ob ich ihn nicht gebe.

Außerdem kommt es darauf an wer der Eigentümer ist. Sofern man selbst Eigentümer ist, trifft das was du schreibst allgemein zu. Ansonsten wird's problematisch, weil man sich durchaus Rechte entziehen, bzw. verweigern kann und danach nicht mehr an das Objekt rankommt ohne Holzhammermethode.

Einfach mal mit icacls selber austesten ... geht schneller als Klickibunti im Eigenschaftendialog.

[creehawk]

Moin Moin.

So. Ich habe das jetzt soweit hingefrimmelt das ich aus einer Res in ein XML Dokument laden kann. Das entspricht jetzt nicht meiner Grundidee aber dem Ziel.

Und es würde mich doch sehr interessieren was da in diesen Spielen abläuft. Ein paar findige Leute haben Programme geschrieben die die Spieldateien auslesen können und dann in ganz normale Windowsverzeichnise ausgeben. Dann kann man wie gesagt in den ausgepackten XML Dateien etliche Verweise auf ganz normal definierte Verzeichnisse finden. Und die müssen ja nun irgendwo sein. Sind sie aber nicht wie ich schon besagt habe. Ich wiederhole mich.....

Aber bitte, dann stream ich jetzt eben.

creehawk

[freimatz]

Nochmals: wie kommst Du darauf diese die Dateien "in ganz normale Windowsverzeichnise ausgeben"? Nur weil da Strings in XML-Daten drin sind, die wie Dateinamen aussehen, heisst das noch lange dass es dann auch Dateien auf deinem System sind.

[Delphi.Narium]

Zitat von creehawk:

Dann kann man wie gesagt in den ausgepackten XML Dateien etliche Verweise auf ganz normal definierte Verzeichnisse finden. Und die müssen ja nun irgendwo sein. Sind sie aber nicht wie ich schon besagt habe.

Das würde ich jetzt mal nicht so unterschreiben.

Nehmen wir einen Webserver.
Der liefert diverse Dateien.
Die enthalten diverse Links auf weitere Dateien.
Diese Verweise sehen aus wie Verzeichnisse, mehr oder weniger lange Pfade, konkrete Dateien ...
Davon muss aber nix tatsächlich in der Form, wie es den Anschein hat, existieren.
Der Webserver ist "nur" in der Lage, diese Dateien zu liefern, wo er sie tatsächlich herkommt, kann man an den Links nicht erkennen.

Bilder müssen nicht irgendwo in 'nem Verzeichnis liegen, das auch nur annähernde Ähnlichkeiten mit der Verzeichnisstruktur aus dem Link hat, sie könne auch aus 'nem Blob einer Datenbank kommen, PDFs müssen nicht zwingend existieren, sie können auch auf Anforderung generiert werden. U. s. w..

Warum sollten andere Softwareentwickler sowas nicht auch machen.
Wird aus 'ner XML via Verzeichnis-/Dateiname auf was anderes verwiesen, so muss das nicht auf der Platte liegen, sondern kann z. B. aus einer anderen Resource geladen werden.

Wenn ich aus 'ner ZIP eine Datei lade und diese enthält Verweise auf andere Dateien, so müssen diese nicht irgendwo auf 'ner Platte liegen, sondern können ebenfalls im ZIP liegen.

EBooks funktionieren doch auch so:

EPub ist z. B. 'ne ZIP mit der Endung EPub.

Dadrinne sind etliche Konfigurationsdateien und eben die "lesbaren" Inhalte und ggfls. die darin verlinkten Bilder.
Schaut man sich nun die Quelltexte der "lesbaren" Inhalte an (was höchstwahrscheinlich einfach nur HTML ist), so sieht man da auch Links auf die verwiesenen weiteren Seiten, Bilder ...
Aber eine entsprechend Verzeichnisstruktur auf der Platte gibt es nicht. Wird ein entsprechender Link geklickt oder ein Bild per IMG-Tag angefordert, so wird das "entzippt" und angezeigt.

Was hier geht, geht garantiert auch bei 'ner Spielekonfiguration.
Vielleicht nicht als ZIP, sondern in 'nem beliebigen anderen Format, aus Resourcen oder was auch immer die Phantasie der Entwickler dort zustande gebracht hat.

Oder flapsig formuliert:

Was optisch den Anschein eines Verzeichnisses erweckt, muss noch lange kein Verzeichnis sein, es muss nichtmal real existieren.

[Bernhard Geyer]

Zitat von Alallart:

Der gesamte Pfad darf in Windows max. 250 Zeichen lang sein (oder 255, weiß nicht mehr so genau). Das bedeutet aber nicht, dass nicht ein längerer Pfad erzeugt werden kann. Liegt die Datei jenseits der 250 Zeichen, kann Windows nicht immer drauf zugreifen. Der Pfad ist zu lang, wird gekürzt, und dann stimmt er nicht mehr. Problem gelöst, auf Datei kann nicht zugegriffen werden.

Das ist schon seit ca. 2 Jahren (komplett) behoben.
Und die 250/255-Zeichen waren immer die "relative Pfad". Mann konnte sich schon immer auch in Tiefere Pfadangaben "hinhangeln".
Das Problem wird sein das viele Programme mit dem Aufheben der Beschränkung noch nicht zurecht kommen.

Zitat von Alallart:

Dann gibt es noch das RootKit. Ich kenne mich da nicht aus, weiß nur, dass Microsoft vor Jahrzehnten diese Technik eingeführt hat, damit Anbieter ihren Kopierschutz irgendwie verstecken können. Mehr weiß ich aber auch nicht.

Ich denke nicht das MS hier was "eingeführt" hat, sondern das diverse Hersteller versuchen durch trickreiche Verwendung der (teilweise inoffiziellen) WinAPIs sich zu verstecken.
Bei Apple fliegt man mittlerweile für sowas schnell aus allen Programmen raus, wenn man was macht was nicht die offiziellen API entspricht.

[dummzeuch]

Im Prinzip könnte man auch versuchen für den eigenen Prozess diverse Windows APIs zu hooken, z.B. CreateFileW, die dann Zugriffe auf "c:\bla\blub" auf "[applicationdir]\blub" umleiten. Das geht, ich habe das schon mal gemacht, um mit Firebird embedded readonly auf eine gdb-Datei auf einem Netzlaufwerk zuzugreifen (was damals(?) nicht möglich war). Ob das praktikabel ist, hängt davon ab, wie auf die Dateien zugegriffenwird, also wieviele API Funktionen man hooken muss.