Есть ли у вас запутать свой коммерческий код Java?

голоса
50

Интересно, если кто использует коммерческие / бесплатно Java обфускаторов на своем собственном коммерческом продукте. Я знаю только об одном проекте, который на самом деле имел стадию запутывания в муравьиной стадии сборки для выпусков.

Есть ли у вас запутать? И если да, то почему вы запутать?

Является ли это на самом деле способ защиты кода, или это просто лучшее чувство для разработчиков / менеджеров?

Изменить: Хорошо, я точнее о моей точке: Вы запутать , чтобы защитить ваш IP (ваши алгоритмы, работу вы положили в свой продукт)? Я не затемнять по соображениям безопасности, что не чувствует себя хорошо. Так что я говорю только о защите вашего приложения код защиты от конкурентов.

@staffan имеет хорошую точку:

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

Задан 15/08/2008 в 09:55
источник пользователем
На других языках...                            


7 ответов

голоса
60

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

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

Ответил 15/08/2008 d 11:57
источник пользователем

голоса
25

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

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

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

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

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

Ответил 13/04/2012 d 09:00
источник пользователем

голоса
17

Я использую ProGuard для развития JavaME. Это не только очень и очень хорошо делать опарник меньше (Essential для мобильных устройств), но это полезно как приятнее способом сделать код конкретного устройства, не прибегая к 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 / библиотеки без наполнителя из конечных исполняемых файлов класса.

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

Ответил 15/08/2008 d 10:29
источник пользователем

голоса
13

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

Ответил 02/05/2009 d 08:32
источник пользователем

голоса
13

Я провел некоторое время в этом году попробовать различные 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 была Гото? Ну, JVM поддерживает их =)

Ответил 21/09/2008 d 08:23
источник пользователем

голоса
12

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

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

Ответил 16/05/2009 d 07:39
источник пользователем

голоса
7

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

Ответил 15/08/2008 d 10:22
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more