Re[2]: Защита ява-приложений
От: Аноним  
Дата: 31.05.07 18:00
Оценка:
A>Уезвимость одна. С хорошим ключом можно написать плохой ClassLoader который расшифрует вам JAR, дальше просто...
А перехват расшифрованного содержимого с помощью слегка модифицированной JVM?
Re: Защита ява-приложений
От: Аноним  
Дата: 31.05.07 18:11
Оценка:
Самый жесткий вариант — нативный запуск.
Компоненты защиты:
1. Портирумая, хорошо защищенная программа на С++, осуществляющая проверку JVM на предмет "незаконных" вставок (меры против перехвата загруженных классов), дешифровку и проверку компонента 2, дешифровку компонента 3 и его передачу компоненту 2.
2. Небольшой, заскрэмбленный загрузчик классов, получающий основной код программы от компонента 1 по зашифрованному каналу в памяти
3. Основной код программы, зашифрованный и, возможно, содержащийся внутри компонента 1.

Защиту Java кода можно осуществлять по методу Алексея Ефимова.
Re[2]: Защита ява-приложений
От: Cyberax Марс  
Дата: 31.05.07 18:41
Оценка: 3 (1) +1
Здравствуйте, Аноним, Вы писали:

А>3. Основной код программы, зашифрованный и, возможно, содержащийся внутри компонента 1.

Это все очень просто ломается. Sun JVM хранит байт-коды классов в памяти — так что просто снимаем дамп и выкусываем оттуда все классы (классы замечательно находятся — у них специфический заголовок). Дальше уже дело техники.

ИМХО, не стоит особо мудрить с защитой. Так как слишком крутая защита в первую очередь будет мешать пользователю.
Sapienti sat!
Re[3]: Защита ява-приложений
От: aefimov Россия
Дата: 01.06.07 07:51
Оценка:
Здравствуйте, Аноним, Вы писали:

A>>Уезвимость одна. С хорошим ключом можно написать плохой ClassLoader который расшифрует вам JAR, дальше просто...

А>А перехват расшифрованного содержимого с помощью слегка модифицированной JVM?
Слегка модифицировать JVM дело несколько не простое. Но, конечно и так тоже можно. Задача просто получить расшифрованный байт код, который идет в defineClass.
Re[4]: Защита ява-приложений
От: Alex Kirhenshtein Латвия http://www.netxms.org
Дата: 01.06.07 13:16
Оценка: 8 (1)
Здравствуйте, aefimov, Вы писали:

A>Слегка модифицировать JVM дело несколько не простое.


Зачем модифицировать JVM? Есть замечательный интерфейс JVMPI, 50 строк на C и по событию JVMPI_EVENT_CLASS_LOAD_HOOK дампим чистенький .class.
... << RSDN@Home 1.2.0 alpha rev. 679>>
NetXMS: Open Source Network monitoring solution
Re[5]: Защита ява-приложений
От: aka50 Россия  
Дата: 01.06.07 13:28
Оценка:
Здравствуйте, Alex Kirhenshtein, Вы писали:


AK>Здравствуйте, aefimov, Вы писали:

A>>Слегка модифицировать JVM дело несколько не простое.
AK>Зачем модифицировать JVM? Есть замечательный интерфейс JVMPI, 50 строк на C и по событию JVMPI_EVENT_CLASS_LOAD_HOOK дампим чистенький .class.
Ломаемая программа может сама запросто перехватить этот хук и использовать например как расшифровщик классов или как дополнительную проверку целостности.
Re[6]: Защита ява-приложений
От: Alex Kirhenshtein Латвия http://www.netxms.org
Дата: 01.06.07 14:17
Оценка:
Здравствуйте, aka50, Вы писали:

A>Ломаемая программа может сама запросто перехватить этот хук и использовать например как расшифровщик классов или как дополнительную проверку целостности.


Да, но при этом надо не забывать, что профайлеров может быть много — достаточно отчейнить NotifyEvent и обработывать данные уже после защиты.

Ну, а если очень хочется — то можно конечно и JVM-ме покопаться. Впрочем, с этого и начинали.

p.s. я бы не стал пользоватся приложением, которые вытворяет такие финты.
... << RSDN@Home 1.2.0 alpha rev. 679>>
NetXMS: Open Source Network monitoring solution
Re[7]: Защита ява-приложений
От: aka50 Россия  
Дата: 01.06.07 14:44
Оценка:
Здравствуйте, Alex Kirhenshtein, Вы писали:

AK>Да, но при этом надо не забывать, что профайлеров может быть много — достаточно отчейнить NotifyEvent и обработывать данные уже после защиты.

Если программа сама рожает jvm (через native пускалку), то это становится очень проблематично.

AK>p.s. я бы не стал пользоватся приложением, которые вытворяет такие финты.

Я бы тоже, но приходится
Re[8]: Защита ява-приложений
От: Alex Kirhenshtein Латвия http://www.netxms.org
Дата: 01.06.07 15:11
Оценка:
Здравствуйте, aka50, Вы писали:

A>Если программа сама рожает jvm (через native пускалку), то это становится очень проблематично.


Да тоже, в принципе, не особо проблематично

AK>>p.s. я бы не стал пользоватся приложением, которые вытворяет такие финты.

A>Я бы тоже, но приходится

А что за софтинка? Интересно взглянуть.
... << RSDN@Home 1.2.0 alpha rev. 679>>
NetXMS: Open Source Network monitoring solution
Re[9]: Защита ява-приложений
От: aka50 Россия  
Дата: 01.06.07 16:28
Оценка:
Здравствуйте, Alex Kirhenshtein, Вы писали:
AK>А что за софтинка? Интересно взглянуть.
ил-2
Re[10]: Защита ява-приложений
От: aka50 Россия  
Дата: 01.06.07 16:32
Оценка:
Здравствуйте, aka50, Вы писали:

A>Здравствуйте, Alex Kirhenshtein, Вы писали:

AK>>А что за софтинка? Интересно взглянуть.
A>ил-2
Правда это не та софтинка, но механизм очень похож на описанный выше (за исключением пп4, вместо инструментирования используется наследование) и цель защиты — защита сетевого кода
Re: Защита ява-приложений
От: berdachuk Беларусь http://bolsheprodag.ru/prodvizhenie-sajtov/prodvizhenie-sajta-skolko-stoit
Дата: 04.06.07 08:21
Оценка:
Здравствуйте, Дмитрий

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

Просто скачиваем декомпилятор, например jad как один из самых популярных и смотрим как он разворачивает вашу программу.
Быстро вставляет мозги.

Опыт показывает, что декомпиляторам трудно справиться с:

— Использование обфускаторов. Самый верный обфускатор это тот, который переименовывает классы в буквы одного регистра Пример: A.class и a.class. (под Windows бесполезно ломать, что само по себе уже отсекает большую часть взломщиков)
— Использование ENUM (декомпилятор генерит свою реализацию)
— Использование анотаций jdk 1.5 (пока не видел декомпиляторов способных их развернуть, можно конечно ручками анализируя байт код, но это довольно трудоемко)
— Использование вложенных классов (декомпиляторы выносят их во внешние и часто загибаются)

Успехов
Re[2]: Защита ява-приложений
От: berdachuk Беларусь http://bolsheprodag.ru/prodvizhenie-sajtov/prodvizhenie-sajta-skolko-stoit
Дата: 04.06.07 08:29
Оценка: 1 (1)
Возможно стоит глянуть проект:
https://truelicense.dev.java.net
Re[2]: Защита ява-приложений
От: aefimov Россия
Дата: 04.06.07 08:34
Оценка:
Здравствуйте, berdachuk, Вы писали:

B>- Использование обфускаторов. Самый верный обфускатор это тот, который переименовывает классы в буквы одного регистра Пример: A.class и a.class. (под Windows бесполезно ломать, что само по себе уже отсекает большую часть взломщиков)


Еще добавлю:
+ Включить режим в котором он изменяет все модификаторы на private.
+ Включить режим, в котором он генерит одинаковые имена методов и разные return type при одинаковых параметрах (обратно это скомпилить очень трудно).
Re[3]: Защита ява-приложений
От: Eugeny__ Украина  
Дата: 04.06.07 10:07
Оценка:
Здравствуйте, Delight, Вы писали:


D>Добавление файла не меняет контрольную сумму или он кладётся в другой jar-файл? Впрочем и такое ломается.


Неломаемой защиты нет и быть не может. Не только для java, для вообще любой платформы/языка. Вопрос в соотношении цены программы, спроса на нее и цены взлома.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[3]: Защита ява-приложений
От: Eugeny__ Украина  
Дата: 04.06.07 10:34
Оценка:
Здравствуйте, Cyberax, Вы писали:


C>ИМХО, не стоит особо мудрить с защитой. Так как слишком крутая защита в первую очередь будет мешать пользователю.


Вот с этим согласен.
Защита, ИМХО, в первую очередь должна быть не на техническом, а на юридическом уровне. То есть, программу от незаконного использования должно защищать лицензионное соглашение и закон. Это у нас тоже через ж.. работает, но использование этой защиты "честным" пользователям почти не мешает, в отличие от технических методов(помните советы игравших даже в ЛИЦЕНЗИОННЫЙ сталкер? "StarForce лучше вырубить сразу, иначе нормально не поиграете"). Так что, имхо, простого обфускатора(который сильно затруднит по крайней мере использование ваших разработок в чужих программах и декомпиляцию "в лоб"), вполне хватит для несложной защиты от дилетантов.
Это как с квартирой. Если у вас железная дверь и решетки на окнах, то от 99% краж(которые совершаются наркоманами или просто любителями быстрой легкой наживы), вы будете защищены. Но если профессионал узнает, что вы дома храните пару лимонов баксов, то не спасут ни сигнализация, ни двойные двери с десятью замками.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[4]: Защита ява-приложений
От: Delight  
Дата: 04.06.07 10:35
Оценка:
Здравствуйте, Eugeny__, Вы писали:

E__>Неломаемой защиты нет и быть не может. Не только для java, для вообще любой платформы/языка. Вопрос в соотношении цены программы, спроса на нее и цены взлома.


Ну это очевидно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: Защита ява-приложений
От: Delight  
Дата: 04.06.07 10:35
Оценка:
Здравствуйте, aefimov, Вы писали:

A>Еще добавлю:

A>+ Включить режим в котором он изменяет все модификаторы на private.
A>+ Включить режим, в котором он генерит одинаковые имена методов и разные return type при одинаковых параметрах (обратно это скомпилить очень трудно).

ИМХО проблема "скомпилять обратно" стоит довольно редко. Всегда можно посмотреть алгоритм, пусть и с "подпорченным" переводом и подправить на уровне байт-кода. Это если не брать во внимание шифрование и подпись, с которыми борются другими методами.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: Защита ява-приложений
От: Eugeny__ Украина  
Дата: 04.06.07 10:40
Оценка:
Здравствуйте, aefimov, Вы писали:


A>Еще добавлю:

A>+ Включить режим в котором он изменяет все модификаторы на private.
A>+ Включить режим, в котором он генерит одинаковые имена методов и разные return type при одинаковых параметрах (обратно это скомпилить очень трудно).

Ну, разумеется, не забыть указать "use java keywords as names". Когда все подряд после декомпиляции называтся do, while, return и пр., это выглядит прикольно . А jvm пофиг, как назыать классы, ограничения ведь только на код.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.