Components auf Codeebene vor reverse engineering schützen?

[kopernus]

Hallo!

Wir versuchen eine Applikation die wir einigen Kunden in Form eines Java-Applets anbieten gegen Reverse-Engineering abzusichern.

Dazu verwenden wird derzeit schon einen Obfuscator um den Code verworren und unkenntlich zu machen.

Da es sich aber um ein Applet mit AWT-Components handelt ist es aber trotzdem ein Kinderspiel zur Laufzeit der Applikation die Struktur der einzelnen Components zu ermitteln und so eventuell Teile unserer Applikation für andere als den gedachten Zweck zu verwenden.

Dazu nun meine Frage: Ich denke schon irgendwo mal davon gelesen zu haben, dass man die Komponenten für diese Art von Abfragen unsichtbar machen kann. Konkret ging es denke ich um ein Panel-Objekt in welches zwar andere Components eingebettet waren, beim Aufruf der Methoden des Panel-Objekts um die Child-Components zu erhalten, wurde aber nichts retourniert.

Es schien so als wäre das Panel leer, man konnte keine Components darin feststellen, wenn man diese versuchte auszulesen. Trotzdem aber waren im Panel Inhalte enthalten, die aus Sicht des Users der die Anwendung bediente ganz normal funktionierten.

Gibt es eine solche Möglichkeit?

kopernus

 

[foobar]

Da es sich aber um ein Applet mit AWT-Components handelt ist es aber trotzdem ein Kinderspiel zur Laufzeit der Applikation die Struktur der einzelnen Components zu ermitteln und so eventuell Teile unserer Applikation für andere als den gedachten Zweck zu verwenden.

Wie das, wenn doch (fast) alles mit nem Obfuscator bearbeitet wurde? Je nachdem wie die Anwendung aufgebaut ist, kannste 80-90 % des Codes mit nem Obfuscator verschleiern. Da blickt dann niemand mehr durch.

 

[kopernus]

Ja, verschleiern ist kein Problem.

Trotzdem aber kann man - vorausgesetzt man startet die Anwendung im JAR-File aus einer anderen Java-Applikation an - wunderbar auf alle instanzierten AWT-Objekte zugreifen.

Mit einem Tool wie FEST zB erhält man dann eine wunderschöne baumartike Struktur, wie die (un)sichtbaren Components aufgebaut und miteinander verknüpft sind.

Beispielsweise sieht man dann, dass im Applet zwei Panel-Objekte vorhanden sind, in diesen dann wieder Buttons, Texteingabefelder usw.

Man könnte also programmatisch auf diese Objekte zugreifen, und genau das will ich verhindern ...

 

[tfa]

Ich denke nicht, das sowas möglich ist. Eine Komponente, die angezeigt wird, muss auch irgendwie vorhanden sein. Und wenn AWT darauf zugreifen kann, kann jder andere es auch.

Warum verbietet ihr euren Kunden nicht vertraglich, die Software zu reengineeren bzw. anders als vereinbart zu verwenden? Seriöse Kunden halten sich an Verträge...

 

[foobar]

@kopernus Das ist aber schon ganz schön paranoid *g*. Es geht doch nur darum jemanden daran zu hindern deine Software auseinander zu nehmen und Teile davon wieder zu verwenden oder nicht?
@tfa dem kann ich mich nur anschliessen

 

[kopernus]

Im Applet um welches es hier geht werden Finanzdaten angezeigt.

Verhindert werden soll uA, dass durch einen Zugriff auf die Component-Objekte die angezeigten Werte programmatisch ausgelesen werden können, da man eine solche Möglichkeit den Privatkunden normalerweise vorenthält und sich im anderen Falle gut dafür bezahlen lässt. (Bei Bezahlung kommt man dann aber leichter an die Daten, ohne sie aus einem laufenden Programm heraus aus den Komponenten auslesen zu müssen ;-)

Gibt es nicht irgend eine Möglichkeit mit zB der 2D-API eine Zwischenschicht in ein Panel-Objekt zu legen, und erst darin dann irgendwie die gewünschten Components zu verwenden?

kopernus

 

[Marco13]

Ähm... die Struktur ist jetzt nicht so klar (bei dem, was du bisher geschrieben hast, frage ich mich, ob die Obfuscation oder andere Verschleierungsmaßnahmen überhaupt noch notwendig sind :autsch: :bae: :wink: ). Aber was du da mit der "Zwischenschicht" und dem "Panel, das nichts zurückliefert" gesagt hast, klingt irgendwie, als könnte man da einfach sowas "Hacken" wie

class HidingPanel extends Panel
{
    public HidingPanel(Panel realPanel)
    {
        add(realPanel);
    }

    // Dreiste Lügen verbreiten:
    public int getComponentCount() { return 0; }
    public Component getComponent(int index) { return null; }
    ...

}

... ist halt schon "strange", aber... was genau du sonst meintest, ist (mir) nicht klar...

 

[kopernus]

Dein Beispiel trifft genau was mir in Gedanken schwebte ;-)

Inzwischen hab ich auch mein schon vor langer Zeit entdecktes Beispiel mit dieser Art von Erschwernis gefunden, es setzt genau am gleichen Punkt an.

 

[kopernus]

Hallo nochmals!

Jetzt gerade hab ich so eine Awendung gesehen.

Es gibt eine Klasse die ist abgeleitet von Panel.

In einer Instanz dieser Klasse wird auch jede Menge Inhalt wie zB Rectangles angezeigt. Nach Aufruf von setVisible(false) beim Panel-Objekt verschwinden die gesamten Inhalte (zB die Rectangles) - die Inhalte sind also - so meine ich - definitv zum Panel dazugehörig.

Diese Elemente hängen nicht selbst im Panel - getComponentCount zB liefert 0, obwohl die Methode nicht überschrieben wurde.

Was schon im Panel hängt, das ist eine Instanz einer anderen Klasse (abgeleitet von Object), die quasi als Container für die anzuzeigenden Elemente dient.

Wie ist dies möglich, dass vom Panel-Objekt scheinbar keine Verbindung zu den Components innerhalb des Panels besteht - diese aber trotzdem angezeigt werden können?

Wir würden so etwas auch gerne implementieren, sind aber derzeit wirklich ratlos ...

 

[Wildcard]

Da AWT Native Peers verwendet, lässt sich der Inhalt wohl sowieso über die Betriebssystem API auslesen, du machst dir also jede Menge Stress für nichts.

 

[Janus]

schreib dir doch einen serverseiten renderer, der lediglich bilder an den client schickt. ist zwar langsamer, aber erschwert das auslesen von rohdaten ungemein

 

[kopernus]

Ja das schein auch eine Möglichkeit zu sein, wenn auch das die Applikation vermutlich unangenehm verlangsamen kann, wenn die angezeigten Inhalte oftmals wechseln.

Wie ist das eigentlich, wenn man in einem AWT-Container wie zB einem Panel selbst Objekte vom Typ Eigenbau hält und im Container diese mit einem Graphics2D-Objekt selber rendert?

Diese Objekte, die dann vom Typ A, B, usw. sein können und durch das selbst programmierte Rendering dann eben Schaltflächen, Anzeigetafeln usw. werden, würden dann ja nicht im AWT-Container hängen, da man sie nicht mittels add() hinzugefügt hat.

Mit container.getComponentCount() würde man sie dann deshalb nicht sehen, denke ich mal.

Sehe ich das richtig?

 

[byte]

Eigene Komponenten erben von AWT-Komponenten. Auch sie werden hinzugefügt.

 

[kopernus]

Ich meine wenn ich meine eigenen "Komponenten" nicht von Component ableite, sondern von Object.

 

[byte]

Und wie willst Du die dann Rendern?

 

[Janus]

die frage ist, wie weit es mit dem verbergen der rohdaten getrieben werden soll. wenn es nur darum geht, die daten nicht durch standardwigdets zu repräsentieren, dann reicht es u.U. tatsächlich, wenn die main view lediglich ein graphics objekt ist, auf dem irgendein controller wild rumzeichnet.

wenn du allerdings die rohen zeichenketten vor dem client verbergen willst, dann dürfen sie auch zu keinem zeitpunkt als zeichenkette im client vorliegen.

 

[kopernus]

Vielen Dank!

Genau in diese Richtung gehen unsere (etwas theoretischen) Überlegungen nun.

In Kombination mit der Anzeige von komplexeren Elementen wie zB Charts macht das sicherlich Sinn, um damit dann auch gleich keine AWT-Komponenten zu haben, die in einem Container herum hängen.

Wie könnte man denn in so einer Situation Maus-Events verarbeiten (zB Klicks und Ziehen der Maus in einem Chart, Aktionen mit anderen Speziellen angezeigten Elementen ...)?

Ist dazu das Einhängen eines MouseListeners im darunter liegenden Container notwendig (über die Position der Klicks könnte man sie dann den angezeigten Elementen zuordnen - man weiß ja, wo auf dem Bildschirm man welches Element gerendert hat), oder ist das vielleicht auch ohne einen Listener möglich?

Denn prinzipiell ist auch ein Listener ein möglicher Angriffspunkt. Und ich weiß von Software, bei derer Entwicklung man sich auch genau über diese Dinge Gedanken gemacht hat ...