Java für sicherheitsrelevante Anwendungen ungeeignet?

[Gast]

Hallo!

Ich beschäftige mich gerade mit dem Erstellen eines Login - Moduls in Java. Nun habe ich aber festgestellt, dass sich Java - Programme kinderleicht dekompilieren lassen. Demnach könnte man doch jedes Login - Modul ausser Kraft setzen: Einfach die entprechenden Klassen dekompilieren und mit veränderten Versionen ersetzten. Auch eine Obfuscator - Software kann so etwas nicht wirklich verhindern. In diesem Fall wäre Java für sicherheitsrelevante Anwendungen völlig unbrauchbar!

Gibt es denn wirklich keine Möglichkeit sich vor so einem Szenario zu schützen, oder habe ich da irgendetwas übersehen?

Grüsse,
--Alexander

 

[Beni]

Gegen das Dekompilieren gibt es wohl kein Schutz.

Aber Du musst dich auch fragen: was sieht man dann?
Du musst ja nicht unbedingt eine if( password.correct() ) Abfrage machen, sondern Du kannst das ganze ein bisschen verstecken :winküber mehrere Klassen verteilen, dort mal ein Parameter aus dem Passwort berechnen, da mal eine Methode missverständlich benennen...)

 

[schalentier]

Na isses denn in anderen Sprachen besser? win32 executables kann man auch decompilieren und wenn man bissel assembler kennt, ist das auch nich komplizierter zu verstehen als decompilierte JavaKlassen, die mittels Obfuscator verwurschtelt wurden.

