Español | English
rss facebook linkedin Twitter

Protección del software (Parte II)

Una vez visto el panorama actual, vamos a echar un ojo a las protecciones que encontramos en las aplicaciones que podemos descargar de cualquier página o comprar en cualquier tienda.

  • Protección por número de serie
  • Protección por keyfile (fichero de registro)
  • Periodo de prueba de X días
  • Versión limitada (Demo)
  • Necesidad de otro dispositivos (CD, llave USB, mochila...)

Además de estas protecciones, hoy casi todos los programas poseen una “capa” más de protección ya que presentan el ejecutable empaquetado, pero esto lo comentaremos más adelante.

Protección por número de serie.

En este tipo de programas, solicita que introduzcamos un número de serie y, si acertamos, el programa quedará registrado y completamente funcional. Por supuesto, no podemos obtener el número de serie a ciegas, pero disponemos de múltiples herramientas para analizar los programas en cuestión.

Existe un problema muy grave en la comprobación del número de serie de muchos programas, y se trata de que las secuencia lógica de comprobación puede ser algo así:

  1. si numero_de_serie = ''5421-546-321-4564-123-134”
  2. entonces llamar registrado
  3. si no
  4. entonces llamar Noregistrado
  5. fin si

Suponiendo que no podemos acceder al descompilado (cosa que hoy día es probable gracias al plug-in Hex-Rays del IDA Pro o herramientas como reflector para aplicaciones .NET), siempre cabe la posibilidad de ver el desensamblado, en el que veremos una ejecución secuencial, que sirve perfectamente para ilustrar este problema.

  1. reg1 <-- numero_de_serie
  2. reg2 <-- ''5421-546-321-4564-123-134”
  3. igual reg1,reg2
  4. si no igual salta NOIGUAL
  5. llamar registrado
  6. salta FIN
  7. NOIGUAL:
  8. llamar Noregistrado
  9. FIN:
  10. terminar

En este pseudocódigo, si conseguimos que la línea 4 no salte a NOIGUAL, podremos conseguir que el programa quede siempre registrado. Podemos cambiarla por una instrucción que no haga nada, o reemplazar el “si no igual” por un “si igual”, haciendo que valgan todos los números de serie excepto, precisamente, el válido.

Por supuesto, esto se corresponde a un fallo de diseño. Por ejemplo, NUNCA se debe comparar un número de serie en texto plano, ya que puede ser vista por el atacante. Ante esto, la primera idea puede ser cifrar el número de serie introducido por el usuario con una rutina muy compleja, incluso alguna matemáticamente irreversible y en la que se sabe que no es viable atacarlo por fuerza bruta en un tiempo razonable, pero siempre se deberá tener cuidado con la manera de plasmar la idea de la comprobación, puesto que si no lo hacemos es más que probable que la protección tenga el mismo formato (y el mismo fallo de diseño) de la aplicación anterior.

No existe un método que te pueda garantizar la seguridad de tu algoritmo en estos casos, pero se puede intentar fortificar la comprobación de muchas maneras. Por ejemplo, se puede aplicar conocimiento adquirido en otras áreas para diseñar un algoritmo de autenticación más fuerte, como se hizo en el reto 3 que se propuso en este mismo blog. Esta misma idea, utilizada sobre una red muy profunda (y una buena gestión de recursos :p ) puede ser muy interesante, aunque está claro que no es la solución definitiva.

Como ejemplo de un diseño correcto podemos ver la implementación de la protección por contraseña de un fichero .rar. En este caso no se comprueba la contraseña de un fichero y se procede a descomprimirlo, sino que se utiliza la propia contraseña para descomprimir el fichero, por lo que una clave errónea nunca nos devolverá un fichero correcto. En estos casos, el único ataque factible es la fuerza bruta.

Haciendo una analogía con un programa shareware, una manera de dificultar el parcheado del programa es cifrar la parte del programa que desees con la clave, y descifrarlo con el número de serie introducido. Si haces esto, recuerda gestionar bien los errores de un descifrado incorrecto.

Y con esto terminamos por hoy. Seguimos en dos semanas.

Mikel Gastesi
S21sec labs

9 comentarios:

Anónimo dijo...

Teneis pensado escribir sobre el presente/futuro de las protecciones basadas en VM?

Como pueden ser Starforce (la que mejor mutacion de codigo e interprete de VM tiene) Securom (Para mi la segunda mejor pero es vulnerable como todas al inline patching, es decir que no es necesario interpretar el pcode de la VM con dumpear y saltarse la VM valga aunque no es un metodo elegante ya que la memoria sufre :) y si no que se lo digan a los jugones jeje (,Themida (Buena mutacion de codigo tambien aunque aun tiene mucho que aprender de la VM de Starforce), TTprotect (Aun está empezando...) Private exe Protector (Buena VM con bastante futuro diria yo) Enigma Protector (Con todos mis respetos al autor me parece una VM de parbulario),VMprotect (Muy usada en el malware donde la version demo dista mucho de la version profesional que esa si que usa mutacion como dios manda ;) y bueno hay mas.... pero ya son de nivel muy bajo como pueden ser la de Asprotect o la VM de Execryptor que tampoco es una VM como podemos conocer a las otras dichas anteriormente.


*La VM de EC que en realidad no es una VM de parbulario no tiene nada.

Anónimo dijo...

Y otra vez yo :) es decir mr_anónimo por motivos legales

