Wir haben mehrere JavaEE 6-Anwendungen (.war-Dateien), die wir vor Reverse Engineering schützen müssen, aber es scheint nicht viele Optionen zu geben.
Ich mag die Idee einer verschlüsselten .jar-Datei (SJAR), die in den JarCrypt / JInstaller Produkten verwendet wird, aber es ist nicht klar, dass JarCrypt / JInstaller in einer JavaEE 6 App funktionieren wird. Server wie Glassfish3.1. Die verschlüsselten SJAR-Dateien müssen von einer nativen Bibliothek mit einem benutzerdefinierten Classloader entschlüsselt werden. Daher müsste ich Glassfish anscheinend einen eigenen Classloader hinzufügen.
Hat jemand die JInstaller- / JarCrypt-Technologien verwendet? Funktionieren sie in einem Anwendungsserver?
Ich habe auch die Verschleierung untersucht, aber für JavaEE-Anwendungen gibt es viele Probleme. Ich müsste alle Webdienste und JNDI-Lookups alleine lassen. Die Verwendung von Dingen wie a.b.c.MyClass.class (d. H. Um log4j Logger zu erstellen) ist problematisch. Das Lesen von Protokolldateien wird schwierig. Und für all diese Probleme macht die Verschleierung so gut wie nichts, um unseren Code zu sichern.
Ich habe Proguard probiert, aber anscheinend kann nicht mit dem umgehen JavaEE 6-Bibliotheken .
Gibt es andere Alternativen oder sind das alle Optionen, die ich habe?
Danke.
Liefern Sie diese Apps an Dritte, die sie auf ihrer Infrastruktur betreiben? Dann hilft Ihnen die Verschlüsselung überhaupt nicht, weil die JVM keinen verschlüsselten Bytecode ausführen kann und es einfach ist, die geladenen Klassendateien abzurufen von einer laufenden App .
Schauen Sie sich GuardIT für Java an - bis heute hatte keine Erfahrung damit, aber zumindest behauptet der Anbieter, dass es speziell entworfen wurde, um Java Web Apps zu schützen.
Wenn Ihre Apps auf Tomcat laufen, könnten Sie sie in nativen Code kompiliert haben. Oder benötigen sie einen vollständigen Java EE App Server?
Ich habe in den letzten zwei Jahren an Softwareschutz gearbeitet und die meisten europäischen Lösungen auf dem Markt evaluiert (Entschuldigung, wir vermeiden amerikanische Lösungen ...).
Es gibt vier Techniken, die wir als Schutzlösungen gesehen haben: - Verschleierung - Verschlüsselung - Kompilierung auf nativen Code - Transkodierung
Sie kennen wahrscheinlich die meisten dieser Techniken mit Ausnahme der Transcodierung.
Verschleierung erfordert eine Menge Arbeit für das, was am Ende ein schlechter Schutz ist. Aber Sie können die Verschleierung und alle anderen Techniken kombinieren.
Die Verschlüsselung ist ziemlich leicht zu knacken (es gibt keine Lösung, um den Schlüssel in einem sicheren Bereich zu speichern; selbst mit einem Dongle ist er leicht zu finden). Außerdem gibt es eine Arbeit, um entschlüsselte Klassen aus dem Speicher zu stehlen (oder direkter den Verschlüsselungsschlüssel).
Die meisten Java-Entwickler glauben, dass die Kompilierung mit nativem Code einen guten Schutz bietet ... Aber sie bietet keinen Schutz; Seit mehr als 20 Jahren ist es möglich, nativen Code umzukehren, und dafür gibt es einige sehr fähige Reverse-Engineers. Es gibt auch einige gute Reverse-Compiler für die C-Sprache, die helfen ...
Schließlich gibt es Transcoding (von denen es sehr wenig Informationen im Internet gibt). Dies ist der einzige wirksame Schutz gegen qualifizierte Reverse-Ingenieure. Es ist ein Schmerz zu brechen, weil es Jahre der Arbeit erfordert. Es ist nicht unmöglich, aber erfordert eine sehr, sehr lange Zeit. Außerdem muss jedes Mal, wenn ein neuer Patch veröffentlicht wird, das Reverse Engineering erneut gestartet werden, da der Code bei jeder Version völlig anders ist. Gibt es einen Nachteil? Ja, Leistung. Aber es kann mit allen anderen Techniken kombiniert werden und es gibt keine Einschränkungen bei der Implementierung (Anwendungsserver, dynamische Klassengenerierung, etc.) oder Java-Einschränkungen (Reflektion, etc.).
Es gibt keine Wunderwaffe. Jede Lösung kann abhängig von Ihrem Ziel verwendet werden. Der Schutz vor einer Regierung oder gegen Skript-Kiddies ist nicht das Gleiche ... Wählen Sie eine Lösung, die sich auf die Vor- und Nachteile und vor allem auf die relativen Einschränkungen bezieht (wie Jarcryp und Verschleierung von Web-Anwendungen).
Um auf die Frage nach Jarcryp (und anderen Verschlüsselungslösungen) zu antworten, ist es möglich: Sie müssen lediglich Componio (mit JInstaller / Jarcryp) bitten, Ihnen einen Klassenlader zu geben, der vom Klassenlader des Anwendungsservers erbt verwenden.
Die Transkodierung funktioniert mit allen Anwendungsservern.
Die Verschleierung von WAR-Dateien mit ProGuard hilft Ihnen dabei, Ihre Kriegsdatei weitgehend zu verschlüsseln. Für weitere Informationen besuchen Sie den Link Ссылка
Prävention ist eigentlich unmöglich. Das Beste, auf das Sie hoffen können, ist es, die Barriere etwas anzuheben, was weitgehend zu einem Fehlplatzierungsgefühl führen wird. Sicherheit durch Dunkelheit ist überhaupt keine Sicherheit . Produkte, die behaupten, dies zu tun, sind tatsächlich Silikonschlangenöl
Tags und Links java-ee reverse-engineering obfuscation