2012-03-21 10 views
6

Obiettivo:Java sicuro da reverse-engineering usando industria crittografia grado

Fissare la mia applicazione Java da reverse engineering.

Idea:

  1. dividere il programma in due metà (caricatore e programma)
  2. caricatore sarà un vaso regolare
  3. programma sarà un file jar crittografato (bouncycastle, AES?)
  4. loader chiede server sicuro (https) per una chiave per decodificare il programma
  5. loader quindi decodifica il programma e carica le sue classi

Domande:

Would numero 5 è possibile?
Qualcuno ha fatto questo?
Conosci qualche libreria già disponibile?
Riesci a individuare le maggiori insidie ​​/ lo faresti diversamente?

Extra

So che è impossibile impedire l'ingegneria completa inversione del codice.
Sto solo cercando di renderlo più difficile e più tracciabile.

+1

Sembra che dovrebbe essere possibile. Non penso che sarebbe troppo difficile craccarlo, aspetta solo che il loader decodifichi il programma e lo salvi sul disco ... – Bwmat

+0

Invertire la progettazione del contenitore normale, decodificare il programma e salvarlo in un file di classe, quindi eseguire nuovamente il reverse engineering –

+0

@Bwmat, il "programma" sarà solo in memoria. Mai su disco. – Frankie

risposta

1

Questo è molto possibile utilizzando i caricatori di classe. Ma è ancora molto facile decodificare il tuo programma. Tutto ciò che si dovrebbe fare è cambiare il Loader in modo che scriva tutte le classi sul disco prima di caricarle in memoria con il ClassLoader personalizzato.

Aggiornamento

Se il caricatore è qualcosa che i vostri utenti possono eseguire poi avrei solo bisogno di decompilare e sostituire il file JAR Loader per scaricare le classi su disco. Non solo sono sicuro che ci deve essere qualcosa che può prendere un dump di memoria di una JVM e generare tutto il codice byte caricato.

Se il programma di caricamento è su una macchina bloccata in cui gli utenti non possono ottenere l'accesso, qual è il caso d'uso che si sta tentando di risolvere?

Le "soluzioni" a questi problemi sono:

  1. Utilizzare un Obfuscator avanzato che è stato progettato per rompere decompilers.
  2. Impedire l'accesso ai file JAR stessi. O tramite ACL sulla macchina o impiegando un server remoto per eseguire il codice che si desidera proteggere. Questo è essenzialmente il modo in cui funzionano le applicazioni Web. Ci può essere una quantità notevole di IP o di elaborazione che StackOverflow fa ma non avremmo mai accesso all'elaborazione back-end, sul risultato dell'output User Experience.
+0

prendere in considerazione il fatto che se si fosse ricreato il caricatore si sarebbe eseguito in un altro computer che non sarebbe stato autorizzato dal server remoto. Hai una soluzione migliore (usando Java)? Grazie. – Frankie

+0

@Frankie Perché dovrebbe essere eseguito su una macchina diversa? Il tuo caricatore è su una macchina a cui nessuno avrebbe accesso? Se è così, perché sei preoccupato della decompilazione? –

+0

@Frankie La macchina che esegue il caricatore ha funzionalità limitate? Cosa deve impedire a un utente malintenzionato di creare un contenitore di un caricatore compromesso e rimetterlo sul computer originale? – matts

Problemi correlati