doza_and
У зипа слабый очень криптоалгоритм и текст известен - он ведь из ключевых слов состоит - такое ломается на раз

Собственный криптоалгоритм зипа не имеет большого значения, т.к. никто не мешает его зашифровать тем же PGP.
Непонятно только, какой практический смысл у такой поделки - ведь программу нельзя запустить без ключа, а с ключом она не только запускается, но и просматривается.
Если только не сделать бинарный лаунчер, который расшифровывает исходник (ключ зашит в него) и инициализирует интерпретатор (через C API).
Фактически, сложность взлома сведется к сложности декомпиляции этого бинарника.

http://www.mail-archive.com/pyinstaller@googlegroups.com/msg00060.html

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

Конечно я не спец в этом деле. У нас есть кафедра защиты информации, там они развлекаются. Даже запуск программы в электрически неэкранированном помещении уже - нарушение режима.

dimabest eсть только один хороший способ защиты который обычно и срабатывает. Пишите программу так, чтобы она никому не была нужна - тогда ее никто и не украдет. :)

doza_and
Люди шифрующие исходники заслуживают порицания и подвергаются остракизму в сообществе программистов на питоне. Или я не прав? Убедите сначала в обратном.

Приклад: Серверне пропрієтарне програмне забезпечення, яке ставиться на сервери клієнтів. Якщо клієнтам надавати не обфускований код, то вони зможуть супортити (додавати потрібні фічі) самі, а якщо код обфускований то за підтримкою треба буде звертатись до компанії виробника. Відповідно компанія може продавати не тільки програмне забезпечення, але й підтримку до нього.
Якось так.

С рождеством всех!!! Жадность до добра не доведет. Код написали - деньги за него получили и не жадничайте по поводу поддержки. Очевидно потребителям проще у авторов поддержку осуществлять. Они так и делают и с открытыми исходниками (наш опыт). Им это проще чем ковыряться в исходниках. Если потребители смогут сами себе что дописать - отлично! Не будут нас тривиальными задачами беспокоить. Мы же не хотим потратить нашу жизнь на занятия пустяками.
У нас типовой подход - ПО поставляется с исходниками всегда. И нам никто без исходников ничего не сплавит.
Основная мотивация передачи кода без исходников насколько я знаю - безобразный код - авторам стыдно исходники передавать.

doza_and
Жадность до добра не доведет. Код написали - деньги за него получили и не жадничайте по поводу поддержки.

Я не прихильник шифрувати код. Але приходилось працювати в такій компанії. Я не те щоб заохочую шифрувати код але і не проти цього. Є різні моделі ведення бізнесу. Ви говорите “Код написали - деньги за него получили и не жадничайте по поводу поддержки.”. Але ж багато компаній працює навпаки. Код дають безплатно, а гроші беруть за підтримку (mongodb, mysql…) . Хіба це погано?

Плохо когда сделали за пять минут а требуют как за год работы. Если оплата за модификацию разумная никому и в голову не взбредет самому поддержку осуществлять, поэтому и шифровать исходник нет смысла. Авторы лучше знают как проводить модификацию.
Примерно так:
Есть две группы знаний:
Знание кода. - эту часть лучше знает разработчик и ему дешевле осуществлять модификацию поскольку он уже вложил труд в изучение кода (Ccode)
Знание предметной области. - эту часть лучше знает пользователь - он может оперативнее осуществлять поддержку и все равно по другим причинам изучает предметную область (Capp).
Cencoding - Cdecoding стоимость шифровки и расшифровки Cmodification стоимость внесения модификаций
Обычная модель внесения модификаций - разработчику передаются данные из предметной области и оплачивается внесение изменений, или если не требуется глубокое знание кода потребитель вносит их сам поскольку так быстрее.
k - степень знания кода для внесения модификаций.
Суммарные затраты на поддержку Cmodification если делает разработчик и Cmodification+Capp*k если пользователь
С шифровкой:
Если потребитель ломает код: Cencoding + Cdecoding + Cmodification + Capp*k
Если потребитель не ломает код Cencoding + Cmodification
Очевидно, что суммарные трудозатраты для человечества меньше для открытого кода. Это и так очевидно - не надо тратить время на то чтобы мешать жить другим людям. :)

p.s.
Кстати мне кажется у приведенных вами примеров - открытые исходики.

Вопрос в том, можно ли расшифровать .pyc.

certanista
Вопрос в том, можно ли расшифровать .pyc.

certanista

Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> with open("mddd.py", "wb") as f:
...     f.write('if __name__=="__main__":\tprint "!"')
...     f.close()
... 
>>> import mddd
>>> import os
>>> os.system("python mddd.pyc")
!
0
>>>

Формат *.pyc на різних платформах різний. пітон для 32бітної машини не буду виконувати *.pyc який скомпілений на 64-бітній.