Quellcode absichern?

[NDEBUG]

Hallo, einfache Frage... Erstelle ich ne jar-Datei aus meinen *.java Dateien, dann compiliert er daraus ja *.class Dateien. Wie ich nu im Internet gefunden habe, sind die sehr einfach mit kostenlosen Programmen wieder in den Quellcode zurückübersetzbar. Kann man da was machen, damit daß nicht mehr geht? Weil ich ja vielleicht nicht will, daß andere mal einfach so meinen Source Code anschauen können. Exe-Dateien wird man ja vermutlich zwecks Plattformunabhängigkeit nicht erstellen können.

 

[Der Müde Joe]

>Kann man da was machen, damit daß nicht mehr geht?

Nein. es gibt zwar Obfuscatoren, welche den Quelltext lesen erschweren (a, b, c ... anstatt maxVelocity, xSize...) aber dekompilieren kann mans trotzdem.

 

[maki]

Diese Problem gibt es nicht nur bei Java, sondern auch bei .Net sobald Bytecode erzeugt wird.
Es gibt sog. "Obfuscator", aber der Einsatz lohnt sich wohl bei dir nicht und diese haben auch ihre Tücken.

Was ist denn so geheim an deinem Quellcode wenn ich fragen darf?

 

[NDEBUG]

Was ist denn so geheim an deinem Quellcode wenn ich fragen darf?

Revolutionäre, nie dagewesene Design Patterns ... die ich erst in meinem in 10 Jahre erscheinenden Buch "Design Patterns des nächsten Jahrtausends" öffentlich machen wollte.

Aber im ernst, dann schießt sich Java als kommerzielle Plattform ja wohl mal ab oder seh ich hier was falsch?

 

[maki]

Aber im ernst, dann schießt sich Java als kommerzielle Plattform ja wohl mal ab oder seh ich hier was falsch?

Nein, wieso denn?
Schon mal darauf geachtet wieviel kommerzielle SW es in Java gibt?

