Come posso evitare il reverse engineering dei file JavaEE 6 .war?

Question

Abbiamo diverse applicazioni JavaEE 6 (file .war) che dobbiamo proteggere dal reverse engineering, ma non sembrano esserci molte opzioni disponibili.

Mi piace l'idea di un file .jar crittografato (SJAR) utilizzato nei prodotti JarCrypt/JInstaller, ma non è chiaro che JarCrypt/JInstaller funzioni in un'app JavaEE 6. server come Glassfish3.1. I file SJAR crittografati devono essere decifrati da una libreria nativa utilizzando un programma di caricamento classi personalizzato, quindi apparentemente dovrei aggiungere un caricatore di classe personalizzato a Glassfish.

Qualcuno ha utilizzato le tecnologie JInstaller/JarCrypt? Funzionano in un server delle applicazioni?

Ho anche guardato l'offuscamento, ma per le applicazioni JavaEE ci sono molti problemi. Dovrei lasciare da solo tutti i servizi Web e le ricerche JNDI. L'uso di cose come a.b.c.MyClass.class (ad esempio per creare logger log4j) è problematico. La lettura dei file di registro diventa difficile. E per tutti questi problemi l'offuscamento non fa quasi nulla per proteggere il nostro codice.

Ho provato Proguard, ma a quanto pare è can't deal with the JavaEE 6 libraries.

Ci sono altre alternative o sono queste su tutte le opzioni che ho?

Grazie.

Answer 1

Stai spedendo tali app a terze parti che la eseguiranno sulla loro infrastruttura? Quindi la crittografia non ti aiuterà affatto, perché la JVM non può eseguire bytecode crittografato e it is trivial to retrieve the loaded class files from a running app.

Dai un'occhiata a GuardIT for Java - fino ad oggi non ho avuto esperienza con esso, ma almeno il venditore afferma che è specificamente progettato per proteggere le applicazioni Web Java.

Se le tue app funzionano su Tomcat, potresti averle compilate con codice nativo. O hanno bisogno di un app server Java EE completo?

Answer 2

La prevenzione è effettivamente impossibile. Il meglio che si possa sperare è di alzare leggermente la barriera che risulterà in gran parte una manomissione piazzata, il fattore Security through obscurity è no security at all. I prodotti che affermano di fare questo sono in realtà peddling silicon snake oil

Answer 3

Ho lavorato alla protezione del software negli ultimi due anni e ho valutato la maggior parte delle soluzioni europee sul mercato (scusate, evitiamo soluzioni americane ...).

ci sono quattro tecniche che abbiamo visto come le soluzioni di protezione: - Offuscamento - Codifica - Compilation a codice nativo - transcodifica

Probabilmente conoscete la maggior parte di queste tecniche, tranne per la transcodifica.

L'offuscamento richiede molto lavoro per ciò che è, alla fine, scarsa protezione. Ma puoi combinare l'offuscamento e tutte le altre tecniche.

La crittografia è piuttosto facile da interrompere (non esiste una soluzione per la memorizzazione della chiave in un'area sicura, anche con un dongle è facile da recuperare). Inoltre, c'è un modo per aggirare le classi decifrate dalla memoria (o, più direttamente, dalla chiave di crittografia).

La maggior parte degli sviluppatori Java ritiene che la compilazione su codice nativo offra una buona protezione ... Ma non fornisce alcuna protezione; per più di 20 anni è stato possibile invertire il codice nativo e ci sono alcuni ingegneri inversi molto esperti per farlo. Ci sono anche alcuni buoni reverse-compilers in linguaggio C per aiutare ...

Infine, c'è la transcodifica (di cui ci sono pochissime informazioni su internet). Questa è l'unica protezione efficace contro ingegneri inversi esperti. È un dolore rompersi perché richiede anni di lavoro. Non è impossibile ma richiede un tempo molto, molto lungo. Inoltre, ogni volta che viene rilasciata una nuova patch, è necessario riavviare il reverse engineering perché a ogni release il codice è completamente diverso. C'è un inconveniente? Sì, prestazioni. Ma può essere combinato con tutte le altre tecniche e non ci sono limitazioni di implementazione (server applicazioni, generazione di classi dinamiche, ecc.) O limitazioni Java (riflessione, ecc.).

Non c'è un proiettile d'argento. Ogni soluzione può essere utilizzata a seconda del target. Proteggere da un governo o da script kiddies non è lo stesso ... Scegli una soluzione relativa ai pro e contro e, soprattutto, alle limitazioni relative (come Jarcryp e offuscamento sull'applicazione web).

Per rispondere alla domanda su Jarcryp (e altre soluzioni di crittografia), è possibile: è sufficiente chiedere a Componio (fornendo JInstaller/Jarcryp) di fornire un classloader che erediti dal programma di caricamento classe server applicazioni che usate.

La transcodifica funziona con tutti i server delle applicazioni.

Answer 4

L'offuscazione del file WAR mediante ProGuard consente di crittografare il file di guerra in gran parte. Per maggiori dettagli visita il link http://bratonfire.blogspot.in/2012/01/war-file-obfuscation-using-proguard.html