Español | English
rss facebook linkedin Twitter

Protección del software (Parte IV)

En las partes anteriores hemos dado un repaso a las protecciones más comunes, por lo que ahora vamos a intentar dar algún consejo a la hora de proteger una aplicación.

Al igual que en las partes anteriores, vamos a tratar la parte lógica de la programación, en la que priorizaremos el no dar facilidades a quien pretende atacar nuestra aplicación, y volveremos a tomar como base de este post una aplicación protegida por contraseña.

En la siguiente parte comenzaremos con temás un poco más técnicos, tomando los packers como base, y tratando diferentes barreras que ponen para tratar de proteger la aplicación.

Volviendo al tema que nos conscierne, en primer lugar deberemos recapacitar sobre lo que un atacante necesita para ponerse manos a la obra. A la hora de atacar una protección, no se analiza el código del programa en su totalidad, sino que interesa ubicar la parte de código en que se encuentra la rutina de comprobación, por lo que la primera labor es encontrarla.

Para ello, muchas veces puede ser suficiente fijarte simplemente en los mensajes que se muestran para indicar que es una versión de prueba, ver qué se necesita para registrar el programa (si un número de serie, keyfile), y buscar en el programa en cuestión cadenas de texto sospechosas, llamadas a APIs relacionadas con la apertura de ficheros, lectura de registro...

Por tanto, un consejo muy importante consiste en no dar más información de la necesaria.

Para el profano en la materia, vamos a ver un pequeño ejemplo de una aplicación que muestre un mensaje "Hola Mundo!" en la que queremos encontrar la zona en la que imprime el mensaje, y vemos cómo existe una diferencia notable entre dos aplicaciones que realizan la misma función.

Hola mundo en MASM32:



Hola mundo en C:


Para empezar podemos ver que la versión en C ocupa el séxtuple que la programada en ensamblador.


Veamos el código que se ejecuta en primera instancia, las cadenas de texto y las APIs importadas en cada uno.

Ensamblador:


C:



En la versión asm el código es muy parecido al escrito más arriba, y tanto las cadenas de texto referenciadas como la llamada a apis se corresponden con las utilizadas en el código fuente. Por el contrario, el compilador de C modfiica el código, y vemos cómo aparecen más cadenas de texto y se importan muchas más APIs.

Con esto comprobamos cómo los compiladores de alto nivel realizan modificaciones en el código, por lo que al analizar un programa, rescatar la idea del programador se convierte en una tarea un poco más complicada. Por supuesto, no se puede confiar en esto como protección. Se puede aconsejar la optimización de código porque puede tener como efecto lateral una pequeña ofuscación del código pero, al ser una transformación de código que no controlamos, ¿no podría afectar negativamente?

Por otra parte, si se debe dar información sobre un evento y no se para a pensar en ello, se puede dar por hecho que la información del evento (¿un registro fallido?) se encontrará cercana a la comprobación, y si se puede seguir la ejecución del programa, vendrá justo detrás de ésta. Es aconsejable separar la comprobación de la decisión y de la información devuelta al usuario (en forma de continuación con la versión de ejecución, por ejemplo).

Un mal hábito que se puede encontrar en más de una ocasión consiste en no mostrar una NAG (ventana de aviso) en caso de fallar el registro, pero a cambio cerrar el programa. Este hecho permite que el atacante pueda detener la ejecución cuando se llama a la API encargada de termina con la aplicación y solamente mirando desde donde es llamada se acercará a tu rutina de comprobación.

Personalmente considero mucho más razonable que una aplicación ante un intento de registro continue una ejecución normal, pero la funcionalidad que se quiere dar a la versión registrada dependa de la clave introducida.

Resumiendo un poco este post, digamos que si no queremos que nuestra protección sea presa fácil, por lo menos no colaboremos a ello ;)

Mikel Gastesi
S21sec e-crime

3 comentarios:

Álvaro Del Hoyo dijo...

En relación con las dudas que se plantearon hace ya algún tiempo en esta secuencia de posts sobre la legalidad de los actos necesarios para la desprotección del software, tenemos que recurrir a una lectura conjunta de los apartados 3, 5, 6 y 7 del artículo 100 del Texto Refundido de la Ley Propiedad Intelectual, y por otro lado del artículo 270.3 del Código Penal:

http://civil.udg.es/normacivil/estatal/reals/Lpi.html

