'Wirklich' nicht sichtbare Verzeichnisse

[hoika]

Hallo,
zum Streamen
https://www.delphipraxis.net/86728-m...-zu-bloed.html

oder in Google "Delphi MSXml Stream"

[freimatz]

Kann ich unterstüzten. Ich selber packe etliche Dateien in ein zip-Archiv und hole Dateien daraus zur Laufzeit in einen Stream.

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

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