'Wirklich' nicht sichtbare Verzeichnisse

[creehawk]

Moin Moin.

Es gibt viele PC Spiele die beim installieren enorme gepackte/verschlüsselte Datenmengen auf den PC platzieren, die bei Spielstart entpackt/entschlüsselt werden. Entpackt/entschlüsselt man die Spieldateien zu Fuß und sieht sich die Dateien an (XML) finden sich ganz normale Pfadangaben zum beispielsweise Grafikdateien. Was für mich dann heißt: es werden ganz normale Verzeichnisse angelegt und verwendet. Also sollten Sie wenn das Spiel läuft ja wohl zu finden sein. Sind sie aber nicht.

Wie kann ich derartiges mit Delphi erzeugen, also Verzeichnisstrukturen die NICHT im Explorer zu finden sind aber die mein Programm verwendet wie normale Verzeichnisse?

creehawk

P.S. Falls das schon irgendwo abgehandelt wurde: ich habe keine Ahnung wonach ich da suchen soll.....

[jfheins]

Da gibt es natürlich mehrere Möglichkeiten. Was mir gerade so einfällt:

- Ganz normale Dateien benutzen und dann dafür sorgen, dass sie versteckt werden. Einerseits schwierig, andererseits arbeiten manche Anti-Cheats schon sehr low level sodass das möglich wäre.
- Dateien verwenden, die ohnehin nicht angezeigt werden. Ich denke hier an alternate data streams oder das Flag "Systemdatei"
- Dateien nicht direkt verwenden. Man kann ja auch nur eine Datei auf der SSD ablegen, in der dann die ganzen Dateien gespeichert werden. Sei es als tar, zip, vhd oder ein eigenes Format.

[creehawk]

Moin Moin.

So ganz werde ich aus deiner Info nicht schlau.

Also das Systemdatei/Hidden Flag ist gar keine Option, kann ja jederzeit umgangen werden. 'Dateien nicht direkt verwenden?' Verstehe ich gar nicht.

Ich möchte für den normalen Anwender Verzeichnisse definitv nicht sichtbar machen. Dabei aber so verwenden wie normale Verzeichnisse.

creehawk

[jfheins]

Die dritte Option ist ein virtuelles(?) Dateisystem. Also du erzeugzt aus deinen Dateien eine zip-Datei und schreibt in deiner Anwendung Code, der diese öffnet und alle folgenden Anfragen für Dateien aus der zip-Datei bedient, wenn verfügbar. (zip lässt sich natürlich ersetzen durch was anderes wie z.B. VHD)

Mit "Dabei aber so verwenden wie normale Verzeichnisse." geht das natürlich nicht zusammen. das Dateisystem unterscheidet normalerweise einfach nicht zwischen deinem Programm und dem Explorer.

Du hast da übrigens einen deutlichen Widerspruch:

Zitat:

Also das Systemdatei/Hidden Flag ist gar keine Option, kann ja jederzeit umgangen werden.

Andererseits:

Zitat:

Ich möchte für den normalen Anwender Verzeichnisse definitv nicht sichtbar machen.

Der normale Anwender wird die Dateien mit System flag nicht finden. Und vor Experten wirst du sie nicht verstecken können.

Bleibt die Zwischenlösung: ADS. Kann dein Programm ganz normal verwenden, sieht man aber nicht im Explorer.
Siehe Anhang - man beachte den Doppelpunkt im Dateinamen.

[Bernhard Geyer]

Eldos hatte mal so ein "Virtuelles File System".
https://www.greymatter.com/EldoS-Cor...SoIFS)/1038394
Da aber Eldos über die Jahre verkauft wurde müsstest du jetzt auf die suche gehen wo aktuell dies Implementierung zu finden ist.

[jaenicke]

Was dabei tatsächlich abläuft kann man mit Tools wie dem Process Monitor sehen. Einfach den Process Name im Filter auf den Namen der Exe des Spiels setzen und dann sieht man worauf das alles zugreift.

[Der schöne Günther]

Zitat:

Zitat von creehawk (Beitrag 1462891)

finden sich ganz normale Pfadangaben zum beispielsweise Grafikdateien. Was für mich dann heißt: es werden ganz normale Verzeichnisse angelegt und verwendet.

Das ist aber eine mutige Schlussfolgerung.

[Redeemer]

Ich würde vermuten, dass es einen Grund gibt, warum Steam es von 10 Jahren abgeschafft hat, Dateien in einem solchen Archivformat zu speichern. Man sollte sich auch fragen, ob es man es selbst braucht.

Ich habe ein Programm, das bestimmte Grafiken cachet, die der Anwender sieht. Die sind sehr klein, recht viele und haben Namen aus Base64, sodass man sie unter Windows nicht speichern kann. Als Dateiformat habe ich mich damals für 16-Bit RES entschieden. Es hat allerdings kein zentrales Inhaltsverzeichnis und muss daher komplett in den Speicher geladen oder zumindest einmal durchlaufen werden. Für so kleine Dateien geht das. Am einfachsten wäre eigentlich ZIP.

[Benmik]

Ich verwende seit einiger Zeit My Lockbox. Die scheinen das zu machen, was du suchst.

Die Laufwerksbelegung wird im Explorer richtig angezeigt (man sieht also eine Diskrepanz zu den sichtbaren Verzeichnissen) und ein Programm wie Everything, das auf die MFT zugreift, findet auch die Dateien. Will man aber solch eine Datei aus Everything heraus öffnen, wird der Pfad nicht gefunden.

[Dalai]

Zitat:

Zitat von creehawk (Beitrag 1462891)

Also sollten Sie wenn das Spiel läuft ja wohl zu finden sein. Sind sie aber nicht.

