Patrick Hütter

Java / JVM Bytecode und Programme dekompilieren und vor Codediebstahl schützen

Da ich einige meiner Webapps in die Cloud zu bestimmten Cloudprovidern auslagern möchte, habe ich mich intensiver mit dem Thema Codesicherheit beschäftigt, da Cloudanbieter wie Heroku keine vorkompilierten Apps zum deployen, sondern den Quellcode in einem git-Repository erwarten. Dadurch gibt man natürlich seinen Quellcode in fremde Hände, worüber man sich im klaren sein sollte. Vertrauen ist natürlich immer gut, aber ich mache mir dann schon Gedanken darüber, wer weiß welcher Mitarbeiter die Clouds / Repos verwaltet und was wenn der Cloudanbieter gehackt wird und somit dein privates Repo für die Öffentlichkeit erreichbar ist?Cloudfoundry hingegen erwartet nur den Bytecode, den man lokal auf seiner Workstation erstellt und dann hochlädt. Den richtigen Schutz bietet dies jedoch auch nicht, denn den Bytecode kann man mit Decompilern wie JD-GUI in Sekunden zu sehr gut lesbarem Quelltext umwandeln. Das geht sogar so gut, dass man teilweise eine 1 zu 1 Kopie der echten Projekt-Klasse bekommt. Einziger Vorteil ist, dass derjenige der das Projekt decompiled, keine Quelltext-Kommentare und ggf. Business-Logik zu sehen bekommt. Diese würde ein Angreifer bei Heroku durch direkten Code-Zugriff nämlich auch bekommen. Das ganze kann natürlich auch bei einem normalen Server passieren, jedoch hat man da die Möglichkeit selbst Vorkehrungen zu treffen und z.B. ganze Festplattenbereiche zu verschlüsseln.

Den Quellcode unleserlich machen

Damit niemand so einfach den Quellcode durch decompilen sichtbar machen kann und daraus ggf. Rückschlüsse auf Funktionsweise einer Software schließen kann, gibt es sogenannte Obfuscatoren. Diese Tools machen den Quellcode unleserlich, in dem Sie Variablennamen, Methodennamen, Klassennamen, Packages uvm. einfach kryptisch umbennenen und Teile die von der Software nicht genutzt werden, komplett entfernen. So kann man neben dem unkenntlich machen auch ggf. die Dateigröße der Software verkleinern. Ein bekannter Java-Obfuscator ist ProGuard.

Aus „Auto.fahren(100);“ wird dann z.B. „a.c(100);„.

Das funktioniert mit normalen Anwendungen, aber was ist mit einer Cloudapplikation?

Theoretisch würde das ganze auch mit einer Cloudapplikation funktionieren. Bei Heroku müsste man jedoch die Webapp immer nach spezieller Konfiguration unkenntlich machen und dann in das git-Repository pushen. Genau so kann man das mit Cloudfoundry machen, nur dass man den unleserlichen Quellcode lokal kompiliert und dann bei Cloudfoundry deployed. Das ganze kann je nach Ausführung komplitziert sein und verträgt sich nicht so sauber mit den offiziellen Cloud-Plugins für die IDEs, deshalb sollte man sich überlegen, ob dieser Aufwand wirklich Sinn macht.

Was meint ihr? Pusht ihr euren Quellcode ohne Weiteres auf Heroku? Ist euch das egal? Habt ihr überhaupt schon mal über so etwas nachgedacht wie Codediebstahl im Falle eines Einbruchs? (Mag vielleicht unwahrscheinlich sein, aber die Vergangenheit hat gezeigt, dass Fehler auch bei großen Hosting-Providern passieren => Hetzner gehackt )

Die mobile Version verlassen