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

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

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

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

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

У @staffan есть хороший момент:

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

15.08.2008 08:55:28
Я еще не видел хорошего обфускатора, но, возможно, вы захотите посмотреть эту ветку, даже если речь идет о .Net: http://stackoverflow.com/questions/12075/should-i-be-worried-about-obfusicating -my-net-code
John Smithers 15.08.2008 09:16:17
7 ОТВЕТОВ
РЕШЕНИЕ

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

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

62
25.06.2014 13:09:33
Звучит как преждевременная оптимизация для меня.
NateS 30.01.2014 18:48:28

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

7
15.08.2008 09:22:45

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

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

17
15.08.2008 09:29:07
Фактически, что касается условного кода, спецификация Java требует, чтобы компилятор отбрасывал мертвый код, подобный этому, при условии, что условие назначено через статически ложное выражение. Что все, что Proguard может сделать.
Lawrence Dol 10.01.2017 03:13:10

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

13
21.09.2008 07:23:26
На уровне машинного кода (и, следовательно, в байт-коде, который является просто машинно-независимым машинным кодом) все компьютеры используют goto. Циклы - это просто конструкции goto / condition. Между прочим, continue и break - это не что иное, как ограниченное использование меток (иногда метка выводится, а не явно).
Lawrence Dol 27.04.2011 05:55:41
Недостатком JBCO является то, что это код качества исследований. Я даже не могу заставить его работать на простых тестовых примерах, а документация практически отсутствует.
Antimony 23.10.2012 20:53:34
Я бы добавил еще одну мысль ... если это действительно результат "простого цикла", то он платит высокую цену за эффективность в обмен на то, что обратный инженерный код становится нешифруемым и неясным.
Lawrence Dol 10.01.2017 03:07:45

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

13
2.05.2009 07:32:26
Мне было интересно, вы когда-нибудь запутывали код, который широко использует рефлексию? У вас были проблемы?
Cratylus 13.04.2012 08:06:39
@ user384706: Да, я использую ProGuard с кодом, который широко использует рефлексию. Вы должны настроить его, чтобы сохранить отраженные элементы, за исключением простого использования Class.forName().
Lawrence Dol 13.04.2012 19:12:10

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

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

12
16.05.2009 06:39:12

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

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

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

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

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

25
27.09.2012 15:45:18
Это очень верно. В наши дни существует так много проектов с открытым исходным кодом, что никому нет дела до коммерческого исходного кода других людей. Главное - это точно защитить некоторую (небольшую) конкретную информацию, такую ​​как ЧАСТНЫЕ КЛЮЧИ и ПАРОЛИ.
marcolopes 9.03.2014 17:06:26