[Python-es] Código Python protegido
Alvaro Manrique
--
Alvaro Manrique
Programador
Caracas - Venezuela
Skype: alvaro_manrique
monoBOT
Òscar Vilaplana
Alvaro Manrique
MonoBot, la verdad es que py2exe no me sirve por que es sólo para windows
Oscar, la búsqueda en google la he hecho y créeme que de muchas maneras, he visto la gran cantidad de debates que se han abierto sobre el tema pero al final no se llega a una solución o metodo.
Esta inquietud no es nueva tengo mucho tiempo buscando una manera, tanto en google como analizando una solución propia, sin embargo sigo leyendo cualquier foro sobre el tema y voy a leer la información que me indicas
Quice exponer el tema nuevamente aquí ya que hay gente nueva integrando la lista y quizá alguno tiene alguna idea.
Sería interesante que si encontramos un buen metodo lo desarrollemos en conjunto.
_______________________________________________
Python-es mailing list
Pyth...@python.org
http://mail.python.org/mailman/listinfo/python-es
FAQ: http://python-es-faq.wikidot.com/
Angel Claudio Alvarez
Te da verguenza que otros lo vean?
Sos tan egoista que no queres compartir codigo?
Si alguna de estas respuestas es afirmativa yo te diria que te vuelques
a un lenguaje que si te permita ocultar tu codigo
El codigo abierto es la esencia de python.
> --
>
>
> Alvaro Manrique
> Programador
> Caracas - Venezuela
> Skype: alvaro_manrique
>
>
>
Carlos Zuniga
> MonoBot, la verdad es que py2exe no me sirve por que es sólo para windows
>
> Oscar, la búsqueda en google la he hecho y créeme que de muchas maneras, he
> visto la gran cantidad de debates que se han abierto sobre el tema pero al
> final no se llega a una solución o metodo.
>
> Esta inquietud no es nueva tengo mucho tiempo buscando una manera, tanto en
> google como analizando una solución propia, sin embargo sigo leyendo
> cualquier foro sobre el tema y voy a leer la información que me indicas
>
> Quice exponer el tema nuevamente aquí ya que hay gente nueva integrando la
> lista y quizá alguno tiene alguna idea.
>
> Sería interesante que si encontramos un buen metodo lo desarrollemos en
> conjunto.
Una opción podría ser que reescribas la parte del programa que te
interesa proteger en cython [0], un lenguaje basado en python que se
compila y luego puedes importar como modulos desde python. Luego
puedes distribuir solo los .so junto con tu programa.
Saludos
[0] cython.org
--
Linux Registered User # 386081
A menudo unas pocas horas de "Prueba y error" podrán ahorrarte minutos
de leer manuales.
Alvaro Manrique
Gracias Carlos, estoy pensando en una opción similar.
Ángel con respecto a tus preguntas, lamento informarte que no acertaste ninguna y mucho menos que si me da vergüenza mostrar mi código jajajajajaja.
A groso modo lo que puedo decir es que este desarrollo esta hecho para manejar información muy delicada en la cual una fuga de la misma puede ser penada con cárcel.
Este desarrollo va a estar en un servidor donde tengo el control pero se puede presentar el escenario donde tenga que ser instalado en un servidor del cliente localmente, en ese caso es donde aplica proteger ciertas partes del código, el resto orgullosamente puedo mostrarlo y hacer circular el conocimiento, que en mi concepto es la mejor manera de aprender.
Pido disculpas si con esto vuelvo a generar el interminable debate del software libre, con lo cual me siento identificado pero no pienso hablar de eso.
Lamentablemente como veo que se puede desviar demasiado el tema creo que debe quedar hasta aquí.
Como ya explique me veo obligado a buscar una solución a esta situación y quien este buscando algo similar puede unirse al desarrollo.
Como última acotación previniendo que me manden a programar en otro lenguaje, puedo decir que no es posible, ya que después de haber aprendido algunos lenguajes me quedé con python por obvias razones todos los que están en esta lista conocen.
Muchas gracias por el apoyo.
Sebastián Magrí
http://neurog33k.blogspot.com/2011/10/python-article-in-hakin9-magazine.html
2012/2/24 Alvaro Manrique <sanreik...@gmail.com>:
--
Sebastián Ramírez Magrí
http://sebasmagri.alwaysdata.net/
Alvaro Manrique
Gracias Sebastián voy a revisarlo
Alvaro Manrique
Oswaldo
>....
> A groso modo lo que puedo decir es que este desarrollo esta hecho para
> manejar información muy delicada en la cual una fuga de la misma puede
> ser penada con cárcel.
Entonces creo la prioridad debería ser proteger la información mas que
el código de la aplicación.
--
Oswaldo
Andrey Antoukh
Andrei.
Andrei Antoukh - <ni...@niwi.be>
http://www.niwi.be/page/about/
http://www.kaleidos.net/A5694F/
"Linux is for people who hate Windows, BSD is for people who love UNIX"
"Social Engineer -> Because there is no patch for human stupidity"
monoBOT
Andrey Antoukh
_______________________________________________
Python-es mailing list
Pyth...@python.org
http://mail.python.org/mailman/listinfo/python-es
FAQ: http://python-es-faq.wikidot.com/
lasizoillo
Resumen ejecutivo:
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 que este cansado del temita puede dejarlo ahi. No voy a hablar de
python en el resto del correo.
El día 25 de febrero de 2012 13:03, monoBOT <monobo...@gmail.com> escribió:
> No se que problema le ves a hacer codigo privativo con Python ... Si fuera
> como tu dices el lenguaje de programación no podria servir para la vida
> laboral, que quieras o no estamos en un mundo movido por el dinero. Las
> empresas si contratan programadores es o para ganar dinero o para
> ahorrarselo, si es para ganar quieren que el código sea protegido si es para
> ahorrarselo quieren una ventaja competitiva respecto de la competencia.
Esa argumentación es falaz. Yo he ganado dinero haciendo software a
medida con licencia libre. Lo cual me ha impedido tener secuestrado al
cliente y chantagearle con actualizaciones y bombas de tiempo. Pero
fijate tu que iban y les daba por repetir y llamarte a tí en vez de a
la competencia (tenian el código y esa es una opcción legítima),
solian pagar un mantenimiento y te recomendaban a otra gente porque
habían quedado satisfechos.
> Si quitas a Python del mundo del software privativo nos quitas a los que
> amamos este lenguaje de programación el poder trabajar con una herramienta
> que nos gusta.
La verdad que aquí tambien veo una seríe de conceptos que habría que definir:
Software libre != open source != software privativo
El software libre es el que cumple con las 4 libertades del software,
el privativo el que no. El acceder al codigo fuente (open source) es
solo una de las libertades y no es necesario infringirla para hacer
código privativo.
El debate iba de cerrar un código, derivo en una pregunta sobre la
utilidad de cerrarlo y se está convirtiendo en un sentido (conceptos
mezclados) de defensa falaz (razonamientos lógicos con premisas
incorrectas) del software propietario. Para seguir por ahí habría que
irse a otro hilo o incluso a otro foro. No tiene nada que ver con
python.
>
> Las razones que él tenga son suyas y los perfectamente razonables.
>
> PD: ya te dio las razones y las veo perfectamente justificadas, si el
> protegiera la información pero no el código al leer el código podrías sacar
> la información es así de sencillo.
>
Si es así de sencillo te doy permiso para que me limpies la cuenta bancaria:
http://www.openssl.org/source/
Basar la seguridad de una información en la ocultación del programa
que lo codifica solo puede producir una falsa sensación de seguridad.
De hecho me ha tocado modificar código ofuscado y darme tiempo a
mostrarle los resultados al que los había ofuscado porque se iba de la
empresa. Muchos ofuscadores son muy debiles, lo mismo que muchos
sistemas de encriptación inventados por gente que piensa que la
seguridad está en el código. No suele hacer falta ser demasiado listo
para criptoanalizar y romper ese tipo de "protecciones". Con
conocimientos matemáticos de secundaria y un par de trucos sobra.
Por contra, he topado con gente que ahora quiere rescatar información
que está en una aplicación a medida de las que desconoce el formato y
las ha pasado putas. Pero esto no es un tema de apertura de código
sino de formatos libres. Supongo que cuando el código se quiere cerrar
es porque el formato de la información tampoco es libre.
Un saludo,
Javi
Alvaro Manrique
El sábado 25 de febrero de 2012, Alvaro Manrique escribió:
El sábado 25 de febrero de 2012, Alvaro Manrique escribió:
Lo explicaste excelentemente monoBot y gracias al aporte del amigo Sebastián se puede ver que existeel mecanismo para que python trabaje con código encriptado (por lo menos fue lo que pude entender del articulohay que llevarlo a la practica para ver como se comporta)Ahora si es tan absurdo lo que necesito hacer, porque esta alli la posibilidad desde python sin tener que tocar elinterprete o la maquina virtual??Yo creo que mas absurdo es creer que se va a estar en un proyecto de gran envergadura, donde tienes que responderlea una empresa que invierte en el proyecto y tienes que garantizar que el software es robusto a nivel de seguridad y pensaren que el código va a estar allí perfectamente visible a cualquiera.Quizá me digas que hay maneras de evitar que lleguen al código, te ahorro la escritura, se que las hay, pero créeme quevoy a implementar todas las posibles maneras para proteger el códigoSi protejo la información? me sugieres encriptar toda la base de datos?? gran parte de ella??Y cuando se procesen miles de registros??Sacrifico la rapidez??Yo pienso que la esencia del SL esta en lo que aportemos a la comunidad, no en que nos pasemos de "buenos" y dejemoscódigos por allí así como así.Que pasaría si los interesados en el tema desarrollamos el mecanismo, los módulos, etc, para trabajar con código encriptado?Eso no seria un gran aporte a la comunidad??Créeme hay grandes razones por la que muchos buscamos proteger el código pero siempre pienso en retribuir lo que la comunidadme aporte, en mi concepto es lo verdaderamente importante, así ganamos todos.Jhony ya te paso la revista, no esta completo el articulo de python por ser free, pero con lo que dice basta para que loscuriosos partamos de ahí y hacer la respectiva investigación ;)
--
Alvaro Manrique
Programador
Caracas - Venezuela
Skype: alvaro_manrique
Alvaro Manrique
El sábado 25 de febrero de 2012, Alvaro Manrique escribió:
El sábado 25 de febrero de 2012, Alvaro Manrique escribió:
Lo explicaste excelentemente monoBot y gracias al aporte del amigo Sebastián se puede ver que existeel mecanismo para que python trabaje con código encriptado (por lo menos fue lo que pude entender del articulohay que llevarlo a la practica para ver como se comporta)Ahora si es tan absurdo lo que necesito hacer, porque esta alli la posibilidad desde python sin tener que tocar elinterprete o la maquina virtual??Yo creo que mas absurdo es creer que se va a estar en un proyecto de gran envergadura, donde tienes que responderlea una empresa que invierte en el proyecto y tienes que garantizar que el software es robusto a nivel de seguridad y pensaren que el código va a estar allí perfectamente visible a cualquiera.Quizá me digas que hay maneras de evitar que lleguen al código, te ahorro la escritura, se que las hay, pero créeme quevoy a implementar todas las posibles maneras para proteger el código
Si protejo la información? me sugieres encriptar toda la base de datos?? gran parte de ella??Y cuando se procesen miles de registros??Sacrifico la rapidez??Yo pienso que la esencia del SL esta en lo que aportemos a la comunidad, no en que nos pasemos de "buenos" y dejemoscódigos por allí así como así.Que pasaría si los interesados en el tema desarrollamos el mecanismo, los módulos, etc, para trabajar con código encriptado?Eso no seria un gran aporte a la comunidad??Créeme hay grandes razones por la que muchos buscamos proteger el código pero siempre pienso en retribuir lo que la comunidadme aporte, en mi concepto es lo verdaderamente importante, así ganamos todos.Jhony ya te paso la revista, no esta completo el articulo de python por ser free, pero con lo que dice basta para que loscuriosos partamos de ahí y hacer la respectiva investigación ;)
El sábado 25 de febrero de 2012, Andrey Antoukh escribió:
--
Alvaro Manrique
Programador
Caracas - Venezuela
Skype: alvaro_manrique
Alvaro Manrique
--
Alvaro Manrique
Programador
Caracas - Venezuela
Skype: alvaro_manrique
Alvaro Manrique
El sábado 25 de febrero de 2012, Andrey Antoukh escribió:
lasizoillo
<sanreik...@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.
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".
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.
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.
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.
Un saludo,
Javi
Alvaro Manrique
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".
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.
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.
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.
Un saludo,
Javi
_______________________________________________
Python-es mailing list
Pyth...@python.org
http://mail.python.org/mailman/listinfo/python-es
FAQ: http://python-es-faq.wikidot.com/
Angel Claudio Alvarez
> Gracias Carlos, estoy pensando en una opción similar.
>
> Ángel con respecto a tus preguntas, lamento informarte que no
> acertaste ninguna y mucho menos que si me da vergüenza mostrar mi
> código jajajajajaja.
>
> A groso modo lo que puedo decir es que este desarrollo esta hecho para
> manejar información muy delicada en la cual una fuga de la misma puede
> ser penada con cárcel.
> Este desarrollo va a estar en un servidor donde tengo el control pero
> se puede presentar el escenario donde tenga que ser instalado en un
> servidor del cliente localmente, en ese caso es donde aplica proteger
> ciertas partes del código, el resto orgullosamente puedo mostrarlo y
> hacer circular el conocimiento, que en mi concepto es la mejor manera
> de aprender.
>
++
Yo, personalmente si la fuga de codigo es una variable, no tilizaria
ningun lenguaje que pueda ser decompilado tan facilmente como python o
java
> Pido disculpas si con esto vuelvo a generar el interminable debate del
> software libre, con lo cual me siento identificado pero no pienso
> hablar de eso.
>
> Lamentablemente como veo que se puede desviar demasiado el tema creo
> que debe quedar hasta aquí.
>
> Como ya explique me veo obligado a buscar una solución a esta
> situación y quien este buscando algo similar puede unirse al
> desarrollo.
>
> Como última acotación previniendo que me manden a programar en otro
> lenguaje, puedo decir que no es posible, ya que después de haber
> aprendido algunos lenguajes me quedé con python por obvias razones
> todos los que están en esta lista conocen.
>
4 lenguajes y uno que deberia ser requerido es C ( y C++)
Alvaro Manrique
Ángel debes leer bien el último párrafo, dije que después de aprender algunos lenguajes, no vi necesidad de dar detalles en ese punto, la verdad no viene al caso, pero lo que te puedo responder que si dominó c++
Chema Cortes
> Yo creo que mas absurdo es creer que se va a estar en un proyecto de gran
> envergadura, donde tienes que responderle
> a una empresa que invierte en el proyecto y tienes que garantizar que el
> software es robusto a nivel de seguridad y pensar
> en que el código va a estar allí perfectamente visible a cualquiera.
Personalmente, trabajo también con datos "muy sensibles" y nunca he
pensado que la robustez de una aplicación consista en impedir que se
sepa cómo funciona, si no más bien todo lo contrario. Por lo general,
la seguridad de mis aplicaciones se establece a través de librerías
externas bien probadas (y sobre todo bien mantenidas), con métodos
criptográficos hardware (tarjetas con chip) y comunicaciones seguras
(ssl).
> Si protejo la información? me sugieres encriptar toda la base de datos??
> gran parte de ella??
>
> Y cuando se procesen miles de registros??
>
> Sacrifico la rapidez??
¡Por supuesto! No es concebible que por un lado pretendas esconder el
código y que, por otro lado, los datos estén accesibles en claro.
> Yo pienso que la esencia del SL esta en lo que aportemos a la comunidad, no
> en que nos pasemos de "buenos" y dejemos
> códigos por allí así como así.
Pues te tengo que contradecir. La esencia del SL es dar libertad al
usuario para saber qué hace el software que utiliza, estudiarlo,
modificarlo y redistribuirlo libremente. Si impides cualquiera de
estas "libertades", llámalo como quieras, pero no "Software Libre".
Tanta fuga de seguridad se podría considerar el ofrecer el código al
usuario, como venir a un foro de "desconocidos" a comentar cómo
resolver un problema determinado. De hecho, muchas empresas prohiben a
sus trabajadores participar en foros públicos.
> Que pasaría si los interesados en el tema desarrollamos el mecanismo,
> los módulos, etc, para trabajar con código encriptado?
> Eso no seria un gran aporte a la comunidad??
Sí, pero no a cualquier precio.
> Créeme hay grandes razones por la que muchos buscamos proteger el código
> pero siempre pienso en retribuir lo que la comunidad
> me aporte, en mi concepto es lo verdaderamente importante, así ganamos
> todos.
Tampoco pretendemos que cambies de opinión. Siempre que hemos tratado
este tema hemos aconsejado no ocultar el código y probar con otras
cosas, dedicar todo ese esfuerzo en donde realmente se puede mejorar
la aplicación.
De todos modos, y recuperando el tema, hace tiempo creé un script para
empaquetar un programa python y todos sus módulos en un sólo fichero.
No es una maravilla, pero al menos te dará alguna pista, además de
desconcertar a más de uno:
http://ch3m4.org/pystore/zippack.py
Para usarlo:
$ python zippack.py zipped.py main.py mod1.py mod2.py
--
Hyperreals *R: http://ch3m4.org/blog
Quarks, bits y otras criaturas infinitesimales