Создание программ на Java без обратного проектирования
Есть ли способ развернуть программу Java в формате, который не подлежит обратному проектированию?
Я знаю, как преобразовать свое приложение в исполняемый файл JAR, но я хочу убедиться, что код нельзя реконструировать или, по крайней мере, нелегко.
Обфускация исходного кода не в счет ... это затрудняет понимание кода, но не скрывает его.
Связанный вопрос: Как заблокировать скомпилированные классы Java, чтобы предотвратить декомпиляцию?
После завершения программы у меня все еще будет доступ к первоисточнику, поэтому поддержка приложения не будет проблемой. Если приложение распространяется, я бы не хотел, чтобы кто-либо из пользователей мог его декомпилировать. Обфускация этого не позволяет, поскольку пользователи все равно смогут его декомпилировать, и, хотя им будет трудно следить за потоками действий, они смогут видеть код и потенциально извлекать из него информацию.
Меня беспокоит, есть ли в коде какая-либо информация, касающаяся удаленного доступа. Существует хост, к которому приложение подключается с использованием идентификатора пользователя и пароля, предоставленных пользователем. Есть ли способ скрыть адрес хоста от пользователя, если этот адрес находится внутри исходного кода?
Почему пользователю важно не знать, что служба базы данных работает на IP-адресе, к которому вы подключаетесь?
Ответы 14
Вы можете запутать свой JAR-файл с помощью YGuard. Это не запутывает ваш исходный код, но скомпилированные классы, поэтому нет проблем с поддержанием кода позже.
Если вы хотите скрыть какую-то строку, вы можете зашифровать ее, что затруднит ее получение, просмотрев исходный код (даже лучше, если вы запутаете файл JAR).
Он сказал обфускация исходного кода, я говорю ему обфускировать результирующие классы jar, которые не имеют ничего общего с исходным кодом
Действительно, предположительно допускается двоичная обфускация. Если нет, то его вопрос действительно сводится к следующему: «Как мне запутать свой код? Ps, я не могу использовать обфускатор», и это не имело бы особого смысла. Обфускация двоичных файлов не идеальна, но она настолько хороша, насколько это возможно.
Я думаю, он имел в виду обфускацию сгенерированного байт-кода, но он должен отредактировать, чтобы прояснить. Обфусцированный байт-код все еще может быть реконструирован, но не в красивом формате.
Все можно реконструировать, возможно, он не понимает, что такое обфускация, и думает, что исходный код - это то, что запутывается.
dotFuscator запутывает код .NET IL таким образом, чтобы его нельзя было декомпилировать во что-то, что вы можете использовать, включая переупорядочивание команд и шифрование строк. Вы можете перекомпилировать его, и если вам повезет, вы не сможете его прочитать. Если не повезет, он даже не перекомпилируется. Спорим, есть такая вещь и для Java
Я специально хочу скрыть определенную информацию, содержащуюся в исходном коде. Точный адрес базы данных, к которой я подключаюсь, если быть точным. Меня не волнует, знают ли они, к какому IP-адресу я подключаюсь, а только что на этом IP-адресе.
Вы можете зашифровать строку, но я бы только усложнил ее просмотр, они всегда могли прочитать исходный код для поиска ключа шифрования
именно поэтому я хочу убедиться, что они не могут получить доступ к источнику, чтобы они не могли найти эту информацию.
Информация будет всегда, вы можете только усложнить ее, например, запутать полученный байт-код
Что мешает им использовать другие средства вывода этой информации. Например, мониторинг всего исходящего трафика от машины, устанавливающей соединение.
@David: dotfuscator утверждает, что они действительно улучшают производительность во многих ситуациях.
Я думаю, что соединения с БД проходят через зашифрованный канал, но я не уверен в этом.
Мне хочется спросить, зачем вам это нужно, но я оставлю это в покое ...
Проблема, которую я вижу, заключается в том, что JVM, как и среда CLR, должна иметь возможность интриговать ваш код, чтобы JIT скомпилировать и запустить его. Вы можете сделать его более «сложным», но, учитывая, что спецификация для байт-кода довольно хорошо документирована и существует на гораздо более высоком уровне, чем что-то вроде спецификации ассемблера x86, маловероятно, что вы сможете «скрыть» поток процесса, поскольку он имеет быть там, чтобы программа работала в первую очередь.
Вы пишете на языке, в основе которого лежит интроспекция. Он генерирует файлы .class, спецификации которых широко известны (что позволяет другим поставщикам создавать "чистые" реализации компиляторов и интерпретаторов Java).
Это означает, что есть общедоступные декомпиляторы. Все, что требуется, - это несколько поисковых запросов в Google, и у вас есть код Java, который делает то же самое, что и ваш. Просто без комментариев и некоторых имен переменных (но имена функций остаются прежними).
На самом деле, обфускация - это все, что вы можете получить (хотя декомпилированный код уже будет немного запутан), в любом случае не переходя на C или какой-либо другой полностью скомпилированный язык.
Если вы знаете, на какие платформы вы ориентируетесь, приобретите что-нибудь, что компилирует вашу Java в собственный код, например Эксельсиор Джет или GCJ.
Если не считать этого, вы никогда не сможете скрыть исходный код, поскольку у пользователя всегда есть ваш байт-код и он может Джад.
эффективно. Это похоже на «управление» авторскими правами. Вы хотите предоставить программу, чтобы ваш компьютер мог ее прочитать (и выполнить), но не хотите, чтобы пользователь ее читал (и копировал). Это довольно неестественно.
Компиляция вашей Java в машинный код кажется единственным реалистичным решением, и оно должно быть лучше, чем обфускация.
Это невозможно.
Все, что можно скомпилировать, можно декомпилировать. Лучшее, что вы можете сделать, - это запутать это до чертиков.
При этом в квантовой криптографии происходит кое-что интересное. По сути, любая попытка прочитать сообщение меняет его. Я не знаю, можно ли это применить к исходному коду или нет.
конечно, до тех пор, пока вы не хотите, чтобы ваш процессор мог его читать;)
Что ж, это было бы нарушением безопасности, не так ли.
Короткий ответ: «Нет, этого не существует».
Обратный инжиниринг - это процесс, который вообще не подразумевает просмотра кода.. По сути, он пытается понять лежащие в основе механизмы, а затем имитировать их. Например, так выглядит JScript из лабораторий MS, копируя поведение JavaScript Netscape, не имея доступа к коду. Копия была настолько идеальной, что копировали даже ошибки.
Гизмо, я думаю, тебе стоит либо удалить, либо отредактировать свой комментарий. Любой, кто читает вопрос, понимает, что Эли ищет способ предотвратить легкую декомпиляцию. Вы раскалываете волосы, и это ДЕЙСТВИТЕЛЬНО не ответ. Или вы можете обновить свой комментарий, включив в него правильную фразу. Pls b полезно!
Извините, но я не буду этого делать. Я предпочитаю дать хороший ответ на неправильный вопрос, чем дать неправильный ответ на неправильный вопрос, тем более, что теперь это имеет место с ответом AlbertEin, который совсем не соответствует реальному требованию, а именно: «не позволять кому-либо найти URL-адрес в декомпилированный код ".
Вы можете ответить на вопрос предназначена и добавить комментарий, объясняющий недостатки вопроса буквальный ...
Не пользуетесь интерпретируемым языком? Что вы все равно пытаетесь защитить? Если это достаточно ценно, все можно реконструировать. Шансы на то, что кто-то достаточно заботливый, чтобы перепроектировать большинство проектов, минимальны. Обфускация создает по крайней мере минимальные препятствия.
Убедитесь, что ваш интеллектуальная собственность (IP) защищен другими механизмами. В частности, для кода безопасности важно, чтобы люди могли проверять реализации, чтобы безопасность была в алгоритме, а не в источнике.
Даже если вы скомпилируете код на родном машинном языке, существуют всевозможные программы, которые позволяют вам по существу декомпилировать его на язык ассемблера и следить за процессом (OlyDbg, IDA Pro).
Превратите его в веб-сервис. Тогда вы единственный, кто может видеть исходный код.
Что-либо интерпретируемое в какой-то момент должно обрабатываться «в открытом виде». Строка будет отображаться как день после того, как код будет запущен через JAD. Вы можете развернуть ключ шифрования с вашим приложением или сделать базовый шифр Ceasar, чтобы зашифровать информацию о подключении хоста и расшифровать во время выполнения ...
Но в какой-то момент во время обработки информация о подключении к хосту должна быть открыта, чтобы ваше приложение могло подключиться к хосту ...
Таким образом, вы можете статически скрыть его, но вы не можете скрыть его во время выполнения, если они запускают отладчик
Это невозможно. ЦП должен будет выполнить вашу программу, т.е. ваша программа должна быть в формате, понятном ЦП. Процессоры намного тупее людей. Следовательно, если ЦП может понять вашу программу, то это сможет сделать человек.
Это невозможно. Это не проблема Java. Любой язык, который можно скомпилировать, можно декомпилировать для Java, это проще простого.
Вы пытаетесь показать кому-то картинку, не показывая на самом деле. Это невозможно. Вы также не можете скрыть свой хост, даже если вы скрываетесь на уровне приложения. Кто-то все еще может получить его через Wireshark или любой другой сетевой сниффер.
Имея опасения по поводу сокрытия кода, я бы все равно запустил ProGuard.
Как кто-то сказал выше, обратная инженерия всегда может декомпилировать ваш исполняемый файл. Единственный способ защитить исходный код (или алгоритм) - не распространять исполняемый файл.
разделите ваше приложение на серверный код и клиентское приложение, скройте важную часть вашего алгоритма в коде сервера и запустите его на облачном сервере, просто распределите клиентский код, который работает только как средство получения и центра обработки данных.
При этом декомпилируется даже ваш клиентский код. Вы ничего не теряете.
Но это наверняка снизит производительность и удобство использования.
Я думаю, что это может быть не тот ответ, который вы ищете, а просто поднятие другой идеи защиты исходного кода.
Здесь уже спрашивали: Об этом уже спрашивали здесь: stackoverflow.com/questions/49379/…