16/6/11

Tutorial. Hotel Mogul {Reversing / Cracking}

En vista de lo chungo que está el asunto, pondré lo típico que recomendará mi abogado en el futuro. Toda la información aquí referida, es para aprender, estoy en contra de la pirateria y el reggeton, etc... (El etc, significa, vease el texto tipico de cese de responsabilidad y esas cosas). Por si acaso, no adjunto crack. Aquí que cada perro se lama...

Siento, la calidad de las imagenes, si haceis click, se ven perfectamente. Insisto, lo siento.

Comienzo
Descripción Protección del juego basada en límite de tiempo. Sólo permite probarlo durante 30 minutos, después cobra 7€.
Descarga: http://am05.mirror.alawar.com/ HotelMogul Es_11484.exe
Una vez instalado el juego, nos encontramos que tiene 2 ejecutables. El primero llamado: HM, y el segundo HM.wrp. Ya comienza a oler raro. Si ejecutamos el primero aparece una NAG, indicando que queremos hacer, jugar 30 minutos o pagar. Y si ejecutamos el HM.wrp no hace nada. Parece que se cierra.
Peid nos indica:
HM.wrp = Nothing Found
HM = ASProtect 1.2x - 1.3x [Registered] -> Alexey Solodovnikov [Overlay]
Como el que ofrece Resistencia (y es el único que hace algo), es el HM, será el que procese por el OllyDbg. Indicar que el otro fichero visto desde olly, tiene un RET, nada más empezar. Salta a Kernerl32.ExitThread y finaliza la aplicación.
Visto lo visto, uno ya empieza a pensar que uno actuará de Padre y llamara al hijo modificándole en memoria y posteriormente ejecutar. O bien, edita el ejecutable y lo deja operable de nuevo, monitorizando y posteriormente restaurando (con el peligro que esto podría acarrear), o por último que copie el fichero en “tmp”, por suponer algo, y de nuevo, modificar y ejecutar. ¿Resultado?
CreateProcess ¡! Como en cualquiera de los casos, me huele a una llamada a esta api, probaré a monitorizarla. Esto lo intuyes por viejo. Así que: BP CreateProcessA. No sin antes, proceder a quitar la protección de ASP. No lo incluiré en el tutorial por que ya existen muchos, si bien utilicé un programa; Por comodidad.
Probamos a ejecutar, pasamos todos los errores, y damos a probar el juego. ¡Tachan! ¡Falla! :D El juego arranca sin mayor problema (falla para nosotros, no el programa). Cambio de idea,
BP CreateProcessW. Y repetimos el proceso. Esta vez, sí, ha parado.
En EDI, vemos la ruta del programa, justo el ejecutable que no hacia nada… Y también lo apreciamos en los parámetros de llamada del proceso. Por lo que ejecutamos hasta el RET, y F8, para ver que podemos ver por la que creo será la zona caliente…
Contenido de EDI
Llamada y parametros
¡Importante el proceso lo ejecuta SUSPENDIDO!
Salimos en 1004CE45, si vamos traceando un poco, vemos abajo en la línea 1049F3E, un DebugActiveProcess, esto, ya me hace sospechar de que el aplicativo, funciona a modo Debugger. Attachea, modifica, y libera. Pero vamos a comprobarlo.
Pues no, hay un salto que nos lleva hasta 10049F8B, un poco más abajo vemos VirtualProtectEx, es decir va a modificar los permisos de la dirección: 0056E17, curiosamente el EP del proceso que falla, justo donde se encuentra el RET, y modifica 2 bytes. Modificará o al menos permitirá modificar el C3 90, que existe. Le otorga permisos de Ejecución / Lectura / Escritura.
Parametros de VirtualProtectEx
Traceando un poco más, nos lleva hasta un WriteProcessMemory, esta api, es la encargada de modificar los valores en MOMORIA del proceso. De nuevo la dirección a modificar es el EP del otro proceso. 2 bytes el tamaño. Si miramos que hay en el Buffer: E8 14.
Valores en buffer
Ya tengo claro que modificando en el otro ejecutable estos 2 valores, pasará a funcionar, pero para muestra siempre es mejor un botón.
La siguiente api que utiliza, no la conocía, FlushInstructionCache. Si la CPU no reconociese las modificaciones, ejecutaría lo que estaba anteriormente, con esto, indicando el EP y los valores modificados (2 bytes). Lo refresca. Y siempre ejecutará lo nuevo.
Por último en 1004A034 se utiliza ResumeThread, y ya tenemos nuestro juego funcionando. Para finalizar, si se parchea el EP de HM.wrp con los valores E8 14. Nos arrancará el juego siempre, sin necesidad de de utilizar el Loader.
Notas adicionales (Nada que ver con cracking).
Bueno, me he liado un poco al ver DebugActiveProcess, al final, no se utilizaba en la aplicación, esto me hace pensar que esta compañía, tiene una aplicación de botón gordo. Es decir, usa la misma para todos los juegos, y le mete una protección u otra de forma genérica. Si la primera falla, mete la segunda, y así sucesivamente.