Еще раз про защиту с привязкой к железу и ключом

[ger_kar]

В общем поиск информации на эту тему, а ее надо сказать немало на просторах интернета, скорее больше запутал, чем дал ответ на интересующие вопросы. Советов много и такое ощущение, что стоишь перед развилкой из ста дорог и мучительно думаешь какую из них выбрать, что-бы начать продвижение. С другой стороны хотелось бы сразу выбрать верное направление, что-бы не метаться от одного способа к другому и не распылять свою энергию на заранее непригодные и кривые варианты.
А хотелось бы для начала реализации знать четкую программу действий и именно на ней сосредоточить все усилия.
Хотелось бы реализовать защиту с привязкой к компьютерному железу, ключом и кодом активации. Ключ нужен для учета.
Программа примерно такова:
1) Сбор информации об установленном железе (тут все прозаично)
2) Далее собранную информацию желательно привести в удобоваримый вид, один вариант - это хеширование, поэтому из собранной инфы можно получить хеш используя например MD5. В итоге получится 128 битный хеш, который пользователь должен вместе с ключом (ключ будет на диске) отправить для получения кода активации.
А дальше у меня непонятки:
3) Что мне делать с этими данными полученными от пользователя, как генерировать код активации и как вовлечь в этот процесс ключ? Сложить ключ и хеш данных о железе и еще раз получить общий хеш, который и будет кодом активации или же нужно закриптовать симметричным алгоритмом (вопрос каким?). Или вообще изобрести свой велосипед. А может достаточно простого XOR шифрования?

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

[FireFenix]

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

По моему для этого достаточно использовать обычный "солёный" хеш
Скажем на md5: md5(md5([серийник харда]), [ключ активации]) == [заложенный ключ]

Можно использовать большее количество вложений, комбинаций или алгоритмы по вкусу, но как ты уже сказал: самое слабое место - это именно проверка на соответствие.

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

Ну адрес будет не статичным, а разница? С точки зрения логики - всё равно будет сравнение и в зависимости от условия, переход в различные места. Для взлома достаточно сделать, чтобы условие всегда выполнялось.
Для таких целей применяют обфускацию/упаковку.

Пока что самое надёжное - ключ-флешка

[Diamock]

Эх... Вот если бы можно было сделать сравнение без If-Else и Select Case тогда можно говорить о защите...

[ger_kar]

Пока что самое надёжное - ключ-флешка

Да, но это не самый дешёвый, а в моем случае еще и крайне неудобный вариант.

С точки зрения логики - всё равно будет сравнение и в зависимости от условия, переход в различные места.

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

[ger_kar]

Эх... Вот если бы можно было сделать сравнение без If-Else и Select Case тогда можно говорить о защите...

В том то и фишка, что никаких If-Else и Select Case даже близко не будет.

[ger_kar]

Скажем на md5: md5(md5([серийник харда]), [ключ активации]) == [заложенный ключ]

Может лучше наоборот md5(md5([серийник харда]) & [ключ Лицензии]) == [код активации]
В исполняемом файле в этом случае ничего хранится не будет, но этот способ наверное не очень хорош ибо на стороне пользователя будут иметься все средства для генерации кода активации. Для генерации кода оборудования MD5 можно заюзать, но вот дальше его использование весьма сомнительно.

[ger_kar]

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

[FireFenix]

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

Как минимум необходимо обезопасить переход, чтобы если юзер случайно ошибся в 1 символе - у него всё не "взорвалось"

В итоге получаем отдельно стоящую функцию с ограничением расположения в памяти. Составляем граф, смотрим какие куски никогда не вызываются и пробуем передать на них управление, пока не найдём нужный.
Это с учётом того, что передача управления идёт как дальнейшее выполнение программы. Если после "джампа" мы используем код, который включает опции регистрации - то это обычный crack me.

Если всё будет запаковано и обфусцировано (+ некоторые пихают левый мусорок для зхаблуждений), то шансы взломать будут ниже.

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

Возьмём самое простое:
Длина пароля 8, символы которого входят в [a-zA-Z0-9] => 2*26 букв + 10 цифр = 62 символа
62 ^ 8 = 218.340.105.584.896 комбинаций
На моих GF 9800GTX + Core i5 производительность где-то 350млн/cек + 20млн/cек ~ 400млн/сек паролей
Делим количество комбинаций на скорость перебора и получаем 545.850 сек = 9.097 минут = 151час ~ 7 дней (это чистый MD5 для [a-zA-Z0-9] длиной в 8 символов.)

А теперь посмотрим (тыц) на солёный MD5 - 109млн/сек => в 4 раза медленнее
Если использовать дважды солёный, то ~в 16 раз медленнее => 7дней * 16 = 112 дней

Получается для 2жды солёного хеша с длиной в 8 символов, при известной "соли" перебирается за 1/3 года.
В твоём случае же: соль не известна или конченая операция перебора ничего не даст,т.к. после неё идут некоторые условия, тем самым время подбора через md5 брут стремиться к 0.

Конечно, существуют ещё радужные таблицы, но сгенеренных больше чем на 8 символов - не видел.

