-^Blue Hacking^-

El mejor hacking al alcance de todos
 
ÍndiceFAQRegistrarseConectarse

Comparte | 
 

 PROTEGE TU PROGRAMA (PARTE3)

Ver el tema anterior Ver el tema siguiente Ir abajo 
AutorMensaje
nacherfaller
Admin
Admin


Mensajes : 123
Fecha de inscripción : 28/09/2008
Edad : 22

MensajeTema: PROTEGE TU PROGRAMA (PARTE3)   Miér Oct 15, 2008 9:52 pm

Quiero hacer yo mismo mi propia protección

Este
apartado lo podríamos llamar consejos de gente que trata con
"Ingeniería Inversa". Consejos para que tu aplicación sea más difícil
de analizar.

Cuando se implanta una licencia, hay que tener presente que esa licencia es para un usuario y normamente es así:
1-Nombre del usuario
2-Contraseña del usuario

Ambas
tienen una relación que sólo debe conocer el autor de la aplicación.
Hay otros programas que simplemente con poner un serial ya está
registrado correctamente. Me basaré en el primer caso: Nombre y
contraseña.

Caso 1 - Protección (0 a 10): 1

Muchos
programadores ponen la relación nombre-contraseña muy difícil de
analizar: pasan los datos de nombre al valor ASCII que corresponda y
realizan infinidad de operaciones matemáticas. Hasta aquí muy bien,
pero...
después de realizar esas operaciones matemáticas comprueban
directamente ese resultado con el serial. Ahí está la debilidad: si se
compara directamente con el serial será muy fácil encontrarlo,
simplemente hay que pararse en la comparación y veremos la contraseña
correcta.
Puedo asegurar que infinidad(requetemuchísimos) de programas hacen esto comentado.

¿Cómo se puede arreglar?
Pues
bien, todo programador debe saber una cosa lo más básico de todo: si el
serial verdadero aparece directamente en memoria por cualquier causa,
en menos de lo que canta un gallo será encontrado por cualquier Newbie.
Hay
que evitar sea como sea la comparación directa del serial. Hay muchas
formas, una por ej. sencilla es poner el valor ASCII también al serial
y realizar otra serie de operaciones matemáticas...

Caso 2 - Protección (0 a 10): 2

Imaginemos un programa que la licencia para mi es:
Nombre: karmany
Serial: 1234
El chequeo que hace para la comprobación es:
Código:
Citar
Nombre: karmany --> pasa a valor ASCII --> operaciones matemáticas --> resultado final: 564
Serial: 1234 --> pasa a valor ASCII --> operaciones matemáticas --> resultado final: 564

Como
se observa. ya no se compara el serial directamente pero tiene asímismo
una gran debilidad: debe comparar esos resultados: 564
Esto en
ensamblador aparecerá también como una comparación y aunque no tengamos
el serial podemos modificar directamente el resultado de la comparación
porque es una comparación: registrado- no registrado. Estaría crackeado
en poco tiempo por un Newbie recién iniciado.
Hay que evitar esas comparaciones.

Caso 3 - Protección (0 a 10): 2-3

Imáginemos
que tenemos el caso 2 en el que cuando introducimos una contraseña
falsa nos aparece un mensaje que dice: "Contraseña no válida"
Sabemos que para el registro hay que comparar los 564 pero ¡hay que encontrarlos primero!
Lo
primero que hace un cracker es ver: las 'string references', es decir,
las cadenas de texto. Normalmente cualquier cadena de texto que se
utilice en un programa, aparece literalmente en el mismo. Por este
motivo, si cuando un usuario pone una contraseña correcta, aparece un
mensaje que dice: "Gracias por registrarse" no dude ni un segundo que
lo que primero va a buscar el cracker son esas palabras. Y cuando las
encuentre irá directamente a parar a la comparación de 564 con 564.
Por todo esto que estoy comentando, hay que evitar las cadenas de texto literales.
Tú eres programador, esto te lo dejo a tí, hay mil formas.

