Demoversion erzeugen?

[sunnyMD79]

Hallo zusammen,

ich habe ein Jar-Archiv von meiner Java-Applikation. Dies soll aber nur sehr beschränkt nutzbar sein.
Gibt es Möglichkeiten, um dieses Java-Programm nur einmal oder x-mal ausführen zulassen, danach soll es unbrauchbar sein und die Info geben, dass die Testversion abgelaufen sei oder so ähnlich?.


mfg,
sunny

p.s.: bin sehr gespannt, ob jemand eine Lösung hat

 

[sunnyMD79]

Oder gibt es vielleicht die Möglichkeit, in Java selbst modifizierten Code zu erstellen?
Dann könnte man ja beim ersten Beenden des Programms den Code entsprechend umschreiben^^

 

[tuxedo]

Das mit Zeitbegrenzten Testversionen müsste doch recht easy machbar sein?!
Klar, die ersten Spezis kommen dann und stellen das Systemdatum zurück.

Aber du kannst ja sowohl ein fixes "StartDatum" festlegen und das Programm abbrechen wenn die Systemuhr ein jüngeres Datum zeigt, und du kannst bei jedem Start die Systemzeit einlesen und in einer (verschlüsselten) Datei speichern, um beim nächsten Start unterscheiden zu können ob das Systemdatum zurückgesetzt wurde. Die verschlüsselte Datei machst du dann als Pflicht-Bedingung für den Start des Programms.

Allerdings lässt sich das auch einfach umgehen: Einfach die gesicherte Datei mit der ersetzen, die frisch nach der Installation auf der Platte war. Aber du kannst die Datei ja entsprechend tarnen und verstecken. Dann isses nciht ganz so offensichtlich.

- Alex

 

[JPKI]

Zumindest für MS Windows hab ich ne Lösung, gegen die die meisten Windows-Benutzer nix tun können:

Hier kann man nachlesen, wie man unter MS Windows etwas in die Registry einträgt. Erstell irgendeinen gut versteckten Schlüssel, in dem du die Anzahl der noch möglichen Aufrufe speicherst und frag diese bei jedem Start ab.

Mit dieser Lösung sind wohl die meisten Benutzer überfordert, weil die Windows-Registry wirklich ein hochkomplexes (und meiner Meinung nach systemloses und unaufgeräumtes) Gebilde ist und solch ein verstecker Eintrag (wenn er nicht gerade den Namen deines Programmes trägt, sondern aus irgendwelchen Hexadezimalzeichen besteht) sehr schwer zu finden ist.

Natürlich könnten wirkliche Cracks den Speicher zur Laufzeit auslesen oder dein Programm decompilieren und schauen, wo das alles gespeichert wird, aber wie gesagt, die meisten Windows-Nutzer (und damit so c.a. 80-90% aller PC-Nutzer :wink: ) werden damit überfordert sein.

 

[tuxedo]

Ja, das is auch ne Idee ...Wobei: Manche Sicherheitstools melden solche Aktionen. D.h. der User bekommts dann bei jeden Start mit dass die Registry benutzt wird.

- Alex

 

[JPKI]

Nachtrag zu meinem obigen Beitrag: Bei anderen Betriebssystemen wie z.B. GNU/Linux könntest du die von alex0801 angepriesene verschlüsselte Datei irgendwo schön versteckt im Systemverzeichnis abspeichern (Root-Rechte vorrausgesetzt :wink: ).

 

[tuxedo]

Naja, oder er hat sonst noch irgendwelche (dummy) Dateien die im Installationsverzeichnis liegen unter die er die File mischen kann....

- Alex

 

[JPKI]

Hm. Jetzt frag ich mich, ob man ohne Root-Rechte in allen restlichen Betriebssytemen auf die TEMP-Ordner zugreifen kann... Dort könnte man solch eine Datei auch speichern.

Andererseits... Viele Leute löschen oder lassen ihren Temp-Ordner beim Runterfahren automatisch löschen, oder ???:L

 

[tuxedo]

Soll vorkommen, ja...

Man könnte die File auch in ~/.MeinProgramm/meineGeheimeDatei.dat oder so verstecken... die meisten kennen und sehen die Verzeichnisse, beginnend mit einem Punkt gar nicht. Wobei damit auch nur die absoluten 0815 User ausgegrenzt wären.

 

[JPKI]

