Proteccion de software

[giulichajari]

Hola amigos, usuarios de Builder C++ o Delphi queria saber como protegen uds el software para que no se lo copien. con C++ Builder no es necesario crear instalador, pero si llevo la bd y el ejecutable otros podrian llevarse el programa.
Muchas gracias por sus ideas.

[Neftali [Germán.Estévez]]

La Base de Datos, con contraseña, si no quieres que la copien, la visualicen o la abran desde fuera de tu programa.
Para el ejecutable, hay muchas técnicas, dependiendo de la complejidad que quieras aplicar.

Desde las más sencillas con un código que asignas a tus clientes, pasando por claves (software) que tengan que ver con el Hardware de la máquina, hasta protección por hardware, como son las llaves USB (o similares).

En algunos programas, suele ser efectivo (si se puede hacer), que la "key" del usuario aparezca o tenga que ver con una dato importante del programa y además se visualice en listados, facturas,... (documentos). Por ejemplo, piensa en un cliente con NIF/dirección/logo/NOMBRE/.... A partir del NIF o la dirección o el LOGO, generas una key para ese cliente. Luego todas las facturas, albaranes,... salen con el NIF del cliente o la dirección (que se genera a partir de la clave).
Si otro usuario copia el programa y utiliza la misma clave, sus listados saldrán con el NIF, dirección, LOGO,... del original.

Eso hace que lo puedan "probar", pero que en la práctica no lo puedan utilizar...

Si quieres algo más concreto, deberás explicarte un poco más...

Un saludo.

[giulichajari]

Gracias por responder, habia pensado en una clave, pero si le voy a vender el software a algunos nomas o a uno, no es necesario darle un serial al cliente, y no se de que otra manera se podria proteger.

Queria preguntarte ademas si hay algo relacionado con dlls, es decir creando una dll se puede proteger el software. Porque si el usuario otorga el ejecutable pero no la librerias no podran utilizar el software.

Saludos

[donald shimoda]

Empezado por giulichajari

Gracias por responder, habia pensado en una clave, pero si le voy a vender el software a algunos nomas o a uno, no es necesario darle un serial al cliente, y no se de que otra manera se podria proteger.

Queria preguntarte ademas si hay algo relacionado con dlls, es decir creando una dll se puede proteger el software. Porque si el usuario otorga el ejecutable pero no la librerias no podran utilizar el software.

Saludos

Te recomiendo que no se te caiga el pelo pensando en esto. Es decir, usa una protección liviana, que no te complique demasiado la vida pero que el usuario promedio no pueda romper. Esto es, si tu programa es lo suficientemente masivo para que alguien se interese en hackearlo lo harán aunque pongas la protección de la nasa. Mira como cada versión de windows ha sido hackeada por mas artilugios que le monten. Contra esto nadie puede y es una batalla perdida antes de arrancar.

Mi concepto es, una protección bastante sencilla que aleje a los honestos de la intención de no pagar la licencia , pero ten por seguro que si se vuelve lo suficientemente masivo convivirás con la versión hacheada de por vida.

Saludos.

[giulichajari]

Empezado por donald shimoda

Te recomiendo que no se te caiga el pelo pensando en esto. Es decir, usa una protección liviana, que no te complique demasiado la vida pero que el usuario promedio no pueda romper. Esto es, si tu programa es lo suficientemente masivo para que alguien se interese en hackearlo lo harán aunque pongas la protección de la nasa. Mira como cada versión de windows ha sido hackeada por mas artilugios que le monten. Contra esto nadie puede y es una batalla perdida antes de arrancar.

Mi concepto es, una protección bastante sencilla que aleje a los honestos de la intención de no pagar la licencia , pero ten por seguro que si se vuelve lo suficientemente masivo convivirás con la versión hacheada de por vida.

Saludos.

Gracias por tu consejo, seria una perdida de tiempo el tema de dlls o algo asi, y vos que metodo usas o me reocmendas? Lo mas importante es el ejecutable.

[donald shimoda]

Empezado por giulichajari

Gracias por tu consejo, seria una perdida de tiempo el tema de dlls o algo asi, y vos que metodo usas o me reocmendas? Lo mas importante es el ejecutable.

