Serialisierung und Obfuscation?

[Fottum]

Hallo zusammen

Nehmen wir eine Klasse Haus. Diese hat als member die Klasse Holztisch.

Holztisch ist eine Spezialisierung der Klasse Tisch.


Ich will Haus serialisieren via ObjectOutputStream (XML ist keine Option).

Darf ich Tisch obfuscaten (Haus und Holztisch werden nicht veraendert)?

Sagen wir Tisch wird durchs obfuscaten zu Klasse C.

Nehmen wir mal an ich obfuscate Tisch - und serialisiere dann eine Instanz von Haus. Dann onfuscate ich nochmal und Tisch wird zu B. Kann ich nun obwohl Tisch nicht mehr C sondern B ist, die serialisierte Instanz deserialisieren?

Ich denke schon - oder spricht was dagegen? Wo seht ihr Probleme?

 

[SlaterB]

Annahme, nicht getestet (ist doch so einfach?):
eine Klasse ohne SerialisierungsId darf überhaupt nicht neu kompiliert werden,

eine Klasse mit SerialisierungsId kann nur dann neu kompiliert werden, wenn sich der Klassen und package-Name nicht ändert,
wonach sollte sonst die Zuordnung stattfinden, die Id gilt soweit ich weiß nur innerhalb der Klasse,

für einen automatischen Serialisierungmechanismus müssen außerdem alle Felder gleich benannt bleiben, denn das passiert ja wohl über Reflection


edit:
ach, auch noch Frage zu Superklassen, da ist es bei den Feldern sicher gleich,
für den Klassennamen ist beides denkbar, entweder muss er gleich sein oder es wird nur nach der aktuellen Superklasse geschaut,
naja, hier bin ich nun endgültig keine Hilfe mehr , ausprobieren!

 

[HoaX]

nachdem du einen obfuskator verwendet hast gibt es keine klasse tisch mehr, sondern nurnoch eine klasse XY und die muss dann auch immer so heißen. mir ist kein obfuskator bekannt der erst zur laufzeit was ändert - macht ja auch nicht viel sinn.

warum willst du überhaupt einen obfuscator verwenden? wieso ist xml keine option?

was ich z.B. bei einem unserer produkte mache ist die lizenzdaten per XStream als xml zu schreiben und danach mit einem einfachen algorithmus zu verschlüsseln. (~5 Zeilen code).

 

[Guest]

nachdem du einen obfuskator verwendet hast gibt es keine klasse tisch mehr, sondern nurnoch eine klasse XY und die muss dann auch immer so heißen. mir ist kein obfuskator bekannt der erst zur laufzeit was ändert - macht ja auch nicht viel sinn.

warum willst du überhaupt einen obfuscator verwenden? wieso ist xml keine option?

was ich z.B. bei einem unserer produkte mache ist die lizenzdaten per XStream als xml zu schreiben und danach mit einem einfachen algorithmus zu verschlüsseln. (~5 Zeilen code).

Dann poste doch die 5 Zeilen code

Wie sicher ist das dann? Muesst ihr nicht den Schluessel zum entschluesseln mit dazu packen?

 

[HoaX]

klar muss man das, aber is doch egal. um den rauszufunden muss man das programm erstmal dekompilieren.

ich will damit eigentlich nur sagen dass man auch mit einfachen mitteln den inhalt verschleiern kann - unbeachtet der sicherheit. so sieht der anwender nicht direkt was da in der datei steht und kann nicht mal eben ohne viel ahnung seine max. benutzeranzahl erhöhne.
außerdem bringt ein obfuskator das problem dass du stacktraces usw nichtmehr wirklich lesen kannst wenn beim kunden mal ein fehler auftritt.
und wenn man seinen logging-code nicht vorher entfernt ist das idR se verräterisch was der code macht dass man sich den obfuskator hätte sparen können.

und zu den 5 Zeilen:

BasicTextEncryptor cryptor = new BasicTextEncryptor(); // jasypt
cryptor.setPassword("Passwort");
String s = new XStream().toXML(someObject);
s = cryptor.encrypt(s);

Dann poste doch die 5 Zeilen code

ok, hast recht mit deiner anspielung, sind doch nur 4 zeilen

 

[Guest]

Kennt jemand vielleicht ein Open Source Projekt, dass zumindest einige Klassen verschluesselt und dann mit einem speziellen Classloader zur Laufzeit wieder freigibt?

Sie sollen halt nicht unverschluesselt im jar liegen

 

[Wildcard]

Kennt jemand vielleicht ein Open Source Projekt, dass zumindest einige Klassen verschluesselt und dann mit einem speziellen Classloader zur Laufzeit wieder freigibt?

Was soll das bringen? Jeder der in der Lage ist ein Jar zu Entpacken und Klassen zu dekompileren, weiß auch, dass der Schlüssel nicht weit sein kein.

 

[HoaX]

wieso auf einmal im jar? ich dachte du wolltest serialiseren?

und was sich alleine entschlüsselt zur laufzeit kann auch von jemand fremden entschlüsselt werden. aber das hast du ja oben bereits selbst festgestellt ("Wie sicher ist das dann? Muesst ihr nicht den Schluessel zum entschluesseln mit dazu packen?"). man dekompiliere halt die klasse die die entschlüsselung übernimmt ...

warum willst du das unbedingt verschlüsseln?