Bedeutet Java automatisch OpenSource?

[Guest]

Hi,

ich hab jetzt schon des Öfteren gelesen, dass es gar kein Problem ist aus einer *.class-Datei eine .*java-Datei zu machen - also den Quellcode zu holen. Das bedeutet doch letztlich, dass jeder problemlos meine Quellcode ansehen kann, oder? Oder wie kann ich den schützen?

 

[Murray]

Man kann den Java-Bytecode mithilfe eines Decompilers in gleichwertigen Source-Code übersetzen - gleichwertig aber nur in dem Sinne, dass aus den durch den Decompiler generierten Sourcen wieder exakt der gleiche Bytecode erzeugt werden kann. Beim Decompilieren lassen sich aber Formatierungen, Kommentare und die Namen lokaler Variablen nicht wiederherstellen, weil diese Dinge überhaupt nicht im Bytecode landen - insofern ist der vom Decompiler erzeugte Code nicht identischem mit dem Original.
Wenn die Rückübersetzbarkeit des Bytecodes für Dich ein Problem darstellt, gibt es zwei Lösungsansätze: erstens kannst Du in den Nutzungsbedingungen das Decomplilieren verbieten; damit verhinderst Du es zwar nicht, aber derjenige, der das Programm trotzdem decompiliert, riskiert verklagt zu werden - Profis ist das meist schon abschreckend genug.
Ansonsten kannst Du Dein Programm auch so krytisch schreiben, dass die Quelltexte nicht zu verstehen sind - also z.B. Klassen und Methoden nicht mit sprechenden Namen, sondern mit ABC, CYZ, b123 etc. bezeichnen. Da man sich damit aber natürlich selbst Steine in den Weg liegt, gibt es Programme, die einen bis dahin lesbaren Quelltext möglichst unwartbar umbennen; such dazu mal nach dem Begriff "Obfuscator". Normalerweise arbeiten man auf einer vernünftigen Quelltextversion und wirft diese dann vor dem Relase dem Ofuscator vor. Der erzeugt dann einen Quelltext, den kein normaler Mensch mehr verstehen kann. Und diesen Quelltext übersetzt man dann und liefert nur den so erzeugten Bytecode aus.

 

[Wildcard]

Es gibt auch für andere Sprachen decompiler.
Letztlich schützt dich nur das Gesetz, du kannst es mit einem Obfuscator jedoch schwieriger machen deinen Quelltext zu entziffern.

 

[foobar]

Zusätzlich zu einem Obfuscator kannst du dein Jar auch in einem Executable verpacken.

 

[Gelöschtes Mitglied 5909]

http://www.galileocomputing.de/open...sel26_005.htm#Rxx747java2600504000A061F045100

schau dir das mal an, da steht einiges übers kompilieren und übers erschweren

 

[Novanic]

Hi,

"Beim Decompilieren lassen sich aber Formatierungen, Kommentare und die Namen lokaler Variablen nicht wiederherstellen."

Was soll dann der Obfuscator bringen, wenn die Variablennamen sowie so nicht im Bytecode hintelegt sind?

Es gibt auch noch die Möglichkeit richtig zu Kompilieren. Allerdings geht dabei die Plattformunabhängigkeit flöten.
Die berühmtesten sind wohl der Jet-Compiler und GCJ.

Mich stört es auch, dass Java-Bytecode so einfach zu dekompilieren ist. Das ist besonders kritisch wenn man z.B. Lizenzüberprüfungen hat, dass kann man dann völlig knicken.
Es ist auch ziemlich blöd, wenn man eine ganz tolle Idee hat und die Idee schön in Java umsetzt. Wenn du damit dann Geld verdienen möchtest, kommt einfach ein Anderer, klaut die Sourcen und baut es ein wenig weiter aus... Fänd ich ziemlich "ärgerlich".
Warscheinlich gibt es deswegen kaum kommerzielle Java-Programme...

Gruß Nova

 

[thE_29]

Obfuscate bringt dass, das Methodenname, Klassennamen, Klassenvariablen etc umbenannt werden, sodaß es keinen Sinn mehr ergibt!

Was imho schon wieder die Codenachverfolgung schwieriger macht!

Es gibt auch eine kostenspieligere Version, wo der Bytecode verschlüsselt wird und vor dem ausführen hängt sich das Ding in die VM und entschlüsselt das wieder!

