Comment protéger le code Python ?

Question

Je développe un logiciel en Python qui sera distribué aux clients de mon employeur. Mon employeur veut limiter l'utilisation du logiciel avec un fichier de licence à durée limitée.

Si nous distribuons les fichiers .py ou même les fichiers .pyc, il sera facile de (décompiler et) supprimer le code qui vérifie le fichier de licence.

Un autre aspect est que mon employeur ne veut pas que le code soit lu par nos clients, craignant que le code soit volé ou du moins les "idées nouvelles".

Existe-t-il un bon moyen de résoudre ce problème ? De préférence avec une solution standard.

Le logiciel fonctionnera sur des systèmes Linux (je ne pense donc pas que py2exe fera l'affaire).

Answer 1

"Y a-t-il une bonne façon de gérer ce problème ?" Non. Rien ne peut être protégé contre l'ingénierie inverse. Même le micrologiciel des lecteurs de DVD a fait l'objet d'une rétro-ingénierie et le logiciel de lecture a été modifié. Clé de cryptage AACS exposé. Et ce, malgré le DMCA qui en fait une infraction pénale.

Comme aucune méthode technique ne peut empêcher vos clients de lire votre code, vous devez appliquer des méthodes commerciales ordinaires.

1. Licences. Contrats. Termes et conditions. Cela fonctionne même lorsque les gens peuvent lire le code. Notez que certains de vos composants basés sur Python peuvent exiger que vous payiez des droits avant de vendre des logiciels utilisant ces composants. De même, certaines licences open-source vous interdisent de dissimuler la source ou l'origine de ce composant.

2. Offrir une valeur significative. Si votre produit est si bon - à un prix difficile à refuser - il n'y a aucune raison de perdre du temps et de l'argent à faire de la rétro-ingénierie. La rétro-ingénierie coûte cher. Rendez votre produit légèrement moins cher.

3. Offrir des mises à jour et des améliorations qui font de la rétroconception une mauvaise idée. Si la prochaine version casse leur ingénierie inverse, il n'y a plus de raison. Cela peut aller jusqu'à l'absurde, mais vous devez proposer de nouvelles fonctionnalités qui rendent la prochaine version plus intéressante que la rétroconception.

4. Proposez la personnalisation à des tarifs si attractifs qu'ils préfèrent vous payer pour construire et prendre en charge les améliorations.

5. Utiliser une clé de licence qui expire. C'est cruel, et cela vous donnera une mauvaise réputation, mais cela fait certainement cesser le fonctionnement de votre logiciel.

6. Offrez-le comme un service web. Le SaaS n'implique aucun téléchargement pour les clients.

Answer 2

Python, étant un langage interprété compilé en code d'octet, est très difficile à verrouiller. Même si vous utilisez un exe-packager comme py2exe la disposition de l'exécutable est bien connue, et les byte-codes Python sont bien compris.

Habituellement, dans des cas comme celui-ci, vous devez faire un compromis. Quelle est l'importance réelle de la protection du code ? Y a-t-il de véritables secrets à l'intérieur (comme une clé pour le cryptage symétrique des virements bancaires), ou êtes-vous simplement paranoïaque ? Choisissez le langage qui vous permet de développer le meilleur produit le plus rapidement possible et soyez réaliste quant à la valeur de vos idées novatrices.

Si vous décidez que vous avez vraiment besoin d'appliquer le contrôle de licence de manière sécurisée, écrivez-le comme une petite extension C afin que le code de contrôle de licence soit très difficile (mais pas impossible !) à désosser, et laissez la majeure partie de votre code en Python.

Answer 3

Python n'est pas l'outil dont vous avez besoin

Vous devez utiliser le bon outil pour faire la bonne chose, et Python n'a pas été conçu pour être obscurci. C'est le contraire ; tout est ouvert ou facile à révéler ou à modifier en Python parce que c'est la philosophie du langage.

Si vous voulez quelque chose que vous ne pouvez pas voir à travers, cherchez un autre outil. Ce n'est pas une mauvaise chose, il est important que plusieurs outils différents existent pour des usages différents.

L'obscurcissement est vraiment difficile

Même les programmes compilés peuvent faire l'objet d'une ingénierie inverse. Ne pensez donc pas que vous pouvez protéger totalement un code. Vous pouvez analyser du PHP obfusqué, casser la clé de cryptage du flash, etc. Les nouvelles versions de Windows sont craquées à chaque fois.

Une obligation légale est un bon moyen d'y parvenir.

Vous ne pouvez pas empêcher quelqu'un d'utiliser votre code à mauvais escient, mais vous pouvez facilement découvrir si quelqu'un le fait. Il s'agit donc d'un problème juridique occasionnel.

La protection du code est surfaite

Aujourd'hui, les modèles économiques tendent à privilégier la vente de services plutôt que de produits. Vous ne pouvez pas copier un service, le pirater ou le voler. Il est peut-être temps d'envisager de suivre le mouvement...

Answer 4

Compilez python et distribuez les binaires !

Une idée judicieuse :

Utilisez Cython , Nuitka , Se débarrasser de la peau ou quelque chose de similaire pour compiler python en code C, puis distribuer votre application sous forme de bibliothèques binaires python (pyd).

De cette façon, il ne reste aucun code (octet) Python et vous avez fait tout ce que l'on peut raisonnablement attendre d'un code normal (c'est-à-dire votre employeur), je pense. (.NET ou Java sont moins sûrs que ce cas, car ce bytecode n'est pas obfusqué et peut relativement facilement être décompilé en source raisonnable).

Cython est de plus en plus compatible avec CPython, donc je pense que cela devrait fonctionner. (En fait, j'y pense pour notre produit ). Nous construisons déjà certaines librairies tierces en tant que pyd/dlls, donc expédier notre propre code python en tant que binaires n'est pas une étape trop importante pour nous).

Voir Ce billet de blog (pas par moi) pour un tutoriel sur la façon de le faire. (thx @hithwen)

Une idée folle :

Vous pourriez probablement faire en sorte que Cython stocke les fichiers C séparément pour chaque module, puis les concaténer tous et les construire avec un inlining important. De cette façon, votre module Python est assez monolithique et difficile à découper avec des outils courants.

Plus que fou :

Vous pourriez être en mesure de construire un seul exécutable si vous pouvez lier (et optimiser avec) le runtime python et toutes les bibliothèques (dlls) de manière statique. De cette façon, il sera difficile d'intercepter les appels vers/depuis python et les bibliothèques du framework que vous utilisez. Cela ne peut pas être fait si vous utilisez du code LGPL.

Answer 5

Je comprends que vous voulez que vos clients utilisent la puissance de Python mais que vous ne voulez pas exposer le code source.

Voici mes suggestions :

(a) Écrire les parties critiques du code sous forme de bibliothèques C ou C++ et utiliser ensuite SIP ou gorgée pour exposer les API C/C++ à l'espace de noms Python.

(b) Utiliser cython au lieu de Python

(c) Dans les deux cas (a) et (b), il devrait être possible de distribuer les bibliothèques sous forme de binaire sous licence avec une interface Python.