Чтоб вообще не оставить вариантов, можно заюзать md6 или другой не популярный алгоритм

[ger_kar]

Как минимум необходимо обезопасить переход, чтобы если юзер случайно ошибся в 1 символе - у него всё не "взорвалось"

Видимо все-же придется заюзать сравнение, именно для барьера, чтобы ничего не "взорвалось" .

На моих GF 9800GTX + Core i5 производительность где-то 350млн/cек + 20млн/cек ~ 400млн/сек паролей

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

А теперь посмотрим (тыц)

Занимательная однако статистика. Кстати очень удивил такой момент:
md5($pass.$salt) - 170 million p/s
md5($salt.$pass) - 260 million p/s
Казалось бы, что в лоб, что по лбу, а такая разница...

Конечно, существуют ещё радужные таблицы, но сгенеренных больше чем на 8 символов - не видел.

Извиняюсь за свою дремучесть, но что такое радужные таблицы я в упор не знаю

Чтоб вообще не оставить вариантов, можно заюзать md6 или другой не популярный алгоритм

Это точно, чем "не популярнее" тем лучше, а можно сделать операцию "Ы" и внести мутацию (можно даже кривую ) в популярный алгоритм и тогда уж точно никто не догадается

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

[Хакер]

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

Как метод защиты это — святая дребедень.

FireFenix уже описал метод: строится Execution-Flow-Graph и в нём очень легко обнаружить процедуру, которая сама вызывает дофига, но которую саму не вызывает никто.

Кстати, в COM-приложении таких процедур будет неимоверная количества: каждый метод класса будет таким, потому что вызывается он только косвенно через vtable. Но чуть более умный анализатор это покажет.

[ger_kar]

Как метод защиты это — святая дребедень.

Оно конечно может и дребедень, но все же это гораздо лучше банального сравнения. Если писать на ассемблере, то там можно еще помудрить, но в VB If ... Tnen ... никуда не денешь и любое их количество, да же сильно размазанное по проге за сравнительно небольшой промежуток времени можно подчистить. Причем это сравнительно легко сделать как в отладчике, так и дизассемблером IDA. Что касается динамического вычисления адреса на основе например хеша от оборудования, то здесь дизассемблер уже не очень поможет.
Если например сделать с одним переходом, то это получится самый простейший СrackMe для начинающих, если размазать это по проге, то это будет уже СrackMe для продолжающих, а для того что-бы поломать мой вариант нужно дорасти до среднего уровня. Прога будет распространятся в городке где я живу, и зная уровень местных умельцев, я думаю это будет вполне надежным заслоном от левого распространения.

FireFenix уже описал метод: строится Execution-Flow-Graph и в нём очень легко обнаружить процедуру, которая сама вызывает дофига, но которую саму не вызывает никто.

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

Пока у меня проблема в другом:
Решил таки применить RSA для генерации кода активации, попробовал, получилось следующее:
Например Хеш: D41D8CD98F00B204E9800998ECF8427E после криптования RSA превращается в такой код
D<04>˜<07><13>7•<05><12>$c D<04>˜<07>I5f”'“<19>ID<04>˜<07>A<13>(1I5f”<07>‚ <11>6<15>Q(6<15>Q("7%u!w&“6<15>Q(<13>7•<05>99p•A<13>(1I5f”6<15>Q(6<15>Q(A<13>(1A<13>(1I5f”99p•'“<19>I<07>‚ <11>I5f”<13>7•<05>!w&“H#ip99p•, что меня совсем не устраивает, ибо один из способов активации будет по телефону, и то что получается, получается во первых очень уж длинно, а во вторых выглядит прямо скажу не очень кошерно
Хотелось бы на выходе получать, что-то подобное "D41D-8CD9-8F00-B204-E980-0998-ECF8-427E", что еще можно заюзать, что-бы получить искомое? Или придется свой алгоритм изобретать?

[Хакер]

Что касается динамического вычисления адреса на основе например хеша от оборудования, то здесь дизассемблер уже не очень поможет.

Что тебе мешает шифровать не адрес, а сам код?

[ger_kar]

Ну код по объему больше, и соответственно шифрование/дешифрование будет потреблять намного больше ресурсов и снижать производительность. С адресами все будет намного быстрее.

[Хакер]

В общем, эта защита уровня «заклеить сейф скотчем».

[Antonariy]

Можно компилировать часть проги с привязкой к железу. Этот способ подходит при последующей активации через интернет.
Что я имею ввиду.
1) Создать библиотеку с классом, содержащим много сервисных функций, но вызывающихся сравнительно редко (но желательно из многих мест) ибо это будет медленно. А что, за все надо платить.
2) Создать в основной проге модуль с константами, содержащими названия этих функций: FUNC_GETDATA = "GetData". Это чтобы самому потом не запутаться.
3) Зашифровать названия функций, используя комбинацию двух ключей: названия функции и ключа, созданного на основании данных о железе.
4) Вызовы этих функций сделать так: CallByName(obj, Decode(FUNC_GETDATA), ...).
5) В Decode расшифровывать название метода теми же ключами.
6) При активации программы через интернет на сервер передается железный ключ, выполняется п. 3, сервер запускает компилятор и возвращает готовую dll.

