¿Cómo puedo evitar que los usuarios lean el código Python?

695

Estoy desarrollando un software en Python que se distribuirá a los clientes de mi empleador. Mi empleador desea limitar el uso del software con un archivo de licencia de tiempo limitado.

Si distribuimos los archivos .py o incluso los archivos .pyc, será fácil (descompilar y) eliminar el código que verifica el archivo de licencia.

Otro aspecto es que mi empleador no quiere que nuestros clientes lean el código, por temor a que el código pueda ser robado o al menos las "ideas novedosas".

¿Existe una buena forma de manejar este problema?

4
  • 26
    py2exe solo almacena los archivos de código de bytes .pyc en un archivo .zip, por lo que definitivamente no es una solución. Aún así, eso puede ser útil cuando se combina con un script de inicio adecuado para que se ejecute en Linux.
    Ber
    4 de noviembre de 2008 a las 12:35
  • dieciséis
    así: stackoverflow.com/questions/15955948/…
    Dog
    25 de abril de 2013 a las 23:43
  • 3
    Esta es la respuesta más completa a su pregunta: wiki.python.org/moin/Asking%20for%20Help/…
    Mike
    17 de diciembre de 2019 a las 6:33
  • Lo único que puede hacer es utilizar las licencias y un backend remoto para completar las operaciones. El código importante se colocará en el backend, por lo que para la perspectiva de la aplicación cliente, el backend actuará como una caja negra. Nadie sabe qué hay detrás de esas llamadas de red, por lo que su código importante estará protegido. Si la licencia expira, las llamadas de red no estarán autenticadas. Esta es la única solución que se me ocurre para mantener oculto el código importante para los usuarios finales. 1 de julio a las 10:03
401

Python, al ser un lenguaje interpretado compilado con código de bytes, es muy difícil de bloquear. Incluso si usa un empaquetador exe como py2exe , el diseño del ejecutable es bien conocido y los códigos de bytes de Python se comprenden bien.

Por lo general, en casos como este, debe hacer una compensación. ¿Qué importancia tiene realmente proteger el código? ¿Hay secretos reales ahí (como una clave para el cifrado simétrico de transferencias bancarias) o simplemente estás siendo paranoico? Elija el lenguaje que le permita desarrollar el mejor producto más rápido y sea realista acerca del valor de sus nuevas ideas.

Si decide que realmente necesita hacer cumplir la verificación de la licencia de forma segura, escríbala como una pequeña extensión de C para que el código de verificación de la licencia pueda ser muy difícil (¡pero no imposible!) De aplicar ingeniería inversa y dejar la mayor parte de su código en Python .

9
  • 175
    Incluso si el código de verificación de licencias fuera difícil de realizar ingeniería inversa porque está escrito en C, ¿no sería relativamente fácil eliminar las llamadas al código de verificación de licencias? 4 de nov. De 2008 a las 12:04
  • 67
    Sí, dependiendo de dónde se realice la verificación de la licencia. Si hay muchas llamadas a la extensión, podría ser difícil de erradicar. O también puede mover alguna otra parte crucial de la aplicación a la verificación de licencia para que eliminar la llamada a la extensión paralice la aplicación. 4 de nov. De 2008 a las 12:10
  • 114
    Realmente, todo este trabajo no se trata de prevenir modificaciones, sino de aumentar su dificultad para que ya no valga la pena. Cualquier cosa puede someterse a ingeniería inversa y modificarse si hay suficientes beneficios. 4 de noviembre de 2008 a las 12:11
  • 13
    @Blair Conrad: No si el código de verificación de licencia también oculta la funcionalidad. P.ejmylicensedfunction(licenseblob liblob, int foo, int bar, std::string bash)
    Brian
    9/08/10 a las 14:26
  • 9
    De hecho, he visto código Python comercial enviado como Python incrustado dentro de una biblioteca C. En lugar de convertir algunas partes del código a C, ocultan todo el código de Python dentro de una capa protectora de C. Luego, si quieren un módulo que Python pueda importar, escriben una extensión delgada de Python encima de C. El código abierto es una forma de vida mucho más fácil. 4 de febrero de 2014 a las 3:38
473

"¿Hay una buena manera de manejar este problema?" No. Nada puede protegerse contra la ingeniería inversa. Incluso el firmware de las máquinas de DVD se ha sometido a ingeniería inversa y se ha expuesto la clave de cifrado AACS . Y eso a pesar de que la DMCA lo convierte en un delito.

Dado que ningún método técnico puede impedir que sus clientes lean su código, debe aplicar métodos comerciales habituales.

  1. Licencias. Contratos. Términos y condiciones. Esto todavía funciona incluso cuando la gente puede leer el código. Tenga en cuenta que algunos de sus componentes basados ​​en Python pueden requerir que pague tarifas antes de vender software utilizando esos componentes. Además, algunas licencias de código abierto le prohíben ocultar la fuente o los orígenes de ese componente.

  2. Ofrezca un valor significativo. Si sus cosas son tan buenas, a un precio difícil de rechazar, no hay ningún incentivo para perder tiempo y dinero en ingeniería inversa. La ingeniería inversa es cara. Haga que su producto sea un poco menos costoso.

  3. Ofrezca actualizaciones y mejoras que hagan que cualquier ingeniería inversa sea una mala idea. Cuando el próximo lanzamiento rompa su ingeniería inversa, no tiene sentido. Esto puede llevarse a extremos absurdos, pero debe ofrecer nuevas características que hagan que la próxima versión sea más valiosa que la ingeniería inversa.

  4. Ofrezca personalización a tarifas tan atractivas que preferirían pagarle para crear y respaldar las mejoras.

  5. Utilice una clave de licencia que caduque. Esto es cruel y le dará una mala reputación, pero ciertamente hará que su software deje de funcionar.

  6. Ofrecerlo como servicio web. SaaS no implica descargas para los clientes.

4
  • 8
    El punto 2 es aún más importante. Si es más barato comprar que la ingeniería inversa, además de las actualizaciones anuales, nadie lo intentará e incluso si lo hace, nadie pagará a un pirata informático en lugar del proveedor del software.
    m3nda
    1 de septiembre de 2015 a las 20:42
  • Eso es cierto. La ingeniería inversa es factible pero costosa en la mayoría de las situaciones. @ S.Lott, creo que el punto 6 tiene más importancia según la pregunta. Si el código fuente realmente necesita ser protegido, entonces debe estar alejado del usuario final.
    Delali
    10/10/2017 a las 11:56
  • 17
    Pregunta: "¿hay una buena manera de proteger a mi familia ya mí mismo de ser asesinados por intrusos mientras dormimos?" Internet: "No. Se puede acceder a cualquiera, y ninguna vivienda es 100 por ciento impenetrable. Una familia humana mortal es la herramienta incorrecta para el trabajo". 29/03/19 a las 4:05
  • 1
    El punto 5 no se podría aplicar con el mismo supuesto de que puede someterse a ingeniería inversa y agrietarse. 4/11/19 a las 16:29
317

Python no es la herramienta que necesitas

Debe usar la herramienta correcta para hacer lo correcto, y Python no fue diseñado para ofuscarse. Es todo lo contrario; todo es abierto o fácil de revelar o modificar en Python porque esa es la filosofía del lenguaje.

Si desea algo que no pueda ver a través, busque otra herramienta. Esto no es malo, es importante que existan varias herramientas diferentes para diferentes usos.

La ofuscación es muy difícil

Incluso los programas compilados pueden someterse a ingeniería inversa, así que no crea que puede proteger completamente cualquier código. Puede analizar PHP ofuscado, romper la clave de cifrado flash, etc. Las versiones más nuevas de Windows se descifran cada vez.

Tener un requisito legal es un buen camino a seguir

No puede evitar que alguien haga un mal uso de su código, pero puede descubrir fácilmente si alguien lo hace. Por lo tanto, es solo un problema legal casual.

La protección del código está sobrevalorada

Hoy en día, los modelos de negocio tienden a apostar por la venta de servicios en lugar de productos. No se puede copiar un servicio, piratearlo ni robarlo. Tal vez es hora de considerar ir con la corriente ...

7
  • 23
    Python no es la herramienta que necesita. Malbolge lo es. :) 4 de agosto de 2011 a las 14:00
  • 9
    ¿Buena respuesta, pero "cuestión legal casual"? ¿En serio? ¿Dónde vive usted que usted tiene cualquier problemas legales que son casuales? 16 de septiembre de 2013 a las 13:40
  • 1
    Creo que, si tenemos una frecuencia (la frecuencia con la que se piratea el costoso código ofuscado), podríamos decir sobre la viabilidad de usar Python y código ofuscado. 18/02/15 a las 10:28
  • 1
    ¿Cómo demonios "descubrirías fácilmente si alguien lo hace"?
    Make42
    28/01/20 a las 15:06
  • 1
    'La protección del código está sobrevalorada', ¿en qué estás pensando en los servicios en las instalaciones? 18 de ene a las 13:31
161

¡Compila Python y distribuye binarios!

Idea sensata:

Use Cython , Nuitka , Shed Skin o algo similar para compilar Python en código C, luego distribuya su aplicación como bibliotecas binarias de Python (pyd) en su lugar.

De esa manera, no queda ningún código Python (byte) y creo que ha realizado una cantidad razonable de oscurecimiento que cualquiera (es decir, su empleador) podría esperar del código normal. (.NET o Java son menos seguros que este caso, ya que ese código de bytes no está ofuscado y se puede descompilar con relativa facilidad en una fuente razonable).

Cython es cada vez más compatible con CPython, así que creo que debería funcionar. (De hecho, estoy considerando esto para nuestro producto. Ya estamos construyendo algunas librerías de terceros como pyd / dlls, por lo que enviar nuestro propio código Python como binarios no es un gran paso para nosotros).

Vea esta publicación de blog (no por mí) para obtener un tutorial sobre cómo hacerlo. (gracias @hithwen)

Idea loca:

Probablemente podría hacer que Cython almacene los archivos C por separado para cada módulo, luego simplemente concatenarlos todos y compilarlos con una fuerte inserción. De esa manera, su módulo de Python es bastante monolítico y difícil de manipular con herramientas comunes.

Más allá de la locura:

Es posible que pueda crear un solo ejecutable si puede vincular (y optimizar) el tiempo de ejecución de Python y todas las bibliotecas (dlls) estáticamente. De esa manera, seguramente será difícil interceptar llamadas hacia / desde python y cualquier biblioteca de marco que use. Sin embargo, esto no se puede hacer si está utilizando el código LGPL.

5
  • ¿La compilación con cython funcionaría con una aplicación Python 3.4 Django, o podría funcionar sin una gran cantidad de esfuerzo?
    Daniel
    15 de septiembre de 2015 a las 4:35
  • @Daniel: No estoy seguro. No he probado Django. No dude en publicar una nueva pregunta al respecto.
    Macke
    4/11/15 a las 10:11
  • 1
  • 6
    @mlvljr FWIW, en mi humilde opinión, compilar binarios es una buena compensación entre vender todos sus secretos y tratar de protegerse contra la ingeniería inversa de clase NSA. Esp si tienes una gran base de código Python y razones para ser paranoico. ;)
    Macke
    8 de enero de 2016 a las 8:18
  • 2
    La POST de hithwen no es válida ahora. 5 de junio de 2018 a las 12:45
60

Entiendo que desea que sus clientes usen el poder de Python pero no quiere exponer el código fuente.

Aquí están mis sugerencias:

(a) Escriba las partes críticas del código como bibliotecas C o C ++ y luego use SIP o swig para exponer las API de C / C ++ al espacio de nombres de Python.

(b) Utilice cython en lugar de Python

(c) Tanto en (a) como (b), debería ser posible distribuir las bibliotecas como binarios con licencia con una interfaz de Python.

2
40

¿Has echado un vistazo a pyminifier ? Minifica, ofusca y comprime el código Python. El código de ejemplo parece bastante desagradable para la ingeniería inversa casual.

$ pyminifier --nonlatin --replacement-length=50 /tmp/tumult.py
#!/usr/bin/env python3
ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲמּ=ImportError
ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲ燱=print
ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲ巡=False
ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲ澨=object
try:
 import demiurgic
except ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲמּ:
 ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲ燱("Warning: You're not demiurgic. Actually, I think that's normal.")
try:
 import mystificate
except ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲמּ:
 ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲ燱("Warning: Dark voodoo may be unreliable.")
ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲﺬ=ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲ巡
class ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲ𐦚(ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲ澨):
 def __init__(self,*args,**kwargs):
  pass
 def ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲ클(self,dactyl):
  ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲ퐐=demiurgic.palpitation(dactyl)
  ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲ𠛲=mystificate.dark_voodoo(ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲ퐐)
  return ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲ𠛲
 def ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲ𐠯(self,whatever):
  ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲ燱(whatever)
if __name__=="__main__":
 ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲ燱("Forming...")
 ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲﺃ=ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲ𐦚("epicaricacy","perseverate")
 ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲﺃ.ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲ𐠯("Codswallop")
# Created by pyminifier (https://github.com/liftoff/pyminifier)
7
  • 9
    Lo bueno de esto es desmoralizar a cualquiera que intente decodificar la funcionalidad. Combine eso con Cython y algunas criptas adicionales sobre módulos o llamadas de Internet, y probablemente obtenga un premio.
    m3nda
    1 de septiembre de 2015 a las 20:28
  • 1
    Lo único que logró este paquete es engañar al 'ofuscador' que el código está ofuscado. 3 de mayo de 2019 a las 11:24
  • 2
    Esta biblioteca no parece mantenerse y me da errores de sangría. Estoy usando Python 3.7
    P.V.
    9/06/20 a las 14:50
  • 2
    sí. Puedo confirmar que Pyminifier está muerto 14/06/20 a las 23:15
  • 3
    pyminifier puede estar muerto, pero encontré que el último impulso de este repositorio fue en mayo de 2020 ... (cómo lo encontré: techgaun.github.io/active-forks/index.html#liftoff/… fork parece agregar correcciones de otras personas ( probablemente mirando las solicitudes de extracción abiertas en el repositorio original) ... 22/06/20 a las 19:59
34

¿Su empleador es consciente de que puede "robar" cualquier idea que otras personas obtengan de su código? Quiero decir, si ellos pueden leer tu trabajo, tú también puedes leer el de ellos. Quizás mirar cómo puede beneficiarse de la situación produciría un mejor retorno de su inversión que temer cuánto podría perder.

[EDITAR] Respuesta al comentario de Nick:

Nada ganado y nada perdido. El cliente tiene lo que quiere (y lo pagó desde que él mismo hizo el cambio). Dado que no publica el cambio, es como si no hubiera sucedido para todos los demás.

Ahora, si el cliente vende el software, tiene que cambiar el aviso de derechos de autor (que es ilegal, por lo que puede demandar y ganar -> caso simple).

Si no cambian el aviso de derechos de autor, los clientes de segundo nivel notarán que el software proviene de usted original y se preguntarán qué está pasando. Lo más probable es que se pongan en contacto contigo para que aprendas sobre la reventa de tu trabajo.

Nuevamente tenemos dos casos: el cliente original vendió solo unas pocas copias. Eso significa que de todos modos no ganaron mucho dinero, así que para qué molestarse. O vendieron en volumen. Eso significa mejores oportunidades para que usted aprenda sobre lo que hacen y haga algo al respecto.

Pero al final, la mayoría de las empresas tratan de cumplir con la ley (una vez que su reputación se arruina, es mucho más difícil hacer negocios). Por lo tanto, no te robarán el trabajo, sino que trabajarán contigo para mejorarlo. Entonces, si incluye la fuente (con una licencia que lo protege de una simple reventa), es probable que simplemente rechacen los cambios que hicieron, ya que eso garantizará que el cambio esté en la próxima versión y no tengan que mantenerlo. . Eso es beneficioso para todos: obtienes cambios y ellos mismos pueden hacer el cambio si realmente lo necesitan desesperadamente, incluso si no estás dispuesto a incluirlo en el lanzamiento oficial.

18
  • ¿Qué pasa si lanzan software a los clientes y el cliente lo modifica internamente sin volver a publicarlo?
    Nick T
    9/08/10 a las 13:36
  • 8
    +1 por robar ideas. ¿Por qué limitar su poder de servicio al cliente a sus soluciones internas, cuando puede ver cómo otros mejoran su solución y, en consecuencia, mejoran su propio producto? "Si tienes una manzana y yo tengo una manzana e intercambiamos estas manzanas, tú y yo todavía tendremos una manzana. Pero si tú tienes una idea y yo tengo una idea e intercambiamos estas ideas, entonces cada uno de nosotros tendrá dos ideas ".
    Jordan
    30 de abril de 2013 a las 5:04
  • 1
    @Skandix ¿Cómo funcionaría eso exactamente? Subir su trabajo a Internet no le perjudica. Empezaría a perjudicarle si mucha gente lo encontrase Y esas personas estarían pagando a los clientes en su lugar. El robo de códigos es un mito. "Mi conocimiento es gratis, mi tiempo es caro" (no estoy seguro de quién dijo eso). 17 de mayo de 2018 a las 7:33
  • 1
    ¿Cómo podría robar algo a cambio? Simplemente ponen el código en su producto y no le dicen a nadie cómo funciona y simplemente lo venden. ¿Cómo iba a descubrir que usaron mi código en primer lugar?
    Make42
    28/01/20 a las 15:12
  • 1
    @AaronDigulla: No creo que esto se aplique. Las otras personas a las que vende el ladrón podrían haberse convertido en mis clientes, pero yo nunca lo sabría. Si alguien A le da a B algo de dinero para que me lo entregue sin que yo lo sepa. B roba el dinero guardándolo. Puede que no esté triste, porque nunca lo supe, pero todavía tengo menos dinero si B hubiera cumplido la promesa.
    Make42
    1 feb.20 a las 10:46
26

Utilice Cython . Compilará sus módulos en archivos C de alto rendimiento, que luego se pueden compilar en bibliotecas binarias nativas. ¡Esto es básicamente irreversible, en comparación con el código de bytes .pyc!

Escribí un artículo detallado sobre cómo configurar Cython para un proyecto de Python, échale un vistazo:

Protección de fuentes de Python con Cython

24

No confíe en la ofuscación. Como ha concluido correctamente, ofrece una protección muy limitada. ACTUALIZACIÓN: Aquí hay un enlace al documento que realizó ingeniería inversa en el código de Python ofuscado en Dropbox. El enfoque: la reasignación de códigos de operación es una buena barrera, pero claramente se puede derrotar.

En cambio, como muchos carteles han mencionado, hazlo:

  • No vale la pena dedicar tiempo a la ingeniería inversa (su software es tan bueno que tiene sentido pagar)
  • Haga que firmen un contrato y hagan una auditoría de licencias si es posible.

Alternativamente, como lo hace el increíble IDE de Python WingIDE: Regala el código . Así es, regale el código y haga que la gente regrese para actualizaciones y soporte.

3
  • 1
    Como esta idea extrema. Lo obtiene de una manera enorme y una participación de mercado masiva, entonces tiene una base de clientes muy grande para soporte y complementos. También he estado lidiando con esta pregunta y todas las respuestas de "licencias" son básicamente tontas porque no protege contra la copia generalizada, pero no le brinda ninguna ventaja de participación de mercado. 16/04/13 a las 14:43
  • Pero, las actualizaciones también son solo obsequios ... entonces, ¿cómo cobrarían por eso? ¿No sería solo el apoyo?
    Make42
    1 feb.20 a las 10:48
  • Respecto al modelo de negocio de WingIDE: El soporte es un servicio, el software un producto. Los productos escalan, el servicio no. El soporte solo es un buen modelo de negocio si no hay otro modelo de negocio, es decir, si nadie compra su producto (por el motivo que sea), usted regala el producto, de modo que tenga una base de clientes que al menos compre su servicio.
    Make42
    1 feb.20 a las 10:50
20

El envío de archivos .pyc tiene sus problemas: no son compatibles con ninguna otra versión de Python que no sea la versión de Python con la que fueron creados, lo que significa que debe saber qué versión de Python se está ejecutando en los sistemas en los que se ejecutará el producto. Ese es un factor muy limitante.

2
  • 3
    Sí, pero no si distribuye esa versión exacta de Python con su código ofuscado.
    Alex
    21 de mayo de 20 a las 6:30 p.m.
  • autopy2exe compila y envía una instalación de Python portátil con el distribuible en un único formato de archivo <application.exe>. Nota: también compatible con Linux. Puede ser complejo y un punto de dolor administrar las instalaciones de Python en las computadoras cliente. 13 de agosto a las 1:22
18

En algunas circunstancias, puede ser posible mover (todo, o al menos una parte clave) del software a un servicio web alojado en su organización.

De esa manera, las verificaciones de licencias se pueden realizar en la seguridad de su propia sala de servidores.

4
  • +1 (de vuelta a 0): parece la única solución verdadera al problema, asumiendo que tal enfoque sea práctico para el entorno. 21/07/10 a las 17:41
  • 11
    Tenga en cuenta que si su servidor web de licencias deja de funcionar o el acceso a Internet de los clientes no funciona, su cliente no estará contento de no poder administrar su negocio debido a la pérdida de acceso a las verificaciones de licencias. 3 de julio de 2012 a las 16:45
  • 2
    @DevPlayer Hay soluciones para esto. Puede implementar un mecanismo de clave local que permita el acceso temporal cuando el software no puede alcanzar el servidor de licencias remoto.
    Jeffrey
    2 mar 14 a las 17:49
  • 2
    @Jeffrey: Eso te lleva de vuelta a donde empezaste: cómo proteger ese código. Para estar más seguro, debe poner algunas de las funciones clave en su propio servidor, por lo que reemplazarlo implicaría un esfuerzo sustancial (en ese momento, ¿por qué no simplemente iniciar un competidor de código abierto?) 10/04/2015 a las 14:31
16

Aunque no existe una solución perfecta, se puede hacer lo siguiente:

  1. Mueva alguna pieza crítica del código de inicio a una biblioteca nativa.
  2. Haga cumplir la verificación de la licencia en la biblioteca nativa.

Si se eliminara la llamada al código nativo, el programa no se iniciaría de todos modos. Si no se elimina, se aplicará la licencia.

Aunque esta no es una solución multiplataforma o de Python puro, funcionará.

2
  • 3
    El enfoque de la biblioteca nativa hace que sea mucho más fácil para alguien forzar mediante programación su sistema de claves de licencia, ya que pueden usar su propio código y API para validar sus licencias. 24 de noviembre de 2008 a las 1:15
  • 9
    ¿Entonces? Use RSA para firmar su licencia y déjeles forzar su clave privada, digamos que consta de 1024 bits. Es posible, pero lleva mucho tiempo ... y, por tanto, dinero.
    Abgan
    29 de diciembre de 2008 a las 2:18
13

Me sorprendió no ver pyconcrete en ninguna respuesta. ¿Quizás porque es más nuevo que la pregunta?

Podría ser exactamente lo que necesitas (ed).

En lugar de ofuscar el código, lo encripta y lo desencripta en el momento de la carga.

Desde la página de pypi :

Protect python script work flow

  • your_script.py import pyconcrete
  • pyconcrete will hook import module
  • when your script do import MODULE, pyconcrete import hook will try to find MODULE.pye first and then decrypt MODULE.pye via _pyconcrete.pyd and execute decrypted data (as .pyc content)
  • encrypt & decrypt secret key record in _pyconcrete.pyd (like DLL or SO) the secret key would be hide in binary code, can’t see it directly in HEX view
13

Creo que hay un método más para proteger su código Python; parte del método de ofuscación. Creo que hubo un juego como Mount and Blade o algo que cambió y volvió a compilar su propio intérprete de Python (el intérprete original que creo que es de código abierto) y simplemente cambió los códigos OP en la tabla de códigos OP para que sean diferentes al estándar Python OP códigos.

Entonces, la fuente de Python no está modificada, pero las extensiones de archivo de los archivos * .pyc son diferentes y los códigos de operación no coinciden con el intérprete público de python.exe. Si marcó los archivos de datos de los juegos, todos los datos estaban en formato de fuente Python.

Se pueden hacer todo tipo de trucos desagradables para meterse con hackers inmaduros de esta manera. Detener a un grupo de piratas informáticos sin experiencia es fácil. Son los piratas informáticos profesionales a los que probablemente no vencerás. Pero imagino que la mayoría de las empresas no mantienen a los piratas informáticos profesionales en el personal por mucho tiempo (probablemente porque las cosas se piratean). Pero los piratas informáticos inmaduros están por todas partes (léase como personal de TI curioso).

Por ejemplo, en un intérprete modificado, podría permitirle que verifique ciertos comentarios o cadenas de documentos en su fuente. Podría tener códigos OP especiales para tales líneas de código. Por ejemplo:

OP 234 es para la línea fuente "# Copyright I escribí esto" o compila esa línea en códigos de operación que sean equivalentes a "if False:" si falta "# Copyright". Básicamente, deshabilitar todo un bloque de código por lo que parece ser una extraña razón.

Un caso de uso en el que volver a compilar un intérprete modificado puede ser factible es cuando no escribió la aplicación, la aplicación es grande, pero se le paga para protegerla, como cuando es un administrador de servidor dedicado para una aplicación financiera.

Me parece un poco contradictorio dejar la fuente o los códigos de operación abiertos para los ojos, pero usar SSL para el tráfico de red. SSL tampoco es 100% seguro. Pero se usa para evitar que la MAYORÍA de los ojos lo lean. Un poquito de precaución es sensato.

Además, si suficientes personas consideran que la fuente de Python y los códigos de operación son demasiado visibles, es probable que alguien eventualmente desarrolle al menos una herramienta de protección simple para ellos. Así que cuanta más gente pregunte "cómo proteger la aplicación Python" solo promueve ese desarrollo.

12

La única forma confiable de proteger el código es ejecutarlo en un servidor que usted controla y proporcionar a sus clientes un cliente que interactúe con ese servidor.

10

Dependiendo de quién sea el cliente, un mecanismo de protección simple, combinado con un acuerdo de licencia sensato, será mucho más efectivo que cualquier sistema complejo de licencias / cifrado / ofuscación.

La mejor solución sería vender el código como un servicio, digamos hospedando el servicio u ofreciendo soporte, aunque eso no siempre es práctico.

Enviar el código como .pycarchivos evitará que su protección sea frustrada por unos pocos #segundos, pero es una protección antipiratería poco efectiva (como si existiera tal tecnología), y al final del día, no debería lograr nada que un acuerdo de licencia decente con la empresa.

Concéntrese en hacer que su código sea lo más agradable posible de usar: tener clientes satisfechos hará que su empresa gane mucho más dinero que la prevención de la piratería teórica.

0
8

Otro intento de hacer que su código sea más difícil de robar es usar jython y luego usar java ofuscator .

Esto debería funcionar bastante bien, ya que jythonc traduce el código Python a Java y luego Java se compila en Bytecode. Así que una vez que ofusques las clases, será muy difícil entender qué sucede después de la descompilación, sin mencionar la recuperación del código real.

El único problema con jython es que no puede usar módulos de Python escritos en c.

6

¿Qué hay de firmar su código con esquemas de cifrado estándar mediante hash y firma de archivos importantes y verificándolos con métodos de clave pública?

De esta forma se puede emitir un archivo de licencia con una clave pública para cada cliente.

Además, puede usar un ofuscador de Python como este (solo busqué en Google).

4
  • 1
    +1 por la firma; -1 para el ofuscador. Al menos puede evitar que se cambie el código. 4 de nov. De 2008 a las 13:07
  • 2
    La firma no funciona en este contexto. Siempre es posible omitir el cargador de verificación de firmas. Lo primero que necesita para una protección de software útil es un mecanismo de arranque opaco. No es algo que Python facilite.
    ddaa
    4 de nov. De 2008 a las 13:41
  • Sí, bootstrap en no python. 4 de nov. De 2008 a las 16:27
  • O valide la licencia no solo al inicio, sino en varios otros lugares. Se puede implementar fácilmente y puede aumentar considerablemente el tiempo de derivación.
    Abgan
    29 de diciembre de 2008 a las 2:21
6

Debería echar un vistazo a cómo lo hacen los chicos de getdropbox.com para su software cliente, incluido Linux. Es bastante complicado de descifrar y requiere un desmontaje bastante creativo para superar los mecanismos de protección.

2
  • 8
    pero el hecho de que se haya superado significó que fracasaron; la conclusión es que no lo intentes, busca protección legal.
    Chii
    17 de nov. De 2008 a las 9:52
  • ¿Existe alguna información publicada sobre cómo conseguir pasar estos mecanismos de protección?
    Mitar
    20/11/12 a las 2:33
6

Lo mejor que puede hacer con Python es oscurecer las cosas.

  • Quite todas las cadenas de documentación
  • Distribuya solo los archivos compilados .pyc.
  • congelarlo
  • Oculte sus constantes dentro de una clase / módulo para que la ayuda (configuración) no muestre todo

Es posible que pueda agregar algo de oscuridad adicional cifrando parte de él y descifrándolo sobre la marcha y pasándolo a eval (). Pero no importa lo que hagas, alguien puede romperlo.

Nada de esto evitará que un atacante determinado desmonte el código de bytes o busque en su api con ayuda, dir, etc.

5

La idea de tener una licencia de tiempo limitado y verificarla en el programa instalado localmente no funcionará. Incluso con una ofuscación perfecta, se puede eliminar la verificación de licencia. Sin embargo, si verifica la licencia en el sistema remoto y ejecuta una parte importante del programa en su sistema remoto cerrado, podrá proteger su IP.

Para evitar que los competidores usen el código fuente como propio o escriban su versión inspirada del mismo código, una forma de protegerse es agregar firmas a la lógica de su programa (algunos secretos para poder demostrar que el código le fue robado) y ofuscar el código fuente de python, por lo que es difícil de leer y utilizar.

Una buena ofuscación agrega básicamente la misma protección a su código que compilarlo en ejecutable (y eliminar binario). Averiguar cómo funciona el código complejo y ofuscado puede ser incluso más difícil que escribir tu propia implementación.

Esto no ayudará a prevenir la piratería de su programa. Incluso con el código de ofuscación, las cosas de la licencia se descifrarán y el programa puede modificarse para tener un comportamiento ligeramente diferente (de la misma manera que compilar código en binario no ayuda a proteger los programas nativos).

Además de la ofuscación de símbolos, podría ser una buena idea deshacer la refactorización del código, lo que hace que todo sea aún más confuso si, por ejemplo, se llaman puntos de gráficos a muchos lugares diferentes, incluso si en realidad esos lugares diferentes eventualmente hacen lo mismo.

Firma lógica dentro del código ofuscado (por ejemplo, puede crear una tabla de valores que son utilizados por la lógica del programa, pero también se utilizan como firma), que se puede utilizar para determinar que el código se originó en usted. Si alguien decide usar su módulo de código ofuscado como parte de su propio producto (incluso después de volver a ofuscarlo para que parezca diferente), puede mostrar que el código ha sido robado con su firma secreta.

4

He analizado la protección de software en general para mis propios proyectos y la filosofía general es que la protección completa es imposible. Lo único que puede esperar lograr es agregar protección a un nivel que a su cliente le costaría más evitarlo que comprar otra licencia.

Dicho esto, solo estaba revisando google para ver si había alguna obstrucción de Python y no aparecía mucho de nada. En una solución .Net, la obstrucción sería un primer enfoque a su problema en una plataforma Windows, pero no estoy seguro de si alguien tiene soluciones en Linux que funcionen con Mono.

Lo siguiente sería escribir su código en un lenguaje compilado, o si realmente quiere ir hasta el final, entonces en ensamblador. Un ejecutable eliminado sería mucho más difícil de descompilar que un lenguaje interpretado.

Todo se reduce a compensaciones. Por un lado, tiene la facilidad de desarrollo de software en Python, en el que también es muy difícil ocultar secretos. En el otro extremo, tiene un software escrito en ensamblador que es mucho más difícil de escribir, pero es mucho más fácil ocultar secretos.

Su jefe tiene que elegir un punto en algún lugar de ese continuo que respalde sus requisitos. Y luego tiene que darte las herramientas y el tiempo para que puedas construir lo que él quiere. Sin embargo, apuesto a que se opondrá a los costos reales de desarrollo frente a las posibles pérdidas monetarias.

4

Larga historia corta:

  1. Cifre su código fuente
  2. Escriba su propio cargador de módulos de Python para descifrar su código al importar
  3. Implementar el cargador de módulos en C / C ++
  4. Puede agregar más funciones al cargador de módulos, por ejemplo, anti-depurador, control de licencias, enlace de huellas dactilares de hardware, etc.

Para obtener más detalles, mire esta respuesta .

Si está interesado en el tema, este proyecto lo ayudará: pyprotect .

3

Es posible tener el código de bytes py2exe en un recurso encriptado para un lanzador C que lo carga y lo ejecuta en la memoria. Algunas ideas aquí y aquí .

Algunos también han pensado en un programa de modificación automática para encarecer la ingeniería inversa.

También puede encontrar tutoriales para prevenir depuradores , hacer que el desensamblador falle, establecer puntos de interrupción del depurador falsos y proteger su código con sumas de verificación. Busque ["código cifrado" ejecutar "en memoria"] para obtener más enlaces.

Pero como ya han dicho otros, si su código vale la pena, los ingenieros inversos tendrán éxito al final.

2

Utilice la misma forma para proteger el archivo binario de c / c ++, es decir, ofuscar el cuerpo de cada función en un archivo binario ejecutable o de biblioteca, insertar una instrucción "saltar" al comienzo de cada entrada de función, saltar a la función especial para restaurar el código ofuscado. El código de bytes es un código binario de la secuencia de comandos de Python, por lo que

  • Primero compile el script de Python para codificar el objeto
  • Luego, itere cada objeto de código, ofusque co_code de cada objeto de código de la siguiente manera
    0   JUMP_ABSOLUTE            n = 3 + len(bytecode)

    3
    ...
    ... Here it's obfuscated bytecode
    ...

    n   LOAD_GLOBAL              ? (__pyarmor__)
    n+3 CALL_FUNCTION            0
    n+6 POP_TOP
    n+7 JUMP_ABSOLUTE            0
  • Guarde el objeto de código ofuscado como archivo .pyc o .pyo

Esos archivos ofuscados (.pyc o .pyo) pueden ser utilizados por un intérprete de Python normal, cuando ese objeto de código se llama por primera vez

  • La primera operación es JUMP_ABSOLUTE, saltará al desplazamiento n

  • En el desplazamiento n, la instrucción es llamar a una función PyC. Esta función restaurará los códigos de bytes ofuscados entre el desplazamiento 3 y n, y pondrá el código de bytes original en el desplazamiento 0. El código ofuscado se puede obtener mediante el siguiente código

        char *obfucated_bytecode;
        Py_ssize_t len;
        PyFrameObject* frame = PyEval_GetFrame();
        PyCodeObject *f_code = frame->f_code;
        PyObject *co_code = f_code->co_code;      
        PyBytes_AsStringAndSize(co_code, &obfucated_bytecode, &len)
    
  • Después de que esta función regrese, la última instrucción es saltar al desplazamiento 0. Ahora se ejecuta el código de bytes real.

Existe una herramienta Pyarmor para ofuscar los scripts de Python de esta manera.

2

Si nos centramos en las licencias de software, recomendaría echar un vistazo a otra respuesta de Stack Overflow que escribí aquí para obtener algo de inspiración sobre cómo se puede construir un sistema de verificación de clave de licencia.

Hay una biblioteca de código abierto en GitHub que puede ayudarlo con el bit de verificación de la licencia.

Puede instalarlo pip install licensingy luego agregar el siguiente código:

pubKey = "<RSAKeyValue><Modulus>sGbvxwdlDbqFXOMlVUnAF5ew0t0WpPW7rFpI5jHQOFkht/326dvh7t74RYeMpjy357NljouhpTLA3a6idnn4j6c3jmPWBkjZndGsPL4Bqm+fwE48nKpGPjkj4q/yzT4tHXBTyvaBjA8bVoCTnu+LiC4XEaLZRThGzIn5KQXKCigg6tQRy0GXE13XYFVz/x1mjFbT9/7dS8p85n8BuwlY5JvuBIQkKhuCNFfrUxBWyu87CFnXWjIupCD2VO/GbxaCvzrRjLZjAngLCMtZbYBALksqGPgTUN7ZM24XbPWyLtKPaXF2i4XRR9u6eTj5BfnLbKAU5PIVfjIS+vNYYogteQ==</Modulus><Exponent>AQAB</Exponent></RSAKeyValue>"

res = Key.activate(token="WyIyNTU1IiwiRjdZZTB4RmtuTVcrQlNqcSszbmFMMHB3aWFJTlBsWW1Mbm9raVFyRyJd",\
                   rsa_pub_key=pubKey,\
                   product_id=3349, key="ICVLD-VVSZR-ZTICT-YKGXL", machine_code=Helpers.GetMachineCode())

if res[0] == None not Helpers.IsOnRightMachine(res[0]):
    print("An error occured: {0}".format(res[1]))
else:
    print("Success")

Puede leer más sobre la forma en que se configuran la clave pública RSA, etc. aquí .

2

Hay una respuesta completa sobre cómo ocultar el código fuente de Python, que se puede encontrar aquí .

Las posibles técnicas discutidas son:
- usar bytecode compilado ( python -m compileall)
- creadores de ejecutables (o instaladores como PyInstaller )
- software como servicio (la mejor solución para ocultar su código en mi opinión)
- ofuscadores de código fuente de Python

1
  • El enlace va a example.com.
    Darian
    4 mar.20 a las 6:08
1

usar cxfreeze (py2exe para linux) hará el trabajo.

http://cx-freeze.sourceforge.net/

está disponible en repositorios de ubuntu

1
  • 5
    Creo que simplemente agrupa los archivos .pyc. Cython, Shed Skin y PyPy van más allá del código de bytes. 3 de agosto de 2012 a las 11:47