Comments 16
Вы получили некоторые class-файлы приложения. Ну и что? Всего приложения у вас нет. Для этого нужно каким-то образом заставить программу загрузить все классы в ней. Иначе восстановленный таким образом набор .class-файлов потом начнет не ожиданно падать когда пользователь сделает что-то необычное.
Серьезные дяди, которым важно шифрование, не пользуються OpenJDK — раз, даже если и пользуются, — любое несимметричное шифрование без приватного ключа не позволит вам расшифровать сп*зженные jar'ки — вы банально не получите байткод для своего дампа.
Если предположить, что у вас лицензионная jar'ка и вы, как любопытный инженер все же решили поиграться — конечно, это возможно, так же как возможно взломать любую программу и любой шифр, если у вас есть приватный ключ. Тут как бы подразумевается, что вам доверили код.
Если речь идет о class encryption вообще, то:
Бессмысленно — нет, с помощью шифрованияи и подписи, можно гарантировать что класс загружен в jvm неизменным, например, по сети
Опасно — не совсем понятно почему
Дорого — да, ну и что?
Если речь идет только об обфускации, чтобы нерадивые клиенты не взламывали святой код — согласен, это все равно, что Майкрософт скажет, что вот вам Виндовс продадим, только не смотрите ассемблерный код нашего ядра, — все равно все будут думать про слона :)
Компиляция в нативный код? А смысл тогда писать код на java? Любви ради и хохмы для?
А вообще статья интересная. Спасибо
Если предположить, что у вас лицензионная jar'ка и вы, как любопытный инженер все же решили поиграться — конечно, это возможно, так же как возможно взломать любую программу и любой шифр, если у вас есть приватный ключ. Тут как бы подразумевается, что вам доверили код.
Если речь идет о class encryption вообще, то:
Бессмысленно — нет, с помощью шифрованияи и подписи, можно гарантировать что класс загружен в jvm неизменным, например, по сети
Опасно — не совсем понятно почему
Дорого — да, ну и что?
Если речь идет только об обфускации, чтобы нерадивые клиенты не взламывали святой код — согласен, это все равно, что Майкрософт скажет, что вот вам Виндовс продадим, только не смотрите ассемблерный код нашего ядра, — все равно все будут думать про слона :)
Компиляция в нативный код? А смысл тогда писать код на java? Любви ради и хохмы для?
А вообще статья интересная. Спасибо
>Серьезные дяди, которым важно шифрование, не пользуються OpenJDK
В статье предлагается использовать OpenJDK для дешифровки класс-файлов, а не для работы систем на продакшине. Ну и, кстати говоря, OpenJDK весьма хорош, а для изучения того как работает виртуальная машина просто клад.
>любое несимметричное шифрование без приватного ключа не позволит вам расшифровать сп*зженные jar'ки — вы банально не получите байткод для своего дампа.
Если программа запускается на вашем компьютере, значит в итоге она где-то расшифровывается, и где-то в ней хранится ключ и алгоритм расшифровки (в бутстраппере обычно). Вы путаете с другим применением несимметричного шифрования — лицензионные ключи и их взлом. Вот в этом случае действительно невозможно написать кейген не зная приватного ключа, если конечно алгоритм хороший и реализован без косяков
В статье предлагается использовать OpenJDK для дешифровки класс-файлов, а не для работы систем на продакшине. Ну и, кстати говоря, OpenJDK весьма хорош, а для изучения того как работает виртуальная машина просто клад.
>любое несимметричное шифрование без приватного ключа не позволит вам расшифровать сп*зженные jar'ки — вы банально не получите байткод для своего дампа.
Если программа запускается на вашем компьютере, значит в итоге она где-то расшифровывается, и где-то в ней хранится ключ и алгоритм расшифровки (в бутстраппере обычно). Вы путаете с другим применением несимметричного шифрования — лицензионные ключи и их взлом. Вот в этом случае действительно невозможно написать кейген не зная приватного ключа, если конечно алгоритм хороший и реализован без косяков
Я не говорю что OpenJDK плох, я имею ввиду, что само использование ее в проекте дает злоумышленнику преимущество в виде доступного кода, который он может модифицировать и провернуть такой хак. Если программа заточена под IBM JDK, то и патч некуда применить, кода то нет, и собрать некак.
А про дешифрование, я это и написал и я с вами согласен, если у вас ЕСТЬ ключ для загрузки класса, то вы его МОЖЕТЕ расшифровать, но само НАЛИЧИЕ ключа подразумевает, что вам ДОВЕРИЛИ код, например вы купили лицензию или подписали драконовские условия. И в таком случае да, ЕСЛИ вы сможете вот так похачить JDK, то вы наконец ПОЛУЧИТЕ код.
Ключ не обязательно должен быть зашит, он может быть в файле, может быть USB-токеном, может быть другой jar'кой, все зависит от реалзации класслоадера.
Просто поразительно, что вы единственный из 9ти решились откомментировать.
А про дешифрование, я это и написал и я с вами согласен, если у вас ЕСТЬ ключ для загрузки класса, то вы его МОЖЕТЕ расшифровать, но само НАЛИЧИЕ ключа подразумевает, что вам ДОВЕРИЛИ код, например вы купили лицензию или подписали драконовские условия. И в таком случае да, ЕСЛИ вы сможете вот так похачить JDK, то вы наконец ПОЛУЧИТЕ код.
Ключ не обязательно должен быть зашит, он может быть в файле, может быть USB-токеном, может быть другой jar'кой, все зависит от реалзации класслоадера.
Просто поразительно, что вы единственный из 9ти решились откомментировать.
> само использование ее в проекте
Автор программы не использовал OpenJDK в своём проекте. Её только злоумышленник и использовал чтоб программу вскрыть. Неужели непонятно?
> Если программа заточена под IBM JDK
Уважаемый, это Java — какая заточка под какие «JDK»? О чём вы вообще?
Затачивать Java код под конкретные JRE вряд-ли получится, но даже если бы это было возможно — это глупо. Даже буде такая «заточка» появится, имея OpenJDK можно будет внести необходимые модификации, чтоб имитировать нужное JRE.
Но таких заточек нет, и никто этого не делает — какой смысл в кроссплатформенном Java приложении если оно «работает только на JRE версия такая-то под win AMD 64» например? Никакого (-:
И примеров таких «заточек» среди серь
— 0 штук.
> если у вас ЕСТЬ ключ для загрузки класса
Автор программы не использовал OpenJDK в своём проекте. Её только злоумышленник и использовал чтоб программу вскрыть. Неужели непонятно?
> Если программа заточена под IBM JDK
Уважаемый, это Java — какая заточка под какие «JDK»? О чём вы вообще?
Затачивать Java код под конкретные JRE вряд-ли получится, но даже если бы это было возможно — это глупо. Даже буде такая «заточка» появится, имея OpenJDK можно будет внести необходимые модификации, чтоб имитировать нужное JRE.
Но таких заточек нет, и никто этого не делает — какой смысл в кроссплатформенном Java приложении если оно «работает только на JRE версия такая-то под win AMD 64» например? Никакого (-:
И примеров таких «заточек» среди серь
— 0 штук.
> если у вас ЕСТЬ ключ для загрузки класса
Пардон — комментарий оборвался на полуслове.
> И примеров таких «заточек» среди серь
среди серьёзных приложений — 0 штук.
Да и среди несерьёзных пожалуй тоже.
> если у вас ЕСТЬ ключ для загрузки класса
Если программа работает, значит классы загружаются — самой программой. Злоумышленнику ничего не нужно иметь, никаких ключей.
> вам ДОВЕРИЛИ код, например вы купили лицензию или подписали драконовские условия
«Доверили» код? Какой такой код? Байткод чтоли? Логично, что для того, чтоб декомпилировать байткод, его нужно иметь (-:
Но ведь уважаемый — статья то _о целесообразности применения обфускаторов байткода_. Не о USB ключах (автор их какраз скорее рекомендует кстати) и т.п., а именно об обфускаторах. А зачем обфускаторы байткода? Именно затем, чтоб не боятся этот байткод потом раздавать. Ни о каком «доверии» речь не идёт.
> Просто поразительно, что вы единственный из 9ти решились откомментировать
Да как-то сложно комментировать такую бессмыслицу. И, боюсь, бесполезно. Уж извините.
> И примеров таких «заточек» среди серь
среди серьёзных приложений — 0 штук.
Да и среди несерьёзных пожалуй тоже.
> если у вас ЕСТЬ ключ для загрузки класса
Если программа работает, значит классы загружаются — самой программой. Злоумышленнику ничего не нужно иметь, никаких ключей.
> вам ДОВЕРИЛИ код, например вы купили лицензию или подписали драконовские условия
«Доверили» код? Какой такой код? Байткод чтоли? Логично, что для того, чтоб декомпилировать байткод, его нужно иметь (-:
Но ведь уважаемый — статья то _о целесообразности применения обфускаторов байткода_. Не о USB ключах (автор их какраз скорее рекомендует кстати) и т.п., а именно об обфускаторах. А зачем обфускаторы байткода? Именно затем, чтоб не боятся этот байткод потом раздавать. Ни о каком «доверии» речь не идёт.
> Просто поразительно, что вы единственный из 9ти решились откомментировать
Да как-то сложно комментировать такую бессмыслицу. И, боюсь, бесполезно. Уж извините.
Мне вообще все понятно, и не нужно лишней кислоты в комментарии, мой аргумент вполне резонный — что категоричное заявляние, что класс енкрипшен «бесполезен, опасен и дорог», не выдерживает критики.
То есть для вас не существет пакетов com.sun и проч, вы не знаете что такое IBM WebSphere, Azul и не понимаете, что привязать приложение вендор сможет, если захочет. Вы также не понимаете как работает шифрование, например, по алгоритму RSA?
А имея OpenJDK, можно так просто взять и сделать из нее IBM JDK? А насколько это «бесполезно, опасно и дорого» в сравнении с использованием class encryption?
Статья о применении класс енкрипшен как средства обфускации, это вы верно заметили. Но видно ваше понимание распространения jar'ок ограничивается скачиванием из интернета, а загрузка классов возможна только с диска. Что ж, тогда спорить с вами действительно не о чем.
В частности я утверждаю, что при кастомном класслоадере, привязке продукта к проприетарной JDK, например IBM, и шифровании приватным ключом, такой фокус не пройдет, либо будет непередаваемо бесполезен, опасен и дорог по затратам.
Конечно, если вы хотите спрятать суперсекретную библиотеку рисования календаря для Swing — это перебор, и там обфускация — действительно слабенькая защита, но если задача того потребует, вполне можно сделать обфускацию, которую взломать будет достаточно дорого, чтобы отбить желание этим заниматся.
То есть для вас не существет пакетов com.sun и проч, вы не знаете что такое IBM WebSphere, Azul и не понимаете, что привязать приложение вендор сможет, если захочет. Вы также не понимаете как работает шифрование, например, по алгоритму RSA?
А имея OpenJDK, можно так просто взять и сделать из нее IBM JDK? А насколько это «бесполезно, опасно и дорого» в сравнении с использованием class encryption?
Статья о применении класс енкрипшен как средства обфускации, это вы верно заметили. Но видно ваше понимание распространения jar'ок ограничивается скачиванием из интернета, а загрузка классов возможна только с диска. Что ж, тогда спорить с вами действительно не о чем.
В частности я утверждаю, что при кастомном класслоадере, привязке продукта к проприетарной JDK, например IBM, и шифровании приватным ключом, такой фокус не пройдет, либо будет непередаваемо бесполезен, опасен и дорог по затратам.
Конечно, если вы хотите спрятать суперсекретную библиотеку рисования календаря для Swing — это перебор, и там обфускация — действительно слабенькая защита, но если задача того потребует, вполне можно сделать обфускацию, которую взломать будет достаточно дорого, чтобы отбить желание этим заниматся.
«для вас не существет пакетов com.sun и проч, вы не знаете что такое IBM WebSphere, Azul и не понимаете, что привязать приложение вендор сможет, если захочет»
Уважаемый, у вас есть хотя-бы один пример такой привязки? Хотя-бы один?
И вообще говоря да, мне интересно как именно вы привязали бы своё приложение к IBM JVM например (и да — WebSphere тут причём? Неужели не стартует на других JVM кроме IBM-овской? Ой не верю (-: ).
«не понимаете как работает шифрование, например, по алгоритму RSA»
Просветите меня, как связано «шифрование, например, по алгоритму RSA» и (де)обфусцирование байткода?
«А имея OpenJDK, можно так просто взять и сделать из нее IBM JDK?»
Это зависит от того, как именно вы «привязывались к IBM JVM». Не думаю что «найти и обезвредить» такую привязку — даже если она вдруг существует, о чём см. выше — будет так уж сложно.
«ваше понимание распространения jar'ок ограничивается скачиванием из интернета, а загрузка классов возможна только с диска»
Да нет, пусть классы грузятся, например, из базы, в которой они хранятся в зашифрованном виде. Что с того? Автор статьи о том и пишет, что при загрузке они будут услужливо расшифрованы класслоадером — ведь JVM «зашифрованный» байткод не запустит.
«я утверждаю, что при кастомном класслоадере, привязке продукта к проприетарной JDK, например IBM, и шифровании приватным ключом, такой фокус не пройдет»
Про привязку см. первый пункт. А без привязки см. пункт выше.
«если задача того потребует, вполне можно сделать обфускацию, которую взломать будет достаточно дорого»
Если уже привязываться к конкретной JVM, можно и саму JVM модифицировать — хрен редьки не слаще. Но к обфускации байткода это уже никоим образом не относится.
Как, вообще говоря и собственно мифическая привязка к JVM — обфускаторы её не делают.
(Хотя её вообще никто не делает (-: )
Уважаемый, у вас есть хотя-бы один пример такой привязки? Хотя-бы один?
И вообще говоря да, мне интересно как именно вы привязали бы своё приложение к IBM JVM например (и да — WebSphere тут причём? Неужели не стартует на других JVM кроме IBM-овской? Ой не верю (-: ).
«не понимаете как работает шифрование, например, по алгоритму RSA»
Просветите меня, как связано «шифрование, например, по алгоритму RSA» и (де)обфусцирование байткода?
«А имея OpenJDK, можно так просто взять и сделать из нее IBM JDK?»
Это зависит от того, как именно вы «привязывались к IBM JVM». Не думаю что «найти и обезвредить» такую привязку — даже если она вдруг существует, о чём см. выше — будет так уж сложно.
«ваше понимание распространения jar'ок ограничивается скачиванием из интернета, а загрузка классов возможна только с диска»
Да нет, пусть классы грузятся, например, из базы, в которой они хранятся в зашифрованном виде. Что с того? Автор статьи о том и пишет, что при загрузке они будут услужливо расшифрованы класслоадером — ведь JVM «зашифрованный» байткод не запустит.
«я утверждаю, что при кастомном класслоадере, привязке продукта к проприетарной JDK, например IBM, и шифровании приватным ключом, такой фокус не пройдет»
Про привязку см. первый пункт. А без привязки см. пункт выше.
«если задача того потребует, вполне можно сделать обфускацию, которую взломать будет достаточно дорого»
Если уже привязываться к конкретной JVM, можно и саму JVM модифицировать — хрен редьки не слаще. Но к обфускации байткода это уже никоим образом не относится.
Как, вообще говоря и собственно мифическая привязка к JVM — обфускаторы её не делают.
(Хотя её вообще никто не делает (-: )
> Я не говорю что OpenJDK плох, я имею ввиду, что само использование ее в проекте дает злоумышленнику преимущество в виде доступного кода
В статье имеется ввиду другой кейс: кто-то написал программу с защитой от декомпиляции под Oracle JDK (хотя с большой вероятностью она запустится и на Open JDK). А мы взяли и запустили ее под модифицированной Open JDK и получили дешифрованные классы.
> у вас ЕСТЬ ключ для загрузки класса, то вы его МОЖЕТЕ расшифровать, но само НАЛИЧИЕ ключа подразумевает, что вам ДОВЕРИЛИ код
Тут опять путаница. Вы хотели, наверное, написать «Доверили запуск программы», а не код? В этом случае как раз и работает предложенный вариант
В статье имеется ввиду другой кейс: кто-то написал программу с защитой от декомпиляции под Oracle JDK (хотя с большой вероятностью она запустится и на Open JDK). А мы взяли и запустили ее под модифицированной Open JDK и получили дешифрованные классы.
> у вас ЕСТЬ ключ для загрузки класса, то вы его МОЖЕТЕ расшифровать, но само НАЛИЧИЕ ключа подразумевает, что вам ДОВЕРИЛИ код
Тут опять путаница. Вы хотели, наверное, написать «Доверили запуск программы», а не код? В этом случае как раз и работает предложенный вариант
Большое спасибо за комментарии.
И в заключение, хотелось бы еще раз сделать несколько акцентов, по определенным причинам.
Речь идет не о привязке приложения к какой-то платформе (совтферной или хардварной), а о том что любое приложение написанное в соответсвии со стандартом Java не может быть защищено с использованием шифрования классов, вернее классы могут быть зашифрованы, но только толку 0.
И хоть OpenJDK (в котором тоже есть com.sun.* пакеты, как ни странно), хоть Oracle JDK, хоть IBM JDK — это реализации Javа, сертифицированные Sun/Oracle и поэтому обязаны в рамках сертификационных тестов обеспечивать совместимость со стандартом Java.
Так, по поводу custom ClassLoader — без нативной части он легко вскрывается, вот отличная статья на эту тему: blogs.oracle.com/sundararajan/entry/retrieving_class_files_from_a
А для IBM JDK и Websphere — дамп всех класс-файлов, насколько я помню, вообще стандартная опция — все загруженные классы в core*.jar выгружаются, подробности здесь: www.ibm.com/developerworks/java/jdk/diagnosis/
И в заключение, хотелось бы еще раз сделать несколько акцентов, по определенным причинам.
Речь идет не о привязке приложения к какой-то платформе (совтферной или хардварной), а о том что любое приложение написанное в соответсвии со стандартом Java не может быть защищено с использованием шифрования классов, вернее классы могут быть зашифрованы, но только толку 0.
И хоть OpenJDK (в котором тоже есть com.sun.* пакеты, как ни странно), хоть Oracle JDK, хоть IBM JDK — это реализации Javа, сертифицированные Sun/Oracle и поэтому обязаны в рамках сертификационных тестов обеспечивать совместимость со стандартом Java.
Так, по поводу custom ClassLoader — без нативной части он легко вскрывается, вот отличная статья на эту тему: blogs.oracle.com/sundararajan/entry/retrieving_class_files_from_a
А для IBM JDK и Websphere — дамп всех класс-файлов, насколько я помню, вообще стандартная опция — все загруженные классы в core*.jar выгружаются, подробности здесь: www.ibm.com/developerworks/java/jdk/diagnosis/
Sign up to leave a comment.
Против лома нет приёма: OpenJDK hack vs. Class Encryption