Защита: привязка к домену

voodoo

Новичок
о надежности getenv:
..> cat v.php
<?php
echo getenv("SERVER_NAME")."\n";
?>
..> export SERVER_NAME=bla-bla; php v.php
bla-bla
..>
 

PhpDeveloper

Guest
Re: Защита: привязка к домену

Автор оригинала: young
Такая ситуация: есть скрипт, который продается и привязывается к доменному имени. Т.е. клиент покупает скрипт, называет домен, ему генерируется и выдается ключ, который он вводит в конфиге. Сам скрипт закодирован ZendEncoder

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

1) Насколько это правильно с точки зрения логики
2) Насколько сложно взломать такую защиту
3) Какой алгоритм оптимален для генерации ключа
1) Абсолбютно правильная идея.
2) Я не знаю как.
3) Дело не в алгоритме генерации ключа, а втом, чтобы доменное имя нельзя было подделать.

$host = getallheaders();
$host = $host['Host'];

// Проверяем установлен ли Apache, как модуль PHP (не помню ф-ю).
// Необходимо для того, чтобы взломщик не создал собственную ф-ю getallheaders().
 

trent

Developer
Нельзя защищаться только на стороне клиента..
IMHO нужен key server (своя база с которой соединятся скрипт) + ассиметричный ключ + привязка например к дате, и смена ключа каждые 15-30 дней, из уже готового набора.
 

si

Administrator
"Что один человек построил, другой завсегда сломать сможет" (С)

небольшая цитата с одного сайта:

Как известно 10 сентября 2003 года компания Macromedia выпустила новую линейку своих продуктов Macromedia Studio MX 2004 и входящих в его состав пакетов Dreamweaver MX 2004, Flash MX 2004, Fireworks MX 2004 а также вышла новая версия Macromedia Contribute 2.0.

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

Дело на этом не остановилось, 2 октября 2003 года события стали принимать новый оборот, варез-группа "CORE" делает удивительную вещь, им удаётся создать консольный генератор лицензий и хотя только 10% сгенерированных ключей можно было "официально" даже почти "легально" активировать т.е получалось что продукты ещё не проданы а их уже используют, хотя при этом надо было затратить некоторое время для проверки сгенерированных ключей.

Но уж совсем невероятные события стали развиваться в эти выходные (5-6 октября) когда три совершенно разных источника (по понятным причинам источники называть не буду) пришли к удивительному открытию. Всё дело в том что при детальном изучении официальной политики лицензирования новых продуктов было выяснено что отдельно корпоративных версий Dreamweaver MX 2004, Fireworks MX 2004, Flash MX 2004, Contribute 2.0 и корпоративного Macromedia StudioMX 2004 не требующих активации НЕТ, есть корпоративные серийные номера, точнее это называется программой MLVK с типом лицензии HVL (High Volume License) т.е вводя такой HVL (High Volume License) серийный номер в так называемые "TRIAL" версии что свободно дают скачать с серверов Macromedia программы не идут в Интернет для активации а сразу регистрируются и начинают работать т.е с такими серийными номерами активация не требуется вовсе.

Отличительной чертой таких HVL (High Volume License) номеров является полное отсутствие его упоминания в "ABOUT" и то что введя один раз этот номер в одну их программ более не требуется вводить в другие, после установки программы будут сразу зарегистрированы без какой либо активации.

Так что всё определяется только серийным номером лицензии который вводится в тот "TRIAL" что дают на серверах Macromedia, вот по этой причине и в коробочных версиях и в корпоративных пакетах идут одни и те же файлы с одинаковыми размерами потому как все файлы везде одинаковы !!!

Вот когда всё это соединилось в одну цепь и все три независимых источника сошлись в одном мнении и появился уникальный генератор HVL (High Volume License) лицензий он позволяет одним выстрелом убить всех зайцев! Этот генератор и выпустила группа "SSG" хотя к решению этой проблемы пришли несколько не связанных между собой сил.