Irgendwo im Board gabs von deathbyaclown mal einen Link mit ner Grafik dazu!

 

[Roar]

@Novanic: das stimmt doch so aber überhaupt nicht. es gibt genug programme in java mit ner vernünftigen lizenzprüfung. ne anständige prüfung ist in java genauso schwer bzw. einfach zu knacken wie in einem nativ kompiliertem programm.

und nur weil du und ich solche nicht benutzen, heißt das nicht, dass es keine kommerziellen java programme gibt, die gibts nähmlich wie sand am meer. und dekopmilierten source code klauen - wer macht denn sowas, da gehts ja schneller das gleiche selber neu zu entwickeln als den code zu dekopmilieren, wieder herzurichten und einzubauen - vom rechtlichen ganz abgesehen ???:L

 

[byte]

Es gibt auch noch die Möglichkeit richtig zu Kompilieren. Allerdings geht dabei die Plattformunabhängigkeit flöten.
Die berühmtesten sind wohl der Jet-Compiler und GCJ.

Die benutzen aber nicht die Sun API und unterstützen deshalb nicht alle Standard Klassen.

Mich stört es auch, dass Java-Bytecode so einfach zu dekompilieren ist. Das ist besonders kritisch wenn man z.B. Lizenzüberprüfungen hat, dass kann man dann völlig knicken.

Du tust fast so, als ob das an der Tagesordnung wäre. Im Zweifelsfall kannst Du immernoch Dein Recht bei Verstoß gegen das Urheberrecht einklagen.

Es ist auch ziemlich blöd, wenn man eine ganz tolle Idee hat und die Idee schön in Java umsetzt. Wenn du damit dann Geld verdienen möchtest, kommt einfach ein Anderer, klaut die Sourcen und baut es ein wenig weiter aus... Fänd ich ziemlich "ärgerlich".

Das Problem hat aber nix mit Java oder dem Bytecode zu tun, das besteht generell in der Softwareentwicklung. Das geht dann eher in Richtung Software-Patente und da gibt es ja sehr kontroverse Diskussionen drüber.

Warscheinlich gibt es deswegen kaum kommerzielle Java-Programme...

Wie kommst Du auf sowas? Nur weil die paar Standard Windows Tools in C++ geschrieben sind? Es gibt haufenweise kommerzielle Java Programme. Die stehen nur nicht bei Media Markt und Co. im Regal sondern sind zum größten Teil Business Anwendungen oder Individualsoftware, die domain-spezifisch nach Auftrag entwickelt werden. Und dazu kommen die ganzen Server/Web Anwendungen, die Du täglich - wenn vielleicht auch nicht bewusst - im Internet ansteuerst.

 

[Guest]

Ja, bei den kommerziellen Produkten dachte ich eher an Produkte für den normalen Anwender. Das eine Firma für ihre gecrackte Software verwendet, hätte ich auch nicht angenommen. ;-)

Also eine Lizenzüberprüfen anhand der Sourcen auszuschalten ist wohl schon etwas leichter als mit nativen, binären Dateien. ;-)

 

[Roar]

Ja, bei den kommerziellen Produkten dachte ich eher an Produkte für den normalen Anwender. Das eine Firma für ihre gecrackte Software verwendet, hätte ich auch nicht angenommen. ;-)

???:L

Also eine Lizenzüberprüfen anhand der Sourcen auszuschalten ist wohl schon etwas leichter als mit nativen, binären Dateien. ;-)

ne, du kannst nativ kompilierte programme genauso dekopmilieren wie java programme. was es da so gibt an decopmilern und was die können für op code weiß ich nich, is aber auch egal. geht schileßlich nich darum zu erkennen: oh hier is ne schleife sondern zu verstehen wie der algorithmus funktioniert und da machts am ende keinen unterschied mehr in welcher programmiersprache der geschrieben ist

 

[byte]

Also eine Lizenzüberprüfen anhand der Sourcen auszuschalten ist wohl schon etwas leichter als mit nativen, binären Dateien. ;-)

Du kannst nativ kompilierte Programme genaus dekompilieren wie den Bytecode von Java. Google einfach mal nach Reverse Engineering, Disassembler oder IDA. Dann findest Du mehr zu dem Thema.

