Вы запутываете свой коммерческий код Java?
Интересно, кто-нибудь использует коммерческие / бесплатные Java-обфускаторы в своем коммерческом продукте? Я знаю только об одном проекте, который на самом деле имел запутывающий шаг на этапе сборки муравья для релизов.
Вы запутываете? И если да, то почему ты запутываешь?
Это действительно способ защитить код или это просто лучшее чувство для разработчиков / менеджеров?
редактировать: хорошо, я, если быть точным, о моей точке зрения: вы запутываете, чтобы защитить свой IP (ваши алгоритмы, работу, которую вы вложили в свой продукт)? Я не буду запутывать по соображениям безопасности, это не правильно. Так что я говорю только о защите кода ваших приложений от конкурентов.
staffan есть хороший момент:
Причина, по которой следует избегать цепочки потоков кода, заключается в том, что некоторые из этих изменений не позволяют JVM эффективно оптимизировать код. По сути, это фактически ухудшит производительность вашего приложения.
7 ответов
Если вы делаете запутывание, держитесь подальше от обфускаторов, которые изменяют код, изменяя поток кода и / или добавляя блоки исключений и тому подобное, чтобы затруднить его разборку. Чтобы сделать код нечитаемым, обычно достаточно просто поменять все имена методов, полей и классов.
Причина, по которой следует избегать изменения потока кода, заключается в том, что некоторые из этих изменений не позволяют JVM эффективно оптимизировать код. По сути, это фактически ухудшит производительность вашего приложения.
Я думаю, что старый (классический) способ запутывания постепенно теряет свою актуальность. Потому что в большинстве случаев классические обфускаторы ломают трассировку стека (это плохо для поддержки ваших клиентов)
В настоящее время главное - не защищать некоторые алгоритмы, а защищать конфиденциальные данные: логины / пароли / ключи API, код, который отвечает за лицензирование (пиратство все еще здесь, особенно в Западной Европе, России, Азии, IMHO), идентификаторы рекламных аккаунтов и т. Д.,
Интересный факт: у нас есть все эти конфиденциальные данные в строках. На самом деле Strings составляет около 50-80% логики наших приложений. Мне кажется, что будущее обфускации - это "Инструменты шифрования строк".
Но теперь функция "String encryption" доступна только в коммерческих обфускаторах, таких как: Allatori, Zelix KlassMaster, Smokescreen, Stringer Java Obfuscation Toolkit, DashO.
NB Я генеральный директор в Licel LLC. Разработчик Stringer Java Obfuscator.
Я использую 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).
В этом году я провел некоторое время, пробуя различные обфускаторы 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 поддерживает их =)
Я использую ProGuard и очень рекомендую его. Хотя запутывание защищает ваш код от случайных злоумышленников, его основным преимуществом является минимизация эффекта удаления неиспользуемых классов и методов и сокращения всех идентификаторов до 1 или 2 символов.
Я думаю, что по большей части обфускация не имеет смысла: даже с полным исходным кодом, как правило, достаточно сложно выяснить, каково было чертовское намерение (при условии, что нет комментариев и нет значимых имен для локальных переменных - как в случае генерация источников из байт-кода). Запутывание просто украшает торт.
Я думаю, что разработчики и особенно их менеджеры, как правило, сильно преувеличивают риск того, что кто-то увидит исходный код. Хотя хорошие декомпиляторы могут создавать красивый исходный код, работать с ним нетривиально, и связанные с этим затраты (не говоря уже о юридических рисках) достаточно высоки, чтобы сделать этот подход редко полезным. Я декомпилировал только для устранения проблем с продуктами поставщиков с закрытым исходным кодом (взаимоблокировки на уровне абстракции БД, тьфу). Я думаю, что байт-код был на самом деле запутан, но мы, тем не менее, нашли основную проблему - это была настоящая проблема дизайна.
Я предполагаю, что все сводится к тому, для чего нужен ваш Java-код, как он распространяется и кто ваши клиенты. Мы ничего не запутываем, так как никогда не находили такой, который был бы особенно хорош, и это, как правило, доставляет больше хлопот, чем стоит. Если кто-то имеет доступ к нашим JAR-файлам и обладает знаниями, позволяющими обнюхивать их, то есть гораздо более тревожные вещи, которые он может сделать, чем срывать наш исходный код.