Мне достаточно любопытно, чтобы не подумать о вечернем написании определенного кода на Java из-за того, насколько легко его декомпилировать. Есть ли способ, которым я могу писать на Java и не беспокоиться о декомпиляторах? Я понимаю, что все может быть изменено в обратном направлении за достаточно времени, поэтому я спрашиваю: достаточно ли эффективны обфускаторы классов Java для сдерживания декомпиляции?
Действительно ли обфускация кода Java эффективна по сравнению с декомпиляторами?
Ответы (7)
Достаточно ли эффективны обфускаторы классов Java для предотвращения декомпиляции?
Я бы сказал «нет». Когда я декомпилирую исходный код с целью выяснить, как кто-то что-то сделал, я уже знаю, что ищу. Так что мне не нужно понимать всю программу - только один фрагмент, который меня интересует в то время. Если достаточно ломать голову над методами и немного возвращаться в цепочку вызовов, обычно можно определить, что находится под капотом, без чрезмерных усилий.
person
John Feminella
schedule
11.02.2010
Если ваш вопрос: "Могу ли я гарантировать, что никто не сможет взломать мой код", ответ будет НЕТ .. Будь то JAVA или Visual C ++. Пока ваше программное обеспечение, состоящее из байтов или битов, доступно хакеру напрямую.
ПРИЧИНА проста.
Каким бы вы ни кодировали, это можно декодировать.
Лучшей стратегией может быть создание веб-службы и развертывание там вашей секретной логики. Позвольте другим пользоваться вашим сервисом, не имея доступа к тому, как вы писали.
person
PassionatedDeveloper
schedule
11.02.2010
Обфускация в Java и других языках - всего лишь средство устрашения. Это просто поднимает планку для атакующего. Это не означает, что обфускация не имеет значения, это просто не гарантия.
Что вы пытаетесь защитить и на какой рынок вы ориентируетесь?
Обфускация для защиты алгоритма лицензирования на рынке, который полон пиратства, не имеет большого значения. Однако для SMB этого может быть достаточно, чтобы избавиться от большинства случайных пиратов.
Если вы пытаетесь защитить IP от конкуренции, я вижу два ответа. Идею будет сложно защитить. Способный инженер, просматривающий код, поймет жемчужины логики и сможет ее реализовать. Из-за обфускации людям будет намного сложнее просто взять код и включить его в свой собственный продукт. Затраты на обслуживание будут продолжать расти по мере того, как они будут пытаться внести изменения (я бы сказал, что это также верно для чисто декомпилированного кода).
Продукты Java, которые я разрабатываю для своей компании, запутаны. Они защитили нас от воровства ... Сомневаюсь. Но в контексте наших затрат на разработку обфускация была не такой уж и дорогой. Небольшая защита за небольшую цену - неплохой компромисс.
person
Jim Rush
schedule
13.02.2010
Затраты на обфускацию выходят за рамки стоимости самого обфускатора. Обфускация также снижает производительность и переносимость.
- person Antimony; 19.08.2013
@Antimony Я согласен, хотя я никогда не мог измерить падение производительности. Байт-код был действителен, но я вызвал ошибки в компиляторе точки доступа (1.6 JVM), приводящие к сбоям (легко воспроизводятся, в результате чего класс должен быть занесен в белый список для обфускатора). Проблемы совместимости будут больше касаться дефектных JVM, которые не могут обрабатывать действительный байтовый код. Поскольку компиляторы, отличные от Java, постепенно набирают популярность, это должно стать меньшей проблемой.
- person Jim Rush; 19.08.2013
Под переносимостью я также имел в виду использование небезопасных или нестандартных API. Например, запутанное приложение Stringer не будет запускаться как ненадежный апплет из-за использования setAccessible или Google App Engine из-за зависимости от внутренних API-интерфейсов Sun (в любом случае вы не захотите запускать запутанный код в GAE).
- person Antimony; 19.08.2013
Исходя из личного опыта декомпиляции Java, я могу сказать, что обфускация может сделать чьи-то попытки декомпилировать очень раздражающими и трудными. Больше всего меня раздражает, когда все файлы классов окончательной сборки называются «a.class, b.class, c.class» и так далее, и в них добавляется большое количество фиктивных элементов. С точки зрения обфускации кода, попробуйте / catches отлично справляется с проблемой декомпилятора.
В общем, все, что вы декомпилируете, не будет компилироваться, но даст вам подсказки относительно общей работы программы.
person
revenantphoenix
schedule
11.02.2010
Обратите внимание, вы не должны делать никаких обфускаций в вашей отладочной сборке, только в выпускных сборках! Так сложно работать с запутанным кодом.
- person revenantphoenix; 11.02.2010
«Достаточно эффективный» полностью зависит от того, насколько он вам нужен. А это зависит от того, что вы защищаете и от кого. Ни один из традиционных методов (обфускация, шифрование байт-кодов, компиляция в exe) не остановит опытного и целеустремленного злоумышленника с достаточным временем и стимулом. Но это в значительной степени относится ко всем формам программирования. (Вы также можете дизассемблировать или декомпилировать приложения C / C ++ ...)
Единственный способ защитить себя от серьезного реверс-инжиниринга - это использовать безопасную платформу выполнения; например используя что-то, основанное на TPM. Даже в этом случае, если злоумышленники могут подключить логический анализатор к системе, в которой выполняется ваш код, они могут (теоретически) захватить выполняемый собственный код и затем начать обратный инжиниринг.
РЕДАКТИРОВАТЬ. Сообщается, что кому-то удалось взломать популярный чип TPM с помощью электронного микроскопа; см. эту статью регистрации. И что интересно, его изначальной мотивацией было взломать консоли Xbox 360!
person
Stephen C
schedule
11.02.2010
Верно, но, вероятно, будет справедливо сказать, что у большей части целевой аудитории не будет инструментов или средств, чтобы взломать приложение. с защитой на основе TPM ... то есть до тех пор, пока уровень успеха указанного приложения не будет означать, что авторам будет все равно, потому что они уже отказались от заработка.
- person Lawrence Dol; 13.04.2011
@SoftwareMonkey - это правда. Но оборотная сторона - то, что у большинства разработчиков нет средств для использования TPM для защиты своих приложений! Мое упоминание TPM ... во многом гипотетически.
- person Stephen C; 19.08.2013
Откровенно говоря, нет. Как бы нелепо вы ни запутали код, если кто-то знает, что он может заработать на вашем коде миллион долларов, он декомпилирует ваши файлы классов и получит код.
Однако есть альтернативы:
Преобразуйте вашу java-программу в exe-файл для распространения. Вы должны знать, что здесь есть уловы.
Зашифруйте файлы классов с помощью ключа. Создайте собственный загрузчик классов, который может декодировать файлы классов с помощью закрытого ключа перед загрузкой их в память. Здесь есть две проблемы: а) время загрузки увеличивается, б) как вы скроете закрытый ключ.
person
Suraj Chandran
schedule
11.02.2010
Ни один из них не действительно предотвратит декомпиляцию - 1.) Просто означает, что им нужно декомпилировать собственный исполняемый файл в сборку - stackoverflow.com/questions / 2244321 / 2.) Если пользовательский загрузчик классов может расшифровать класс, он может просто получить его из загрузчика классов - stackoverflow.com/questions/1175008/encrypting-war-files/
- person Nate; 18.02.2010
@nate ... проще сказать, потом сделать ... 1) в случае exe, если бы декомпиляция нативного кода в сборку действительно помогла, тогда никакой код на земле не был бы безопасным 2) Нет, если только ваш загрузчик классов знает ключи
- person Suraj Chandran; 18.02.2010
ты хоть ссылки читал? 1.) Никакой код (к которому пользователь имеет прямой доступ) не защищен от обратного проектирования - любой исполняемый файл может быть декомпилирован в сборку - и есть люди, которые могут программировать сборку так же, как и Java. 2.) Шифрование классов бесполезно, независимо от схемы шифрования, потому что для того, чтобы ClassLoader работал в JVM, он должен предоставить JVM класс незашифрованный через метод defineClass () - что делать помешать кому-то просто использовать ваш ClassLoader для расшифровки ваших классов за них, а они сохранят их в незашифрованном виде?
- person Nate; 18.02.2010
@nate ... как я уже сказал ... проще сказать, чем сделать. не читайте отсюда и отсюда ... сделайте это, добейтесь успеха, а затем верьте этому.
- person Suraj Chandran; 18.02.2010
1.) Я видел, как декомпиляторы декомпилируют .exes в ассемблер - я сам недостаточно хорошо знаю ассемблер, чтобы много с ним делать, но я знаю, что люди знают. 2.) В статье по ссылке приводится краткий пример, плюс только из обязательного ClassLoader и спецификации JVM, это не сработает. Я верю в это, и он не добьется успеха (ну, в зависимости от определения успеха - 1.) действительно делает его намного сложнее (но на самом деле просто потому, что больше людей понимают Java, чем ассемблер), что может быть достаточно хорошим, чтобы добиться успеха - однако 2.) имеет недостатки, несмотря ни на что. )
- person Nate; 18.02.2010
если вы прочтете мой пост https://stackoverflow.com/a/26717791/2132826, вы увидите, что я не мог найдите один хороший java де-обфускатор, который действительно работает так, как ожидалось.
так что текущий ответ: НЕТ.
person
Community
schedule
07.11.2014
