Я хочу отправить некоторые компоненты своим клиентам. Причины, по которым я хочу предоставить исходный код, заключаются в следующем: 1) Мой класс темплатирован. Клиент может использовать любой аргумент шаблона, поэтому я не могу предварительно скомпилировать и отправить файл .o. 2) Клиент может использовать разные версии компилятора для gcc, чем мои.
Поэтому я хочу, чтобы он сделал компиляцию в конце. Теперь я не могу раскрыть свой исходный код по очевидным причинам. Максимум, который я могу сделать, это открыть файл .h. Любые идеи, как я могу это достичь. Я думаю о некоторых перехватах в gcc, которые поддерживают дешифрование перед компиляцией и т.д.
Возможно ли это? Короче говоря, я хочу, чтобы он смог скомпилировать этот код, не заглядывая внутрь.
deeJ 13 окт. 2010, в 08:49
Поделиться
Ваш код юридически классифицирован как коммерческая тайна ?
JoshD 13 окт. 2010, в 06:08
Он основан на стандартах открытого исходного кода, но саму реализацию я не хочу, чтобы он видел.
deeJ 13 окт.
Как защитить исходный код PHP, JS, HTML, CSS — обфускация, минимизация, сжатие и шифрование
2010, в 06:10
На основе стандартов с открытым исходным кодом? Это под чем-то вроде GPL? Многие из этих лицензий прямо запрещают именно это.
JoshD 13 окт. 2010, в 06:14
«Теперь я не могу раскрыть свой исходный код по понятным причинам», для меня это не совсем очевидно, поскольку вы планируете отправлять исходный код для компиляции, не могли бы вы уточнить?
shuttle87 13 окт. 2010, в 06:14
deeJ 13 окт. 2010, в 06:23
deeJ 13 окт. 2010, в 06:25
Вы должны принять решение. Либо вы доставляете исходный код, либо нет. Вы не можете доставить исходный код без доставки исходного кода. Весь смысл исходного кода в том, что его можно читать и компилировать. Вы можете доставить его в зашифрованном виде вместе с ключом дешифрования (например, коммерческий DVD), но, по сути, он должен быть читаемым вашим клиентом (или его компилятором).
CB Bailey 13 окт. 2010, в 06:44
Вы можете удалить все комментарии.
Paul R 13 окт. 2010, в 06:49
«по очевидным причинам»: они не очевидны. Можете ли вы уточнить?
Bill 13 окт. 2010, в 14:55
deeJ 19 окт. 2010, в 05:25
Bill 19 окт. 2010, в 17:59
deeJ 20 окт. 2010, в 09:05
Показать ещё 10 комментариев
Поделиться:
7 ответов
Лучший ответ
Контракт = хороший, obfuscation = ungood.
Тем не менее, вы всегда можете сделать своего рода идиому PIMPL, чтобы обслуживать своего клиента с помощью двоичных файлов и просто шаблонных оболочек в заголовках. Идея заключается в том, чтобы использовать «нетипизированную» отдельно скомпилированную реализацию, где шаблонная оболочка просто обеспечивает безопасность типов для клиентского кода. То, как часто делалось, прежде чем компиляторы начали понимать, как оптимизировать шаблоны, то есть избегать разметки кода кода машинного кода, но он лишь обеспечивает некоторую степень защиты от тривиальной кражи копирования и вставки, а не защиты от кого-либо желая углубиться в машинный код.
Но возможно ли тогда усилие больше, чем просто переосмысление вашей функциональности?
Что могут хакеры? В школе такому точно не научат. Профессионалы..
Cheers and hth. — Alf 13 окт. 2010, в 07:35
Поделиться
Ваш постскриптум принадлежит meta.stackoverflow.com
mouviciel 13 окт. 2010, в 07:32
+1 за то, что вы нашли время и написали такой хороший подробный ответ! 🙂
Vinzenz 13 окт.
2010, в 11:12
Вы правы, говоря, что в моем случае усилия по реинжинирингу будут больше, чем переизобретать. При этом, не могли бы вы разработать свое решение, возможно, со ссылкой на пример?
deeJ 19 окт. 2010, в 05:45
Cheers and hth. — Alf 19 окт. 2010, в 07:02
Показать ещё 2 комментария
Просто добавив некоторую терминологию в ответ Alf: Тонкая иконология шаблона — это то, что вы можете посмотреть. Он в основном имитирует функциональность общего. Не путайте статью wikipedia, которая появляется в Google, вам не нужно использовать void* .
Это, конечно, не гарантирует двоичную совместимость. Как обычно, с «родным» С++ вы либо сами компилируете компонент для платформы клиентов, либо развертываете двоичный файл, либо предоставляете им свой код. Разница с чистым общим кодом компонента заключается в том, что вы можете вообще сделать первый.
Paul Michalik 13 окт. 2010, в 07:37
Поделиться
pinichi 13 окт. 2010, в 06:34
Поделиться
Конечно, выбор шаблонов C ++ уже был хорошим началом для запутывания?
JUST MY correct OPINION 13 окт.
2010, в 09:05
Во-первых, если вы собираетесь предоставить исходный код, вам необходимо предоставить исходный код. Разумеется, вы можете зашифровать его, но даже если GCC имеет параметр «decrypt before compile», ему нужно будет расшифровать код, и если GCC может расшифровать код, то и ваш клиент.
То, что вы просите, невозможно. (Если вы найдете способ сделать это, я считаю, что в киноиндустрии может быть многомиллионный контракт для вас. В настоящее время им приходится прибегать к дорогостоящим специальным аппаратным средствам, чтобы люди не могли копировать контент, и это работает только в ограниченной степени)
Что касается ваших «очевидных причин», почему вы не хотите предоставлять исходный код, я не понимаю, почему они очевидны. Что произойдет, если вы предоставили исходный код?
У вас есть два варианта:
- предоставить исходный код целиком или
- скомпилировать все, что можно предварительно скомпилировать в (статическую или динамическую) библиотеку, и предоставить вашему клиенту это, а также файлы заголовков.
jalf 13 окт. 2010, в 07:28
Поделиться
* «это работает только в ограниченной степени» * . где «ограниченная степень» означает «совсем нет», верно?
JUST MY correct OPINION 13 окт. 2010, в 09:08
1) Мой класс темплатирован. Клиент может использовать любой аргумент шаблона, поэтому я не могу предварительно скомпилировать и отправить файл .o.
2) Клиент может использовать разные версии компилятора для gcc, чем мои. Поэтому я хочу, чтобы он сделал компиляцию в конце.
Теперь я не могу раскрыть свой исходный код по очевидным причинам.
Максимум, который я могу сделать, это открыть файл .h. Любые идеи, как я могу это достичь. Я думаю о некоторых перехватах в gcc, которые поддерживают дешифрование перед компиляцией и т.д. Возможно ли это?
Короче говоря, я хочу, чтобы он смог скомпилировать этот код, не заглядывая внутрь.
Рассмотрение 2) выше охватывает A) различия в ABI, так что тот же код, скомпилированный с разными версиями/поставщиками компилятора на одной и той же платформе, несовместим, а также B) различия в системных библиотеках, версиях ядра и т.д., что код может быть в зависимости от. Единственное общее решение заключается в компиляции на конкретных платформах. Либо вы делаете это для всех платформ, либо вы даете им весь исходный код, и они это делают. Это не только реализация заголовков и шаблонов, что и ваши функции вне очереди. Вы можете немного смягчить A), создав стену с более функциональными внешними функциями «C», но вы в основном застреваете, когда дело доходит до B).
Итак, можете ли вы расшифровать во время компиляции? Только если вы отправляете свои собственные взломанные двоичные файлы GCC для них, созданных для их конкретной системы, что, вероятно, является более сложным, чем предоставление различных сборок ваших собственных библиотек (хотя оно может затрагивать проблему с шаблоном/заголовком).
В качестве альтернативы вы можете использовать методы обфускации исходного кода. Это, вероятно, практически — так же хорошо, как и получается. Я не знаю, какие инструменты там, но это подход, который люди преследовали на протяжении десятилетий (хотя я еще не слышал, чтобы кто-нибудь его рекомендовал), поэтому обязательно появятся некоторые зрелые инструменты.
Re templated code — другие люди предложили шаблонный интерфейс для общей реализации C-стиля, отправленной как предварительно скомпилированный объект. Это может быть или не быть практичным (явно рискует ухудшить производительность, и вам нужно захватить набор требуемых типов операций, например, путем создания экземпляра класса, определенного из базового класса абстрактных операций), но в любом случае предварительно скомпилированный объект все еще бежит от B).
Еще одна мысль. клиенты могут взять ваш исходный код, но вряд ли это поймут так же хорошо, как и вы. Даже если они строят больше систем, зависящих от их версии, таким образом они становятся более запертыми и могут иметь больше потребности в ваших услугах в будущем. И, если вы видите, что они не играли честно, вы берете их за это соответственно, когда придет время.
Источник: overcoder.net
Как защитить Python-код от модификации?
25 декабря 2013 г. 
Archy 
Просмотров: 25069 
RSS 
3
Python для начинающих » Общие вопросы 
защитить Python код, код Python, код на python
Многие задаются вопросом — как скрыть исходный код написанных на питоне скриптов, чтобы затем можно было например продавать эти скрипты. В своё время и мы задались этим вопросом, в следствии чего со временем нашли его решение.
Можно было бы просто отдавать клиентам байт-код, который создает python при первом запуске скрипта. Например, запустили test.py, рядом появился test.pyc, его и продаем. Однако в сети есть скрипты, которые восстанавливают из него исходный код с точностью до байта.
Поэтому, чтобы закрыть сорцы скрипта — его надо скомпилировать. Для этого, с помощью расширения cython его можно перевести в Си код, который и скомпилировать обычными инструментами, вроде make.
Рассмотрим решение пошагово:
— Конвертируем python-скрипт в Си:
cython -3 СКРИПТ.py
Получаем СКРИПТ.c — это исходный код python-модуля, который выполняет то же самое что и питон-скрипт.
— Компилируем полученный Си-файл:
gcc -pthread -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/local/include/python3.3m -c СКРИПТ.c -o СКРИПТ.o
Получаем объектный файл СКРИПТ.о
Осталось слинковать его в бинарник. Так как примеры выполняются на линуксе, он будет иметь расширение .so:
На Windows расширение будет .pyd
link = gcc -pthread -shared СКРИПТ.o -o СКРИПТ.so
Таким образом мы имеем новый модуль для питона «СКРИПТ.so», который можно импортировать в код других скриптов:
import СКРИПТ .
Этим способом мы компилируем все наши скрипты для социальных сетей, работы с FTP и имейлами, входящие в состав программного продукта Fream. Ознакомиться с ним вы можете на сайте http://www.freedomscripts.org
На нашем сервере стоит скрипт, который каждую ночь пересобирает все наши программы для Linux, Windows и Freebsd, благодаря чему мы имеем в git-репозитории свежие бинарные версии каждой из них.
Продажа скомпилированных программ позволила реализовать привязку к железу — скрипты связаны с общим сервером авторизации и сообщают ему параметры компьютера, на котором их запускают, проверяя валидность купленной лицензии. Мы не делаем секрета из используемых нами технологий. Пишите нам по контактам на сайте и мы с радостью ответим на ваши вопросы об устройстве наших программ.
Еще записи по теме
- Азино777. Играем в игровой автомат Формула 1 через официальный сайт
- ПМ Казино: игровые автоматы на любой вкус
- ПМ Казино Украина — райское местечко для любителей азартных игр
- Программирование метаклассов на Python
- Почему программисты используют Python?
- Копирование файлов в Python
- Игровой автомат Warlords: Crystals of Power — за незабываемыми победами в Вулкан казино
Источник: python-3.ru
Защита PHP скриптов от копирования — это возможно?
Бывает так, что вам неохота предоставлять исходные коды проектов, которые вы разрабатывали. Для этого можно использовать программы-обфускаторы, о которых недавно шла речь.
А бывает, что вам не так хочется закрыть исходный код, как защитить скрипт от копирования. На мой взгляд, сокрытие исходного кода, в большинстве случаев, не имеет смысла без защиты от копирования. Некоторые обфускаторы, шифрующие код (а не просто коверкающие), имеют возможность лочить скрипт под определенный домен или айпишник. Но, во-первых, мы же не хотим для каждого домена перешифровывать все исходники? Во-вторых, мне удалось разлочить эту защиту одной строкой в начале скрипта:
$_SERVER[‘HTTP_HOST’]=’разрешенный домен’;
Я долго искал в интернете решение для защиты от копирования. На форумах этот вопрос часто обсуждался, в основном, задавали его новички, а опытные (видимо) программисты отвечали «— Ты дурак, кому нужен твой код. Учи матчасть, да и вообще php-скрипты ничего не достойны!». Что ж, подумал я. Наверное, действительно нельзя.
Но подождите, тот же Битрикс (фу) выдает лицензии на отдельные сайты, при этом вы получаете открытый исходный код после покупки лицензии. Что же мешает скопировать его на несколько своих сайтов? Я не знаю, а если вы знаете — скажите мне пожалуйста.
- Скрипт, очевидно, должен быть зашифрован, например Зендом. Но мне понравился Lock It — во-первых, он не требует Зенд Оптимайзера, и, во-вторых — стоит недорого. Но сейчас речь не о том, как шифровать скрипт, а как защитить его от копирования. Поэтому идем дальше, просто будем считать, что исходный код закрыт. Очевидно, что это необходимое условие.
- Я хочу выдавать ключ (я назову его лицензией) на каждый экземпляр скрипта. То есть я хочу каждому человеку отдавать только лицензию, а скрипт пусть валяется во всеобщем доступе.
- Лицензию привязывать к домену, но если у домена есть синонимы — скрипт должен работать и при обращении через них. Главное, чтоб это был один и тот же экземпляр скрипта.
- Никаких коннектов на другой (мой) сервер. Скрипт должен быть самодостаточным.
- Никакого доверия скрипта к серверным переменным или переменным окружения во время проверки лицензии. Их можно легко переопределить.
Решение
1. Выдача лицензии и проверка действительности лицензии скриптом
Я создаю ключ к домену приблизительно таким образом:
$key = md5($domain.$secretword);
Cкрипт проверяет свою лицензию так:
$key == md5($domain.$secretword);
Действительно, некрасиво хранить $secretword в самих скриптах. Поэтому здесь можно использовать шифрование с открытым ключом. При выдаче лицензии я буду подписывать ее своим закрытым ключем, а скрипт, при проверке лицензии, открытым ключем будет проверять действительность лицензии. Но я не нашел в стандартном комплекте PHP никаких функций шифрования с открытым ключом, даже RSA (я слепой?). Если поможете — буду благодарен.
Итак, скрипт проверил правильность лицензии. То есть, подходит ли указанный ключ к указанному домену. Идем дальше.
2. Проверка домена
Как скрипт может проверить, лежит ли он на указанном домене? У нас нет доверия к $_SERVER[‘HTTP_HOST’].
Так же, по условиям — никаких коннектов на другой сервер. Значит, коннектимся сами к себе по предполагаемому домену, и проверяем мы ли там находимся 🙂
А точнее:
1) сохраняем случайное число на сервре (например, во временном файле)2) обращаемся по адресу наш_домен.ру/наш_скрипт.php?action=скажи_число3) проверяем, какое число нам отдают по этому адресу. Если оно соответсвует тому, что мы сохранили, значит, по адресу находимся мы :)0) нулевым пунктом надо добавить отдачу сохраненного числа, если нас вызвали с параметром action=скажи_число
Я немного упростил алгоритм, на самом деле для каждого обращения к скрипту нужно отдельно учитывать эти случайные числа.
Теперь скрипт знает, что лицензия действительна, и что он лежит на соответствующем домене. Основная задача решена!
Вы скажите — wtf, скрипт при каждом обращении будет дергать сам себя? Действительно, жестоко как-то. Поэтому:
3. Временная лицензия
При первом обращении, если проверка прошла успешно, скрипт сохраняет во временном файле временную лицензию.
Временная лицензия представляет собой что-то ноподобие md5(сегодняшняя_дата, домен, секретное слово).
Теперь при каждом запросе мы проверяем только временную лицензию, которая действительна в течение дня. Как только со временной лицензией что-то неладное (поменяли, удалили, прошли сутки) — скрипт опять проверит всё серьезно и сохранит новую временную лицензию.
4. Выполнение скрипта на локальном компьютере без лицензии
Было бы идеально, если бы скрипт не требовал лицензии при запуске на локальном компьютере. Зачем, спрашивается, человеку требовать с меня лицензию, если он просто хочет протестировать скрипт на своем компьютере? Он должен скачать его, и пользоваться. А вот когда он поставит скрипт на сервер, тогда и прийдет ко мне.
Я не знаю как решить эту задачу. У меня пока есть 3 варианта решения, но они мне не нравятся:
1) Если скрипт лежит на домене без точек (типа myscript) — считать, что это виртуальный домен, значит, скорее всего, это локальное тестирование. Недостаток этого метода — умельцы создадут виртуальный домен на своем сервере, а настоящий домен сделают синонимом. Так же, непонятно что делать с доменом localhost.
2) Проверка $_SERVER[«REMOTE_ADDR»]. Проверяем наличие ‘127’ в начале ip-адреса. Недостаток — можно переопределить эту переменную перед выполнением скрипта.
3) Смешно, но можно проверить операционную систему сервера. И разрешить выполнение под Windows. Только не бейте меня, это всего лишь вариант.
Выкладываю пример скрипта для тестирования.
Я с благодарностью жду конструктивных комментариев. Возможно, вы найдете ошибку в этой защите, или подадите сежую идею.
- скрипт
- защита от копирования
Источник: habr.com