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

B>Понятно, что для .NET и java можно использовать обфускацию, но интересно насколько можно "запутать" кракера "обычными" методами языка?

Главное в этом деле самому не запутаться.
Имей ввиду, что ты должен учитывать ещё и то, что тебе нужно будет управлять лицензиями. Т.е. выпускать новые версии, заносить в блэк-лист недобросовестных пользователей итд. Защита может весьма усложниться, что несопостовимо с затратами на навесную защиту. Если обнаружится какая-нибудь проблема с генерацией ключей, то придётся переделывать и перерассылать ключи всем пользователям.
Как сказали выше, свои велосипеды придумывать не стОит. Они могут быстро перерости в гусеничные трактора.

Привет всем!

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

Собственно, в чем вопрос — можно ли надежно защитить программу не прибегая к "хакерским" методам и различным низкоуровневым трюкам — типа ASMовских вставок, навесных низкоуровневых защит и т.д.?

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

Реализация — .NET, java и Pascal.

Понятно, что для .NET и java можно использовать обфускацию, но интересно насколько можно "запутать" кракера "обычными" методами языка?

--
С уважением,
Михаил.

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

B>Привет всем!

B> К сожалению читаю форум нерегулярно, поэтому прошу заранее прощения, если тема уже всплывала — просто поиск сейчас не работает, а тему надо изучить срочно.

К сожалению, это не та тема, которую можно изучить срочно.

B> Собственно, в чем вопрос — можно ли надежно защитить программу не прибегая к "хакерским" методам и различным низкоуровневым трюкам — типа ASMовских вставок, навесных низкоуровневых защит и т.д.?

Надёжность — это как КПД, т.е. никогда не достигается 100%.
Для начала можно прикинуть уровень допустимых $$$ потерь, это определит всё остальное.

B> Навскидку — можно использовать многопоточные алгоритмы контроля целостности даных, развитая иерархия "секьюрных" классов с виртуальными методами, дублирующими секьюрные данные и методы их проверки.
B> Реализация — .NET, java и Pascal.
B> Понятно, что для .NET и java можно использовать обфускацию, но интересно насколько можно "запутать" кракера "обычными" методами языка?

В двух словах — не стоит тратить время на изобретение "собственных велосипедов", проще и дешевле купить навесную защиту, какую именно — здесь обсуждалось неоднократно, легко найти поиском, он заработает, это уж точно. Если возникнет желание плотнее изучить эту тему и найдётся для этого время, стОит взять в руки свежую книгу К. Касперски "Искусство дизассемблирования" (2008), 892с.
Удачи и успехов!

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

B>Понятно, что для .NET и java можно использовать обфускацию, но интересно насколько можно "запутать" кракера "обычными" методами языка?

У меня есть продукт на .NET, в качестве защиты использую комбинацию хорошего обфускатора (Spices.NET) и велосипеда — собственной виртуальной машины: куски кода, которые нужно спрятать от взломщиков, компилируются в свой байткод и исполняются простой процедуркой. Взломщику придется делать специальный дизассемблер, а потом выискивать нужную логику в большом количестве лишнего автогенеренного кода. Таких героев пока не нашлось.

Главное в этом деле самому не запутаться.
Имей ввиду, что ты должен учитывать ещё и то, что тебе нужно будет управлять лицензиями. Т.е. выпускать новые версии, заносить в блэк-лист недобросовестных пользователей итд. Защита может весьма усложниться, что несопостовимо с затратами на навесную защиту. Если обнаружится какая-нибудь проблема с генерацией ключей, то придётся переделывать и перерассылать ключи всем пользователям.
Как сказали выше, свои велосипеды придумывать не стОит. Они могут быстро перерости в гусеничные трактора.

На самом деле использование чужой программной защиты не освобождает от приведенных проблем с поддержкой лицензий. Взять тот же FLEXnet или StarForce корпоративный. Другое дело — сколько эти продукты стоят.

