Obfuscate codul tău comercial Java?

Mă întreb dacă cineva folosește obfuscatorii comerciali/liberi pe propriul produs comercial. Știu doar despre un proiect care a avut de fapt un pas de obfuscare în etapa de construire a furnici pentru eliberări.

Ești obfuscat? Și dacă e așa, de ce nu-l obligești?

Este într-adevăr o modalitate de a proteja codul sau este doar un sentiment mai bun pentru dezvoltatori/manageri?

edit: Ok, I to be exact about my point: Do you obfuscate to protect your IP (your algorithms, the work you've put into your product)? I won't obfuscate for security reasons, that doesn't feel right. So I'm only talking about protecting your applications code against competitors.

@staffan has a good point:

Motivul pentru a nu fi înlăturate de fluxul de coduri de legare este că unele dintre aceste modificări fac imposibil pentru JVM să optimizeze eficient codul. De fapt, aceasta va degrada efectiv performanța aplicației dvs.

0
fr hi bn
Nu am văzut încă un obfuscator bun, dar poate că vrei să te uiți la acest thread, chiar dacă este vorba despre .Net: http://stackoverflow.com/questions/12075/should-i-be-worried‌ -Despre-obfusicating- & zwnj, mi-net-cod
adăugat autor John Smithers, sursa

7 răspunsuri

Folosesc ProGuard și o recomand foarte mult. În timp ce obfuscația vă protejează codul de atacatorii obișnuiți, avantajul principal îl reprezintă efectul minimizării eliminării clasei și metodelor neutilizate și scurtarea tuturor identificatorilor la 1 sau 2 caractere.

0
adăugat
@ user384706: Da, folosesc ProGuard cu cod care folosește extensiv reflecția. Trebuie să îl configurați pentru a păstra elementele reflectate, cu excepția utilizării simple a Class.forName() .
adăugat autor Lawrence Dol, sursa
Mă întrebam că ați obfuscat vreodată codul care folosește pe larg reflecția? Aveați probleme?
adăugat autor Cratylus, sursa

Cred că se întâmplă cu adevărat ce codul tău Java este pentru, cum este distribuit și cine sunt clienții tăi. Nu împiedicăm nimic, pentru că nu am găsit niciodată una care să fie deosebit de bună și are tendința de a avea mai multe probleme decât merită. Dacă cineva are acces la fișierele noastre JAR și are cunoștințele necesare pentru a putea străpunge în interiorul lor, atunci sunt lucruri mult mai îngrijorătoare pe care le pot face decât să ne distrugă codul sursă.

0
adăugat

Eu folosesc proguard pentru dezvoltarea JavaME. Nu este doar foarte bun pentru a face fișierele de jar mai mici (esențiale pentru telefonul mobil), dar este util ca un mod mai plăcut de a face codul dispozitivului, fără a recurge la unelte de preprocesare nepotrivite IDE, cum ar fi antena.

De exemplu.

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");
    }
}

Acest lucru este compilat, obfuscated, iar fișierul de clasă se termină ca și cum ați fi scris:

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

Deci, aveți posibilitatea să aveți variante de cod pentru a rezolva erorile producătorului în implementările JVM/bibliotecă, fără a extinde fișierele clasa executivă finală.

Cred că unele obfuscatorii comerciale pot îmbina, de asemenea, fișiere de clasă împreună în anumite cazuri. Acest lucru este util deoarece mai multe clase pe care le aveți, cu atât este mai mare dimensiunea deasupra capului pe care o aveți în fișierul zip (jar).

0
adăugat
De fapt, în ceea ce privește codul condițional, specificația Java necesită ca un compilator să scadă un cod mort ca acesta, dacă condiția este atribuită printr-o expresie statică falsă. Care este tot ce poate face Proguard.
adăugat autor Lawrence Dol, sursa

Dacă faceți obfuscări, nu vă abțineți de la obfuscatorii care modifică codul modificând fluxul de cod și/sau adăugând blocuri de excepție și astfel încât să fie greu de dezasamblat. Pentru a face ca codul să nu fie citit, este de obicei suficient să schimbați toate numele metodelor, câmpurilor și claselor.

