Entwickler-Ecke :: Thema anzeigen - Suche Tool das kopieren einer Datei verhindert.

avoid - Sa 30.11.13 11:08
Titel: Suche Tool das kopieren einer Datei verhindert.

ich suche ein Tool das dafür sorgen kann das sich eine schon lauffähige exe ausführen aber nicht kopieren lässt.

da leserechte dafür sorgen das man Dateien nicht nur ausführen sondern auch kopieren kann,
müsste es doch sicher irgend ein Tool geben mit dem man eine exe in einer Art Container Kopierschützen kann.

Es ist mir wichtig das die kopiergeschützte aber ausführbare Datei später ohne Installation von Treibern
oder anderer Software von einem USB-Stick aus arbeiten kann.

hat da jemand einen Tipp wie ich das hin bekommen kann?
p. s. nein die exe kann ich nicht verändern um den Kopierschutz zu integrieren.

Gruß,
avoid

avoid - Sa 30.11.13 12:29

ich hab mal versucht mir selbst was zusammen zu coden.
ich habe eine exe als Resource geladen und diese dann aus meiner Anwendung extrahiert und gestartet.

C#-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:

string filetempPath = Path.Combine(System.IO.Path.GetTempPath(), "irpt.exe");
if (!string.IsNullOrEmpty(filetempPath) && File.Exists(filetempPath))
{
    try
    {
        File.Delete(filetempPath);
        using (FileStream fsDst = new FileStream(filetempPath, FileMode.CreateNew, FileAccess.Write))
        {
            byte[] bytes = global::ShellExecute.Properties.Resources.RFID_test2;
            fsDst.Write(bytes, 0, bytes.Length);
        }
    }
    catch { }
}
else
{
    using (FileStream fsDst = new FileStream(filetempPath, FileMode.CreateNew, FileAccess.Write))
    {
        byte[] bytes = global::ShellExecute.Properties.Resources.RFID_test2;
        fsDst.Write(bytes, 0, bytes.Length);
    }
}
System.Diagnostics.Process.Start(filetempPath);

leider hab ich damit aber noch keinen Kopierschutz der eigentlichen Datei weil diese dann auf dem Rechner liegt.
auch wenn ich in meiner Anwendung nun Passwortabfrage für den Start oder eine Fixierung auf einen Ursprungs Pfad Realisieren könnte.

ich werde auf jeden fall mal dafür sorgen das sich mein Programm nach dem Starten der Extrahierten exe versteckt.
zusätzlich werde ich wohl das aufgerufene Programm überwachen (ob es noch gestartet ist)
und wenn es beendet wird die extrahierte Datei wieder löschen.
nach dem löschen beendet sich dann mein Programm selbst.

kommt mir aber wie eine Bastellösung vor, geht doch sicher auch anders.

jaenicke - Sa 30.11.13 16:50

An eine solche .exe kommt man immer verhältnismäßig einfach heran. Das liegt in der Natur der Sache. Das Betriebssystem muss die .exe ja zum Ausführen in den Speicher lesen.

Mit Tricks kann man so eine .exe selbst in den Speicher laden und muss sie nicht auf die Festplatte legen:
http://www.michael-puff.de/Programmierung/Delphi/Importe/Nico/inmemexe.zip
Das geht aber nicht bei allen Programmen.

Wirklich sicher ist das aber nie. Denn man muss ja nur eine 1:1 Kopie des Sticks machen, wenn es keine zusätzlichen Maßnahmen gibt...

Wenn es etwas kosten darf, wäre eine Lösung mit USB-Dongle viel sinnvoller. Ohne die .exe zu verändern lässt sich das aber nicht integrieren.

Ralf Jansen - Sa 30.11.13 16:50

Du versuchst gegen das System zu arbeiten also kann es nur eine Bastellösung sein. Gibt also keinen Grund sich zu wundern :wink:

Um das Programm auszuführen muss es vom Datenträger bewegt werden. Letztlich macht es keinen Unterschied ob das Ziel dieser Bewegung der Speicher oder ein anderer Datenträger ist. Wenn die Executable da nicht irgendwie mitspielt sondern als die ganz normale kopierschutzfreie Anwendung irgendwann Speicher landet wird man die auch wieder auf eine anderen Datenträger bekommen. Solange du die Exe unverändert lassen willst ist das wohl eine Sackgasse. Ausgenommen die ganz schweren Geschütze wie eine virtuelle Appliance da wäre es aber einfacher und günstiger die Executable zu überarbeiten und mit einem Standardkopierschutz vom Markt auszustatten.

Ralf Jansen - Sa 30.11.13 17:08

Zitat:

Mit Tricks kann man so eine .exe selbst in den Speicher laden und muss sie nicht auf die Festplatte legen:

Falls die Executable managed Code ist .Net kann von Haus aus Assemblies aus Streams laden. Es muß kein Filestream sein. Wird daraus dann aber auch kein nennenswerter Kopierschutz wenn ich mir das Ding einfach aus der Resource des Starter klaube oder direkt aus dem Speicher.

avoid - Sa 30.11.13 17:37

die Idee, die exe aus dem Ram zu starten anstelle von der Festplatte klingt nach einem guten weg.
den link von jaenicke kann ich aber nicht öffnen, mein Kaspersky jammert dann verständlicherweise wegen Trojaner.
bzw. es sollte schon ein weg sein, der gängig ist und darum nicht gleich von Antiviren Software als gefährlich angesehen wird.

der Schutz muss nicht Bombensicher sein.
ich muss jemandem einen USB-Stick mit einem Lizensierten Programm kurzzeitig überlassen.
an dem Programm kann ich natürlich nicht einfach was ändern weil nicht von mir erstellt.
doch ich möchte verhindern das es Raubkopiert und mir meine Lizenz dadurch evtl. gesperrt wird.
darum versuch ich gerade ein Container Tool dafür zu stricken.

die Person die mit dem Programm auf dem Stick arbeiten soll,
ist meines Wissens nach ein Otto Normalanwender.
Ich möchte nur das einfache Kopieren vom Stick unterbinden bzw.
dafür sorgen dass das Programm nur vom Stick aus zu starten geht.

hoffe jetzt hab ich das Szenario treffend genug beschrieben.

Ralf Jansen - Sa 30.11.13 18:05

Zitat:

ich muss jemandem einen USB-Stick mit einem Lizensierten Programm kurzzeitig überlassen.
an dem Programm kann ich natürlich nicht einfach was ändern weil nicht von mir erstellt.
doch ich möchte verhindern das es Raubkopiert und mir meine Lizenz dadurch evtl. gesperrt wird.

Es gibt Software deren Lizenz Ihren Verleih erlaubt?

jaenicke - Sa 30.11.13 19:43

avoid hat folgendes geschrieben :

den link von jaenicke kann ich aber nicht öffnen, mein Kaspersky jammert dann verständlicherweise wegen Trojaner.
bzw. es sollte schon ein weg sein, der gängig ist und darum nicht gleich von Antiviren Software als gefährlich angesehen wird.

Den gibt es nicht. :nixweiss:
Gängig ist so ein Vorgehen nun einmal nicht.

Wenn es nur ein geringer Schutz sein muss, reicht ja auch das Entpacken nach Temp und danach zu löschen. Dort findet ein normaler Nutzer das Tool ja ohnehin nicht. Und wenn du noch einen Hook auf die Dateizugriffsfunktionen der API setzt, kannst du die meisten Zugriffe normaler Nutzer verhindern.

Ich selbst würde einfach schauen wo die Exe liegt und den PC hart ausschalten, schon kannst du nix mehr schützen bei so einem Vorgehen.

Greenberet - So 01.12.13 13:57

Kopieren verhindern geht leider nicht so einfach. Was du allerdings machen kannst ist das ausführen verhindern.

Am besten du nimmst einen bestimmten USBSTICK und überprüfst ob die Seriennummer des Gerätes wo die EXE läuft (also der des USBSticks bzw. Festplatte) mit der gespeicherten(deines USBSticks) übereinstimmt.

Wenn ja -> führe Programm aus
Wenn Nein -> beende das Programm mit Fehler "DU böser böser Exe-Dieb".

Wie man die Seriennummer eines Gerätes ausfindig macht siehst du hier:
http://stackoverflow.com/questions/450009/how-to-get-serial-number-of-usb-stick-in-c-sharp

avoid - So 01.12.13 20:09

ich denke mal die Prüfung der Seriennummer des Gerätes in Kombination mit dem extrahieren in Temp
und nach dem beenden wieder löschen sollte genügen.

mal angenommen ich wollte die integrierte Anwendung nicht erst extrahieren,
könnte ich die fremde exe als (Binary Resources) mit Process.Start()
als Parent in meiner Anwendung laden wie ich es hier gemacht habe?
http://www.entwickler-ecke.de/viewtopic.php?t=111064
oder kann Process.Start() keine Resources Starten?

damit könnte ich es mir sparen mich in den MemoryStream ein zu lesen,
wenn der überhaupt der richtige weg währe.

leider klappt das auslesen der USB-Stick Seriennummer nicht wirklich.
ich bekomme zwar bei meiner USB-HDD die Seriennummer raus aber nicht von USB-Sticks.
als hätten die keine, obwohl ich sie im Windows sehen kann.

ich habe als Beispiel diesen code verwendet:

C#-Quelltext

1:
2:
3:
4:
5:
6:

ManagementObjectSearcher theSearcher = new ManagementObjectSearcher("SELECT * FROM Win32_DiskDrive WHERE InterfaceType='USB'");
foreach (ManagementObject currentObject in theSearcher.Get())
{
    ManagementObject theSerialNumberObjectQuery = new ManagementObject("Win32_PhysicalMedia.Tag='" + currentObject["DeviceID"] + "'");
    label1.Text += "\n - " + theSerialNumberObjectQuery["SerialNumber"].ToString();
}

jaenicke - So 01.12.13 21:43

avoid hat folgendes geschrieben :

oder kann Process.Start() keine Resources Starten?

Standardmäßig kann man eine Anwendung ausschließlich aus einer Datei heraus starten. Alles andere muss man selbst tricksen, indem man die ausführbare Datei in den Speicher lädt, ein paar Vorbereitungen trifft und den Einsprungpunkt der ausführbaren Datei anspringt (Kurzfassung).

Palladin007 - So 01.12.13 22:16

Wie du verhindern kannst, dass die originale Datei kopiert wird, kann ich dir nicht sagen. Höchstens würde ich versuchen, was die Anderen gesagt haben und entweder aus dem RAM laden, oder es gibt eine Möglichkeit, die exe ausführbar in eine Anwendung hinein zu kompilieren.
Wenn diese Person aber ein typische Otto-Normal-Nutzer ist, sollte es aus reichen, die exe in den Speicher zu laden und von dort zu starten. Wie das geht, weiß ich aber nicht.

Zusätzlich kannst du in deiner eigenen Anwendung Schutzmaßnahmen einfügen, die verhindern, dass er sie unrechtmäßig nutzt.
Wenn lokale Maßnahmen (Seriennummer, etc.) nicht ausreichen, dann könntest du doch hin gehen und auf einem Server abfragen, ob die lizenzierte Anwendung gestartet werden darf.
Meine Idee wäre, dass jeden Tag nur eine Instanz am laufen sein darf, also dass auf dem Server hinterlegt ist, wenn eine Instanz am laufen ist.
Außerdem kannst du dann gleichzeitig noch die MAC-Adresse (oder andere Hardware-IDs) von dem Rechner mit geben, dass ab dem ersten Start diese Anwendung nur noch auf diesem einen Rechner gestartet werden darf. Entweder auf einen Tag gerechnet, oder eben dauerhaft.
Und was du auch noch einbauen kannst: Wenn die Anwendung keinen passenden Server findet, startet sie das Programm gar nicht. Wenn doch, fragt sie erst einmal nach ob du das Startet überhaupt erlaubst. Du kannst bei Bedarf also einfach verbieten, dass die Anwendung überhaupt geht, indem du den Server schlicht vom Netz nimmst.

So kannst du sicher gehen, dass er die Anwendung nur dann nutzt, wenn du es erlaubst.

Palladin007 - So 01.12.13 23:25

Ja, eine Anwendung, die das prüft und die exe startet, muss er trotzdem erstellen.

Aber wenn er dann die Anwendung hat, die die lizenzierte exe sicher beherbergt und dann bei Bedarf startet, muss er auch dafür sorgen, dass diese nicht unrechtmäßig gestartet werden kann.
Das an den Stick via Seriennummer zu binden ist unsicher und meiner Meinung nach auch unpraktisch, daher die Idee, das über das Internet zu regeln.

Ralf Jansen - So 01.12.13 23:55

Zitat:

Das an den Stick via Seriennummer zu binden ist unsicher und meiner Meinung nach auch unpraktisch, daher die Idee, das über das Internet zu regeln.

Ich fasse mal meine Vorstellung über das was avoid vorhat gerade zusammen.
Eine einzelne Anwendung für einen einzelnen User vorübergehend bereitstellen und das kleine Risiko verhindern das er die Executable weiterverteilt. Und du findest es praktischer dafür mal eben einen Serverdienst irgendwo zu hosten gegen den dann ein Starter prüft :gruebel:

Palladin007 - Mo 02.12.13 15:49

Nagut ... praktisch ... nicht so ganz :D

Aber sicher wäre es. Kann ja auch avoid entscheiden, mir ging es nur darum, die Idee in den Raum zu werfen, als Möglichkeit, die eventuell helfen könnte. Schließlich lesen das hier ja auch andere Leute.

Trotzdem bleibt die Frage:

Ist es nicht irgendwie über Umwege möglich, eine exe ausführbar in eine Anwendung hinein zu kompilieren, dass sie nicht erst irgendwo (Festplatte oder RAM) abgelegt werden muss, um sie starten zu können?

Würde mich auch interessieren, ob das geht.

Oder gibt es eine Möglichkeit, in die bestehende Anwendung am Anfang etwas vor zuhängen, was dann vor dem Start der eigentlichen Anwendung ausgeführt wird? Für avoid wäre das wahrscheinlich unpraktisch, weil das schwer nach typischen Virus-Verhalten klingt, aber die Idee finde ich trotzdem interessant.

Delete - Mo 02.12.13 16:06

Palladin007 hat folgendes geschrieben :

Ist es nicht irgendwie über Umwege möglich, eine exe ausführbar in eine Anwendung hinein zu kompilieren, dass sie nicht erst irgendwo (Festplatte oder RAM) abgelegt werden muss, um sie starten zu können?

Und was wäre dadurch gewonnen? Diese "Außen-Exe" könnte doch dann genau so leicht kopiert werden ...

Martok - Mo 02.12.13 17:17

Palladin007 hat folgendes geschrieben :

Ohne RAM gehts natürlich nicht, aber ansonsten ist das exakt das was EXE-Packer tun. Die entsprechenden Segmente werden erst zur Laufzeit zusammengesucht (und im Falle von UPX&co eben dekomprimiert). Dann kannst du aber immer noch nicht verhindern, dass jemand die Anwendung einfriert und die Daten wieder zu einer PE zusammenschreibt.

Palladin007 - Mo 02.12.13 18:14

Zitat:

Und was wäre dadurch gewonnen? Diese "Außen-Exe" könnte doch dann genau so leicht kopiert werden ...

Aber in der "Außen-exe" könnte er uneingeschränkt Sicherheitsvorkehrungen einbauen.

Zitat:

Genau deshalb hab ich gehofft, dass man es irgendwie schaffen kann, die exe fest mit in die "Außen-exe" hinein zu legen, dass eben kein Umweg über den RAM nötig ist.
Wenn das aber nicht geht, ist das sowieso geklärt.

Dann würde ich aber auch den RAM bevorzugen, einfach nur deshalb, weil es für den Otto-Normal-Verbraucher deutlich schwieriger ist, eine komplette Anwendung aus dem Speicher zu ziehen, als von der Festplatte.

Delete - Mo 02.12.13 18:30

@avoid: Mal andersherum gefragt: Wer sollte denn die Exe-Datei ausführen dürfen? Registrierte User? Dann wäre es doch wohl am einfachsten, wenn dein Programm beim Start auf der entsprechenden Web-Präsenz nachschaut, ob der User, der sich gerade anmelden will, registriert ist. Eine zusätzliche Abfrage der Rechner-Hardware sorgt dann dafür, daß das Programm nicht auf jedem Rechner mit denselben Anmelde-Daten lauffähig ist. Offline kann das Program dann natürlich nicht verwendet werden.

avoid - Mo 02.12.13 19:20

ich hab vor meine "Außen-Exe" (wie ihr sie so schön genannt habt) beim Start ein Passwort ab zu fragen und die Ausführbarkeit auf einen bestimmten Datums Zeitraum zu beschränken.
trotzdem bleibt das Risiko, wenn die innere exe zum ausführen auf einen Datenträger extrahiert wird.
aber ich denke mal das kein Otto normal User den Temp Ordner durchsucht.

da ich schon die abfrage der stick-SN nicht richtig schaffe wie soll ich da eine exe in den RAM entpacken. ;)
am ende hilft wohl nur Daumen drücken und zur not ne Rechnung über die Lizenz stellen wenn sie gesperrt wird.

die diversen Tools die es bei so manchem USB-Stick gibt die machen ja leider meist nix anderes als einen Passwortschutz.

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!