http://www.boe.es/g/es/bases_datos/doc.php?coleccion=iberlex&id=1995/25444

En cristiano, que un usuario legítimo puede tratar de entender el software del que tiene una licencia de uso, y que incluso puede buscar la manera de hacer que tal programa se entienda, interopere con otro, eso sí, dentro de los límites marcados en el artículo 100 TRLPI.

Lo que no puede hacer nadie, salvo autorización previa del titular de los derechos sobre el software ;-p, es eliminar o neutralizar su protección, constituyendo ello un ilícito civil (infracción del artículo 100 TRLPI) e incluso un delito (artículo 270.3 Código Penal, pues un crack y el término "específicamente" se llevan muy bien ;-) si media ánimo de lucro, entendido en vía penal como beneficios económicos dada la existencia del principio de interpretación restrictiva en Derecho Penal.

Tomemos como ejemplos de actos lícitos de ingeniería inversa en base al artículo 100 TRLPI el desarrollo de Samba (compartir ficheros entre sistemas Windows y distintos a Windows), OpenOffice (tratamiento de formatos de archivos de Microsoft),...

Os paso el link a una noticia al respecto de la desprotección de software de hoy mismo:

http://pwcspain.typepad.com/blog_nuevas_tecnologias/2008/10/en-septiembre-d.html

No teniendo el detalle de las circunstancias que rodean el supuesto, el caso de la noticia en mi opinión parece no era más que un ilícito civil (artículo 100 TRLPI), si bien no un delito pues no se comenta que hubiera pruebas de que quien desprotegió el software (art. 270.3 Código Penal) y lo distribuyó en las redes P2P (artículo 270.1 Código Penal en relación con el artículo 20 TRLPI sobre "comunicación pública") obtuviera beneficios económicos por cualquiera o ambos de tales actos.

El uso del término "específicamente" en este artículo 270.3 Código Penal, y de nuevo el principio de interpretación restrictiva en Derecho Penal pueden hacer que por ejemplo que los Modchips queden fuera de este tipo penal, si bien de nuevo saltarse las protección de los videojuegos podría constituir un ilícito civil.

Os paso una sentencia de cal y otra de arena (en vía penal ambas):

http://deley.wordpress.com/2008/07/04/sentencia-que-falla-que-la-instalacion-de-chips-para-neutralizar-los-dispositivos-de-proteccion-de-las-videoconsolas-que-no-constituye-un-delito-contra-la-propiedad-intelectual/

http://deley.wordpress.com/2008/07/04/sentencia-que-falla-que-la-instalacion-de-chips-para-neutralizar-los-dispositivos-de-proteccion-de-las-videoconsolas-que-no-constituye-un-delito-contra-la-propiedad-intelectual/

El problema con los videojuegos es que pueden considerarse como programa de ordenador o como obra multimedia (conjunto de software, obras audiovisuales, obras pcitóricas). Yo me inclino más por lo segundo, si bien no debe olvidarse que normalmente se trata de obras colectivas, propiedad de la empresa que los desarrolla. La diferente consideración de la naturaleza jurídica de los videojuegos trae consigo el problema de que dependiendo de cómo lo véamos entonces entrará en juego lo dicho en los apartados 3, 5, 6 y 7 TRLPI (videojuegos = software), o junto al artículo 100 TRLPI (en relación al software del videojuego) también los artículos 160 a 162 TRLPI (en relación con las obras audiovisuales y obras pictóricas).


Finalmente, aunque de forma tangencial la legalidad, no ya de la desprotección de software y su distribución en redes P2P, si no de la descarga en redes de software desprotegido para ser usados por personas jurídicas y su posible uso empresarial podéis consultar el segundo post de una secuencia en nuestro blog:

http://blog.s21sec.com/2008/02/redes-p2p-datos-personales-ilcitos_13.html

Es de destacar que el uso de programas desprotegidos para uso de personas jurídicas puede constituir también un acto de competencia desleal.

Qué aproveche ;-p

Un saludo

cienes de datos dijo...

Yo recomendaría una llave hardware que contuviese parte del código (cifrado incluido) necesario para ejecutar la aplicación y, dicho sea de paso, también caería.

Anónimo dijo...

cienes, me interesa tu metodo, podrias explicar mas o menos que seria eso, un poco mas de luz.

Osea lo que vos decis es que una rutina tome parte de su codigo de la llave, como harias eso ? no daria error al compilar ?

Gracias.


(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login