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

E>Насчет крякеров — я неточно выразился, они не взломали прогу, а подобрали ключ.
E>В логах сервера я вижу регистрационное имя "Cracked by DOLTON // REVENGE Crew.". Я естественно не регистрировал такое имя.

E>Поменяю генерацию ключа и вообще алгоритм защиты — сделаю активацию с привязкой к Hardware ID, тем кто уже купил выдам новые ключи.
E>На самом деле защита была написана самая простая, просто на основе RSA. Я не хотел заморачиваться насчет защиты — вдруг программа будет никому и не нужна. Ну а теперь сделаю защиту получше, дизайн переделаю и соответственно выпущу новую версию.

Зачем так сложно? забань обновления базы для "Cracked by DOLTON" но потом, сейчас оно не мешает, да и кряки — тоже типа промоушена

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

А>мне тоже интерестно как?
А>Если вопсользоваться вашим vmprotect на самом деле будет не понять алгоритма проверки ключей ?
А>что vmprotect делает с данными или они остаються без изменений

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

Вот пример для библиотеки FGInt на Delphi:

var e,n:TFGInt;
begin
  ...
  SetLength(e.Number, 2);
  e.Number[0]:=1;
  e.Number[1]:=65537;
  e.Sign:=positive;

  SetLength(n.Number, 12);
  n.Number[5]:=123456789;
  n.Number[1]:=012334545;
  n.Number[4]:=234433454;
  n.Number[7]:=462434346;
  n.Number[3]:=5785676545;
  n.Number[10]:=12346546;
  n.Number[6]:=567345345;
  n.Number[11]:=234345345;
  n.Number[8]:=575675756;
  n.Number[2]:=1232123;
  n.Number[9]:=6456456;
  n.Number[0]:=2342344;
  n.Sign:=positive;
  ...
end;

Содержимое структур можно узнать после инициализации "e" и "n" обычным способом (через Base256StringToFGInt или Base10StringToFGInt).

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

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

Читать — открытого ключа

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

PT>Читать — открытого ключа

Да, я вот тоже задумался... генерация секретного ключа находу

Кстати, а что мешает хакеру найти даже так написанный кусками ключ?... Или я чё-то не догнал...

Если кто-то даже подменит ключ на свой в хакнутой версии, то это ведь никак не скажется на оригинале. Хакнутую версию нужно будет размещать отдельно на сайте. А если есть возможность подменить ключ, то есть и возможность вообще проверку ключа вырезать(как у меня делали) и не париться с кей-генами. Но я еженедельно выпускаю новые версии(чего и всем советую), крак-патчи на них уже не работают. Единственное, что можно сделать, это взломать и выложить взломанный вариант. Кстати, кракеры, которые мне попадались, были людьми аккуратными считали хэш-сумму у файла и по ней определяли годность крака "Потому и не кусают..."

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

CEM>Кстати, а что мешает хакеру найти даже так написанный кусками ключ?... Или я чё-то не догнал...

1. Генерация открытого ключа будет делаться перед каждой проверкой регистрации в твоей программе — т.е. чтобы отломать программу нужно уже как минимум найти все эти проверки.
2. Сам код формирования открытого ключа лучше завиртуализировать (ну или как минимум считать CRC открытого ключа и далее делать неявные проверки полученного результата с CRC "правильного" открытого ключа).

CEM>Если кто-то даже подменит ключ на свой в хакнутой версии, то это ведь никак не скажется на оригинале. Хакнутую версию нужно будет размещать отдельно на сайте. А если есть возможность подменить ключ, то есть и возможность вообще проверку ключа вырезать(как у меня делали) и не париться с кей-генами.

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

Народ, а как Вы боретесь с тем что заходите на какой нибудь сайт и видите что там лежит упакованная ваша программа с готовым ключиком, ну подумаешь версия 3.2.0 а у Вас на сайте уже свежая 3.3.1. Холявщикам подойдёт и 3.2.0 зато бесплатная. Или на это закрывать глаза?

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

PT>2. Сам код формирования открытого ключа лучше завиртуализировать (ну или как минимум считать CRC открытого ключа и далее делать неявные проверки полученного результата с CRC "правильного" открытого ключа).

извините могли бы вы привести пример как можно делать неявные проверки CRC (не на асме)

M_K>Народ, а как Вы боретесь с тем что заходите на какой нибудь сайт и видите что там лежит упакованная ваша программа с готовым ключиком, ну подумаешь версия 3.2.0 а у Вас на сайте уже свежая 3.3.1. Холявщикам подойдёт и 3.2.0 зато бесплатная. Или на это закрывать глаза?

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

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

А>извините могли бы вы привести пример как можно делать неявные проверки CRC (не на асме)

Достаточно просто "примешать" результат сравнения двух CRC к логике своей программы.

Например ваша программа умножает некое число на 2:

var A,B: Integer;
begin
 ...
 A:=B*2;
 ... 
end;

Добавляем неявную проверку CRC:

var A,B: Integer;
begin
 ...
 A:=(B+CRC-Orig_CRC)*2;
 ...
end;

Где CRC — посчитанное CRC открытого ключа, Orig_CRC — CRC "правильного" открытого ключа.

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

PT>Где CRC — посчитанное CRC открытого ключа, Orig_CRC — CRC "правильного" открытого ключа.

спасибо за пример

скажите крякер средней квалификации как долго будет разбираться с выражением A:=(B+CRC-Orig_CRC)*2; запротекченное вашим протектором

насколько трудно будет разобраться крякеру с запротекченным кодом занимающим на Си 200 строк (код не примитивный но и не чего особого нет)

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

if (flag)
A=1;
else
{
B=2;
if (flag1) A=2;
}

