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

Question

[Ariurn]

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

Опишу ситуацию: имеется простенький 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 файла в закодированном виде с сервера, помещаем его в переменную, декодируем и импортируем. И вот здесь возникает вопрос: как импортировать из переменной? Возможно, я не умею пользоваться Гуглом (в таком случае, заранее приношу извинения).

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

Answer 1

[Сергей Горностаев]

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

Comments

[Ariurn]

То есть, это нисколько не усложнит понимание кода?

[Сергей Горностаев]

Ariurn, ничуточки.

Answer 2

[Андрей Смирнов]

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

Answer 3

[Сергей П]

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

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

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

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

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

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

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

Я не знаю что у вас за продукт, стало бы понятнее при наличии подробностей, но в общем случае хорошо работают и достаточно эффективны (если речь не идёт о "ломе") следующие меры в порядке убывания удобства:
1. вынос функциональности на сервер в виде API
2. байткод без исходников
3. обфускация (лёгкая)
4. обфускация (тяжелая, с поддержкой полиморфности кода)

Всякие упаковки в экзешники и шифрование - это уже так... от лукавого.
Просто вынесите ключевой ресурс на сервер и всё.

Answer 4

[CityCat4]

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

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