HWID / Code protection

[progsfa]

So, ich bins mal wieder
Ich bin gerade dabei mir in Java ein kleines Programm zu schreiben ,welches ich dann verkaufen möchte.

Ich hatte mir gedacht, über HWID und Server-Requests, festzustellen, ob der Benutzer eine valide Lizenz hat.

Ich war gerade etwas am googlen, und merke, das es doch nicht so "leicht" wird

Deswegen hier meine Fragen:

1. Wie kann ich z.B. Computername/Username/CPUID des PCs auslesen?

2. Wie kann ich mich davor schützen, das der Kunde, meine Request-URL in seine Hosts-Datei einfügt und meine positive Antwort vom Server simuliert?

3. Weiterhin wäre, es dann ja problematisch, das man die JAVA files mit einige Decompilern relativ leicht decompilen kann.
Ich weiß, das man diese nicht komplett verschlüssel kann (wie z.B. in C(++)), weil die JVm den Code zur Laufzeit decompiliert und ausführt.
Gibt es trotzdem noch Möglichkeiten, das RE zu verhindern?

Weil auf C# will ich ungerne umsteigen, da Java ja Plattformunabhängig ist.
Bei C(was auch immer ), müsste man schauen, ob die Biblotheken, welche man benutzt, auch auf anderen System vorhanden sind und denmach vers. Compilen.

Beste Grüße
progsfa

 

[Tomate_Salat]

1.

//Benutzername:
System.getProperty("user.name");
// oder
System.getenv("USERNAME");

// CPUID:
System.getenv("PROCESSOR_IDENTIFIER");

// Computername:
System.getenv("COMPUTERNAME");

2. Naja, die Hosts datei veruschen auszulesen (nicht sicher, ob das so einfach geht. Wahrscheinlich aber nicht :-/). Hier musst du die Antwort vom Server komplexer gestallten. Kein TRUE oder FALSE. Mit verschlüsselungen (z.B. RSA) kannst du einen String empfangen, der inhaltlich gleich ist, aber jedes mal trotzdem anders ausschaut.

3. Es gibt afaik VM's die mit verschlüßeltem Bytecode arbeiten können. wurde schon öfters genannt, ich vergesse es nur immer wieder. Eine VM kann man mit dem Programm zusammen ausliefern.

 

[progsfa]

1.
Danke

2.
Ich hatte schon vor, meine Ausgabe zu verschlüseln, man müsste nur schauen wie
Vlt gibt man einfach noch die aktuelle Serverzeit aus und prüft, ob diese +- 10 sec darüber drunter liegt, weil ich denke, falls der verschlüsselungsalgorithmus (zu) komplex wird, dann wird es auch schwierig, diesen zu reversen.

3.
Das Problem bei "speziellen" VMs ist ja dann auch, das diese dann nicht jede Person hat...

Gruß

 

[Tomate_Salat]

2.) Theoretisch reicht eine verschlüsselung. RSA-Keys werden immer zufällig generiert, weswegen auch die übertragenen bytes unterschiedlich aussehen. Wie die Antwort in solchen Fällen ausschaut, wäre hier die Frage. Ich werde mir noch was überlegen.

Edit: Man könnte eine dauerhafte Internetverbindung voraus setzen. Wenn der Server eine Raubkopie vermutet, beendet er einfach die Verbindung zum Clienten.

Edit2: Wenn er eh einen Server abfragen soll: bau ein Login-System. Dann sind alle lizensierte Version bekannt und du könntest auch sicherstellen, dass nur eine Version gleichzeitig läuft.

3.) i.d.R. müssen VMs nicht mal installiert werden. Du könntest eine batch, command, haumichtot Datei dazupacken, die das Programm startet (relativ eben zur mitgelieferten VM).

 

[progsfa]

RSA werd ich mir mal anschauen, wird aber nicht das einzige sein.
Man kann ja noch nen Base64 oder noch nen DES drumhauen.

2.1 : Hmm, ich will es über ein php-script mit meiner DB abgleichen, eine Dauerhafte Abfrage, ist noch so die super Lösung.

2.2 : Ok, loginsystem wär ok, aber dann muss man sich immer einloggen ;( eig soll nur beim ersten Start die HWID ermittelt werden und zusammen mit dem Aktivierungskey in meine DB. Der Key wird danach aus der DB gelöscht.

Danach wird beim starten einfach abefragt, ob die HWID in der DB ist.

3. OK.

4.
Bleibt immer noch das Problem mit dem decompilen.
wenn man bei google "JAVA code protection" eingibt, kommt man zu einigen Programmen, die das angeblich verhindern sollen.

Hat damit schon jemand Erfahrung?

Gruß

 

[Tomate_Salat]

2.1.) Ändert die Lage enorm, ich bin von einem Java-Server ausgegangen.

