FAQ 1 WKT Tutorialz Site FAQ 2
WKT
[WkT!] FAQ We'll Rock in 1999

Introducción
Estas leyendo la FAQ Oficial de [WkT!]. Este proyecto fue iniciado en su momento (1997) por Mr.Red [WkT!], y ahora volvemos a reabrirlo para deleite de todos nuestros lectores. La versión inglesa aún no esta disponible, y es posible que nunca llegue a ver la luz. A no ser que algún alma caritativa se ofrezca voluntaria a iniciar la traducción. Algún voluntario????
Si es así, por favor envianos un e-mail.
Si tus dudas aún no están resueltas en esta FAQ, [WkT!] te recomienda que te pases por la Web de Gerza, donde encontrarás la FAQ Oficial del
"Spanish ReverseEngineering Forum".
Si alli tampoco encuentras lo que buscas, utiliza ese foro.


¿Cual es el objetivo de [WkT!]? ¿Por que un grupo de crackers hispano?
¿Qué es el Cracking?
¿Qué es un debugger?
¿Qué es un desensamblador?
¿Qué es un editor hexadecimal?
¿Todos los programas se desprotegen de la misma forma?
¿Qué diferencias hay entre programas hechos en Visual C++ y Visual Basic?
¿Cómo saber si un programa esta hecho en Visual Basic?
¿Qué es una DLL?
Pongo un break point en Winice y nunca para el programa en él
Cuando paro un programa con Ctrl+D en Winice me aparece el listado en una zona llamada KERNEL32


¿Cual es el objetivo de [WkT!]? ¿Por que un grupo de crackers hispano?
Desde sus orígenes, el objetivo de Whiskey Kon Tekila ha sido, es y será siempre proporcionar información. Por diversos motivos (principalmente económicos) la Ingeniería Inversa siempre se ha considerado un tema "tabú" en la Informática. Y como tal, el desconocimiento técnico en este sentido ha sido notable.
(Al menos en el mundo hispano hablante).

[WkT!] surge como un grupo de gente apasionada por la programación de protecciones hardware/software, con el único propósito de ampliar su conocimiento y el de cualquier otra persona interesada al respecto. Los programadores de aplicaciones comerciales suelen actuar con una cierta indiferencia cuando se trata de programar la protección de su software. Quizá sería más correcto afirmar que más que indiferencia se trata de inconsciencia. Desconocimiento, en definitiva, de las técnicas empleadas desde "el otro lado".

Es por esto que estas páginas constituyen (o eso se pretende) un punto de referencia para todo aquel programador realmente interesado en ampliar sus conocimientos y adaptarlos a los nuevos tiempos.
[WkT!] es consciente de que la información proporcionada en su Web Site puede llegar a ser un "arma de doble filo", puesto que nada impide el posible mal uso de esa información por parte de nuestros lectores. Ante esto cabría plantearse unas cuantas cuestiones:

  • ¿Hasta donde llega el conocimiento sobre Ingenieria Inversa del programador hispano?
  • Cuando un programador desarrolla una protección.... ¿es consciente de sus limitaciones?
    ¿Sabe cómo buscar sus puntos débiles? ¿Quiere realmente ELIMINAR esos puntos débiles?
  • El problema de la piratería de software .... ¿Es acaso una consecuencia de la sociedad consumista actual? ¿O se debe en mayor medida a los elevados precios del mismo?
  • ¿Por qué algunos de los mejores y tambien más caros programas son al mismo tiempo los que peores protecciones incorporan? ¿Hasta que punto preocupa la protección de su software a las grandes compañias?
  • Cuando alguien utiliza un crack... ¿Es porque quiere evaluarlo mejor antes de comprarlo?
    ¿Lo hace porque no puede pagar el programa en cuestión?
    ¿Lo hace porque no quiere pagarlo? Si es así.... ¿es consciente del daño que puede ocasionar?
  • Realmente, ¿Que deberia estar más sujeto a una "persecución social"?
    ¿El uso ilegal de un programa o la programación / administración inadecuada e insegura del Software?

