[Python-es] Código Python protegido

Sab Feb 25 18:41:54 CET 2012

El 25 de febrero de 2012 12:18, lasizoillo <lasizoillo en gmail.com> escribió:

> El día 25 de febrero de 2012 15:51, Alvaro Manrique
> <sanreikaj.foros en gmail.com> escribió:
> > lasizoillo,
> >
> > Totalmente de acuerdo contigo, sobre todo la parte en la de chantajear al
> > cliente, no no no Sres. eso no se hace,
> > pero te invito a leer completo el debate sobre todo la parte donde dije
> que
> > el código va a estar en un servidor bajo
> > mi control (es una aplicación web) pero se puede presentar el escenario
> > donde se tenga que instalar en un servidor
> > de alguno de los clientes en ese caso es que aplica protejer ciertas
> partes
> > del código,
> > lo dije desde un principio Ciertas Partes del Código
> >
> > Lo de falsa seguridad mmmm, no lo creo, esta es solo una de las medidas
> de
> > seguridad.
> >
>
> 1.- Antes de discutir nada hay que centrar conceptos.
> 2.- Cerrar el códido que maneja una información no implica asegurar la
> información manejada (falsa sensación de seguridad).
> 3.- Cerrar código puede impedir el acceso a cierta información
> (formatos cerrados vs abiertos).
> 4.- Hay que analizar los costes/beneficios de cerrar el código (en mi
> opinión es despilfarro).
>
> El punto 1 parece realizado. El punto 2 parece aclarado si dices que
> es solo una medida más. El punto 3 parece no ser relevante. Vayamos al
> punto 4:
>
> Los empaquetadores como py2exe o similares para otros sistemas
> operativos hacen lo siguiente: crean un ejecutable con un interprete
> de python e introducen los programas de python que son interpretados.
> La ingeniería inversa de estos métodos son sencillos. Aun cuando
> ejecuten los bytecodes de python y no el fuente de python, conseguir
> los segundos a partir de los primeros es inmediato. Py2exe por si solo
> carece de utilidad.
>
> La verdad no he pensado en los empaquetadores como py2exe, no aplican para
mi.

> Se puede encriptar código python mediante el encoder:
>
> https://breakingcode.wordpress.com/2010/07/23/quickpost-hiding-your-python-source-with-rot13/
> Como te imaginaras el encoder es un código python que es utilizado
> para desencriptar el propio programa antes de ser pasado al
> intérprete. Da igual si lo que haces es crearte y registrar tu propio
> encoding que no sufre de los problemas debilidad del rot13 (se ve
> claramente si encriptas dos veces un mensaje para hacerlo más seguro),
> porque será fácil usar trozos de tu propio código para desproteger tu
> código. El encoder se encuentra en la zona de código no "asegurada".
>
> Tienes toda la razón pero quizá pueda llegarse a algo mas complejo.

> Se puede usar cosas como cython, shedskin, ... para compilar tu código
> fuente en un binario que sea más dificil de analizar. La diferencia es
> que se hará ingenieria inversa leyendo código máquina en vez de
> python. Es una molestia, pero no una barrera insalvable. A parte de
> eso, ninguno de los compiladores de python que hay tienen soporte
> total de python a día de hoy, por lo que te complicará el ciclo de
> desarrollo limitándote las funcionalidades de python que puedes
> utilizar en tu desarrollo.
>
> Me inclino mas por encriptarlo que pasarlo a binario.

> Puedes mantener el código que quieres que permanezca oculto mediante
> procedimientos remotos (xml-rpc por ejemplo). Eso garantiza que el
> usuario del código no tiene acceso al mismo y no puede realizar una
> ingeniería inversa de el (solo puede hacer análisis de caja negra). La
> contrapartida es que el programa no funcionara en modo offline.
>
> Eso es correcto y llegando al caso que deba ser offline, seria una
debilidad.

> Puedes hacerte un paquete que incluya un binario capaz de ejecutar
> código python cifrado con un secreto que es solicitado a un servicio
> remoto o a un dongle conectado al ordenador y que descifre el código
> python antes de ser ejecutado. Ese código lo puedes meter en zonas de
> memoria marcadas para no ser swapeadas y al código base binario
> ponerle varias medidas de seguridad: antidebugging, enpaquetado de
> binarios, ... Todo esto solo sirve para hacer más dificil (no
> inviable) el acceso al código, es técnicamente posible de hacer, pero
> jamás lo he realizado porque la inversión en desarrollo nunca me ha
> parecido rentable. Aparte de eso, siempre me ha parecido más divertido
> saltarme las medidas de seguridad que implementarlas. El tiempo que se
> pierde en impedir el acceso al código es tiempo que no estás empleando
> en quitar a tu código de problemas de seguridad que puedan ser
> detectados por un fuzzer y explotados sin aceso al código fuente.
>
> Nuevamente de acuerdo contigo, seria mas difícil mas no imposible y esa es
la
idea.

Gracias por la critica constructiva aquí me estas dando datos bien
interesantes
que voy a investigar.

> Un saludo,
>
> Javi
> _______________________________________________
> Python-es mailing list
> Python-es en python.org
> http://mail.python.org/mailman/listinfo/python-es
> FAQ: http://python-es-faq.wikidot.com/
>

-- 

*Alvaro Manrique
Programador
Caracas - Venezuela
Skype: alvaro_manrique*
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.python.org/pipermail/python-es/attachments/20120225/4fa032f7/attachment.html>