Nosotros usamos un archivo plano encriptado conteniendo todos los datos del equipo y su licencia, pero la ventaja es que mi sistema corre vinculado a un dispositivo de hardware que actúa de llave, así que no puedo aconsejarte en otros cosas.

Saludos.

[Neftali [Germán.Estévez]]

Estoy de acuerdo con Donald.
Prueba con una cosa sencilla que no te de muchas complicaciones y que te evite en simple "copy&paste" de la aplicación. Si la cosa va a más, ya pensarás en algo complejo.

Por ejemplo:

(1) Al ejecutar la aplicación compruebas una clave de registro o un fichero en el directorio de sistema.
(a) Si el fichero o la clave existe, continuas.
(b) Si no existe, generas una pantalla con un número aleatorio.
La persona que está ejecutando la aplicación debe llamarte (o enviarte un correo) y pasarte ese número;
Tú le devuelves otro número "relacionado" con el primero.
(2) Si el número que devuelves es correcto, grabas el fichero (o la clave de registro y continuas)
(3) Si el número no es correcto. detienes la ejecución.

Alguien con conocimientos pillará el fichero o la clave, pero al menos evita que alguien copie la aplicación directamente.

Esto sería lo más básico; A partir de aquí puedes ir añadiendo cosas para dificultar el asunto.

[ecfisa]

Hola giulichajari.

Tal vez también te resulte de interés este enlace: Guardar datos en un ejecutable.

Saludos.

[WkaymQ48]

Esto me recuerda este otro hilo:

Juego (buscar Clave)
http://www.delphiaccess.com/forum/an...buscar-clave)/

En el nuestro amigo Caral propone un pequeño juego donde hay que "adivinar" la clave de un ejecutable, para saber como son de efectivos estos métodos de protección.





Spoiler: Al final la adivinan, y ademas publican un crack con código fuente y todo

[Casimiro Notevi]

No había visto ese hilo, interesante.

[Neftali [Germán.Estévez]]

Empezado por WkaymQ48

Juego (buscar Clave)
http://www.delphiaccess.com/forum/an...buscar-clave)/

Tampoco había visto ese hilo... Interesante.

Me he entretenido un rato y al final ha salido.
Para que te hagas una idea, yo que no soy nada del otro mundo en estos temas, he sacado la clave en un rato. Y hace bastante tiempo que ya no lidio con estas herramientas; Alguien que las tenga "por la mano" supongo que sería bastante más rápido.

* Tal como comentan en ese hilo, la clave para el primer intento es: hola289528519
* Tal como explica Caral, la clave es diferente según el intento, así que para el segundo intento y el tercero, funciona: hola289492718

En este caso, el primer ataque (al menos yo lo haría así) se hace para intentar adivinar las claves (OPCION1).

Una de las premisas básicas a la hora de utilizar claves, es intentar no compararlas directamente en memoria, es decir, no comparar directamente la clave que ha puesto en usuario, con la clave correcta del programa, para saber si es correcta. Si se hace así, lo que pasa es que si detienes el programa en memoria en el momento de la comparación, puedes ver en memoria lo siguiente:



El 1111111111 es la clave con la que yo he intentado entrar (1er intento) y la otra es con la que la está comparando (correcta).
Si hacemos lo mismo para el segundo (2222222222) y tercer intento (3333333333) veremos lo siguiente:





Tan fácil como eso. A tener en cuenta si estamos generando una clave para nuestro programa.

Si esta opción no es viable, lo otro que se puede intentar hacer (y que es bastante habitual) es "modificar" el programa para que funcione de una forma diferente (OPCION2).
En este caso, como sabemos que al introducir una clave, el programa la compara con "la buena" y según sea buena o no, hace una cosa u otra, lo que hacemos es cambiar el resultado de la comparación.
Es decir, el programa ahora hace....
(1) Si las claves son iguales, continuo (correcto)
(2) Si las claves no son iguales, paro y saco ventana de aviso.

Lo que intentaremos es que haga lo siguiente (al cambiar la comparación):
(1) Si las claves son iguales, error
(2) Si las claves no son iguales, continúo...

En estos casos se intenta buscar el lugar de la comparación para "atacar" en ese punto.
Si realizamos un dump del programa, podemos encontrar lo siguiente:



Basta ahora con buscar esa referencia y cambiar el JNZ (Jump No Zero) por JZ (Jump Zero); Es decir, realizamos la comparación "al negativo".
Con esto bastará para que si introducimos una clave incorrecta, ahora "salte" al procedimiento correcto y si introducimos la clave correcta nos de error y salga el cuadro de diálogo.

¿Porqué de esta explicación?
Bueno, creo que cualquiera que esté pensando en desarrollar un sistema de protección, debería al menos (como me tocó hacer a mi en su día) dedicar un tiempo a estudiar "mínimamente" los sistemas de "desprotección". Y esta explicación intenta ser la prueba y el "porqué" de ello.
He visto sistemas que calculan números y claves complejas a partir de los indicadores de Hardware del sistema e infinidad de números, y luego una vez realizado eso y con una clave "más larga que un día sin pan", resulta que hacen una comparación en memoria (como la del principio) para ver si es correcta. Lo que significa que has pasado 1 semana programando un sistema de protección que alguen con un poco de práctica se "salta" en 5 minutos.

Al igual que esta, hay una serie de "normas básicas" que cualquier sistema de protección debe evitar. Y a esas llegas a la conclusión cuando has visto cómo funcionan "mínimamente" los sistemas inversos de desprotección; De ahí mi recomendación de estudiarlos (un poquito, al menos), junto con las herramientas que se utilizan (NOTA).

No es mi interés que aquí la gente se dedique y aprenda a hackear/crackear programas y no es para eso para lo que he hecho esta explicación. Pero si somos programadores y realizamos sistemas de protección, más nos vale que aprendamos lo necesario, para que no sean una pérdida de tiempo. Al igual que se aprende lo fácil que es "saltarse" determinadas protecciones, también se aprenden técnicas que dificultan e incomodan muuuuuuuuuucho a la persona que está intentando desproteger el programa. Al menos que si lo van a hacer, lo tengan que "sudar"...

NOTA: Por otro lado, muchas de las herramientas que se utilizan para "desproteger" programas y aplicaciones, son muy potentes y pueden ser de mucha utilidad, si se usan en el día a día para un programador (realizando otras tareas), sobre todo relacionadas con errores, trace, y optimización de aplicaciones.

Un saludo.

[Casimiro Notevi]

[WkaymQ48]

Solo comentar dos consejos muy sencillos para evitar los errores comentados por neftali.

1. Usar un hash para las comparaciones. Es decir nunca guardar la clave en claro, guardar en su lugar un hash de la clave y hacer comparaciones del tipo hash(clave_introducida)=hash_guardado, así si alguien hace un debug no tendrá forma de averiguar la clave original.
2. Usar "inline". Para evitar que alguien no "borre" el "if" podemos utilizar un MONTON de "if", seguira pudiendo hacerlo pero si ponemos los bastantes puede que se aburra, ademas le sera dificil saber si los elimino todos. La forma mas sencilla de hacer esto es crear una función del tipo "function ClaveCorrecta: Boolean; inline;" y llamarla al principio de cada función de nuestro programa Al usar "inline" el código de la función se replicara tantas veces como se use por lo que nuestro "pirata" tendrá que parchear un montón de funciones.

No son la panacea, pero algo si ayudan

[look]

Empezado por Neftali

Tampoco había visto ese hilo... Interesante.


Basta ahora con buscar esa referencia y cambiar el JNZ (Jump No Zero) por JZ (Jump Zero); Es decir, realizamos la comparación "al negativo".
Con esto bastará para que si introducimos una clave incorrecta, ahora "salte" al procedimiento correcto y si introducimos la clave correcta nos de error y salga el cuadro de diálogo.

Hola amigo, esta muy interesante el tema, me gustaria saber cual seria el procedimiento para cambiar esos valores y que herramientas has utilizado para debugear el programa como se ve en las imagenes que muestras, y por las herramientas que mencionas para desproteccion y optimizacion ¿ Podrias mencionarme alguna?

[Neftali [Germán.Estévez]]

La herramienta para debug es OllyDbg; Ya la comentaba Seoane en el hilo original, con en que hemos empezado las pruebas.
Para temas de dependencias y saber qué ficheros se están utilizando, ya hemos hablado aquí alguna vez de Dependency Walker. Te aseguro que más de una vez me ha sacado de algún aprieto con errores "raros" por DLL's de versiones incorrectas.
DLLExp de NirSoft o ADLLExports para ver qué funcionan exportan las DLL's. Muy útil para saber si una determinada DLL trabaja como servidor COM, o conocer las cabeceras que exporta.

