Обеспечивает ли компиляция Java-кода для исполнения (например, с помощью Launch4Java), что код не может быть реверсирован?

Question

После экспериментов я убедился, что запутывание java-кода небезопасно с точки зрения предотвращения разработки обратного кода. Итак, я перехожу к использованию Launch4J для объединения одного из моих основных jar-файлов в один EXE-файл. Файл jar также содержит основной метод ввода. Собирается ли это снова защитить код реверс-инжиниринга?

Answer 1

Если компьютер может запустить его, человек может его реконструировать.

Answer 2

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

Answer 3

Проще говоря, вы не можете предотвратить обратный инжиниринг своего кода.

• Вы уже сами заметили, какие преимущества в запутывании ( ничего особенного, действительно )
• Разделение / объединение классов ( целенаправленное смешивание и сопоставление различных классов, чтобы нарушить логическую структуру кода ) также не будет таким полезным, особенно когда вам нужно отладить чудовищность.
• Вы также не можете по-настоящему зашифровать / замаскировать байт-код, потому что после того, как байт-код достиг вашего пользовательского ClassLoader, он уже вернулся в полностью читаемый формат. Больше информации здесь .

Даже если вы получите защищенный код, его можно отслеживать.Может быть, на уровне байт-кода, может быть на уровне ASM, это не имеет значения - важно то, что когда кто-то может отслеживать выполняемый код, он также может быть подвергнут обратному проектированию.Некоторые методы занимают больше времени, чем другие, но не бывает случаев, когда это было бы невозможно.

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

Answer 4

Я выполнил реверс-инжиниринг на exe (создан из launch4j) над банкой.
Ниже приведены шаги для проверки источника, если вы пропустили файл jar и у вас есть только exe.

1. предположим, ваше имя exe xyz.exe переименуйте его в xyz.exe.zip
2. Перейдите в RAD / eclipse, создайте проект jave для ex: temp.
3. Перейдите к файлу, выберите «Импорт», откроется окно импорта.
4. Перейдите в раздел «Основные» и выберите «Архивный файл», нажмите «Далее».
5. В окне архива нажмите кнопку обзора и выберите zip (например, xyz.exe.zip)
6. В папке Into выберите целевой путь, здесь я выбрал созданный проект jave и щелкните Finish.
7. Вы можете увидеть все файлы .class в вышеуказанном проекте.
8. В jd-gui вы открываете файл .class, источник которого нужно проверить, вы можете увидеть src.

Answer 5

Если вы переименуете исполняемый файл из .exe в .zip, вы сможете просматривать все .class-файлы и такие вещи, как переименование из .jar в .zip, и с помощью декомпилятора, такого как http://java.decompiler.free.fr, люди будут по-прежнему сможете просматривать ваш исходный код.

Answer 6

Должен. Однако в этом не было бы смысла Java.