Nachträglich Klasse zu Package hinzufügen

[Pappenheimer++]

Hallo,

mir ist die Frage gekommen, ob ich nachträglich zu einem externen Package (das ich von einem Hersteller bspw. als .jar bezogen habe) Klassen hinzufügen kann. Mein naives Experiment war jetzt natürlich gleich, "javax.swing" als Package in meinem Eclipse-Projekt hinzuzufügen und das ging auch. Ich konnte auch Klassen hinzufügen. Die Frage ist jetzt noch: Kann man dann auf die package-sichtbaren Elemente der Bibliothek zugreifen? Wahrscheinlich gibt es da nen Mechanismus, das zu verhindern, das wäre zumindest einleuchtend. Muss man das irgendwie explizit verbieten (wenn ich selbst eine Bibliothek herausbringe und vermeiden will, dass packe-sichtbare Elemente Teil der API werden?). Bzw. was passiert, wenn zwei Klassen mit gleichem Package und gleichem Namen im Classpath sind?

 

[nillehammer]

mir ist die Frage gekommen, ob ich nachträglich zu einem externen Package (das ich von einem Hersteller bspw. als .jar bezogen habe) Klassen hinzufügen kann.

Ja, von ein paar Ausnahmen abgesehen (z.B. java.lang) kannst Du packages so definieren, wie Du willst. Ist aber, wie Du sicher selbst weißt nicht Sinn der Sache.

Die Frage ist jetzt noch: Kann man dann auf die package-sichtbaren Elemente der Bibliothek zugreifen?

Ja, das kann man dann.

Wahrscheinlich gibt es da nen Mechanismus, das zu verhindern, das wäre zumindest einleuchtend.

Nein, gibt es nicht. Java kennt vier Sichtbarkeiten (public: für alle sichtbar, protected: für alle aus dem eigenen Package plus Subklassen sichtbar, package/default: für alle im selben package sichtbar, private: nur für die selbe Klasse sichtbar). Also alles, was nicht private ist, kann von Klassen im selben package gesehen werden, egal wo und von wem sie definiert sind. Das einzige, was man machen kann, ist über einen Security Manager verbieten, dass jemand Klassen in einem bestimmten Package definiert. Der Security Manager ist aber ein Laufzeitfeature. D.h. als Entwickler kannst Du nicht sicher sein, dass es nicht doch jemand macht.

Bzw. was passiert, wenn zwei Klassen mit gleichem Package und gleichem Namen im Classpath sind?

Das ist ne gute Frage. Ich habe es gerade in Eclipse ausprobiert. Da hat meine Klasse "gewonnen". Ich schätze es gibt eine definierte Reihenfolge, in der Klassen aus jars und class-Dateien geladen werden. Die, die als letztes geladen wurde, gewinnt.

 

[mvitz]

Soweit ich weiß, gewinnt die Klasse, die zuerst gefunden wird, lässt sich in Eclipse z.B. ausprobieren indem man die Reihenfolge von eingebundenen JARs änder (geht in den Build Path Optionen).

Wie die Reihenfolge allerdings beim Aufruf auf der Konsole aussieht weiß ich jetzt so adhoc auch nicht, aber auch hier glaube ich, dass einfach die Reihenfolge des -cp Parameters entscheidet.

 

[Noctarius]

Nein, gibt es nicht. Java kennt vier Sichtbarkeiten (public: für alle sichtbar, protected: für alle aus dem eigenen Package plus Subklassen sichtbar, package/default: für alle im selben package sichtbar, private: nur für die selbe Klasse sichtbar). Also alles, was nicht private ist, kann von Klassen im selben package gesehen werden, egal wo und von wem sie definiert sind. Das einzige, was man machen kann, ist über einen Security Manager verbieten, dass jemand Klassen in einem bestimmten Package definiert. Der Security Manager ist aber ein Laufzeitfeature. D.h. als Entwickler kannst Du nicht sicher sein, dass es nicht doch jemand macht.

Das stimmt so nicht. Genau wie 2x der selbe Bytecode von 2 Classloadern geladen für Java verschiedene Klassen sind, sind auch Packages aus einem Classloader nicht Package-Visible zu einem gleichnamigen Package von einem anderen Classloader.
Da Java Bootstrap-, System- und App-Classloader nutzt ist ein "java.lang" im App-Classloader nicht Package-Visible zu einem "java.lang" vom System-Classloader (in welchem sich die Java-Klassen befinden).

Zu mindestens sollte es so sein (laut Definition)

 

[nillehammer]

Das stimmt so nicht. Genau wie 2x der selbe Bytecode von 2 Classloadern geladen für Java verschiedene Klassen sind, sind auch Packages aus einem Classloader nicht Package-Visible zu einem gleichnamigen Package von einem anderen Classloader.

Danke für die Korrektur. Die Einschänkung mit den Classloadern muss man machen. Ich habe es (erstmal) nicht geglaubt und habe folgendes Ausprobiert:
Klasse in verbotenem Package java.io: Anwendung startet garnicht. Es fliegt eine SecurityException, die sagt, dass man java.io nicht benutzen darf

Dann Klasse in erlaubtem Package, das im rt.jar liegt und deswegen (glaube ich) vom System-Classloader geladen wird

package com.sun.org.apache.xerces.interna.impl;

public class XerxesInvader {
public static final void main(final String args[]) {
  final PropertyManager invaded = new PropertyManager(-2);
  
  // Hier greife ich auf ein package private field zu, dass ich sonst nicht sehen würde.
  // Der Compiler meldet erstmal keine Fehler, deswegen war ich hoffnungsvoll.
  System.out.println(invaded.supportedProps);
}}

Ergebnis: IllegalAccessException, geht also wohl nicht, weil anderer ClassLoader.