Puh, da weis ich nicht, wie gut du dort mit asynchroner Verschlüsselung arbeiten kannst.

Ansonsten. Mit solchen VM's/tools habe ich noch nie gearbeitet KA. Aber du kannst es ja mal einfach ausprobieren.

 

[progsfa]

Okay,
hätte ich schreiben müssen

Ich dachte mir, das ich einfach den Algo in PHP nachschreibe (sollte kein größeres Prob sein, muss halt nur schauen, ob mein Server die last dann trägt...)

Okay, werde ich dann mal machen und wenn ich Zeit finde, ein Feedback schreiben.

Danke für deine Tipps

Gruß

 

[kay73]

// CPUID:
System.getenv("PROCESSOR_IDENTIFIER");

// Computername:
System.getenv("COMPUTERNAME");
[/code]

Sicher, dass das geht? ;-)

Kommerzielle Produkte in der Richtung setzen auf kleine DLLs/shared libraries in denen der Authorisierungscode sitzt. Wenn man portables C verwendet, kann man durchaus 32/64 bit Windows- und Linux-Systeme mit vertretbarem Aufwand abdecken.

Die eigentliche Schutzfunktion ist nicht das Problem, da man RSA/DSA u. s. w. geschenkt bekommt. Man kann auch z. B. auch leicht aus einer DLL heraus abfragen, ob eine oder mehrere Klassen im JAR-File richtig signiert sind.

 

[progsfa]

So, ich hab mich gerade mal ans Coden gemacht, jedoch sind mir die

// CPUID:
System.getenv("PROCESSOR_IDENTIFIER");

zu unspezifisch.

Das mit dem Processor_Identifier, gibt nur dessen namen zurück, und die PC / Usernamen kann man ja selber auch ändern.
Gibt es nicht noch weitere IDs, welche ich nutzen kann?
Finde bei Google nur

// CPUID:
System.getProperty();

aber da auch nur Java-bezogene, oder zu allgemeine Sachen

Gruß

 

[Gastredner]

Danach wird beim starten einfach abefragt, ob die HWID in der DB ist.

Und was, wenn der Benutzer nun einen neuen Prozessor gekauft hat? Muss er dann eine neue Lizenz kaufen?
Lizenzen an Hardware zu binden ist immer kritisch, da so bereits der Austausch einzelner Teile zum Verfall der Lizenz führen kann, was erst einmal vor allem für den Benutzer, über längere Sicht aber womöglich auch den Entwickler/Anbieter ärgerlich sein kann.

 

[progsfa]

Und was, wenn der Benutzer nun einen neuen Prozessor gekauft hat? Muss er dann eine neue Lizenz kaufen?
Lizenzen an Hardware zu binden ist immer kritisch, da so bereits der Austausch einzelner Teile zum Verfall der Lizenz führen kann, was erst einmal vor allem für den Benutzer, über längere Sicht aber womöglich auch den Entwickler/Anbieter ärgerlich sein kann.

Ich speichere die Lizensen dazu auch in meiner Datenbank.
Falls der Benutzer seine alte Lizense vorzeigen kann, dann wird die HWID geändert, bzw der Lizensecode wird wieder aktiviert.

Hast du einen anderen Vorschlag?
Möchte keinen fest eingebauten Algorithmus haben, da man sonst den Code weitergeben könnte.
Oder, man müsste irgendwie auf dem System des Benutzers ein "Hinweis" lassen, womit mein Programm beim starten dann feststellen kann, ob dieses schon aktiviert wurde. Hier ist das dann wieder kritisch, da der Benutzer einfach dieses Hinweis herausfinden muss, um das Programm öfters zu aktivieren.

Andere Vorschläge gerne gesehen

Gruß

 

[Tomate_Salat]

@kay73: da ich diese Keys nicht erfunden habe, sondern mir sie hab zurückgeben lassen: Ja. Der TO will plattformunabhängig bleiben. Das kannst du mit einer DLL nicht, außer du schreibst für jede Plattform eine eigene lib.

@TO: ich würde das login-system nutzen. Damit hat der Benutzer eine ID die er nicht mehr verfälschen kann und wundert sich auch nicht mehr, bei Änderung der Hardware, wieso das Programm nicht mehr funktioniert.

 

