Вы запутываете свой коммерческий Java-код?

Ответ 1

Если вы делаете обфускацию, держитесь подальше от обфускаторов, которые изменяют код, изменяя поток кода и/или добавляя блоки исключений и т.д., чтобы затруднить его дизассемблирование. Чтобы сделать код нечитаемым, обычно достаточно просто изменить все имена методов, полей и классов.

Причина того, чтобы избежать изменения потока кода, заключается в том, что некоторые из этих изменений не позволяют JVM эффективно оптимизировать код. Фактически это фактически ухудшит производительность вашего приложения.

Ответ 2

Я думаю, что старый (классический) способ обфускации постепенно теряет свою актуальность. Потому что в большинстве случаев классические обфускаторы разбивают трассировку стека (это не хорошо для поддержки ваших клиентов)

В настоящее время основной задачей является не защита некоторых алгоритмов, а защита конфиденциальных данных: логины/пароли/ключи API, код, который отвечает за лицензирование (пиратство все еще здесь, особенно в Западной Европе, России, Азии, IMHO), рекламная учетная запись Идентификаторы и т.д.

Интересный факт: у нас есть все эти важные данные в Strings. Фактически Strings составляет около 50-80% от логики наших приложений. Мне кажется, что будущее обфускации - это "инструменты шифрования строк".

Но теперь функция "String encryption" доступна только в коммерческих обфускаторах, таких как: Allatori, Zelix KlassMaster, Smokescreen, Stringer Java Obfuscation Toolkit, DashO.

N.B. Я генеральный директор компании Licel. Разработчик Stringer Java Obfuscator.

Ответ 3

Я использую proguard для разработки JavaME. Это не только очень хорошо помогает уменьшить размер файлов jar (Essential for mobile), но и полезен как лучший способ сделать код, специфичный для устройства, не прибегая к недружественным инструментам предварительной обработки IDE, таким как антенна.

например.

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

Это компилируется, обфускается, и файл класса заканчивается так, как если бы вы написали:

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

Таким образом, у вас могут быть варианты кода для работы с ошибками производителя в реализациях JVM/library без добавления окончательных файлов исполняемых файлов.

Я считаю, что некоторые коммерческие обфускаторы также могут объединять файлы классов в определенных случаях. Это полезно, потому что чем больше у вас классов, тем больше размер накладных расходов у вас в файле zip (jar).

Ответ 4

Я потратил некоторое время в этом году на тестирование различных Java-обфускаторов, и я нашел, что один пробег впереди остальных: JBCO. К сожалению, он немного громоздко настроен и не имеет графического интерфейса, но с точки зрения уровня запутывания, который он производит, он не имеет себе равных. Вы пытаетесь кормить его простым циклом, и если ваш декомпилятор не разбивается, пытаясь загрузить его, вы увидите что-то вроде этого:

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

        }

    }

Вы не знали, что Java имеет goto? Ну, JVM поддерживает их =)

Ответ 5

Я использую ProGuard и настоятельно рекомендую его. Хотя обфускация защищает ваш код от случайных злоумышленников, основным преимуществом является минимизирующий эффект удаления неиспользуемых классов и методов и сокращения всех идентификаторов до 1 или 2 символов.

Ответ 6

Я думаю, что по большей части обфускация бессмысленна: даже с полным исходным кодом это обычно достаточно сложно, чтобы выяснить, что это за намерение (при условии, что комментариев нет, и нет значимых имен для локальных переменных - случай, когда регенерация источников из байтового кода). Обфускация просто украшает торт.

Я думаю, что разработчики и особенно их менеджеры склонны сильно преувеличивать риск того, что кто-то увидит исходный код. В то время как хорошие декомпиляторы могут создавать красиво выглядящий исходный код, это не тривиально работать с ним, а связанные с этим затраты (не говоря уже о юридических рисках) достаточно высоки, чтобы этот подход редко был полезен. Я только декомпилировал, чтобы отлаживать проблемы с продуктами поставщиков с закрытыми исходными кодами (взаимоблокировки в слое абстракции DB, ugh). Я думаю, что байткод был фактически запутан, но мы все же нашли основную проблему - это была фактическая проблема проектирования.

Ответ 7

Я думаю, это действительно сводится к тому, для чего нужен ваш Java-код, как он распространяется и кто ваши клиенты. Мы ничего не пугаем, поскольку мы никогда не находили того, что было особенно хорошо, и это, как правило, больше проблем, чем того стоит. Если кто-то имеет доступ к нашим файлам JAR и обладает знаниями, которые могут обнюхать их внутри, то гораздо более тревожные вещи, которые они могут сделать, чем срывать наш исходный код.