Защита программы

[sergey-911]

Доброго времени суток уважаемые!
Прошу прощения за банальный вопрос.
Пишу программу для столярного цеха. Программа клиент-серверная, платная. Заказчик денег платит неахти, НО пообещал, что ещё несколько таких фирм, которые он знает, захотят её приобрести!
Так вот, собственно вопрос. Какой алгоритм реализовать, чтобы мой клиент мог использовать программу на ЛЮБЫХ своих компьютерах, подключённых к своему SQL серверу, но никто другой, сделав бэкаб БД, не смог её использовать в другом офисе?
Я вижу выход в том, чтобы приобрести USB ключ, подключить его к серверу и каким-либо образом считывать информацию с него на других компьютерах.
Может вы, чего подскажите? Я столкнулся с этой проблемой впервые!

[Viper]

гм... ищем тему про защиту в этом разделе форума... изжелали до косточек

[Antonariy]

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

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

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

[VKS]

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

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

Учитывая что всёравно рано или поздно программе придётся определиться с легальностью запуска еёжесамой и скорее всего это произойдёт на мнемонике комменды cmp - то что же мешает злоумышленнику добиться тогоже при "Допустим при правильной регистрации программы его результат должен равняться нулю" и, мне кажется, что все эти мат фокусы зависят только от опыта работы с asm. Да и даже если он не должен равняться нулю то это не значит что нельзя узнать чему он должен равняться либо даже проще - как Вы говорили - поменять условие условного перехода или совсем просто решить проблему коммандой jpm

и "высокий порядок сложности этого процесса" рано или поздно придёт к логическому - да/нет

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

А нельзя ли генерировать с "ключа" код в памяти при выполнении которого будет достижение донного результата? Ну другими словами (если совсем грубо поступить) в ключе находится "возможно как то криптован" адрес безусловного перехода дальнейшего выполнения программы (jmp 0xXXXXXXXX или условный для пущей запутанности - вдруг запутаются =)) точно! правда на VB данная реализация станет маленькой проблемкой

[sergey-911]

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

[Andrey Fedorov]

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

У тебя ведь SQL-сервер? Ну и сделай процедуру которая проверяет его имя. Вряд ли оно у всех других потенциальных клиентов то же самое... Ну и по результатам проверки - выполнение программы с урезанной функциональностью (например, без печати)...

[sergey-911]

Спасибо Андрей.
Ты прав. Так и сделаю. Очень своевременный совет, и весьма элегантный!

[alibek]

Учитывая что всёравно рано или поздно программе придётся определиться с легальностью запуска еёжесамой и скорее всего это произойдёт на мнемонике комменды cmp - то что же мешает злоумышленнику добиться тогоже при "Допустим при правильной регистрации программы его результат должен равняться нулю" и, мне кажется, что все эти мат фокусы зависят только от опыта работы с asm.

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