[progsfa]

@TO: ich würde das login-system nutzen. Damit hat der Benutzer eine ID die er nicht mehr verfälschen kann und wundert sich auch nicht mehr, bei Änderung der Hardware, wieso das Programm nicht mehr funktioniert.

Aber dann könnte dieser den Login weitergeben, und dann hätte ich Multi-Using einer Lizenz.
Das müsst ich dann auch irgendwie verhindern können...

Aber man kann ja dann z.B. nen Auto-Login einstellen, dann ist das noch etwas mehr benutzerfreundlich.

Gruß

 

[Tomate_Salat]

Nun ja, du könntest beim einloggen und nach jeder Serveraktivität die IP speichern und 5minuten lang sperren, sodass man sich von keiner anderen IP aus anmelden kann. Somit ist ein zeitgleicher login nicht mehr möglich und du hättest eine Single-user-Anwendung

 

[- Java -]

Wie wärs, wenn du denen, die eine Lizenz gekauft haben, einen Username + Passwort gibst, die sie im Programm eingeben. Dein Programm ruft dann ein PHP-Script auf, das den Username und Passwort checkt und die IP in der DB bei dem entsprechenden Usernamen speichert. Dann könntest du noch ein PHP-Script basteln, das gleiche IPs mit Usernamen auflistet. Dann kannst du sehen, ob jemand seinen Account weitergegeben hat und diesen dann sperren.

 

[Tomate_Salat]

du kannst nicht einfach so Accounts sperren!(!!!!). Wenn der Benutzer mobiles Internet verwendet oder vom Urlaub aus das Programm nutzen will... würdest du ihm irrtümlicherweise ein multiplizieren unterstellen.

 

[ARadauer]

Oder was ist wenn mehrere Benutzer mit unterschiedlichen Lizenzen hinter dem selben Router sitzen und somit die gleiche ip haben?

hartes thema,...

 

[Atze]

[ironie]mach es so wie andere große softwareschmieden auch. verteil deine software so gut wie kostenlos, bau eklatante fehler ein und verdien dein geld dann mit den supportverträgen! [/ironie]

 

[Tomate_Salat]

Oder was ist wenn mehrere Benutzer mit unterschiedlichen Lizenzen hinter dem selben Router sitzen und somit die gleiche ip haben?

hartes thema,...

Hier bewährt sich mein System. Jeder Benutzer hat seinen eigenen Login und solange dieser angemeldet ist, wird der Benutzer für andere Arbeitsplätze gesperrt.

 

[progsfa]

So, ich hab jetzt nochmal darüber nachgedacht und bin zu den SChluss gekommen, das ich eine Kombination aus Login / HWID machen werde.
Der User kann sich mit seinem Login einloggen und dann wird seine HWID in der Datenbank gespeichert.

Hmmm, so richtig toll ist das dann auch nicht...
Ganz schön schwer so eine Entscheidung.

GRuß

 

[schalentier]

Mich wundert, warum hier noch keiner was zur Sache ansich gesagt hat. Dir sollte klar sein, dass jeder mittelmaessig begabte Entwickler, dir deinen Schutzmechanismus in maximal 1h ausgehebelt hat.

Ist es das wert, jetzt Tage oder Woche in die Entwicklung eines Kopierschutzes zu stecken, der dann verdammt schnell geknackt werden kann?

Mach doch einfach dein Programm besser, dann finden sich auch mehr Leute, die in dem Programm einen Mehrwert sehen und es kaufen.

 

[Empire Phoenix]

Mich wundert, warum hier noch keiner was zur Sache ansich gesagt hat. Dir sollte klar sein, dass jeder mittelmaessig begabte Entwickler, dir deinen Schutzmechanismus in maximal 1h ausgehebelt hat.

Ist es das wert, jetzt Tage oder Woche in die Entwicklung eines Kopierschutzes zu stecken, der dann verdammt schnell geknackt werden kann?

Mach doch einfach dein Programm besser, dann finden sich auch mehr Leute, die in dem Programm einen Mehrwert sehen und es kaufen.

Zum Glück ist die normalle Kundschaft meistens eher mittelmäßige Anwender, für die kann sowas eine erhebliche sperre darstelen, solange es nicht in einschlägigen foren einen Einfachen Crack gibt. (Und das wird erst passieren wenn das intresse an dem Programm eine Schwelle übersteigt.)

 

