Schreibzugriff in ein jarFile

[GrüneBohne]

Hallo Leute,

ich habe folgendes Problem:

Ich liefere meine Anwendung als Test-Installation aus. Dabei schreibe ich in eine Instanz von Preferences das Startdatum und einen dazu gehörenden MD5-Check als "Merker" weg. Zusätzlich liefere ich im jarFile eine Datei aus, die meiner Anwendung beim Erststart erklärt, das es sich wirklich um einen Erststart handelt. Nach dem Eintrag des Startdatums möchte ich aber nun in dieser Datei vermerken, das die Registrierung erfolgt ist, so das ein Entfernen aller Einträge in der "Prefs" nicht dazu führen kann, das ein erneuter, vermeintlicher Erststart die Folge ist.

Tagelanges googlen hat mich nicht weitergeführt, außer das in einem Beitrag genannt wurde, das man in einem jarFile nur Leserechte hat.

Ist das so (mein versagendes Bemühen deutet irgendwie schon darauf hin!) oder gibt es doch eine Möglichkeit oder einen Trick??

Vielen Dank vorweg,

Thomas

 

[deleted]

Was soll das bringen?
Wird das eine Art Kopierschutz oder so?

 

[GrüneBohne]

Hallo R.B. ,

wie schon geschrieben, kein Kopierschutz (oder im weitesten Sinne ja schon), aber eigentlich eine zeitlich begrenzte Nutzung von 14 Tagen.

Gruß, Thomas.

 

[The_S]

Man kann schon in ein JAR schreiben (JarOutputStream), allerdings klappt das nur, wenn das JAR gerade nicht verwendet wird. D. h. du könntest ein zweites Jar mitliefern. Von deinem 1. Jar das 2. Jar ausführen (über Runtime), das 1. Jar danach beenden lassen, vom 2. Jar das 1. Jar manipulieren und dann anschließend vom 2. Jar wieder das 1. Jar ausführen (ebenfalls über Runtime) bevor du dann das 2. Jar wieder beendest.

 

[GrüneBohne]

Hallo Hobbit,

danke erstmal für den Hinweis und die schnelle Reaktion. Das muss ich erstmal überdenken (und verstehen ???:L ).

Danke, Thomas

 

[deleted]

@Hobbit:

Er will nen DRM. Deine Lösung ist zwar technisch korrekt, bringt ihm aber nix

@Bohne:

Statt deine Zeit zu verschwenden auf der Suche nach Möglichkeiten deine User zu gängeln, solltest du lieber mehr Zeit in die Verbesserung deiner Software investieren.

Ein einfaches Hinweisfenster:
"Diese Software ist nur zu Testzwecken bestimmt. Eine Nutzung im Produktivbetrieb ist nicht gestattet!" reicht völlig aus...
Eventuell bei Netzwerksoftware noch mit Hinweis ins Logfile/eMail an den Administrator, damit er erkennt, dass er z.B. zu wenig Clients lizensiert hat.

Alles andere ist eh unnütz weil es nicht klappt (im Torrent bekommst du z.B. ein Vista ohne Aktivierung trotz Millioneninvestitionen von MS in den "Kopierschutz").
Wer deine Software legal nutzen will, wird sie, wenn er durch Meldungen erinnert wird kaufen.
Wer deine Software nicht legal nutzen will, tut dies, egal was du machst.

 

[thomator]

@R.B.
Ohne der grünen Bohne zu nahe treten zu wollen: Ich kann mir nicht vorstellen, dass seine Applikation ähnlich populär wird, wie Windows. Damit ist so was auch für die Hacker-Gemeinde eher uninteressant. Allerdings wird bei solchen Geschichten schon gerne mal Jahrelang mit Testversionen gearbeitet.
Also die Implementierung von minimalistischen Mechanisme, die vor so was schützen, halte ich schon für sinnvoll. Der DAU wird sowieso nicht in der Lage sein, das Ganze auszuhebeln. Dass man nicht versuchen kann, sich 100%ig dagegen zu schützen ist auch klar.
Sicher spielt hier auch die Zielgruppe eine nicht unwesentliche Rolle...

EDIT: wenn, dann sollten solche Infos aber verschlüsselt geschrieben werden, weil das Bearbeiten von .jar-Dateien in diversen Editoren auch für den DAU kein problem darstellt.

 

[deleted]

@thomator

warten wir mal noch so 10 Jahre ab. Dann dürfte es eh für so ziemlich alle Probleme Lösungen in freier Software geben und das Thema "Kopierschutz" ist endlich vom Tisch (außer bei Sachen wie z.B. Computerspielen.).

