Virtuelles Laufwerk oder Datei verteckt anlegen und starten

[Riese]

Hallo!

Ich schreibe gerade einen Download-Manager als Zusatzkomponente für unsere Software.
Ich prüfe, ob auf dem Server eine neue Datei vorhanden ist. Falls ja wird diese runtergeladen.
Und jetzt kommts:
Die heruntergeladene Datei soll direkt mittels ShellExecute etc. aus meiner Applikation gestartet werden. Kein Problem, aber ich möchte die heruntergeladene Datei NICHT auf der Platte ablegen.
Also auch nicht im temp-Ordner. Sie könnte dort nach/während dem Start vom Benutzer kopiert werden und das darf nicht sein.
Meine Idee. Die Datei irgendwie in den Arbeitspeicher (virtuelles (nicht angezeigtes) Laufwerk etc.) kopieren und dort starten.
Geht sowas und wenn ja wie?

Gruß
Riese

[Olli]

Ähem ... okay. Und wie hinderst du den Benutzer es aus dem Speicher zu dumpen?

Unter Umgehung aller höheren OS-APIs kann man das erreichen (ohne Ablegen auf der Platte), ob man damit aber den Benutzer daran hindert etwas zu kopieren, wage ich anzuzweifeln.

Außerdem riecht mir das leicht nach Malware ...

Schonmal dran gedacht den Benutzer mithilfe der Rechte auf die Datei daran zu hindern sie zu kopieren?

Nachtrag: Virtuelle Laufwerke benötigen meistens einen Treiber um zu funktionieren. Die Tatsache, daß dein Laufwerk keinen Laufwerksbuchstaben hat, bedeutet aber lange nicht, daß es nicht zugreifbar ist. Selbst von Win32 aus kann jeder Benutzer sich das Gerät auf einen freien Buchstaben mappen und dann auf die Datei zugreifen.

[Riese]

Danke für Deine schnelle Antwort,

Zitat von Olli:

Ähem ... okay. Und wie hinderst du den Benutzer es aus dem Speicher zu dumpen?

OK, ganz verhindern kann man so was natürlich nicht, aber es dem Otto-Normal-User zumindest verwehren.

Zitat von Olli:

Außerdem riecht mir das leicht nach Malware ...

Riecht es vielleicht, ist es aber nicht.

Zitat von Olli:

Schonmal dran gedacht den Benutzer mithilfe der Rechte auf die Datei daran zu hindern sie zu kopieren?

Dies geht nur unter NTFS (zumindest meines Wissens nach) und viele unserer Kunden haben noch das FAT32 System.

Zitat von Olli:

Nachtrag: Virtuelle Laufwerke benötigen meistens einen Treiber um zu funktionieren.

Ja, leider. Ich möchte auch keinen Treiber programmieren aber ich dachte es gibt vielleicht etwas anderes als ShellExecute bei dem man keine Datei sondern eine Adresse (z.B. MemoryMappedFile) angeben kann.
Naja, vielleicht hat ja noch jemand eine Idee...

[Olli]

Zitat von Riese:

Ja, leider. Ich möchte auch keinen Treiber programmieren aber ich dachte es gibt vielleicht etwas anderes als ShellExecute bei dem man keine Datei sondern eine Adresse (z.B. MemoryMappedFile) angeben kann.

Darauf liefe meine andere Idee hinaus. Dabei müßtest du Importe selbst auflösen, den PEB und den TEB vorbereiten usw. usf. ... alles nicht so einfach.

Weswegen willst du es denn überhaupt verhindern? Warum lädst du nicht bspw. eine DLL von dem entfernten Server (unter der Annahme, daß du per FS darauf zugreifst) und hast diese dann eben in deinem Prozess. Die DLL kann doch sicher das gleiche leisten wie eine "normale Anwendung".

[Riese]

Zitat von Olli:

