Boo или Pyrex

bialix
Boo или Pyrex

Ни то, ни другое - не python. Ближе был бы ответ “PyPy + c-frontend”, но, насколько я понимаю, он еще в нерабочем состоянии.

Хотя pyrex, надо отдать ему должное, скомпилировал мой “hello world” c pygtk и threading. Жаль, что поддерживается не весь Python (нет вложенных функций, генераторов, ругается на lambda и т.п.).

> Если нужно скрыть код - оптимально использовать язык Boo - развитие питона под net, позволяющий получать быстрые (в 10 раз минимум) exe-шники.

Да ну? Как это в 10 раз быстрые? 0_0
Поверю, что в 2, но чтобы в 10…

Более того, IL элементарно декомпилируется…
Да и даже ковыряние в IL намного проще, чем в том же x86 асме - уровень входа около часа =)))

для IL куда дотфускаторов есть. которые жизнь СИЛЬНО портят :-)

Я так понял, возможности закрытия кода написанного на Python не существует и в принципе не может существовать. А очень жаль!

Интересует абсолютное закрытие или “сильно осложняющее жизнь дешифровщику”?
Абсолютное - невозможно по определению. Любую программу можно взломать - написана она на питоне или плюсах. Только дизассемблер бинарного кода очень утомителен (особенно если код самомодифицируемый, и “распознавать” его приходится совсем вручную. Сейчас - экзотика). И может потребовать неимоверно большого времени (конечного, все же). Вопрос в цене. Если “сломать” программу дороже, чем ее купить - получаем “хорошую” защиту. Но никак не абсолютную.
Практически приемлимое закрытие возможно. Но требуется знать еще и С.
1. Изучаем, как работает py2exe.
2. Особое внимание обращаем на его import hook.
3. Создаем “по подобию” свой импортер модулей, работающий не с открытым zip файлом, а шифрованым (можно даже прилепить его к запускаемой программе, получив единый файл). Способ шифрования выбирается из соотношения цены программы/стоимости взлома. Можно закатать все в RSA 2048 и заставить вводить простыню-ключ при каждом запуске:) А можно просто зашить ключ дешифровки в код - и выдавать каждому клиенту уникальную копию. Много чего можно. Все тот же вопрос цены.
4. Если все еще недостаточно и боимся, что внешние pyd и pythonxx.dll могут быть подменены злоумышленниками, чтобы вытащить таки наш заветный код - статически встраиваем python dll в “запускач”. Имеем возможность (после тривиальной модификации) проверять sha для каждого pyd.
5. Все еще не устраивает - статически вкомпиливаем и эти pyd.
6. Делаем что-нибудь еще - список бесконечен.
7. На середине вышеперечисленного списка опять вспоминаем про главный критерий - стоимость защиты/программы/взлома. Еще вспоминаем про авторизацию через интернет и аппаратные ключи. Если нужно - делаем.
8. Приходим к выводу, что проблема решена, причем до пунктов 4-5-6 не добрались.

Андрей, очень интересный метод.
Было бы хорошо, рассказать об этом создателям py2exe (и py2app). В иделале мы получим api на плюсах, для написания архиватора-шифроватора с возможностью подключать его при сборке. Это решило бы множество проблем и неплохо пробвинуло бы язык в массы тех, кто боится того, что его код сопрут.

Ну уж нет!
Во первых, Питон - открытый язык, и появление “шифраторов” в большом количестве лично мне не очень-то по душе. Из эстетических соображений.
Во вторых создание защиты - процесс творческий и сильно привязанный к защищаемому софту.
В третьих и главных - никто, думаю, не хочет увидеть рядом с шифрующим py2exe такой же свободно распростроняемый и открытый дешифратор? :)

Текущего состояния дел в плане “API на плюсах” более чем достаточно

ZZZ
Было бы хорошо, рассказать об этом создателям py2exe (и py2app). В иделале мы получим api на плюсах, для написания архиватора-шифроватора с возможностью подключать его при сборке. Это решило бы множество проблем и неплохо пробвинуло бы язык в массы тех, кто боится того, что его код сопрут.

Целиком и полностью согласен. Я знаю много людей, которые не изучают Python только потому, что боятся, что их гениальные алгоритмы могут узнать не гуру в ассемблере, а любой продвинуты пользователь. Да и любой заказчик, как только узнает, что ты собираешься реализовать его ТЗ на Python, так сразу отказывается от твоего предложения.

Андрей Светлов
Ну уж нет!
Во первых, Питон - открытый язык, и появление “шифраторов” в большом количестве лично мне не очень-то по душе. Из эстетических соображений.
Во вторых создание защиты - процесс творческий и сильно привязанный к защищаемому софту.
В третьих и главных - никто, думаю, не хочет увидеть рядом с шифрующим в py2exe такой же свободно распростроняемый и открытый дешифратор?

Во-первых, может создание защиты процесс творческий, а вот метод шифрования уже давно стандартизованы.
Во-вторых, все криптографы почти всегда руководствуются правилом, Керкхоффа которое гласит: «стойкость шифра должно определяться только секретностью ключа», смысл здесь в том, чтобы py2exe появился еще один параметр, который указывал на то, что код необходимо шифровать, кто из эстетических соображений не может, пусть не использует этот параметр. А в setup.py, во-первых, указывать метод шифрования, лучше из тех методов, алгоритмы которых известны и проверенны временем, во-вторых, указывать ключ виде случайной последовательности символов.
Поэтому универсальный дешифратор не возможно будет сделать!

Я бы защищал код так:

1. Откомпилировал все в .pyc.
2. Зашифровал и, опционально, объеденил в один архив все эти модули.
3. Написал на нативном языке исполняемый модуль, запускающий наше приложение (подгружающий необходимые модули Python и передающий им управление). В нем же необходимо реализовать дешифровщик наших .pyc'ов (свой импортер модулей).
4. Опционально. Использовать одну из существующих “шифровалок” исполняемых файлов и динамических библиотек, что бы затруднить дизассемблирование и анализ нашего главного исполняемого модуля, динамической библиотеки Python и других нативных модулей Python.

Работы здесь на 3-5 дней. С проектированием, кодированием и тестированием.

p.s. Андрей Светлов выше все правильно сказал про надежность защиты. Могу добавить, что некоторым людям стоит больше внимания уделять не защите своих гениальных алгоритмов, а тестированию, что бы, не дай бог, софтина у конечного пользователя не свалилась в самый неудачный момент.

..bw