Создание Java-программ без обратной разработки

Question

Есть ли способ развернуть Java-программу в формате, который не подлежит обратному проектированию?

Я знаю, как преобразовать мое приложение в исполняемый файл JAR, но я хочу убедиться, что код не может быть переработан, или, по крайней мере, нелегко.

Запутывание исходного кода не считается ... оно усложняет понимание кода, но не скрывает его.

Смежный вопрос: Как заблокировать скомпилированные классы Java для предотвращения декомпиляции?

---

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

Меня беспокоит, есть ли в коде какая-либо информация, касающаяся удаленного доступа. Существует хост, к которому приложение подключается, используя идентификатор пользователя и пароль, предоставленные пользователем. Есть ли способ скрыть адрес хоста от пользователя, если этот адрес находится внутри исходного кода?

Answer 1

Краткий ответ: «Нет, его не существует».

Реверс-инжиниринг - это процесс, который не подразумевает вообще никакого взгляда на код . Это в основном пытается понять основные механизмы, а затем подражать им. Например, именно так JScript появляется в MS labs, копируя поведение JavaScript Netscape, не имея доступа к коду. Копия была настолько идеальной, что даже ошибки были скопированы.

Answer 2

Вы можете скрыть файл JAR с помощью YGuard . Это не запутывает ваш исходный код , но скомпилированные классы, поэтому нет проблем с поддержанием кода позже.

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

Answer 3

Если вы знаете, на какие платформы вы нацелены, получите что-то, что компилирует вашу Java в нативный код, такой как Excelsior JET или GCJ .

Кроме того, вы никогда не сможете скрыть исходный код, поскольку пользователь всегда имеет ваш байт-код и может Jad его.

Answer 4

Вы пишете на языке, в котором самоанализ является частью основного языка. Он генерирует .class файлы, спецификации которых широко известны (что позволяет другим поставщикам создавать реализации чистых помещений для компиляторов и интерпретаторов Java).

Это означает, что существуют общедоступные декомпиляторы. Все, что нужно, - это несколько поисков в Google, и у вас есть код Java, который делает то же самое, что и ваш. Просто без комментариев и некоторых имен переменных (но имена функций остаются прежними). ​​

Действительно, обфускация - это все, что вы можете получить (хотя декомпилированный код уже будет слегка запутан), не переходя на C или какой-либо другой полностью скомпилированный язык.

Answer 5

Не пользуетесь устным переводом? Что вы пытаетесь защитить в любом случае? Если это достаточно ценно, все может быть реконструировано. Вероятность того, что кто-то проявит достаточную заботу, чтобы перепроектировать большинство проектов, минимальна. Запутывание обеспечивает как минимум минимальное препятствие.

Убедитесь, что ваша интеллектуальная собственность (IP) защищена с помощью других механизмов. Особенно для кода безопасности важно, чтобы люди могли проверять реализации, чтобы безопасность была в алгоритме, а не в источнике.

Answer 6

Я испытываю желание спросить, почему ты хочешь сделать это, но я оставлю это в покое ...

Проблема, которую я вижу, заключается в том, что JVM, как и CLR, должна иметь возможность вмешиваться в ваш код, чтобы JIT компилировал и запускал его. Вы можете сделать его более «сложным», но, учитывая, что спецификация для байт-кода довольно хорошо документирована и существует на гораздо более высоком уровне, чем что-то вроде спецификации ассемблера x86, вряд ли вы сможете «спрятать» поток процесса, так как он получил быть там, чтобы программа работала в первую очередь.

Answer 7

Как кто-то сказал выше, обратный инжиниринг всегда может декомпилировать ваш исполняемый файл. Единственный способ защитить ваш исходный код (или алгоритм) - не распространять исполняемый файл.

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

При этом даже ваш клиентский код декомпилируется. Вы ничего не теряете.

Но наверняка это снизит производительность и удобство для пользователя.

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

Answer 8

Это невозможно сделать. Это не проблема Java. Любой язык, который можно скомпилировать, можно декомпилировать для Java, это проще.

Вы пытаетесь показать кому-то фотографию, фактически не показывая ее. Это невозможно. Вы также не можете скрыть свой хост, даже если вы прячетесь на уровне приложения. Кто-то еще может захватить его с помощью Wireshark или любого другого сетевого анализатора.

Answer 9

Превратите это в веб-сервис. Тогда вы единственный, кто может видеть исходный код.

Answer 10

Даже если вы компилируете код на родной машинный язык, существуют всевозможные программы, которые позволяют по существу декомпилировать его на ассемблер и следовать процессу (OlyDbg, IDA Pro).