Я, собственно, немного о другом хотел спросить. Вот есть криптоалгоритмы, стойкость которых доказана математически. Например, если мы используем лицензионный файл с подписью на основе хорошего асимметричного алгоритма шифрования, то вероятность взломать (подделать) такой файл достаточно низкая. Однако остается возможность использовать грубый хак к защищенной программе в месте проверки этого защищенного файла.
Вопрос в том — можно ли сделать такую защиту, которая бы тяжело вскрывалась даже при условии что алгоритм проверки известен.

Насколько я понимаю — это можно сделать с помощью некоторой избыточности. Например, используя множество полиморфных объектов-проверяльщиков, работающих в нескольких потоках, с плавающим алгоритмом вызова. Для простого байт-патча придется найти все места обращения к файлу/загрузчику. Если таких место очень много, а объекты/методы полиморфны и не ищутся по простой сигнатуре, то кракер просто замучается править все эти места. Или я в чем-то ошибаюсь?

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

B>Я, собственно, немного о другом хотел спросить. Вот есть криптоалгоритмы, стойкость которых доказана математически. Например, если мы используем лицензионный файл с подписью на основе хорошего асимметричного алгоритма шифрования, то вероятность взломать (подделать) такой файл достаточно низкая. Однако остается возможность использовать грубый хак к защищенной программе в месте проверки этого защищенного файла.

Самый простой путь взлома таких программ — это изменение открытого ключа в самой программе + написание кейгена на основе новой пары. В данном случае необходимо защитить в программе не только саму проверку, но и хранение и использование открытого ключа.

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

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

B>Насколько я понимаю — это можно сделать с помощью некоторой избыточности. Например, используя множество полиморфных объектов-проверяльщиков, работающих в нескольких потоках, с плавающим алгоритмом вызова. Для простого байт-патча придется найти все места обращения к файлу/загрузчику. Если таких место очень много, а объекты/методы полиморфны и не ищутся по простой сигнатуре, то кракер просто замучается править все эти места.

Да, но только проверок надо на самом деле большое количество, скажем порядка сотен штук.
Самый добрый вариант- это код зашифровать так, чтобы он без ключа не расшифровывался. (точнее, второй добрый; самый добрый — это на сервере код держать)

Причем если вам кроссплатформенно надо, напишите виртуальную машину какого-нибудь языка полегче (типа brainfuck), на нем напишите какие-то части кода, которые нельзя в триале запускать, и уже этот код зашифруйте. Чтобы отвязаться от ассемблера и самомодифицирующегося кода.

DM>собственной виртуальной машины: куски кода, которые нужно спрятать от взломщиков, компилируются в свой байткод и исполняются простой процедуркой.

а эта штука у тебя НЕТ-ориентированная? или более-менее универсальное решение?
расскажи поподробнее, насколько это возможно, конечно

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

ov>а эта штука у тебя НЕТ-ориентированная? или более-менее универсальное решение?

Есть решение как для .NET, так и для нативного кода (С++). Виртуальные машины этих вариантов отличаются набором команд, т.к. в нативном варианте используется арифметика указателей, а в .NET — нет.

ov>расскажи поподробнее, насколько это возможно, конечно

На следующей неделе постараюсь написать, когда из Лаоса вернусь.

ov>>расскажи поподробнее, насколько это возможно, конечно
DM>На следующей неделе постараюсь написать, когда из Лаоса вернусь.
давай. буду ждать. тема, на самом деле, интересная.

Самый простой путь взлома таких программ — это изменение открытого ключа в самой программе + написание кейгена на основе новой пары. В данном случае необходимо защитить в программе не только саму проверку, но и хранение и использование открытого ключа.

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

А что даст подмена ключа? Мы получим какое-то другое значение хеша — как получить такой же хеш из модифицированного сообщения?

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

B>

Самый простой путь взлома таких программ — это изменение открытого ключа в самой программе + написание кейгена на основе новой пары. В данном случае необходимо защитить в программе не только саму проверку, но и хранение и использование открытого ключа.

B>Что-то соображалки у меня в этом смысле не хватает. Допустим нам известен открытый ключ. Что мы делаем дальше? Как мы его подменяем?

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

B>А что даст подмена ключа? Мы получим какое-то другое значение хеша — как получить такой же хеш из модифицированного сообщения?

