martes, 20 de enero de 2015

Ejemplo de game-hack en ensamblador (x86)

Bueno chicos, como no recibo ninguna sugerencia, os enseño un ejemplo de las modificaciones o hacks que se pueden hacer fácilmente en ensamblador/hexadecimal.
En esta ocasión quería centrarme en algún juego para Windows, que es lo que se lleva hoy en día (Aunque modificar ROMs es mas sencillo, este formato ya no se lleva)
Me centraré en lo que viene siendo modificación de código, si quisierais modificar gráficos o música, es tan sencillo como acceder a la carpeta donde esta instalada la aplicación o juego, y buscar el archivo que queréis cambiar. El código por el contrario se suele encontrar en el *.exe

Concretamente en este ejemplo os enseñaré un hack que hice para el juego "Midtown Madness 2",
un juego que tiene ya unos años, no es un juego legendario, pero me basta para haceros un ejemplo de lo que se puede hacer de forma muy sencilla en ensamblador.


Concretamente, en este juego de coches, el hack consiste en que al activar el claxon del coche, el coche se eleva por los aires, permitiendo acceder a escenarios que no se puede acceder normalmente en el juego y pasar encima de los edificios.

Para ello, necesitamos encontrar el codigo que se ejecuta cuando activamos el claxon.
Gracias al programa "Cheat Engine" pude encontrar este codigo con facilidad. (Recordemos que Cheat Engine ademas de ser un conocido programa para modificar variables in-game, tambien tiene un desensamblador muy bueno)
Cuando encendemos el claxon se ejecuta un procedimiento en la dirección 0x000d17dc y cuando se apaga, otro procedimiento en la dirección 0x000d181c.
Si vamos a estas direcciónes encontramos:

...................
000D17DC - mov [esi],00000001
000D17E2 - pop esi
000D17E3 - ret 
000D17E4 - nop 
000D17E5 - nop 
000D17E6 - nop 
000D17E7 - nop 
000D17E8 - nop 
000D17E9 - nop 
000D17EA - nop 
000D17EB - nop 
000D17EC - nop 
000D17ED - nop 
000D17EE - nop 
000D17EF - nop 
000D17F0 - push esi
...................

...................
000D181C - mov [esi],00000000
000D1822 - pop esi
000D1823 - ret 
000D1824 - nop 
000D1825 - nop 
000D1826 - nop 
000D1827 - nop 
000D1828 - nop 
000D1829 - nop 
000D182A - nop 
000D182B - nop 
000D182C - nop 
000D182D - nop 
000D182E - nop 
000D182F - nop 
000D1830 - push ebp
...................


Como veis, el registro esi en estos dos casos contiene la dirección de memoria de un entero que se pone a 1 cuando el claxon esta encendido y a 0 cuando esta apagado. Esta variable ha sido la que me ha ayudado a encontrar el código. Y ademas vemos una buena noticia, y es que hay muchos bytes sin utilizar hasta el siguiente fragmento de código, lo cual nos ayuda a implementar el mod.
Ahora para hacer que el coche vuele, lo que tendremos que hacer es meter un código en este hueco que ponga el valor de la velocidad vertical del coche a un valor alto.
Este valor es un float que se debe encontrar con un puntero (situado en la dirección 0x005dfd20 al que hay que añadir a su valor 2450 en hexadecimal).
Yo personalmente le he puesto 30.0 de valor al float (41f00000), aunque se le puede dar cualquier otro, mayor o menor. Podemos aprovechar el registro esi que como vemos es reemplazado inmediatamente después cargando desde stack. El código queda así:

...................
000D17DC - mov [esi],00000001
000D17E2 - mov esi,[005DFD20]
000D17E8 - add esi,00002450
000D17EE - jmp 000D1824
000D17F0 - push esi
...................

...................
000D181C - mov [esi],00000000
000D1822 - pop esi
000D1823 - ret 
000D1824 - mov [esi],41F00000
000D182A - pop esi
000D182B - ret 
000D182C - nop 
000D182D - nop 
000D182E - nop 
000D182F - nop 

000D1830 - push ebp
...................

Como veis, he aprovechado parte de los bytes sin utilizar tras el procedimiento de apagar el claxon, ya que con el hueco del procedimiento al encender el claxon me quedaba corto de espacio.
¡Y con esto ya esta implementado! 
Si lo vemos con un editor hexadecimal vemos que los bytes que hemos cambiado son muy pocos.


Y sorprendentemente estos pocos bytes nos han permitido hacer un mod de vuelo totalmente funcional.

Ya sabeis, cualquier comentario o sugerencia (con otros juego si queréis) que queráis hacer... No es necesario registrarse para comentar. Aunque creo que ya lo sabeis :')

martes, 13 de enero de 2015

¿Cual es el mejor formato de audio? ¿MP3? ¿OGG?

Compara tu mismo os formatos aqui ;)
Bueno chicos, todos hemos usado siempre el formato MP3 de toda la vida para almacenar y compartir música, al menos la inmensa mayoría. MP3 como todos sabemos en un formato de compresión de audio con perdidas que ahorra mucho espacio respecto al audio sin comprimir PCM (Como en los CDs de audio).
Pero MP3 no es el único, de hecho, es yo creo, el formato mas antiguo que se usa actualmente en la actualidad, en cuanto formatos de audio buenos con perdida.
Otros formatos que salieron mas tarde son:
*.WMA, *.AAC y *.OGG.
Recientemente el equipo xiph.org creador de OGG Vorbis ha desarrollado otro formato de audio del cual hablaré tambien brevemente: *.OPUS

MP3 fue desarrollado por la fundación MPEG en 1994, y el mayor problema que presentaba era que este formato tenia una patente por la que se debia pagar a MPEG por su uso (o algo de eso). Esto fue el motivo de que por ejemplo mas tarde la fundacion Xiph.org creara el formato de audio abierto OGG Vorbis (Como podeis ver en la Wikipedia)

Hoy en día, el problema de MP3 ya no es la patente (Hoy en día la gente usa MP3 con total libertad) sino que al ser el formato de audio mas antiguo de los que hay en la comparativa, es el que en general tiene menor eficacia.

La eficacia  de un formato o de otro tambien depende del bitrate entre otros. Por ejemplo. El formato AAC que utiliza itunes a 192 kbps es el mejor formato de compresión a este bitrate, por encima de MP3 y OGG, pero solo a partir de este bitrate.

En general, y en mi opinión, a 128 kbps que es la tasa de bits mas utilizada y para abajo, el mejor formato es OGG.

la ventaja de AAC (Ademas de su eficacia a partir de 192 kbps) por lo que lo utiliza itunes, es la posibilidad de incluir proteccion de datos de derechos de autor (anticopia).
No obstante, a bajos bitrates puede ser incluso peor que MP3.

MP3 y WMA, son en general y para mi gusto los peores. WMA, que parece ser un poco mejor que MP3, fue el segundo formato de audio mas usado en la anterior decada (2000-2009). Muchos discmans y reproductores de MP3 fueron compatibles con WMA, hoy en dia este formato casi ni se usa, se podria decir que ha sido reemplazado por AAC (Gracias a la popularidad de Itunes).

OGG Vorbis, a pesar de su muy baja popularidad entre la gente, es un muy buen formato de compresión, y lo mejor de todo, es abierto.
Su alta calidad de compresión y su formato abierto, hace que sea uno de los formatos favoritos en los desarrolladores de videojuegos, por ejemplo: OGG es el formato elegido para la música de la saga de videojuegos GTA, incluido GTA San Andreas.
OGG tambien es el formato de audio utilizado en Spotify.

OPUS es el nuevo formato de audio desarrollado por Xiph.org como un formato pensado para audio en streaming. Es un formato de audio que combina los codec SILK (de skype) para el audio hablado y CELT para la música (CELT era el codec de audio que estaba desarrollando Xiph.org como sucesor de Vorbis). Este formato apenas tiene un par de años, y a pesar de que tiene una gran eficacia, esta totalmente enfocado en el streaming y la baja latencia. Una gran desventaja de este formato pese a su eficacia, es que la tasa de muestras esta fija a 48000 Hz, haciendo que si por ejemplo queremos convertir un archivo de audio a 44100 hz (Como en un CD de audio y la mayoria de MP3s) a esta nueva tasa de frecuencia, se tendria que reescalar.

Se que es muy dificil distinguir la calidad en canciones a 128 kbps, asi que como prueba para que compareis la eficacia de los distintos formatos, os adjunto la cancion de Bon Jovi - Living on a prayer a 64 kbps en formatos MP3, AAC, OGG y OPUS. Todos ocupan casi lo mismo, unos 1,80 Mb.
Para ello convertire un fichero original en MP3 a 160 kbps tambien adjunto, por lo que la calidad final si convirtieramos directamente desde CD seria un poco mejor tal vez.
Vosotros mismos podeis ver la comparación. En mi opinion los mejores formatos a este bitrate son en orden: OPUS, OGG, MP3, AAC. Descarga arriba del todo.
¿Os esperabais esta calidad de sonido de OGG y OPUS en un archivo de solo 1,80 mb? Comentad ;)

