Offuschi il tuo codice Java commerciale?[Chiuso]

Question

Mi chiedo se qualcuno utilizzi offuscatori Java commerciali/gratuiti sul proprio prodotto commerciale.Conosco solo un progetto che in realtà ha avuto una fase di offuscamento nella fase di creazione della formica per i rilasci.

Offuschi?E se sì, perché offuschi?

È davvero un modo per proteggere il codice o è semplicemente una sensazione migliore per gli sviluppatori/manager?

modificare: Ok, per essere preciso sul punto:Offuschi per proteggere il tuo IP (i tuoi algoritmi, il lavoro che hai dedicato al tuo prodotto)?Non offuscherò per motivi di sicurezza, non mi sembra giusto.Quindi sto solo parlando di proteggere il codice delle tue applicazioni dai concorrenti.

@staffan ha un buon punto:

Il motivo per evitare di concatenare il flusso di codice è che alcune di queste modifiche rendono impossibile per la JVM ottimizzare in modo efficiente il codice.In effetti degraderà effettivamente le prestazioni della tua applicazione.

Answer 1

Se offuschi, stai lontano dagli offuscatori che modificano il codice modificando il flusso del codice e/o aggiungendo blocchi di eccezioni e simili per renderlo difficile disassemblarlo.Per rendere illeggibile il codice di solito è sufficiente cambiare semplicemente tutti i nomi di metodi, campi e classi.

Il motivo per evitare di modificare il flusso del codice è che alcune di queste modifiche rendono impossibile per la JVM ottimizzare in modo efficiente il codice.In effetti degraderà effettivamente le prestazioni della tua applicazione.

Answer 2

Penso che il vecchio modo (classico) di offuscamento stia gradualmente perdendo la sua rilevanza.Perché nella maggior parte dei casi un offuscatore classico interrompe l'analisi dello stack (non va bene per supportare i tuoi clienti)

Al giorno d'oggi il punto principale non è proteggere alcuni algoritmi, ma proteggere un dato sensibile:Login/password/chiavi API, codice responsabile della licenza (pirateria ancora qui, in particolare Europa occidentale, Russia, Asia, IMHO), ID account pubblicitari, ecc.

Fatto interessante:abbiamo tutti questi dati sensibili in Strings.In realtà le stringhe rappresentano circa il 50-80% della logica delle nostre applicazioni.Mi sembra che il futuro dell'offuscamento siano gli "strumenti di crittografia delle stringhe".

Ma ora la funzionalità "Crittografia stringa" è disponibile solo negli offuscatori commerciali, come: Allatori, Zelix KlassMaster, Cortina di fumo, Stringer Java Obfuscation Toolkit, DashO.

N.B.Sono amministratore delegato di Licel LLC.Sviluppatore di Stringer Java Obfuscator.

Answer 3

Utilizzo Proguard per lo sviluppo JavaME.Non solo è molto efficace nel ridurre i file jar (essenziale per i dispositivi mobili), ma è utile come un modo migliore per eseguire codice specifico per il dispositivo senza ricorrere a strumenti di preelaborazione ostili all'IDE come antenna.

Per esempio.

public void doSomething()
{
    /* Generated config class containing static finals: */
    if (Configuration.ISMOTOROLA)
    {
        System.out.println("This is a motorola phone");
    }
    else
    {
        System.out.println("This is not a motorola phone");
    }
}

Questo viene compilato, offuscato e il file di classe finisce come se avessi scritto:

public void doSomething()
{
    System.out.println("This is a motorola phone");
}

In questo modo puoi avere varianti di codice per aggirare i bug del produttore nelle implementazioni JVM/libreria senza sovraccaricare i file di classe eseguibili finali.

Credo che alcuni offuscatori commerciali possano anche unire insieme i file di classe in alcuni casi.Ciò è utile perché più classi hai, maggiore è la dimensione del sovraccarico nel file zip (jar).

Answer 4