Quizá estas sean algunas de las cuestiones más polémicas, pero que en definitiva nos hacen reflexionar a todos si el estudio de la Ingenieria Inversa deberia dejar de ser considerado como algo dañino e inapropiado para ser más tenido en cuenta a la hora de programar una aplicación comercial. Y es que, en definitiva, el mejor modo de avanzar en el conocimiento es investigar y para ello el primer paso es conocer nuestro propio software. Espero que esto te haya aclarado un poco la situación. De todas formas, gracias por haberlo leido.
Un saludo. Mr.WhiTe [WkT!]
¿Qué es el Cracking?
No tiene nada que ver con las drogras...(el famoso Crack) : (

"Crackear es el arte de reventar protecciones software/hardware con fines intelectuales, personales pero no lucrativos. Crackear también se llama "ingeniería inversa" (Reverse Engineering), ya que sin el programa fuente  se es capaz de analizar el comportamiento del programa y modificarlo para tus intereses."
Ref.- Como crackear por Estado Porcino.

¿Qué es un debugger?
Permite ver  paso a paso (instrucción a instrucción)  un programa mientras se está ejecutando en la memoria del ordenador.
Las instrucciones se visualizan en ensamblador normalmente. Nos servira para ver como se comportan las rutinas de protección ya que son parte del programa. En el podremos cambiar instrucciones para comprobar y asi eludir las protecciones. Estos cambios no son permanentes en el fichero ejecutable.

El mejor debugger es SoftIce (Softice para Windows 95) http://www.numega.com
Para MSDOS existe una versión Softice y otras versiones poco potentes llamadas DEBUG y SymDebug.

¿Qué es un desensamblador?
Un desensamblador toma un fichero de instrucciones en hexa y lo convierte a lenguaje ensamblador. El lenguaje ensamblador, es el conjunto de sentencias que entiende el microprocesador
(tu Pentium o mi 486). El procesador es el corazón del ordenador, todas las sentencias son ejecutadas por él y sólo por él.
Por ejemplo un 43 en hexa se transforma en inc eax. Se necesitan algunos  conocimientos de ensamblador pa esto de crackear.
Nosotros usaremos el desensamblador para crakear con la técnica de la lista muerta...
Ref.- Como crackear por Estado Porcino.
¿Qué es un editor hexadecimal?
"Los programas no son más que un conjunto de instrucciones y cada instrucción no es más que un conjunto de bits, pero donde demonios se guardan esos bits?. Los bits del programa se localizan en los ficheros, p.e. las instrucciones del programa de compresión arj se guardan en el fichero arj.exe. Hay algunos programas que no guardan todas sus instrucciones en único fichero, si no en varios, un ejemplo de esto son los programas que utilizan librerías dinámicas (o dll)."

Un editor hexadecimal, no es más que un programa, que permite "editar" los ficheros de instrucciones de otros programas, osea, que permite ver,modificar,copiar,pegar... los bits de los programas. Para simplificar la cosa no se muestran los bits a pelo, sino que se muestran en hexadecimal, de ahí su nombre.

Nosotros lo utilizaremos para  alterar el comportamiento de los programas. Supongamos que conocemos la instrucción sentencia de la rutina de protección que debemos modificar, sea jz 23 y queremos modificarla por jnz 23, bien como toda instrucción no es más que un conjunto de bits, sea 0110 para jz 23 y 1001 para jnz 23, sólo nos queda buscar estos bits dentro del fichero ejecutable del programa (que es, en general, el contiene las sentencias del programa). Como usamos un editor hexadecimal, debemos buscar la secuencia de un unos y ceros en hexa en el fichero del programa que queremos modificar. Si la secuencia que buscamos es muy común deberemos utilizar las instrucciones que se encuentran entorno a la instrucción a modificar.

Esto es muy importante, sólo debe existir una localización del patrón de búsqueda en el  fichero, si existe más de una, debemos añadir a la búsqueda las sentencias de alrededor, sino se corre el riego de modificar la sentencia equivocada, lo que provoca casi siempre un "cuelgue".
Ref.- Como crackear por Estado Porcino.
Uno de los más completos es  UltraEdit-32 Professional http://www.uedit.com
¿Todos los programas se desprotegen de la misma forma?
No...
Un programa aún haciendo lo mismo puede programarse de mil formas... Esto se entiende en las protecciones del mismo modo (protecciones de numero de serie, etc..).

Pueden existir miles de formas de proteger un programa, aún siendo el mismo tipo de protección.
No obstante la "estupidez" de muchos programadores de pacotilla (aquellos que solo ven dinero en sus programas), y a la falta de imaginación de otros, hacen que la tarea de desproteger sea a veces muy sencilla.
¿Qué diferencias hay entre programas hechos en Visual C++ y Visual Basic?
La mayoría de las aplicaciones programadas mas profesionalmente para Windows 95 (requieren un conocimiento mas exhaustivo de programación) son las compiladas en  C++... aparte de ser siempre las mas rápidas.
De hecho Windows 95 está hecho prácticamente en C++...

La diferencia entre Visual C++ y Visual Basic es la siguiente:

Con Visual C++ somos como el director general de una oficina mientras que con Visual Basic somos los empleados (si entregamos un informe pasaremos por varios departamentos hasta que llegue al despacho del director general).
E incluso no podremos hacer cosas que no pueda hacer el director general. Todo ese proceso interno de pasar de un departamento a otro lo realizan unas librerías que actúan mientras se ejecuta el programa (librerías Run-time). Estas son VBRUN300, VB40032, MSVBM50 según sea la versión de Visual Basic.

Desde el punto de vista de un cracker es mucho mas interesante un programa en C++...
Los crackers suelen huir de programas hechos en Visual Basic, por lo incomodos y pesados que son y porque casi nunca aportan nada interesante que investigar. Aunque esto no significa que sean los mas dificiles de desproteger.
¿Cómo saber si un programa esta hecho en Visual Basic?
Existen muchas maneras, pero todas consisten en lo mismo. Hay que localizar  referencias a varias librerias de ejecucion. Sus nombres son VBRUNxxx (xxx =100,200,300  para la versión 1,2 y 3 respectivamente), VB40032.DLL para la versión 4 del compilador de Visual Basic y MSVBM50.DLL para la versión 5. Las formas de localizarlas podrían ser:
  • Usar un editor hexadecimal con el fichero EXE a tratar y usar la opción de busqueda....     Ejemplos de texto a buscar:  VBRUN300, VB40032, MSVBM50
  • Usar un desensamblador (W32Dasm) con el archivo EXE y una vez desensamblado mirar al principio del listado en la zona de :

  • +++++++++++++++++++ IMPORTED FUNCTIONS ++++++++++++++++++
    Number of Imported Modules =    1 (decimal)

       Import Module 001: MSVBVM50.DLL

Aquí se observa una referencia a la libreria de ejecución de Visual Basic 5.0, con lo que este ejecutable está compilado con VBasic.
¿Qué es una DLL?
Es una librería dinámica (Dynamic Link Library). Es un fichero en el que residen funciones(código ejecutable) o recursos (ventanas de un programa, menues, iconos, bitmaps, etc...) y que pueden ser llamadas por cualquier otro programa de Windows. Existen  una gran variedad de  DLL personalizadas y  comerciales que permiten sacar partido a muchos programadores (Jscript.dll =librería de Java Script, Tl32v20.dll =Timelock, rutina de protección de programas en periodo de prueba, etc...).
De hecho Windows 95 usa en su mayoria DLLs... KERNEL32.DLL, USER32.DLL, GDI32.DLL...
Incluso los archivos DRV y FON  (fuentes) son DLL, aunque estos se cargan de forma no automatica...
Pongo un break point en Winice y nunca para el programa en él
Hay muchas  instrucciones de programas que nunca se ejecutan si no se dan las condiciones adecuadas...
Siempre conviene estudiar un poco el ejecutable, o bien con la lista muerta o con el Winice.
Poner en cualquier punto del programa un breakpoint no lleva a nada si no sabemos donde lo ponemos.
Cuando paro un programa con Ctrl+D en Winice me aparece el listado en una zona llamada KERNEL32
Esto es muy normal, teniendo en cuenta que Windows 95 usa internamente un API
(Interfaz de Programación Avanzada)  núcleo de sistema (Kernel) de 32 bits.
El kernel32 es el minimo de código que necesita Windows95 para arrancar el sistema.

También la mayoria de los programas suelen usar esta API para realizar operaciones basicas con sus funciones( uso de archivos, tareas, recursos, carga de librerías, uso de la memoria, etc..). Hay unas 780 funciones dentro de esta librería.
Muchas rutinas de protección  hacen uso de funciones de esa librería y de otra llamada USER32.DLL.

Para nosotros el listado interno de estas librerias no interesa. Usaremos estas funciones como cajas tontas (solo interesará lo que nos muestre por fuera no como esté hecha por dentro). Es decir, si un programa usa la función GetComputerName (obtener el nombre de la computadora), solo nos interesará el nombre que la computadora, no como lo obtiene internamente.