Oder dachtest Du etwa, diese ganzen Cracker sprechen Binär in Echtzeit und sitzen vor lauter Nullen und Einsen? :roll:

 

[Guest]

Oder dachtest Du etwa, diese ganzen Cracker sprechen Binär in Echtzeit und sitzen vor lauter Nullen und Einsen? :roll:

Ne, ich dachte da eher an Hex-Editoren. Also ich kenn sonst nur noch Decompiler für Visual Basic 4. Und für höhere Visual Basic Version gab es keinen Decompiler.
Und ich denke für z.B. C++ gibt es überhaupt keine Decompiler und wenn doch sind sie illegal. Aber bei Java scheint das generell ganz offiziell und legal zu sein, es sei denn man schreibt eine Klausel in seine Lizenzbestimmungen.

Ich muss den Algorithmus für die Lizenzüberprüfung verstehen oder welchen Algorithmus muss ich deiner Meinung nach verstehen? Wenn man die Sourcen hat, könnte man die Lizenzprüfung entweder komplett ausbauen oder einfach umgehen "return true;". ;-)[/quote][/quote]

 

[bronks]

... Also ich kenn sonst nur noch Decompiler für Visual Basic 4. Und für höhere Visual Basic Version gab es keinen Decompiler.

Bei MS ist das schöne, daß alles streng geheim (Gegenteil von open) ist. Da ist sogar MS-Access eine unbezwingbare Burg, wenn man die Sicherheit richtig eingestellt hat. Das ist einer der großen Vorteile, die man mit MS-Produkten hat.

... Und ich denke für z.B. C++ gibt es überhaupt keine Decompiler und wenn doch sind sie illegal ...

C++ ist ein bissl verwirrend zu lesen, aber C kann wunderbar disassembled werden.

Aber bei Java scheint das generell ganz offiziell und legal zu sein, es sei denn man schreibt eine Klausel in seine Lizenzbestimmungen.

Da ist es genauso legal und offiziell, wie bei C++. In Java wird aus fast nichts ein Geheimnis gemacht und entsprechend wurde Java entwickelt. Es hat keinen sinn aus ClosedSource irgendwas zu klauen, weil man immer etwas vergleichbares open bekommt.

... Ich muss den Algorithmus für die Lizenzüberprüfung verstehen oder welchen Algorithmus muss ich deiner Meinung nach verstehen? Wenn man die Sourcen hat, könnte man die Lizenzprüfung entweder komplett ausbauen oder einfach umgehen "return true;". ;-)

Hacken kann man absolut alles. Das ist keine neuheit aus der JavaWelt.

 

[Guest]

Ne, ich dachte da eher an Hex-Editoren.

Ok, dann ist dir hoffentlich klar, dass es Menschen gibt die weiter denken als du.

Und ich denke für z.B. C++ gibt es überhaupt keine Decompiler und wenn doch sind sie illegal.

Hast du irgendwie etwas nicht richtig verstanden? Nativer Code ist immer gleich. Dein OS interessiert sich nicht dafür, ob es ursprünglich in C, C++, Delphi, Lisp, Haskell, XYZ oder Java geschrieben wurde. Was auch immer du davon nativ linkst ist direkt ausführbar für das System und kann (von ein und dem selben) Dissassembler in Assembler umgewandelt werden. Da du häufig auf Klassenbibliotheken setzt findest du also auch gute Programme, die dir unter Windows z.B. die MFCs oder die VCL Klassen wieder teilweise anzeigen können.

Ich muss den Algorithmus für die Lizenzüberprüfung verstehen oder welchen Algorithmus muss ich deiner Meinung nach verstehen? Wenn man die Sourcen hat, könnte man die Lizenzprüfung entweder komplett ausbauen oder einfach umgehen "return true;".

Ich muss nochmal sagen, es gibt Menschen die einfach weiter denken als du. Die entwickeln entsprechend auch bessere Lizenzprüfungen. Nicht alles wird einfach über ein return true geregelt. Ich weiß nicht in weit du mit dem Thema Mathematik vertraut bist, solltest du dir mal anschauen! Da kann man tolle Sachen machen, z.B. Dinge verschlüsseln ohne ein true zu verwenden. Zudem kannst du auch die Abfragen an mehr als eine Stelle im Code verstecken und wenn du dir mal disassemblierten Code anschaust, dann merkst du schnell, dass das eine true nicht schnell zu finden ist. Auch hier gibt es natürlich Hilfsmittel, aber das ist eine andere Sache.
Sicherheit gibt es halt nicht, aber du kannst den Aufwand beliebig groß halten. Ist halt günstiger die Software zu kaufen.

