Jar Datei Sichern bzw Verschlüsseln !!!!!!

[Bluedaishi]

Guten Morgen zusammen,
ich suche nach einer Möglichkeit ein Programm zu schützen zB.
in dem die eigentliche Jar Datei auf einem USB stick liegt und einen zweiten USB stick abfragt
zB. die Seriennummer ausliest und nur wenn das stimmt lässt sich das Pragramm ausführen.
Dann wäre es noch schön wenn die Jar Datei verschlüsselt ist so das sie nicht direkt eingesehen
werden kann. Hab bis jetzt noch nicht wirklich eine Idee wie ich das anstellen kann, hat vielleicht
jemand von euch eine Idee , bin für jede Idee und Hilfe sehr Dankbar

Vielen Dank schon mal für eure Hilfe


Schönen Tag noch zusammen


:rtfm::rtfm::idea::idea:

 

[Sunchezz]

Wirklich sichern lässt sich eine Jardatei nicht. Zumindest nicht durch Verschlüsselung.

Allerdings kannst du mal nach dem Stichwort "Obfuscator" suchen.
Es gibt einige für Java, zumindest für sourcecode.
Ob es für Java auch Bytecode-obfuscating gibt weiß ich nicht, aber ich möchte dir auch nur mal die Anregung geben.

 

[Tobse]

Das Thema kommt zum X-ten mal => Suche nutzen.

Es läuft jedesmal darauf hinaus: Die JVM muss deinen Code lesen können also kann das auch jeder, der die Datei hat, unweigerlich. Du kannst höchstens, wie gesagt, einen Obfuscator benutzen. Der macht die Arbeit für die JVM in gewisser weise sogar einfacher aber für den Menschen ist der Decompilierte Quellcode dann nur ein einziges "Chaos".

 

[VfL_Freak]

Moin,

stimme den letzten Posts absolut zu!
Wir nutzen hier in der Firma "proguard" (ProGuard ? Wikipedia) und damit sehr zufrieden!

Gruß
Klaus

 

[kay73]

Hallo,

das Thema ist zwar schon öfters behandelt worden, allerdings lief es immer darauf hinaus, dass man mit der App implizit auch den Schlüssel ausliefert. Wenn der Schlüssel allerdings getrennt von der App aufbewahrt wird und erst immer zur Laufzeit hiinzugefügt wird, lässt sich das gut umsetzen: Man implementiert einen (Jar-) ClassLoader dessen loadClass()-Methode die class-Bytes on the fly decodiert.

Ich habe ein Maven-Projekt hinzugefügt, das Dir zeigt wie das geht: Nachdem Du mit

mvn clean install

das Projekt gebaut hast, gehe ins Unterverzeichnis secure-runner/target und führe

java -jar secure-runner-1.0-SNAPSHOT.jar

aus. Du wirst nach einem Passwort gefragt, das "password123" lautet. Das entschlüsselt die Klassen in secure-runner/target/lib/secure-app-encrypted-1.0-SNAPSHOT.jar.

Die eigentliche Anwendung ist im Projekt "secure-app"; da gibt es nichts besonderes, auch das Ressourcenladen und transitive Abhängigkeiten (slf4j, log4j) funktionieren ganz normal. Wenn das Maven Projekt auf der obersten Ebene gebaut wird, wird secure-app zunächst ganz normal kompiliert. Das Projekt "secure-app-encrypted" kopiert die Klassen und Ressourcen aus secure-app und mittels encrypter wird jede Klassendatei gegen eine Blowfish-verschlüsselte "*.classx"-Datei ausgetauscht. Das Passwort wird in secure-app-encrypted/pom.xml Zeile 77 gesetzt.

secure-runner hat den ClassLoader und die Startklasse org.test.App, wo das Passwort abgefragt wird.

Du kannst auch einen ClassLoader/encrypter implementieren, der ein vollständig verschlüsseltes Jar-File (de-)kodiert, aber das ist ein bisschen mehr Aufwand, weil Du über die Einträge im Jar-File Buch führen musst.

 

[Marantis]

