Comments 20
Воистину красивое решение! А главное полезное!
Получайте первый плюсЪ :)
такой вопрос — а как вы в свою шифрованную функцию заложили логику которая не позволит работать скрипту если функцию вырезать?

если помучатся с вашим скриптом и использовать дезендер, и немного мозгов, то вашу функцию можно раскодить в какой то мере.

Внутри функции генерируются ключи. При их создании используется в том числе md5 исходного файла. Если что-либо поменять (вырезать), то к нам на сервер придет уже не совсем валидный ключ :)
Простите, а у скольки скриптов (программ) в своей жизни вы ломали защиту?
То что сказано вами — абсолютно не проблема, создается второй файл с открытым исходным кодом, а предыдущий — так и лежит себе закодирован. Если же там в явном виде считается вроде md5_file(__FILE__); то это значение просто меняется на нужное. То что защищено зендом тоже не проблема, т.к. тот дезендер что лежит в паблике очень хорошо открывает функции вне классов. Проблема будует только в логических условиях (тут его глючит). Если же заплатить немного денег, так вообще можно получить абсолютно читаемый код.
В целом — лично я сейчас доверяю только ioncubу (но похоже что и это не панацея).
Вообщем, если вам так дорог продукт — пересмотрите его методы защиты. При наличии прямых рук ваша защита будет взломана меньше чем за 1 сутки.
Защита далека от совершенства, согласен. Однако мы слегка отошли от темы поста :)
Что касается Dezender'а. Если уж ломают продукты Microsoft, кудааа нам :)
у микрософта защита преследует несколько иную цель — осложнить взлом лишь на столько, насколько нужно, чтобы большинство пользователей не морочились этим делом, а купили продукт.
Кстати, через Reflection можно определить количество строк скрипта, ну и/или функциональное окружение. И тем самым не позволять вырезание зашифрованного блока. А это позволит исключить применение дезендера.
Расскажите, пожалуйста, в каких задачах бывает «очень необходимо» шифровать код?
Мы в функции генерируем ключи.
Ну а вообще, кто как. Решение не совсем красивое, ну так и задача не совсем часто встречающаяся в жизни, согласен.
Для чего используются эти ключи? Расскажите подробнее, пожалуйста. Это у вас защита от копирования такая что ли?
Есть некое SaaS-решение. К нему подключены провайдеры. Ключи генерируются на стороне провайдеров, используя данные, введенные абонентом провайдера: ip, номера договоров, etc. Затем эти ключи передаются к нам.
У себя мы не можем их генерировать, потому что информация об абоненте является коммерческой тайной провайдера.
В то же время мы должны защититься от читинга с ключами со стороны провайдера. Потому что по количеству ключей он платит деньги.
А почему нельзя использовать открытый алгоритм генерации ключей?
Эм… а не судьба шифрованный код вывести в отдельный файл и тупо его подключать через инклуд?
Да, можно, наверное, было реализовать и так, беря в расчет два значения md5: исходного файла + того, который зашифрован. В этом случае мы бы тоже гарантировали неизменность обоих файлов на стороне чужого сервера. Но сделали так, получилось интересно, решил поделиться находкой :)
грамотный @phpdoc и дать заказчику возможность просмотреть код У ВАС в офисе на ВАШЕМ компьютере (если это очень принципиально и ему хочется знать что нет бекдоров)
Честно говоря, стойкое ощущение что вы пытаетесь не то, чтобы изобрести велосипед, а погнуть существующий.
нампример, можно сделать нужный кусочек через cgi.
а во вторых — почему, действительно, не использовать какие-либо открытые алгоритмы? тогда дело ограничилось бы надежным хранением вашего пароля/ключа/сертификата, не затрагивая сам алгоритм, что логически верно.
защищать сарай бронированной дверью не стоит. дверь и сама упадет и снесет стены.
думайте насчет другой защиты менее технической а более правовой.

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

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

и самое главное — если ваш продукт воруют, есть чем гордиться. говна ведь воровать не станут, концентрируйтесь на продажах и развитии.
Защита кода — тоже много значит. Хотя зацикливаться на этом не нужно.
Only those users with full accounts are able to leave comments. Log in, please.