Jedenfalls kann ich hier nur sagen, dass du dir erstmal die Möglichkeiten (die oft genug auch in anderen Foren diskuttiert werden) anzuschauen, dir eine Basis an Wissen zu schaffen und dann mal etwas zu schreiben (und nicht nur das was du glaubst).

Gruß Der Anmeldeboykottierer

 

[Guest]

Also ich weiß jetzt nicht was du tolles mathematisches berechnen willst, aber normalerweise nimmt ein Programm eine Lizenz an und überprüft die Lizenz auf Gültigkeit. Wie die Gültigkeit überprüft wird ist absolut unwichtig, wenn ich die Sourcen einfach so modifiziere, dass immer "ist gültig" (true) zurückkommt. Da kannst du dir noch so tolle Algorithmen ausdenken...

 

[Guest]

"Dein OS interessiert sich nicht dafür, ob es ursprünglich in C, C++, Delphi, Lisp, Haskell, XYZ oder Java geschrieben wurde.". Ich wusste noch garnicht dass Java Betriebssystemabhängig ist, dass ist ja ein Ding, dann brauch ich ja garkeine JVM mehr... *gg*

 

[byte]

"es" = das (nativ kompilierte) Programm, nicht "es" = das Betriebssystem.

Und ja, Java ist betriebssystemabhängig. Deswegen lädst Du Java auch in Abhängigkeit zu Deinem Betriebssystem runter. Einzig die mit Java geschriebenen Programme können bestriebssystemunabhängig sein.

 

[Anmeldeboykottierer]

Nativer Code ist immer gleich. Dein OS interessiert sich nicht dafür, ob es ursprünglich in C, C++, Delphi, Lisp, Haskell, XYZ oder Java geschrieben wurde.

Es = Grammatik Fehler, er wäre hier richtig. Es bezieht sich auf gelinkten Code. Die GCC hat doch z.B. die Möglichkeit (oder hatte sie mal) Java Code auch in nativen Assembler zu verwandeln (nicht in den für die JVM). Wie das genau geht steht (und da bin ich mir sicher) in den FAQs dieses Forums, findet man hier als ersten Post!

Was ich tolles mathematisches berechnen will ist die Gültigkeit der Lizenz. Ich kenne nicht die Einheitslizenz, die man einfach mit istLizenzGültig == true überprüft.
Dir ist schon klar, dass es Rechnergebundene Lizenzen gibt? Deswegen möchten Firmen wie MS oder Adobe gerne mal, dass du eine Internetverbindung aufbaust und ein paar Daten übermittelst. Was machen die wohl mit den Daten? Doch nichts berechnen?! Oder doch?

Schau dir einfach mal an, was für Nummern deine HW so hat. Da findest du dann eine Menge Ansatzpunkte für Lizenzprüfungen. Du kannst einfach schauen, ob bestimmte Nummern in eine mathematische Funktion gesteckt, die z.B. einen Hashberechnet mit einem Datum dass du abgespeichert hast übereinstimmen. Dann hättest du deine leicht zu patchende Abfrage und ein Problem (irgendwann liegt natürlich das Datum offen im Speicher).
Anders sieht es aber aus, wenn du Teile deines Programms nur über diese Zahl entschlüsseln kannst. Das ganze geht dann nur noch auf einer HW. Tja, und dann hast du mathematik und eine Lizenzprüfung (zumindest eine Möglichkeit dafür).

Andere Möglichkeiten eine gültige Lizenz zu prüfen besteht in Dongles, auch die basieren (wie überraschend) auf Mathematik. Auch hier kannst du nicht einfach einen alternativen Selbstbau nehmen, der halt den gleichen Port belegt. Würde hier immer ein True über das Dongle zurückgegeben werden, wäre das wohl kaum Fälschungssicher. Wenn du aber hier vom Dongle etwas berechnen lässt...
Nebenbei bemerkt gibt es eine ganze Menge kommerzieller Anbieter, die dir die Sicherheit bei der Lizenzprüfung ermöglichen wollen, da findest du aus irgendeinem Grund auch solche, die man für C++ verwenden kann.