Ho trascorso un po' di tempo quest'anno provando vari offuscatori Java e ne ho trovato uno molto più avanti degli altri: JBCO.Sfortunatamente è un po' complicato da configurare e non ha una GUI, ma in termini di livello di offuscamento che produce, non ha eguali.Provi ad alimentarlo con un semplice ciclo e se il tuo decompilatore non si blocca durante il caricamento, vedrai qualcosa del genere:

    if(i < ll1) goto _L6; else goto _L5
_L5:
    char ac[] = run(stop(lI1l));
    l7 = (long)ac.length << 32 & 0xffffffff00000000L ^ l7 & 0xffffffffL;
    if((int)((l7 & 0xffffffff00000000L) >> 32) != $5$)
    {
        l = (long)III << 50 & 0x4000000000000L ^ l & 0xfffbffffffffffffL;
    } else
    {
        for(l3 = (long)III & 0xffffffffL ^ l3 & 0xffffffff00000000L; (int)(l3 & 0xffffffffL) < ll1; l3 = (long)(S$$ + (int)(l3 & 0xffffffffL)) ^ l3 & 0xffffffff00000000L)
        {
            for(int j = III; j < ll1; j++)
            {
                l2 = (long)actionevent[j][(int)(l3 & 0xffffffffL)] & 65535L ^ l2 & 0xffffffffffff0000L;
                l6 = (long)(j << -351) & 0xffffffffL ^ l6 & 0xffffffff00000000L;
                l1 = (long)((int)(l6 & 0xffffffffL) + j) & 0xffffffffL ^ l1 & 0xffffffff00000000L;
                l = (long)((int)(l1 & 0xffffffffL) + (int)(l3 & 0xffffffffL)) << 16 & 0xffffffff0000L ^ l & 0xffff00000000ffffL;
                l = (long)ac[(int)((l & 0xffffffff0000L) >> 16)] & 65535L ^ l & 0xffffffffffff0000L;
                if((char)(int)(l2 & 65535L) != (char)(int)(l & 65535L))
                {
                    l = (long)III << 50 & 0x4000000000000L ^ l & 0xfffbffffffffffffL;
                }
            }

        }

    }

Non sapevi che Java avesse avuto dei goto?Bene, la JVM li supporta =)

Answer 5

Io uso ProGuard e lo consiglio vivamente.Sebbene l'offuscamento protegga il tuo codice da attacchi occasionali, il suo vantaggio principale è l'effetto di minimizzazione della rimozione di classi e metodi inutilizzati e della riduzione di tutti gli identificatori a 1 o 2 caratteri.

Answer 6

Penso che per la maggior parte l'offuscamento sia inutile:anche con il codice sorgente completo è generalmente abbastanza difficile capire quale fosse l'intenzione (supponendo che non ci siano commenti e nomi significativi per le variabili locali, come nel caso della rigenerazione di sorgenti dal codice byte).L'offuscamento decora solo la torta.

Penso che gli sviluppatori e soprattutto i loro manager tendano a esagerare notevolmente il rischio che qualcuno veda il codice sorgente.Sebbene i buoni decompilatori possano produrre un codice sorgente dall'aspetto gradevole, non è banale lavorarci e i costi associati (per non parlare dei rischi legali) sono abbastanza alti da rendere questo approccio raramente utile.Ho decompilato solo per eseguire il debug dei problemi con i prodotti dei fornitori closed-source (deadlock nel livello di astrazione DB, ugh).Credo che il bytecode fosse effettivamente offuscato, ma abbiamo comunque trovato il problema di fondo: si trattava di un vero problema di progettazione.

Answer 7

Immagino che si tratti davvero di Che cosa a cosa serve il tuo codice Java, come è distribuito e chi sono i tuoi clienti.Non offusiamo nulla, poiché non ne abbiamo mai trovato uno particolarmente buono e tende a essere più un problema che un vantaggio.Se qualcuno ha accesso ai nostri file JAR e ha le conoscenze necessarie per poterli annusare, allora ci sono cose molto più preoccupanti che può fare che fregare il nostro codice sorgente.