Recientemente he visto la noticia de que planean introducir sistemas de protección anticopia (también conocidos como DRM) en la Nintendo DS. No es que esta noticia sea especialmente relevante, pero quiero aprovechar la ocasión para hablar más desde un punto de vista analítico que teórico, de la mayoría de protecciones comerciales disponibles en el mercado; empezando por la que oferta la empresa mencionada en la noticia, Metaforic, demostrando que la venta de aparente seguridad parece ser muy rentable.

El caso en concreto:

Viendo la descripción de su producto estrella, Metafortress, se puede ver que abunda el autobombo con promesas de seguridad longeva y hay pocas muestras de que realmente pueda ser efectivo. Un ejemplo:

Low performance impact – MetaFortress could cost as little as 0.1Hz in operation – a negligible impact at runtime.

High protection strength – Unlike other offerings which can be cracked by script kiddies in 35s, MetaFortress protection can keep you secure for months, well beyond the profitable selling curve of all your games

Easy to use – You do not have time to learn a complicated security system when you are deep in crunch for a Xmas release. MetaFortress has a unique 2 step process that can protect your game in less than ten minutes – without complex set up.

Si realmente tiene una criptografía potente se supone que consumirá muchos recursos, en cambio prometen un consumo de 0.1 Hz (toma piscina de espuma); o bien a un XOR le llaman ‘alta seguridad’ o algo falla en estas premisas. El último párrafo también se da de morros con otra parte de la web, indican que es fácil de utilizar, hasta un crío podría proteger tu programa vaya… y por otro lado te dice que el programa inserta miles y miles de capas de encriptación que hacen que tenga que desprotegerse manualmente.

Resumen hasta ahora: Tenemos un programa de seguridad que puede manejar un bebé, que mete tantas capas como 7 Kg de cebolla, con un algoritmo de seguridad fortísimo, pero todo este añadido que hará crecer unos pocos megas al programa protegido no afectan en nada al rendimiento; y está clarísimo que esto ¡sólo puede desprotegerse capa a capa manualmente! si un programa puede meter todas esas capas con sólo pulsar un botón, ningún otro podrá quitarlas de la misma forma.

Otra pifia con mayúsculas:

In addition, every application of protection is unique, which means that every protected application must be individually cracked. Compromising one application does not allow any further applications to be cracked or even aid other crack attempts.

Literalmente indican que cada protección es única y que para crackear el sistema aunque caiga una de las copias no implica que caigan las demás. Aunque esto en principio es cierto, no quiere decir que la gente vaya a hacer un crackeador genérico para todas y cada una de las copias vendidas, lo lógico y normal sería distribuir la versión crackeada en lugar de cualquiera de las versiones protegidas. Puro merchandising.

Anuncian que utilizan numerosas capas de encriptación,  que se verifica continuamente la integridad de la aplicación (supongo que mediante algún mecanismo de checksum como CRC32) y que incluyen varios trucos antidebug para prevenir depurar directamente la aplicación, inyección de DLLs en el proceso, etc…

Ninguna de las protecciones que implementan en sus productos es invento suyo, muchas otras compañías que programan empaquetadores las han usado con anterioridad y rara vez consiguen sobrevivir más de un mes.

Una visión más generalizada:

Lo primero a tener en cuenta al diseñar una protección es saber qué es lo que quiere el que la va a atacar:

Si la aplicación utiliza un número de serie para registrarse, el atacante buscará encontrar el algoritmo de validación para obtener una clave válida o bien crear un generador de claves. Ante esto, sólo es útil las protecciones antidebug que intentan evitar que se depure la aplicación directamente. ¿Porqué? Porque si se consiguen desactivar, mediante puntos de interrupción en las DLLs del sistema se puede encontrar el código desprotegido en memoria.

Recordemos que aunque implemente N capas de encriptación, el procesador sólo interpreta el código original, así que en algun momento estará disponible.

Es posible programar una herramienta que desenpaquete la aplicación, se han hecho muchos antes, aunque lleva más tiempo y al atacante claramente le interesa la opción más rápida y sencilla.

Si el objetivo fuese eliminar una serie de verificaciones de la aplicación, digamos alguna comprobación de hardware, una comprobación de seguridad, etc… el método más sencillo sería parchear el programa. Esto lo evitan mediante checksums que verifican que los datos no hayan cambiado y mediante las miles de capas de encriptación.

El punto más claro por donde probablemente el atacante buscará entrar es saltarse los checksums (esto se puede conseguir evitando que se ejecute la comprobación; cambiando el valor del checksum por el valor correcto después de haber modificado la aplicación; o bien haciendo que lo verifique sobre una copia sin modificar del programa, en lugar de sobre el programa modificado).

El mayor problema será entonces la encriptación, dependiendo de cómo esté hecha, será más o menos fácil. Depende de si la encriptación es del ejecutable completo (aun pudiendo ser varias capas) o procedimiento a procedimiento. En cualquier caso, de la misma forma que se añaden las capas, se pueden saltar, aunque sería necesario programar una utilidad para ello o bien utilizar una ya existente si alguien la ha creado antes.

Si se implementase alguna protección mediante hardware o un sistema de claves públicas y privadas, el punto más débil suele ser una copia legítima. Es decir, aunque sin la clave privada o el hardware no pueda funcionar el programa, si se obtiene acceso a ellos es posible desactivar todas las validaciones de seguridad de la aplicación.

Recordando otros sistemas de DRM de audio como los de los archivos WMA, iPod, Zune o similares, si conectamos un cable minijack desde el dispositivo a otro aparato grabador, podremos grabar analógicamente el sonido saltándonos todas y cada una de las protecciones.

Como dijo un sabio anónimo:

Si puede ser ejecutado, puede ser crackeado.

Conclusión:

Cualquiera de estos sistemas de seguridad basados en la ocultación puede haber tardado años en ser elaborado para garantizar una compatibilidad y seguridad óptimas, y lo más probable es que no aguante más de un mes una vez liberado; dejando a la empresa que ha obtenido una licencia para dicho producto igual que si no la hubiese adquirido.

Irónicamente, si se tienen estas premisas como base y se ajusta el modelo de negocio correctamente, sería posible para dichas empresas mantener el producto con un modelo basado en el Software Libre.

Si se da la copia indiscriminada del programa como perdida, mediante la publicidad, merchandising, soporte técnico, etc… es posible hacer que sea rentable; además, ofreciendo un mejor producto al usuario, con un menor consumo inútil de recursos y sin el prejuicio de catalogarlo como ladrón incluso después de adquirir el producto.