Что-то я не вижу никаких ограничений по времени для некоммерческих проектов (http://www.excelsior-usa.com/jetfree.html). А если уж речь идет о коммерческих проектах, Standard версия и Basic суппорт вполне достаточны, по крайней мере для меня, а это в два с небольшим раза дешевле. На наших десктопных SWING приложениях результирующий размер макс. 20MB. И дело не только в том, чтобы не качать JRE. Ну и JET — это сертифицированная Oracle реализация, так что можно не опасаться всяких подводных камней.
Дык, давнно же уже есть Excelsior JET (http://www.excelsior-usa.com/jet.html). Единственное, поддержки Мака нет, а так вон для некоммерческого использования бесплатно можно взять. Но конкуренция — это всегда хорошо, надеюсь в JET поскорее поддержка MacOS X появится.
Метод не является универсальным, т.к., например, zenofx ClassGuard попытки подключения через Agent блокирует. Здесь, на Хабре, я публиковал статью с хорошим методом обхода подобной защиты: Против лома нет приёма: OpenJDK hack vs. Class Encryption
Большое спасибо за комментарии.
И в заключение, хотелось бы еще раз сделать несколько акцентов, по определенным причинам.
Речь идет не о привязке приложения к какой-то платформе (совтферной или хардварной), а о том что любое приложение написанное в соответсвии со стандартом Java не может быть защищено с использованием шифрования классов, вернее классы могут быть зашифрованы, но только толку 0.
И хоть OpenJDK (в котором тоже есть com.sun.* пакеты, как ни странно), хоть Oracle JDK, хоть IBM JDK — это реализации Javа, сертифицированные Sun/Oracle и поэтому обязаны в рамках сертификационных тестов обеспечивать совместимость со стандартом Java.
Так, по поводу custom ClassLoader — без нативной части он легко вскрывается, вот отличная статья на эту тему: blogs.oracle.com/sundararajan/entry/retrieving_class_files_from_a
А для IBM JDK и Websphere — дамп всех класс-файлов, насколько я помню, вообще стандартная опция — все загруженные классы в core*.jar выгружаются, подробности здесь: www.ibm.com/developerworks/java/jdk/diagnosis/
Здесь вы правы, но ключ сначала нужно найти и правильно собрать. Stringer работает как хороший вирус, динамически встраивая части своего кода в разные class-фалы.
Естевственно нужно понимать, что софтверная защита никогда не сможет стать «не взламываемой», но мы сделали все, что бы максимально усложнить эту задачу.
Code Flow обфускация — это одна из довольно опасных вещей, т.к. зачастую эти техники приводят к невозможности оптимизации виртуальной машиной определенного куска кода.
А как вообще дела обстоят с потерей производительности? Все-таки строки приходится расшифровывать в рантайме.
Если не шифровать всё подряд — можно свести потери на нет, а если в цикле складывать миллион строк, то, соответственно, ничего хорошего не получится.
Мы используем AES с максимальным развернутым S-box, и для еще большей оптимизации в качестве входного блока мы используем char, не производя конвертацию в байты туда и обратно.
Все верно. Я писал в этом контексте на StackOverflow: stackoverflow.com/a/10137205/1398289.
Кратко: большая часть логики содержится в строках, в подавляющем большинстве приложений мы не используем секретные алгоритмы, которые нам нужно было бы защищать, т.о. строки — самое уязвимое место.
Цена здесь, как ни странно, не является определяющим фактором, но тем не менее: можно использовать Stringer + ProGuard за 150$ или другой схожий по возможностям продукт, который будет стоить минимум 300$ (Allatori например).
Пофиксят — поменяем алгоритм.
Мы сейчас готовим к публикации отчет о метриках производительности Stringer на нескольких типовых open-source проектах. Опубликуем в нашем блоге — licel.ru/blog
Если шифровать все подряд, то потери производительности неизбежны. Допустим у вас есть цикл с большим (миллионы) количеством итераций или очень интенсивно используемый метод — то потери в производительности порядка 100 раз (причем большая часть времени уходит на вызов функции получения контекста, конечно можно было бы использовать пропроетарное api из sun.reflect — но это немного не true way). А так если в конфигурации задать классы и данные, которые реально стоит защищать не более 10%.
Есть GUI — www.secureteam.net/Java-Decompiler.aspx, github.com/deathmarine/Luyten
А теперь по делу, описанный подход известен довольно давно: blogs.oracle.com/sundararajan/entry/retrieving_class_files_from_a, еще одна статья — www.javaworld.com/javaworld/javaqa/2003-05/01-qa-0509-jcrypt.html
Метод не является универсальным, т.к., например, zenofx ClassGuard попытки подключения через Agent блокирует. Здесь, на Хабре, я публиковал статью с хорошим методом обхода подобной защиты: Против лома нет приёма: OpenJDK hack vs. Class Encryption
И в заключение, хотелось бы еще раз сделать несколько акцентов, по определенным причинам.
Речь идет не о привязке приложения к какой-то платформе (совтферной или хардварной), а о том что любое приложение написанное в соответсвии со стандартом Java не может быть защищено с использованием шифрования классов, вернее классы могут быть зашифрованы, но только толку 0.
И хоть OpenJDK (в котором тоже есть com.sun.* пакеты, как ни странно), хоть Oracle JDK, хоть IBM JDK — это реализации Javа, сертифицированные Sun/Oracle и поэтому обязаны в рамках сертификационных тестов обеспечивать совместимость со стандартом Java.
Так, по поводу custom ClassLoader — без нативной части он легко вскрывается, вот отличная статья на эту тему: blogs.oracle.com/sundararajan/entry/retrieving_class_files_from_a
А для IBM JDK и Websphere — дамп всех класс-файлов, насколько я помню, вообще стандартная опция — все загруженные классы в core*.jar выгружаются, подробности здесь: www.ibm.com/developerworks/java/jdk/diagnosis/
Естевственно нужно понимать, что софтверная защита никогда не сможет стать «не взламываемой», но мы сделали все, что бы максимально усложнить эту задачу.
Отношение Constant Pool к общему размеру class-файла.
Например, аналогичные выкладки от University of Victoria, Canada:
citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.3939&rep=rep1&type=pdf — раздел 2.1
citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.1.2047&rep=rep1&type=pdf — раздел «DEVELOPING A TAILORED SOLUTION FOR JAVA CLASS FILES»
А как вообще дела обстоят с потерей производительности? Все-таки строки приходится расшифровывать в рантайме.
Если не шифровать всё подряд — можно свести потери на нет, а если в цикле складывать миллион строк, то, соответственно, ничего хорошего не получится.
Мы используем AES с максимальным развернутым S-box, и для еще большей оптимизации в качестве входного блока мы используем char, не производя конвертацию в байты туда и обратно.
Кратко: большая часть логики содержится в строках, в подавляющем большинстве приложений мы не используем секретные алгоритмы, которые нам нужно было бы защищать, т.о. строки — самое уязвимое место.
Цена здесь, как ни странно, не является определяющим фактором, но тем не менее: можно использовать Stringer + ProGuard за 150$ или другой схожий по возможностям продукт, который будет стоить минимум 300$ (Allatori например).
Пофиксят — поменяем алгоритм.
Попробуйте сами, Вам понравится!