Здравствуйте!

Я хочу встроить в выполняемый JAR файл механизм проверки этого файла.

То есть, если пользователь распаковал оригинальый файл, изменил в нём что-то, а потом опять сделал новый файл, то этот новый файл не должен работать.

Сделать это я хочу с помощью обычных signed JAR файлов.

Как это сделать описано в документации Явы.

Но есть одно но. Существенное.

Что если пользователь

а) распакует JAR файл,
б) найдёт механизм проверки и
в) уберёт соответствущие части

?

Как этому можно противостоять?

Я думал использовать obfuscator.

Вопрос: Какой из общедоступных лучше всего выполняет свою работу?

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

Вопрос: Как можно защитить программу кроме указанных мер?

Заранее благодарен

Дмитрий

Здравствуйте, Дмитрий Писаренко, Вы писали:

ДП>Вопрос: Как можно защитить программу кроме указанных мер?
ДП>Заранее благодарен
ДП>Дмитрий
При сборке джарника, расчитывается некоторая контрольная сумма и записывается в специальный файл, который и помещается в джарник.
Затем при работе приложения джарники регулярно проверяются на предмет контрольной суммы и соответствия тому, что находится в файле.
— это у меня под боком приложение есть, там такой принцип работы.

Здравствуйте, Дмитрий В, Вы писали:

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

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

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

D>Здравствуйте, Дмитрий В, Вы писали:

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

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

D>Впрочем и такое ломается.
А как ломается? Расскажи, я тут всех обрадую

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

D>Здравствуйте, Дмитрий В, Вы писали:

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

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

Здравствуйте, Дмитрий В, Вы писали:

ДВ>А как ломается? Расскажи, я тут всех обрадую

Через реверс-инжинринг кода вестимо (сюрприз!) Это если контрольная сумма — надёжный хэш.

Здравствуйте, Дмитрий В, Вы писали:

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

Me чешет репу в замешательстве. Манифест, что ли?

Здравствуйте, Дмитрий В, Вы писали:

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

D>>Здравствуйте, Дмитрий В, Вы писали:

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

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

D>>Впрочем и такое ломается.
ДВ>А как ломается? Расскажи, я тут всех обрадую

ИМХО все ломается и создать нерушимую систему невозможно. Сломают все вопрос времени.

Здравствуйте, Дмитрий В, Вы писали:

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

Вы сэр щас понимаете что при "кладении" в JAR нового файла, у вас JAR получится другой? поменяется и контрольная сумма...

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

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

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

A>Вы сэр щас понимаете что при "кладении" в JAR нового файла, у вас JAR получится другой? поменяется и контрольная сумма...
Сэр, как вы можете делать выводы об изменении контрольной суммы, если вы даже не знаете, как она считается?

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

D>Здравствуйте, Дмитрий В, Вы писали:

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

D>Me чешет репу в замешательстве. Манифест, что ли?
Нет, файлик key.key , кладется в папку META-INF

Здравствуйте, Дмитрий Писаренко, Вы писали:

ДП>Я думал использовать obfuscator.

Из бесплатных proguard, из платных ZKM.

ДП>Возможно, имеет смысл вставить механизм проверки не только на старте, а во многих разных местах. Или запускать механизм проверки время от времени, через случайные интервалы времени.

Не надо ничего придумывать. Принцип простой. Прада ломается тоже на ура.
Берете и разбиваете ваш JAR на два — основное приложение и специальный класслоадер.

И ClassLoader и JAR основного приложения скремблируете так, чтобы имена классов пересекались, чтобы при декомпиляции были методы и поля с одинаковыми именами, чтобы все модификаторы менялись на private. Кароче, чтобы максимально обезопасить себя от перекомпиляции. Убирайте все строковые константы из ClassLoader — делайте из них byte[] и так храните в коде, напишите функцию, чтобы строки получались из byte[] в runtime -- это максимально затруднит поиск по строке "License Expiried" и т.п.

Класс лоадер имеет у себя открытый ключ (лучше хранить его также в byte[], причем использовать для него специальную скремблирующую функцию), точней часть ключа. Вторая часть защивается в лицензионный ключ, выдаваемый хорошему пользователю тайно. JAR шифруется по SHA алгоритму закрытым ключом. И грузится через этот ClassLoader. При совпадении ключей ClassLoader сможет расшифровать и загрузить классы из основного JAR.

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

На 100% защитить практически невозможно.

Здравствуйте, Дмитрий В, Вы писали:

A>>Вы сэр щас понимаете что при "кладении" в JAR нового файла, у вас JAR получится другой? поменяется и контрольная сумма...
ДВ>Сэр, как вы можете делать выводы об изменении контрольной суммы, если вы даже не знаете, как она считается?

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

Дмитрий В wrote:

> D>>>Добавление файла не меняет контрольную сумму или он кладётся в
> другой jar-файл? Впрочем и такое ломается.
> ДВ>>А файлик кладется в тот же джарник.
> D>Me чешет репу в замешательстве. Манифест, что ли?
> Нет, файлик key.key , кладется в папку META-INF
А что мешает поправить в jar чего угодно, посчитать контрольную сумму и записать результат в META-INF/key.key?

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

.>Дмитрий В wrote:

>> Нет, файлик key.key , кладется в папку META-INF
.>А что мешает поправить в jar чего угодно, посчитать контрольную сумму и записать результат в META-INF/key.key?
В данном случае проще подменить классы (или навесить проксики) читающие jar файлы и подсовывать ему оригинальный. (ведь на клиентской машине нет никаких проблем подсунуть даже свой rt.jar если нужно)

Здравствуйте, Дмитрий В, Вы писали:

A>>Вы сэр щас понимаете что при "кладении" в JAR нового файла, у вас JAR получится другой? поменяется и контрольная сумма...

ДВ>Сэр, как вы можете делать выводы об изменении контрольной суммы, если вы даже не знаете, как она считается?

А не накладно лезть в архив, вытаскивать, считать? Может проще контрольную сумму отдельным файлом класть?

Здравствуйте, Дмитрий В, Вы писали:

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

Спасибо за совет, это (signed JAR files) я уже делаю. Вроде работает, т. е. если я

1) распаковываю файл originalJar.jar,
2) заменяю один символ в каком-то файле на другой,
3) делаю новый файл modified.jar и
4) пытаюсь его запустить,

то получаю сообщение, что проверочная сумма файла такого-то не совпадает.

Вопрос: Насколько реально обойти такую защиту?

Может взломщик поступить так:

1) Найти ту часть кода, где производится эта проверка,
2) убрать её оттуда

?

Ну и ещё вопрос вдогонку: Насколько я знаю, в Яве можно шифровать class-файлы.

Имеет смысл зашифровать ту часть кода, которая делает проверку JAR-файла на неиспорченность?

А если взломщик знает, как этот механизм работает (что возможно, потому как механизм-то стандартный) ?

С уважением

Дмитрий

Здравствуйте, aefimov!

Большое спасибо за идею!

Дмитрий

Здравствуйте, Дмитрий Писаренко, Вы писали:

ДП>Вопрос: Насколько реально обойти такую защиту?

ДП>Может взломщик поступить так:

ДП>1) Найти ту часть кода, где производится эта проверка,
ДП>2) убрать её оттуда

ДП>Ну и ещё вопрос вдогонку: Насколько я знаю, в Яве можно шифровать class-файлы.

мне кажется, что всё обходится подсовыванием своих класс-лоадеров

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

C0s>Здравствуйте, Дмитрий Писаренко, Вы писали:

C0s>мне кажется, что всё обходится подсовыванием своих класс-лоадеров

Я видел такую реализацию:
1. jar файлы -> свой собственный формат + свой native класслоадер
2. Классы шифруются и достаются только по имени (т.е. каталог просмотреть невозможно)
3. Классы подгружаются через preload (имена закодированы в byte как указали выше) и есть только одна точка входа, через которую уже все дальше раскручивается
4. Большинство классов интструментируется кодом посдчета хешсумм критических внутренних данных класса (вероятно в исходниках есть некие аннтоации CompileTime которые говорят что и как считать)
5. Встроена логика зависимостей по preload одних пакетов от других (т.е. цепочка криптования на основе некого базового ключа + хешсумма от предыдущих)

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

Самый жесткий вариант — нативный запуск.
Компоненты защиты:
1. Портирумая, хорошо защищенная программа на С++, осуществляющая проверку JVM на предмет "незаконных" вставок (меры против перехвата загруженных классов), дешифровку и проверку компонента 2, дешифровку компонента 3 и его передачу компоненту 2.
2. Небольшой, заскрэмбленный загрузчик классов, получающий основной код программы от компонента 1 по зашифрованному каналу в памяти
3. Основной код программы, зашифрованный и, возможно, содержащийся внутри компонента 1.

Защиту Java кода можно осуществлять по методу Алексея Ефимова.

Здравствуйте, Аноним, Вы писали:

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

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

Здравствуйте, Аноним, Вы писали:

A>>Уезвимость одна. С хорошим ключом можно написать плохой ClassLoader который расшифрует вам JAR, дальше просто...
А>А перехват расшифрованного содержимого с помощью слегка модифицированной JVM?
Слегка модифицировать JVM дело несколько не простое. Но, конечно и так тоже можно. Задача просто получить расшифрованный байт код, который идет в defineClass.

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

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

Зачем модифицировать JVM? Есть замечательный интерфейс JVMPI, 50 строк на C и по событию JVMPI_EVENT_CLASS_LOAD_HOOK дампим чистенький .class.

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


AK>Здравствуйте, aefimov, Вы писали:
A>>Слегка модифицировать JVM дело несколько не простое.
AK>Зачем модифицировать JVM? Есть замечательный интерфейс JVMPI, 50 строк на C и по событию JVMPI_EVENT_CLASS_LOAD_HOOK дампим чистенький .class.
Ломаемая программа может сама запросто перехватить этот хук и использовать например как расшифровщик классов или как дополнительную проверку целостности.

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

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

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

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

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

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

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

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

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

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

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

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

А что за софтинка? Интересно взглянуть.

Здравствуйте, Alex Kirhenshtein, Вы писали:
AK>А что за софтинка? Интересно взглянуть.
ил-2

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

A>Здравствуйте, Alex Kirhenshtein, Вы писали:
AK>>А что за софтинка? Интересно взглянуть.
A>ил-2
Правда это не та софтинка, но механизм очень похож на описанный выше (за исключением пп4, вместо инструментирования используется наследование) и цель защиты — защита сетевого кода

Здравствуйте, Дмитрий

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

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

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

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

Успехов

Возможно стоит глянуть проект:
https://truelicense.dev.java.net

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

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

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

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


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

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

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


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

Вот с этим согласен.
Защита, ИМХО, в первую очередь должна быть не на техническом, а на юридическом уровне. То есть, программу от незаконного использования должно защищать лицензионное соглашение и закон. Это у нас тоже через ж.. работает, но использование этой защиты "честным" пользователям почти не мешает, в отличие от технических методов(помните советы игравших даже в ЛИЦЕНЗИОННЫЙ сталкер? "StarForce лучше вырубить сразу, иначе нормально не поиграете"). Так что, имхо, простого обфускатора(который сильно затруднит по крайней мере использование ваших разработок в чужих программах и декомпиляцию "в лоб"), вполне хватит для несложной защиты от дилетантов.
Это как с квартирой. Если у вас железная дверь и решетки на окнах, то от 99% краж(которые совершаются наркоманами или просто любителями быстрой легкой наживы), вы будете защищены. Но если профессионал узнает, что вы дома храните пару лимонов баксов, то не спасут ни сигнализация, ни двойные двери с десятью замками.

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

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

Ну это очевидно.

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

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

ИМХО проблема "скомпилять обратно" стоит довольно редко. Всегда можно посмотреть алгоритм, пусть и с "подпорченным" переводом и подправить на уровне байт-кода. Это если не брать во внимание шифрование и подпись, с которыми борются другими методами.

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


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

Ну, разумеется, не забыть указать "use java keywords as names". Когда все подряд после декомпиляции называтся do, while, return и пр., это выглядит прикольно . А jvm пофиг, как назыать классы, ограничения ведь только на код.