'Wirklich' nicht sichtbare Verzeichnisse

[himitsu]

Oder als Ressource in die EXE, bzw. eine DLL?

eigene .RES erstellen,
eigene .RC und manuell zur .RES kompilieren,
oder automatisch die .RES kompilieren lassen
und via {$R ...} bzw {$RESOURCE ...} einbinden.

oder über den Ressourcen-Manager in die Projekt-.RES bzw. .DRES.

Diese könnte man zur Laufzeit z.B. im TEMP-Verzeichnis speichern. (bzw. siehe letzte Zeile)



Und dann gibt es massenhaft Möglichkeiten darauf zuzugreifen
TResourceStream
TBitmap.LoadFromResourceName
LoadString (siehe auch resourcestring)
LoadResource
CreateIconFromResource
uvm.

Und es gibt sogar ein res://-Protokoll.
http://delphidabbler.com/articles?article=10

[Alallart]

@creehawk

Was du dir wünscht ist der Traum jeder Virus-Software. Ordner die tatsächlich versteckt sind und die niemand sieht. Selbst der Profi nicht. Ich glaube nicht, dass es so was gibt.

Was aber bedingt funktionieren könnte wäre u. U. ein zu langer Pfad.

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.

Mit Tricks kann man dennoch auf die Datei jenseits der MaxPath-Länge zugreifen. Einfach einen Ordnernamen kürzen.

Andererseits ist das keine sichere Angelegenheit. Manchmal klappt das, manchmal nicht.


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 habe es mal was vor 20 Jahren darüber gelesen, mich aber in der Zwischenzeit nicht mehr darum gekümmert. Was ich aber im Kopf behalten habe ist, dass man damit Daten verstecken, oder schwer auffindbar machen kann. Vielleicht weiß einer hier mehr darüber.

[himitsu]

Zitat von Alallart:

Ich glaube nicht, dass es so was gibt.

Das gibt es, aber du willst es nicht, da dich sonst zurecht jeder dafür lynchen wird.

Es gab mal den ProtectedStorage in Windows, aber ist auch schon wieder tot.

[TurboMagic]

Unter Windows 3.11 (genauer DOS) konnte man einen ordner mit ASCII Zeichen 255,
eine Art spezielles Leerzeichen anlegen (oder sogar mit mehreren drin).

Rein kam nur, wer DOS Befehle kannte, denn der Windows Dateimanager ist beim Zugriffsversuch
dann immer schnurstracks ins Stammverzeichnis des betreffenden Laufwerks gegangen

[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.

[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.