[JAVA] "Blindatura" di una classe

[alka]

Originariamente inviato da tonytalk
Inserire l'algoritmo in un metodo nativo dovrebbe essere "protetto" (protetto tra virgolete perchè io penso che nulla informaticamente parlando sia veramente protetto)

Hai perfettamente ragione...non mi era nemmeno venuto in mente.

E dire che l'ho proprio fatto recentemente, non con Java ma su .NET, ma il concetto è identico.

Però, si dovrebbe sviluppare una versione "nativa" dell'algoritmo (ad esempio, una DLL?) per ogni sistema operativo che si desidera indirizzare...o sbaglio?

Ciao!

[LeleFT]

Di offuscatori per Java ce ne sono abbastanza, il problema è che sono quasi tutti a pagamento (e non costano poco!)

Comunque, cercando con Google ho trovato questo che da quanto scritto dovrebbe essere Free.
Non l'ho provato, ma mi ricordo che anche JBuilder (sempre nella versione Enterprise, a pagamento) ha incorporato un offuscatore.

Aggiungo solamente che gli offuscatori generano del codice ridondante e molto spesso codice che può essere eseguito dalla VM, ma non compilato. Cosa vuol dire: se qualcuno tenta di decompilare i .class dell'applicazione si ritroverà con del codice che non potrà essere ricompilato perchè fa uso di istruzioni che sono state inibite al compilatore (salti incondizionati, soprattutto). Per cui il codice diventa maggiormente illeggibile e sopratutto non ricompilabile.


Ciao.

[tonytalk]

Originariamente inviato da LeleFT

Aggiungo solamente che gli offuscatori generano del codice ridondante e molto spesso codice che può essere eseguito dalla VM, ma non compilato. Cosa vuol dire: se qualcuno tenta di decompilare i .class dell'applicazione si ritroverà con del codice che non potrà essere ricompilato perchè fa uso di istruzioni che sono state inibite al compilatore (salti incondizionati, soprattutto). Per cui il codice diventa maggiormente illeggibile e sopratutto non ricompilabile.

Non è esattamente così, in pratica le persone che vogliono offuscare il codice e fornire un livello di protezione maggiore possono sfruttare alcuni bug dei decompilatori.

Come si fa a fregare un decompilatore, si fa ad esempio prendendo un file .class ed aprendolo con uno strumento particolare e manomettendo questo file nella posizione corretta.
per ulteriori dettagli prova questo link http://www.mokabyte.it/2001/10/decompilaizone.htm

Quello che bisogna capire però è che le istruzioni che si vanno ad inserire in un class sono istruzioni che

1)Non verranno mai eseguite quindi del tipo

....
return x //qui termina il metodo
if(true) {
int z=-1
}

}


2)Queste istruzioni impediranno la compilazione corretta de file


Ma a mio parere ci voglione 20 minuti ad eliminare questo codice "sporco" e riuscire quindi a compilare senza alcun prolema.

I file .class NON sono in nessun modo protetti

Sun dice che ha in mente uno strumento o un meccanismo di protezione per le classi ma lo dice da troppo tempo :-)

Ciao


PS i migliori decompilatori sono il jad a mi trovo molto bene con il jode-1.1.2-pre1

Se non funziona uno provate l'altro

[LeleFT]

Originariamente inviato da tonytalk
Non è esattamente così, in pratica le persone che vogliono offuscare il codice e fornire un livello di protezione maggiore possono sfruttare alcuni bug dei decompilatori.

Come si fa a fregare un decompilatore, si fa ad esempio prendendo un file .class ed aprendolo con uno strumento particolare e manomettendo questo file nella posizione corretta.
per ulteriori dettagli prova questo link http://www.mokabyte.it/2001/10/decompilaizone.htm

Quello che bisogna capire però è che le istruzioni che si vanno ad inserire in un class sono istruzioni che

1)Non verranno mai eseguite quindi del tipo

....
return x //qui termina il metodo
if(true) {
int z=-1
}

}


2)Queste istruzioni impediranno la compilazione corretta de file


Ma a mio parere ci voglione 20 minuti ad eliminare questo codice "sporco" e riuscire quindi a compilare senza alcun prolema.

I file .class NON sono in nessun modo protetti

Sun dice che ha in mente uno strumento o un meccanismo di protezione per le classi ma lo dice da troppo tempo :-)

Ciao