Der Thread ist zwar schon etwas älter, allerdings ist das Problem zeitlos. Daher erwähne ich hier eine professionelle, kostenpflichtige Alternative zu dem Thema JAR-Dateien verschlüsseln. (und nein, ich bin nicht der Author der Software)

> http://www.bfa-it.com/index.php?lang=de&id=products/jarprotector

 

[mihe7]

Der Thread ist zwar schon etwas älter, allerdings ist das Problem zeitlos.

Das Problem ist zeitlos, weil es nicht gelöst werden kann. Irgendwann wird Code ausgeführt, der zu dem Zeitpunkt natürlich nicht mehr verschlüsselt sein kann und damit hat man eben auch die Möglichkeit, die Anweisungen abzugreifen. Man kann nur die Hürden erhöhen und es so einem potentiellen Angreifer so schwer wie möglich machen. Ob man das will, muss jeder selbst wissen.

Und die Seite macht jetzt auch nicht unbedingt einen absolut seriösen Eindruck: keine Namen, keine Telefonnummer, keine Datenschutzerklärung, Bezahlung nur via PayPal... Muss nix heißen, aber "professionell" sieht bei mir anders aus.

 

[Thallius]

Naja erster Beitrag gleich Werbung für ein bezahlprodukt. Was soll man wohl davon halten?

 

[Marantis]

Es ist mein erster Beitrag, weil ich aktuell selbst auf der Suche nach einer solchen Software bin. So einfach ist das.

Und wenn man bei Google "jar verschlüsseln" eingibt, landet man halt auch in 2021 hier auf der Seite "Java-Forum" und auf einigen anderen, bspw. auch auf der von BFA-IT. Mir persönlich ist es egal, ob die SW etwas kostet und wie die Webseite optisch aussieht, ist mir auch egal, wenn die Software ihren Job erledigt.

Das Problem ist zeitlos, weil es nicht gelöst werden kann

Doch, offenbar wurde bzw. wird das Problem ja gelöst, wie bspw. ja auch dem Coding Beispiel von Kay73.

seriösen Eindruck: keine Namen, keine Telefonnummer, keine Datenschutzerklärung, Bezahlung nur via PayPal... Muss nix heißen, aber "professionell" sieht bei mir anders aus.

Tja, da merkt man, dass du halt deutsche Verhältnisse gewöhnt bist und offenbar keine Ahnung von der Rechtsprechung anderer Länder hast. Der Anbieter sitzt in der Schweiz und da sehen Webseiten idR. immer so aus. Impressumspflicht und Datenschutzerklärung gibt es nur in DE bzw. in der EU, wobei es auch hier zw. den einzelnene Nationen massive Unterschiede gibt.Und andere Länder, insbesonders außerhalb der EU, wie die Schweiz, können über solche Themen nur Grinsen.

 

[LimDul]

In der Schweiz gilt keine allgemeine Impressumspflicht. Websites jedoch, die Produkte oder Dienstleistungen anbieten, unterliegen dem Bundesgesetz gegen den unlauteren Wettbewerb und dadurch auch der Impressumspflicht.

Eigene Website erstellen: Das müssen Sie rechtlich beachten | Beobachter

Wie darf ich meine Website nennen? Welche Bilder darf ich verwenden? Die wichtigsten Antworten rund um das Erstellen einer eigenen Website bekommen Sie hier.

www.beobachter.ch

#

Und weiter

Internationale Websites​

Wenn Sie über Ihre Website Waren oder Dienstleistungen ins Ausland verkaufen oder Daten von Nutzern aus dem Ausland erfassen, unterliegt das den dortigen Impressumspflichten und Datenschutzgesetzen. In der EU ist das die Datenschutzgrundverordnung (DSGVODSGVO Das bringt Ihnen das neue EU-Datenschutzgesetz)

 

[mrBrown]