Parte de lo que comentas es lo mismo que hace asprotect con su encrypted code como armadillo con su secured sections o como themids con su licencia.

Si no tiees una key/licencia valida actualmente no es posible crackearlo.

Por lo que creo que en el mundo de la proteccion de software está todo mas que reeinventado ya que las VMs tienen mas años que la polca y si no que se lo digan a las compañias de AV que metodos venian usando ellos hace tiempo.

En fin que no está mal el articulo aunque creo que es de caracter muy facil de entender.

Y pot favor sin acritud

Anónimo dijo...

Y de nuevo yo ;)

Teniendo experiencia en los dos campos pienso que es mas facil romper que construir.

Es decir que es mas dificil programar algo para que sea dificil romperlo ya que todo en el mundo del software es posible que romper eso que sea ha construido para evitar ser destruido ;)

Y ya creo que para terminar, aun no he visto una proteccion ni a mi se me ocurre nada por el momento que sea compatible en todos los Windous :) y que mantenga a los AVs calladitos y que corra en ring3 que evite inyeccion de codigo o como comunmente se llama dll hacking u otra version/ataque inline patching.

Y me refiero a algo serio ya que no basta con unos simples CRCs o Antidumps.

Porque es evidente que si fuera en ring0 todo seria mas facil ya que se tiene el control absoluto :)

Ah y tampoco valen los trucos sucios de saltar de ring3 a ring0 y tiro porque me toca :)

Anónimo dijo...
Este comentario ha sido eliminado por un administrador del blog.
Anónimo dijo...
Este comentario ha sido eliminado por un administrador del blog.
Anónimo dijo...

Viva la libertad de expresión ;) (lo digo única/exclusivamente por la eliminación de mi post anterior ya que creo he respetado todas las normas posibles de un blog no?)

Dicho esto se me había ocurrido otro tipo de sistema de protección que no sé si hablarán en las siguientes entregas que es protección de software a traves de un servidor.

Por poner un ejemplo tenemos a Starforce Proactive Version.

La aplicación se protege de forma online contra los servidores de los chicos rusos de starforce para evitar de esa forma que todo el mundo pueda usar su software de protección y lo pueda estudiar como hacen con los demas protectores basados en otros sistemas locales.

Pienso que esto es el futuro ya que se puede llevar un control mayor de la licencia que compras ya que se puede restringir por Ip,numero de usos,etc y eso todo se controla desde una maquina segura que está muy lejos de tu casa :)

El gran problema que tienen los protectores locales (con local me refiero a que no es necesario internet para que funcione) es que al ejecutarse en tu PC tienes el control absoluto sobre ello por mucha protección que tenga como licencias generadas por hardware-id o marcas de agua o versiones custom,etc,etc

No olvidemos que hay muchos protectores como pueden ser Asprotect que ofrecen un sistema de registro online pero ofrecen a su vez la opcion de registro offline como tambien hacen aplicaciones tipos adobe que si no tienes internet de forma offline puedes registrarte.

También tenemos otro ejemplo con las famosas marcas de agua.

He visto protectores como son VMprotect que el autor manda versiones personalizadas de su protector a cada cliente pero que pasa cuando alguien tiene acceso a 2 versiones? Pues que es fácil quitar la marca de agua y todo el sistema se viene abajo.

Otro ejemplo de las marcas de agua la tiene el famoso desesamblador IDA de los belgas de Datarescue (aunque de belgas no tienen mucho porque el autor principal es ruso) que por mucho que metan marcas de agua en las licencias de sus clientes y queden incrustadas en sus "proyectos" se quitan.

Y lo mismo le pasa a la gente del Winlicense que por que en la licencia que te generen vaya una marca de agua con tus datos de cliente al estar generada esa licencia con el propio protector es factible eliminar esa marca de agua o incluso saber los datos que es mas peligroso aún :)

Dicho esto creo que en el mundo del software de protección está todo mas que re-inventado

Y me atrevería a decir que hay algunas "empresas" lúdicas que el tema de la pirateria les resbala un poco ya que si su producto es realmente bueno se vende y un ejemplo creo que seria el GTA.

Y bueno haber si alguien entra al trapo porque esto es un monologo y es un poco aburrido escribir uno solo y no poder debatir tus ideas es un poco cansino jeje

S21sec labs dijo...