Motivul pentru a nu fi în măsură să schimbe fluxul de coduri este că unele dintre aceste modificări fac imposibil pentru JVM să optimizeze eficient codul. De fapt, aceasta va degrada efectiv performanța aplicației dvs.

0
adăugat
Sună ca o optimizare prematură pentru mine.
adăugat autor NateS, sursa

Cred că, în cea mai mare parte, obfuscația este inutilă: chiar și cu codul sursă complet este destul de greu să înțelegi ce intenție a fost heck (presupunând că nu există comentarii și nici un nume semnificativ pentru variabilele locale - - generarea surselor din codul octet). Obfuscatia doar decoreaza tortul.

Cred că dezvoltatorii și, în special, managerii lor tind să exagereze prea mult riscul ca cineva să vadă codul sursă. Deși bunele decompilatoare pot produce un cod sursă frumos, nu este deloc banal să lucrezi cu acesta, iar costurile asociate (ca să nu mai vorbim de riscurile juridice) sunt destul de ridicate pentru a face ca această abordare să fie rareori utilă. Am decompilat doar pentru a depana probleme cu produsele furnizorilor cu surse închise (blocaj în stratul de abstractizare DB, ugh). Bytecode a fost, de fapt, obfuscated, cred, dar am găsit totuși problema de bază - a fost o problemă reală de design.

0
adăugat

Cred că vechiul mod (clasic) al obfuscării își pierde treptat relevanța. Deoarece, în majoritatea cazurilor, un obfuscator clasic care rupe o urmă de stivă (nu este bine să îi sprijini pe clienți)

În prezent, punctul principal nu este să protejezi niște algoritmi, ci să protejezi datele sensibile: login-uri API/parole/chei, cod responsabil pentru licențiere (pirateria încă aici, în special Europa de Vest, Rusia, Asia, IMHO) .

Un fapt interesant: avem toate aceste date sensibile în șir. De fapt, șirul este de aproximativ 50-80% din logica aplicațiilor noastre. Mi se pare că viitorul obfuscării este "instrumente de criptare a șirului".

Dar acum caracteristica "Encryption String" este disponibilă numai în obfuscatorii comerciali, cum ar fi: Allatori , Zelix KlassMaster , Smokescreen , Stringer Java Obfuscation Toolkit , DashO .

N.B. Sunt CEO la Licel LLC. Programator de Stringer Java Obfuscator.

0
adăugat
Asta este foarte adevărat. În aceste zile există atât de multe proiecte open source pe care nimeni nu le pasă de codul sursă comercial al altor persoane. Punctul principal este acela de a proteja exact anumite informații (mici) specifice, cum ar fi KEYS PRIVATE și PASSWORDS.
adăugat autor marcolopes, sursa

Am petrecut ceva timp în acest an încercând diferite obfuscatorii Java, și am găsit unul care să fie la mila înaintea restului: OCCF . Din păcate, este greu de configurat și nu are GUI, dar din punctul de vedere al nivelului de obfuscare pe care îl produce, este de neegalat. Încercați să o hrăniți cu o bucla simplă și dacă decompilatorul dvs. nu se prăbușește încercând să îl încarce, veți vedea ceva de genul:

    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;
                }
            }

        }

    }

Nu știai că Java avea să fie? Ei bine, JVM îi sprijină =)

0
adăugat
La nivelul codului mașinii (și prin urmare în bytecode, care este pur și simplu codul mașinii independente de mașină) toate computerele folosesc gata. Buclele sunt construite pur și simplu/construite. Incident, continuarea și ruperea nu reprezintă nimic altceva decât limitarea goală folosind etichete (uneori eticheta este dedusă, mai degrabă decât explicită).
adăugat autor Lawrence Dol, sursa
Aș adăuga un gând suplimentar ... dacă acesta este într-adevăr rezultatul unei "bucla simple", atunci plătește un cost ridicat în eficiență, în schimbul faptului că codul inversat este incompetent și obscur.
adăugat autor Lawrence Dol, sursa
Dezavantajul JBCO este că acesta este codul de calitate al cercetării. Nici măcar nu reușesc să ruleze pe cazuri simple de testare, iar documentația este practic inexistentă.
adăugat autor Antimony, sursa