Czy zaciemniasz swój komercyjny kod Java? [zamknięte]

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

Obecnie głównym punktem nie jest ochrona niektórych algorytmów, ale ochrona poufnych danych: loginy/hasła / klucze API, kod odpowiedzialny za licencjonowanie (piractwo nadal tutaj, zwłaszcza Europa Zachodnia, Rosja, Azja, IMHO), identyfikatory kont reklamowych itp.

Ciekawe fakt: mamy wszystkie te poufne dane w ciągach. W rzeczywistości ciągi to około 50-80% logiki naszych aplikacji. Wydaje mi się, że przyszłość zaciemniania to "Narzędzia szyfrowania ciągów".

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

NB Jestem dyrektorem generalnym w Licel LLC. Programista Stringer Java Obfuscator.

Używam proguard do tworzenia JavaME. Jest nie tylko bardzo dobry w zmniejszaniu plików jar (niezbędny dla urządzeń mobilnych), ale jest przydatny jako przyjemniejszy sposób wykonywania kodu specyficznego dla urządzenia bez uciekania się do nieprzyjaznych narzędzi do wstępnego przetwarzania IDE, takich jak antena.

Np.

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

To zostanie skompilowane, zaciemnione, a plik klasy skończy się tak, jakbyś napisał:

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

Więc możesz mieć warianty kodu do pracy nad błędami producenta w implementacjach JVM/library bez wypełniania plików klasy wykonywalnej.

Uważam, że niektóre komercyjne maskatory mogą również łączyć pliki klas w pewnych przypadkach. Jest to przydatne, ponieważ im więcej klas masz, tym większy rozmiar nad głową masz w pliku zip (jar).

W tym roku spędziłem trochę czasu na testowaniu różnych obfuscatorów Javy i znalazłem jeden, który wyprzedza resztę: JBCO . Jest to niestety trochę kłopotliwe w konfiguracji i nie ma GUI, ale pod względem poziomu zaciemnienia, który wytwarza, jest niezrównany. Spróbuj podać prostą pętlę, a jeśli twój dekompiler nie zawiesi się próbując go załadować, zobaczysz 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;
                }
            }

        }

    }

Używam ProGuard i Gorąco polecam. Podczas gdy zaciemnianie chroni kod przed przypadkowymi atakami, jego główną korzyścią jest zminimalizowanie efektu usuwania nieużywanych klas i metod oraz skrócenie wszystkich identyfikatorów do 1 lub 2 znaków.

Myślę, że w większości przypadków zaciemnianie jest bezcelowe: nawet przy pełnym kodzie źródłowym jest na tyle trudne, aby dowiedzieć się, jaki był zamiar Hecka (zakładając, że nie ma komentarzy i nie ma sensownych nazw dla zmiennych lokalnych-co ma miejsce w przypadku ponownego generowania źródeł z kodu bajtowego). Zaciemnienie ozdabia tylko ciasto.

Myślę, że deweloperzy, a zwłaszcza ich menedżerowie, mają tendencję do znacznie przesadzania z ryzykiem, że ktoś zobaczy kod źródłowy. Podczas gdy dobre Dekompilatory mogą wyprodukuj ładnie wyglądający kod źródłowy, praca z nim nie jest trywialna, a koszty z tym związane (nie wspominając o ryzyku prawnym) są wystarczająco wysokie, aby takie podejście rzadko było użyteczne. Dekompilowałem tylko w celu debugowania problemów z produktami dostawców z zamkniętymi źródłami (blokady w warstwie abstrakcji DB, ugh). Bytecode był rzeczywiście zaciemniony, ale mimo to znaleźliśmy podstawowy problem - był to rzeczywisty problem projektowy.

Myślę, że to naprawdę sprowadza się do do czego służy Twój kod Java, jak jest rozpowszechniany i kim są twoi klienci. Niczego nie zaciemniamy, ponieważ nigdy nie znaleźliśmy takiego, który byłby szczególnie dobry i sprawiałby więcej kłopotów niż jest wart. Jeśli ktoś ma dostęp do naszych plików JAR i ma wiedzę, aby móc węszyć wewnątrz nich, to jest o wiele więcej niepokojących rzeczy, które mogą zrobić, niż wyrwać nasz kod źródłowy.