Darauf liefe meine andere Idee hinaus. Dabei müßtest du Importe selbst auflösen, den PEB und den TEB vorbereiten usw. usf. ... alles nicht so einfach.

Oh je, klingt schwierig, ...

Zitat von Olli:

Weswegen willst du es denn überhaupt verhindern? Warum lädst du nicht bspw. eine DLL von dem entfernten Server (unter der Annahme, daß du per FS darauf zugreifst) und hast diese dann eben in deinem Prozess. Die DLL kann doch sicher das gleiche leisten wie eine "normale Anwendung".

Ja, aber die herunterladbare Anwendung ist schon fertig (als exe). Es soll aber nach einem Download nur gestattet sein diese 1 x zu starten. Ein doppelter Start könnte Datenbanken die dabei konvertiert werden zerstören, ...

[Olli]

Schwierig schwierig. Ich hätte ja Streams (ADS) vorgeschlagen, aber die gibt's für FAT32 nicht (nur FAT12 und FAT16).

Ich befürchte, daß du wirklich auf jemanden mit einer anderen Idee warten mußt ...

[SirThornberry]

Also wenn du das ganze als DLL runterlädst (wie bereits vorgeschlagen) kannst du doch eigentlich erreichen das die Datei nur einmal ausgeführt wird. Du lädst also die DLL herunter und lädst diese mit LoadLibrary. Dann kannst du in der DLL deine eigentliche Funktion ja aufrufen (mit irgendwelchen tollen Parametern)

[jim_raynor]

Zitat von Riese:

Ja, aber die herunterladbare Anwendung ist schon fertig (als exe). Es soll aber nach einem Download nur gestattet sein diese 1 x zu starten. Ein doppelter Start könnte Datenbanken die dabei konvertiert werden zerstören, ...

Dafür gibts aber wesentlich einfachere Möglichigkeiten, um den Mehrfachstart zu verhindern.

Zum Beispiel über Semaphoren:

Delphi-Quellcode:

  
var
  SH_Sem    : HWND;
  SH_Ins    : boolean;

.
.
.

  SH_Sem:=CreateSemaphore(nil,0,1,'ein belibiger eindeutiger Text');
  SH_Ins:=(SH_Sem<>0) and (GetLastError=ERROR_ALREADY_EXISTS);
  If SH_Ins then
  begin
    CloseHandle(SH_Sem);
    exit;
  end;

Das in die .dpr datei rein vor Application.Initialize.

Dann noch die Unit Windows ins Projekt einbinden und fertig ... Damit wird eine Semaphore angelegt, die in der Sitzung einzigartig ist. Beim zweiten start erhählt man dann über GetLastError die Info, dass diese schon exisistiert und man weiß, dass Programm bereits läuft ...

Aber ehrlich. Wenn dein Programm so unsicher ist, dass es bei zweifachen Start die Datenbank zerstört, dann ist irgendwas nicht so recht schön ...

[SirThornberry]

@jim_raynor: Es geht nicht darum zu verhindern das eine Datei merhfach gleichzeitig läuft sondern darum sicherzustellen das ein Programm nur ein einziges mal ausgeführt wird und dann nie wieder.

[jus]

Wie wärs wenn du die Datei einfach verschlüsselst oder zumindest Teile davon dann von deinem Server runterlädst und die Datei erst entschlüsselst und dann startest, nach dem Starten, kann es ja auch dann sofort gelöscht werden.
Dann könnte der Benutzer zwar die Datei kopieren, kann aber nix mit der verschlüsselten Datei anfangen.
Man kann das Spiel ja noch weiter treiben und das Passwort der Verschlüsselung an das derzeitige Sessionkey binden, sprich das Passwort/Verschlüsselung ist nur für diese einmalige Session gültig und wird vom Server zu deinem Programm mitgeteilt, dann brauchst du in deinem Programm das Passwort nicht mitspeichern, usw... der Aufwand ließe natürlich noch weitertreiben aber....naja....

Lg,
jus