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

Обсуждения по программированию для ОС Windows безотносительно используемого языка программирования. Windows NT, Win32, Windows API, ядро и драйверы.
ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1873
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

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

Сообщение ger_kar » 12.02.2012 (Вс) 14:33

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

И еще по поводу дальнейшей проверки в программе. Дело в том, что это самое уязвимое место. Можно конечно эту проверку делать не раз и не два, т.е. попросту ее размножить, но мне пришла другая идея, что если вызов процедур и ф-ций делать по указателю, соответственно адрес будет не статичным, а будет высчитываться на основе кода активации и в случае если все ОК, то вызовы пойдут по нужным адресам и все будет работать, а иначе вызовы просто уйдут в никуда и все весело упадет, выдав неприятное сообщение. Что вы думаете насчет такой идеи?
Последний раз редактировалось ger_kar 12.02.2012 (Вс) 18:51, всего редактировалось 1 раз.
Бороться и искать, найти и перепрятать

FireFenix
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1640
Зарегистрирован: 25.05.2007 (Пт) 10:24
Откуда: Mugen no Sora

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

Сообщение FireFenix » 12.02.2012 (Вс) 15:16

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

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

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

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

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

Пока что самое надёжное - ключ-флешка
Птицей Гермеса меня называют, свои крылья пожирая... сам себя я укрощаю
私はヘルメスの鳥 私は自らの羽根を喰らい 飼い慣らされる

Diamock
Постоялец
Постоялец
Аватара пользователя
 
Сообщения: 356
Зарегистрирован: 26.10.2009 (Пн) 4:19
Откуда: Кемерово

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

Сообщение Diamock » 12.02.2012 (Вс) 15:53

Эх... Вот если бы можно было сделать сравнение без If-Else и Select Case тогда можно говорить о защите...
In der Beschrankung zeigt sich erst der Meister
Visual Basic Russian Knowledge Base

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1873
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

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

Сообщение ger_kar » 12.02.2012 (Вс) 16:09

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

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1873
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

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

Сообщение ger_kar » 12.02.2012 (Вс) 16:10

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

В том то и фишка, что никаких If-Else и Select Case даже близко не будет.
Бороться и искать, найти и перепрятать

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1873
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

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

Сообщение ger_kar » 12.02.2012 (Вс) 18:50

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

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

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1873
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

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

Сообщение ger_kar » 13.02.2012 (Пн) 21:09

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

FireFenix
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1640
Зарегистрирован: 25.05.2007 (Пт) 10:24
Откуда: Mugen no Sora

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

Сообщение FireFenix » 13.02.2012 (Пн) 23:16

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

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

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

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

ger_kar писал(а):... И еще мне вот думается, а не стоит ли в реализацию алгоритма 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
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1873
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

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

Сообщение ger_kar » 14.02.2012 (Вт) 8:39

FireFenix писал(а):Как минимум необходимо обезопасить переход, чтобы если юзер случайно ошибся в 1 символе - у него всё не "взорвалось"
Видимо все-же придется заюзать сравнение, именно для барьера, чтобы ничего не "взорвалось" ;) .
FireFenix писал(а):На моих GF 9800GTX + Core i5 производительность где-то 350млн/cек + 20млн/cек ~ 400млн/сек паролей
Я что-то видимо отстал от жизни, разве видяху можно заюзать для этих целей? И насколько я понял основная доля вычислений, как раз и приходится на видяху. Да надо срочно восполнять пробелы и почитать на эту тематику.
FireFenix писал(а):А теперь посмотрим (тыц)

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

FireFenix писал(а):Конечно, существуют ещё радужные таблицы, но сгенеренных больше чем на 8 символов - не видел.
Извиняюсь за свою дремучесть, но что такое радужные таблицы я в упор не знаю :oops:

FireFenix писал(а):Чтоб вообще не оставить вариантов, можно заюзать md6 или другой не популярный алгоритм
Это точно, чем "не популярнее" тем лучше, а можно сделать операцию "Ы" и внести мутацию (можно даже кривую ;) ) в популярный алгоритм и тогда уж точно никто не догадается ;)

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

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16073
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

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

Сообщение Хакер » 14.02.2012 (Вт) 9:59

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

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

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

Кстати, в COM-приложении таких процедур будет неимоверная количества: каждый метод класса будет таким, потому что вызывается он только косвенно через vtable. Но чуть более умный анализатор это покажет.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1873
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

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

Сообщение ger_kar » 14.02.2012 (Вт) 11:42

Хакер писал(а):Как метод защиты это — святая дребедень.
Оно конечно может и дребедень, но все же это гораздо лучше банального сравнения. Если писать на ассемблере, то там можно еще помудрить, но в 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", что еще можно заюзать, что-бы получить искомое? Или придется свой алгоритм изобретать?
Бороться и искать, найти и перепрятать

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16073
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

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

Сообщение Хакер » 14.02.2012 (Вт) 12:30

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

Что тебе мешает шифровать не адрес, а сам код?
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1873
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

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

Сообщение ger_kar » 14.02.2012 (Вт) 12:54

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

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16073
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

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

Сообщение Хакер » 14.02.2012 (Вт) 16:04

В общем, эта защита уровня «заклеить сейф скотчем».
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

Antonariy
Повелитель Internet Explorer
Повелитель Internet Explorer
Аватара пользователя
 
Сообщения: 4824
Зарегистрирован: 28.04.2005 (Чт) 14:33
Откуда: Мимо проходил

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

Сообщение Antonariy » 14.02.2012 (Вт) 16:10

Можно компилировать часть проги с привязкой к железу. Этот способ подходит при последующей активации через интернет.
Что я имею ввиду.
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 тоже можно что-нибудь наворотить.
Лучший способ понять что-то самому — объяснить это другому.

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16073
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

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

Сообщение Хакер » 14.02.2012 (Вт) 16:33

Это всё архи-смехотворно.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

Antonariy
Повелитель Internet Explorer
Повелитель Internet Explorer
Аватара пользователя
 
Сообщения: 4824
Зарегистрирован: 28.04.2005 (Чт) 14:33
Откуда: Мимо проходил

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

Сообщение Antonariy » 14.02.2012 (Вт) 16:52

Рассказывай.
Лучший способ понять что-то самому — объяснить это другому.

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16073
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

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

Сообщение Хакер » 14.02.2012 (Вт) 17:06

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

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

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

А шифровать имена вызовов IDispatch::Invoke — это детские забавы.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16073
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

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

Сообщение Хакер » 14.02.2012 (Вт) 17:10

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

А у вас:
У одного — упало при вызове по левому адресу, ага, вот она защита.
У другого — вылезла ошибка «object does not support this property or method», ага, вот она защита.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

Antonariy
Повелитель Internet Explorer
Повелитель Internet Explorer
Аватара пользователя
 
Сообщения: 4824
Зарегистрирован: 28.04.2005 (Чт) 14:33
Откуда: Мимо проходил

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

Сообщение Antonariy » 14.02.2012 (Вт) 17:14

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

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

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16073
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

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

Сообщение Хакер » 14.02.2012 (Вт) 17:40

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

Вообще, под x86 системой Native API предоставляет одну очень интересную возможность, позволяющую в принципе создать внутри процесса такую среду, что любой отладчик загнётся там от «не-нормальности мира». По-крайней мере те, что мне знакомы. Надеюсь, что использовать эту возможность защиты ради никому ещё не приходило в голову.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1873
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

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

Сообщение ger_kar » 14.02.2012 (Вт) 17:57