Tja, da merkt man, dass du halt deutsche Verhältnisse gewöhnt bist und offenbar keine Ahnung von der Rechtsprechung anderer Länder hast. Der Anbieter sitzt in der Schweiz und da sehen Webseiten idR. immer so aus. Impressumspflicht und Datenschutzerklärung gibt es nur in DE bzw. in der EU, wobei es auch hier zw. den einzelnene Nationen massive Unterschiede gibt.Und andere Länder, insbesonders außerhalb der EU, wie die Schweiz, können über solche Themen nur Grinsen.

Liest sich für mich anders:

Unlauter handelt insbesondere, wer [...]
s. Waren, Werke oder Leistungen im elektronischen Geschäftsverkehr anbietet und es dabei unterlässt: 1. klare und vollständige Angaben über seine Identität und seine Kontaktadresse einschliesslich derjenigen der elektronischen Post zu machen,

Abgesehen davon greift da ziemlich sicher z.B. DSGVO.

 

[Marantis]

Eigene Website erstellen: Das müssen Sie rechtlich beachten | Beobachter

Wie darf ich meine Website nennen? Welche Bilder darf ich verwenden? Die wichtigsten Antworten rund um das Erstellen einer eigenen Website bekommen Sie hier.

www.beobachter.ch

#

Und weiter

Die Impressumspflicht hat er erfüllt (nach den Kriterien der Schweiz) und mehr muss er nicht. Aber du darfst die Firma gerne anschreiben und dich dort beschweren.

 

[LimDul]

Die Impressumspflicht hat er erfüllt (nach den Kriterien der Schweiz) und mehr muss er nicht. Aber du darfst die Firma gerne anschreiben und dich dort beschweren.

Für die Schweiz - wenn er in die EU handelt, unterliegt er der EU Richtlinien (Wie ich ergänzt habe)

Ergo ist die Werbung hier Unfug, weil anscheinend ja nicht legal in die EU gehandelt werden soll

 

[LimDul]

Und praktischerweise nutzt die Domain auch Privacy Protect, so als wolle man blos keine belastbaren Adressen rausgeben.

Aber immerhin gibt es ein schönes Streetview-Bild: https://www.google.com/maps/place/B...0xe096b55b3a977d8!8m2!3d47.4008752!4d9.470639

 

[mihe7]

Mal unabhängig von diesem ganzen rechtlichen Gedöns: der Punkt ist einfach, dass ich von einem professionellen Auftritt gewisse überprüfbare Angaben erwarte und wenn die fehlen, wird die Firma mit mir kein Geschäft machen. Wer zuletzt grinst, grinst am besten

 

[mihe7]

Aber immerhin gibt es ein schönes Streetview-Bild:

Scheint mir die Zentrale des Konzerns zu sein.

 

[mrBrown]

Die Impressumspflicht hat er erfüllt (nach den Kriterien der Schweiz) und mehr muss er nicht. Aber du darfst die Firma gerne anschreiben und dich dort beschweren.

anschreiben geht nicht, da keine Mail-Adresse verfügbar ist:

Unlauter handelt insbesondere, wer [...]
s. Waren, Werke oder Leistungen im elektronischen Geschäftsverkehr anbietet und es dabei unterlässt: 1. klare und vollständige Angaben über seine Identität und seine Kontaktadresse einschliesslich derjenigen der elektronischen Post zu machen,

 

[Marantis]

Wer eine technische Lösung für das Problem sucht, dem ist das ganze Gedöns hier vollkommen egal. Ich habe mir die Testversion kostenlos heruntergeladen und die SW macht, was sie soll und sie funktioniert.

 

[LimDul]

Mal unabhängig von diesem ganzen rechtlichen Gedöns: der Punkt ist einfach, dass ich von einem professionellen Auftritt gewisse überprüfbare Angaben erwarte und wenn die fehlen, wird die Firma mit mir kein Geschäft machen. Wer zuletzt grinst, grinst am besten

Genau das ist der Punkt. Es mag seriös sein - aber alle Anzeichen die man sieht, sehen für mich eher kritisch aus und nicht seriös. Ich würde von dem Produkt mit den verfügbaren Infos eindeutig abraten.

 

[kneitzel]

Wer eine technische Lösung für das Problem sucht, dem ist das ganze Gedöns hier vollkommen egal. Ich habe mir die Testversion kostenlos heruntergeladen und die SW macht, was sie soll und sie funktioniert.

Und doch löst auch die Firma das Problem nicht. Unter dem Strich hast du am Ende eine JVM mit den geladenen Klassen. Wie die davor verschlüsselt waren oder nicht ist vollkommen egal. Es wird entschlüsselt und damit kann jeder, der die Kontrolle über den Rechner hat, die Daten auslesen.

Alles was du machen kannst, ist eben die Messlatte höher zu stecken. Aber mit einer JVM bist du da immer auf verlorenem Posten, denn das Verhalten und die Implementierung sind offen gelegt. Und es gibt genug Software Reverse Engineering Tools (Ghidra von NSA sage ich nur) die es mit etwas Erfahrung/Übung zum Kinderspiel macht.

Ich hatte früher jar2exe im Einsatz. Preislich auch nicht teurer und man hatte am Ende alles schön in einer EXE und so ...

 

[mrBrown]

Hint: Werbung, die nicht nacht Werbung aussehen soll, wirkt besser, wenn man dann nicht blind das Unternehmen verteidigt

Wer eine technische Lösung für das Problem sucht, dem ist das ganze Gedöns hier vollkommen egal.

Ich kann mindestens für mich sprechen und sagen: Nein, das ist keineswegs egal.

Irgendwem, wo man nicht weiß ob da eine Einzelperson oder eine Firme oder sonstwas hintersteht, 140€ in den Rachen werfen für ein Produkt, über welches es quasi keinerlei Informationen gibt, zu unbekannten Lizenzbedingungen, welches für aktuelle Java-Versionen nicht läuft – klingt nicht nach etwas, was man machen sollte.

Vor allem, da völlig unbekannt ist, wie es eigentlich funktioniert – und das ist bei allem, was mit Verschlüsselung zu tun hat, eine riesige rote Flagge.

 

[mihe7]

Ich habe mir die Testversion kostenlos heruntergeladen und die SW macht, was sie soll und sie funktioniert.

Da ist schön und dagegen hat ja auch keiner was gesagt. Auch habe ich nicht behauptet, dass die Firma unseriös wäre, sondern dass sie bei mir keinen seriösen Eindruck hinterlässt (ob das rechtlich in Ordnung ist oder nicht, ist mir erst einmal völlig egal) und explizit dazugeschrieben, dass auch die aufgeführten Punkte alle nichts heißen müssen. Kann sein, dass das einfach ein Entwickler ist, der sein Tool verticken und so wenig Daten wie möglich preisgeben will.

Hier lesen ja auch andere mit und daher erwähne ich solche Dinge dann auch, wenn sie mir auffallen. Vielleicht hilft es jemandem bei seiner Entscheidung.

 

[Marantis]

Natürlich müssen die (class) Dateien irgendwann auch für die JVM lesbar bzw. verfügbar sein aber im Gegensatz zur Lösung von Kay73 werden die entschlüsselten Dateien nicht auf der HD abgelegt, sondern im RAM entschlüsselt und abgelegt und das legt die Hürde für einen Hack noch einmal ein ganzes Stück höher.

Natürlich ist kein Sicherheitssystem zu 100% sicher aber es genügt auch vollkommen, wenn 99% aller User einer kommerziellen Software diese nicht hacken können. Wer vorher seine SW noch mit einem Obfuscator "gesichert" und die JAR-Datei "offiziell" signiert hat, kommt mit dieser Kombination auf ein akzeptables Ergebnis.

 

[LimDul]

Ich würde soweit gehen, dass ich das Programm sogar als Scam ansehen würde.

Ich hab mir die Trial mal angesehen, warum zum Geier ein Jar-Encrypter "net use" aufrufen will, würde ich gerne mal wissen.

 

[Marantis]

Frage einfach den Entwickler. Ich habe das bereits getan und lass 'mich mal überraschen, ob und was er sagt.

 

[LimDul]

Frage einfach den Entwickler. Ich habe das bereits getan und lass 'mich mal überraschen, ob und was er sagt.

Ich fasse mal zusammen. Eine Firma ohne E-Mail Adresse, wo du die trial runtergeladen hast und du keinerlei Beziehung zur Firma hast - da fragst du mal eben den Entwickler? Klar doch

 

[mihe7]

Ich würde soweit gehen, dass ich das Programm sogar als Scam ansehen würde.

Ich hab mir die Trial mal angesehen, warum zum Geier ein Jar-Encrypter "net use" aufrufen will, würde ich gerne mal wissen.

Vermutlich ist noch ein Virenscanner integriert Vor allem: was ruft der auf einem Linuxrechner auf?

 

[Marantis]

Eine Firma ohne E-Mail Adresse

Der Entwickler hat zwar keine Mailadresse angegeben aber es gibt ein Kontaktformular. Man sollte sich die Webseite halt mal richtig ansehen, bevor man postet.

 

[mihe7]

@Marantis, hast Du schon mal einen Debugger drangehangen?

 

[Marantis]

ich bin gerade selbst am analysieren ... ihr macht mich ganz wuschig

 

[mihe7]

Tja, Du bist hier ja nicht zum Spaß da

 

[LimDul]

Die eigentlich Verschlüsselung wird von 2 DLL Files gemacht (einmal 32, einmal 64 Bit Variante), die on the fly entpackt werden.

Da hört mein Decompile Wissen dann auch auf - ich sehe zumindest einige XORs im DLL Programm (Und so Dinge wie "Debugger Check")

 

[Marantis]

dann hat die SW zumindest schon etwas bewiesen ... sie ist nicht leicht zu analysieren/hacken.

 

[betatwo]

sie ist nicht leicht zu analysieren/hacken.

1 Milliarde Chinesen können alles.

 

[mrBrown]

dann hat die SW zumindest schon etwas bewiesen ... sie ist nicht leicht zu analysieren/hacken.

Weil @LimDul's Wissen nach 30min endet sagt das eigentlich nur was über LimDul aus, aber nichts über die Software.

 

[Marantis]

Wie gesagt, 100% Schutz gibt es nicht, es genügen aber meist auch 99%

Aber hey, wenn ihr eine bessere Lösung zu dem Thema kennt ... ich bin ganz Ohr.
Und nein, Obfuscating alleine ist keine Lösung.

 

[mrBrown]

Bedingt durch die Funktionsweise sind das aber eher (spätestens bei minimaler Verbreitung) 0%.

Gib einen mit minimaler Ahnung davon etwas Zeit und das ist geknackt.

 

[betatwo]

Wie gesagt, 100% Schutz gibt es nicht, es genügen aber meist auch 99%

1% von einer Milliarde sind immernoch 10.000.000 ... also ziemlich viele, die das können.

 

[Marantis]

Bedingt durch die Funktionsweise sind das aber eher (spätestens bei minimaler Verbreitung) 0%.

Gib einen mit minimaler Ahnung davon etwas Zeit und das ist geknackt.

Dann ist die SW zwar gehackt aber der Hack ist dann auch über Hash und Signatur nachweisbar.

Unsere Kunden würden eine solche SW nie einsetzen. Zum einen, weil sie Angst davor haben, irgendwelchen Mist zu laden und zum anderen vor den rechtlichen Konsequenzen, wenn wir den Kunden den Einsatz einer gehackten SW-Version nachweisen können.

Das Einzige, das mich bzw. uns an der Lösung von BFA-IT stört ist, dass es keine OpenSource ist und wir daher selbst nicht wissen, was das Ding in Wirklichkeit macht.

Wir sind bereits am überlegen, das Tool selbst nach zu programmieren.

 

[LimDul]

Ich traue mir zu, mit genügend Zeit & Willen das zu knacken. Im Endeffekt ist es nur ein C++ implmentierter Java Classloader, der on the fly Dateien extrahiert. Soweit ich die genutzten Funktionen in dem Dekompilat durchblicke, scheint es tatsächlich genau das zu tun (Das net use find ich im Java Code aber immer noch sehr Strange).

