El 25 de febrero de 2012 12:18, lasizoillo <lasizoi...@gmail.com> escribió:
> El día 25 de febrero de 2012 15:51, Alvaro Manrique > <sanreikaj.fo...@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@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*
_______________________________________________ Python-es mailing list Python-es@python.org http://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/