[schalentier]

Ja, fuer diese Leute reicht aber ne laengliche Nummer, deren Quersumme... uhm.. 7 ergeben muss, voellig aus.

 

[Atze]

Ja, fuer diese Leute reicht aber ne laengliche Nummer, deren Quersumme... uhm.. 7 ergeben muss, voellig aus.

 

[kay73]

@kay73: da ich diese Keys nicht erfunden habe, sondern mir sie hab zurückgeben lassen:

Interessant, sind mir noch nie untergekommen. Außerdem ist getenv deprecated.

Der TO will plattformunabhängig bleiben.

PROCESSOR_IDENTIFICATION existiert zumindest unter Ubuntu nicht.

...außer du schreibst für jede Plattform eine eigene lib.

Nicht schreiben, sondern nur neu übersetzen.

An Threadersteller: Wenn Du "reines" Java schreibst, musst Du Dir im Klaren sein, dass Du bezüglich Sicherheit schwere Kompromisse eingehst und verloren hast, sobald jemand fähig ist, Java Bytecode zu patchen. Da nützt auch eine Serververbindung nichts.

Aber das Schreiben eines "Keygens" lässt sich unterbinden. Ich habe mal eine ganz ähnliche Problemlösung in reinem Java implementiert und wenn ich es heute noch einmal an Deiner Stelle machen müsste, würde ich:

1.) Mir ein public/private keypair erstellen.
2.) Eine Signatur erstellen.
3.) Die Anwendung "ganz normal" schreiben und als JAR packen.
4.) Das JAR mit der Signatur aus 2. signieren.

5.) Beim Start der Anwendung würde ich die Signatur von ein paar (zufällig) ausgewählten Einträgen checken.
6.)Dann testen, ob eine Lizenzdatei im Pfad des JARs liegt. Diese Lizenzdatei besteht im Wesentlichen aus einem (XML-)String mit den (wie auch immer ermittelten) Kernbestandteilen wie CPUID, Festplattengröße, Username und einer digitalen Signatur aus dem privaten Schlüssel aus 1. Der String wird intern neu-ermittelt und dessen Hash gegen den signierten Hash aus aus dem Lizenzfile mit Hilfe des in die Anwendung hart eingebetteten public Key verifiziert.

All die Signier- und Verschlüsselungsgeschichten lassen sich unmittelbar mit Java-Boardmitteln realisieren.

Den Prüfcode für 5.) und 6.) würde ich in eine verschlüsselte Klassendatei mit ins JAR packen, die von einem eigens geschriebenen ClassLoader zur Laufzeit geladen wird, der z. B. nur anfängt zu arbeiten, wenn seine eigene Signatur stimmt.

Das macht das Dissassemblieren deutlich umständlicher. Wenn irgendwas nicht stimmt, könnte der ClassLoader z. B. die Hauptklasse der Anwendung gar nicht erst erzeugen.

Um den Prüfcode zu verschlüsseln, kann man z. B. einen simplen RC4 (Wikipedia) nehmen und die SBox direkt als Array in den Code packen. Das Ganze dann mit einem Obfuscator "behandeln" (Letzteres habe ich nicht probiert.)

 

[Atze]

boar, scheint n krasses vorhaben zu werden steht das denn in relation zum sicherheitsgewinn? oder ist dann der security-code-anteil größer als das tool selbst?

 

[schalentier]

Den Prüfcode für 5.) und 6.) würde ich in eine verschlüsselte Klassendatei mit ins JAR packen, die von einem eigens geschriebenen ClassLoader zur Laufzeit geladen wird, der z. B. nur anfängt zu arbeiten, wenn seine eigene Signatur stimmt.

Bin mir grad nicht sicher ob ich das jetzt richtig verstanden hab (Krypto war noch nie meine Staerke...), aber sieht das dann nicht in Pseudocode so aus:

class Main {
   public static void main() {
      if( !SignatureChecker.isJARValid() ) {
         throw new IllegalVersionDetected();
      } else {
         Application.start();
      }
   }
}

Naja, und das einzige was zu tun waere, ist das ! zu entfernen. Das ist der Austausch eines Bytes in der Main.class.

 

[kay73]

...und wenn Du das Byte ausgetauscht hast, ist das JAR kaputt ;-)

Nein, der Witz ist der ClassLoader, der Teile des JARs entschlüsselt. Aber Du hast grundsätzlich schon recht: Das zu patchen ist dann Fleißarbeit. Interessant wird es, wenn sich die wesentlichen Teile nicht so einfach disassemblieren lassen.

 