Im Prinzip lässt sich jedes Kompilat dekompilieren, egal ob Assembler, C/C++, C# oder Java, das Ergebnis ist dann mehr oder weniger nah am Original, aber eigentlich nie der Original Quellcode. Ist nur eine Frage des Aufwandes... aber illegal ist es meist, solange es sich nicht um OSS handelt, und in diesem Falle macht dekompilieren wenig Sinn
Es gibt sogar Stimmen die sagen, mal sollte nix Obfuskieren (gibt es dieses Wort überhaupt? :noe, denn so lässt sich am einfachsten ein Verstoss gegen das Urheberrecht nachweisen.

Ist für den Otto-Normal Entwickler aber meist uninteressant, wer hat schon so tolle Algorythmen die sonst keiner kennt. Ganz abgesehen davon, das nicht selten das Projekt schon GPL ist, ohne dass der Entwickler das weiss, dazu reicht es schon den MySQL Treiber zu nutzen

Gab dieses Thema schon öfters hier, einfach mal suchen.

 

[SlaterB]

kommt auf den Wunsch nach Dekompilierung an,
wenn es so begehrte Software wäre, zu denen jetzt schon Seriennummern/ Kopierschutz usw. geknackt wird,
dann wird es mit Java sicher nicht schwerer

 

[NDEBUG]

Hmmm kann mich damit ja nicht recht anfreunden, daß jeder meinen Source Code mit wenigen Mausklicks angucken kann. Bei Assembler/c/c++ usw. ist das Reverse-Engineering recht anspruchsvoll und braucht viel Erfahrung. Vielleicht gibts auch dafür Tools die das erledigen. Die dürften dann aber schweineteuer sein.

EDIT: kopierschutz wenn jeder den source code dazu anschauen kann is ja mal witzlos...

 

[maki]

Hmmm kann mich damit ja nicht recht anfreunden, daß jeder meinen Source Code mit wenigen Mausklicks angucken kann.

Wie gesagt, das dekompilat entspricht eigentlich nie 100% dem Original Quellcode, kann aber verstehen dass das eine neue Erfahrung ist, an die man sich erstmal gewöhnen muss.

Wenn du dich dadurch besser fühlst, kannst du ja einen Obfuscator nutzen, ich wage aber zu bezweifeln das es sich lohnt

EDIT: kopierschutz wenn jeder den source code dazu anschauen kann is ja mal witzlos...

Kopierschutz war auch vorher witzlos Deswegen geht der Trend seit Jahren hin zu Client/Server basiertem freischalten der SW oder gar Dongels..

 

[Jango]

...dann schießt sich Java als kommerzielle Plattform ja wohl mal ab oder seh ich hier was falsch?

Nein. Du siehst das richtig.

 

[Marco13]

Oooch naja... als "kommerzeille Plattform" vielleicht, aber nicht als Sprache für kommerzielle Anwendungen.

 

[Spacerat]

Ich höre in diesem Zusammenhang komischerweise immer nur "Obfuscator". Hab' mich diesbezüglich auch schon öfters dazu geäussert, das es möglich ist, Klassen (Bytecode) zu verschlüsseln, wodurch direktes dekompilieren zunächst erstmal verhindert wird. Derartig verschlüsselte Klassen müssten dann natürlich mit einem speziellen Classloader geladen werden. Dieser Classloader ist bisher die einzig erkennbare Schwachstelle in diesem Verfahren und, obwohl dessen Sicherheit von der bzw. den verwendeten Verschlüsselungsart(en) abhängt, ist es definitiv standhafter als "obfuscation" aber natürlich auch nicht 100%ig sicher. Ich selbst hab' auch so meine Schwierigkeiten meine Codezeilen vor mir selbst zu schützen.
@Edit: ...und egal wo... C++, Java, usw. Disassemblys zu Verstehen ist nicht all zu schwer. Assembler ist nunmal die einfachste Programmiersprache der Welt, für mich jedenfalls. Leider ist Assembler nicht so komfortabel wie irgendwelche OOPs. Aber IdaPro sei Dank ist nichts wirklich sicher.

 

[void]

Ich verstehe das Grundproblem ehrlich gesagt nicht, denke mal das mit den "revolutionären Pattern" war nicht ganz ernst gemeint und was gibt es sonst schon groß zu verheimlichen?

 

[Spacerat]

...wie jetzt... "Ich verstehe das Grundproblem nicht"? Das Grundproblem ist doch eigentlich immer das selbe. Der Schutz der Software. Z.B. verheimlichen, wie ein spezielles Lizensierungsverfahren, ein spezieller Kopierschutz oder was auch immer funktioniert. Was gibts da nicht zu verstehen? Aus welchem Grund sind denn die meisten Anwendungen kopiergeschützt? Warum sollte man den in irgendwelchen Anwendungen Lizensierungsverfahren einbinden? Ist doch völlig Klar... zum Geld verdienen oder nicht?

 

[Ebenius]

Ich wollte nur mal eben anmerken, dass keines Wegs die meisten Anwendungen kopiergeschützt sind; das glaube ich frühestens, wenn ich dazu vernünftige Zahlen sehe. Außerdem ist Java keines Wegs kommerziell unnütz, sonst hätte ich ja schließlich keinen (oder nicht meinen jetzigen) Job.

Ebenius

 

[Spacerat]

Mehr oder weniger gute Copy-Locks (Kopierschütze? hmmm) findet man eigentlich nur bei irgendwelchen Spielen, welche letztenendes auch Anwendungen sind. Obendrein haben die dann auch manchmal noch ein ausgeklügeltes Lizensierungsverfahren. Und wenn man sich in irgendwelchen Computergeschäften mal umsieht, ist das Angebot an Spielen meist höher, als der Anteil der übrigen Anwendungen. Spiele sind im Gegensatz zu ernsthaften Anwendungen eben auch Massenware und wären viel teurer, wenn man statt eines Copy-Locks Lizenzdongles verwendet. Daraus erschliesst sich dann der Wahrheitsgehalt meiner Aussage, es gäbe mehr Copy-Locks als Lizenzverfahren. Braucht man immer noch irgendwelche Zahlen?

 

[maki]

Die (kommerziellen) Anwendungen die ich schreibe sind allesamt für dem Kunden, gehören ihm inkl. Quellcode etc., hatte noch nie den Fall dass der Kunde einen Kopierschutz wollte/brauchte.

Ist wohl eher etwas für Leute die eigene Anwendung schreiben um damit reich und berühmt zu werden.

Zum Thema "revolutionäre Pattern"..
Wenn es keiner kennt, íst es kein Pattern

 

[Spacerat]

Die (kommerziellen) Anwendungen die ich schreibe sind allesamt für dem Kunden, gehören ihm inkl. Quellcode etc., hatte noch nie den Fall dass der Kunde einen Kopierschutz wollte/brauchte.

??? Was sind denn das für Kunden? Ich meine, wenn man seine Anwendungen speziell für einen Kunden zuschneidet und sie diesem dann inklusive Quellcode verkauft, verdient man dadurch zwar sein Geld, die speziell entwickelte Software bleibt aber "einmalig", ist deswegen nicht komerziell und braucht auch nicht geschützt werden. Nur deine Kunden haben Nutzen von deinen Entwicklungen.

Ist wohl eher etwas für Leute die eigene Anwendung schreiben um damit reich und berühmt zu werden.

Eben: Das macht komerzielle Software aus. Z.B. Windows, MS-Office, Need for Speed, Diablo3 usw.

Zum Thema "revolutionäre Pattern"..
Wenn es keiner kennt, íst es kein Pattern

Da fehlt noch ein Rudel Ausrufezeichen :lol:

 

[bygones]

??? Was sind denn das für Kunden? Ich meine, wenn man seine Anwendungen speziell für einen Kunden zuschneidet und sie diesem dann inklusive Quellcode verkauft, verdient man dadurch zwar sein Geld, die speziell entwickelte Software bleibt aber "einmalig", ist deswegen nicht komerziell und braucht auch nicht geschützt werden. Nur deine Kunden haben Nutzen von deinen Entwicklungen.

und ? ist bei uns genauso... der Kunde ist "Eigentuemer" des Quellcodes und das will er auch vertraglich zugesichert haben.
Ausserdem versteh ich nicht den kausalen zusammenhang von einmalig und nicht kommerziell.
Und natuerlich haben nur die Kunden Nutzen von der Entwicklung - ich selbst oder die Firma brauchts bestimmt net, wurde ja fuer den Kunden entwickelt...

kommerzielle Software heisst nicht per se "ich erschaffe was und scheffel damit geld indem es tausende von menschen nutzen"... die Software hier bei uns geht auch fuer einige Millionen weg, nur halt fuer einen Kunden - das nenn ich dann auch kommerziell

 

[Marco13]

Nein. es gibt zwar Obfuscatoren, welche den Quelltext lesen erschweren (a, b, c ... anstatt maxVelocity, xSize...) aber dekompilieren kann mans trotzdem.

Dazu noch ein Nachtrag: Obfuscatoren wie RetroGuard verändern nicht nur die Variablen- und packagenamen in der beschriebenen Form, sondern setzen für diese Namen auch Schlüsselwörter ein. Ich kann mir gut vorstellen, dass ein normaler Decompiler dort an seine Grenzen stößt, und nur solchen Code ausspuckt wie

package a.c.d;

import a.c.e.e;
import a.c.d.e;

class int
{
    private int while(a a, d do)
    {
        int class = 0;
        for(int float=0; float<5; float++)
        {
            float break = a.b(float);
            class += do.switch(break);
        }
        return class;
    }
}

Das bringt einem dann auch nicht so viel....

 

[schalentier]

.. Was gibts da nicht zu verstehen? Aus welchem Grund sind denn die meisten Anwendungen kopiergeschützt? Warum sollte man den in irgendwelchen Anwendungen Lizensierungsverfahren einbinden? Ist doch völlig Klar... zum Geld verdienen oder nicht?

Der Punkt ist nur, dass die Kopierschutze IMHO voellig fuern Popo sind. Gugg dir doch mal die einschlaegigen Seiten an... nen Crack gibts meisten mit dem Release und manchmal auch ne Woche spaeter. Fuer Serials jeder Art gibts Key-Generatoren.

Und warum? Weil man Quellcode und dessen Compilate per se nicht schuetzen kann. Spaetestens zur Ausfuehrungszeit der Software muss das Compilat entschluesselt, entpackt, was-auch-immer werden. Ja, man kann als Entwickler viiiel Zeit und Energie hernehmen, um es einem Angreifer so schwer wie moeglich zu machen. Aber waere diese Zeit/Energie nicht sinnvoller in der eigentlichen Anwendung untergebracht? Denn diese wird dadurch logischerweise etwas besser (z.B. bugfreier), was fuer mich den Kaufanreiz deutlich staerker erhoehen wuerde, als ein Kopierschutz/Obfuscator/Dongle.

 

[Spacerat]

Uhhh... nu' weichen wir aber vom Thema ab... Was komerziell bedeutet muss ja nicht geklärt werden. Der Unterschied zwichen speziell entwickelter Software und "kommerzieller" Software ist schlicht der: Eure Firmen verkaufen Software im allgemeinen; Eurer Handelsgut ist "Software". Ein Softwarehaus (z.B. Egosoft) handelt mit namentlich benannten Software-Produkten wie z.B. "X3 - Terran Conflict". Das Handelsgut ist dieses eine Produkt (... in diesem Fall eines aus einer Produktpalette).
BTT schlag ich vor...
@Schalentier: Da sind wir ja schonmal einer Meinung. Und die, die unsere Meinung nicht teilen, wollen dann irgendwelche Schutzmechanismen in ihre Software eingebaut haben und eröffnen Threads wie diesen hier. Die Antwort ist und bleibt die gleiche: "Man kann es Crackern nur schwerer machen!". Vllt. wäre für dieses Thema langsam mal ein Sammelthread sinnvoll.

 

[maki]

??? Was sind denn das für Kunden? Ich meine, wenn man seine Anwendungen speziell für einen Kunden zuschneidet und sie diesem dann inklusive Quellcode verkauft, verdient man dadurch zwar sein Geld, die speziell entwickelte Software bleibt aber "einmalig", ist deswegen nicht komerziell und braucht auch nicht geschützt werden. Nur deine Kunden haben Nutzen von deinen Entwicklungen.

Hmm.. wenn man sich die Rechnungen an den Kunden ansieht, wird gleich ganz schnell klar das die SW kommerziell ist
Das eigentliche Geld machen wir meist nicht mit der Initialversion der SW, sondern mit dem Änderungen während der Laufzeit und dem Service.