Si
partimos del Caso 2 y hemos eliminado toda referencia de texto, ya
estamos protegiendo nuestra aplicación contra un número de Newbies. Sin
embargo, este último, aunque tenga muy poca experiencia, con el tiempo
encontrará esa comparación 564 con 564 y la modificará.

Caso 4 - Protección (0 a 10): 2-3

Partimos del Caso 3.
¿Qué
ocurre cuando hemos introducido un código correcto? Muchos programas
modifican cierto byte de ellos mismos de tal modo que si está el
registro correcto el byte es 1 y si no está registrado el byte es 0.
Estamos
en el Caso 4 y ya no resulta fácil encontrar un nombre-serial válido,
pues el programador hace millones de operaciones matemáticas para
obtener esos 564.
El cracker puede optar por dos sencillas opciones:
-modificar la comparación de 564 para que cualquier nombre-serial valga
-ver después cuál es el byte que se pone a 1 cuando nos registramos.

Sabiendo esta segunda forma, el cracker directamente modificará permanentement e ese byte a 1 y ya no hay que poner ningún nombre-serial porque ya será una versión registrada.

Caso 5 - Protección (0 a 10): 5-...

Cada persona es diferente así que lo que a mí me parece fácil a otro le parecerá difícil y viceversa.
Para mí un protección 5 ya es un tema para estrujarse las neuronas.
Partimos
del caso anterior pero cuando está registrado ya no depende sólo de un
byte. Para hacer esto podemos hacer que de vez en cuando sea comparado
el nombre-serial, pero tenemos el problema de siempre: llegamos a la
comparación de antes: 564 que hay que eliminar.
En ensamblador las
comparaciones directas suelen hacerse con la instrucción cmp y después
viene un salto por ejemplo "je" o "jne". El cracker lo primero que
probará será modificar tras la comparación el "je" por un "jne" o
viceversa.

Sólo pensando un poco se le pueden ocurrir a uno
muchísimas formas de evitar que se compare directamente 564 con 564.
Por ejemplo, con el nombre realizamos operaciones, con el serial lo
mismo. Después realizamos operaciones con los valores obtenidos dando
un valor de resultado. Con ese resultado podemos desencriptar parte de
código. El problema de esto es que ese valor es siempre el mismo para
cualquier nombre-serial.

Se pueden también realizar diversos
chequeos, por ej. se puede examinar si la comparación 564 con 564 ha
sido modificada, en tal caso no mostrar un mensaje inmediato ya que
alerta al cracker y el mensaje le sirve de guía.

Se pueden
realizar chequeos CRC, se pueden utilizar archivos para la licencia
(keyfiles) donde cada archivo licencia es diferente según usuario.

Si
no se te ocurre ninguna forma de ocultar la comparación 564 puedes
hacer una cosa y es hacer esa comparación en memoria dinámica ya que
ahí el cracker no puede modificar el "je" por "jne" porque en el
ejecutable no existe todavía.

Si tu programa requiere actualizacione s
de cualquier tipo, lo tienes bastante fácil porque según el
usuario-serial tú puedes permitir la descarga o no de actualizacione s, aunque el programa esté crackeado.


Hay
muchas formas que deben salir de tu imaginación. Cada programa es un
mundo, como cada persona. Incluso para saber proteger una aplicación
puedes analizar tutoriales de cracking, que te enseñarán las
protecciones más comunes que se suelen utilizar.
Volver arriba Ir abajo
Ver perfil de usuario http://bluehacking.coolbb.net
 
PROTEGE TU PROGRAMA (PARTE3)
Ver el tema anterior Ver el tema siguiente Volver arriba 
Página 1 de 1.
 Temas similares
-
» Celtx. Un programa para escribir guiones.
» Programa que mejore el rendimiento de nuestra RAM ?
» no se donde se ha ido un programa
» alguien me recomienda un programa, para crear letras animadas para poner en mi foro?
» Algun programa para instalar un RPG??? juegos...

Permisos de este foro:No puedes responder a temas en este foro.
-^Blue Hacking^- :: Hacktivismo :: Hacking Novatos-
Cambiar a: