Entwickler-Ecke
Dateizugriff - Andere Datei schützen das sie nicht zu kopieren geht.
Biarchiv - Mi 09.10.02 12:29
Titel: Andere Datei schützen das sie nicht zu kopieren geht.
Hallo,
Wie könnte den sowas ohne VCL und andere Komponenten funktionieren.
Ich öffne per Shell eine andere Datei (*.exe) .
Die Datei die geöffnet wurde darf man nicht weiterkopieren können.
Nach dem Ausführen wird sie von meine Programm wieder gelöscht.
Prog A schützt > Shell Prog B
Wenn es da nur eine Komponente gibt dann bitte eine kleine die ohne
VCL geht.
Danke.
tommie-lie - Mi 09.10.02 13:47
Häh?
Wenn ich das richtig verstanden habe, öffnet dein Programm eine Datei. Vermutlich mit 'nem Stream, oder? Schau mal in der Onlneilfe unter dem Stream nach. Da gibt es ein Attribut, daß den Modus, in dem die Datei geöffnet werden soll. Dieses kann unter anderem den Zugriff von anderen Dateien sperren. Ob da auch eine Lese-Sperre (und kopieren ist ja nur lesen) dabei ist, weiß ich auswendig nicht. Wenn eine dabei ist, kann kein anderes Programm (ob nun der Explorer oder ein anderes selbsgemachtes Programm) diese Datei lesen, solange die Datei geöffnet ist. Wenn du sie aber gleich nach dem schließen löscht, gibt's keine Probleme. Nur wenn du sie während der Laufzeit des Programmes mehrmals öffnen willst, musst du das anders Regeln.
Aber wenn du eine normale Datei nicht kopieren können darfst (ohne das sie geöffnet, gerade erstellt oder sonstwas ist) dann geht das unter Windows (9x) nicht, da das FAT32 keine Zugriffsrechte vergeben kann. Wie's unter NTFS aussieht, weiß ich nicht. Unter Linux (ext2, RFS müsste es auch können, ext3 sowieso) gibt es dafür mit dem mod-Shell-Befehl eine Möglichkeit Benutzerrechte zu ändern, sodaß nur der aktuelle Benutzer die Datei antasten darf.
Sollte ich irgendwas ganz falsch verstanden haben, vergiss meinen Post.
O'rallY - Mi 09.10.02 17:21
Zitat: |
Sollte ich irgendwas ganz falsch verstanden haben, vergiss meinen Post.
|
Toller Beitrag, den man schnell wieder vergessen soll :mrgreen: .
Ich glaube, er will nicht eine Datei zum Bearbeiten öffnen, sonder eine Datei ausführen und diese dann schützen. Aber ebenso wie tommie-lie geschrieben hat, wüsste ich nur, wie es bei Streams möglich ist...
tommie-lie - Mi 09.10.02 18:39
Schön wenn du ihn toll findest.
Aber ich habe das raus gemacht, was ich aus der Frage verstanden habe. entweder bessere Fragen, oder dümmere Antowrten.
Aber wenn du's auch nciht besser weißt, habe ich ja nix verpasst zu lernen...
O'rallY - Mi 09.10.02 19:57
Sorry, wenn ich dich gekränkt haben sollte, war echt nicht meine Abicht. Es war eigentlich auch nicht ernst gemeint, was ich geschrieben habe. Ich fand nur diesen subtile Kommentar am schluss amüsant... doch vollkommen in Ordnung. Also nochmal, s tut mir leid wenn du mich missverstanden hast... Kanns du mir nochmal verzeihen :eyes: (dieser Betrag ist nicht ironisch gemeint,... nur um Missverständisse auszuschließen :wink: )
Biarchiv - Do 10.10.02 18:56
Hallo,
Danke für Eure Post.
Nunja interessant nur will ich eine EXE Shellen aslo ausführen. Dieser folgenden Code öffnet (shell) eine EXE file und wartet bis sie wieder vom Benutzer beendet wird.
Ich hab was gehört das das mit "fmshareexlusive" gehen kann. Wer weiß darüber mehr oder hat einen besseren Vorschlag? Bei diesen Beispiel wird die EXE (Shw('test.exe', ParamStr(1)); geöffnet und waret bis der Benutzer abbricht. Ginge da was zum einbauen???
Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34:
| procedure ShW(FileName: string; Params: string); var exInfo: TShellExecuteInfo; Ph: DWORD; Msg : TMsg;
begin FillChar(exInfo, SizeOf(exInfo), 0); with exInfo do begin cbSize := SizeOf(exInfo); fMask := SEE_MASK_NOCLOSEPROCESS or SEE_MASK_FLAG_DDEWAIT; Wnd := GetActiveWindow(); ExInfo.lpVerb := 'open'; ExInfo.lpParameters := PChar(Params); lpFile := PChar(FileName); nShow := SW_SHOWNORMAL; end; if ShellExecuteEx(@exInfo) then Ph := exInfo.HProcess else begin // ShowMessage(SysErrorMessage(GetLastError)); Exit; end; while WaitForSingleObject(ExInfo.hProcess, 50) <> WAIT_OBJECT_0 do // while PeekMessage(Msg, 0, 0, 0, 0) do // begin TranslateMessage(Msg); DispatchMessage(Msg); // end; //Application.ProcessMessages; CloseHandle(Ph); end; |
O'rallY - Do 10.10.02 19:01
Biarchiv hat folgendes geschrieben: |
Ich hab was gehört das das mit "fmshareexlusive" gehen kann. |
Diesen Befehl gibt es meines Wissens nur bei Streams als eine Property:
Quelltext
1: 2: 3: 4: 5: 6:
| {...} var FS:TFileStream; begin FS := TFileStream.Create('C:\afile.txt', fmCreate or fmShareExclusive); {...} |
SMI - Do 10.10.02 20:24
Meinst du so was:
Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10:
| VAR EXE :TFileStream; begin WinExec(PCHAR('d:\project1.exe'),SW_SHOW); exe:= TFileStream.Create('d:\project1.exe', fmOpenRead or fmShareExclusive); TRY Showmessage('Datei exklusiv geöffnet'); Finally exe.free; end; |
Funktioniert erstaunlicherweise! Was hast du damit eigentlich vor?
SMI
(10.10.02 21:38 Tino) Code-Tags hinzugefügt.
Biarchiv - Fr 11.10.02 13:01
[quote="SMI"]Meinst du so was:
Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10:
| VAR EXE :TFileStream; begin WinExec(PCHAR('d:\project1.exe'),SW_SHOW); exe:= TFileStream.Create('d:\project1.exe', fmOpenRead or fmShareExclusive); TRY Showmessage('Datei exklusiv geöffnet'); Finally exe.free; end; |
Funktioniert erstaunlicherweise! Was hast du damit eigentlich vor?
SMI
-----------
Ja das sieht gut aus.
Werde es heute Abend probieren. Werde da auch ParamStr(1) einbauen.
Ich hoffe das er auch wartet bis das Programm wieder beendet ist.
Finally
exe.free;
DeleteFile(PCHAR('d:\project1.exe');
Wollte so einen EXE Protector schreiben.
SMI - Fr 11.10.02 13:36
Der ist aber nicht sehr sicher!
Schieß mal das Programm während der Ausführung ab, dann wird deleteFile nicht ausgeführt, das da Programm beendet wird weden von Windows auch alle Dateizurgiffe beendet, daraus folgt: Die "exe-Datei" ist Datei ungeschützt im Ausgangspfad.
Einen funktionierender Ansatz für Exeprotectoren, ist folgender : Der Exe Header wird manipuliert, woraufhin die Exe wie eine DLL startbar ist, also nicht mehr von selbst ab laufen kann. Zum Starten muss der Exe muss der Protector dann dir , durch Manipulation erstellte, Einstiegsfunktion aufrufen. Das ganze erforder aber recht gutes Wissen von der Headerstruktur eine Exe.
SMI
Biarchiv - Fr 11.10.02 14:24
SMI hat folgendes geschrieben: |
Der ist aber nicht sehr sicher!
SMI |
Ja sowas habe ich auch schon getacht.
Ja Header kenne ich mich aus.
Also ich setze bei PE die Datei auf DLL.
Nur wie kann ich dann bei WinEXEC das so simulieren?
Oder wie könnte das gehen. Ich nehmen den Entry Point und
ziehe da halt 55h ab. Also Exe Startet nicht mehr.
Also wenn mein Programm die EXE öffnet springt der beim EntryPoint
+ 55h ein. Und die Datei geht.
Hast halt eine solche Idee wie das gehen könnte?
Danke SMI
SMI - Fr 11.10.02 15:14
Du musst das Programm nachdem es modifiziert ist wie eine DLL laden via LoadLibarayEx, die in der Hilfe folgendermaße definiert ist:
Quelltext
1: 2: 3: 4: 5: 6:
| HINSTANCE LoadLibraryEx(
LPCTSTR lpLibFileName, // points to name of executable module HANDLE hFile, // reserved, must be NULL DWORD dwFlags // entry-point execution flag ); |
da trägst du deinen entry-point ein und es müsste dan klappen.
SMI
SMI - Fr 11.10.02 15:19
Folgendes au der ApiHifde habe ich versehtlich nicht mitkopiert :-)
Quelltext
1:
| The LoadLibraryEx function maps a specified executable module into the address space of the calling process. The executable module can be a .DLL or an .EXE file. The specified module may cause other modules to be mapped into the address space. |
SMI
Biarchiv - Fr 11.10.02 16:45
Hallo,
Gibts da irrgendo ein kleines Beispiel dafür.
Bei Delphi3 hat er nichts in der Hilfe.
Danke.
tommie-lie - Fr 11.10.02 19:56
O'rallY hat folgendes geschrieben: |
Sorry, wenn ich dich gekränkt haben sollte, war echt nicht meine Abicht. Es war eigentlich auch nicht ernst gemeint, was ich geschrieben habe. Ich fand nur diesen subtile Kommentar am schluss amüsant... doch vollkommen in Ordnung. Also nochmal, s tut mir leid wenn du mich missverstanden hast... Kanns du mir nochmal verzeihen :eyes: (dieser Betrag ist nicht ironisch gemeint,... nur um Missverständisse auszuschließen :wink: ) |
Ich bin doch auch gar nicht gekränkt. Ich finde es toll, wenn du meinen Beitrag schön findest. Und ich finde es gut, daß du auch nicht mehr weißt als ich, bzw ich nciht weniger als du. Mehr nicht. Nix gekränkt, nix beleidigt ;-)
O'rallY - Fr 11.10.02 20:30
Zitat: |
Nix gekränkt, nix beleidigt :wink: |
Puh!, da fällt mir aber ein stein vom Herzen ... :mrgreen:
Wiesenbiber - Fr 11.10.02 22:14
Titel: Andere Lösung?!
Hallo,
ich weiß nicht ob dir die folgenden Zeilen unbedingt nützlich sind, aber wenn du deine "B Datei", wie du Sie genannt hast vor dem kopieren schützen willst, dann verschmelz doch die B Datei in der A datei, die wird dann nur zur laufzeit aus der B datei ausgelagert, beispielsweise in ein Temp verzeichnis und nach programmende wieder verschmolzen. So ist sie nur zur laufzeit des programms kopierbar und dass auchnur wenn man weiss wie sie heisst und wo sie ausgelagert wird.
SMI - Sa 12.10.02 02:57
@Wiesenbiber
Hallo,
Biarchiv hatte genau das vor, das problem, daran ist: wenn ich das programm mit hilfe eines debuggers überwache weiß ich wo es dateien ablegt, wenn ich es nun zum richtigen zeitpunkt abschieße, kann das programm die datei nicht mehr weglöschen, da es ja mutwillig zum "absturz" gebracht wurde. Somit hat ein mittelmäßiger Programmieren innerhalb von einer minute das geschützte programm! Daher ist das ganze sehr unsicher.
SMI
Wiesenbiber - Sa 12.10.02 08:50
@SMI
Okay, das versteht ich schonmal :o
Wie wäre es dann in der B datei einen test auf den Prozess manager laufen zu lassen ob das a programm noch läuft und wenn nicht eben entsprechen die B datei zu zerschiessen oder etc.
SMI - Sa 12.10.02 16:37
@Wiesenbiber
geht nicht, denn eine datei die ausgeführt wird, hat windows geöffnet, und geöffnete Dateien dürfen nicht gelöscht werden! Also kann Programm b sich nicht selber löschen. Desweiteren ist der Sinn eines Exe Protector meist eine fremde Exe-Datei zu schützen., von der man nur das Compilat hat.
SMI
Biarchiv - So 13.10.02 12:57
Hallo,
Ja entpacken und dann löschen ist wirklich zu unsicher.
Habe folgendes Probiert.
Habe den EIP Entry Point auf 00000000h abgeändert.
Nun führe ich
loadlibraryEX('Datei.EXE',0,02050712); aus leider funktioniert das nicht.
LAUT MSDN kann man dort keine HEX Werte reinschreiben.
Es funktionieren EXE und DLL Files.
Vieleicht hat wer ein kleines Beispiel. Währe echt nett. Da ich bei google
und MSDN nicht passendes finde.
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!