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

Question

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

Вы обфускации? И если да, то почему вы запутываете?

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

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

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

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

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

Answer 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 была Гото? Ну, JVM поддерживает их =)

Answer 5

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

Answer 6

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

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

Answer 7

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

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

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

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

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