Meiner Meinung nach liegst du mit dieser Schlussfolgerung falsch. Denn warum sollte man Dateien nochmal auf einen extra langsamen Datenträger (egal ob HDD oder SSD) packen, nur um sie von dort gleich wieder zu lesen? Klingt umständlich, und ist es IMO auch. Spiele entpacken ihre Daten in aller Regel in den RAM, weshalb sie oft recht hohe Anforderungen an selbigen haben. Vermutlich läuft das per Streams oder sowas in der Richtung.

Grüße
Dalai

[creehawk]

Hossa!

Jede Menge Info, ich danke allen die geantwortet haben.

Vielleicht habe ich das jetzt nicht gut genug erklärt, vielleicht ist meine schlussfolgerung Laienhaft - wie auch immer. Ich werden das jetzt alles mal durchackern und außerdem versuchen eine bessere Frage zu produzieren.

Auf im den Kampf!

creehawk

[creehawk]

Moin Moin.

6:38 Uhr. Alles mal erforscht. Hat nix geholfen Ich formuliere mal um:

Der geneigte Fachmann stelle sich vor:

Ich möchte 3 XML Dateien (10MB) mittels eines Delphiprogrammes benutzen (nur lesen, nicht schreiben). Dies muss geschehen mittels MSXML via XPath, also unter Verwendung von normalen Pfadangaben. Nun soll aber der Anwender nicht in den XML Dateien rumfummeln, aber besten gar nicht wissen das sie da sind, was am elegentesten wäre. Wie also kann ich das veranstalten?
Vielleicht mit einem ähnlichen Konstrukt wie eine TImageList, das heißt die Datei ist komplett im Programm "drin". Oder wie anders? Womöglich stinkeinfach und ich steh' auf'm Schlauch? Oder extra kompliziert?

Im ersten Post hatte ich das so jedenfalls gemeint. Im Spiel Age Of Empires zum Beispiel wird das so gemacht. Jede Menge XML Dateien, zu keinem Zeitpunkt zu sehen. Dies ist nicht meine Schlussfolgerung sondern eine freundliche Info von den EnsembleStudios auf der damaligen Gamescon. (2006?)

Jemand 'ne Idee?


creehawk

[Bernhard Geyer]

XML-Dateien als Ressource in der Exe ablegen -> Nicht als eigen Datei zu sehen.
Dann diese nicht "lesbar" sondern z.B. verschlüsselt ablegen.
Dies werden dann vom Programm entschlüsselt in einen Stream geladen und dort mittels MSXML eingelesen.

[creehawk]

Moin Moin.

Ok, dann probier ich das mal so. Dazu muss ich allerdings erst "streamen" studieren.

Mach ich.:)

creehawk

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

Zitat von Alallart (Beitrag 1463064)

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:

Zitat von Alallart (Beitrag 1463222)

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:

Zitat von creehawk (Beitrag 1463335)

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:

Zitat von Alallart (Beitrag 1463064)

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:

Zitat von Alallart (Beitrag 1463064)

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.

[Assarbad]

Zitat:

Zitat von creehawk (Beitrag 1463335)

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

Eben. Du wiederholst dich und ignorierst geflissentlich zuvor gegebenen Rat und Aussagen anderer Diskutanten in diesem Thema.

So ziemlich jeder größere Spieltitel den ich kenne, beinhaltet irgendeine Form von Archiven. Seien es nun die `.pak`-Dateien von Doom/Prey/... (id Software), oder seien es die Dateien in Drakensang oder Witcher, für die man spezielle Werkzeuge braucht um sie zu entpacken. Mancher Titel "entpackt" die dann wirklich in eine Art Zwischenspeicher für schnelleres Laden, aber andere arbeiten direkt mit den Archiven. Die werden quasi gemountet.

Python hat ein Modul in der Standardbibliothek mit der man direkt aus einer ZIP heraus weitere Abhängigkeiten nachladen kann. Ich selbst habe bereits Code in C geschrieben, der ähnliches tut, weil Deflate nunmal extrem praktisch für sowas ist.

Was in aller Welt bringt dich dazu, dich zu der Aussage zu versteigen, daß diese Verzeichnisse sich irgendwo auf dem Dateisystem in entpackter Form wiederfinden müßten?

Und wenn wir schon dabei sind: wenn es dir darum geht herauszufinden wie das bei einem bestimmten Spiel funktioniert, dann müßtest du schon einen bestimmten Titel angeben. Mit etwas Glück fände sich ein spieleinteressierter und extrem erfahrener Rückentwickler (wie mindestens einer hier im Forum unterwegs ist :mrgreen:) und erbarmt sich, oder andere haben schon Modding-Erfahrungen mit dem Titel ohne Rückentwickler zu sein. Die Frage, so wie sie steht, ist extrem breit. Und wenn es dir aber eben nicht allein darum geht die (vermutete!) Funktionalität in deinem Programm umzusetzen, sondern darum wie das irgendwo umgesetzt ist, dann ist dieses gesamte Thema hier aber im falschen Unterforum.

[Alallart]

@creehawk

Oder du mountest das Verzeichnis als Laufwerk. Du hast dann Pfade die sonst wo sind, aber weil sie gemountet sind, so tun als ob sie irgendwo anders wären. Das versteckt dein Verzeichnis nicht wirklich, aber wenn du Glück hast, ist derjenige wenigstens zwei Minuten verwirrt.

[himitsu]

Alallart meint es bestimmt andersrum.

Datei bzw. Laufwerk/Partition als Verzeichnis mounten, weil ein Laufwerk/Buchstabe im Windows zu finden wäre zu einfach.
(ZIP als Unterverzeichnis bzw. ISO als Laufwerk)