Ansonsten ist aber die Bearbeitung des Programmfiles oder irgendetwas im Programmordner komplett nutzlos.
Was hindert mich daran
a) zu beobaten was sich verändert (Decompiler!)
b) einfach das jar File neu reinzukopieren

WENN dann sollte Bohne lieber z.B. ein Rootkit auf seine CD machen, welches automatisch eine Backdoor nebst "Kopierschutz" installiert, sobald jemand die CD einlegt (z.B. Sony machte sowas schon erfolgreich).
Oder man legt die Registrierungsinfos irgendwo z.B. ein paar Bit hinter dem MBR auf die Festplatte (Adobe).
Oder man nutzt wie diverse kleinerer Softwareklitschen irgendwelche halbgaren Produktaktivierungssysteme...

Aber einfach JAR File ändern ist nicht drinnen...

Im Übrigen:
Du musst auch noch eine komplette Zeitverwaltung programmieren.
Es ist nix einfach als in einer manipulierten VM so eine "Trailversion" ewig am Leben zu halten...

*edit*

Im Übrigen kann man bei Java auch direkt die Java-VM manipulieren um Trailsoftware am Laufen zu halten.

Kopierschutzmechanismen in Java implementieren ist nicht drinnen.
Java ist ehr eine Plattform für professionelle Firmensoftware bei der Sicherheit und Qualität gefragt sind (Individualsoftware lässt sichj hervorragend in Java realisieren!) als ein Gestubber für z.B. Privatnutzersoftware.
Da möge man doch bitte lieber zu diversen Lösungen aus dem Hause Microsoft greifen.
Die bieten ihren Kunden da perfekte Lösungen.
Von WPF (optisch der soliden Swingoberfläche weit vorraus) sowie DRM, TCPA usw.

Irgendwelches Gefummel welches sich nicht korrekt an die Spezifikationen hält um in Java irgendwelchen Murks von Kopierschutz zu erreichen senkt nur das Ansehen von Java wenn dann die Programme nicht vernünftig laufen...
Ich würde echt zu C oder .NET raten.
Visual Basic ist leicht zu erlernen und für Privatnutzersoftware genau das Richtige!

 

[GrüneBohne]

Hallo Ihr alle,

ist ja nett, so ne rege Anteilnahme.... . Ich wollte lediglich wissen, ob es an mir liegt oder tatsächlich problematisch ist, was ja wohl der Fall ist.
Das es keinen wirklichen Schutz gibt, weis ich letztendlich auch. Aber das hindert mich ja nicht daran, dem Anwender einerseits eine zeitbegrenzte Anwendung zu überlassen und andererseits einen Hinweis zu geben, das er da schon was macht, was er nicht darf. Ich begnüge mich jetzt mit dem Eintrag in den Prefs, und wenn ein User herausbekommt, wie er das wieder "jungfräulich" bekommt, dann ist es auch gut...

Trotzdem vielen Dank für die Denkanstöße von Eurer Seite

Gruß, Thomas

 

[deleted]

Mach doch einfach ein Lizenzfile:

Datum-Jahr-Zufallszahl-Checksumme über die ersten 3 Sachen

Die Checksummenberechnung schreibst du ganz normal in den Quelltext als Methode.

Der User läd deine Testversion also runter, meldet sich bei dir, du gibst ihm einen Testkey und er kann testen.

Wenn er dann kauft, gibst du ihm eine Version, bei der er sich nicht mehr mit Keys rumärgern muss...

Vorteile:

- du hast schon Kontakt zum Kunden während er testet
- du kannst ihm individuelle Testzeiträume geben
- er kann die Software vernünftig in beliebigen Umgebungen testen
- du musst nicht in irgendwelchen Dateien herumpfuschen

Nachteile:

- es ist halt mehr eine Lösung wie ein Schild "bitte nicht betreten" oder so. Aber die anderen Lösungen sind auch nix anderes und nerven die Kunden nur...

 

[GrüneBohne]

Hallo R.B.,

entschuldige, das ich jetzt erst antworte, aber ich war im Außendienst.

Danke für den Hinweis. So hatte ich das auch bereits zum Download auf meiner Page. Aber da passierte nix. Die Leute haben zwar die Software gezogen, aber nur ganz wenige haben dann angefragt, um zu testen bzw. zu kaufen.

Über diesen Weg kam ich ja auf die andere Idee. Ich mach das jetzt so, wie ich das oben geschrieben habe. So ganz unrecht haben die anderen ja nicht, das hat mich jetzt schon vil zu viel Zeit gekostet. Die hätte ich echt lieber in die eigentliche Sache investiert.

Danke nochmal,

Gruß, Thomas