После такого очевидного провала по внедрению системы активации в компании Macromedia последуют репрессии, такого позора не было со времён провала компании ADOBE в попытке заблокировать обновление для нелегальных пользователей Photoshop 7.0, когда проставлением простого пробела в регистре отключалась проверка на легальности.
По-видимому после этого скандального события и в ADOBE надумали внедрить активацию в новом Photoshop 8.0 он же Adobe Photoshop CS. Посмотрим, как долго на этот раз устоит супер-пупер активация в новом Adobe Photoshop CS и возможно ещё ждут большие рождественские сюрпризы компанию Microsoft, кто знает....
 

trent

Developer
Offtopic: Меня как пользователя web технологий это не должно не радовавать :)

Не надо стремиться создать "абсолютную защиту", надо всего лишь сделать стоимость взлома на порядок большей, стоимости лицензии.
 

Skat

Guest
Не надо стремиться создать "абсолютную защиту", надо всего лишь сделать стоимость взлома на порядок большей, стоимости лицензии.
Вопрос: как тогда оценить стоимость взлома ? :)
 

Crazy

Developer
Элементарно: нижний предел равен ежемесчным расходам взломщика, помноженным на число часов, потребных на взлом, и поделенным на 192. :)
 

Doomer

Guest
И второй вопрос: как выцепить доменное имя, так что бы ео нельзя было подделать?!
Все ссылки сделать абсолютными т.е. если юзер подделает домен с vasya.ru на masha.ru то и ссылки у него будут на masha.ru ;)
 

maxnemo

Новичок
Ну дак что решили, мужики?)
Напишите кто-нибудь кратко обобщающе красивый код в двух-трех строчках реальной или хотя бы 50% защиты скрипта от копирования или просмотра с учетом всех подмен и очевидных хитростей?
 

Активист

Активист
Команда форума
Ну дак что решили, мужики?)
Напишите кто-нибудь кратко обобщающе красивый код в двух-трех строчках реальной или хотя бы 50% защиты скрипта от копирования или просмотра с учетом всех подмен и очевидных хитростей?
12 лет прошло, дигеры блин. Сейчас в моде Open Souce. А те, кто до сих пор кодируют исходники - на кол! Не думаю, что ваша идея прямо таки уникальна.
 

maxnemo

Новичок
12 лет прошло, дигеры блин. Сейчас в моде Open Souce. А те, кто до сих пор кодируют исходники - на кол! Не думаю, что ваша идея прямо таки уникальна.
т.е. в моде ничего не блочить ? а как же БД защитить от иньекций и мусора вредных ботов)
 

c0dex

web.dev 2002-...
Команда форума
Партнер клуба
@maxnemo, а какое отношение имеет обфускация/привязка к домену и прочее к защите от SQL инъекций?
 

maxnemo

Новичок
@maxnemo, а какое отношение имеет обфускация/привязка к домену и прочее к защите от SQL инъекций?
Ну дак я понял что ключем с правильным именем домена защищают весь КОД php от копирования, ну и соответственно от возможных подборов/переборов переменных, sql - запросов, ещё чего-нибудь.
Или по идее имена post переменных известны только на стороне сервера и их никак не вычленить?
Может ли хакер узнать имя GET или POST переменной? Может у меня в открытом доступе спец модуль какой-то лежит типа к примеру " http://www.citename.ru/p/parse_clear?id_special_block=toys " , как он узнает что в скрипте существует переменная id_special_block ? Ведь введя toys в строку у get переменной - удалится всё из БД по статьям "toys". Или мне както по другому обернуть это дело?
Это скрипт очистки старых данных, а потом идет скрипт парсинга для новых данных ! И вызывается они другой внешней windows-программой парсером.
Экранирование и прочую лабуду то понятно надо использовать.
Информацию то пусть копируют, тут open sourse понятен. Главное чтобы БД не взломали через php скрипты или через админку на asp.net допустим :) Вот где главная задача защиты.
Или я уже не в те дебри полез?
 
Последнее редактирование:
Сверху