Насколько подходит предложенный мной вариант защиты python кода?
==================================================================

 Доброго времени суток!  
  

Опишу ситуацию: имеется простенький python проект (который, на самом деле, без учёта подключенных модулей, представляет из себя один .py файл). Конечный пользователь получает его в виде .exe, собранного через тот же auto-py-to-exe или py2exe (не знаю, что точно буду использовать, пока что этим вопросом не задавался). В ответ на мой вопрос "А сможет ли конечный пользователь разобрать этот .exe и получить исходный код?" гугл ответил: "Да, конечно, ему даже не придется прикладывать особых усилий".  

Итак, я поставил себе задачу: защитить проект от получения исходного кода пользователем, который дальше запихивания куда-нибудь этого .exe не пойдёт.  

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

Отправившись со своим вопросом в Гугл, я нарыл следующие варианты:  
* Обсуфикация кода (например, pyarmor)
* Перевод в байт-код
* Подгрузка закодированного кода с сервера, его декодирование и использование
* cython (не вариант, т.к. основная пачка кода - использование импортируемых модулей)

  
  

В конечном счёте, родилась мысль использовать комбинацию этих идей:  

1) Использовать подгрузку закодированного кода с сервера.  

2) Обсуфицироаать код (pyarmor).  

3) Перевести его в байт-код.  

4) Собрать .exe (auto-py-to-exe, py2exe).  
  

Собственно, у меня к вам следующие вопросы:  

1) Имеет ли смысл такая схема? Какие подводные камни? Возможно, хотите что-то изменить/добавить? Ещё раз: мне будет достаточно даже того, что получение исходников станет хоть сколько-то да затруднительней, нежели я просто соберу из .py файл .exe.  

2) Касательно подгрузки закодированного кода: как это осуществить? Я знаю, что можно загрузить .py файл (например, через urllib или requests), раскодировать его и использовать обычный import. Но хотелось бы делать это без сохранения файла на на компьютере пользователя. То есть: подгружаем содержимое .py файла в закодированном виде с сервера, помещаем его в переменную, декодируем и импортируем. И вот здесь возникает вопрос: как импортировать из переменной? Возможно, я не умею пользоваться Гуглом (в таком случае, заранее приношу извинения).  
  

Заранее спасибо за ответ! 

 Если бы вы понимали принципы работы интерпретатора Python, стала бы очевидна бесполезность этих идей. В частности, компиляция в байткод делается всегда, дополнительных телодвижений совершать не надо. Декомпиляция элементарна. И цикл компиляции/декомпиляции сделает обфускацию бесполезной. Наконец подгрузка закодированного кода более-менее сработала бы, если бы дешифрация выполнялась на уровне интерпретатора. То есть вам для этого придётся написать свой Python. 

 Пишешь веб сервис, и у пользователей не будет доступа к исходникам.  
  

> Обсуфицироаать код

  

Это видимо что-то новенькое?)  
  

UPD:  
  

[Ariurn](http://qna.habr.com/user/Ariurn), 
> Весь код выполняется на устройстве пользователя.

  

В случае веб сервиса у пользователя не будет возможности смотреть исходный код.  
  

Ты же собирался 
> 1) Использовать подгрузку закодированного кода с сервера.

  

Таким образом можно чать функционала вынести на сервер и обращаться к определенным функциям по API, из своей программы запещенной на клиентском устройстве. 

 Лучший вариант - исполнять код на сервере, из-за специфики интерпретатора python всё перечисленное Вами смысла не имеет 

 Тоже попробую пояснить.  

При разработке защиты ПО всегда нужно сопоставлять цену взлома и профит от взлома.  

Арифметика примерно такая.  

Если цена взлома в k раз меньше суммарного профита от взлома (с учетом масштабирования) и сильно не превышает цену повторного написания приложения, то продукт будет взломан и это вопрос времени.  

Это пуассоновский процесс и чем больше k тем быстрее произойдёт вероятный взлом.  
  

Разработчик защищая продукт огребает существенный геморрой с поддержкой, отладкой, диагностикой, обновлением и расширением ПО.  

Цена этого геморроя может оказаться не сильно ниже ущерба от взлома. Тогда такую защиту применять не стоит. Особенно если ваш продукт развивается и растёт, в нём регулярно появляются новые фичи и каждый раз ломать дорого (даже с учетом, что повторный взлом дешевле первого).  
  

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

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

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

Очевидно, что делать это будут не рядовые пользователи, а профессионалы и за деньги. Для защиты от рядовых неквалифицированных пользователей достаточно поксорить байткод=).  
  

В итоге. У вас с вашим списком мер есть шанс построить бастион вокруг сортира. Если сортир с золотыми унитазами, то их всё равно сопрут, а если нет, то нафиг столько геморроя?  
  

Если у вас в коде есть алгоритмические участки, которые можно изолировать и трудено повторить или эмулировать (это должны быть нужные функциональные участки реально постоянно работающего кода), то их можно вынести в крипто-ключ в виде USB-донгла. Это тоже немалый гемор, но порой вполне применимый.  
  

Я не знаю что у вас за продукт, стало бы понятнее при наличии подробностей, но в общем случае хорошо работают и достаточно эффективны (если речь не идёт о "ломе") следующие меры в порядке убывания удобства:  

1. вынос функциональности на сервер в виде API  

2. байткод без исходников  

3. обфускация (лёгкая)  

4. обфускация (тяжелая, с поддержкой полиморфности кода)  
  

Всякие упаковки в экзешники и шифрование - это уже так... от лукавого.  

Просто вынесите ключевой ресурс на сервер и всё. 

> В конечном счёте, родилась мысль использовать комбинацию этих идей:

  

1...  

2...  

...  

5. Перестать бредить и понять, что ничего уникального в Вашем коде нет. Если им будут пользоваться два с половиной человека - им будет пофиг на то, как он защищен, а если он внезапно станет популярным - его все равно сломают. Поэтому не тратьте время.