Todo lo que siempre quisiste saber, y nunca nadie supo decirte: ¿Como crackear un Juego?
Aqui aprenderas, con el tiempo, desde como llegar al final de cualquier juego, sin dificultades, hasta como eliminar las claves de los mismos, con ejemplos e ilustraciones, para que hasta tu, puedas hacerlo, no te ofendas.
-- Antes de empezar, quiero decir que nada de los que hay aqui infringe la ley, salvo la utilización que tu hagas de la información, es como los zapatos, no es ilegal llevarlos ni que te los vean, pero seguro que te detienen si vas por hay usandolos para tirarselos a la cabeza a la gente.--
Parte I: Las partidas salvadas son faciles | Parte II: La memoria es incierta |
Parte III: Que molestas son las claves | Parte IV: Algunos prog. de interes |
Parte I: Las partidas salvadas son faciles
Antes de empezar, aviso que será necesaria alguna utilizadad capaz de abrir un archivo binario y mostrarlo de forma hexadecimal. Visita la "Parte IV", para y consiguete alguno. Si te sirve de algo, yo utilizo el TurboDebuger de Borland Inc. a parte, es el que necesitaras utilizar en la "Parte III", o almenos otro parecido.
¿Tienes ya las herramientas?
Vale, empecemos con un poco de teoría:
Cuando un juego graba una partida, normalmente lo hace de forma ordenada, siempre coloca en las mismas posiciones cosas similares. Estos datos no son mas que la posición y estado en que se encontraba el juego, justo en el momento de salvar la partida. Algunos de estos datos son fáciles de localizar como "vidas, energía, cantidad de disparo...".
¿Cómo buscar?, Bien, lo que debemos hacer es grabar un mínimo de tres partidas, con tres estados diferentes del valor que nos interesa mantener, (por ejemplo la cantidad de dinero). Acto seguido buscaremos las coincidencias de esos valores, en los tres o más archivos, hasta encontrar una coincidencia en todos y que se encuentra en la misma posición, esa será la posición de lo que buscamos, no tenemos mas que camibiar el valor, (cambiando asi la cantidad de dinero, ejem.).
No te apresures, debes saber que los números no se almacenan como piensas, sino que depende de tu máquina: existen del tipo LittelEndian (parte baja del nº primero) o BigEndian (parte alta del nº primero) caso del PC.
(d)ecimal / (h)exadecimal
Ejemplo:
Si buscas el número 34.500d --> 86C4h
Se guardará la parte alta (8 bits) primero y la parte baja (8 bits) despues: C486h.
Eso no es todo, ¿Cómo es de grande el número que buscas?. Debes pensar como un programador, o almenos con un poco de intuición. En el ordenador, los números, vienen representados, como norma general, en bloques de 8 bits, o lo que es lo mismo 1 byte.
Si lo que buscamos es el lugar de almacenamiento de las vidas, es lógico pensar que para ello han utilizado un simple "byte". A continuación os enseño cuantos bits, ocupan los ditintos tipos de números que existen, y cual es la cantidad máxima que pueden contener, (con o sin signo).
Tipo Longitud Rango unsigned char 8 bits 0 to 255 char 8 bits -128 to 127 unsigned int 16 bits 0 to 65,535 int 16 bits -32,768 to 32,767 unsigned long 32 bits 0 to 4,294,967,295 long 32 bits -2,147,483,648 to 2,147,483,647 Nota: Si el número que buscas esta dentro del rango de arriba, aunque no esté completo debes rellenar lo que falta al buscar.
Ejemplo:
Buscamos el dinero, y en este momento tenemos 10 creditos, pero sabemos que podemos tener hasta 20.000 creditos como máximo -> el número estará en el rango de los enteros (int 16bits).
Al buscar 10d hemos de escribir A000h, ¿no?, Pues no, recuerda que tu máquina es BigEndian por lo que tendras que escribir 00A0h.
Si te has empapado bien de la teoría, podemos pasar a un ejemplo práctico, que aplicaremos al juego Civilization 2:
Buscamos la posición física del dinero, dentro de la partida salvada.
1º ¿Qué sabemos? Sabemos que el dinero puede sobrepasar los 256 creditos asi que el dinero ocupo, por lo menos 16 bits.
2º Hemos salvado tres partidas; ( a1.sav | a2.sav | a3.sav ), con ( 300 | 75 | 250 ) creditos respectivamente.
3º Pasamos las cantidades a hexadecimal y agrupamos las partes altas y bajas: ( 300d = 12Ch | 75d = 4Bh | 250d = FAh )
4º Buscamos las primeras coincidencias en cada archivo de las cadenas ( C012h | 004Bh | 00FAh ).
¿Coinciden las posiciones física? No = continua en el paso 4º.
5º Hemos encontrado la posición física, cuanto queriamos ¿ 20.000 creditos ?. Pues 20.000d = 4E20h, por lo que sustituimos el valor a partir de la posición encontrada por 20E4h, recuerda: BigEndian.
Fin del Capitulo, si te queda alguna duda dimelo, de ese modo, sabré los puntos debiles de este tutorial, y los elimaré para de ese modo ir perfeccionandolo.
Parte II: La memoria es incierta
Lo que quiero decir, es que la memoria es incostante, todo en ella cambia, lo que ahora esta en una posición, dentro de cinco minutos, estará en otra.
Todo lo dicho en el capitulo anterior, sería aplicable a este, de hecho, para juegos antiguos de MS-DOS, es totalmente valido, incluso existen aplicaciones (ver. Parte IV) para ello. El problema de ahora, es que todo es dinámico, todo cambia, y es mas dificil localizar, lo que buscamos. Pero a pesar de esto, siempre existe el orden dentro del caos, y para aplicar las lecciones anteriores, se requieren cierta modificaciones a nuestra forma de pensar.
Ahora, lo constante, no son las posiciones físicas que contienen los valores, sino punteros, dirigidos a esos valores. La busqueda, a partir de ahora es tediosa y complicada, pero el fruto de esta busqueda es el conocimiento del orden, mediante el cual podemos construir un pequeño programa que se ejecute en segundo plano, bloqueando el contenido, apuntado por el puntero, del cual siempre conoceremos su posición física.
Para la localización del puntero, debemos realizar los pasos de la Parte I, pero aplicados a memoria, una vez conocida la dirección, buscaremos por todo el rango de memoria destinado al programa, valores que concuerden con la dirección física (segmento:desplazamiento), del valor. DirecciónP = dirección física - dirección de carga del programa.
Una vez conocida estas direcciones, el programa de segundo plano, estará continuamente o cuando se requiera, escribiendo en la direccion apuntada por el puntero. La dirección del puntero, será la dirección de carga del programa + DirecciónP.
Podemos ver ejemplos de esta parte, por ejemplo, en los programas residentes que te permiten cambiar los niveles de oro, petroleo, y leña en Warcraft 2, yo poseo esos programas si os interesan...
Si no incluyo ejemplos de esta sección es poque requeririan conocimientos de programacion Muy Altos, y aquel que los tenga, seguro que con solo leer esto, sabe como encaminar mas o menos sus pasos, si no, siempre puede preguntarme las dudas que tenga.
Parte III: Que molestas son las claves
Este capitulo es algo más complicado, y en él aprenderemos a eliminar la ya casi obsoleta protección o claves de los juegos. Debo decir que aunque trataré de simplificar el tutorial, lo mas que pueda, serán imprescindibles conocimientos medios/altos de programación, así como algunas nociones de ensamblador.
Las herramientas necesarias, vuelven a estar disponibles entre las aplicaciones de la "Parte IV". Necesitaremos un desensamblador, (hasta el debug de MS-DOS puede servirte).
La Teoría:
Cualquier aplicación no es mas que una serie de instrucciones una detras de otras, cada una de ellas con una función especifica. Si intentamos profundizar cada vez mas, (espera, retrocede, vale hay esta bien), hasta llegar a las instrucciones antes de ser decodificadas nos encontramos con ordenes simples del tipo Mov AX, BX ó JNZ ###.
Si realizamos un seguimiento del programa en cuestion, llegaremos al momento de las claves, tras introducir una, (cualquiera no valida), seguro que unas cuantas instrucciones mas tarde se realiza una comparacion CMP, y un salto J**, es aquí donde intervenimos nosotros, los opcode de los saltos son de la misma longitud, por lo que no tendremos problemas.
Pregunta: Si el salto es tal que JE, ¿qué pasaría si lo cambiasemos, digamos por JNE?.
Respuesta: Cualquier código introducido al azar provocará que la aplicación crea que es correcto (de hecho, ahora lo es), y solo cuando tengamos la mala suerte de introducir un código correcto, nos expulsará la aplicación, diciendo: CODIGO NO VALIDO.
Para el ejemplo práctico usaremos debuger de MS-DOS, intentaré ser lo más descriptivo posible. Nuestra victima será, será Juego.exe, dado que sería ilegal incluir un programa real para eliminar su protección, eliminaremos el de este programa ejemplo, que puedes bajarte de aquí mismo.
write.textfile('dbug.txt')
No te preocupes, seguro que muchos de los que intenten seguir el documento anterior no llegarán a nada. Reconozco que es bastante complicado.
Esta es, como se suele decir, la puerta trasera. Las claves estan siempre en el mismo orden, ¿cómo? ¿qué cada vez que te pide una clave tu juego, es una clave distinta?. Bueno, eso es por que no sabes que lo único que pasa es que la aplicación busca una clave al azar, pero el azar no existe, (ver mi pág. de pensamientos filosóficos). Para extraer una clave al azar, por lo general, las aplicaciones se basan en el reloj del sistema, por lo que:
Hipotesis: si cambiamos la fecha y hora, a momentos constantes, y cargamos una vez, tras otra el juego (previo arranque al juego, cambiamos siempre fecha y hora), la clave que se extrae es siempre la misma (por lo que si la clave es simplemente escribir un nº entre 1 y 100, de entre 1.000.000 de posibilidades, como mucho solo tendremos que ejecutar el juego 100 veces para conseguir obtener la clave, que siempre será la misma).
Teorema: siempre y cuando el tiempo transcurrido entre el cambio de fecha, hora y la carga de la aplicación sea constante, conseguimos que siempre nos pida la misma clave.
Bueno, os diré que esto da resultados muy buenos por lo general, y para poneros algunos ejemplos, os diré que lo he probado en "Simon the sorcerer", "PC Futbol 3.0", y otros más...
Seguro que ya, os estaís preguntado: ¿es imposible, como mantenemos el tiempo constante desde que ponemos el reloj constante hasta que ejecutamos el juego?. Pues yo os digo hermanos, je je, no es imposible de hecho, mas abajo se describe el pequeño archivo de proceso por lotes, que consigue, que el tiempo transcurrido en las cargas, sea cte. (Siempre y cuando no estemos bajo MS-DOS, no en una sesión)
MClave.BAT |
......date 01/01/01 |
......time 00:00:00 |
......JUEGO.EXE |
Parte IV: Algunos prog. de interes
Siento que no estén disponibles los enlaces, pero tengo que encontrar algun sitio, donde "albergar", dichos programas, o almenos, otro lugar donde ya esten. Pasaros por aquí, de vez en cuando, para ver si van apareciendo los enlaces.
Editores hexadecimal Te permitirán editar un fichero binario, y escribir dentro de él. TurboDebuger PcToolsHex |
Desassembler Tecnología inversa, convierte el .EXE a .ASM para tocarlo como te de la gana. |
Desprotectores de
Juegos Igual que el capitulo III, pero de forma automática, están muy bien, para los juegos prehistoricos, que todos tenemos ya llenos de polvo. RawCopy DeCripter LockStmith RawCopy |
Utilidades Ver "Parte II", programas que realizan eso mismo, genial para los juegos antiguos, pero casi todos fallan con los modernos, y son solo para MS-DOS. GameWizard Pro |
(Por falta de espacio, y no haberlos encontrado en la red, puede que algunos de los prog. anteriores, no esten, si realmente te interesan; "e-mail" al canto.)
.