Хакер писал(а):В общем, эта защита уровня «заклеить сейф скотчем».
Если уж переходить на ассоциации, то скорее это дощатая хибарка закрытая на дощатую дверь и смысла ставить многослойную бронированную дверь никакого нет. Если говорить предметно, то на самом деле самое узкое место в другом месте, а именно сбор информации об установленном железе и есть та самая сарайка. Потому как запрос
Код: Выделить всё
"SELECT ProcessorId, Revision FROM Win32_Processor"
никуда не спрятать и даже если его формировать динамически посимвольно, то все равно перед вызовом это вылезет, как бельмо на глаз. Ну, а зная какие параметры запрашиваются, остается найти где они возвращаются и подменить их на свои и все. Гораздо проще и быстрее, чем восстанавливать связи между процедурами. Если и шифровать код, то как раз это участок, хотя это большой погоды не сделает, разве что этих запросов не будет видно при просмотре строк в отладчике.
Но все это будет потом, а сейчас на повестке совсем другой вопрос, а именно как сгенерировать удобоваримый и короткий код активации, какой алгоритм асимметричного шифрования можно заюзать, а может и вообще его нафиг не использовать (асимметричное шифрование), но тогда все что нужно для генерации кода активации будет на стороне клиента, и просечь как формируется код большого труда не составит и тогда сразу нарисуется KeyGen.
Вот сижу думу думаю, уж третий день пошел, а воз и ныне там...
Вобщем помогите тупому обучится :cry:
Бороться и искать, найти и перепрятать

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16073
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

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

Сообщение Хакер » 14.02.2012 (Вт) 18:01

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

Нет. Не надо переоценивать. Именно скотчем.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1873
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

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

Сообщение ger_kar » 14.02.2012 (Вт) 18:19

Хакер писал(а):Нет. Не надо переоценивать. Именно скотчем.
А где тогда сейф :lol:

Хакер писал(а):Достойная защита, это когда куча процедур, которые вызываются и никогда не возвращают управление.
Что-то у меня даже в голове такое не очень укладывается, а уж до реализации... Вобщем пока это не мой вариант.
Хакер писал(а):весь полезный код разбивается на чунки. Чунки перекодируются таким образом, что код чунка работает так:
Какое диковинное и прикольное название "чунка" - мне очень понравилось. А что до дальнейшего, то вряд ли такое можно на VB реализовать, в отличии от моего варианта. Кроме всего прочего при такой реализации трудоемкость реализации и соответственно стоимость защиты превысит стоимость самого продукта. Такое вариант, если уж и реализовывать, то как отдельный продукт для многократного применения.
Хакер писал(а):Вообще, под x86 системой Native API предоставляет одну очень интересную возможность, позволяющую в принципе создать внутри процесса такую среду, что любой отладчик загнётся там от «не-нормальности мира».
А само приложение не будет при этом глючить и само загибаться? И будет ли такое возможно с приложением VB?
Бороться и искать, найти и перепрятать

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16073
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

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

Сообщение Хакер » 14.02.2012 (Вт) 18:31

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

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

Два:
ger_kar писал(а):А что до дальнейшего, то вряд ли такое можно на VB реализовать, в отличии от моего варианта

Три:
ger_kar писал(а):И будет ли такое возможно с приложением VB?
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1873
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

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

Сообщение ger_kar » 14.02.2012 (Вт) 19:13

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

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

iGrok
Артефакт VBStreets
Артефакт VBStreets
 
Сообщения: 4247
Зарегистрирован: 10.05.2007 (Чт) 16:11
Откуда: Сетевое сознание

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

Сообщение iGrok » 14.02.2012 (Вт) 19:30

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

http://translate.google.ru/?q=chunk
label:
cli
jmp label

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1873
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

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

Сообщение ger_kar » 14.02.2012 (Вт) 19:52

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

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1873
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

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

Сообщение ger_kar » 15.02.2012 (Ср) 8:57

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

Qwertiy
Доктор VB наук
Доктор VB наук
 
Сообщения: 2751
Зарегистрирован: 26.06.2011 (Вс) 21:26

Сообщение Qwertiy » 15.02.2012 (Ср) 20:35

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

След.

Вернуться в Windows-программирование

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1

    TopList