Mecanismos de protección de datos en videojuegos

83
Universidad de Granada Escuela Técnica Superior de Ingeniería Informática y de Telecomunicación Grado en Ingeniería de Tecnologías de Telecomunicación Especialidad en Telemática Mecanismos de protección de datos en videojuegos Trabajo Fin de Grado Benito Palacios Sánchez Tutor Dr. D. Pedro García Teodoro Departamento de Teoría de la Señal, Telemática y Comunicaciones Julio de 2015

description

Trabajo Fin de Grado sobre Mecanismos de protección de datos en videojuegos.Para este trabajo se aplicaron conceptos de ingeniería inversa sobre videojuegos (ROM Hacking) para estudiar y documentar los diferentes formatos y algoritmos de protección para evitar tanto traducciones no oficiales, extracción de contenido con derechos de autor o acciones no autorizadas en comunicaciones inalámbricas.

Transcript of Mecanismos de protección de datos en videojuegos

  • Universidad de GranadaEscuela Tcnica Superior de Ingeniera Informtica y de Telecomunicacin

    Grado en Ingeniera de Tecnologas de TelecomunicacinEspecialidad en Telemtica

    Mecanismos de proteccin de datos envideojuegos

    Trabajo Fin de Grado

    Benito Palacios Snchez

    Tutor

    Dr. D. Pedro Garca TeodoroDepartamento de Teora de la Seal, Telemtica y Comunicaciones

    Julio de 2015

  • Benito Palacios Snchez

    Mecanismos de proteccin de datosen videojuegos

    Trabajo Fin de Grado

    Universidad de Granada

  • Yo, Benito Palacios Snchez, alumno de la titulacin Grado en Ingeniera de Tecnologas deTelecomunicacin de la Escuela Tcnica Superior de Ingenieras Informtica y de Telecomu-nicacin de la Universidad de Granada, con DNI 75129861Q, autorizo la ubicacin de la siguientecopia de mi Trabajo Fin de Grado en la biblioteca del centro para que pueda ser consultada por laspersonas que lo deseen.

    Fdo: Benito Palacios Snchez

    Granada a 6 de julio de 2015.

  • Dr. D. Pedro Garca Teodoro, Profesor del rea de Ingeniera Telemtica del Departamento deTeora de la Seal, Telemtica y Comunicaciones de la Universidad de Granada.

    Informa:

    Que el presente trabajo, titulado Mecanismos de proteccin de datos en videojuegos, ha sidorealizado bajo su supervisin por Benito Palacios Snchez, y autorizo la defensa de dicho trabajoante el tribunal que corresponda.

    Y para que as conste, expide y firma la presente autorizacin en Granada a 6 de julio de 2015.

    El director:

    Dr. D. Pedro Garca Teodoro

  • Mecanismos de proteccin de datos en videojuegos por Benito Palacios Snchez se distribuye bajo unaLicencia Creative Commons Atribucin 4.0 Internacional.

  • Mecanismos de proteccin de datos en videojuegosBenito Palacios Snchez

    Palabras clave: seguridad, videojuegos, ingeniera inversa, servicios en lnea, DRM, Nintendo DS.

    Resumen

    Los videojuegos son cada da ms un factor importante de nuestra cultura actual. Especialmentedesde el boom que ha dado el mercado de los telfonos inteligentes. A final de 2014 la compaa detrsdel famoso juego Candy Crush report tener 356 millones de usuarios nicos, con unas ganancias de1.300 millones de dlares. La industria de los videojuegos es, as, la segunda con mayor beneficiosdespus de la de libros y supera a la del cine y msica. No solo forma parte de nuestro entretenimiento,sino que, cada vez ms, se incorpora al mundo de la enseanza, especialmente para nios.

    Por estas razones, los mecanismos de seguridad asociados a los juegos son importantes. Pensadosoriginalmente para combatir la piratera, distribucin ilcita de copias de juegos, hoy en da abarcan mscampos aparte de estos. Son importantes para evitar modificaciones, realizar acciones no autorizadasdurante las partidas en lnea y traducciones a idiomas donde la empresa piensa crear mercado.

    Este trabajo pretende ofrecer una perspectiva de seguridad sobre este creciente mercado, analizandojuegos de las videoconsolas Nintendo DS, Play Station 3 y plataformas mviles como Android y iOS. Sever cmo se han protegido textos, imgenes y archivos ante modificaciones, con cifrados. As mismo,se analizarn protocolos de comunicacin para servicios en lnea, el cifrado en las descargas de archivos,la transmisin segura de cdigo y la proteccin de contenidos con derechos de autor. En general, estastcnicas, pretenden impedir poder realizar ingeniera inversa sobre el producto final, entendindose estacomo el proceso de analizar una aplicacin para comprender cmo funciona y cmo integra cada uno desus recursos.

    La ingeniera inversa se lleva realizando desde el inicio de la computadoras, en su mayora conmotivos de entretenimiento y enseanza; aprendiendo cmo funciona un sistema se puede crear unoms robusto y con ms caractersticas! Existen diversas herramientas para llevarla a cabo, tales comodepuradores y desensambladores, aunque son especficas para cada plataforma. En este trabajo se hautilizado un emulador de cdigo abierto DeSmuME y otro privativo pero freeware, No$GBA, paraNintendo DS. Estos se han usado con el objetivo de analizar el cdigo en ensamblador de los juegosy de automatizar tareas de depuracin como guardar paquetes de red, exportar datos descifrados derutinas de cdigo y analizar los archivos cargados. Adems, para el desarrollo de este proyecto se hanrealizado una serie de programas que ayudan al anlisis de juegos. Tambin se explican las metodologasseguidas para el desarrollo de los estudios.

    Las conclusiones del estudio demuestran una ausencia general en cuanto a proteccin sobre losarchivos con contenidos con copyright. As mismo, se evidencian las tcnicas utilizadas por algunascompaas a la hora de ofuscar para evitar modificaciones de archivos, tales como cifrados medianteoperaciones XOR, algoritmos HMAC y de firma digital. En cuanto a los servicios en lnea, se han detectadofallos de seguridad a la hora de configurar servidores y fallos en el diseo de los protocolos, quepermiten realizar acciones no autorizadas con facilidad. En suma, se deducen unas claras carenciasen la provisin de seguridad en los videojuegos, que ponen de manifiesto la necesidad de mejorar losesquemas actualmente dispuestos para ellos.

  • Data Protection Mechanisms in Video GamesBenito Palacios Snchez

    Keywords: security, video games, reverse engineering, online services, DRM, Nintendo DS.

    Abstract

    Video games are getting one of the most important elements of our culture. The mobile marketboom has made companies behind games like Candy Crush very successful. In that specific case, thegame has about 356 millions of unique users and 1.300 millions of dollars in benefits. The video gameindustry is in fact only before the books one in top of profits and it gets over music and cinema. It isnot only about entertainment but also for education, specially for children, for instance, to learn newlanguages and help with mathematics.

    All that benefit makes to think about how to protect against possible attacks. They started fightingpiracy with Digital Rights Management techniques, that is, releasing copy of games without permissionsfrom the author, but nowadays it deals with more fields. Mods, cheats in online plays and translationsmade by fans to languages where the company is going to release a port of the game are only someexamples.

    This project aims to offer a new perspective about game security. In it, we analyze products fromNintendo DS and Play Station 3 devices and mobile platforms like Android and iOS, to show whatkind of techniques has been used to protect both text and images files, as well as sound archives.Communication protocols for online services, download content protection and wireless code transmissionwill be studied too. The general purpose of all these protection is to avoid doing reverse engineering,that is, disassemble the product to study all its pieces and resources.

    Reverse engineering is one of the main topics of this dissertation. Usually it is done as a hobby but,with the rights tools and knowledge it is a powerful way to test the security of a system. Related tovideo games, it is called romhacking, since it is about modify (hack) a game (usually distributed inRead Only Memories). These project will use common tools like disassemblers and debuggers. Forinstance, for Nintendo DS games two emulators will be used. The first one, DeSmuME, since it isopen source, it will allow to hack its code to automatize task and save network packets. The secondone, No$GBA, freeware, includes a built-in debugger so it will be used to analyze code and algorithms.Some tools have been developed to help with the task of studying games, like binary searcher, databasemanager and some game specific exporters. Furthermore, all the methodology followed to figure outformats and algorithms will be explained in detail.

    This project concludes with a summary of the mechanism analyzed, with recommendations toimprove them. Most copyright contents, that usually contains DRM in virtual stores, are not protectedin games. That refers to music, electronic books and videos. However, text and images are usuallyprotected with encryption by using XOR operand, HMAC algorithm or a digital signature. About theonline services, it will show how bad protocol designs has been found, with some vulnerabilities thatallow to users to cheat, but also how in some games the download content has a good protection againstexternal modifications and man-in-the-middle attacks.

  • ndice general

    1. Introduccin 11.1. Motivacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3. Organizacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

    2. Seguridad en videojuegos 32.1. Conceptos de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

    2.1.1. Cifrado simtrico y asimtrico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.2. Algoritmos para integridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.3. Firma digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

    2.2. Seguridad en videoconsolas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.1. Nintendo DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.2. Nintendo DSi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.3. Nintendo 3DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

    2.3. Ingeniera inversa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.1. Legalidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

    3. Planificacin y costes del proyecto 113.1. Organizacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2. Planificacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3. Presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

    3.3.1. Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3.2. Estimacin de costes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

    4. Metodologa 174.1. Anlisis de ficheros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2. Depuracin de cdigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

    4.2.1. Bsqueda de archivos en memoria RAM . . . . . . . . . . . . . . . . . . . . . . 194.2.2. Bsqueda de algoritmos sobre textos . . . . . . . . . . . . . . . . . . . . . . . . 204.2.3. Bsqueda de algoritmo sobre imgenes . . . . . . . . . . . . . . . . . . . . . . . . 21

    4.3. Interceptacin de la comunicacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.4. Documentacin y repositorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

    5. Traducciones no oficiales 255.1. Saga Pokmon en Nintendo DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

    5.1.1. Pokmon Perla y Diamante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.1.2. Pokmon HeartGold y SoulSilver . . . . . . . . . . . . . . . . . . . . . . . . . . 285.1.3. Pokmon Blanco y Negro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.1.4. Pokmon Conquest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

    5.2. Ninokuni: El Mago de las Tinieblas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.3. Proyectos abandonados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

    6. Contenido con derechos de autor 39

    v

  • NDICE GENERAL

    6.1. Libros electrnicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406.1.1. Ninokuni: La Ira de la Bruja Blanca . . . . . . . . . . . . . . . . . . . . . . . . 406.1.2. 100 Classic Book Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

    6.2. Bandas sonoras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.2.1. Osu! Tatakae! Ouendan! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.2.2. Guitar Hero: On Tour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.2.3. Guitar Rock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.2.4. Level-5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456.2.5. Duet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

    6.3. Vdeos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466.3.1. Play Station 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466.3.2. Nintendo DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

    7. Servicios en lnea 497.1. Multijugador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

    7.1.1. Conexin segura en servidores de Nintendo . . . . . . . . . . . . . . . . . . . . 497.1.2. Preguntados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

    7.2. Contenido descargable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547.2.1. 100 Classic Books Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547.2.2. Ninokuni: El Mago de las Tinieblas . . . . . . . . . . . . . . . . . . . . . . . . . 547.2.3. Duet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

    7.3. Transmisin segura de cdigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

    8. Resultados y recomendaciones 578.1. Seguridad sobre ficheros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578.2. Seguridad en comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

    9. Conclusiones 599.1. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

    Bibliografa 61

    Acrnimos 63

    vi

  • ndice de figuras

    3.1. Diagrama de Gantt del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

    4.1. Contenido de un fichero con imgenes de Ninokuni. . . . . . . . . . . . . . . . . . . . . 174.2. Contenido de un fichero comprimido de Ninokuni. . . . . . . . . . . . . . . . . . . . . . 184.3. Primeros bytes del fichero PSAR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.4. Programas para depurar juegos de Nintendo DS. . . . . . . . . . . . . . . . . . . . . . 194.5. Frase con codificacin no estndar encontrada por RelativeSearch en Pokmon. . . . . . 214.6. Programa de gestin de algoritmos de juegos DataBrithm. . . . . . . . . . . . . . . . . 23

    5.1. Sistema de ficheros en Pokmon Perla visto con Tinke. . . . . . . . . . . . . . . . . . . 275.2. Carpetas y ficheros ofuscados en Pokmon HeartGold. . . . . . . . . . . . . . . . . . . 295.3. Comparacin de carpetas entre Pokmon Blanco (izq.) y Pokmon HeartGold (der.). . . 315.4. Imgenes sin cifrar en Pokmon Blanco. . . . . . . . . . . . . . . . . . . . . . . . . . . 325.5. Archivo cifrado (arr.) y descifrado (ab.) de Ninokuni: El Mago de las Tinieblas. . . . . 345.6. Mensaje de error al detectar una partida modificada (izq.) y advertencia (der.) en Ninokuni. 35

    6.1. Extracto de texto de un libro de 100 Classic Books Collection. . . . . . . . . . . . . . . 426.2. Archivos comprimidos en SDAT y codificados con IMA-ADPCM visto con Tinke. . . . . 436.3. Guitar Grip necesario para jugar a la saga Guitar Hero: On Tour. . . . . . . . . . . . 43

    7.1. Primeros paquetes de una comunicacin entre una Nintendo DS y los servidores. . . . 507.2. Comunicacin entre Nintendo DS y servidor de Nintendo para descargar un fichero. . . . 517.3. Peticin respuesta descifrada entre Nintendo DS y servidor. . . . . . . . . . . . . . . . 527.4. Mensajes descifrados del protocolo multijugador de Nintendo DS. En verde el token. . 527.5. Conexin a los servidores alternativos de Nintendo. . . . . . . . . . . . . . . . . . . . . 537.6. Captura de trfico con las preguntas y respuestas de una partida de Preguntados. . . . 537.7. Filas de la base de datos de Duet que activan el contenido extra. . . . . . . . . . . . . 54

    vii

  • ndice de tablas

    2.1. Tabla de resultados de la operacin XOR. . . . . . . . . . . . . . . . . . . . . . . . . . . 5

    3.1. Coste de los recursos de personal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2. Presupuesto final. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

    5.1. Especificacin de tipografas en Pokmon Perla. . . . . . . . . . . . . . . . . . . . . . . 275.2. Especificacin del formato de texto en Pokmon Perla. . . . . . . . . . . . . . . . . . . 285.3. Especificacin del formato de texto en Pokmon Blanco. . . . . . . . . . . . . . . . . . . 315.4. Especificacin del formato de texto en Pokmon Conquest. . . . . . . . . . . . . . . . . 33

    6.1. Especificacin de formato PSAR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.2. Especificacin de formato GVD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.3. Especificacin del formato de 100 Classic Books. . . . . . . . . . . . . . . . . . . . . . 486.4. Especificacin del formato de Guitar Hero: On Tour. . . . . . . . . . . . . . . . . . . . 486.5. Especificacin del formato HWAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

    ix

  • Captulo 1

    Introduccin

    1.1. Motivacin

    El primer videojuego se remonta al ao 1952 [9], cuando el profesor de informtica Alexander S.Douglas cre un juego con grficos para ordenador. Llamado Nought and crosses u OXO, se tratade un tres en raya implementado para la computadora EDSAC de la Universidad de Cambridge.Este permita enfrentar a una persona contra la mquina. Seis aos ms tarde, William Higginbothamdesarroll el juego Tennis for Two sobre un osciloscopio, inventando el primer videojuego multijugador.Cuatro aos despus, un estudiante del Massachusetts Institute of Technology (MIT) cre un juego congrficos vectoriales donde dos naves se enfrentaban, denominado Spacewar.

    Desde entonces, y 63 aos ms tarde, existen ocho generaciones de videoconsolas. Las ltimaspermiten jugar en alta calidad y 60 fps, consiguiendo un alto nivel de detalle y realismo. La industriade los videojuegos ha evolucionado a un ritmo imparable, siendo uno de los sectores que ms rpido hacrecido en Estados Unidos [4]. En 2014, se vendieron solo en Estados Unidos 135 millones de juegos,generando unas ganancias de 22 mil millones de dlares. Para 2015, la empresa Gartner estima que laventa de videojuegos a nivel global ser de en torno a 100 mil millones de euros. En cuanto a Espaa,en 2014 la industria creci un 21%, facturando 413 millones de euros segn la Asociacin Espaola deEmpresas Productoras y Desarrolladoras de Videojuegos y Software de Entretenimiento [8].

    1.2. Objetivos

    En el contexto anteriormente planteado, el objetivo que persigue este trabajo es analizar tresdiferentes aspectos de seguridad sobre videojuegos. En cada uno se ofrecern varios anlisis paramostrar vulnerabilidades y puntos fuertes de cada videojuego y, ofrecer recomendaciones para mejorarsu seguridad.

    Para ello se habr de determinar el mbito de las problemticas, identificando qu tipo de contenidodeben ser protegido y por qu. Sobre esto, habr de realizarse un anlisis del estado actual y en qumedida afecta a la industria.

    Se han escogido juegos de la Nintendo DS para la mayora de los casos, por la documentacin queexiste sobre el hardware de la consola y emuladores con capacidades de depuracin. Los resultados delanlisis de estos juegos son el objetivo de la memoria, mostrando qu tcnicas de proteccin de datos sehan implementado y cmo se podra haber mejorado.

    1

  • 2 CAPTULO 1. INTRODUCCIN

    Este estudio surge del reciente inters por la edicin de videojuegos al que se llama romhacking. Elnombre proviene del ingls modificacin no autorizada (hack) sobre un archivo que originalmente vieneen dispositivos de solo lectura (Read Only Memory, ROM ). Estas modificaciones se realizan aplicandoconceptos de ingeniera inversa sobre los archivos, es decir, a partir del producto final se extraen susrecursos y se averigua cmo funciona. Existen comunidades en Internet dedicadas a este propsito1,donde se comparte informacin y utilidades. Los tres tipos de modificaciones y estudios ms frecuentesen este movimiento, y sobre los que se basar este trabajo, son:

    1. Las traducciones no oficiales son llevadas a cabo por personas externas a una empresa, de maneraque, editan los archivos del juego para ofrecer un parche que traduce el juego a un idioma.Relacionado con este tema estn los mods, modificaciones sobre un juego para ofrecer una versinalternativa.

    2. Los contenidos con derechos de autor ser el otro tema a tratar, y en ello en relacin a losvideojuegos con contenido sobre el que tpicamente se le aplican algoritmos de proteccin comolibros electrnicos, msica y vdeos.

    3. El tercer aspecto ser los servicios en lnea, tales como los protocolos de comunicacin entreconsola y servidor y la seguridad sobre los ficheros transmitidos.

    1.3. Organizacin

    La memoria se ha organizado de forma que primero se presentar la metodologa a seguir en elanlisis de los videojuegos, a continuacin los resultados de los anlisis y finalmente una conclusin.

    En el Captulo 2 se introducir la edicin de videojuegos, la seguridad que habitualmente seimplementa y aspectos legales para realizar ingeniera inversa.

    En el Captulo 3 se mostrarn los apartados y tareas en los que se ha dividido y planificado eltrabajo, adems de los recursos y los costes estimados.

    El Captulo 4 explica las diferentes metodologas empleadas a la hora de analizar un aspecto de unvideojuego. Tambin se har referencia a los programas desarrollados durante el trabajo para facilitarlos anlisis y se detallar su uso y funcionamiento.

    El Captulo 5 comenta los resultados obtenidos tras analizar juegos que han sido objeto de traduccionesno oficiales. La investigacin se concentr en averiguar los algoritmos empleados para ofuscar textos eimgenes. Incluye tambin un estudio sobre las causas de abandono de estos proyectos.

    En el Captulo 6 se habla sobre los contenidos con derecho de autor. Para ello, se han escogidouna serie de juegos que incluyen libros electrnicos, canciones o vdeos; y se han analizado los posiblesalgoritmos para proteger dichos contenidos.

    El Captulo 7 muestra los resultados de analizar diferentes servicios en lnea. Se explicarn losmecanismos de seguridad de los servidores de Nintendo para Nintendo DS, comentando la metodologaseguida y los fallos de seguridad descubiertos. Tambin se comentar la seguridad implementada sobrevideojuegos para jugar en multijugador y descargar contenidos extras. El captulo termina con unanlisis sobre cmo se transmite cdigo ejecutable en la Nintendo DS de forma segura entre consolas.

    El Captulo 8 resume los algoritmos encontrados as como sus puntos dbiles y fuertes y se proponenalgunas tcnicas para reforzar la seguridad global en videojuegos.

    La memoria concluye con el Captulo 9, donde se detallan los conocimientos aprendidos y habilidadesdesarrolladas con este trabajo. Incluye una seccin con lneas de trabajo sobre los que se podra continuaravanzando en el trabajo aqu realizado.

    1http://romhacking.net/

  • Captulo 2

    Seguridad en videojuegos

    Este trabajo explora los conceptos de seguridad y videojuegos. Unos trminos que en principio nose suelen relacionar, a no ser que se hable sobre la piratera, fenmeno que aumenta cada da ms,esperando un crecimiento del 22% para 2015 [3]. Esta fuente menciona tambin la ingeniera inversacomo usando herramientas genricas, los hackers pueden convertir rpidamente binarios desprotegidosen cdigo fuente, volver a empaquetarlos y distribuirlos.

    Comnmente se asocia el trmino de hacker a una persona que maliciosamente investiga un programa.Es una mala interpretacin dada por medios y pelculas, ya que realmente se habra de hablar de cracker.El nombre de hacker naci en 1961, en los laboratorios del MIT, para denominar a los estudiantes quedominaban con destreza la programacin. A da de hoy, segn el RFC 13921 se define hacker como:

    Hacker: A person who delights in having an intimate understanding of the internal workings ofa system, computers and computer networks in particular. The term is often misused in a pejorativecontext, where cracker would be the correct term.

    Hacker: Persona apasionada por entender cmo funciona internamente y en detalle, un conjunto desistemas, ordenadores y redes de ordenadores. Generalmente se usa de forma incorrecta en un contextopeyorativo, debiendo usarse de modo ms correcto cracker.

    De esta forma, este mismo RFC define cracker como:

    Cracker: A cracker is an individual who attempts to access computer systems without authorization.These individuals are often malicious, as opposed to hackers, and have many means at their disposal forbreaking into a system.

    Cracker: Individuo que intenta acceder a un sistema de ordenadores sin autorizacin. Estosindividuos son generalmente maliciosos, en oposicin a los hackers, y tienen intereses ocultos en suintento por romper el sistema.

    Este trabajo muestra la seguridad de los juegos con el nico propsito de enseanza, como mencionaAndew Huang [13, p. 7]: For every copyright protection scheme that is defeated by a hacker, there issomeone who learned an important lesson about how to make a better protection scheme. (Para cadaesquema de proteccin con copyright que un hacker rompe, hay alguien que aprende una importanteleccin sobre cmo hacer un esquema de proteccin ms robusto.).

    1https://tools.ietf.org/html/rfc1392

    3

  • 4 CAPTULO 2. SEGURIDAD EN VIDEOJUEGOS

    2.1. Conceptos de seguridad

    El concepto de seguridad se puede definir en tres puntos: la condicin de un sistema como resultadodel establecimiento y mantenimiento de medidas de proteccin; la condicin de un sistema en el cual susrecursos estn libres de accesos no autorizados y de cambios accidentales no autorizados, destruccin o,prdida; medidas tomadas para proteger un sistema.2. Esta puede estar referida a tres mbitos:

    La seguridad de la informacin trata sobre la proteccin de datos guardados.

    La seguridad en las comunicaciones se refiere a la proteccin en la transmisin de datos

    La seguridad de sistemas se centra en la proteccin de entidades por los que pasa la informacin.

    Este trabajo abarca los dos primeros puntos, habiendo una pequea introduccin sobre el tercero enel Apartado 2.2 de seguridad en videconsolas.

    Max Kilger, investigador de ciberseguridad, resume la motivacin de las amenazas con las siglasMEECES del ingls dinero, ego, entretenimiento, ideologa, entrada en grupos sociales y estatus social.

    Con el objetivo de hacer frente a estas amenazas, existen varios modelos de seguridad con losaspectos que debe cumplir un sistema considerarse protegido. El ms conocido se denomina CIA, porlas iniciales de los tres principales puntos recogidos a continuacin. A este modelo se aaden cuatropuntos ms, resultando la siguiente lista:

    Confidencialidad: la informacin solo puede estar accesible por los entes autorizados.

    Integridad: se ha de garantizar que la informacin no ha sido modificada de manera no autorizada.

    Disponibilidad (Availability): la informacin ha de estar accesible cuando se solicita.

    Autenticacin: se ha de garantizar quin es el otro extremo.

    Disuasin: se ha de evitar cualquier motivacin para realizar ataques.

    No repudio: se ha de garantizar que la operacin se realiz.

    Recuperacin: se puede devolver el sistema su estado inicial tras un ataque.

    2.1.1. Cifrado simtrico y asimtrico

    La tcnica de cifrado se emplea para garantizar la confidencialidad. En lneas generales se basa enaplicar un algoritmo con una clave sobre un bloque de datos, denominado texto plano. El resultado esotra representacin del texto plano de manera que no se puede recuperar la informacin original sinconocer los detalles del cifrado.

    Estos algoritmos se basan en operaciones de sustitucin y transposicin, reordenacin de bloques dedatos. Se clasifican en dos tipos principalmente: simtricos y asimtricos.

    El cifrado simtrico hace referencia a la existencia de una misma clave para cifrar y descifrar. Estaclave la tienen que conocer los dos extremos para poder establecer una comunicacin con xito. Algunosde los algoritmos ms conocidos son IDEA, 3DES, AES y RC4.

    2https://tools.ietf.org/html/rfc4949

  • 2.2. SEGURIDAD EN VIDEOCONSOLAS 5

    Tabla 2.1: Tabla de resultados de la operacin XOR.

    Primer operando Segundo operando Resultado

    0 0 00 1 11 0 11 1 0

    Sin embargo, no hace falta aplicar operaciones tan complejas cuando solo se desea ofuscar el texto,como sucede en los videojuegos. En estos casos, la operacin XOR sirve a este propsito (Tabla 2.1). Elprimer operando sera el byte a cifrar y el segundo un valor de clave. Esta operacin tiene el problemade que si se aplica sobre un byte con valor cero, el resultado ser el segundo operando, es decir, la clave.Otra desventaja es que, conociendo una seccin del texto plano y teniendo el texto cifrado, el resultadode aplicar XOR entre ambos sera la clave. Para evitar estos dos problemas, se usa una clave que cambiatras cada ejecucin, de forma que mediante un conjunto de bytes nulos solo se recuperara un estadotemporal de la misma.

    El cifrado asimtrico, a pesar de ser ms lento que el simtrico, soluciona el problema de compartirla misma clave usada para cifrar y descifrar. De esta forma, cada extremo posee una clave y no necesitaconocer la otra. Un mensaje cifrado con la primera clave solo podra ser descifrado con la segunda, yviceversa. Este tipo de algoritmo se usa en las comunicaciones a travs de redes inseguras como Internet.Cuando se genera el par de claves, una se suele mantener secreta (clave privada) y la otra se comparteentre varias entidades (clave pblica). El algoritmo ms utilizado es RSA, que soporta tanto cifrado ydescifrado como firma digital e intercambio de claves.

    2.1.2. Algoritmos para integridad

    Los algoritmos para integridad tienen como objetivo asegurar que el mensaje no ha sido modificado.Para ello, mediante una serie de operaciones, se ofrece un resumen de tamao fijo de los datos deentrada. Los algoritmos deben cumplir que las colisiones (coincidencias de resumen entre dos bloquesde datos distintos) sean no reproducibles. Estos se clasifican por el nmero de bits del resultado, siendolos ms frecuentes MD53, con 128 bits, y SHA-1, con 160 bits.

    2.1.3. Firma digital

    La firma digital es una tcnica para proveer tanto autenticidad como integridad sobre un mensaje.Consiste en aplicar un algoritmo de integridad sobre un bloque de datos y, el resultado cifrarlo conla clave privada del emisor. De esta forma, solo la clave pblica correspondiente a esta entidad podrdescifrarlo, asegurando que ha sido esta quien ha realizado la operacin. Adems, al tener el resumense puede comprobar que el mensaje no ha sido modificado. Lo frecuente es emplear SHA-1 para laintegridad y RSA para cifrar.

    2.2. Seguridad en videoconsolas

    La seguridad cada vez ms se confa en la consola, en lugar de sobre el propio juego. El principalproblema que esto genera es que una vez que esta proteccin se consigue romper, todos los juegosquedan expuestos.

    3Este algoritmo es inseguro.

  • 6 CAPTULO 2. SEGURIDAD EN VIDEOJUEGOS

    A principios de la era de los videojuegos, la piratera era poco comn, principalmente por la dificultaden encontrar el hardware necesario para romper los sistemas de proteccin. Los juegos se distribuanen cartuchos de solo lectura, ya que no existan memorias se uso genrico como SD, ni protocolos decomunicacin como USB.

    Con la introduccin de la Nintendo DS, esto cambi. Los juegos se distribuyen en pequeos cartuchosde tamao similar a una tarjeta SD. Debido a la existencia de tarjetas MicroSD, se pudieron creardispositivos que simulan ser un juego comercial y que permiten ejecutar cdigo no autorizado porNintendo. Estos se conocen como flashcards y se basan en exploits que consiguen saltarse las limitacionesdel sistema de la consola para, simulando ser un juego, comenzar la ejecucin de otro.

    2.2.1. Nintendo DS

    En el caso de la Nintendo DS, los juegos incorporan una lgica para transmitir, mediante un protocolo,datos cifrados a la consola [15]. Este cifrado se basa en dos claves, la primera constante y la segundagenerada en cada ejecucin. Se cifran los comandos enviados por la consola al cartucho y la respuestacon los datos del juego. Aparte del cifrado, la BIOS y firmware realizan una comprobacin sobre lacabecera del juego. En concreto, hay una regin donde se encuentra el logo de Nintendo ofuscado 4. Elpropsito es que, al contener datos con derechos de autor como es el logo de la compaa, los juegos nose podran distribuir sin la autorizacin de Nintendo. Un caso similar fue llevado a juicio en EstadosUnidos, perdiendo Sony, la empresa que pretenda evitar estas actuaciones [7, p. 18].

    El caso descrito sucedi con la consola Sega Genesis, cuando la empresa Accolade, en lugar deafiliarse con Sega para desarrollar juegos, decidi realizar ingeniera inversa y crear sus productos enbase a esa informacin. Esta compaa determin que la palabra SEGA tena que estar contenida en lacabecera del juego para hacerlo funcionar. Sin embargo, esos caracteres estn protegidos con copyrightpor Sega y en base a esto, llev a cabo una demanda. Finalmente, la corte le dio la razn a Accolade yaque no haba copiado cdigo de Sega y beneficiaba al mercado introduciendo competencia.

    2.2.2. Nintendo DSi

    Un sistema ms robusto se introdujo con la Nintendo DSi. El formato de los juegos se mantienepero, en aquellos juegos exclusivos para la nueva generacin, se aade una firma digital usando la claveprivada de Nintendo. El sistema operativo de la consola comprueba la firma y, de ser invlida, el juegono se ejecuta.

    Mediante este procedimiento, las flaschard dejaron de funcionar. No se poda ni generar una firmadigital vlida, ni utilizar una existente porque, al modificar el cdigo del juego, la firma sera invlida.

    El agujero de seguridad vino junto a las malas implementaciones de algunos juegos. Modificandolos archivos de guardado de ciertos juegos, se consegua provocar un fallo del juego (buffer overflow),de forma que el siguiente cdigo que ejecutaba era el almacenado en el propio archivo de guardado.Esto implica que distribuyendo un juego comercial con este fallo junto a una partida preparada paraexplotarlo, se podan crear flashcard que ejecutasen cualquier cdigo contenido en el archivo de lapartida.

    4http://pleonet.blogspot.com.es/2013/08/logo-de-nintendo-en-gba-y-nds.html

  • 2.3. INGENIERA INVERSA 7

    2.2.3. Nintendo 3DS

    La siguiente generacin de consolas de Nintendo aument ms la seguridad. Los juegos distribuidosvienen protegidos con un cifrado simtrico implementado sobre un mdulo hardware de la consola.Cuando se piden datos al cartucho, estos pasan por el mdulo de descifrado de la consola y se almacenanen la memoria RAM. Se trata de un mdulo diseado especficamente para la consola, encontrndose laclave sobre las pistas del chip, por lo que no se puede averiguar.

    Para incrementar la seguridad se colocaron los componentes de la consola estratgicamente, deforma que era complicado extraer y acceder a la memoria RAM. A pesar de ello, hubo personas queconsiguieron acceder, pudiendo leer los datos descifrados del juego e incluso alterar las instruccionesalmacenadas en la memoria para ejecutar cdigo que forzara descifrar del juego completo. Fue este,as, un proceso manual que permiti encontrar una serie de exploits5 que se aprovechaban de nuevo defallos de seguridad en los archivos de guardado para ejecutar cdigo descifrado directamente.

    2.3. Ingeniera inversa

    Reverse engineering is the process of analyzing a subject system to identify the systems compo-nents and their inter-relationships, and to create representations of the system in another form or athigher levels of abstraction.

    La ingeniera inversa es el proceso de analizar un sistema para identificar sus componentes yrelaciones y, crear una representacin del sistema en otro formato o a un nivel ms alto de abstraccin.

    Con estas palabras defini el compendio del proyecto europeo REDO en 1993 el trmino ingenierainversa [6, p. 17]. Se trata de un proyecto enmarcado dentro del plan European Strategic Program onResearch in Information Technology (ESPRIT). El trabajo realizado por 11 organizaciones de 7 pasestena como objetivo tratar el problema del mantenimiento de software mediante tcnicas de ingenierainversa. Para ello se propusieron los siguientes objetivos:

    1. Validar el software existente.

    2. Acoplar el software y su documentacin.

    3. Usar mtodos formales en mantenimiento de software.

    4. Mejorar la usabilidad del software existente mediante mejores interfaces de usuario.

    5. Desarrollo y mejora de herramientas para reestructurar el cdigo fuente y el control de trabajo.

    6. Desarrollo de un lenguaje genrico con el que se pueda expresar la semntica de diferentes lenguajesde programacin y control de trabajo.

    Este proyecto identific dos tareas principales a la hora de realizar un trabajo de ingeniera inversa [6,p. 17]:

    Redocumentacin. Proceso por el que se crea una representacin semnticamente equivalente conel mismo nivel de abstraccin. En este trabajo se ha llevado a cabo mediante el desarrollo deciertos programas que procesan ficheros de igual forma que lo hace un videojuego.

    Recuperacin de diseo. Proceso que involucra identificar el diseo en niveles ms altos deabstraccin que aquellos se que pudieran ver, examinando el sistema en s. Esta tarea se ha llevadoaqu documentando los algoritmos estudiados.

    5http://smealum.net/ninjhax/

  • 8 CAPTULO 2. SEGURIDAD EN VIDEOJUEGOS

    En proceso de desarrollo comn es el de programar una aplicacin en un lenguaje de alto nivel y,mediante un software denominado compilador, convertir el texto escrito en una serie de bytes que elordenador es capaz de interpretar para ejecutar operaciones a nivel de hardware. La tarea de depuracin,en el caso de la ingeniera inversa, trata sobre analizar esos bytes, instrucciones que el ordenadorinterpreta, y a partir de ellas entender el diseo original en alto nivel. Existen programas llamadosdescompiladores que automatizan esta tarea para diferentes lenguajes de programacin, como porejemplo, el que incluye IDA Pro para convertir lenguaje ensamblador en lenguaje C.

    La forma de evitar este proceso, aparte de aplicar cifrados a nivel de hardware como hace la Nintendo3DS (Apartado 2.2.3), es mediante ofuscacin de cdigo. Este proceso consiste en transformar el cdigode forma que es menos legible, pero mantiene la funcionalidad [7, p. 344]. Debe de cumplir ademsque las transformaciones aplicadas no sean sencillas de revertir, de forma que no se pudiera crearun desofuscador y que el sobrecoste que este proceso conlleva no afecte al rendimiento. El nivel decomplejidad que aade esta tcnica se llama potencia, y se puede medir con software convencionalque toma en cuenta factores como el nmero de funciones y la profundidad de anidado que tiene unasecuencia de cdigo.

    Un sistema podra considerarse seguro una vez que el esfuerzo y tiempo que requiere romper suseguridad es mayor al valor del producto y su validez. Un ejemplo sera que el coste de distribuir copiasno legales de un juego sea mayor al coste del mismo original, o que el tiempo empleado para averiguaruna clave sea mayor a la frecuencia con la que el sistema la cambia.

    En cuanto a la ingeniera inversa en videojuegos, no es distinta a los procedimientos seguidos sobreaplicaciones. Esta se centra ms sobre los recursos y sus formatos que en el cdigo y funcionalidad6.

    2.3.1. Legalidad

    La ingeniera inversa no est exenta de controversia a la hora de determinar su legalidad. El punto14 de la directiva 2009/24/CE sobre la proteccin jurdica de programas de ordenador7 dice:

    No debe impedirse a la persona facultada para utilizar el programa de ordenador que realice losactos necesarios para observar, estudiar o verificar su funcionamiento, siempre que dichos actos nosupongan infraccin de los derechos del autor sobre el programa.

    Es decir, siempre que se posean los derechos de acceder a un contenido, no se debe prohibir el derechoa estudiar este. Sin embargo, las directivas europeas son recomendaciones que los pases miembrosimplementan con sus propias leyes. En el caso de Espaa, se recoge en nmero 97 del BOE8 en el ttuloVII, Programas de ordenador, artculo 100, lmites a los derechos de explotacin:

    El usuario legtimo de la copia de un programa estar facultado para observar, estudiar o verificarsu funcionamiento, sin autorizacin previa del titular, con el fin de determinar las ideas y principiosimplcitos en cualquier elemento del programa, siempre que lo haga durante cualquiera de las operacionesde carga, visualizacin, ejecucin, transmisin o almacenamiento del programa que tiene derecho ahacer.

    6En la siguiente direccin se encuentra una gua de introduccin a la ingeniera inversa para Nintendo DS:http://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2014-edition-out.73394/7http://eur-lex.europa.eu/legal-content/ES/TXT/PDF/?uri=CELEX:32009L0024&from=EN8http://boe.es/buscar/act.php?id=BOE-A-1996-8930&tn=1&p=19980307&vd=#a100

  • 2.3. INGENIERA INVERSA 9

    donde se recoge el mismo contenido que la directiva europea recomienda. Esto, adems, est respaldadopor la resolucin de un juicio en la Corte Suprema de la Unin Europa en esta materia9. En ella, lacompaa World Programming Ltd fue demandada por SaaS Institute Inc. al desarrollar un software apartir de conocimientos adquiridos mediante ingeniera inversa, que replicaba el funcionamiento delprograma de la compaa demandante. La corte seal que There is no copyright infringement [when asoftware company without access to a programs source code] studied, observed and tested that programin order to reproduce its functionality in a second program. (No se infringe el copyright [cuando unacompaa de software sin acceso al cdigo fuente del programa] estudia, observa y prueba el problemapara reproducir su funcionalidad en un segundo programa).

    En el caso de Estados Unidos, la ley Digital Millennium Copyright Act (DMCA) lo prohbe a no serque se cuente con el permiso del autor. El Captulo 12 del libro Hacking the Xbox, escrito por Lee Tien,abogado de la Electronic Frontier Foundation (EFF), contiene un completo anlisis al respecto. Incluyeuna cita de la Corte Suprema americana, refirindose a la ingeniera inversa como una parte esencial dela innovacin [13, p. 180].

    9http://www.bloomberg.com/news/articles/2012-05-02/copyright-can-t-block-software-reverse-engineering-court

  • Captulo 3

    Planificacin y costes del proyecto

    Este captulo explica cmo se ha estructurado y planificado el trabajo, as como los costes que hasupuesto. Analizada la problemtica y su contexto, se ofrecer un enfoque global en cuanto a diferentesaspectos sobre videojuegos pocos tratados en la literatura.

    3.1. Organizacin

    El proyecto se ha estructurado en cinco tareas principales explicadas a continuacin:

    1. Caracterizacin de algoritmos. El objetivo es introducirse en el tema, estudiando los mecanismosactuales para proteger datos en videojuegos. Tambin se estudiar qu problemticas que seanalizarn en profundidad durante el trabajo. Estn implicadas las siguientes labores:

    Buscar informacin sobre seguridad en videojuegos.

    Buscar informacin sobre los algoritmos de Digital Resource Management (DRM) actuales.

    Identificar categoras sobre las que los algoritmos se centran.

    Identificar las caractersticas de cada categora.

    2. Escoger juegos para el estudio. Una vez analizada la situacin actual, e identificados los algoritmosdeseados para estudiar, el siguiente bloque estudiar qu juegos sern objeto del trabajo. As, lospuntos a desarrollar son:

    Buscar informacin sobre proyectos de edicin abandonados.

    Identificar juegos con contenidos con derechos de autor.

    Priorizar juegos por aquellos ms vendidos.

    3. Desarrollo de software de ayuda. Antes de comenzar la investigacin se planific un periodo detiempo para el desarrollo de utilidades para su posterior uso. Se incluy el estudio de un posibledesarrollo de una utilidad opcional que, si bien existan soluciones que podan usarse para eltrabajo, no eran de cdigo abierto. Las subtareas, as, a desarrollar aqu son:

    Crear script para clasificar juegos por nmero de ventas.

    Crear un gestor para una base de datos sobre algoritmos.

    Crear programas de bsqueda y modificacin binaria avanzada.

    (Opcional) Desarrollar depurador de cdigo remoto para Nintendo DS (NDS). Se optfinalmente por usar el emulador freeware No$GBA.

    11

  • 12 CAPTULO 3. PLANIFICACIN Y COSTES DEL PROYECTO

    4. Anlisis de juegos. Creados los programas de ayuda, se comenz con el anlisis de los juegos. Sedividieron en tres rondas para ir agrupando los resultados obtenidos:

    Reunir y complementar la informacin sobre juegos previamente estudiados.

    Primera ronda de siete juegos.

    Segunda ronda de siete juegos.

    Tercera ronda de siete juegos.

    Analizar servicios en lnea.

    5. Redaccin de memoria. Esta tarea se refiere al desarrollo de un documento que explique todos losresultados del trabajo. Para ello, se prevn las siguientes actuaciones:

    Aprender LATEX.

    Crear una plantilla para el trabajo.

    Desarrollo de la memoria.

    3.2. Planificacin

    El trabajo se ha planificado para realizar las cinco tareas descritas anteriormente, en el plazo de ochomeses descontando festivos. Comenzando en octubre, el anlisis del problema planteado y el estudio delarte ocuparn los dos primeros meses de trabajo. Juntando el desarrollo de software de ayuda, ambaspartes se estimaron que tomaran hasta principios de 2015.

    Desde comienzos de ao hasta Semana Santa se planific la realizacin de los anlisis de los juegos.La estimacin fue realizar un anlisis de siete juegos cada mes y medio. Una vez terminado el anlisis,se revisaron todos los resultados y se redactaron una serie de conclusiones que tomaran hasta el mesde mayo.

    El ltimo bloque del trabajo sera el desarrollo de la memoria, incluyendo el aprendizaje del entornoLATEX. Esto se estim que durara un mes y medio hasta finales de junio. En la Figura 3.1 se muestraun diagrama de Gantt a pgina completa con las temporizacin global del proyecto.

    3.3. Presupuesto

    La realizacin de este trabajo ha supuesto una serie de costes. A continuacin se detallan tanto losrecursos empleados, como la estimacin del coste de los mismos.

    3.3.1. Recursos

    En la elaboracin de este trabajo se han necesitado tanto recursos de personal como materiales.Estos se detallan a continuacin.

    Recursos de personal

    Las siguientes personas han participado en el desarrollo del trabajo.

    D. Benito Palacios Snchez, alumno del Grado en Ingeniera de Tecnologas de Telecomunicacinen la Universidad de Granada, en calidad de autor del trabajo.

  • 3.3. PRESUPUESTO 13

    Oct

    Nov

    Dic

    Ene

    roFe

    bM

    arzo

    Abr

    ilM

    ayo

    Juni

    o

    Tare

    asFe

    chas

    4042

    4446

    4850

    5202

    0406

    0810

    1214

    1618

    2022

    2427

    Car

    acte

    riza

    cin

    deal

    gori

    tmos

    Situ

    aci

    n ac

    tual

    DR

    M29

    /09

    01

    /10

    Alg

    oritm

    os e

    xist

    ente

    s D

    RM

    02/1

    0

    09/1

    0

    Iden

    tific

    ar c

    ateg

    ora

    s de

    algo

    ritm

    os10

    /10

    12

    /10

    Iden

    tific

    ar la

    s car

    acte

    rstic

    as d

    e al

    gorit

    mos

    13/1

    0

    19/1

    0

    Esc

    oger

    jueg

    osa

    estu

    diar

    Enco

    ntra

    r pro

    yect

    os a

    band

    onad

    os20

    /10

    26

    /10

    Enco

    ntra

    r jue

    gos

    con

    cont

    enid

    o co

    n co

    pyrigh

    t27

    /10

    05

    /11

    Ord

    enar

    jueg

    os p

    or v

    enta

    s06

    /11

    09

    /11

    Des

    arro

    llode

    soft

    war

    ede

    ayu

    da

    Cla

    sific

    ador

    de

    jueg

    os27

    /10

    09

    /11

    Dep

    urad

    or d

    e c

    digo

    a d

    ista

    ncia

    (GD

    B S

    tub)

    10/1

    1

    23/1

    1

    Ges

    tor d

    e ba

    se d

    e da

    tos d

    e re

    sulta

    dos

    24/1

    1

    07/1

    2

    Bus

    cado

    r y e

    dito

    r bin

    ario

    ava

    nzad

    o08

    /12

    21

    /12

    An

    lisis

    de

    jueg

    os

    Jueg

    os y

    a es

    tudi

    ados

    08/1

    2

    04/0

    1

    Prim

    era

    rond

    a (7

    jueg

    os)

    22/1

    2

    15/0

    2

    Segu

    nda

    rond

    a (7

    jueg

    os)

    06/0

    2

    29/0

    3

    Terc

    era

    rond

    a (7

    jueg

    os)

    16/0

    3

    10/0

    5

    Ana

    lizar

    serv

    icio

    s en

    lne

    a27

    /04

    24

    /05

    Mem

    oria

    Red

    acta

    r25

    /05

    05

    /07

    Figura 3.1: Diagrama de Gantt del proyecto.

  • 14 CAPTULO 3. PLANIFICACIN Y COSTES DEL PROYECTO

    Profesor Dr. D. Pedro Garca Teodoro, Catedrtico de la Universidad de Granada adscrito al reade Ingeniera Telemtica en el Departamento de Teora de la Seal, Telemtica y Comunicaciones,en calidad de tutor del proyecto y supervisor de la propuesta.

    Recursos materiales

    Los recursos materiales se han dividido en dos secciones detalladas a continuacin.

    Hardware

    Ordenador porttil Asus X66IC.

    Telfono mvil iOS con jailbreak iPhone 4.

    Router Linksys modelo WRT54G.

    Cable Ethernet de 2 metros.

    18 juegos para Nintendo DS, 2 para iOS y 1 para Play Station 3.

    Software

    Sistemas operativos Fedora 20 y 22.

    Gestor de control de versiones git.

    Editor de texto Atom.

    Entorno de desarrollo integrado MonoDevelop.

    Compilador para C# mono.

    Intrprete de python.

    Emuladores para Nintendo DS con capacidades de depuracin DeSmuME y No$GBA.

    Distribucin de LATEXtexlive.

    Editor de imgenes GIMP.

    Analizador de capturas de trfico Wireshark.

    Visor de bases de datos sqliteman.

    Explorador de archivos de juegos para Nintendo DS Tinke.

    Editor hexadecimal wxHexEditor y HxD.

    3.3.2. Estimacin de costes

    La estimacin de costes se realiza en base a los recursos utilizados y comentados en el apartadoanterior, as como la temporizacin detallada en la Seccin 3.2.

    Coste de personal

    La duracin del trabajo se ha estimado en unas 378 horas siguiendo el siguiente desglose:

    Anlisis del estado del arte y planificacin: 20 horas.

    Desarrollo del software de ayuda: un mes a media jornada de lunes a viernes, 100 horas.

  • 3.3. PRESUPUESTO 15

    Tabla 3.1: Coste de los recursos de personal.

    Concepto Coste Cantidad Total

    Desarrollo 20 euros/h 378 h 7.560 eurosSupervisin 100 euros/h 17 h 1.700 euros

    Total: 9.260 euros

    Anlisis de juegos: 8 horas de media por juego y 21 juegos, 168 horas.

    Redaccin de la memoria: medio mes a media jornada de lunes a viernes y jornada completa losfines de semana, 90 horas.

    Las reuniones con el tutor eran cada dos semanas con una duracin media de 30 minutos. Comenzandodesde septiembre hasta julio y descontando festivos se estiman unas 20 reuniones, resultando en 10horas. Adems se han de contar las diferentes discusiones previas al trabajo y las revisiones de lamemoria, sumando un total de 17 horas.

    Basndose en publicaciones sobre el salario de un recin graduado en Ingeniera de Tecnologas deTelecomunicacin, se estima un sueldo medio de 20 euros por hora de trabajo. En cuanto a la consultaradel tutor, teniendo en cuenta la categora de catedrtico de la Universidad de Granada, se estima unsueldo medio neto de 100 euros por hora de trabajo.

    El coste total de este apartado se muestra en la Tabla 3.1, ascendiendo a 9.260 euros, NUEVE MILDOSCIENTOS SESENTA EUROS.

    Coste de materiales

    Los materiales, como se comentaron en el apartado de recursos, se dividen en hardware y software.

    El coste del hardware usado se ha estimado teniendo en cuenta su vida til y precio inicial. Elordenador porttil valorado en 600 euros, con una vida til de 7 aos, ha supuesto un coste total de 65euros para la realizacin del trabajo en 9 meses. Tanto el telfono mvil, el router y el cable Ethernethan sido utilizados durante periodos de tiempo muy cortos y tienen una vida til muy larga, por lo quesu precio no se incluye en el clculo total.

    Para el estudio de los juegos, se tuvo que adquirir una copia fsica legal de los mismos. Los juegos paraNintendo DS, al ser no ser una consola de ltima generacin, se pueden adquirir por una media de 15 eurospor copia. El juego para Play Station 3 utilizado se puede adquirir en la tienda virtual de Sony por 5 euros.Finalmente, los dos juegos para plataformas mviles se encuentran de forma gratuito durante periodos deoferta. Esto hace un total de 18 juegos * 15 euros/juego + 1 juego * 5 euros/juego = 275 euros.

    Refirindose al primero, se escogieron dando prioridad a soluciones de software libre para poderestudiarlos y modificarlos. En caso de no existir se analizaron por precio, de manera que en cuanto aeste apartado no hubo costes.

    Presupuesto final

    El presupuesto total se basa en los clculos descritos en la secciones anteriores. Adems, se aade unsuplemento por costes indirectos tales como manutencin, electricidad y conexin a Internet, de untotal de 200 euros para todos los meses de trabajo.

    El clculo de este presupuesto se muestra en la Tabla 3.2, haciendo un total de 9.800 euros, NUEVEMIL OCHOCIENTOS EUROS.

  • 16 CAPTULO 3. PLANIFICACIN Y COSTES DEL PROYECTO

    Tabla 3.2: Presupuesto final.

    Concepto Coste

    Recursos de personal 9.260 eurosRecursos de material 340 eurosGastos indirectos 200 euros

    Total: 9.800 euros

  • Captulo 4

    Metodologa

    Este captulo se centrar en explicar las diferentes metodologas, tcnicas y programas que se hanusado durante el desarrollo del proyecto. No existe un nico mtodo cuando se realiza un trabajo deingeniera inversa ya que cada juego es distinto, con formatos diferentes. Debido a esto, en lugar deproporcionar unos pasos exactos, se detallarn los razonamientos seguidos a la hora de estudiar ficherosy analizar cdigo.

    4.1. Anlisis de ficheros

    Una vez decidido el juego a analizar, se debe reunir informacin como es el desarrollador, el aode lanzamiento y gnero del juego. Esta proporciona indicios sobre el tipo y versin del formato delos ficheros que contiene. A continuacin se pueden usar programas de exploracin de juegos comoTinke1, para reconocer los tipos de formato estndar, analizar el contenido de las carpetas y exportarlos archivos.

    El inters, sin embargo, es analizar aquellos formatos nuevos que codifican recursos como imgenesy textos. Los nombres y directorios de los archivos son la primera referencia sobre el tipo de con-tenido. Por ejemplo, tomando el juego de Ninokuni para Nintendo DS como referencia, el archivo/data/UI/Menu/Skin/2/CheckSheet/bg_a.n2d debe contener elementos de la interfaz grfica (GUI )del men (Menu) del juego. Adems, la abreviatura bg se utiliza para describir imgenes de fondo depantalla (background). Mirando el contenido de este archivo con un visor hexadecimal, se puede ver queen la posicin 0x54 se encuentran los caracteres RLCN, correspondientes a la cabecera de un formatoestndar en la Nintendo DS (Figura 4.1).

    1https://github.com/pleonex/tinke

    Figura 4.1: Contenido de un fichero con imgenes de Ninokuni.

    17

  • 18 CAPTULO 4. METODOLOGA

    Figura 4.2: Contenido de un fichero comprimido de Ninokuni.

    Encontrar esta cabecera indica que este archivo contiene varios ficheros, en un formato similara zip, ya que de otro modo estara al comienzo de los datos. El anlisis se centra en saber cmoextraer los ficheros para luego determinar qu datos tienen cada uno de ellos. Se parte sabiendo que laposicin del primer fichero es 0x54, por lo que se buscar este valor en la cabecera del formato. En laposicin 0x0C se observa ese valor, seguido de 0x228. Frecuentemente, despus de la posicin de unfichero se indica su tamao, por lo que habr que comprobar si el primer fichero termina en la posicin0x54 + 0x228 = 0x27C. En la Figura 4.2 se ve que en esa posicin aparece la cabecera RGCN, estndarpara otro formato de archivo, por lo que es el comienzo de otro fichero.

    Esto corrobora la estructura que se intua, por cada fichero hay 8 bytes indicando posicin ytamao. Para determinar el nmero de ficheros se puede calcular cuntos archivos especifica esa tablade contenidos, restando el principio del primer fichero a la posicin de la primera entrada y dividiendopor el nmero de bytes dedicado a cada entrada: (0x54 - 0x0C) / 0x08 = 9. El resultado es que sehan especificado 9 ficheros, valor que coincide con el encontrado en la posicin 0x08 (Figura 4.1).

    Esta forma de razonar es la que se ha empleado para averiguar acerca de los formatos estudiadosen el trabajo. Falta averiguar el contenido de cada fichero. Estudiando los formatos ms comunes, sepuede identificar (Figura 4.2) que al principio hay colores, pues cada valor de 16 bits est prximo alsiguiente. Al final, hay informacin sobre pxeles, en concreto el ndice al color de la paleta, ya que serepiten muchos valores que estn prximos. Esto concuerda con el hecho de que un pxel en una imagensuele tener a su alrededor pxeles de color similar.

    Otro ejemplo se encuentra en los archivos de tipo PSAR (Figura 4.3) analizados en la Seccin 6.1.1.En ellos, en la posicin 0x08, mediante los caracteres ASCII se indica el tipo de compresin que se usasobre los datos, zlib.

    Figura 4.3: Primeros bytes del fichero PSAR.

  • 4.2. DEPURACIN DE CDIGO 19

    (a) IDA Pro 6.1 con DeSmuME. (b) Emulador con depurador integrado No$GBA.

    Figura 4.4: Programas para depurar juegos de Nintendo DS.

    4.2. Depuracin de cdigo

    En ocasiones, el anlisis de un fichero hexadecimal no es suficiente para estudiar un formato. Estees el caso de codificaciones complejas y estudios de cifrado e integridad en los que hace falta mirarla implementacin del juego. En estos casos, mediante depuracin del juego se pueden analizar lasinstrucciones mquina que ejecuta la consola, para saber cmo procesa el juego los ficheros y as poderestudiarlos. La depuracin de juegos de Nintendo DS se puede realizar utilizando dos procedimientos(Figura 4.4).

    El primer mtodo es usar el emulador DeSmuME y el depurador IDA Pro. Este emulador se puedecompilar activando funciones de depuracin remotas. Incluye una implementacin de GDB RemoteSerial Protocol2 que permite que programas externos controlen la ejecucin del juego paso a paso yaccedan a la memoria RAM. Esto es lo que hace IDA Pro, sirviendo como un depurador universal. Deesta forma se puede visualizar el cdigo en ensamblador, poner puntos de interrupcin y ver y cambiarla memoria del juego.

    La alternativa es usar el emulador privativo No$GBA. Existe una versin que incluye un depuradororiginalmente de pago, pero que recientemente se liber como freeware. Incluye las mismas funcionesdescritas anteriormente, pero en este caso implementadas sobre el propio emulador, aumentando as laeficiencia.

    Dado que IDA Pro es un programa con una licencia bsica de coste $500, este trabajo se realiz conel emulador No$GBA que, a pesar de no tener tanta funcionalidad, s provee de las necesarias pararealizar el trabajo sin coste.

    4.2.1. Bsqueda de archivos en memoria RAM

    Esta subseccin explicar el procedimiento seguido para, mediante depuracin, averiguar cmoel juego procesa un fichero. Para ello hace falta conocer cmo se obtienen datos del cartucho deljuego. El protocolo de comunicacin es sencillo: cuando se necesitan datos, se enva un comando queel hardware cifra (esa parte, al usar un emulador, no se realiza), y al cual al cartucho responde conlos datos solicitados. El cdigo de este comando es 0xB7 y se enva escribindolo en el puerto virtual0x040001A8 [15].

    Esta direccin se puede buscar en el cdigo ensamblador, encontrando la funcin que solicita los datos.Gracias a esto se puede poner un punto de interrupcin y comprobar qu direcciones se piden. Dadoque continuamente se estn cargando datos, realizar esto manualmente no es viable. Es por ello que,aprovechando que el emulador DeSmuME es de cdigo abierto, se puede modificar para automatizarlo.

    Esta mecnica se implement para realizar los anlisis de este trabajo, desarrollando el programaNitroFilcher3. En el emulador se aadieron las siguientes lneas de cdigo a la funcin HandleDebugEvent_Execute del archivo debug.cpp, consiguiendo que cada vez que se ejecutara las instrucciones quesolicitan datos, guardase en un fichero de texto la posicin que se peda junto al tamao:

    // 0x02016DE0 es la direccin de la funcin que solicita datos.

    2http://www.embecosm.com/appnotes/ean4/embecosm-howto-rsp-server-ean4-issue-2.html3https://github.com/pleonex/AiroRom/tree/master/Programs/NitroFilcher

  • 20 CAPTULO 4. METODOLOGA

    if (DebugEventData.addr == 0x02016DE0 && log_ptr != NULL) {u32 addr = DebugEventData.cpu()->R[2];u32 size = DebugEventData.cpu()->R[3];fprintf(log_ptr, "%08X,%08X,%08X\n", addr, size, addr + size);

    }

    Este fichero luego lo procesara el programa NitroFilcher, escribiendo en otro fichero de texto lasrutas a los archivos que correspondan esas direcciones.

    4.2.2. Bsqueda de algoritmos sobre textos

    En el Captulo 5 se mostrarn algoritmos para ofuscar y cifrar textos. El procedimiento para realizareste estudio se basa en depuracin de cdigo.

    El primer paso es buscar la frase en texto plano sobre el binario del juego. Tras determinar que noaparece, se puede confirmar que puede estar codificada en una codificacin no estndar, comprimida ocifrada. Se suele probar con las codificaciones soportadas nativamente por las fuentes de Nintendo DS,como son UTF-8, UTF-16, SHIFT-JIS y CP1252.

    Confirmado que hay un algoritmo que se aplica sobre el texto, el objetivo es encontrar este texto enla memoria RAM del juego, para poder poner un punto de interrupcin y ver qu transformaciones seaplican hasta llegar al texto descifrado. Para ello, se extrae la memoria justo en el momento de mostrarun dilogo de texto, pues debera estar la frase guardada para poder mostrarla en pantalla. Esto sepuede realizar con cualquier emulador de Nintendo DS. Una vez extrado el archivo binario con lamemoria, se busca el texto mediante visores hexadecimales, usando de nuevo codificaciones estndar. Sila frase se encuentra, se pondra un punto de interrupcin en dicha posicin y se estudiara el algoritmo.De no ser as, probablemente se use una codificacin propietaria. En esos casos se puede encontrarsiguiendo la metodologa explicada en los siguientes apartados.

    Bsqueda de la tipografa

    El primer procedimiento consiste en buscar el archivo con la tipografa del juego, pues la codificacinser la misma que el orden con el que aparecen los caracteres en ella. El estndar de este formato tienela cabecera NTFR y existen programas para extraer y editar este tipo de formatos4.

    Bsqueda diferencial

    El segundo procedimiento pasa por desarrollar un programa de bsqueda diferencial. Una implemen-tacin se llev a cabo para este estudio, denominado RelativeSearch y disponible en el repositorio deltrabajo5.

    La idea de este programa se basa en que un grupo de caracteres similares tiene una numeracinseguida. Por ejemplo, si la codificacin indica que el carcter a tiene asociado el valor 0x0123, elcarcter b tendr el siguiente, 0x0124. Restando ambos valores, se encuentra su distancia en elabecedario. Esta distancia, en la mayora de los casos, ser la misma en cualquier codificacin, inclusopropietaria, a no ser que se hayan desordenado los caracteres.

    RelativeSearch (Figura 4.5) implementa esta idea. Para ello dada una palabra como hola resta cadacarcter sobre el anterior y guarda esa diferencia. A continuacin, realiza esta misma operacin sobreun fichero binario, resta un byte sobre el anterior y compara la diferencia. Si la diferencia coincide, semuestra en pantalla la posicin de la coincidencia. El programa soporta la bsqueda de codificacionesde 8 y 16 bits.

    4https://github.com/pleonex/NerdFontTerminatoR5https://github.com/pleonex/RelativeSearch

  • 4.3. INTERCEPTACIN DE LA COMUNICACIN 21

    Figura 4.5: Frase con codificacin no estndar encontrada por RelativeSearch en Pokmon.

    4.2.3. Bsqueda de algoritmo sobre imgenes

    El procedimiento para encontrar el algoritmo de cifrado en este caso es distinto al realizado contexto. No se puede partir de datos conocidos como anteriormente se haca con una frase que se vea enla pantalla. Sin embargo, dado que las cabeceras de la imagen suelen ser estndar, se puede buscarsobre el cdigo en ensamblador la funcin que la procesa. En concreto se busca el identificador CHAR,que se lee para determinar el comienzo de una seccin del archivo.

    Una vez encontrada la funcin que carga una imagen, se puede poner un punto de interrupcin sobreella para tener acceso a los datos cifrados cuando el juego procese un archivo. Una vez localizados, seaade un punto de interrupcin sobre los datos cifrados de la imagen, el cual llevar al cdigo que losprocesa y, por tanto, el algoritmo que los descifra.

    4.3. Interceptacin de la comunicacin

    La Nintendo DS fue la primera porttil de Nintendo en soportar servicios en lnea mediante unaconexin Wi-Fi. Esta comunicacin se ha estudiado en el Captulo 7, explicndose en esta seccin lametodologa seguida para capturar los paquetes.

    Para ello se prepar un escenario para realizar un ataque man-in-the-middle. Un punto de acceso seconect al ordenador mediante Ethernet y este, a su vez, mediante conexin Wi-Fi, con el punto deacceso original. Dado que el sistema operativo Fedora 20 tiene por defecto una configuracin restrictivade red, se tuvo que disear el siguiente script para configurar una subred mediante NAT y permitir elredireccionamiento de paquetes:

    # El primer argumento es la IP de la interfaz que tiene conexin a Internet# Crea la ruta hacia la subredsudo route add -net 192.168.3.0/24 gw 10.42.0.29 p35p1

    # Habilita SNAT para la segunda subredsudo iptables -t nat -I POSTROUTING -s 192.168.3.0/24 -o wlp4s0 -j SNAT --to $1

    # Permite los paquetes de destino la segunda subredsudo iptables -t filter -I FORWARD -d 192.168.3.0/24 -j ACCEPT

    # Permite los paquetes con origen la segunda subred

  • 22 CAPTULO 4. METODOLOGA

    sudo iptables -t filter -I FORWARD -s 192.168.3.0/24 -j ACCEPT

    # Permite sin restriccin los paquetes con destino la primera subredsudo iptables -t filter -I FORWARD -d 10.42.0.0/24 -j ACCEPT

    Usando Wireshark para capturar los paquetes sobre la interfaz de Ethernet se pudo ver todo eltrfico. Este escenario requera hardware y era complejo de montar cada vez que se quera analizar unjuego. Es por ello que, aprovechando que el emulador DeSmuME soporta las comunicaciones Wi-Fiy es de cdigo libre, se modific para guardar los datos que transmita y enviaba en formato PCAP,compatible con Wireshark.

    Se modificaron los archivos wifi.cpp y wifi.h6, aadiendo los siguientes mtodos:

    create_packet(): inicializa un nuevo archivo PCAP para guardar los datos. Esta funcin se llamacada vez que se realiza una peticin de asociacin con el punto de acceso, es decir, cuando seinicia una conexin.

    save_packet(u8* packet, u32 len): guarda un paquete Ethernet en el archivo.

    save_adhocPacket(u8* packet, u32 len, void* addrGen, bool isSent): genera un paque-te con cabeceras Ethernet, IP y UDP y guarda los datos de la capa aplicacin que se le pasa.Esta funcin se llama cuando se enva un paquete mediante comunicacin ad-hoc a otra consola.Dado que este paquete solo contiene datos en formato del protocolo de Nintendo, para poderanalizarlo con Wireshark es necesario crear las cabeceras de la capa de enlace, red y transporte.

    Esta comunicacin sin embargo est cifrada. En la Seccin 7.1.1 se explica, sobre los resultados delos servicios en lnea de Nintendo, cmo utilizar los programas desarrollados RC4Finder y SSLPatcherpara capturar una comunicacin descifrada.

    4.4. Documentacin y repositorio

    Los programas y documentacin de este trabajo se han ido publicando en un repositorio, gestionadopor git, y subido a la pgina GitHub, con el siguiente enlace:

    https://github.com/pleonex/AiroRom

    La documentacin se fue redactando en formato Markdown en la wiki7 del repositorio. En lapgina de Mecanismos a investigar, se muestran los juegos ordenados por desarrollador con ms juegospublicados. Para crear esta clasificacin se hizo el script en python llamado Scenadvorter. Este programalee un XML con una base de datos de todos los juegos para Nintendo DS que proporciona la pginaADVANsCEne8, y clasifica los juegos por desarrollador mostrando los diez primeros con ms juegos.

    Para guardar la informacin sobre los algoritmos descubiertos se desarroll un programa que permitaguardar y editar dicha informacin en ficheros XML. Este programa (Figura 4.6) se llam DataBrithmy su cdigo se encuentra en el repositorio tambin.

    En la carpeta Games y Programs del repositorio se hallan los programas desarrollados para analizarlos contenidos de los juegos. Esta memoria, realizada con LATEX [16], est en Report.

    6https://github.com/pleonex/AiroRom/tree/master/Programs/DeSmuME%20PCAP7https://github.com/pleonex/AiroRom/wiki8http://www.advanscene.com

  • 4.4. DOCUMENTACIN Y REPOSITORIO 23

    Figura 4.6: Programa de gestin de algoritmos de juegos DataBrithm.

  • Captulo 5

    Traducciones no oficiales

    Las traducciones no oficiales, conocidas informalmente como fan-traducciones [27], son trabajosrealizados por personas externas a la compaa desarrolladora. Su objetivo es traducir un videojuegoy compartirlo de forma altruista. La distribucin se hace comnmente en foros dedicados y medianteparches, es decir, archivos binarios que contienen solo las modificaciones realizadas y, en principio, nocontenido con derechos de autor. Este captulo se ha centrado en los resultados obtenidos al analizarjuegos principalmente de la consola Nintendo DS. La seleccin se ha realizado en base a sagas que hantenido ms traducciones no oficiales (Pokmon), juegos con proyectos largos de traduccin (Ninokuni)y aquellos en los que se han visto solicitudes o intentos (London Life y dems).

    Este tipo de trabajos se remontan al origen de los ordenadores cuando, en 1993, se forma el primergrupo de traduccin llamado Oasis para MSX [24]. A partir de entonces, han surgido numerososproyectos, con dos pginas webs como referencia: GbaTemp.net1 y ROMHacking.net2. El motivo parainiciar un proyecto es la confirmacin por parte de una empresa de que no se llevara a cabo la traduccindel juego. Como se explica en el ltimo apartado, a pesar de ello han existido casos en los que latraduccin se ha iniciado antes de dicha confirmacin y tras producirse esta, esos proyectos se detuvieron.No ha sucedido as con todos los juegos, pues en la saga de Pokmon han existido traducciones parcialesantes de la oficial, perjudicando las ventas de la compaa, pues los usuarios prefieren obtener una copiano lcita del juego antes de esperar a la salida oficial. Es en estos juegos donde, como se ha analizado enla siguiente seccin, se observa una evolucin de mecanismos para evitar y retrasar estos trabajos.

    Estos hechos se han visto reflejados recientemente en dos cartas de cese y desista enviadas porla empresa Square Enix a los grupos de traduccin de Final Fantasy Type-0 [21] para Play StationPortable (PSP) y Dragon Quest VII [2] para Nintendo 3DS. En ellas se alega que por motivos demercado no pueden permitir esos trabajos, refirindose a la salida de estos ttulos para otras consolas.En ambos casos, los grupos de traduccin pararon la traduccin.

    Relacionado con las traducciones, se encuentran los mods [29], modificaciones sobre un videojuegocon el objetivo de crear una versin alternativa. Usando el motor del juego se cambia historia, imgenes,sonidos y scripts. Existen comunidades dedicadas exclusivamente a este motivo como es Whack a Hack! 3

    para la saga Pokmon.

    Los mecanismos que se van a comentar a continuacin muestran cmo los archivos con contenido detexto e imgenes son los ms protegidos u ofuscados. Esto no evita en su totalidad la edicin, pues,teniendo acceso al cdigo mquina que ejecuta la consola, se puede mirar cmo accede a los ficheros.Sin embargo, s puede retrasar o al menos imposibilitar para aquellas personas que no tengan losconocimientos tcnicos necesarios.

    1http://gbatemp.net/2http://www.romhacking.net/3http://wahackpokemon.com/es

    25

  • 26 CAPTULO 5. TRADUCCIONES NO OFICIALES

    5.1. Saga Pokmon en Nintendo DS

    Pokmon es una serie de juegos desarrollados por Game Freak desde 1993 para las consolas deNintendo. La saga se divide en denominadas generaciones, que engloban al menos tres juegos. Ha sidouna de las franquicias ms exitosas a nivel mundial [5], con series de animacin y pelculas entre otros.

    A causa de la fama de los juegos y la falta de paciencia de los seguidores, se desarrollan traduccionesparciales del juego. Estos proyectos, comenzados pocas horas despus del primer lanzamiento en Japn,pretenden ofrecer una versin parcialmente traducida en semanas, adelantndose a los lanzamientosoficiales. Este es el caso de comunidades como PokCheats.net4 o ProjectPokemon.org5.

    Es por estos motivos que Game Freak, desde el primer juego de Nintendo DS, incluy mtodos deofuscacin, con el objeto de no solo evitar traducciones, si no tambin los mods. Los textos que aparecenen dilogos y mens, al igual que las imgenes principales de Pokmons, son el primer objetivo a lahora de realizar una traduccin o edicin. Estos han sido el objeto de estudio y se han encontradolos algoritmos de proteccin que se analizarn en los siguientes subapartados. Adems, se ha podidocomprobar una evolucin de estas tcnicas a lo largo de las generaciones.

    Los sonidos y msica han sido los nicos archivos que no han estado protegidos. Se encuentran enun formato y codificacin estndar con extensin sdat en la carpeta raz del juego.

    5.1.1. Pokmon Perla y Diamante

    Los juegos Pokmon Diamante y Perla corresponden a la cuarta generacin de saga y a la primeraque sali para Nintendo DS. Primero lleg a Japn en septiembre de 2006, siete meses despus a losEstados Unidos y tres meses despus a Europa.

    Archivos

    Una de las caractersticas de la Nintendo DS respecto a su antecesora (GameBoy Advance) es laintroduccin del sistema de ficheros. El formato del juego incluye una seccin en la que indicar cmodividir los datos en ficheros y clasificarlos en carpetas con nombres. Esto ha facilitado la tarea deinvestigacin ya que, en la mayora de los juegos, los archivos tienen nombres descriptivos sobre sucontenido.

    Es el caso de esta generacin donde, como se ha visto (Figura 5.1), la jerarqua de carpetas y anms el nombre de los archivos ofrecen pistas de su contenido. Por ejemplo, en msgdata/msg.narc se hanencontrado los textos del juego, en itemtool/itemdata/item_icon.narc las imgenes de los objetos yen graphic/font.narc las tipografas del juego.

    Textos

    La investigacin de los textos se llev a cabo usando la metodologa descrita en la Seccin 4.2.2. Seha podido comprobar que estn cifrados, adems de codificados sin usar un estndar (como podra serASCII o UNICODE). Para usar el primer mtodo descrito, se ha buscado y estudiado la tipografa deljuego, determinando as la tabla de codificacin, es decir, el valor nmero que est asociado a cadacarcter (Tabla 5.1).

    El algoritmo es un cifrado con operacin XOR y clave dinmica aplicado sobre cada byte individual-mente. La clave inicial es igual a clave = (ushort)(0x91BD3 * (i + 1)), donde i es el bloque detexto a descifrar. Despus de descifrar un byte se actualiza segn clave = (ushort)(clave + 0x493D).

    4http://pokecheats.net/tools/translations.php5http://projectpokemon.org/

  • 5.1. SAGA POKMON EN NINTENDO DS 27

    Figura 5.1: Sistema de ficheros en Pokmon Perla visto con Tinke.

    Tabla 5.1: Especificacin de tipografas en Pokmon Perla.

    Posicin Tamao Descripcin

    Cabecera0x00 0x04 Puntero a la seccin de datos0x04 0x04 Puntero a la seccin VWT0x08 0x04 Nmero de caracteres0x0C 0x01 Ancho de un carcter0x0D 0x01 Alto de un carcter0x0E 0x01 BPP0x0F 0x01 BPP

    Datos de la fuentea

    Variable Width Table (VWT)ba Los caracteres estn codificados por tiles de 88 pxeles enformato horizontal.

    b Cada byte indica el ancho del carcter.

    El cifrado se ha aplicado tambin sobre los campos de la tabla de contenidos (ver Tabla 5.2). Se usala misma clave de 16 bits, concatenada dos veces, para aplicarla sobre los valores de 32 bits posicin ytamao de una misma entrada. Se inicializa con: clave = (ushort)(clave_base * 0x2FD * (i + 1)),donde i es el nmero de la entrada a descifrar. Como se ve, se hace uso de una clave base que seencuentra disponible en la cabecera del fichero.

    Sin embargo, esta parte del fichero presenta un fallo de seguridad, pues se est guardando la claveen texto plano. Como se ha comentado los valores cifrados son de 32 bits (4 bytes) pero, en el casodel campo posicin, la mayora de las veces solo se usan los dos primeros bytes. Ello se debe aque, como el tamao del fichero de texto no supera los 2^16 = 65535 bytes, no hacen falta posicionesms grande de estas. Esto ocurre tambin sobre el campo tamao donde se aplica la misma clave, yaque en pocas ocasiones un dilogo ocupar ms de 65 KB. Debido a que la clave se concatenapara descifrar el valor de 32 bits, se est aplicando sobre bytes con valor 0, quedando la clave almacena-da en texto plano: valor_cifrado = (00 00 AB CD) XOR (XW YZ XW YZ) = (XW YZ EF GH), siendo00 00 AB CD el campo descifrado y XW YZ la clave.

    En la Tabla 5.2 se especifica el formato de los archivos de texto.

  • 28 CAPTULO 5. TRADUCCIONES NO OFICIALES

    Tabla 5.2: Especificacin del formato de texto en Pokmon Perla.

    Posicin Tamao Descripcin

    Cabecera0x00 0x02 Nmero de bloques de texto0x02 0x02 Clave base para descifrar TOC

    Table Of Contenta

    0x00 0x04 Posicin del textob

    0x04 0x08 Tamao del textob

    Textoba Se especifica solo la primera entrada.b Campo cifrado descrito en la Seccin 5.1.1.

    Imgenes

    En este juego las imgenes no contienen texto, por lo que no son necesarias editarlas en unatraduccin. Sin embargo, son uno de los recursos a editar para realizar un mod. Es por ello que se hapodido ver cmo las imgenes del archivo poketool/pokegra/pokegra.narc, que contiene seis spritespor Pokmon usados durante las batalla, estn cifradas. El cifrado se realiz sobre los datos de laimagen, manteniendo las cabeceras del formato.

    Aplicando la metodologa descrita en la Seccin 4.2.3 se pudo encontrar el algoritmo. Usando bloquesde datos con tamao fijo de 0x1900 bytes, aplicar la operacin XOR sobre valores de 16 bits comenzandopor el final. La clave es de 32 bits y se actualiza despus de usarse. Se inicializa con el primer valor cifrado,ltimos dos bytes del fichero, e ir cambiando segn clave = (uint)(clave * 0x41C64E6D + 0x6073).

    Conclusin

    Puntos fuertes Puntos dbiles

    Los textos usando una codificacinno estndar.Los textos estn cifrados con unaclave dinmica.Las imgenes estn cifradas con unclave dinmica.

    Los archivos y carpetas tienen nombres des-criptivos.Hay un fallo de seguridad en el cifrado de latabla de contenido de los textos por el que sepuede averiguar la clave.Las imgenes usan codificaciones estndar porlo que el software existen de procesamiento sepuede utilizar una vez descifrado el fichero.

    5.1.2. Pokmon HeartGold y SoulSilver

    Los juegos Pokmon HeartGold y SoulSilver son una remasterizacin para Nintendo DS de la segundageneracin, originalmente para GameBoy Advance. Se lanz primero en Japn en septiembre de 2009y en Estados Unidos y Europa seis meses despus. No hubo mucha diferencia entre los lanzamientosde Estados Unidos y Europa, por lo que no se realizaron traducciones no oficiales desde el ingls, solodesde el japons que lleg a completarse al 90%6.

    6En el siguiente hilo se llev a cabo el proyecto: http://projectpokemon.org/forums/showthread.php?4534-Pokemon-HeartGold-and-SoulSilver-Translation-Patch

  • 5.1. SAGA POKMON EN NINTENDO DS 29

    Figura 5.2: Carpetas y ficheros ofuscados en Pokmon HeartGold.

    Archivos

    La primera gran diferencia en estos nuevos juegos lleg con el ofuscado de nombres de archivos ydirectorios. Como se observa en la Figura 5.2, todos los archivos principales del juego estn nombradoscon nmeros, al igual que las carpetas que los contienen. Adems, el contenido de estas carpetas norelaciona a los archivos entre s generando una organizacin aleatoria. En total hay 275 archivos que,a su vez, son contenedores de 1000 ficheros sin nombre pero relacionados en contenido, como son lostextos o sprites de los Pokmons.

    Analizando el cdigo en ensamblador se pudo encontrar la forma interna en la que se accede aestos ficheros. Se realiza llamando a varias funciones de similares, el primer parmetro es un ID queidentifica al archivo y el segundo el ndice del fichero dentro del contenedor. Este ID es lineal y si sedescompone en base diez se puede calcular la ruta absoluta. De esta forma, el ID 0x1B (27) correspondea 27 = 0*100 + 2*10 + 7*1, lo que significa que estara ubicado en a/0/2/7. A la hora de implementareste mecanismo durante el desarrollo del videojuego se podra haber usado un archivo de cabecerasimilar al siguiente:

    file_paths.h#define MESSAGE_FILE_ID 0x1B#define POKEMON_IMAGES_FILE_ID 0x1C

    donde cada constante corresponde a un fichero, facilitando el desarrollo pero ofuscando el producto final.Para poder editarlos, habra que investigar archivos, sin nombres, binarios y sin estructuras de datosconocidas, mediante depuracin de cdigo, sin contar con pistas como pasaba en la edicin anteriordonde el nombre era descriptivo del contenido.

  • 30 CAPTULO 5. TRADUCCIONES NO OFICIALES

    Textos

    Tras realizar una bsqueda del algoritmo, que se aplica en los textos (Seccin 4.2.2), se pudocomprobar que estn cifrados. Adems, tanto el formato del archivo, el algoritmo de cifrado y las clavesson las mismas a las descritas en los juegos anteriores (apartado textos de la Seccin 5.1.1). El formatode las fuentes es tambin el mismo.

    A pesar de que el cifrado no cambi y que los mismos programas de edicin se podan usar, se ofusceste archivo pasando a estar en a/0/2/7.

    Imgenes

    Al igual que sucedi con los textos, tras encontrar el algoritmo de cifrado de imgenes (Seccin 4.2.3),se descubri que se utiliza el mismo algoritmo de cifrado con las mismas claves. Solo existe una diferenciade implementacin, ya que el descifrado empieza por el comienzo del fichero en lugar de por el final.

    Conclusin

    Puntos fuertes Puntos dbiles

    Los nombres de los archivos y direc-torios estn ofuscados.

    No todos los archivos estn ofuscados como seve en la Figura 5.3.Se mantiene los mismos algoritmos y clavesque en la generacin anterior por lo que, unavez encontrado los archivos, se pueden reutili-zar las mismas herramientas de edicin.

    5.1.3. Pokmon Blanco y Negro

    La quinta generacin corresponde a los juegos Pokmon Blanco y Negro para Nintendo DS. Salieronen Japn en septiembre de 2010 y en marzo de 2011 en Estados Unidos y Europa. Hubo un proyecto detraduccin desde el japons al ingls7 que lleg a estar casi completado.

    Archivos

    Los archivos y carpetas fueron ofuscados al igual que pas con la generacin anterior. En este caso,se protegieron todos los archivos en lugar de los principales como se ve en la Figura 5.3. Los nicosarchivos que se dejaron fuera fueron el de sonido y la demo.

    A pesar de usar internamente la misma forma de acceso que se describi en el apartado de archivosde la Seccin 5.1.2, los identificadores, y por tanto localizacin de estos, cambi. Por ejemplo, el archivocon los textos pasa a estar en a/0/0/2 en lugar de a/0/2/7.

    Textos

    En los dos apartados anteriores (5.1.1 y 5.1.2), se describi cmo los textos usaban el mismo algoritmoy clave para cifrarse. Una vez encontrado el algoritmo de esta generacin (Seccin 4.2.2), se pudo verque se trata de un cifrado XOR con clave dinmica pero cambia respecto a las pasadas ediciones.

    7En el siguiente foro se puede encontrar el desarrollo del proyecto: http://projectpokemon.org/forums/showthread.php?11397-Pokemon-Black-and-White-Translation-Project

  • 5.1. SAGA POKMON EN NINTENDO DS 31

    Figura 5.3: Comparacin de carpetas entre Pokmon Blanco (izq.) y Pokmon HeartGold (der.).

    Tabla 5.3: Especificacin del formato de texto en Pokmon Blanco.

    Posicin Tamao Descripcin

    Cabecera0x00 0x02 Constante: 0x010x02 0x02 Nmero de bloques de texto0x04 0x04 Tamao de la seccin de datos0x08 0x04 Constante: 0x000x0C 0x04 Tamao de la cabecera

    Datos0x00 0x04 Tamao de la seccin0x04 0x04 Posicin relativa a la seccina

    0x06 0x02 Nmero de caracteresab

    0x08 0x02 Desconocidoa

    Textoca Se especifica solo la primera entrada.b Cada carcter es un valor de 16 bits.c Campo cifrado descrito en la Seccin 5.1.3.

    Una de las principales diferencias es que no se usa una codificacin propia, que dificulta la investigacin,si no que se usa el estndar UTF-16. La clave inicial se genera segn clave = (i + 3) * 0x2983,donde i es el nmero de bloque al que se quiere acceder. A continuacin se aplica la operacin XOR sobreun carcter (un valor de 16 bits ya que se usa UTF-16) y se actualiza la clave. Para ello, se mueven lostres bits ms significativos a la posicin menos significativa:

    temp = clave & 0x1FFF; // Elimina los bits ms significativosclave = (temp > 13) // y los aade al principio.

    Al desplazarse un nmero impar de veces, cada bit pasar sobre cada posicin de la clave una vez,obtenindose el mximo de permutaciones. En una clave de 16 bits, esta ser de 16.

    La estructura de datos se especifica en la Tabla 5.3, donde se puede ver que la seccin con la tablade contenido no est cifrada a diferencia de cmo pasaba en ediciones anteriores.

    Imgenes

    Las imgenes, a diferencia de las pasadas ediciones, no se han cifrado. En cambio, no se utiliza unformato estndar de codificacin excepto para las paletas. Existe un conjunto de ficheros adicionalescon nuevos formatos con la informacin necesaria para recomponer la imagen (Figura 5.4).

  • 32 CAPTULO 5. TRADUCCIONES NO OFICIALES

    Figura 5.4: Imgenes sin cifrar en Pokmon Blanco.

    El cambio de formato es ms eficaz como mtodo de proteccin para prevenir modificaciones. Aunquepodra ser que el nico motivo fuera tcnico (representar animaciones), usando un nuevo formatohace que los programas de procesado de imagen existentes no se puedan usar. Esta tarea requierede investigacin de formatos y de programacin, se requiere ms esfuerzo y tiempo que crear undecodificador.

    Conclusin

    Puntos fuertes Puntos dbiles

    Los nombres de las carpetas y archi-vos estn ofuscados.Los textos estn cifrados con un nue-vo algoritmo y clave.Las imgenes usan archivos extrascon especificaciones nuevas para re-componerlas por lo que software deprocesamiento nuevo sera necesa-rio.

    Los textos no usan una codificacin propia.Las imgenes no est cifradas.

    5.1.4. Pokmon Conquest

    Pokmon Conquest es un juego desarrollado