"Всё уже украдено до нас" (с)
В том смысле, что это не та область, где запросто сооружается свой вариант "Пасьянса", надо всё же иметь соотв. подготовку, некоторый "задел", наработки, в конце концов. Иначе результат будет соответствующим, увы...

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

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

Могу рассказать на примере RSA:
Например ключ регистрации представляет собой некий набор регистрационных данных (название пользователя, тип лицензии, дата окончания лицензии, количество мест и т.д.) и электронную подпись под этими данными (разработчик имеет закрытый ключ, с помощью которого он и подписывает регистрационные данные). При проверке регистрационных данных программа просто проверяет подпись под ними (имея только открытый ключ) — если подпись верна, то считаем что регистрационные данные тоже верны и программа успешно регистрируется введенным ключем.

Злоумышленнику в данном случае достаточно:
1. Сгенерить новую пару закрытый/открытый ключ при известных остальных константах
2. Изменить открытый ключ в программе на открытый из п.1.
3. Написать кейген на основе новой пары из п.1., который по введенным данным будет создавать регистрационные данные+подпись под ними.
4. В инет выкладывается пропатченная программа из п.2. + кейген из п.3.

PT>Могу рассказать на примере RSA:
PT>Например ключ регистрации представляет собой некий набор регистрационных данных (название пользователя, тип лицензии, дата окончания лицензии, количество мест и т.д.) и электронную подпись под этими данными (разработчик имеет закрытый ключ, с помощью которого он и подписывает регистрационные данные). При проверке регистрационных данных программа просто проверяет подпись под ними (имея только открытый ключ) — если подпись верна, то считаем что регистрационные данные тоже верны и программа успешно регистрируется введенным ключем.

PT>Злоумышленнику в данном случае достаточно:
PT>1. Сгенерить новую пару закрытый/открытый ключ при известных остальных константах
PT>2. Изменить открытый ключ в программе на открытый из п.1.
PT>3. Написать кейген на основе новой пары из п.1., который по введенным данным будет создавать регистрационные данные+подпись под ними.
PT>4. В инет выкладывается пропатченная программа из п.2. + кейген из п.3.

Понятно. Насколько я понимаю защита от этого заключается в "сильном" сокрытии ключа и алгоритма проверки?

Соответственно, нельзя использовать APIшные функции шифровки и хеширования, а надо реализовывать свои. Что тоже не слишком хорошо...

Если говорить о сокрытии ключа и схемы проверки, то покритикуйте схему:

0. Пусть имеется LIC-файл состоящий из аттрибутов лицензии и подписи.
1. Защищенная программа имеет модуль-загрузчик, который читает этот файл, шифрует его простым алгоритмом, таким образом, что в зашифрованном блоке возникает некоторая сигнатура (динамическая). Помещает весь этот блок данных в "кучу"
2. Имеется некоторый генератор объектов-проверяльщиков, который создает достаточно большое количество полиморфных объектов, запуская их выполнение в разных потоках.
3. "Проверяльщики" асинхронно сканируют "кучу" на предмет нужной сигнатуры, найдя ее расшифровывают LIC-запись и выполняют проверку. Полиморфность проверяльщиков заключается в том, что методы проверки у них различны (нельзя узнать одно смещение функции проверки). А их большое количество затрудняет поиск и патч всех возможных мест проверки.
4. Дальше фантазии пока не хватает, но допустим, что проверяльщики используют какие-то динамические признаки валидности лицензии, которые также храняться "на куче" и имеется также набор проверяльщиков второго уровня, асинхронно сканирующих эти признаки.

Есть ли у такой идеи слабые стороны, если пока не думать о конкретной реализации?

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

B>Есть ли у такой идеи слабые стороны, если пока не думать о конкретной реализации?

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

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

Идея в том, что необязательно главный поток должен чего-то ждать — поток проверяльщик может просто предпринять какие-то действия мешающие этому основному потоку — например подправить таблицу обработчиков или еще что-то, что приведет к невозможности нормальной работы. Причем таких разнообразных действий может быть достаточно много.
Еще момент — нет прямой ссылки на тот кусок памяти в котором лежит лицензия. Ну и третий момент — асинхронность потоков, которая, насколько я понимаю, должна мешать отладчику.