Czy zaciemniasz swój komercyjny kod Java?

Question

Zastanawiam się, czy ktoś używa komercyjnych/darmowych obfuscatorów java na swoim własnym komercyjnym produkcie. Wiem tylko o jednym projekcie, który faktycznie miał ukryty krok w kroku budowy mrówek dla wydań.

Czy zaciemniasz obraz? A jeśli tak, to dlaczego je ignorujesz?

Czy to naprawdę sposób na ochronę kodu lub czy jest to po prostu lepsze odczucie dla programistów/menedżerów?

edit: Ok, a dokładnie o moim punkcie: Czy zaciemniać do ochrony IP (swoje algorytmy, pracę, którą umieściliśmy na swoje produkty)? Nie będę się zamazywał ze względów bezpieczeństwa, co nie jest w porządku. Więc mówię tylko o ochronie kodu aplikacji przed konkurentami.

@staffan ma dobry punkt:

Powodem się trzymać z dala od łańcuchowym przepływ kodu jest to, że niektóre z tych zmian uniemożliwia JVM skutecznie zoptymalizować kod. W efekcie obniży to wydajność twojej aplikacji.

Answer 1

W przypadku zaciemniania należy unikać obfuscatorów, które modyfikują kod, zmieniając przepływ kodu i/lub dodając bloki wyjątków i takie, które utrudniają ich dezasemblację. Aby uczynić kod nieczytelnym, zwykle wystarczy zmienić wszystkie nazwy metod, pól i klas.

Powodem, dla którego nie należy zmieniać przepływu kodu, jest to, że niektóre z tych zmian uniemożliwiają JVM wydajną optymalizację kodu. W efekcie obniży to wydajność twojej aplikacji.

Answer 2

Chyba tak naprawdę sprowadza się do co kod Java jest, jak to jest rozpowszechniany i kim są twoi klienci. Nic nie zaciemniamy, ponieważ nigdy nie znaleźliśmy czegoś, co było szczególnie dobre, a to sprawia więcej problemów niż jest warte. Jeśli ktoś ma dostęp do naszych plików JAR i ma wiedzę, aby móc węszyć w ich wnętrzu, to jest o wiele więcej niepokojących rzeczy, niż mogą zdziałać nasz kod źródłowy.

Answer 3

Używam proguard do rozwoju JavaME. Jest to nie tylko bardzo dobre w zmniejszaniu rozmiarów plików JAR (Essential for mobile), ale jest również użyteczne jako lepszy sposób na tworzenie kodu specyficznego dla urządzenia bez uciekania się do nieprzyjaznych dla IDE narzędzi do przetwarzania, takich jak antena.

E.g.

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

ta zostanie skompilowany, ukrywane, a plik klasa kończy się tak, jakby trzeba było napisane:

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

Więc można mieć warianty kodu do obejścia błędów producentem w implementacjach/Library JVM bez łączenie plików końcowych plików wykonywalnych.

Sądzę, że niektóre komercyjne obfuscatory mogą w niektórych przypadkach łączyć ze sobą pliki klas. Jest to użyteczne, ponieważ im więcej masz klas, tym większy rozmiar masz w pliku zip (jar).

Answer 4

Spędziłem w tym roku trochę czasu, próbując różnych obfuscatorów Javy, i znalazłem jedną milę przed resztą: JBCO.Jest niestety dość kłopotliwa w konfiguracji i nie ma GUI, ale pod względem poziomu zaciemniania, który generuje, jest niezrównany. Próby karmienia bardzo prostą pętlę, a jeśli Dekompilator nie psuje próbuje go załadować, można zobaczyć coś takiego:

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

     } 

    } 

nie wiedziałeś Java miał Goto? Cóż, JVM je obsługuje =)

Answer 5

Używam ProGuard i bardzo polecam. Podczas gdy zaciemnianie chroni twój kod przed przypadkowymi napastnikami, główną korzyścią jest minimalizujący efekt usunięcia nieużywanych klas i metod oraz skrócenie wszystkich identyfikatorów do 1 lub 2 znaków.

Answer 6

Uważam, że w większości przypadków zaciemnianie nie ma sensu: nawet przy pełnym kodzie źródłowym jest na ogół wystarczająco ciężko, aby dowiedzieć się, co to jest cholerna intencja (zakładając, że nie ma komentarzy i nie ma znaczących nazw dla zmiennych lokalnych - czyli przypadek, gdy ponownie generuje źródła z kodu bajtowego). Obfuskacja właśnie ozdabia ciasto.

Myślę, że deweloperzy, a zwłaszcza ich menadżerowie, mają tendencję do nadmiernego przesadzania z ryzykiem, że ktoś zobaczy kod źródłowy. Podczas gdy dobre dekompilatory mogą produkować ładnie wyglądający kod źródłowy, nie jest to łatwe do pracy z nim, a koszty związane (nie wspominając o ryzyku prawnym) są wystarczająco wysokie, aby takie podejście rzadko bywa użyteczne. Dekompilowałem tylko do debugowania problemów z produktami dostawców o zamkniętym kodzie (zakleszczenia w warstwie abstrakcji DB, ugh). Bytecode zostało faktycznie zaciemnione, ale mimo to znaleźliśmy podstawowy problem - był to prawdziwy problem projektowy.

Answer 7

Myślę, że stary (klasyczny) sposób zaciemniania stopniowo traci na znaczeniu. Ponieważ w większości przypadków klasyczne obfuscatory przerywają śledzenie stosu (nie jest to dobre dla obsługi klientów)

Obecnie głównym celem nie jest ochrona niektórych algorytmów, ale ochrona wrażliwych danych: loginy/hasła/klucze API, kod odpowiedzialne za licencjonowanie (nadal piractwo, zwłaszcza w Europie Zachodniej, Rosji, Azji, IMHO), identyfikatory kont reklamowych itp.

Interesujący fakt: wszystkie te poufne dane mamy w Strings. Właściwie Strings to około 50-80% logiki naszych aplikacji. Wydaje mi się, że przyszłością zaciemniania jest "Narzędzia szyfrujące łańcuchy".

Ale teraz "szyfrowanie String" funkcja jest dostępna tylko w obfuscators handlowych, takich jak: Allatori, Zelix KlassMaster, Smokescreen, Stringer Java Obfuscation Toolkit, DashO.

N.B. Jestem CEO w Licel LLC. Twórca Stringer Java Obfuscator.