Oder man hängt die Daten als Kommentar in die erste Zeile einer wichtigen, aber vom Benutzer nicht oft genutzen Systemdatei (z.B. xorg.conf: Einmal configuriert, ändert man da ja kaum noch was [ich bin jetzt bei Ubuntu]).

 

[kleiner_held]

... weil die Windows-Registry wirklich ein hochkomplexes (und meiner Meinung nach systemloses und unaufgeräumtes) Gebilde ist ...

wenn alle moeglichen Programme da heimlich kryptische Eintraege ablegen ist das ja auch kein Wunder :-D

Ansonsten:
- Registry ist plattformabhaengig.
- Alle hier genannten Linux-Hacks mit versteckten Dateien funktionieren nicht, wenn ein verantwortungsvoller User ein Demo Programm mit chroot installiert bzw ausfuehrt (ist uebrigens sehr zu empfehlen!)

Sauberer ist mMn nach das Vorgehen, eine funktional abgespeckte und keine zeitlich begrenzte Demo-Version anzubieten. Da kann man bei einem sauberen Design auch nur die notwendigen Klassen mit ins Jar packen, so dass auch kein Decompilieren was bringt.

 

[Wildcard]

Einfach den verbleibenden erlaubten Starts im Java Preference Store ablegen und gut.
Ein nicht-Java Programmierer weiß nichtmal das soetwas existiert.

 

[Guest]

Man kann dem Benutzer noch zusätzlich damit auf den Sack gehen, indem man Teile der Demo-Anwendung
von irgendeinem Server lädt. Soll heissen, Demo nur lauffähig, wenn gleichzeitig online und nicht abgelaufen.
Serverseitig kannst du dann den Zähler präparieren und zum Client mit übertragen. Wird er manipuliert,
merkst du es.

1) Jede runtergeladene Kopie der Anwendung kriegt eine eigene, verschlüsselte Zählerdatei (pro Download
eine und Download nur mit Anmeldung).
2) Diese Datei wird bei jedem Start zum Server übertragen, geprüft und zusammen mit einem Teil der Anwendung
zurück an den Client geschickt.
3) Beim nächsten Start das gleiche.

Wird die Datei manipuliert, merkst du serverseitig, dass die Datei nicht dem aktuellen Stand des Clients
entspricht und zweigst den Finger.
Hat sich jemand eine Kopie der Datei angelegt, kann er sie sowieso nicht zweimal nutzen, da serverseitig
der Zähler hochgezählt wurde.

OK, das ist nur so 'ne Idee, die mir auf die Schnelle so einfällt. Die Anwender werden entzückt sein. :roll: :wink:

 

[Guest]

Ätch, keine "verschlüsselte Zählerdatei" sondern eine Art eindeutiges Client-Zertifikat.
Der Zähler wird nur serverseitig verwendet.

 

[Gast]

Die Idee mit dem Server ist gut. Wäre nur doof bei Offline-Systemen... Aber die werden ja immer seltener.

- Alex

 

[Leroy42]

Sauberer ist mMn nach das Vorgehen, eine funktional abgespeckte und keine zeitlich begrenzte Demo-Version anzubieten. Da kann man bei einem sauberen Design auch nur die notwendigen Klassen mit ins Jar packen, so dass auch kein Decompilieren was bringt.

100% Zustimmung.

Alle anderen, hier gemachten, Vorschläge sind in meinen Augen,
ziemlich wirre Rumpfuschereien am System.

 

[tuxedo]

Naja, ich für meinen Teil hasse es wenn ich ne Demo habe und diverse Funktionen die mir wichtig sind gar nicht testen kann, weil sie in der Dem nicht drin sind.

Bin mir sicher da gibts noch genug andere denen es genau so geht.

Ich denke sowas ist aber ne Grundsatzentscheidung...

Ergo muss jeder Entwickler für sich selbst entscheiden welche der zwei Ansätze er verfolgt.

 

[Guest]

Wäre interessant zu wissen, was das für eine Anwendung ist? Eventuell reicht es bestimmte Funktionen zu deaktivieren.

Beispiel: Bildbearbeitung

Man kann Bilder laden, manipulieren, eigentlich sämtliche Funktionen nutzen, nur speichern kann man das Ergebnis nicht. Gut, könnte man per Screenshot umgehen, aber nur mal als Anregung.