Dann package, dass in log4jxxx.jar liegt, welches ich als lib selber hinzugefügt habe. Wird darum (glaube ich) vom App-ClassLoader geladen.

package org.apache.log4j;
public class Log4JInvader {
public static final void main(final String args[]) {
  final ConsoleAppender appender = new ConsoleAppender();
  
  // Hier greife ich auf ein protected field zu, dass ich sonst nicht sehen würde.
  // Der Compiler meldet erstmal keine Fehler, deswegen war ich hoffnungsvoll.
  System.out.println(appender.target);
}}

Ergebnis: Es hat geklappt.

Mit der Einschränkung der Gleichheit der ClassLoader stimmt meine Aussage. Aber die Einschränkung muss man machen. Danke Noctarius

 

[Noctarius]

Zusätzliche Klassen in bestehende Packages bekommen geht allerdings mit Tricks auch, aber das sollte man nur machen wenn es gar nicht (also nie ) anders geht.

 

[beastofchaos]

Ich bin schockiert, über das, was ich hier lese... :shock:

Wenn ich nun ein Programm entwickle, das super wertvoll ist und vor Veränderungen/Kopien geschützt werden soll, kann ich gar nicht schützen, da man die jar noch verändern kann? Keine Möglichkeiten, das Problem zu umgehen?

 

[Fu3L]

Ich bin schockiert, über das, was ich hier lese... :shock:

Wenn ich nun ein Programm entwickle, das super wertvoll ist und vor Veränderungen/Kopien geschützt werden soll, kann ich gar nicht schützen, da man die jar noch verändern kann? Keine Möglichkeiten, das Problem zu umgehen?

Ich glaube, dass es um etwas anderes geht, als du gerade denkst^^ Es geht mehr darum, Java vorzugaukeln, man hätte Klassen in bereits vorhanden packages, um die Zugriffsbeschränkungen (package-private) zu umgehen.

Aber auch was du meinst: Im Prinzip schützt dich nichts davor, dass jemand dein .jar entpackt, die classes decompiliert und alles umbaut^^
(Siehe cracks für Computerspiele und co )

 

[Noctarius]

Das Einzige was man in Java machen kann sind USB-Dongles (wie z.B. HaspHL), welche den Sourcecode on-the-fly im Dongle erst entschlüsseln (der Key verlässt dabei niemals den Dongle) oder Code-Obfuscation. Letzteres ist aber nur eine Erschwärung und kein echter Schutz. Wie man bei Apple sieht "Security through obscurity" funktioniert auch bei IOS nicht

 

[Pappenheimer++]

Wieder was gelernt, danke für die Antworten. Sowas wie Lizenz-Checks in der Java-Anwendung einzubauen ist (vor allem ohne Obfuscation) wahrscheinlich ziemlich witzlos, wenn dann einfach jemand die .jar entpackt und ihm schon ne Klasse wie "SecurityXYZ" ins Auge springt und die dann am besten noch per Depency Injection austauschbar ist.

 

[TheDarkRose]

Lizenz-Checks sollte man eher in ner nativen Sprache (z.b. C++) programmieren.

 

[beastofchaos]

Ok, also ich werde mich mal mit HaspHl und sowas befassen. Ist mir wichtig, sowas ein bisschen zu schützen

Wo man gerade auf andere Sprachen kommt... Was wären eigentlich Sprachen, mit denen Internet Explorer, Windows Media Player oder auch Spiele wie CoD oder auch Minigames programmiert werden? Link zu einer informationsreichen Seite würde mir auch helfen Wüsste nämlich gerne, welche Sprache auf welchem Gebiet die vortailshafte ist und was ich bräuchte, um professionelle Spiele zu basteln.
Bekannte "große" Sprachen sind für mich bisher: Pascal/ Delphi - Java - C(inkl. C# und C++)

 

[Noctarius]

Ok, also ich werde mich mal mit HaspHl und sowas befassen. Ist mir wichtig, sowas ein bisschen zu schützen

HaspHL lohnt erst ab einem gewissen Verkaufswert der Software. Du musst bei Aladdin ein Dev-Kit bestellen und einen Masterdongle mit welchem die Dateien verschlüsselt werden (in diesem liegt der Private-Key). Danach musst du (für bedeutend weniger, aber immernoch genug - ich glaub 40€/Stk) die Dongles für die Kunden kaufen. Auf denen befindet sich der Public-Key zum entschlüsseln.

Ein nicht ganz billiges Spiel.

 

[beastofchaos]

Ok, vergiss es Tipps wie ich (kostenlos) mein Programm ein bisschen vor sowas schützen kann? Indem ic hversuche soviel wie möglich "private" zu machen, oder sonst noch iwelche Tipps?

 

[Gast2]

Indem ic hversuche soviel wie möglich "private" zu machen, oder sonst noch iwelche Tipps?

Was soll das bringen?

Um deinen Code relativ einfach zu schützen kannst du einen Obfuscator verwenden. Das machts dem "Hacker" sehr viel schwieriger durch dein programm zu steigen.

 

[Fu3L]

Und ansonsten wirst du dich dann wohl damit begnügen müssen, dass die wenigsten Leute das nötige Fachwissen zum Dekompilieren, Verändern und Recompilieren eines Programms besitzen^^

Aber siehe Minecraft: Jeder der einene Minecraftmod schreiben will, muss quasie genau diese Technik anwenden und diese Mods sind relativ zahlreich^^

 

[beastofchaos]

Also ich werd mir mal so nen Obfuscator anschaun und sehen, was der bringt.
Grundsätzlich will ichzumindest mal lernen, was es so für Möglichkeiten gäbe als Schutzmaßnahme.