| FAQ 1 | WKT Tutorialz Site | FAQ 2 |
 |
 |
 |
| [WkT!] | FAQ | We'll Rock in 1999 |
| FAQ 1 | WKT Tutorialz Site | FAQ 2 |
|
|
|
| [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? |
|
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:
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."
|
| ┐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
|
| ┐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:
+++++++++++++++++++ IMPORTED FUNCTIONS ++++++++++++++++++ Number of Imported Modules = 1 (decimal) Import Module 001: MSVBVM50.DLL |
| ┐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. |