FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
Proteccion de software
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. |
#2
|
||||
|
||||
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.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#3
|
|||
|
|||
Gracias de vuelta
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 |
#4
|
||||
|
||||
Cita:
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. |
#5
|
|||
|
|||
Ok.
Cita:
|
#6
|
||||
|
||||
Cita:
Saludos. |
#7
|
||||
|
||||
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.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#8
|
||||
|
||||
Hola giulichajari.
Tal vez también te resulte de interés este enlace: Guardar datos en un ejecutable. Saludos.
__________________
Daniel Didriksen Guía de estilo - Uso de las etiquetas - La otra guía de estilo .... |
#9
|
|||
|
|||
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 |
#10
|
||||
|
||||
No había visto ese hilo, interesante.
|
#11
|
||||
|
||||
Cita:
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.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. Última edición por Neftali [Germán.Estévez] fecha: 11-07-2013 a las 12:31:18. |
#12
|
||||
|
||||
#13
|
|||
|
|||
Solo comentar dos consejos muy sencillos para evitar los errores comentados por neftali.
No son la panacea, pero algo si ayudan |
#14
|
||||
|
||||
Cita:
__________________
all your base are belong to us |
#15
|
||||
|
||||
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.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#16
|
|||
|
|||
¿Y como lo hago?
Cita:
|
#17
|
||||
|
||||
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.
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).
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#18
|
||||
|
||||
Cita x Neftali
Cita:
Cita:
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ú |
#19
|
||||
|
||||
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ú |
#20
|
||||
|
||||
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
|
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Protección anticopia... ¿ sí o no ? | rretamar | Debates | 11 | 10-04-2013 19:37:34 |
Proteccion de software | edgwin | Varios | 5 | 14-11-2009 00:41:17 |
Alguien ha visto el Software llamado DIA de Software Libre? | eddg | Varios | 0 | 29-09-2007 17:16:45 |
Protección de archivos mdb | Gabo | Conexión con bases de datos | 3 | 05-09-2007 18:40:11 |
Encriptacion de datos y proteccion de software | Wanderer | OOP | 2 | 12-03-2004 08:46:37 |
|