Думаю, не надо объяснять, что при неудачной дешифровке будет object does not support this property or method.
В самой dll тоже можно что-нибудь наворотить.

[Хакер]

Это всё архи-смехотворно.

[Antonariy]

Рассказывай.

[Хакер]

Ну даже вариант ger_kar'а с шифрованием адреса лучше.
Если адрес зашифрован и неизвестен, то он неизвестен и всё тут.
А если имя метода зашифровано и неизвестно, то на радость взломщику есть таблица расшифрованных имён методов.

Хотя, если до оплаты своей копии, клиент не располагает dll-кой, в чём вообще смысл подхода с dll? Почему просто не слать ему полностью скомпилированную программу, которая работала бы только на его машине?

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

А шифровать имена вызовов IDispatch::Invoke — это детские забавы.

[Хакер]

К тому же хорошая защита — это такая, которую анализируешь-анализируешь, а момент бифуркации поведения так и не удаётся найти. То есть саму защиту не видно.

А у вас:
У одного — упало при вызове по левому адресу, ага, вот она защита.
У другого — вылезла ошибка «object does not support this property or method», ага, вот она защита.

[Antonariy]

Понял. Действительно глупо.

Почему просто не слать ему полностью скомпилированную программу, которая работала бы только на его машине?

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

[Хакер]

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

Вообще, под x86 системой Native API предоставляет одну очень интересную возможность, позволяющую в принципе создать внутри процесса такую среду, что любой отладчик загнётся там от «не-нормальности мира». По-крайней мере те, что мне знакомы. Надеюсь, что использовать эту возможность защиты ради никому ещё не приходило в голову.

[ger_kar]

В общем, эта защита уровня «заклеить сейф скотчем».

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

Код: Выделить всё

"SELECT ProcessorId, Revision FROM Win32_Processor"

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

[Хакер]

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

Нет. Не надо переоценивать. Именно скотчем.

[ger_kar]

Нет. Не надо переоценивать. Именно скотчем.

А где тогда сейф

Достойная защита, это когда куча процедур, которые вызываются и никогда не возвращают управление.

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

весь полезный код разбивается на чунки. Чунки перекодируются таким образом, что код чунка работает так:

Какое диковинное и прикольное название "чунка" - мне очень понравилось. А что до дальнейшего, то вряд ли такое можно на VB реализовать, в отличии от моего варианта. Кроме всего прочего при такой реализации трудоемкость реализации и соответственно стоимость защиты превысит стоимость самого продукта. Такое вариант, если уж и реализовывать, то как отдельный продукт для многократного применения.

Вообще, под x86 системой Native API предоставляет одну очень интересную возможность, позволяющую в принципе создать внутри процесса такую среду, что любой отладчик загнётся там от «не-нормальности мира».

А само приложение не будет при этом глючить и само загибаться? И будет ли такое возможно с приложением VB?

[Хакер]

Я не понимаю. Не понимаю одного.
Раздел по Windows API, к языку вообще никак не привязанный. Но все говорят только о VB:

Раз:

4) Вызовы этих функций сделать так: CallByName(obj, Decode(FUNC_GETDATA), ...).

Два:

А что до дальнейшего, то вряд ли такое можно на VB реализовать, в отличии от моего варианта

Три:

И будет ли такое возможно с приложением VB?

[ger_kar]

Я не понимаю. Не понимаю одного.Раздел по Windows API, к языку вообще никак не привязанный. Но все говорят только о VB:

Все очень просто. Раздел не привязан к языку, и то что я собираюсь сочинить тоже, но сочинить я хочу такую защиту, которую с минимальными переделками можно реализовать в С, PB и естественно в VB. Здесь собственно идет речь об алгоритме, который к языкам не привязан, но тем не менее для меня очень важно, что-бы это потом потенциально можно было и в проектах на VB применять. А иначе только и придется, что заниматься изобретением очередных велосипедов. Кстати на защиту у меня времени тратится уже больше, чем на само изделие.

Что касается последнего, то мне очень стало интересно. Я думаю, что на VB такое не сотворить, но вполне возможна реализация на других языках в виде стороннего протектора. Может даже таковой в твоей разработке и появится, тогда я стану первым клиентом и бетта тестером .
И вопрос по этому "с приложением VB", а не "на VB". Хотя если ты писал, как можно на VB отладчик сделать, то я не удивлюсь, что и на VB можно реализовать такую защиту. Уже не удивлюсь.

[iGrok]

Какое диковинное и прикольное название "чунка" - мне очень понравилось.

http://translate.google.ru/?q=chunk

[ger_kar]

Вот те на! Такое название и так банально переводится абыдно да

[ger_kar]

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

[Qwertiy]

Сделать что-нибудь с массивом байт от md5, а потом привести к нужному виду.
А ещё существует base-64 кодирование, которое байты превращает в текст, но с увеличением объёма, естественно.