-^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:51 pm

Herramientas para la depuración

Yo
sé que todo esto que estoy explicando, si el lector nunca ha trabajado
con Ingeniería Inversa, pues puede resultar complicado... de todos
modos lo más difícil ya ha sido explicado, ahora vienen cosas "menos
técnicas"


Muchas herramientas para el cracking ya reconocen estos métodos comentados.

Para tener una idea de la "fuerza" de algunos programas explicaré el archiconocido OllyDBG:
OllyDBG
es un debugger a 32 bits (en ring3) potentísimo. Yo casi me atrevo a
decir que para ring3 es el mejor. Desde su aparición, que al principio
no causó buena sensación, fue sumando adeptos y su despegue ha sido
brutal. Tiene una opción que es la posibilidad de insertar plugins...
así que programadores de todo el mundo han hecho millones de plugins
para este debugger. Unos plugins que hacen que OllyDBG sea una
herramienta esencial e invisible a todo: sólo con un click de ratón, es
posible anular ¡todas las protecciones anti-debugger que vimos en el
apartado anterior!.
Con esto demuestro la magnitud de este programa. Es impresionante.

Hasta ahora sólo he comentado la existencia de dos herramientas: debuggers y desensamblador es, sin embargo, existen muchísimas más que hacen que todo cracker tenga las cosas bien fáciles.

No
todas estas herramientas están preparadas para detectar los trucos
anti-debugger/desensambladores que vimos en el apartado anterior, así
que es bueno por este motivo poner siempre algún tipo de protección de
las ya vistas.

Hay herramientas específicas incluso para cada
lenguaje de programación con que la aplicación haya sido compilada. Por
ejemplo para programas compilados con Visual Basic hay aplicaciones
como VB Decompiler, VB Reformer, SmartCheck (de verdad éste último es impresionante) etc.. para compilaciones con Delphi o Borland C++ tenemos Dede, E2A, MiniDe etc...
Todos
estos programas ofrecen una ayuda al debugger muy precisa, con lo cual,
el cracker rápidamente llega a la "zona caliente" que le interesa.
Excepto Smartcheck que también actúa como "debugger", los demás
normalmente trabajan analizando el código, por lo cuál determinadas
protecciones anti-debugger no valen para nada.

Cada programa,
cuando está ya compilado hay que tratarlo de forma muy diferente, por
ej. un programa que haya sido compilado con Visual Basic ya se sabe que
necesita de su librería de apoyo para funcionar , un programa en Delphi
tiene bastante código ya que incorpora todo lo necesario en él para
funcionar, los programas en NET suelen resultar muy requetefáciles de
romper e incluso encontrar seriales también suele ser tarea
relativamente sencilla.
Personalmente los programas en Delphi o
Borland C++ me resultan los más difícultosos a la hora de analizar ya
que cuando se realiza alguna función no se realiza directamente, sino
que se envía un valor (normalmente 0 o 1) a un lugar de la memoria y
posteriormente ese valor será tratado, me explico:
Si nosotros queremos activar un botón, por ej. en ensamblador haremos:
Call Activar_botón
Simplemente ejecutando esa subrutina (Activar_botón) el botón se activará.

Si ahora lo hacemos en Delphi o en Borland C++:
Call Activar_botón
Al
pasar esa subrutina el botón NO se activa!! simplemente en un lugar de
la memoria se habrá puesto un 1 y ese 1 será el que haga activar el
botón más tarde.

Como se observa cada programa y según con qué lenguaje de programación fue escrito hay que tratarlo de forma muy diferente.

En
todos estos casos, debes ver con qué lenguaje de programación trabajas
y de este modo puedes implementar en tu aplicación alguna medida contra
estas herramientas.

Como comenté antes existen debuggers
(OllyDBG por ejemplo) que son invisibles a todo. Incluso algunos
utilizan drivers para ejecutarse por debajo de donde las aplicaciones
trabajan: ring3.
Yo pienso que es por este motivo que, como comenté
al principio, los software especializados en protecciones no se
preocupan tanto de poner trampas anti-debugger sino en "romper" el
ejecutable para que no sea recompuesto... esta es la misión del
cracker: recomponer el ejecutable que ha sido desmenuzado por un packer.

Voy a bajar el "listón" para que se entienda perfectamente:
-Un packer tiene dentro de sí mismo al ejecutable que se ha protegido. El packer se va descomprimiend o
poco a poco, desencriptándose, realizando chequeos anti-debugger etc...
hasta que llega un momento, cuando se ha descomprimido del todo que
pasa la ejecución al programa que se ha protegido... y ¡zas! ahí entra
el cracker a jugar. En ese mismo momento es cuando el cracker para todo
y reconstruye poco a poco el puzzle. Como ya se sabe hay puzzles
fáciles, y muy difíciles. Sin embargo, con tiempo todo puzzle se puede
hacer.

Ese momento en el que ya se ha descomprimido todo y pasa
a ejecutarse la aplicación protegida, es diferente también según qué
compilador hayamos utilizado, por ej. en Visual Basic suele ser muy
fácil llegar a este punto.

LLegados hasta aquí, ya sé que muchos
se preguntan... pero yo quiero hacer mis protecciones y quiero fabricar
un programa DEMO y licencia y.... ahora lo veremos en el siguiente
apartado.
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: