Я хочу встроить в выполняемый JAR файл механизм проверки этого файла.
То есть, если пользователь распаковал оригинальый файл, изменил в нём что-то, а потом опять сделал новый файл, то этот новый файл не должен работать.
Сделать это я хочу с помощью обычных signed JAR файлов.
Как это сделать описано в документации Явы.
Но есть одно но. Существенное.
Что если пользователь
а) распакует JAR файл,
б) найдёт механизм проверки и
в) уберёт соответствущие части
?
Как этому можно противостоять?
Я думал использовать obfuscator.
Вопрос: Какой из общедоступных лучше всего выполняет свою работу?
Возможно, имеет смысл вставить механизм проверки не только на старте, а во многих разных местах. Или запускать механизм проверки время от времени, через случайные интервалы времени.
Вопрос: Как можно защитить программу кроме указанных мер?
Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>Вопрос: Как можно защитить программу кроме указанных мер? ДП>Заранее благодарен ДП>Дмитрий
При сборке джарника, расчитывается некоторая контрольная сумма и записывается в специальный файл, который и помещается в джарник.
Затем при работе приложения джарники регулярно проверяются на предмет контрольной суммы и соответствия тому, что находится в файле.
— это у меня под боком приложение есть, там такой принцип работы.
Здравствуйте, Дмитрий В, Вы писали:
ДВ>При сборке джарника, расчитывается некоторая контрольная сумма и записывается в специальный файл, который и помещается в джарник. ДВ>Затем при работе приложения джарники регулярно проверяются на предмет контрольной суммы и соответствия тому, что находится в файле. ДВ> — это у меня под боком приложение есть, там такой принцип работы.
Добавление файла не меняет контрольную сумму или он кладётся в другой jar-файл? Впрочем и такое ломается.
Здравствуйте, Delight, Вы писали:
D>Здравствуйте, Дмитрий В, Вы писали:
ДВ>>При сборке джарника, расчитывается некоторая контрольная сумма и записывается в специальный файл, который и помещается в джарник. ДВ>>Затем при работе приложения джарники регулярно проверяются на предмет контрольной суммы и соответствия тому, что находится в файле. ДВ>> — это у меня под боком приложение есть, там такой принцип работы.
D>Добавление файла не меняет контрольную сумму или он кладётся в другой jar-файл?
А хрен знает, другой мужик писал.
D>Впрочем и такое ломается.
А как ломается? Расскажи, я тут всех обрадую
Здравствуйте, Delight, Вы писали:
D>Здравствуйте, Дмитрий В, Вы писали:
ДВ>>При сборке джарника, расчитывается некоторая контрольная сумма и записывается в специальный файл, который и помещается в джарник. ДВ>>Затем при работе приложения джарники регулярно проверяются на предмет контрольной суммы и соответствия тому, что находится в файле. ДВ>> — это у меня под боком приложение есть, там такой принцип работы.
D>Добавление файла не меняет контрольную сумму или он кладётся в другой jar-файл? Впрочем и такое ломается.
А файлик кладется в тот же джарник.
Здравствуйте, Дмитрий В, Вы писали:
D>>Добавление файла не меняет контрольную сумму или он кладётся в другой jar-файл? Впрочем и такое ломается. ДВ>А файлик кладется в тот же джарник.
Здравствуйте, Дмитрий В, Вы писали:
ДВ>Здравствуйте, 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, дальше просто...
Здравствуйте, Дмитрий В, Вы писали:
A>>Вы сэр щас понимаете что при "кладении" в JAR нового файла, у вас JAR получится другой? поменяется и контрольная сумма... ДВ>Сэр, как вы можете делать выводы об изменении контрольной суммы, если вы даже не знаете, как она считается?
Это даже не интересно ломать, тогда. Если вы хешируете не бинарные данные, а файлы по маске...
Дмитрий В wrote:
> D>>>Добавление файла не меняет контрольную сумму или он кладётся в > другой jar-файл? Впрочем и такое ломается. > ДВ>>А файлик кладется в тот же джарник. > D>Me чешет репу в замешательстве. Манифест, что ли? > Нет, файлик key.key , кладется в папку META-INF
А что мешает поправить в jar чего угодно, посчитать контрольную сумму и записать результат в META-INF/key.key?
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.>Дмитрий В 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-файла на неиспорченность?
А если взломщик знает, как этот механизм работает (что возможно, потому как механизм-то стандартный) ?
Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>Вопрос: Насколько реально обойти такую защиту?
ДП>Может взломщик поступить так:
ДП>1) Найти ту часть кода, где производится эта проверка, ДП>2) убрать её оттуда
ДП>Ну и ещё вопрос вдогонку: Насколько я знаю, в Яве можно шифровать class-файлы.
мне кажется, что всё обходится подсовыванием своих класс-лоадеров
Здравствуйте, C0s, Вы писали:
C0s>Здравствуйте, Дмитрий Писаренко, Вы писали:
C0s>мне кажется, что всё обходится подсовыванием своих класс-лоадеров
Я видел такую реализацию:
1. jar файлы -> свой собственный формат + свой native класслоадер
2. Классы шифруются и достаются только по имени (т.е. каталог просмотреть невозможно)
3. Классы подгружаются через preload (имена закодированы в byte как указали выше) и есть только одна точка входа, через которую уже все дальше раскручивается
4. Большинство классов интструментируется кодом посдчета хешсумм критических внутренних данных класса (вероятно в исходниках есть некие аннтоации CompileTime которые говорят что и как считать)
5. Встроена логика зависимостей по preload одних пакетов от других (т.е. цепочка криптования на основе некого базового ключа + хешсумма от предыдущих)
Впрочем и такое ломается.