Besonders schwer sieht das nicht, wenn man weiß man was man tut. Debugger Check rauswerfen und dann schauen was es tut. Aber so weit geht meine Motivation jetzt nicht

 

[mrBrown]

Unsere Kunden würden eine solche SW nie einsetzen. Zum einen, weil sie Angst davor haben, irgendwelchen Mist zu laden und zum anderen vor den rechtlichen Konsequenzen, wenn wir den Kunden den Einsatz einer gehackten SW-Version nachweisen können.

Hint: in dem Fall spar dir die 140€. Sowohl bei ehrlichen Kunden als auch für rechtliche Konsequenzen brauchst du keine Verschlüsselung.

 

[mrBrown]

Ich traue mir zu, mit genügend Zeit & Willen das zu knacken. Im Endeffekt ist es nur ein C++ implmentierter Java Classloader, der on the fly Dateien extrahiert. Soweit ich die genutzten Funktionen in dem Dekompilat durchblicke, scheint es tatsächlich genau das zu tun (Das net use find ich im Java Code aber immer noch sehr Strange).

Besonders schwer sieht das nicht, wenn man weiß man was man tut. Debugger Check rauswerfen und dann schauen was es tut. Aber so weit geht meine Motivation jetzt nicht

Vielleicht reicht es sogar einfach schon, die class-Datei als Resource zu laden?


Verschlüsselung, die nur über das geheimhalten des Verschlüsselungsverfahrens funktioniert, ist halt generell nie sinnvoll...

 

[mihe7]

Hint: in dem Fall spar dir die 140€. Sowohl bei ehrlichen Kunden als auch für rechtliche Konsequenzen brauchst du keine Verschlüsselung.

Dem möchte ich mich anschließen: wir haben weder Obfuscatoren noch sonst was im Einsatz.

Wozu? Der Otto-Normal-Kunde interessiert sich für den Quelltext nicht und wer es darauf anlegt, wird ihn erhalten. Außerdem sind die meisten Anwendungen bei uns mit Server-Aufrufen verbunden und ohne die Anbindung an den Server ist die Software nahezu nutzlos. Allerdings sind wir auch in bestimmten Branchen unterwegs, also nix, was sich irgendwie an Entwickler oder ähnliches richten würde.

 

[Marantis]

So ganz uninteressant ist das Thema mit der Absicherung nicht, denn wir haben nachweislich eine spürbare Umsatzsteigerung verbucht, nur weil wir bspw. Signaturen und Obfuscating, personifizierte Kompilate und Online-Überprüfung der Lizenzen eingesetzt haben, ohne dass sich etwas an der Funktionalität geändert hätte.

Früher hatten wir bspw. häufig den Fall von CC-Stornierungen oder Zahlungen über gestohlene CC. Heute schalten wir in dem Fall die SW remote ab, sobald sie sich im Web befindet und die Lizenz nicht ordnungsgemäß bezahlt wurde, wie das bspw. auch bei Microsoft und Adobe der Fall ist.

Plötzlich wurden mutmaslich unehrliche Kunden zu ehrlichen Kunden. Zumindest hatten wir danach plötzlich eine rege Anfrage nach echten Lizenzen.

Mit der Verschlüsselung der JAR-Datei gehen wir einfach nur einen weiteren Schritt bzgl. der Absicherung. Weiter wollen allerdings nicht gehen. Der Einsatz von Tools, wie bspw. DRM-Tools aka SecuRom, usw. kommt für uns nicht in Frage.

Aber ganz ohne Absicherung geht es offenbar auch nicht.

 

[LimDul]

So ganz uninteressant ist das Thema mit der Absicherung nicht, denn wir haben nachweislich eine spürbare Umsatzsteigerung verbucht, nur weil wir bspw. Signaturen und Obfuscating und personifizierte Kompilate eingesetzt haben, ohne dass sich etwas an der Funktionalität geändert hätte.

