Конференция VBStreets

Можете кто-нибудь посоветовать какой-нибудь EXE протектор?

djalex777 писал(а):Можете кто-нибудь посоветовать какой-нибудь EXE протектор?

Язык? Что именно должен защищать? Код? Ресурсы?

Язык: VB6
Объект защиты: код

Нашел протектор Themida. Кто-нибудь пользовался? Недостатки?

Советую бросить заниматься глупостями.

Не понимаю что именно бросить и что глупости... Использовать чужую программу для защиты своей? Делать вобще какую-либо защиту?
Цель - сделать взлом программы дороже её стоимости. Непонимаю, как можно построить защиту. Точнее, кажется, какой метод, из тех которые я могу реализовать, не возьми - всё легко можно обойти. А глянув на то, как декомпилирует Native-EXE тот же VBDecompiler, вобще руки опускаются. Пока реализовал часть не критических по быстродействию функций программы на сервере, чтобы использовать одновременно и как защиту программы, и как проверку лицензии.
Хакер, а что посоветуешь делать? У меня есть три программных продукта, которые нужно продавать. Аудитория покупателей довольно широка. Хочется как-то защитить свои программы - защитить от нелегального использования и некоторую часть от реверс-инжиниринга.

djalex777 писал(а):У меня есть три программных продукта, которые нужно продавать. Аудитория покупателей довольно широка.

Продукты в студию. И прайс. Посмотрим-посмотрим.

Не понимаю что именно бросить и что глупости...

Защищать программу такими методами. Это портит PE-файл очень сильно, делает программу более памяти-жрущей.
Сначала рассказать надо о том, что хочется защитить. Если там какой-то уникальный оригинальный алгоритм, то его будет дешевле купить, чем восстановить из VB-Decompiler'а даже если никакая защита не применена.

Если же цель защиты: усложнить крякинг, то защита защита с помощью протекторов малоэффективна.

В данных программах главная цель - предотвратить нелегальное использование, т.е. фактически не дать человеку использовать программу не заплатив денег. Подумал что протектор поможет решить эту задачу.

Если же цель защиты: усложнить крякинг, то защита защита с помощью протекторов малоэффективна.

Просто не знаю что ещё можно сделать... Поэтому и спрашиваю.

Предотвратить нелегальное использование невозможно, можно его усложнить. А в случае стоимости программы <$100 бессмысленно, сужу по собственному опыту. За два года продаж электронных учебно-методических комплексов было выявлено всего одно "нарушение" лицензии. Почему в кавычках — лицензионное соглашение предполагает установку программы только на один компьютер. Ее и установили на один. На сервер А студенты читали методички через терминалы Это так же к вопросу о технологиях — ломать не всегда необходимо.

