Вы запутываете свой коммерческий код Java? [закрытый]
@Bean
public ViewResolver getViewResolver(){
InternalResourceViewResolver resolver = new InternalResourceViewResolver();
resolver.setPrefix("/WEB-INF/jsp/");
resolver.setSuffix(".jsp");
resolver.setViewClass(JstlView.class);
return resolver;
}
также необходимо, и ваши страницы должны быть в / webapp / WEB-INF / jsp /
+
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
</dependency>
<dependency>
<groupId>org.apache.tomcat.embed</groupId>
<artifactId>tomcat-embed-jasper</artifactId>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
</dependency>
6 ответов
Если Вы действительно запутываете, избегаете obfuscators, которые изменяют код путем изменения потока кода и/или добавления блоков исключения и такого, чтобы быть сложно демонтировать его. Для создания кода нечитабельным, обычно достаточно просто изменить все имена методов, полей и классов.
причина избегать изменяющегося потока кода состоит в том, что некоторые из тех изменений лишают возможности JVM эффективно оптимизировать код. В действительности это на самом деле ухудшит производительность Вашего приложения.
Я использую прозащиту для разработки JavaME. Это не только очень очень хорошо в создании меньших файлов банки (Важный для мобильного телефона), но это полезно как более хороший способ сделать определенный для устройства код, не обращаясь к недружелюбным 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/библиотеки, не увеличивая объем заключительных исполняемых файлов класса.
я полагаю, что некоторый коммерческий obfuscators может также объединить файлы класса вместе в определенных случаях. Это полезно потому что, чем больше классов Вы имеете, тем больше размер наверху Вы имеете в zip (банка) файл.
Я предполагаю, что это действительно сводится , для чего Ваш код Java, как это распределяется и кто Ваши клиенты. Мы ничего не запутываем, поскольку мы никогда не находили тот, который был особенно хорош, и он имеет тенденцию быть большей проблемой, чем это стоит. Если кто-то имеет доступ к нашим файлам JAR и имеет знание, чтобы быть в состоянии осуществить сниффинг вокруг внутренней части их, то существуют намного более тревожные вещи, которые они могут сделать, чем срывают наш исходный код.
Я провел некоторое время в этом году, испытывая различный Java obfuscators, и я нашел, что был милями перед остальными: JBCO. Это является, к сожалению, немного громоздким для установки и не имеет никакого GUI, но с точки зрения уровня путаницы это производит, это является непараллельным. Вы пытаетесь подать его простой цикл, и если Ваш декомпилятор не разрушит попытку загрузить его, Вы будете видеть что-то вроде этого:
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 символов.
I think that for the most part obfuscation is pointless: even with full source code it's generally hard enough to figure out what the heck intention was (assuming there are no comments, and no meaningful names for local variables -- which is the case when re-generating sources from byte code). Obfuscation just decorates the cake.
I think developers and especially their managers tend to greatly over-exaggerate risk of someone seeing the source code. While good decompilers can produce nice looking source code, it's not trivial to work with it, and costs associated (not to mention legal risks) are high enough to make this approach seldom useful. I have only decompiled to debug problems with closed-source vendors' products (deadlocks in DB abstraction layer, ugh). Bytecode was actually obfuscated, I think, but we nonetheless found the underlying problem -- it was an actual design problem.