[schalentier]

Okay, mein Pseudocode is Quatsch, vielmehr so:

class Main {
   public static void main() {
      Application app = CryptoClassloader.loadClass( "Application" );
      app.start();
   }
}

Wobei die Application.class halt verschluesselt ist. D.h. man muesste erst den Classloader verstehen (Schluessel zum Entschluesseln muss ja irgendwo im JAR rumliegen), sonst bekommt das Programm die Klasse ueberhaupt net. Wenn der Schluessel alternativ auch noch nur von nem Server geholt werden wuerden, dann wird das schon ordentlich schwierig zu knacken. Man darf nur keine Fehler machen Ich hab so einen aehnlichen Check schonmal gesehen, allerdings hat es da gereicht, die Signaturfiles aus dem JAR zu loeschen...

 

[kay73]

(Schluessel zum Entschluesseln muss ja irgendwo im JAR rumliegen)

Einfach in ein byte Array hartkodieren. Ich habe gleich die ganze SBox hartkodiert.

In meinem Fall hat dann der "Cryptoclassloader" erst den "eigentlichen" ClassLoader geladen. Und dann ist das Löschen der Signaturen natürlich fatal, weil der ClassLoader diese explizit prüft.

Wenn man wesentliche Teile des CryptoClassLoaders in portablem C schreibt, braucht es schon jemand mit richtig Ahnung. Wobei man aus C auch nur Java per JNI aufruft.

 

[progsfa]

@ schalentier:
Genau das möchte ich verhindern
Mir ist klar, das man ein Programm nie zu 100% schützen kann, solange es Leute gibt, die sich daran setzen, es zu Reversen.
Das das dann keine 0815 Benutzer sind, ist mir auch klar.
Aber schon Benutzer mit etwas mehr krimineller Energie suchen in einschlägigen Foren nach Cracks, Serials, etc...

@Empire Phoenix:
Das sollte auch verhindert werden.

@kay73:
Ok, du scheinst mein Anliegen verstanden zu haben
Jetzt bin ich auch noch kein so großer Java Guru, das ich jetzt genau damit etwas anfangen kann.
Der Pseudo Code der Nachposter ist mir klar, aber wie genau schreibt man/sollte so eine ClassLoader Anwendung aussehen?

Weil wenn man jetzt die ClassLoader Classe, welche die Prüfungen macht, auch nur leicht absichert, dann kann der REser, sich einfach diese anschauen, und von dort die hartcodeden Keys herausfinden.

Würde mich hier sehr über genauere/umfangreichere Anleitungen/Stoff zum Nachlesen freuen.
Ich möchte halt nicht nur c&p machen, sondern das dann auch verstehen, deswegen wie gesagt, würde ich mich über Links zu diesen Informationen freuen

Was ist eine SBox, so nebenbei.


@Atze
So, wie es aussieht wird es eher so aussehen 80-95 % Sec-code und 20-5 % eigentliche Programm, doch wenn ich den Aufwand einmal durchhabe und es so funktioniert, wie es soll, dann werde ich später keine Probleme mehr haben und kann dann auch größere Projekte sicher schreiben.


Ich werde erstmal 1 Woche nicht nachschauen können, würde mich aber sehr freuen, wenn ihr fleißig weiterdiskutiert.

Schönen Sonntag noch
progsfa

 

[Tomate_Salat]

Außerdem ist getenv deprecated.

wäre mir neu.

PROCESSOR_IDENTIFICATION existiert zumindest unter Ubuntu nicht.

Diese Sache hatte ich allerdings befürchtet.

Nicht schreiben, sondern nur neu übersetzen.

Da ich in dem Bereich zu wenig Erfahrung habe, halte ich einfach mal die klappe

 

[Atze]

@Atze
So, wie es aussieht wird es eher so aussehen 80-95 % Sec-code und 20-5 % eigentliche Programm, doch wenn ich den Aufwand einmal durchhabe und es so funktioniert, wie es soll, dann werde ich später keine Probleme mehr haben und kann dann auch größere Projekte sicher schreiben.

das stimmt, zu übungszwecken ist es sicherlich gut. nur die absicherung sollte in ner guten relation um aufwand stehen. 100%ige sicherheit gibt es wie du schon gesagt hast nicht. klar kann man unmengen an sicherheitsaufwand betreiben, aber für n tool was später nicht mehr als (angenommen) 1 Euro als download kosten soll ist der aufwand da 14 mann/tage zu verwenden dies für den "worts case" zu sichern zu groß. wenn der "cracker" das tool unbedingt braucht, wird er schon den euro zahlen bevor er sich überhaupt damit beschäftigt es knacken zu wollen.

 