я пытаюсь понять насколько надежна будет защита (я понимаю что лучше так чем не как) если программа содержит только работы с sql bd

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

PT>1. Генерация открытого ключа будет делаться перед каждой проверкой регистрации в твоей программе — т.е. чтобы отломать программу нужно уже как минимум найти все эти проверки.

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

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

А>скажите крякер средней квалификации как долго будет разбираться с выражением A:=(B+CRC-Orig_CRC)*2; запротекченное вашим протектором
А>насколько трудно будет разобраться крякеру с запротекченным кодом занимающим на Си 200 строк (код не примитивный но и не чего особого нет)

Суть виртуализации кода (не путать с VMWare и т.д.) заключается в переводе машинных команд х86 в машинные команды нового виртуального процессора со своей архитектурой. Чем больше архитектура конечного процессора будет отличаться от архитектуры начального процессора, тем крякеру будет труднее разобраться в машинных командах виртуального процессора (т.е. как минимум для анализа надо будет написать дизассемблер этих команд, а как максимум — декомпилятор).
В VMProtect реализована микрокомандная ВМ, суть которой заключается в том, что в базовую логику входит ограниченный набор команд, а более сложные операции (например OR, XOR, NOT, NEG, CMP, Jxx и т.д.) реализуются через базовый набор. Вот представьте себе, что ваше условие if (flag) будет представлять из себя пару десятков виртуальных команд, перемешанных с соседними независимыми командами (плюс сюда еще можно добавить различные мусорные команды). Анализировать все это дело без написания специальных инструментов будет невозможно.

P.S. Вот есть немного теории по методу виртуального процессора:
http://www.citforum.ru/security/software/virt_proc/

E>Блин, уже взломали.

Следующее сообщение: блин, уже склонировали!

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

Спасибо за ваше объяснение и ссылку.

Последние вопросы
1) если моя программа после проверки ключя устанавливает N опций настройки то получаеться что тот кто будет хакать может отключить вызов проверки ключя и устанавливать опции как ему надо. Те да проверку ключей не сломают но программу сломать могут (те сегмент данных программы остаеться незащищенный, криптовать раскриптовывать константы выглядит геморойно) у меня нет в программе математики кофициентов и тд тоесть я могу только выполнять или не выполнять функцию отключенную в trial версии

2) насколько замедлиться работа кода с vm

3) насколько стабильно работает ваша vm ? Те не будет ли она вешать программу

4) есть ли у вас клиенты которые в реально используют vmprotect поверх или под другим протектором (как правильно использовать два протектора)

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

А>1) если моя программа после проверки ключя устанавливает N опций настройки то получаеться что тот кто будет хакать может отключить вызов проверки ключя и устанавливать опции как ему надо. Те да проверку ключей не сломают но программу сломать могут (те сегмент данных программы остаеться незащищенный, криптовать раскриптовывать константы выглядит геморойно) у меня нет в программе математики кофициентов и тд тоесть я могу только выполнять или не выполнять функцию отключенную в trial версии

Организация внутренней защиты это отдельная тема

Для начала можно почитать вот это:
http://www.vmprotect.ru/forum/viewtopic.php?t=81

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

А>2) насколько замедлиться работа кода с vm

Скорость под ВМ падает очень сильно, поэтому не рекомендуется виртуализировать код, который будет выполняться в больших циклах.

А>3) насколько стабильно работает ваша vm ? Те не будет ли она вешать программу

Достаточно стабильно

А>4) есть ли у вас клиенты которые в реально используют vmprotect поверх или под другим протектором (как правильно использовать два протектора)

Да, есть:
http://www.vmprotect.ru/forum/viewtopic.php?t=39

PT>Суть виртуализации кода (не путать с VMWare и т.д.) заключается в переводе машинных команд х86 в машинные команды нового виртуального процессора со своей архитектурой. Чем больше архитектура конечного процессора будет отличаться от архитектуры начального процессора, тем крякеру будет труднее разобраться в машинных командах виртуального процессора (т.е. как минимум для анализа надо будет написать дизассемблер этих команд, а как максимум — декомпилятор).
PT>В VMProtect реализована микрокомандная ВМ, суть которой заключается в том, что в базовую логику входит ограниченный набор команд, а более сложные операции (например OR, XOR, NOT, NEG, CMP, Jxx и т.д.) реализуются через базовый набор. Вот представьте себе, что ваше условие if (flag) будет представлять из себя пару десятков виртуальных команд, перемешанных с соседними независимыми командами (плюс сюда еще можно добавить различные мусорные команды). Анализировать все это дело без написания специальных инструментов будет невозможно.

Грамотная идея

ov>лежит она обычно не "на сайте", а на rapidshare и подобных файлообменниках. им можно написать, поплакаться о тяжелой жизни и они там файлик похерят. за сутки, обычно, управляются. с торрентами в этом плане дела обстоят похуже...

А с торрентами можно бороться?

E>В принципе идея насчет нескольких уровней защиты хорошая — но ИМХО нужно делать так, чтобы пользователь понимал, что какое-то ненормальное, неправильное поведение программы именно из-за кряка, а не из-за того что программа плохая.

Вот-вот... Применяю подобную технику, но не все понимают, что значение поля базы данных заменяется на WaReZ из-за кряка или ворованного серийника. Некоторые наивно полагают, что это "прога глючит"

ov>>лежит она обычно не "на сайте", а на rapidshare и подобных файлообменниках. им можно написать, поплакаться о тяжелой жизни и они там файлик похерят. за сутки, обычно, управляются. с торрентами в этом плане дела обстоят похуже...

Tom>А с торрентами можно бороться?

было б можно, кино б скачать нельзя было свежее