coremaze/me2-writeupReconstruyendo un protocolo USB muerto: Los secretos de una consola portátil desbloqueados con un cuchillo caliente, un viaje multidisciplinario para revivir una interfaz USB olvidada
En 2024, bjiru subió un video sobre el dispositivo portátil ME2, un juguete producido alrededor de 2008 que contaba con la capacidad de usar USB para sincronizar puntos y gemas entre tu dispositivo y un mundo en línea. El juego era extremadamente nicho, por lo que no se había archivado ningún software, controlador o activo, al menos hasta que bjiru apareció con el cliente del juego en línea.
Soy el líder de Miuchiz Reborn, un esfuerzo que comenzó en 2015 para preservar, aplicar ingeniería inversa, emular y mantener la accesibilidad de un juego similar a este, con una parte en línea y una parte portátil conectadas vía USB. Debido a la antigüedad y tipo de juego similares, el ME2 ya había sido traído a mi atención por mi comunidad de Miuchiz en 2018, ya que pensaban (erróneamente) que podrían compartir similitudes arquitectónicas. A pesar de que conocía la existencia del dispositivo desde hacía años, el video de bjiru finalmente me impulsó a comenzar a investigarlo.
Mis esfuerzos iniciales se dedicaron únicamente a recrear el servidor necesario para que la copia de bjiru del juego de computadora volviera a funcionar, pero en el camino, mi atención inevitablemente se desvió hacia el dispositivo portátil. Una recreación del juego en línea seguramente nunca podría estar completa sin el mecanismo para sincronizar tus puntos hacia y desde el dispositivo. Esta comunicación entre tu computadora y el dispositivo ME2 era el principal atractivo del juego, después de todo. Supuse que mi experiencia previa con los dispositivos portátiles Miuchiz me ayudaría a desenredar rápidamente cualquier ritual de comunicación que esperaran... siempre que pudiera obtener algo de código para aplicar ingeniería inversa.
Mi curiosidad exigió el sacrificio de ME2s. eBay exigió el sacrificio de dinero fiduciario. En poco tiempo, estos especímenes yacían ante mí.
Son unidades pequeñas con solo un par de botones y un puerto mini-USB hembra. Hay un cable incluido en la caja, pero carece de cualquier disco con software y controladores. Ese puerto USB sería la forma de sincronizar puntos entre tu computadora y el dispositivo portátil, pero cuando emprendí el mismo viaje para el dispositivo portátil Miuchiz, obtuve acceso completo a su memoria flash aplicando ingeniería inversa a cómo funcionaba su software de Windows acompañante. Sin tal software para el ME2, no hay nada a lo que aplicar ingeniería inversa para descubrir cómo comunicarse con el dispositivo. Incluso después de verificar Wayback Machine y bjiru, aparentemente no sobrevivieron copias del software que se usaba para hablar con estos dispositivos. Creo que se llamaba ME2 Desktop Buddy, pero esa aplicación era independiente del cliente del juego que bjiru recuperó. El dispositivo portátil se expone a sí mismo como un dispositivo de almacenamiento extraíble, pero el contenido simplemente te dirige en línea para descargar el juego ME2, que ya no está disponible.
El camino a seguir está claro, ya que solo queda una opción: abrir el hardware.
El firmware principal del ME2 está almacenado en un SST39VF3201, un chip flash de 2 megapalabras (4 megabytes, con unidades direccionables de 16 bits). El microcontrolador principal está... bajo una dura capa de epoxy glob-top. Esto se conoce como chip-on-board (CoB) y suele ser una medida de ahorro de costos, pero tiene el efecto secundario de ocultar cualquier información de identificación sobre el circuito integrado interior. Un chip empaquetado normalmente tendrá marcas que lo identifiquen, al igual que el chip flash. Dado que los microcontroladores usados en dispositivos como estos a menudo contienen una ROM interna, es posible que partes o todo el código USB que quería aplicar ingeniería inversa estuviera en esa ROM. Tener ese código en ROM tiene el beneficio de permitir la recuperación de un dispositivo bloqueado o, si el fabricante así lo decide, la programación del dispositivo después del ensamblaje. Esa ROM existiría dentro de un chip que no tenía forma de identificar.
Recuperar los datos del chip flash es un proceso sencillo y bien documentado: desoldar el chip, colocarlo en un programador flash estándar como los de XGecu, y usarlo para volcar el contenido. Si también necesito información de la ROM del microcontrolador, eso es menos sencillo, pero aún es factible para un dispositivo como este donde es poco probable que haya protección. En el pasado, añadí código a la flash SPI de un Tamagotchi Pix que copiaría su ROM de arranque al espacio libre en el chip flash, que luego podía leer el mismo programador flash que usé para inyectar el código. Sin embargo, en ese caso, el microcontrolador estaba empaquetado correctamente y tenía información del modelo impresa, por lo que pude encontrar su hoja de datos para saber qué conjunto de instrucciones usaba y dónde estaba su ROM en el espacio de memoria. En este punto, no tenía ninguna de esa información para el misterioso chip-on-board del ME2.
A pesar de las incertidumbres, el único camino aparente a seguir desde aquí es desoldar el chip flash. También había comprado algunos zócalos para el chip flash con la esperanza de poder soldar uno en el PCB del dispositivo portátil. Esto me permitiría reprogramar el ME2 e iterar rápidamente si necesitaba escribir código para volcar la ROM interna del microcontrolador.
Desafortunadamente, no pude quitar el chip flash con un soldador sin dañar el chip. Para resolver este problema de habilidad después de múltiples intentos fallidos, compré una estación de retrabajo (efectivamente una pistola de calor que afirma poder alcanzar 500 °C) y quité el chip derritiendo la soldadura con aire caliente. Esto me permitió volcar el contenido de la flash sin problemas, pero reveló que realmente usar los zócalos que había comprado iba a estar más allá de mis capacidades. No solo tendría que soldar los 48 pines diminutos al PCB, sino que también tendría que hacerlo lo suficientemente rápido para evitar derretir el plástico de los zócalos. No tenía ni las herramientas ni la habilidad para lidiar con eso, así que si necesitaba la ROM, necesitaría otra estrategia.
El volcado se veía bien, sin embargo, y usando una herramienta que ya había construido específicamente para encontrar mapas de bits sin comprimir en volcados de firmware, pude encontrar imágenes que se mostrarían normalmente en el dispositivo:
He obtenido un volcado del firmware del chip flash, pero antes de que se pueda hacer ingeniería inversa seria, al menos necesito saber qué conjunto de instrucciones ejecuta el dispositivo. No había marcas en el hardware en sí, así que tendría que adivinarse. Intenté analizar el código en Ghidra, un desensamblador, descompilador y pesadilla chapucera de código abierto que me mantiene empleado, con casi todos los tipos de especificaciones de procesador que traía. ¿Alguna variante ARM? ¿Algún descendiente de 6502? ¿MIPS? ¿Literalmente cualquier otra cosa compatible con Ghidra? Todo un rotundo "no".
Lo intenté todo, y nada desensamblaba este código. Sabía que era código, porque ¡incluso podía encontrar partes del código que estaba buscando!
Debido a mi trabajo anterior en el dispositivo portátil Miuchiz, tenía cierta familiaridad con cómo funcionaban los dispositivos de almacenamiento masivo USB. Identifiqué este fragmento como casi con seguridad moviendo 'U', 'S', 'B', 'S' a algún lugar, que es una firma específica para el tipo de comunicación de almacenamiento masivo USB que estaba buscando. Parte o todo el código USB que necesitaba aplicar ingeniería inversa para descubrir cómo interactuar con este dispositivo estaba definitivamente en este volcado de flash, pero sin pista alguna sobre en qué conjunto de instrucciones estaba escrito, no podía desensamblarlo.
En este punto, tenía un par de unidades ME2 rotas. Parece estúpido, pero quizás hay marcas en algún lugar debajo de las gotas de epoxy? Probablemente no, pero para la fase de investigación, a veces una unidad completamente destruida es más valiosa que una que simplemente está rota.
Bueno, tenía una pistola de calor y tenía un cuchillo. Como dicen, cuando tienes una pistola de calor y un cuchillo, todo parece... ¿un clavo? Creo que así es como va el dicho.
Configurando la estación de retrabajo a su temperatura máxima y haciendo palanca con un cuchillo liberó toda la gota de epoxy. Su partida no reveló marcas debajo del chip-on-board-ahora-fuera-del-pcb. Se puede ver la parte inferior del dado de silicio del microcontrolador, sin embargo, y el epoxy tiene un par de burbujas de aire a través de las cuales se pueden ver los cables de unión.
Como dije, a veces una unidad destruida vale más que una unidad rota, y tenía una pistola de calor, un cuchillo y una necesidad imperiosa de repasar mis modismos.
Oh.
Vaya.
No tenía idea de que se pudiera decapsular un CoB de esa manera. Simplemente salió limpio, y dada su temperatura, me alegra que no lo hiciera en mi dirección. Es muy bonito, pero en realidad hay un camino a seguir desde aquí. Déjenme echar un vistazo más de cerca con mi microscopio electrónico.
Bueno, eso es lo que su manual de usuario afirma que es. Para ser justos, lo verifiqué, y contiene al menos un electrón.
Mientras destruía "hackeaba" otros juguetes cuyos componentes pequeños desafiaban mis ojos, se hizo obvio que rara vez sabía lo que estaba sucediendo al otro extremo de mi soldador. Una recomendación muy cortés de un amigo resultó en la compra de un microscopio digital barato, destinado a monedas y soldadura.
A pesar de no ser realmente un equipo adecuado para el trabajo, en contra de las afirmaciones de su manual de usuario, capturé esta imagen con el microscopio. Está muy lejos de poder descifrar cualquier texto en el dado, pero el diseño general está claro, y sabía dónde podía encontrar más imágenes como esta.
Siliconpr0n, ahora conocido como Siliconprawn, tiene un archivo donde muchas personas han subido imágenes de dados, aunque normalmente en mejor calidad que la mía. Desafortunadamente, no hay una forma útil de buscar en el sitio dada la información que tenía, así que comencé a hacer clic, y desplazarme, y repetir...
¡Sus huellas dactilares están en el registro!
Después de varias horas, a las 4 AM, finalmente vi algo familiar. Tiene mejor calidad que la mía, pero el diseño es inconfundible. Tengo un GPL162002A (o B) rotado 180 grados en comparación con la imagen coincidente tomada por John McMaster. Es un microcontrolador GeneralPlus, su hoja de datos está disponible en internet, y su conjunto de instrucciones es μ'nSP.
μ'nSP, resulta, es bastante común para juguetes de este tipo y antigüedad. Espero que se me pueda perdonar no haber adivinado que era un conjunto de instrucciones cuyo nombre contiene caracteres que ni siquiera están en el alfabeto latino. A pesar de eso, sigue siendo lo suficientemente nicho como para no ser compatible con Ghidra de serie. Afortunadamente, hay algunos trabajos de terceros existentes para ello, así que pude comenzar a desensamblarlo en Ghidra, nombrar funciones e importar nombres de registros de la hoja de datos.
Aquí está la función de la que estaba tan seguro que era código USB solo por su volcado hexadecimal, interactuando con registros USB según lo especificado en la hoja de datos del microcontrolador:
Como señalé anteriormente, ya estaba algo familiarizado con cómo se comunican los dispositivos de almacenamiento masivo USB como este, especialmente debido a algún trabajo experimental portando mi biblioteca USB de Miuchiz a macOS usando libusb. Los dispositivos de almacenamiento masivo USB esencialmente tunelizan comandos SCSI, y esos están bien documentados en línea. Por ejemplo, hay comandos para solicitar una lectura o una escritura al dispositivo.
Sin embargo, sabía que, en general, los comandos estándar, como los de lectura o escritura, no me serían útiles. Esos son los que tu computadora ya sabe cómo hacer con sus controladores de almacenamiento masivo incorporados. Los emitirá para interactuar con él como cualquier dispositivo de medios extraíbles ordinario. En este caso, el comando de lectura simplemente recuperará el sistema de archivos que contiene el archivo de ayuda, y el comando de escritura no hará nada, ya que se supone que no es escribible. Estos no son para interactuar con todo el chip flash; en cambio, son efectivamente un pequeño CD-ROM simulado para ayudar a los usuarios primerizos.
Sin embargo, algunos IDs de comando están reservados para lo que el fabricante quiera implementar. Los manejadores para algunos IDs reservados se inyectan de manera tosca antes de que se ejecute la búsqueda normal de IDs.
A través del análisis estático, pude identificar y nombrar las funciones que estaba buscando: leer, programar y borrar flash. Todos estos son comandos no estándar que se implementaron para el ME2 y posiblemente otros dispositivos GeneralPlus, y casi con certeza usados por el software y los controladores que originalmente venían con el dispositivo. Puedes crear un mensaje USB para desencadenar cualquiera de estas rutas. Leer te permite recuperar datos de la flash. Programar te permite "programar" la flash. Borrar te permite restablecer todos los bits en una región de flash a 1, que cuando se usa en combinación con el comando de programación, puede emitir una escritura completa a la flash, ya que "programar" solo puede cambiar bits de 1 a 0. Cada uno de los comandos personalizados que me interesaban usa el ID reservado 0xFF seguido de IDs para subcomandos y cualquier parámetro que la operación necesite.
Las estructuras exactas de los comandos no son particularmente relevantes para el lector, pero la metodología podría serlo. Usé libusb (bueno, en realidad, rusb) para facilitar toda mi interacción a través de USB. Este método te permite escribir código de espacio de usuario para interactuar con tu dispositivo USB, a diferencia de escribir un nuevo controlador.
Cuando el software ME2 de Windows desapareció de internet, fue como si el penúltimo hablante de su idioma muriera. El dispositivo portátil ME2 se convirtió, en cierto sentido, en un hablante terminal. Con un poco de experimentación y un poco de lectura de descompilación a veces correcta, estaba leyendo su mente para aprender las palabras de su idioma casi extinto. Cuando respondió, supe que estaba en el camino correcto.
Č̶̯a̴̩͗n̵͉͆ ̴͍͠Ǐ̶̜ ̴͈͌h̷̙̔á̶͉v̸͈̽é̴̢ ̵͍͛a̵̞͝ ̴̤̉s̵̡͊ē̴̮c̸̭̅t̶̛͖o̸̡͠r̶̺̊ ̶̥̀ǫ̸̀f̸̦́ ̷̈ͅỳ̷͎o̶̦̐u̵͙̚r̶͙͒ ̵̥̕f̸̡͝l̷͈̄a̶͍͋s̸̢̓h̸̗͝?̴̪̕
...¿No? Debe ser mi acento. Déjame ajustar y preguntar de nuevo: ¿Puedo tener un sector de tu flash? ¿Qué tal el siguiente sector? ¿Estás dispuesto a programar alguno de los bits en ese sector? ¿Puedo tener tu flash de nuevo para ver si es diferente ahora? ¿Me atrevo a pedirte que borres un sector... y con suerte entender cuál te estoy pidiendo que destruyas?
Uno por uno, escribí el código para estructurar, llenar y transmitir los mensajes que necesitaba que el ME2 escuchara. Una vez que estuvimos en la misma página, le pedí que me enviara un par de volcados de flash teniendo diferentes cantidades de puntos. Después de compararlos, pude identificar dónde se almacenan los puntos en la flash y finalmente usar mi computadora para modificarlos.
De hecho, podía hacer lo que quisiera con el dispositivo usando estos comandos, siempre que no implicara borrar código que estuviera siendo usado activamente. El ME2 se unió a mi colección de dispositivos que muestran el emblema de Miuchiz Reborn en lugares donde no debería estar, incluido el microscopio digital que tomó la imagen del dado.
Admito que la primera vez que intenté leer/escribir la flash, estaba siendo un poco imprudente, porque no podía ver todo el código que se estaba ejecutando. Por ejemplo, algún código llama a la ROM interna del microcontrolador, o a rutinas en RAM copiadas allí por la ROM. Algunas de mis conjeturas para las otras funciones se basaron en cómo se configuraban los registros de acceso directo a memoria (DMA). Si DMA está configurado para copiar desde el búfer USB, por ejemplo, probablemente está usando esos datos para programar la flash, no para leer de la flash.
Este código, por ejemplo, llama a una función que reside fuera de la flash, para no arrancar código de debajo de sí mismo, antes de regresar al código del que acaba de arrancar de debajo de sí mismo de todos modos. Hay que tener mucho cuidado de no bloquear el dispositivo.
La región de memoria en cuestión está claramente dispuesta en la hoja de datos:
Hay 128 kilopalabras de ROM particularmente "embadded" a las que aún no tenía acceso, lo que me impedía comprender completamente el sistema.
Afortunadamente, la función para el comando personalizado de lectura de flash no realiza verificación de límites. Esto significa que con un mensaje especialmente diseñado que intente una lectura desde una dirección de flash muy alta, puedes envolver todo el espacio de direcciones del microcontrolador, terminando de vuelta al inicio. Debido a que esto equivale a una capacidad de lectura arbitraria, ¡no necesité escribir ningún código de volcado en el dispositivo esta vez! Toda la memoria es legible con este error, así que lo usé para leer la ROM Embadded, que guardé para ingeniería inversa posterior.
Con toda la memoria, pude detectar el framebuffer del dispositivo en RAM, mostrando la imagen que estaba en la pantalla del dispositivo en ese momento:
También pude leer los registros de E/S de propósito general (GPIO) del espacio de direcciones del dispositivo consultando dónde la hoja de datos decía que debían estar. Al desencadenar el error docenas de veces por segundo, podía sondear efectivamente las pulsaciones de botones y convertirlo en un controlador USB si quería: (Video)
En algún momento durante mis pruebas, noté una modificación extraña de un valor en la flash que ni siquiera parecía que se suponía que fueran datos de guardado.
0x00AA (recuerden, el tamaño de palabra de este sistema es de 16 bits) se ha escrito en un lugar de la flash que no solicité. Con la ROM Embadded, finalmente podemos ver el código que explica esto.
Estos chips flash toman comandos escribiendo en offsets específicos. A diferencia de la RAM, que confirma inmediatamente los datos escritos, el chip flash solo intentará interpretar las escrituras como parte de un comando, por lo que una sola escritura en el espacio de direcciones de la flash no es suficiente para cambiar realmente ningún dato. Cuando un fragmento de código quiere programar la flash, emite una secuencia de comandos de varios pasos que comienza escribiendo 0xAA en 0x5555 y termina escribiendo los datos deseados en la dirección deseada.Si un usuario con demasiado tiempo libre (y quizás una pistola de calor y un cuchillo) tiene la idea de intentar sondear cómo funciona el dispositivo, podría terminar solicitando que el dispositivo programe un sector más allá de la capacidad de su chip flash. El procesador es consciente de cada paso, pero el chip flash no. En cambio, ese último ciclo de comando falla completamente en el espacio de direcciones del chip flash, por lo que el flash espera ansiosamente qué valor debe programarse y dónde.
Procesador: ¡Oye flash! ¡Quiero empezar a programar otra palabra!
Flash: ¡Fuerte y claro! ¡Programando 0xAA en 0x5555!
Procesador: ...¿Cómo?
Debido a la desincronización de los ciclos de comando, el flash confunde el primer ciclo del siguiente comando con el último ciclo del comando anterior, y 0xAA se programa en 0x5555. La dirección equivalente para bytes típicos de 8 bits es 0xAAAA, que coincide con donde se escribió 0x00AA en mi volcado de flash.
Esto podría potencialmente usarse para una escritura arbitraria, siempre que se acepte corromper esa palabra específica en el flash, pero el dispositivo ya está suficientemente comprometido como para que no me interese brickear más unidades. Podría ser posible salvar estos dispositivos, ya que la ingeniería inversa de la ROM embebida también mostró que contiene su propio manejador USB e implementaciones de lectura/programación/borrado de flash. Sin embargo, solo he logrado que la ROM entre en ese estado (en lugar de arrancar en el código flash) una vez, y nunca más. Basándome en la descompilación de la ROM, sospecho que podría depender de un puerto GPIO que ha quedado flotando, pero no estoy seguro. En cualquier caso, mi misión aquí ya estaba cumplida.
El resultado final de esta travesura es una utilidad de línea de comandos que puede:
Esto, junto con el código del servidor del juego y otras investigaciones, está disponible en el repositorio ME2-Restoration. Dado que los detalles de implementación están disponibles allí y probablemente no sean de interés para el lector típico, aquí se omitieron detalles técnicos específicos en favor de describir procesos y técnicas.
Más importante aún, esto demuestra que el software original del lado del PC no es estrictamente necesario para comprender o preservar su funcionalidad. Incluso con el software oficial perdido en el tiempo, fue posible abrir la caja negra que era el ME2 y reconstruir su protocolo a partir de su hardware y firmware, restaurando una interfaz que de otro modo estaría muerta a algo utilizable nuevamente. Esto no se limita solo a interfaces como USB. Lee cómo recreé un servidor de licencias muerto hace mucho tiempo para devolverle la vida a un editor vectorial de hace una década.
Esta es también mi primera vez decapsulando un circuito integrado, así que para rendirle el respeto que merece, compré un microscopio mejor y desde entonces he contribuido con la foto de mayor calidad del GPL162002A/B a siliconprawn, vista previa aquí a una resolución reducida para ser más amigable con la web:
