Hi, ich möchte eine *.exe Datei mit einem VC++ Code so einpacken, dass diese nur unter bestimmter Bedingung ausführbar ist. Also
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
Diese setup.exe soll nicht mehr zu sehen. Ist das überhaupt möglich? Cu Senmeis
|
Anzeige
|
*.exe Dateien einpackenHi, ich möchte eine *.exe Datei mit einem VC++ Code so einpacken, dass diese nur unter bestimmter Bedingung ausführbar ist. Also
Diese setup.exe soll nicht mehr zu sehen. Ist das überhaupt möglich? Cu Senmeis > Diese setup.exe soll nicht mehr zu sehen.
nix setup.exe, setup.dll nehmen.
Dann gehen...
Owen Senmeis schrieb: > Diese setup.exe soll nicht mehr zu sehen. Ist das überhaupt möglich? Im Prinzip ja. Dazu muss die Datei als Resource im Programm abgespeichert werden, und sie wird erst vor der Ausführung aus der Resource extrahiert.
Gast
#2135200
Owen Senmeis schrieb: > Hi, > > ich möchte eine *.exe Datei mit einem VC++ Code so einpacken, dass diese > nur unter bestimmter Bedingung ausführbar ist. Also >
> Diese setup.exe soll nicht mehr zu sehen. Ist das überhaupt möglich?
Solltest Du damit so etwas wie DRM, Kopierschutz, Lizenzverwaltung oder
so vorhaben: vergiss es, das kann prinzipbedingt nicht funktionieren.
Sonst so wie die anderen schon schroben.
Was meinst Du mit “prinzipbedingt nicht funktionieren”? Ist das überhaupt nicht möglich oder ist dies knackbar? MfG Senmeis - SFX (selbstextrahierende Exe) kann afair von einigen Programmen auch verschlüsselt erzeugt werden. - InnoSetup kann verschlüsselte Installations-Pakete erzeugen Owen Senmeis schrieb: > Was meinst Du mit “prinzipbedingt nicht funktionieren”? Ist das > überhaupt nicht möglich oder ist dies knackbar? Sobald die Exe extrahiert ist, ist sie, falls keine weiteren Maßnahmen getroffen werden, beliebig kopier- und verwendbar. D.h. es müssten noch weitere Sachen hinzukommen ala Verknüpfen mit der Volume-ID, MAC-Adresse, Online-Überprüfung etc. Das Problem: Letztlich sind das auch nur Abfragen ala if currentX == instX und diese lassen sich relativ einfach mit einem Debugger finden. Das gilt (auch wenn es dort komplizierter wird) für Dongle
Gast
#2136676
Owen Senmeis schrieb: > Was meinst Du mit “prinzipbedingt nicht funktionieren”? Ist das > überhaupt nicht möglich oder ist dies knackbar? Was Arc Net geschrieben hat. Letztlich kann sowas ohne sehr spezielle Hardware nicht wirklich funktionieren. Und sehr speziell meint sowas: verschlüsselte Busse, verschlüsselten Speicher (ROM, RAM, Massenspeicher, alles), das alles natürlich mit Maschinen-individuellen Schlüsseln (weil sonst ein Crack alle Maschinen aufmacht, siehe PS3), das volle Programm. Und auch dann scheitert das oft an Implementationsfehlern, siehe die gehackte XBox (die hatten wohl vergessen einen bestimmten Bus zu verschlüsseln) oder die gehackte PS3 (die haben da richtig in die Sicherheit investiert, hat ja sogar ein paar Jahre gehalten :-). Ich packe gelegentlich kleine (fremde*) Command-Line-Programme mit in meinen Sourcecode, dann spare ich meinen Kunden mögliche Fehler bei der Installation. Die Programme werden zunächst gezipt und dann Base64-codiert. Diesen Text nehme ich als String-Konstatnte in meinen Sourcecode auf. Wird das Programm benötigt, prüfe ich zunächst, ob die Datei extern schon vorhanden ist - das ist meist beim ersten Start nicht so. Also wird die Stringkonstante Base64-decodiert, entzipt** und extern geschrieben. Danach ausgeführt ... Frank * wenn ich über die Funktionalität als Source verfüge, ist dieser Weg natürlich nicht erforderlich. ** Fürs Entzippen habe ich eine interne Funktion.
Gast
#2136808
Erst zippen damit es kleiner wird und hinterher mittels Base64 wieder aufblähen. Wozu denn dieser sinnlose Aufwand? Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|