О декомпиляции, клонировании, Dephi и Java

← →
P (2007-06-23 20:02) [40]

>
> IMHO © (23.06.07 11:11)
> А как обстоят подобные делаю с Джавой? Что получаем на выходе?
> JAR-файл, в который можно залезть и изменить его.
>
> Слышал про какие-то обфускаторы... Насколько они действенны?

например просто понять такой код:
jksdjkds754 += rer43438943 -(dfjdfl5 + rrrttr474)/rthewrjwk493;
for(trjrtjk3443 = 10; trjrtjk3443 < 34; trjrtjk3443++){};

Ну и тому подобное. Имеем полное запутывание имен переменных.

← →
Anatoly Podgoretsky © (2007-06-23 20:47) [41]

> P (23.06.2007 20:02:40) [40]

> for(trjrtjk3443 = 10; trjrtjk3443 < 34; trjrtjk3443++){};

Чего сложного

for(i = 10; i < 34; i++){};

← →
iZEN © (2007-06-23 20:53) [42]

> IMHO © (23.06.07 14:02) [34]
>
> Делая EXE-бинарник, я могу быть относительно спокоен в этом,
> но делая JAR - где гарантия???

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

Один из известных свободный обфускаторов для Java-кода — ProGuard: http://proguard.sourceforge.net/

← →
P (2007-06-23 22:01) [43]

> Anatoly Podgoretsky © (23.06.07 20:47) [41]
>
> > P (23.06.2007 20:02:40) [40]
>
> > for(trjrtjk3443 = 10; trjrtjk3443 < 34; trjrtjk3443++){};
>
> Чего сложного
>
> for(i = 10; i < 34; i++){};

Только данный код проще написать самому чем разгребать подобное.

← →
Panel (2007-06-24 00:41) [44]

Только данный код проще написать самому чем разгребать подобное.

Средства рефакторинга в руки... и не надо ничего разгребать.

← →
Иа (2007-06-24 06:45) [45]

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

← →
iZEN © (2007-06-24 07:42) [46]

> Иа (24.06.07 06:45) [45]

Э...
Не надо переносить понимание проблем .Net на Яву.
Там несколько всё по-другому.

← →
Иа (2007-06-24 10:42) [47]

> iZEN © (24.06.07 07:42) [46]
>
> > Иа (24.06.07 06:45) [45]
>
> Э...
> Не надо переносить понимание проблем .Net на Яву.
> Там несколько всё по-другому.

Во-первых, я не считаю это проблемой. Во-вторых, не могли бы вы озвучить отличие Java VM от .NET CLR в возможностях и механизмах обфускации кода?

← →
iZEN © (2007-06-24 22:16) [48]

> Иа (24.06.07 10:42) [47]
>
> Во-первых, я не считаю это проблемой. Во-вторых, не могли
> бы вы озвучить отличие Java VM от .NET CLR в возможностях
> и механизмах обфускации кода?

В Java исполняемой единицей является .class-файл. В .Net исполняемой единицей является сборка. Сборка .Net содержит несколько типов и код исполнения, но из неё не удастся выделить отдельные типы (классы) и сохранить их в отдельных файлах для последующей обработки обфускатором и построения из них новой сборки.

В .class-файле Java:
имена переменных и методов хранятся в том виде, каком их определил программист (подмножество ASCII, допустимы имена членов на национальном языке, коды символов которого имеют отображение в ASCII-набор);
значения строковых типов хранятся в Unicode (UTF-8, UCS-2 и UCS-4 в Java 5.0);
class-файл имеет CRC-последовательность, подтверждающую корректность байткода файла.
Всё это и ещё куча вещей должны учитываться обфускатором. И это гораздо легче, чем работать с бинарной сборкой .Net.

Кроме того, Java VM каждый раз производит верификацию байткода загружаемого .class-файла. А .Net CLR верификацию делает(делает ли?) один раз при первоначальном запуске сборки и генерирует из неё бинарный нативный код, который кэширует GAC для будущего использования CLR.

← →
Иа (2007-06-25 02:21) [49]

> Сборка .Net содержит
> несколько типов и код исполнения, но из неё не удастся выделить
> отдельные типы (классы) и сохранить их в отдельных файлах
> для последующей обработки обфускатором и построения из них
> новой сборки.

Неверно

> В .class-файле Java:

То же самое, за исключением локальных переменных.

> Всё это и ещё куча вещей должны учитываться обфускатором.
> И это гораздо легче, чем работать с бинарной сборкой .Net.

Не вижу как одно вытекает из другого

>А .Net CLR верификацию делает(делает ли?)

Задавая такой вопрос вы демонстрируете свое незнание в вопросе, который взялись осветить.

>один раз при первоначальном запуске сборки

Неверно.

>и генерирует
> из неё бинарный нативный код, который кэширует GAC для будущего
> использования CLR.

Неверно.

← →
iZEN © (2007-06-25 03:07) [50]

> Иа (25.06.07 02:21) [49]

Отвечая на ваш вопрос, основывался на выкладках, почерпнутых из книжки Пол Гиббонз "Платформа .NET для Java-программистов". Допускаю, что с тех пор многое в .Net переменилось -- не изучал вопрос досконально и не претендую на знание последней версии .Net CLR.

← →
iZEN © (2007-06-25 03:25) [51]

> IMHO © (23.06.07 11:11)
>
> JAR-файл, в который можно залезть и изменить его.

class-файлы можно защитить от реинжиниринга кода обфускацией. Ресурсы (текст, картинки, аудио, видео) невозможно проверить на достоверность кроме как использованием подписанного JAR-файла цифровой подписью со сверкой MD-5 и SHA-1 контрольных сумм файлов архива на этапе запуска приложения.

← →
Иа (2007-06-25 03:49) [52]

> как использованием подписанного JAR-файла цифровой подписью

Что изменится если я уберу цифровую подпись с чужого файла и подпишу его заново моим ключом? Предполагая, что в коде приложения нет специальной проверки на публичный ключ автора?

← →
Иа (2007-06-25 03:54) [53]

> > Иа (25.06.07 02:21) [49]
>
> Отвечая на ваш вопрос, основывался на выкладках, почерпнутых
> из книжки Пол Гиббонз "Платформа .NET для Java-программистов".
> Допускаю, что с тех пор многое в .Net переменилось -- не
> изучал вопрос досконально и не претендую на знание последней
> версии .Net CLR.

В нет пунктах которые вы затронули выше принципиальных изменений с 1.0- 2.0 не произошло. Предполагаю, что вы могли запутаться в терминологии или запоминили не то. К примеру, компиляцию в native и кэширование в GAC как вы описывали можно устроить с помощью ngen, при обычной работе такого не происходит. Читать по CLR можно и нужно Рихтера.

← →
Игорь Шевченко © (2007-06-25 12:30) [54]

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

← →
Anatoly Podgoretsky © (2007-06-25 13:08) [55]

> Игорь Шевченко (25.06.2007 12:30:54) [54]

Ну можно же заплатить взломщику.

← →
db2admin © (2007-06-25 14:11) [56]

Anatoly Podgoretsky © (25.06.07 13:08) [55]
ради спортивного интереса

← →
Anatoly Podgoretsky © (2007-06-25 14:39) [57]

Ради того, что бы проявили интерес хотя бы за деньги.

← →
iZEN © (2007-06-25 21:41) [58]

> Иа (25.06.07 03:49) [52]
>
>
> > как использованием подписанного JAR-файла цифровой подписью
>
>
> Что изменится если я уберу цифровую подпись с чужого файла
> и подпишу его заново моим ключом? Предполагая, что в коде
> приложения нет специальной проверки на публичный ключ автора?
>

Ничего, если ваш сертификат будет находится в хранилище сертификатов пользователя в списке доверенных.

← →
Petr V.Abramov (2007-06-26 00:47) [59]

> Ничего, если ваш сертификат будет находится в хранилище сертификатов пользователя в списке доверенных.
а сколько надо заплатить пользователю, чтоб он послушал такие слова?

← →
Иа (2007-06-26 02:42) [60]

> Ничего, если ваш сертификат будет находится в хранилище
> сертификатов пользователя в списке доверенных.

Мой или родительский? Если мой, то каким образом происходит добавление моего сертификата легально - во время инсталляции? И как тогда делать xcopy deployment? Что произойдет если ресурс подписан самодельным сертификатом? А если файл с кодом?

← →
iZEN © (2007-06-26 09:17) [61]

Вообще же, общие принципы описаны здесь:
http://khpi-iip.mipk.kharkiv.edu/library/extent/prog/jar/TOC.html

Более наглядно:
http://www.rudometov.com/security/03_01_26_Java_Crypto/Java_Crypto.html

> Иа (26.06.07 02:42) [60]
> > Ничего, если ваш сертификат будет находится в хранилище
> > сертификатов пользователя в списке доверенных.
> Мой или родительский?
Ваш.

> Если мой, то каким образом происходит
> добавление моего сертификата легально - во время инсталляции?
Ну да.
Панель управления -> Java -> вкладка Security -> диалог Certificates -> добавляете сертификат производителя подписанного продукта в одну из категорий.

> И как тогда делать xcopy deployment?

Использовать утилиты jarsigner, keytool и средство автоматизации типа Ant или скриптов командного процессора операционной системы.

http://www.javaportal.ru/java/articles/jar.html

> Что произойдет если
> ресурс подписан самодельным сертификатом? А если файл с
> кодом?

Выброс java.security.DigestException или java.security.SignatureException -- в зависимости от ситуации. В общем случае -- потомок java.security.GeneralSecurityException.

Подробнее: http://java.sun.com/javase/reference/api.jsp

← →
Иа (2007-06-26 09:59) [62]

> Вообще же, общие принципы описаны здесь:
> http://khpi-iip.mipk.kharkiv.edu/library/extent/prog/jar/TOC.
> html

"А в версии 1.2 платформы Java подписанные приложения, вызываемые с опцией интерпретатора -jar, будут проверяться средой выполнения. "

? То есть если я не вызову с ключем, то не проверится? 8()

Более наглядно:
http://www.rudometov.com/security/03_01_26_Java_Crypto/Java_Crypto.html

А тут вообще про криптографию в принципе. Мне не надо объяснять как public/private ключи работают и что такое x509 сертификаты. Я, э, это знаю :) Меня интересует как цифровая подпись используется java vm, в сравнении с .NET. Первая ссылка с цитаой выше меня просто потрясла. Это афтар курил чего-то?

> > И как тогда делать xcopy deployment?
>
> Использовать утилиты jarsigner, keytool и средство автоматизации
> типа Ant или скриптов командного процессора операционной
> системы.

Ничего из вышеперечисленного к моему вопросу отношения не имеет.
Собственно, вы уверены что вы не java аплеты только имеете ввиду обобщая их на все java приложения? Потому как аплеты, так же как и .NET thin controls в IE живут своей особой жизнью.

← →
Тульский © (2007-06-26 10:24) [63]

Можно воспользоваться компилятором Excelsior Jet и получить exe-шник.

← →
iZEN © (2007-06-26 10:55) [64]

> Иа (26.06.07 09:59) [62]
>
> "А в версии 1.2 платформы Java подписанные приложения, вызываемые
> с опцией интерпретатора -jar, будут проверяться средой выполнения.
> "
> ? То есть если я не вызову с ключем, то не проверится? 8()

У вас что-то с логикой?
Опция "-jar" нужна для запуска jar-файла на выполнение ВООБЩЕ.

> Иа (26.06.07 09:59) [62]
>
>
> Более наглядно:
> http://www.rudometov.com/security/03_01_26_Java_Crypto/Java_Crypto.
> html
>
>
> А тут вообще про криптографию в принципе. Мне не надо объяснять
> как public/private ключи работают и что такое x509 сертификаты.
> Я, э, это знаю :) Меня интересует как цифровая подпись
> используется java vm, в сравнении с .NET. Первая ссылка
> с цитаой выше меня просто потрясла. Это афтар курил чего-
> то?

Там картинки. Всё ясно.

А причём здесь сравнение с .NET?

> Иа (26.06.07 09:59) [62]
>
> > > И как тогда делать xcopy deployment?
> >
> > Использовать утилиты jarsigner, keytool и средство автоматизации
> > типа Ant или скриптов командного процессора операционной
> > системы.
>
> Ничего из вышеперечисленного к моему вопросу отношения не
> имеет.

К какому вопросу?

> Иа (26.06.07 09:59) [62]
> Собственно, вы уверены что вы не java аплеты только имеете
> ввиду обобщая их на все java приложения? Потому как аплеты,
> так же как и .NET thin controls в IE живут своей особой
> жизнью.

В Java одна и та же система безопасности для апплетов и приложений. Правда, модели безопасности Java v.1.1.x и Java v.2 отличаются.

http://www.rudometov.com/security/03_01_26_Java_Crypto/Java_Crypto.html
Рисунки:
Рис. 3. Последовательность действий при подписи jar-архива.
и
Рис. 4. Последовательность действий при верификации полученного jar-архива.
Достаточно наглядны.

> буду рад, если вы укажите на узкие места, о которых я не
> знаю.

Элементарно.
После дешифровки дешифрованная информация должна появиться где-нибудь в памяти в открытом виде.

> После дешифровки дешифрованная информация должна появиться
> где-нибудь в памяти в открытом виде

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

← →
Иа (2007-06-26 16:37) [68]

> > Иа (26.06.07 09:59) [62]
> >
> > "А в версии 1.2 платформы Java подписанные приложения,
> вызываемые
> > с опцией интерпретатора -jar, будут проверяться средой
> выполнения.
> > "
> > ? То есть если я не вызову с ключем, то не проверится?
> 8()
>
> У вас что-то с логикой?
> Опция "-jar" нужна для запуска jar-файла на выполнение ВООБЩЕ.
>

В той же ссылке рассказывается о JavaRunner классе. На мой взгляд никакой опции -jar там не видно. Будет ли выполнятся проверка при таком варианте запуска?

> Там картинки. Всё ясно.
>
> А причём здесь сравнение с .NET?

Вы говорили выше о то что в Java "немного не так". Вот я и пытаюсь выяснить, что именно. Кстати, вы говорили о .class как минимальной единице. Но подписать .class нельзя. Я правильно понимаю, что ограничить права для кода выполняемого не из .jar нельзя?

> > Иа (26.06.07 09:59) [62]
> >
> > > > И как тогда делать xcopy deployment?

> К какому вопросу?

Теперь видите? Из ваших слов следовало что если моего сертификата нет в списке, код не запустится. Я пытаюсь выяснить у вас как тогда его распространять.

Иа (26.06.07 16:37) [68], такое ощущение, что я зря ссылки выкладывал.

Там же всё написано!

> Делая EXE-бинарник, я могу быть относительно спокоен в этом,
> но делая JAR - где гарантия???

Думаю, что даже делая EXE-бинарник быть спокойным нельзя, гарантии не даст никто. Можно немного усложнить процесс, но думаю, что лучшим средством защиты будет соответствующее лицензионное соглашение :)

> IMHO © (23.06.07 11:11)
> вы не сильно беспокоитесь о том, что кто-то декомпилирует вашу программу

Флаг ему в руки! Несколько миллионов строк asm-кода...

> oldman (26.06.2007 19:08:11) [71]

Из которых менее процента своего кода.

← →
Иа (2007-06-27 02:24) [73]

> Иа (26.06.07 16:37) [68], такое ощущение, что я зря ссылки
> выкладывал.
>
> Там же всё написано!

Пока все что я понял о "security" в Java это

1) При запуске jar файла через networkloader и иже с ними никакой проверки не происходит
2) Никакой проверки на наличие сертификата в разрешенных не происходит если это не апплет. То есть по умолчанию.
3) Что бы распространить полиси с апплетов на запускаемое приложение надо сделать это ручками java -Djava.security.manager MyLoader
4) До 1.2 все было ГОРАЗДО хуже.

Вывод: правила безопасности на основе цифровой подписи в java по прочности в подметки не годятся .NET security policy.
Собственно, это меня и интересовало. Спасибо.

Возможность декомпиляция это очень большая проблема для таких программ.
В частности для .net есть утилита Lutz Roeder"s .NET Reflector которая для любой сборки генерирует очень даже неплохой код на любом из языков (c#, vb, delphi, c++). Для исследования стандартных классов это полезно, но ...

MS насколько помнится обещала принять меры, только что они хотели предпринять я уже не помню..

> Иа (27.06.07 02:24) [73]
> Пока все что я понял о "security" в Java это
>
> 1) При запуске jar файла через networkloader и иже с ними
> никакой проверки не происходит

Тем не менее, все class-файлы (кроме системных классов из пакетов java*), которые участвуют в загрузке, проходят верификацию. Процесс выполнения их кода контролируется диспетчером безопасности (java.lang.SecurityManager, java.security.AccessController) и регулируется текущей политикой безопасности (java.security.Policy). Всё очень гибко устроено так, что система управления доступом обеспечивает механизмы, которые используют права доступа и политики безопасности, чтобы разрешить или запретить доступ к определённым ресурсам от файлов на локальном диске до сетевых соединений (включая домены) и защищённых объектов среды выполнения.

> Иа (27.06.07 02:24) [73]
> 2) Никакой проверки на наличие сертификата в разрешенных
> не происходит если это не апплет. То есть по умолчанию.
> 3) Что бы распространить полиси с апплетов на запускаемое
> приложение надо сделать это ручками java -Djava.security.
> manager MyLoader

Пока не определена новая политика безопасности в системе Java, используется базовая политика безопасности. В каталоге [JAVA_HOME]/lib/security/ находится файл java.security, в котором по мимо прочего есть две записи, указывающие, где находится файл политики безопасности. Пример:policy.url.1=file:${java.home}/lib/security/java.policy policy.url.2=file:${user.home}/.java.policy Приведу так же содержимое стандартного файла политики [JAVA_HOME]/lib/security/java.policy: // Standard extensions get all permissions by default grant codeBase "file:${{java.ext.dirs}}/*" { permission java.security.AllPermission; }; // default permissions granted to all domains grant { // Allows any thread to stop itself using the java.lang.Thread.stop() // method that takes no argument. // Note that this permission is granted by default only to remain // backwards compatible. // It is strongly recommended that you either remove this permission // from this policy file or further restrict it to code sources // that you specify, because Thread.stop() is potentially unsafe. // See "http://java.sun.com/notes" for more information. permission java.lang.RuntimePermission "stopThread"; // allows anyone to listen on un-privileged ports permission java.net.SocketPermission "localhost:1024-", "listen"; // "standard" properies that can be read by anyone permission java.util.PropertyPermission "java.version", "read"; permission java.util.PropertyPermission "java.vendor", "read"; permission java.util.PropertyPermission "java.vendor.url", "read"; permission java.util.PropertyPermission "java.class.version", "read"; permission java.util.PropertyPermission "os.name", "read"; permission java.util.PropertyPermission "os.version", "read"; permission java.util.PropertyPermission "os.arch", "read"; permission java.util.PropertyPermission "file.separator", "read"; permission java.util.PropertyPermission "path.separator", "read"; permission java.util.PropertyPermission "line.separator", "read"; permission java.util.PropertyPermission "java.specification.version", "read"; permission java.util.PropertyPermission "java.specification.vendor", "read"; permission java.util.PropertyPermission "java.specification.name", "read"; permission java.util.PropertyPermission "java.vm.specification.version", "read"; permission java.util.PropertyPermission "java.vm.specification.vendor", "read"; permission java.util.PropertyPermission "java.vm.specification.name", "read"; permission java.util.PropertyPermission "java.vm.version", "read"; permission java.util.PropertyPermission "java.vm.vendor", "read"; permission java.util.PropertyPermission "java.vm.name", "read"; };
Вообще же, общий формат файла политики таков:[keystore "URL_хранилища_ключей", "тип_хранилища";] grant [SignedBy "список_подписавших"] [, CodeBase "URL_базы_кода"] { permission имя_класса_права_доступа ["имя_объекта"] [, "действие"] [, SignedBy "список_подписавших"]; .... }(в именах допустимы шаблоны: ${user.home}, ${file.separator} и т.д.).
При задании новой политики для приложения можно определить: класс Провайдера политики безопасности, класс собственного Диспетчера безопасности, файл Политики безопасности или же оставить что-то из них по умолчанию. Всё это похоже на управление расширенным доступом на основе ACL в операционных системах UNIX.

> Иа (27.06.07 02:24) [73]
> 4) До 1.2 все было ГОРАЗДО хуже.

Не надо абсолютизировать.
До v.1.2 нельзя было задать свою политику безопасности и права доступа для выполнения приложения в JVM. В Java 1.0.x всё походило на политику безопасности Microsoft для ActiveX (которые можно было либо вырубить, либо разрешить им всё) и EXE-приложения. В Java 1.1: апплеты выполнялись в песочнице с максимальными ограничениями; подписанные апплеты имели определённые права и доступ к файловой системе (как приложения пользователя); приложения же были ничем не ограничены. Всё это было не очень гибко. Сейчас же (начиная с версии Java 1.2) всё гораздо гибче -- появилась возможность создания конфигурируемых прав доступа.

> Иа (27.06.07 02:24) [73]
> Вывод: правила безопасности на основе цифровой подписи в
> java по прочности в подметки не годятся .NET security policy.

Если не хотите разбираться, что ж, думайте так и дальше. :))

> Иа (27.06.07 02:24) [73]
> Собственно, это меня и интересовало. Спасибо.

Пожалуйста.

P.S.
Сертификаты служат для идентификации производителя продукта и определения принадлежности продукта конкретному производителю. Дайджест (MD-5, SHA-1) удостоверяет целостность продукта. Напоминаю, что в данной теме разговор ведётся именно о защите контента от дизассемблирования и обеспечения его целостности -- о защите от модификации.

О декомпиляции, клонировании, Dephi и Java Найти похожие ветки