[giulichajari]

Empezado por Neftali

Estoy de acuerdo con Donald.
Prueba con una cosa sencilla que no te de muchas complicaciones y que te evite en simple "copy&paste" de la aplicación. Si la cosa va a más, ya pensarás en algo complejo.

Por ejemplo:

(1) Al ejecutar la aplicación compruebas una clave de registro o un fichero en el directorio de sistema.
(a) Si el fichero o la clave existe, continuas.
(b) Si no existe, generas una pantalla con un número aleatorio.
La persona que está ejecutando la aplicación debe llamarte (o enviarte un correo) y pasarte ese número;
Tú le devuelves otro número "relacionado" con el primero.
(2) Si el número que devuelves es correcto, grabas el fichero (o la clave de registro y continuas)
(3) Si el número no es correcto. detienes la ejecución.

Alguien con conocimientos pillará el fichero o la clave, pero al menos evita que alguien copie la aplicación directamente.

Esto sería lo más básico; A partir de aquí puedes ir añadiendo cosas para dificultar el asunto.

Y en donde puedo encontrar como crear el archivo plano que dice? me refiero a las ionstrucciones de como hacerlo?

[Neftali [Germán.Estévez]]

Para crear un fichero plano hay varias formas.
Si buscas en la ayuda de delphi la función rewrite, encontrarás un ejemplo como este, para crear y escribir en un fichero.

Código Delphi [-]
var 
  F: TextFile;
begin
  AssignFile(F, 'NEWFILE.$$$');
  Rewrite(F);
  Writeln(F, 'Just created file with this text in it...');
  CloseFile(F);
end;

También puedes usar un TStrings. Utilizando el método SaveToFile de esta clase también puedes crear un fichero (Busca en los foros y encontrarás varios ejemplos).

[StartKill]

Cita x Neftali

Basta ahora con buscar esa referencia y cambiar el JNZ (Jump No Zero) por JZ (Jump Zero); Es decir, realizamos la comparación "al negativo".

Cita x WkaymQ48

Usar un hash para las comparaciones. Es decir nunca guardar la clave en claro, guardar en su lugar un hash de la clave y hacer comparaciones del tipo hash(clave_introducida)=hash_guardado, así si alguien hace un debug no tendrá forma de averiguar la clave original.

A mi parecer Neftali de una otra forma mataría el artificio de WkaymQ48.

No estoy para ser negativo, mas deseo dar un pequeño aporte a este tema tan interesante: Algo que sea más trabajoso romper.

Creando el instalador del programa.
1ro. Entregar un KEY al cliente para instalar, ejemplo (T3V-5FW-TGY-XJ7)
2do. De alguna forma obtener el ADN de la PC a instalar el programa. (algo del hardware...)
3ro. Conectarse a un webService y enviar el KEY y ADN, alli en el server validar el KEY, si todo correcto el webService devuelve un HASH del ADN
4to. Con el HASH encriptar un archivo mochila: claves de acceso y/o valores de algunas variables del programa.(ojo: la idea es que sean valores necesarios para el programa)

Ejecutando el programa instalado
1ro. Obtener el ADN de la PC. (el paso 1ro del instalador)
2do. Crear un HASH del ADN
3ro Con ese HASH desencriptar el archivo mochila y asignar valores, claves de inicialización para el programa.

Si se copian el programa, este dará un ADN diferente por ser otra PC, y por consecuencia un HASH que no desencriptaría de forma correcta al archivo mochila.

* Si desean de vez en cuando hacen alguna validación en el webService


Your friend

StartKill
Lima-Perú

[StartKill]

Solo para satisfacer una curiosidad....

- Si bien es cierto una protección es difícil de romper siempre y cuando no se tenga idea de como esta hecha.

Your friend

StartKill
Lima-Perú

[Casimiro Notevi]

Empezado por StartKill

--- deseo dar un pequeño aporte a este tema tan interesante: Algo que sea más trabajoso romper.-

Básicamente, todo lo que pongas, por muy buena idea que sea, si no tienes en cuenta lo que ha indicado Neftalí, estás vendido