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:

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:

Zitat von Olli

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

Riecht es vielleicht, ist es aber nicht.

Zitat:

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:

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:

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:

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:

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:

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

[dahead]

Könnte man nicht irgendeinen Wert in die Registrierung schreiben, dass das Programm bereits gestartet wurde?

Eine andere Idee wäre, in der Datenbank diesen Wert zu hinterlegen und vor dem "Updaten" zu prüfen, ob bereits die aktuelle "Version" vorliegt.

[Vjay]

Also mir fallen zwei mögliche Lösungen ein.

1. Dein Hauptprogramm, welches das andere Programm läd, hat dieses ein Fenster? Wenn ja, registriere dir eine WM_XXX Nachricht, nennen wir sie mal, WM_DARFICHSTARTEN. Sobald die exe ausgeführt wird, sucht sie nach deinem Hauptfenster und verschickt die Nachricht. Dein Hauptprogramm weiss ja über die aktuelle Sachlage bescheid und gibt ein "ok" zurück. Wenn das geladene Programm dein Hauptfenster nicht findet, oder kein ok bekommt -> quit

2. Ich weiss nicht in wie weit ein Hook auf createFile und readFile(ex?) sich auf createProcess auswirken würde. Dazu fehlen mir die Kenntnisse. Andere werden dazu sicher mehr sagen können. Aber ich denke wenn es möglich wäre damit den Lesevorgang "umzubiegen" wäre es vor langer Zeit schon erwähnt worden.

Gruss


*EDIT* @ dahead
Leichen zurück zu lassen ist unschön :(

[Olli]

Zitat:

Zitat von jus

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

:shock: ... wie soll das denn gehen?
a.) kannst du es nicht sicher verschlüsseln ohne sichere Hardware, denn irgendwie muß der Schlüssel auch auf den Rechner des Users gelangen.
b.) wenn die Datei vor dem Starten entschlüsselt wird, kann man sie während der Ausführung kopieren.

Zitat:

Zitat von dahead

Könnte man nicht irgendeinen Wert in die Registrierung schreiben, dass das Programm bereits gestartet wurde?

Eine andere Idee wäre, in der Datenbank diesen Wert zu hinterlegen und vor dem "Updaten" zu prüfen, ob bereits die aktuelle "Version" vorliegt.

Finde ich bisher am besten als Lösung. Problematisch ist das nur dann, wenn sich das (Binär-)Format der Datenbankdateien (oder deren Interface - API) ändert. Aber es in der DB zu hinterlegen ist definitiv am besten. Registry würde ich eher nicht nehmen - Bsp. gefällig? Bei mir ist die Registry auf Partition1, die ich oft mal wieder mit alten Backups überschreibe. Die Datenbank (Daten allgemein) habe ich aber auf Partition2. Nach einer Wiederherstellung eines Backups wäre der Status der Datenbank und in der Registry mglw. "out-of-sync".

Zitat:

Zitat von Vjay

2. Ich weiss nicht in wie weit ein Hook auf createFile und readFile(ex?) sich auf createProcess auswirken würde. Dazu fehlen mir die Kenntnisse. Andere werden dazu sicher mehr sagen können. Aber ich denke wenn es möglich wäre damit den Lesevorgang "umzubiegen" wäre es vor langer Zeit schon erwähnt worden.

Würde sich garnicht auswirken. Intern werden ganz andere Funktionen aufgerufen. Stichwort: Native API.

Zitat:

Zitat von Vjay

Leichen zurück zu lassen ist unschön :(

Leichen? Wo? Hab ich dahead mißverstanden?

[Vjay]

Zitat:

Zitat von Olli

Stichwort: Native API.

Habe ich mir schon gedacht, nu hast du mir jede Hoffnung auf eine bessere Welt genommen.

Zitat:

Zitat von Olli

Leichen? Wo? Hab ich dahead mißverstanden?

Naja ich ging irgendwie davon aus, dass er in die Registry schreibt dass jenes Programm bereits ausgeführt wurde = ein Eintrag mehr. Mir ist klar das das "nichts" ist, aber mich stört der Gedanke der Verunreinigung.

[Olli]

Zitat:

Zitat von Vjay

Naja ich ging irgendwie davon aus, dass er in die Registry schreibt dass jenes Programm bereits ausgeführt wurde = ein Eintrag mehr. Mir ist klar das das "nichts" ist, aber mich stört der Gedanke der Verunreinigung.

Achso. Ich ging davon aus, daß er sozusagen die aktuelle Datenbankversion in sowas wie einem REG_DWORD oder REG_BINARY abspeichert. Aber selbst das ist, wie man oben nachlesen kann, nicht hundertprozentig praktikabel, weil man ja Registry und Datenbank synchron halten muß.

[jus]

Zitat:

Zitat von Olli

Zitat:

Zitat von jus

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

:shock: ... wie soll das denn gehen?
a.) kannst du es nicht sicher verschlüsseln ohne sichere Hardware, denn irgendwie muß der Schlüssel auch auf den Rechner des Users gelangen.
b.) wenn die Datei vor dem Starten entschlüsselt wird, kann man sie während der Ausführung kopieren.

zu a.) und b.)
Zuerst nehme ich an, dass auch der Downloadmanager von Riese selbst entwickelt wird und der Downloadmanager die Update-Datei selber runterlädt. Ich hatte mir eigentlich vorgestellt, der Server verschlüsselt Teile/ganze Datei mit einem Passwort bevor die Datei verschickt wird. Dann schickt der Server das Passwort mit der Datei dem Downloadmanager, damit der Downloadmanager nicht immer dasselbe statische Passwort verwendet(ok muss nicht unbedingt sein :wink: ). Wenn der downloadmanager die Datei fertigruntergeladen hat, dann werden heruntergeladene Datei/oder Teile davon einfach im Ram entschlüsselt und gestartet.


Ich glaube, es geht hier ja auch nicht darum, ob es überhaupt nicht knackbar wäre, sondern einfach den DAU die Möglichkeit zu nehmen, die heruntergeladene Datei mehrmals ausführen zu lassen. Dass das einen Profi Cracker davon nicht abschreckt ist mir auch klar. :) Der kopiert sich einfach den Raminhalt und bastelt sich daraus eine unverschlüsselte Dateiversion....
Außerdem ist die Lösung mit der Registry für einen Cracker ja auch manipulierbar...... :wink:
Letztendlich ist es vielleicht noch besser/notwendig, wenn man in das Updateprogramm zusätzlich einfach eine Updateerkennung einbaut, dass das Programm automatisch erkennt, ob die Daten(Exe/DLL-version, Datenbank,etc..) eh schon update sind oder nicht.

Grüsse,
jus

[Real_Thunder]

Also nun bin ich auch mal am überlegen.
Di Hattes von Normalusern Gesprochen...

Wieso sollten sich Normal User die atei kopieren, bzw wenn es ne dll ist, gerade die dll raussuchen, nur um die datenbank zu zerstören ?
so und wen du eine ee hast die eine datenbank ändert oder so ähnlich dann progge die exe doch einfach so das sie vorher prüft ob die daten schon geändert wurden sind

Und welcher Normaluser kommt denn auf die Idee sich ne dll zu kopieren geshwiege denn sie noch einmal zu benutzen...

Naja ich kann dein vorhaben icht ganz nachvollziehen.

[Hansa]

soll ich Dir neue Tastatur schicken ? 8) :mrgreen:

[jus]

Zitat:

Zitat von Hansa

soll ich Dir neue Tastatur schicken ? 8) :mrgreen:

@Hansa
Da mache ich mit. Ich zahl die Hälfte der Versandkosten. :mrgreen:

P.S.: Ich muss zugeben, ich habe natürlich auch Menge Tippfehler. Entschuldige Real_Thunder! :oops: Ich konnte es mir einfach nicht verkneifen. :) Also bitte nicht bös sein.

[jim_raynor]

Zitat:

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

Na dann hilft doch aller Schutz nicht. Das einzigst wirksame wäre, dies in der Datenbank zu speichern, dass diese bereits konvertiert ist. Ist der einzigst sichere Weg ... Alles andere wird vermutlich früher oder später zu Problemen führen, da es irgendjemand garantiert schafft, das Programm zwei mal laufen zu lassen ...

[Real_Thunder]

Zu meiner Verteidigung.
Es war um die 01:30 und mein Keyboard ist wirklich im A****...
Aber das nur als Nebensache.
...
Und damit möchte ich diese Diskussion schliessen,
da es OFF-Topic wird.

MfG
Real_Thunder