Io ho avuto modo di trovarmi di fronte da un programma che non funzionava (la software house che l'ha programmato ha commesso un piccolissimo errore di valutazione...) ed ho utilizzato un decompilatore per controllarne il compilato (sia chiaro, ho solo fatto presente a questa software house del problema, non mi sono messo a riprogrammare la loro applicazione)... mi sono imbattuto in istruzioni del tipo

goto _etichetta;

Da quello che so la software house non ha alcuno "strumento particolare" per modificare i propri .class, ma sfrutta proprio un offuscatore. Da questo desumo che esistono degli offuscatori in grado di generare un codice compilato e, successivamente, modificarlo a tale scopo.


Ciao.

[tonytalk]

Si ho trovato anche istruzioni del tipo
goto etichetta ...spesso basta buttare tutto via oppure il decompilatore è andato parzialmente in palla e quindi dovresti provare con un altro decompilatore.

Ciao


PS i migliori decompilatori sono il jad a mi trovo molto bene con il jode-1.1.2-pre1

Se non funziona uno provate l'altro

[LeleFT]

Originariamente inviato da tonytalk
PS i migliori decompilatori sono il jad a mi trovo molto bene con il jode-1.1.2-pre1

Ho decompilato proprio con il JAD!

Comunque, un modo per rendere ancora più difficile la strada a chi vuole decompilare è quella di inserire fin dall'inizio delle "offuscazioni". Nessuno vieta di scrivere a mano dei cicli inutili, chiamate a metodi che ritornano valori mai usati o valori costantemente preceduti o seguiti da sporcizia... l'offuscatore non farà altro che aggiungere altra "complessità" a quell'inutilità di codice già presente nel sorgente.


Ciao.

[tonytalk]

Originariamente inviato da LeleFT
Ho decompilato proprio con il JAD!

Comunque, un modo per rendere ancora più difficile la strada a chi vuole decompilare è quella di inserire fin dall'inizio delle "offuscazioni". Nessuno vieta di scrivere a mano dei cicli inutili, chiamate a metodi che ritornano valori mai usati o valori costantemente preceduti o seguiti da sporcizia... l'offuscatore non farà altro che aggiungere altra "complessità" a quell'inutilità di codice già presente nel sorgente.


Ciao.

Prova anche jode se ricordo bene il goto è sparito eheheheh con questo decompilatore

Ciao

[LeleFT]

Posto un esempio di codice "abbastanza offuscato" per rendere l'idea: un codice come questo, seppur in chiaro, non è così semplice da interpretare o da capire, proprio perchè sono state volutamente aggiunte parti di codice ridondante e non perfettamente chiaro.

public class Offusc {
   private String offuscata;
   public Offusc() {
      offuscata = "!S£E$M%G";
   }
   public void startApp() {
      String start = offuscata;
      System.out.println( stampaStringa(start) );  
   }

   public static void main(String [] args) {
      Offusc off = new Offusc();
      off.startApp();
   }

   private String stampaStringa(String str) {
      String first =((Offusc) getClassCode("other")).returnString("first", str);
      return first;
   }

   private Object getClassCode(String source) {
      Object obj;
      if (!source.equals( "" + source)) {
         if (source.equals("other")) {
            obj = null;
         } else {
            obj = new String("Offusc");
         }
      } else {
         obj = this;
      }
      return obj;
   }

   private String returnString(String source, String dest) {
      String tmp = dest;
      String out = "";
      int [] code = {0x7A, 0x05, 0xF2, 0x38};
      int k = 0;
      dest = source;
      for (int i=0; i<tmp.length(); i++) {
         if (!((i%2) == 0)) {
            out += tmp.substring(0,(k%2));
         } else {
            out += (char)((int) tmp.substring(
                                (tmp.length()-k)-1,
                                (tmp.length()-k)).charAt(0) - code.length);
            k+=2;
         }
      }
      return out;
   }
}

Ciao.

[edark]

Originariamente inviato da LeleFT
Ho decompilato proprio con il JAD!

Comunque, un modo per rendere ancora più difficile la strada a chi vuole decompilare è quella di inserire fin dall'inizio delle "offuscazioni". Nessuno vieta di scrivere a mano dei cicli inutili, chiamate a metodi che ritornano valori mai usati o valori costantemente preceduti o seguiti da sporcizia... l'offuscatore non farà altro che aggiungere altra "complessità" a quell'inutilità di codice già presente nel sorgente.


Ciao.

cosi facendo non sia sporca inutilmente il codice?(parlo dell'efficienza del programma)

[LeleFT]

Originariamente inviato da edark
cosi facendo non sia sporca inutilmente il codice?(parlo dell'efficienza del programma)

Certamente sì... e anche in termini di manutenibilità del programma.
L'importante è sapere esattamente cosa si sta facendo e, magari, creare una copia del sorgente con tutti i commenti del caso.

Per quanto riguarda l'efficienza del codice, è pur vero che essa viene diminuita, ma solo in termini di efficienza algoritmica... in pratica in termini di sensazione da parte dell'utente non ci sono effetti, se si pensa oltretutto che già l'offuscatore effettua questo genere di "sporcatura" lavorando su un codice pulito.


Ciao.