Во-первых, если вы ориентируетесь «только» на рынок Windows, очень легко предотвратить декомпиляцию «.class to .java»: используйте такой инструмент, как Excelsior Jet, который преобразует .jar в .exe .
Это защита от ошибок: невозможно вернуть файл .java, если вы используете Excelsior Jet (так долго для всех, кто говорит: «Невозможно предотвратить декомпиляцию .class *» 1010 * файл "). Конечно, злоумышленник может запустить SoftIce и попытаться отследить ваш .exe , но это окажется немного сложнее, чем использование JAD для декомпиляции .class в .java и, конечно, он не позволит найти файл .java обратно.
Теперь, может быть, вы тоже ориентируетесь на OS X и Linux, или у вас нет $$$ для оболочки для Excelsior Jet.
Я пишу коммерческое программное обеспечение, написанное на Java. Это программное обеспечение имеет смысл только при наличии подключения к Интернету. Следовательно, мы «защищаем» наше программное обеспечение, в том числе тем, что часть вычислений происходит на стороне сервера: у нас есть несколько .class , которые не будут работать, если они не генерируются на стороне сервера, и мы отправьте их по проводам (и то, что отправляется по проводам, всегда отличается: мы генерируем уникальные одноразовые .class файлы на стороне сервера).
Для этого требуется подключение к Интернету, но если пользователю не нравится, как работает наше программное обеспечение, он может бесплатно купить один из продуктов нашего конкурента;)
Декомпиляция не принесет много пользы: вам нужно активно взломать программное обеспечение (т.е. воспроизвести то, что происходит на стороне сервера), иначе вы не сможете его использовать.
Мы используем нашу собственную "обфускацию строк" , прежде чем мы используем Proguard. Мы также выполняем инструментарий исходного кода (мы могли бы также выполнить инструментарий для байт-кода), где мы удаляем много вещей из кода (например, «утверждение», которое мы комментируем) и вводим некоторую случайную «запутанность потока кода» [программное обеспечение может принять разные пути все же дают один и тот же результат, это то, что действительно затрудняет отслеживание программного обеспечения]).
Затем мы используем Proguard (который бесплатен), чтобы сгладить всю нашу OO-иерархию и запутать уже зашифрованный код code-flow-and-string-obfuscated.
Итак, наш поток:
- Строка запутывания
- обфускация случайного кодового потока
- final .jar , который зависит от .class , которые (по-разному) динамически генерируются на стороне сервера.
В дополнение к этому мы выпускаем очень регулярные (и автоматизированные) обновления, которые всегда позволяют немного изменить нашу схему защиты клиента / сервера (чтобы каждый выпуск гипотетического злоумышленника начинался в основном с нуля).
Конечно, проще бросить полотенце и подумать: "Я ничего не могу сделать, чтобы сделать жизнь злоумышленника тяжелее, потому что JAD все равно может найти файл .java" (что более очень спорно и откровенно плохой в том случае, если вы используете в .class на .exe конвертера, чтобы защитить ваш .class от декомпиляции).