miércoles, 7 de enero de 2015

WinRar -vs- 7zip

Nota: tal vez os interese este articulo reciente sobre mi propio formato de compresion que combina 7z y rar para obtener la mejor compresión hasta el momento.

Seguramente todos nosotros hayamos usado alguna vez WinRar. Cuando apareció WinRar y el formato RAR, muchos aptamos por utilizar este formato para comprimir nuestros archivos, ya que este era (y sigue siendo) mucho mejor que zip.
Este formato no es malo, y por ello no me extraña que se use tanto, no obstante me sorprende que no se use el formato .7z tanto como se usa .RAR.
Para los que no hayais oido hablar de 7z, os lo comento brevemente:
Al contrario que RAR, el formato 7z es abierto, y a pesar de ser bastante menos popular, tiene tasas de compresión mayores.

Mas info sobre RAR: http://es.wikipedia.org/wiki/RAR
Mas info sobre 7z: http://es.wikipedia.org/wiki/7z

-Los programas:
Hablando brevemente de los programas correspondiestes a los dos formatos, tanto los compresores WinRAR como 7zip dan soporte para descomprimir ambos archivos. 7zip ademas tiene soporte para muchos mas formatos de compresión que WinRar.
WinRAR por otra parte tiene una interfaz grafica mejor que la de 7zip, la cual imagino que es simple para poder ser portado a varias plataformas sin dificultades.

-La compresión:
7zip tiene tasas de compresión mayores que RAR casi siempre. De momento el unico tipo de archivo que he comprobado que RAR comprime un poco mejor que 7z son los archivos de audio WAVE sin comprimir, los cuales no se usan frecuentemente. En el resto de los casos 7zip gana con diferencia.
7zip tarda aproximadamente entre un 125-150% de tiempo en comprimir en comparación con RAR en mi ordenador con procesador dual core. No lo he probado en otras plataformas, pero 7zip puede usar controlar varios nucleos. sobre esto no tengo información de WinRAR. Asi que no sabria deciros la comparacion de tiempo de los dos formatos en un ordenador quad-core actual, pero seguramente sean similares.

-Comparativa:
A continuación hare la compresión de varios archivos cotidianos en formato ZIP, RAR, y 7Z con el maximo nivel de compresión para que veais los resultados.
Los archivos a complimir seran un ROM de Nintendo 64 (SM64) otro de MegaDrive (Sonic 2) y Pokemon Hellín.
A continuación una carpeta con modelos 3D de SketchUp.
Un PDF aleatorio, y por ultimo un archivo de audio WAVE en formato CD (S16_LE a 44,1 kHz)

SM64
Tamaño original: 8,00 Mb
ZIP: 6,01 Mb
RAR: 5,59 Mb
7z: 5,43 Mb

Sonic 2
Tamaño original: 1,00 Mb
ZIP: 740 Kb
RAR: 735 Kb 
7z: 712 Kb

Pokemon Hellín
Tamaño original: 1,00 Mb
ZIP: 485 Kb
RAR: 467 Kb 
7z: 439 Kb

Carpeta modelos SketchUp
Tamaño original: 25 Mb
ZIP: 13,3 Mb
RAR: 10,9 Mb
7z: 9,65 Mb

Documento PDF
Tamaño original: 7,09 Mb
ZIP: 6,51 Mb
RAR: 6,45 Mb
7z: 6.19 Mb

Musica WAVE sin comprimir
Tamaño original: 36,3 Mb
ZIP: 34,2 Mb
RAR: 26,8 Mb
7z: 33,0 Mb

La comparativa habla por si sola, exceptuando los archvos de audio WAVE que no se suelen usar habitualmente, 7zip obtiene los mejores resultados. Logicamente si comprimimos archivos ya comprimidos como pueden ser JPG o MP3, obtendremos siempre una compresion muy mala y casos en los que por ejemplo el archivo comprimido ocupa mas que el original, o que la mejor compresion es la ZIP o/y la 7Z es la peor con diferencias muy bajas, es por esto que no se suelen comprimir estos tipos de archivos.