Zusaetzlich koennte man auch mit Pruefsummen fuer die jars arbeiten, aber auch fuer diesen Test steht dann irgendwo im Code if( xz.ab() )..., was natuerlich umgangen werden kann (analoges gilt fuer assembler, da steht dann irgendwo ein JNE (=jump [if] not equal), was du durch JE (=jump [if] equal] ersetzen musst. Man muss eben "nur" die richtige stelle finden, und das wird u.u. ziemlich schwierig.

Kryptografisch sicher(er) gehts nur mit Verschluesselung und dynamisch nachgeladenen Klassen, die vielleicht in einer geschuetzten datenbank-tabelle liegen (wuerde das gehen?). Aber sowas hab ich noch nie gesehen.

Entwickel halt opensource, da gibts das problem nich

gl&hf

 

[AlArenal]

Entwickel halt opensource, da gibts das problem nich

So ein Schmarrn...

 

[DP]

Entwickel halt opensource, da gibts das problem nich

So ein Schmarrn...

suuuuuper, ingo!

btt: das problem habt ihr bei jeder software. cracks sind ja gerade dafür da, um diese routinen auszuhebeln...
cu

 

[Gast]

Hallo!

Mir ist natürlich klar, dass es das Problem mit dem dekompilieren überall gibt. Es ist allerdings schon so, dass das bei anderen Programmiersprachen mehr Hintergrundwissen erfordert: Bei C/C++ Programmen sollte man z.B. wissen, mit welchem Compiler die Software erstellt worden ist und welche Optimierungen verwendet wurden. Assembler kann auch nicht jeder Laie und Assembler - Code ist einfach schwerer zu lesen als irgendeine "if (password.equals(...) )" - Anweisung. Echte Profis wird das alles sicher nicht aufhalten. In Java allerdings reicht es schon, wenn man mit google nach den Begriffen "Java" und "Decompiler" sucht, sich die Decompiler - Software herunterlädt, ausführt und schon sieht man den Quellcode im Klartext - aber das ist wohl einer der Nachteile eines offenen und platformunabhängigen Standards.

Mir geht es jetzt auch nicht darum meinen Quellcode zu sichern - ob Andere nun wissen, wie ich meine Gui programmiere oder Datenbankzugriffe mache ist mir relativ egal. Problematisch wird die Sache allerdings, wenn es um Passwörter, Zugriffsrechte usw. geht. Um das Dekomilieren zu erschweren, werde ich wohl auf einen Obfuscator zurückgreifen - was mich gleich zu meiner nächsten Frage bringt:

Hat irgend jemand von euch schon Erfahrung mit Obfuscator - Software? Habe mal in einem anderen Forum gelesen, dass es dabei zu Geschwindigkeitseinbußen und zu Problemen im Kontrollfluss kommen kann.

Welchen Obfuscator könnt ihr empfehlen?

Grüsse,
--Alexander

 

[Stefan1200]

Naja, Passwörter sollten sowieso nicht im Sourcecode stehen, zumindest nicht unverschlüsselt.

Das mit dem einfacher Lesen halte ich für ausgeschlossen, wenn man einen Obfuscator benutzt hat.
Originale class Dateien lassen sich natürlich wunderbar decompilieren, nur die Kommentare fehlen, der Rest ist 100%ig gleich.

Wie hat das eigentlich Borland in JBuilder gemacht, lassen sich die classes auch einfach decompilieren?
Das Programm ist ja nicht gerade billig.

 

[bygones]

Originale class Dateien lassen sich natürlich wunderbar decompilieren, nur die Kommentare fehlen, der Rest ist 100%ig gleich.

Wenn man glaub ich static final Variablen verwendet erkennt man das beim decompilieren auch nicht. D.h. es werden nicht die Variablen sondern die Werte der Variablen eingsetzte (also sagen wir 98% gleich :wink: )

 

[schalentier]

Entwickel halt opensource, da gibts das problem nich

So ein Schmarrn...

wieso schmarrn? Ich entwickle nur opensource mit hilfe von opensource. Geld bekomm ich, weil ich die Software als Dienstleistung speziell fuer den Kunden entwickle. Damit hab ich nur vorteile: Ich kann OpenSource zeug nehmen und spare dadurch unendlich viel zeit, ich brauch mir keine gedanken um einen decompilier-schutz zu machen und muss keine wartungsvertraege mit dem kunden aushandeln, da dieser den gesamten quellcode hat. was der damit macht, is mir eigentlich voellig wurst. z.b. koennte dieser ein neues team ransetzen und die software erweitern/verbessern. dafuer bekomm ich dann vielleicht sogar hinweise wie schlecht oder gut mein code ist. is doch gut, oder?

Guck dir halt mal das decompilat von jbuilder an. ich kenn jetzt nur intellij und jprofiler, bei beiden wurde ein obfuscator eingesetzt. du wirst nicht durchsehen... okay, man kann durchsehen, ist aber sehr zeitintensiv.

strings werden uebrigens auch verschluesselt, wobei fuer jede klasse ein anderer verschluessel-algo verwendet wird. damit muss man in jeder klasse den entschluessler finden, ansehen, verstehen, tool zu entschluessel bauen. dazu kommt, dass du nicht weist wo du die passwoerter suchen sollst.

ausserdem kenn ich keinen decompiler, der den sourcecode wieder so rekonstruiert, dass man ihn uebersetzen kann. das waere aber sinnvoll, zum debuggen.

hf

 

[AlArenal]

Deine Aussage war apuschal und platt "entwickle Open Source und du hast keine Sicherheitsprobleme" und das ist nunmal Schmarrn. Wofür gibts es wohl all die Bugfixes und Patches auch im Open Source Bereich, wenn es doch keine Sicherheitslücken gibt?

Der Sicherheit ist es ziemlich egal unter welcher Lizenz ein Programm entwickelt wurde und ich kann auch nicht hingehen und sagen "Ich entwickel jetzt Open Source und verkaufe euch den Service drumrum, wenn das Programm ein Sicherheutsleck hat, ist das nicht mehr mein Problem. Wendet euch an die Community.".

Halte ich für ein sehr seltsames Verständnis vom Begriff "Service". Abgesehen davon das man niemanden zwingen kann und sollte Open Source zu entwickeln. Wenn ich meinem Chef sage "Übrigens, ich habe vor ner Woche unsere Quellcodes online gestellt.", wäre der nicht sehr begeistert.

 

[schalentier]

oh ein klassisches missverstaendnis.

"entwickle Open Source und du hast keine Sicherheitsprobleme"

Das hab ich nie gesagt und nie gemeint. Es geht hier darum, wie ich meine uebersetzten bytecode klassen vor der sourcecode rueckgewinnung schuetzen kann. das geht nicht 100%ig, aber mit opensource produkten ist genau das kein problem, da der quelltext ja mit dabei sein muss.

ausserdem hab ich nich gesagt, dass ich den service drumrum verkaufe, sondern ein, dem pflichtenheft nach, fertiges softwareprojekt incl quelltext. Ich verkaufe also kein produkt, sondern quelltext. Und ohne produkt gibts auch kein haftungsanspruch des kunden, wenn irgendwas nicht klappt. natuerlich werde ich auftretende bugs auch nach ablauf des projektes entfernen, aber ich hafte nicht.

fuer den kunden hat es den vorteil, dass er nicht auf mich (uns) angewiesen ist. z.b. ist es ein echtes problem, als kleine firma an grosse auftraege ranzukommen, alleine schon deswegen, weil die firma sicherlich eingeht, wenn ich ploetzlich nicht mehr mit dabei bin (andere arbeit, unfall, etc). das weiss auch der kunde und er wuerde sich niemals auf ein solchen auftrag einlassen, wenn er nicht sicher sein kann, dass das projekt auch nach uns weitergehen kann. mit quelltext ist das moeglich (<-- ich hab nicht gesagt einfach )

ich will auch niemanden zwingen, opensource zu entwickeln. aber es ist ein hardfact, dass sich die entwicklungszeit unter verwendung von os dramatisch reduziert. da die loc (line of code), die ich schreibe kleiner ist, treten logischerweise auch weniger fehler auf. sind bugs in den eingesetzten os-modulen, kann ich die entweder selber fixen, da der quelltext dabei ist, oder ein update draufspielen und hoffen, dass sich die api nicht geaendert hat.

ich persoenlich (und mein chef auch) sehe einfach die vielen vorteile, die mir os bietet. warum sollte ich die also nicht nutzen?

ps: obendrein spart man ne menge geld...

 

[bygones]

ich persönlich sehe in der diskussion keinen Bezug mehr aufs das ursprüngliche thema....
Wenn ihr weiter diskutieren wollt - eröffnet einen Diskussionsthread in der Plauderecke !!

Daher schließe ich mal den thread !!