Perdonad la tardanza en responder, pero me encontraba de viaje. A ver si puedo responder a los comentarios.

No pretendo llegar a describir las VM, sino una vista más genérica de la protección de software y, como dices, de carácter fácil de entender, pero agradezco el resumen que nos traes.

En cuanto al uso del key para que funcione el programa, es verdad que se está implementando, pero personalmente me extraña que se haya tardado tanto en utilizar el key para la proteción cuando, una vez visto, parece tán lógico. De hecho, ¿En que porcentaje de programas se utiliza?

Discrepo en cierta medida que sea más fácil romper algo que construirlo. Ciertamente muchas veces es muy sencillo romper una protección que habrá tardado su tiempo en ser creada pero, ¿acaso tú no serías capaz de hacerte sudar a ti mismo si dispones del tiempo necesario para ello?

Desde mi punto de vista el utilizar redes y lógica compleja y abstracta permite que el programador pueda partir con cierta ventaja sobre el cracker, que tiene que reconstruir dicha lógica. Por supuesto, hay que plasmarla bien, porque si puedes parchear el programa para que salte toda la protección y vaya a donde interesa sin ningún problema, estamos listos...
Todo esto en ring3 y sin trampas.

Respecto a las protecciones basadas en, digamos, cliente-servidor está claro que es muy fuerte, siempre y cuando necesites la información que te devuelve el servidor y éste implemente cierta lógica, no vale que te devuelve on 'OK'. De esto hablaremos más adelante, pero comparto opinión contigo, al igual que con el ejemplo del GTA, pero este tema ya es muy subjetivo.

Gracias por las respuestas

Anónimo dijo...

Gracias por responder y disculpas aceptadas por la parte que me toca :) aunque no eran necesarias ya que el tiempo es oro como decia un buen amigo mio

Respecto a lo de la VMs que cometas/mos he de decirte que no es un tema dificil de entender ni mucho menos ya que por ejemplo la version demo de VMProtect el codigo que genera no es dificil de interpretar ni mucho menos.

Yo creo que si una persona entiende ensamblador o por lo menos los comandos básicos es capaz de enteder una protección fácil basada en VM.

Donde radica la dificultad de una VM normal? En interpretar el codigo que genera y saber como funciona.

Es decir TIEMPO!!!

Para mi ese es el punto fuerte de una VM el hacerte gastar tiempo en saber como funciona por dentro.

Aunque es cierto que todas tienen parametros genericos tienes que estudiarla "un poco" y eso que estamos hablando de una normalita jeje

Respecto al uso del key para que funcione el programa tienes razon en que muy pocos programas la usan.

Es mas :) cuantos clientes de packers usan su SDK? Muy pocos la verdad

Ahora bien no sé si es por falta de documentación/soporte de algún protector o por falta de conocimientos del programador.

Aunque esto que digo no creo que sea muy veridico ya que la mayoría de SDK de protectores es muy facil de implementar en el codigo y tienen infinidad de ejemplos en varios lenguajes.

Entonces porque esta caracteristica no es usada por los programadores?

De nada sirve adquirir una licencia de un protector si lo que vas a hacer con tu aplicación es un simple "click-protect".

Y esa si que es una realidad muy grande por parte de los programadores que adquiren protectores y de verdad que desconozco el motivo ya que en realidad, quien mejor puede proteger una aplicación es el mismo programador que la desarrolla, ya que sabe donde hay que proteger exactamente y las funciones "debiles" en las que cae el peso del registro, chequeos de trial, etc.

Asi que si combinamos nuestras propias tecnicas (no tienen por que ser complejas) junto con un protector, obtendriamos resultados excelentes.

Ya ta :)

Y en estos dias sigo con los temas que me faltan por contestarte que ahora no tengo tiempo :)

S21sec labs dijo...

Totalmente de acuerdo.

Yo clasificaría los trucos antidebug, antidump, crc, etc, en "ñapillas" que pretenden evitar la desprotección, pero que una vez descubiertas muchas son totalmente inútiles, y otras requieren intervención manual pero tampoco suponen un gran problema (las hay que más y las hay que menos, claro).

En cambio, las VMs pienso que siguen la filosofía de dificultar el cracking, no volverlo imposible. A mi me gusta decir que más que buscar la imposibilidad de ruptura de la protección, ya que se ha "demostrado" imposible, se busca atacar al cracker.
Haciendo una analogía más sencilla, me parece mucho más molesto analizar un programa con 4 procesos de 5 hilos que una aplicación con 20 antidebugs.

Las VM son complicadas, pero más que eso son complejas, y los crackers humanos y muchas veces sin el tiempo libre necesario para entenderlas, y ahí es donde duele ;)

Respecto a los protectores, opino que quien compra un protector (generalmente) lo único que pretende es desentenderse de tener que proteger el programa y, salvo en contadas excepciones, será difícil que se preocupe de ello.

Saludos,


(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login