Да понимаю я что предотвратить на 100% невозможно. Стоимость двух программ около 2000 руб., а третьей около 10000 руб. По-поводу ломать невыгодно - тут зависит от ширины аудитории, которая будет пользоваться программой. Предположим стоимость твоей программы 500р. а человек, готовых ею пользоваться, 10000. Невыгодно ломать? Выгодно. Но, если защита выше определенного уровня, то уже накладно. Всё вышесказанное про выгоду относится к программам либо не имеющим конкурентов в своей сфере, либо когда конкурентов не много, либо среди конкурентов имеющим большие (лучшие) функциональные возможности. До этого я писал программное обеспечение для конкретных фирм и наделял защитой, которая сейчас, кажется, посмотрев на уровень знаний асемблерных команд и вобще работы машинного кода, тогоже Хакера, обходится очень легко (естественно нигде нет тупых проверок типа if licensed = false then End или после проверки сразуже выскакивающего MsgBox("Ключ программы не верен" и т.д.). И риск того, что контора, заказывающая у меня программное обеспечение, начала бы пускать эти программы "на сторону" был минимальным. Теперь же ситуация другая - программы пускаются в "свободное плавание". И хотелось бы повысить уровень защиты программ с уровня обычного пользователя и сопливого взломщика.

Защищать надо логикой работы, а не программными защитами.
Каким образом протектор предотвратит нелегальное использование программы?

alibek писал(а):Защищать надо логикой работы, а не программными защитами.
Каким образом протектор предотвратит нелегальное использование программы?

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

Под логикой подразумевалось совсем не то, что ты понял.
Как ты думаешь, почему не взламывают клиентов MMORPG или софт типа Shadow Security Scanner?

Клиентов MMORPG? Я понимаю, что ты имел в виду, но формально ещё как взламывают. Делают "отвязку" от оф. сервера, и добавляют возможность работы со сторонними.
Впрочем, я в них уже года три как не играю, может сейчас уже игры без привязки к серверам выпускают..

iGrok писал(а):Клиентов MMORPG? Я понимаю, что ты имел в виду, но формально ещё как взламывают. Делают "отвязку" от оф. сервера, и добавляют возможность работы со сторонними.

Ну и что? Многие делают свои сервера Battle.Net или WOW, от этого подписчиков у Blizzard не убудет.

alibek писал(а):Под логикой подразумевалось совсем не то, что ты понял.
Как ты думаешь, почему не взламывают клиентов MMORPG или софт типа Shadow Security Scanner?

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

djalex777 писал(а):Клиентов MMORPG и прочих не взамывают только потому, что основную функциональную нагрузку несет сервер, именно на его стороне всё реализовано.

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

alibek писал(а):Например, SSS продается только по договору и только юридическим лицам, причем для каждого конкретного клиента делается отдельная компиляция продукта и все ограничения (диапазоны адресов, которые можно тестировать) являются структурной частью программы.

Я думал об этом, но, к сожалению, не думаю что такое возможно. Теряется процентов 30 аудитории + делать отдельную компиляцию для каждого клиента (коих предполагается около 400 в месяц) очень трудоёмко. Про ограничения не понял - любые жестко задаваемые параметры в программе можно же изменить. Будь то цикл, либо любая проверка if и т.д. Приведи пожалуйста пример с каким-нибудь ограничением на котором можно базировать защиту (делать взлом нецелесообразным). Мне ничего в голову просто не приходит. Ведь каждая из компиляций программы имеет одинаковый функционал. Не представляю себе как можно построить логику работы так, чтобы функциональные возможности не изменялись, а взлом становился нецелесообразным. К примеру одна из моих программ позволяет расчитывать стоимость продвижения сайтов в интернете (по России).

djalex777 писал(а):К примеру одна из моих программ позволяет расчитывать стоимость продвижения сайтов в интернете (по России).

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

alibek писал(а):Навскидку, пусть результаты расчетов программа отправляет по электронной почте тому, на кого она зарегистрирована.

Если честно, я не до конца понимаю сути таких механизмов защиты.
К примеру, что мешает заменить адрес почты, зашитый в программу?
Что мешает заменить адреса, зашитые в SSS?

Хакер писал(а):Если же цель защиты: усложнить крякинг, то защита защита с помощью протекторов малоэффективна.

Подскажи пожалуйста, что эффективно.

Код.

Тот, который индусский?

iGrok писал(а):Если честно, я не до конца понимаю сути таких механизмов защиты.
К примеру, что мешает заменить адрес почты, зашитый в программу?
Что мешает заменить адреса, зашитые в SSS?

Ну если это будет что-то вроде Public Const DestinationEmail As String = "...", то ничего.
Нужно смотреть по ситуации. Даже если строку собирать из фрагментов, то обнаружить этот участок кода будет несложно, однако заменить его в исполняемом файле, чтобы адрес был другой, уже станет не тривиальной задачей.
Нужно определить в программе то, что представляет собой ценность для пользователей, и защищать это организационными методами. А код и структура программы должны дополнять эти организационные меры.
В одной из shareware-программ защита выполнена следующим образом: каждый зарегистрированный пользователь получает ключ, в котором закодировано его имя. В принципе, он может эту программу выложить в открытый доступ — в самой программе нет защиты от копирования. Но тогда сразу же станет известно, кто именно из пользователей нарушил условия лицензии. И ему перестают приходить обновления программы, которые выпускаются довольно часто и которые действительно являются нужными, т.к. программа развивается активно. Таким образом, владельцам программы, легально ее купившим, есть что терять и они сами не будут распространять программу. Разве что среди самых близких друзей под условием дальнейшего нераспространения, что на доходах разработчиков не сказывается.

Затереть ключ посланием разработчиков подальше и выложить? Ы?

Каким образом? Вылавливать в коде все места, где храниться хеш ключа?

Хакер писал(а):Затереть ключ посланием разработчиков подальше и выложить? Ы?

Его ещё найти надо. А если это не имя пользователя, а какой-то внутренний ID, хранящийся в виде нескольких взаимозаменяемых кусочков в разных местах программы? Этакая стеганография. )
А если для каждого юзера создаётся своя компиляция с изменением этого ключа + плюс ещё какой-нибудь кусок программы создаётся полиморфным движком, тогда даже анализ двух купленных экземпляров программы мало что даст.

Согласен, этот вариант защиты прокатывает.

Образ зависит от того, как конкретно реализовано впечатывание ключа.

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

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