Plötzlich wurden mutmaslich unehrliche Kunden zu ehrlichen Kunden. Zumindest hatten wir danach plötzlich eine rege Anfrage nach echten Lizenzen. Mit der Verschlüsselung der JAR-Datei gehen wir einfach nur einen weiteren Schritt bzgl. der Absicherung. Weiter wollen allerdings nicht gehen. Der Einsatz von Tools, wie bspw. DRM-Tools aka SecuRom, usw. kommt für uns nicht in Frage.

Aber ganz ohne Absicherung geht es offenbar auch nicht.

Kommt halt immer auf den Einsatzzweck an.

Ich hab hier schon mehrfach gepredigt, man muss sich genau überlegen, was man wie schützt und vor wem.
Den klar ist - jeder Schutz nervt mehr oder weniger auch ehrliche Kunden,

Was z.B. mit dem Tool das was du verlinkt hast ein klares Problem ist: Non Windows Plattformen - da ist eine win32 und win64 dll drin, Linux schaut in die Röhre. Mag euch nicht betreffen - aber ist auch ein zu berücksichtigender Punkt.

Deswegen gibt es kein Pauschalrezept sondern man muss überlegen:
* Geht man davon überhaupt aus, dass die Software weitergegeben wird (Je nach Software mehr oder weniger wahrscheinlich)
* Hat man eine Idee wie sie weitergegeben wird (Wird sie z.B. einfach auf mehr Rechnern genutzt als Lizenzen vorhanden oder wird sie tatsächlich komplett an Dritte weitergegeben)
* Wird sie einfach nur weitergegeben oder wird dabei bewusst die Software manipuliert um z.B. Hinweise auf den originalen Lizenznehmer zu entfernen

Dann kann man Maßnahmen überlegen wie:
* Seriennummern
* Personalisierte Kompilate
* Code Obfuscator
* Optionale Online-Background Checks zur Überprüfung von blacklisted Seriennummern
* Erzwungene Online-Checks zur Überprüfung von Seriennummern

etc.

Und man muss halt das Pro/Contra abwägen.

 

[temi]

Wer eine technische Lösung für das Problem sucht, dem ist das ganze Gedöns hier vollkommen egal.

Also mir ist das nicht egal. Ich schaue schon, was ich auf meinem Rechner installiere.

 

[Marantis]

Was z.B. mit dem Tool das was du verlinkt hast ein klares Problem ist: Non Windows Plattformen - da ist eine win32 und win64 dll drin, Linux schaut in die Röhre. Mag euch nicht betreffen - aber ist auch ein zu berücksichtigender Punkt.

Das Tool von BFA -IT gibt es auch für Linux und OSX, nicht nur für Windows.

Den klar ist - jeder Schutz nervt mehr oder weniger auch ehrliche Kunden,

Die Kunden sind mittlerweile gewöhnt Codenummer zur Aktivierung einzugeben und akzeptieren auch die Online-Überprüfung. Wie gesagt Microsoft, Adobe, usw. gehen diesen Weg schon lange.

Und selbst im Linuxbereich gibt es zunehmend kommerzielle Produkte mit Aktivierungspflicht, bspw. die ganzen Spiele von Steam unter Linux. Und da regt sich auch kein Mensch drüber auf.

 

[LimDul]

Die Kunden sind mittlerweile gewöhnt Codenummer zur Aktivierung einzugeben und akzeptieren auch die Online-Überprüfung. Wie gesagt Microsoft, Adobe, usw. gehen diesen Weg schon lange.

Und selbst im Linuxbereich gibt es zunehmend kommerzielle Produkte mit Aktivierungspflicht, bspw. die ganzen Spiele von Steam unter Linux. Und da regt sich auch kein Mensch drüber auf.

Klar - aber auch nicht jeder Kunde. Je nach Software ist es im professionellen Umfeld problematisch, wenn die nach außen telefonieren wollen. Oder wenn die Software nicht läuft, wenn man offline ist.

Deswegen muss man es abwägen. Und in soweit stimme ich dir zu, mittlerweile ist Online Zwang (leider) so verbreitet, dass kein generelles KO-Kriterium ist.