[kay73]

wäre mir neu.

Es ist nicht mehr

deprecated

. Das war mir neu... ;-)
Java How To ...: System getenv() reinstated in JDK 1.5

 

[Atze]

schön mal zu lesen dass auch fehler eingesehen und korrigiert werden / wurden

 

[tuxedo]

eine ID die einen Computer identifiziert lässt sich mit etwas Arbeit auch selbst zusammenbasteln. Habs glaub ich schonmal in nem anderen Thread geschrieben. Geht halt nur nicht exakt Platformübergreifend. Hier das ganze nochmal in Kurzfassung:

Windows:
id = Windows Serial Key (via Kommandozeilenbefehl "reg query...")
id += Timestamp von C:\Windows
id += ...
id = sha1(id)

Linux:
id += diverse Daten aus /dev/ oder auch /proc
id = sha1(id)

MacOS X:
id = sha1(GeräteID) (bekommt man via Kommandozeilenbefehl --> google)

-------------

Nachteile:

Windows: Ändert man die Windows-Installation (Neuinstallation etc.), ändert sich die ID. Kommt drauf an an welche Merkmale man sich hängt.
Linux: Kommt drauf an an welche Merkmale man sich hängt ...
MacOSX: Bei einer Gerätereparatur mit einem Tauschgerät ist die ID wohl anders

 

[progsfa]

Okay, danke.
Man könnte ja vlt einfach ne Kontrolle durchführen, welches System gerade läuft.

Nochmal zu meiner Frage: Wie genau sieht so eine CryptoLoader Classe aus?
Kann mir gerade nichts darunter vorstellen...

GRuß

 

[kay73]

Wie genau sieht so eine CryptoLoader Classe aus?

Sorry, den Code publiziere ich nicht.

Das hier hat mir seiner Zeit sehr geholfen:
Java Class Loaders (Java Security)

Weitere Ideen gibt es hier:
Encrypting Your Java Application | DeciSci Knowledge/Community Site
Java: encrypt, decrypt...JAR..., obfuscator, obfuscation

Du könntest Dir überlegen, eine kommerzielle Lösung anzuschaffen:
componio GmbH - ByteCode-Verschlüsselung für Java-basierte Software mit der JarCryp™-Technologie
ClassGuard FAQ

 

[Dit_]

Ich habe mir auch gedanken gemacht wie schütze ich den Code am besten? Irgendwann wurde mein Projekt riesig (zumindest für meine Verhältnisse), dann dachte ich hey, ich laufe doch einfach abfuscator drüber und gut ists...
Falls jemand in der Lage ist ein System, dass aus über 500 Klassen besteht (heutiger Stand) und durch Weiterentwicklung/Updates ständig erweitert und veraendert werden soll, zu verstehen, dann hat derjenige es auch verdient von dem Code gebrauch zu machen .

Ich meine, wenn ich schon implementierte, große Module 4 Wochen später anschaue, brauche ich sehr lange bis ich wieder den Durchblick habe, obwohl ich sehr gut kommentiere (60% der codezeilen sind kommentare) und der Code dank Patterns (+ UMLs) gut lesbar ist.
Kann sich jemand große Menge der Klassen nach Obfuscatorbehandlung vorstellen? Ohne packages, mit Variablennamen wie "_" oder "____" oder "_____" und in Hälfte der Klassen kommen die API Objekte sogut wie nicht vor (außer String, int natürlich). Man kann zwar die Klassen und Variablen unbenennen aber was dann? Mit nächstem "Release" könnte vieles anders sein und es könnte absichtlich vielles anders sein

Oder sehe ich das falsch?

Code verschlüsseln? Ich glaube der Aufwand lohn sich einfach nicht...
Wenn es wirklich um know-how handelt, dann -> C/C+ oder Assembler

 

[Atze]

außerdem kommt es ja auf die art von software an. wenn es bspw "nur" ein simpler thin-client ist der sowieso nur bekannte, öffentliche schnittstellen anspricht, wobei der große teil auf dem server abgearbeitet wird und die firmenbezogenen daten und rechnungen dort gemacht werden, gibt es ja auch nicht mehr viel abzusichern. jedenfalls im günstigsten falle