Как легко защитить код Java от обратной инженерии? [Дубликат]

Question

Как легко защитить код Java от обратной инженерии? [Дубликат]

Типы ссылок по умолчанию равны null, чтобы указать, что они не ссылаются на какой-либо объект. Следовательно, если вы попытаетесь получить доступ к объекту, на который ссылаетесь, а его нет, вы получите исключение NullReferenceException.

Для Ex:

SqlConnection connection = null;
connection.Open();

Когда вы запускаете это кода, вы получите:

System.NullReferenceException: Object reference not set to an instance of an object.

Вы можете избежать этой ошибки, например, следующим образом:

if (connection != null){
    connection.Open();
}

Примечание. Чтобы избежать этой ошибки, вы всегда должны инициализировать свои объекты прежде чем пытаться что-либо сделать с ними.

82

reverse-engineering obfuscation

задан Peter Mortensen 27 November 2011 в 11:53

7 ответов

Отказ от ответственности: я не эксперт по безопасности.

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

Возможно, могут работать асимметричные ключи:

развернуть зашифрованную лицензию с открытым ключом для дешифрования

позвольте клиенту создать новую лицензию и отправить ее вам для шифрования

отправить новую лицензию клиенту.

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

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

12

ответ дан Peter Mortensen 23 August 2018 в 22:43
поделиться

1

– jatanp 8 September 2008 в 11:00

2

– Jim Rush 24 June 2010 в 13:04

3

– Radu Murzea 21 February 2012 в 16:34

4

– Antimony 1 April 2013 в 03:11

5

– user207421 29 May 2016 в 00:54

6

– J.Profi 21 July 2017 в 14:58

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

A: Проблема предотвращения декомпиляции байт-кода Java почти как старый язык сам. Несмотря на множество инструментов обфускации, доступных на рынке, новички Java-программистов продолжают думать о новых и умных способах защиты своей интеллектуальной собственности. В этом выпуске Java Q & amp; A я развею некоторые мифы вокруг идеи, часто повторяющейся на дискуссионных форумах.

Крайняя легкость, с которой файлы Java .class могут быть восстановлены в источниках Java, которые очень напоминают оригиналы, имеет много, чтобы сделать с Java байт-кода целей дизайна и компромиссов. Помимо всего прочего, байт-код Java был разработан для компактности, независимости платформы, мобильности сети и простоты анализа с помощью интерпретаторов байтового кода и динамических компиляторов JIT (точно в срок) / HotSpot. Возможно, скомпилированные файлы .class выражают намерение программиста настолько четко, что их легче анализировать, чем исходный исходный код.

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

К сожалению, оба подхода должны фактически изменить код, который запускает JVM, и многие пользователи боятся (по праву), что это преобразование может добавить новое ошибок в их приложениях. Кроме того, метод и переименование полей могут вызвать обратные вызовы, чтобы перестать работать. Изменение имен реальных классов и пакетов может привести к поломке нескольких других Java-API (JNDI (интерфейс именования и интерфейса Java), поставщиков URL-адресов и т. Д.). В дополнение к измененным именам, если связь между смещениями байтового кода класса и номерами исходных строк изменена, восстановление исходных трасс стека исключений может стать затруднительным.

Тогда есть возможность обфускации исходного источника Java код. Но в корне это вызывает аналогичный набор проблем. Шифрование, а не обфускация?

Возможно, вышесказанное заставило вас подумать: «Ну, а что, если вместо манипулирования байтовым кодом я зашифровываю все мои классы после компиляции и расшифровываю их на лету внутри JVM (что может быть сделанный с помощью специального загрузчика классов)? Тогда JVM выполняет мой исходный байт-код, и все же нет ничего, чтобы декомпилировать или реконструировать, не так ли? »

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

0

ответ дан S Harish Morampudi 23 August 2018 в 22:43
поделиться

Вы можете использовать шифрование байтового кода без страха.

Дело в том, что цитируемый выше документ «Cracking Java byte-code encryption» содержит логическую ошибку. Основная претензия к статье перед запуском всех классов должна быть расшифрована и передана методу ClassLoader.defineClass(...) . Но это не так.

Предполагаемое здесь недопустимое значение - при условии, что они работают в аутентичной или стандартной среде java run-time . Ничто не может заставить защищенное Java-приложение не только запускать эти классы, но даже расшифровывать и передавать их на ClassLoader. Другими словами, если вы находитесь в стандартной JRE, вы не можете перехватить метод defineClass(...), потому что стандартная java не имеет API для этой цели, и если вы используете модифицированную JRE с исправленным ClassLoader или любым другим «хакерским трюком», вы можете 't делать это, потому что защищенное приложение Java не будет работать вообще, и поэтому вам нечего перехватывать. И совершенно неважно, какой «патч-искатель» используется или какой трюк используется хакерами. Эти технические детали - совсем другая история.

1

ответ дан ThiefMaster 23 August 2018 в 22:43
поделиться

1

– Antimony 1 April 2013 в 03:14

2

– Ascendant 10 July 2013 в 02:14

3

– Patrick M 29 March 2014 в 08:29

Другие вопросы по тегам:
reverse-engineering obfuscation

Похожие вопросы:

31
Защищать .NET-код от обратного инжиниринга? - 24 February 2013 08:47

23
Инструменты/стратегия путаницы.NET [закрываются] - 13 April 2015 12:51

23
Возможно ли запутать JavaScript-код приложения NodeJS? [Дубликат] - 16 May 2016 12:57

19
Какой язык защитит мой исходный код? - 4 July 2010 15:28

17
Как защитить код Python? - 22 September 2014 13:23

16
Лучший способ запутать адрес электронной почты на веб-сайте? - 21 September 2014 21:11

score 3 · Answer 1

Если вы ищете решение для лицензирования, вы можете проверить API TrueLicense . Он основан на использовании асимметричных клавиш. Однако это не означает, что ваше приложение не может быть взломан. Каждое приложение может быть исправлено с достаточным усилием. Что действительно важно, поскольку Стю ответил , выяснив, насколько необходима сильная защита.

score 11 · Answer 2

Независимо от того, что вы делаете, его можно «декомпилировать». Черт, вы можете просто разобрать его. Или посмотрите на дамп памяти, чтобы найти свои константы. Вы видите, что компьютер должен знать их, поэтому ваш код тоже понадобится.

Что делать с этим?

Попытайтесь не отправлять ключ в виде жестко запрограммированной константы в своем code: Храните его как настройку для каждого пользователя. Заставьте пользователя отвечать за этот ключ.

score 17 · Answer 3

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

score 6 · Answer 4

@jatanp: или еще лучше, они могут декомпилировать, удалить код лицензирования и перекомпилировать. С Java я действительно не думаю, что есть правильное, надежное решение этой проблемы. Даже злой маленький ключ может помешать этому с помощью Java.

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

Итак, я должен спросить, действительно ли вы действительно нуждаетесь в усиленной защите, например, ищете свою заявку? Как выглядит ваша клиентская база? (Корпорации? Или подростковые массы геймеров, где это будет больше проблемой?)

score 12 · Answer 5

Отказ от ответственности: я не эксперт по безопасности.

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

Возможно, могут работать асимметричные ключи:

развернуть зашифрованную лицензию с открытым ключом для дешифрования
позвольте клиенту создать новую лицензию и отправить ее вам для шифрования
отправить новую лицензию клиенту.

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

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

score 0 · Answer 6

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

A: Проблема предотвращения декомпиляции байт-кода Java почти как старый язык сам. Несмотря на множество инструментов обфускации, доступных на рынке, новички Java-программистов продолжают думать о новых и умных способах защиты своей интеллектуальной собственности. В этом выпуске Java Q & amp; A я развею некоторые мифы вокруг идеи, часто повторяющейся на дискуссионных форумах.

Крайняя легкость, с которой файлы Java .class могут быть восстановлены в источниках Java, которые очень напоминают оригиналы, имеет много, чтобы сделать с Java байт-кода целей дизайна и компромиссов. Помимо всего прочего, байт-код Java был разработан для компактности, независимости платформы, мобильности сети и простоты анализа с помощью интерпретаторов байтового кода и динамических компиляторов JIT (точно в срок) / HotSpot. Возможно, скомпилированные файлы .class выражают намерение программиста настолько четко, что их легче анализировать, чем исходный исходный код.

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

К сожалению, оба подхода должны фактически изменить код, который запускает JVM, и многие пользователи боятся (по праву), что это преобразование может добавить новое ошибок в их приложениях. Кроме того, метод и переименование полей могут вызвать обратные вызовы, чтобы перестать работать. Изменение имен реальных классов и пакетов может привести к поломке нескольких других Java-API (JNDI (интерфейс именования и интерфейса Java), поставщиков URL-адресов и т. Д.). В дополнение к измененным именам, если связь между смещениями байтового кода класса и номерами исходных строк изменена, восстановление исходных трасс стека исключений может стать затруднительным.

Тогда есть возможность обфускации исходного источника Java код. Но в корне это вызывает аналогичный набор проблем. Шифрование, а не обфускация?

Возможно, вышесказанное заставило вас подумать: «Ну, а что, если вместо манипулирования байтовым кодом я зашифровываю все мои классы после компиляции и расшифровываю их на лету внутри JVM (что может быть сделанный с помощью специального загрузчика классов)? Тогда JVM выполняет мой исходный байт-код, и все же нет ничего, чтобы декомпилировать или реконструировать, не так ли? »

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

score 1 · Answer 7

Вы можете использовать шифрование байтового кода без страха.

Дело в том, что цитируемый выше документ «Cracking Java byte-code encryption» содержит логическую ошибку. Основная претензия к статье перед запуском всех классов должна быть расшифрована и передана методу ClassLoader.defineClass(...) . Но это не так.

Предполагаемое здесь недопустимое значение - при условии, что они работают в аутентичной или стандартной среде java run-time . Ничто не может заставить защищенное Java-приложение не только запускать эти классы, но даже расшифровывать и передавать их на ClassLoader. Другими словами, если вы находитесь в стандартной JRE, вы не можете перехватить метод defineClass(...), потому что стандартная java не имеет API для этой цели, и если вы используете модифицированную JRE с исправленным ClassLoader или любым другим «хакерским трюком», вы можете 't делать это, потому что защищенное приложение Java не будет работать вообще, и поэтому вам нечего перехватывать. И совершенно неважно, какой «патч-искатель» используется или какой трюк используется хакерами. Эти технические детали - совсем другая история.