Reverse Engineering ME2's USB with a Heat Gun and a Knife

In 2024, bjiru uploaded a video about the ME2 handheld device, a toy produced around 2008 that featured the ability to use USB to synchronize points and gems between your device and an online world. The game was extremely niche, so no software, drivers, or assets had been archived, at least until bjiru came forward with the online game client.

I am the leader of Miuchiz Reborn, an effort that started in 2015 to preserve, reverse engineer, emulate, and maintain the accessibility of a game similar to this one, with an online portion and a handheld portion connected via USB. Due to the similar vintage and type of game, the ME2 had already been brought to my attention by my Miuchiz community in 2018, since they thought (mistakenly) that they might share architectural similarities. Despite me being aware of the device's existence for years, bjiru's video finally prompted me to begin research on it.

My initial efforts were spent solely on recreating the server required to make bjiru's copy of the computer game functional again, but along the way, my attention inevitably drifted to the handheld. A recreation of the online game surely could never be complete without the mechanism to synchronize your points to and from the device. This communication between your computer and the ME2 device was the game's main gimmick, after all. I figured that my prior experience with the Miuchiz handheld devices would help me make short work of untangling whatever communication ritual they expect... as long as I could get some code to reverse engineer.

My curiosity demanded the sacrifice of ME2s. EBay demanded the sacrifice of fiat money. Before long, these specimens lay before me.

These are small units with only a couple of buttons and a female mini-USB port. There's a cable included in the box, but it's lacking any disk for software and drivers. That USB port would be the way to synchronize points between your computer and the handheld, but when I embarked on the same journey for the Miuchiz handheld device, I attained full access to its flash memory by reverse engineering how its accompanying Windows software worked. With no such software for the ME2, there is nothing to reverse engineer to figure out how to communicate with the device. Even after checking the Wayback Machine and bjiru, there were apparently no surviving copies of whatever software used to talk to these things. I think it was called ME2 Desktop Buddy, but that application was separate from the game client that bjiru recovered. The handheld does expose itself as a removable storage device, but the contents just direct you online to download the ME2 game, which is no longer available.

The way forward is clear, since there's only one option left: open the hardware.

The main ME2 firmware is stored on an SST39VF3201, a 2 megaword (4 megabytes, with 16-bit addressable units) flash chip. The main microcontroller is... under a hard epoxy glob-top. This is known as a chip-on-board (CoB) and is usually a cost-saving measure, but it has the side effect of hiding any identifying information about the integrated circuit inside. A regularly packaged chip will usually have markings that identify it, just like the flash chip does. Since microcontrollers used in devices like these often contain an internal ROM, it's possible that parts or all of the USB code that I wanted to reverse engineer were in that ROM. Having that code in ROM has the benefit of allowing recovery of a bricked device or, if the manufacturer chooses to do so, flashing the device after assembly. That ROM would exist inside a chip which I had no way of identifying.

Retrieving the data from the flash chip is a straightforward and well-documented process: desolder the chip, put it into an off-the-shelf flash programmer like those by XGecu, and use it to dump the contents. If I need information off the microcontroller's ROM as well, then that is less straightforward, but it's still doable for a device like this where protection is unlikely. In the past, I added code to the SPI flash on a Tamagotchi Pix that would copy its boot ROM to free space on the flash chip, which could then be read by the same flash programmer that I used to inject the code. However, in that case, the microcontroller was properly packaged and had model information printed on it, so I could find its datasheet to know what instruction set it used and where its ROM was in the memory space. At this point, I had none of that information for the ME2's mysterious chip-on-board.

Despite uncertainties, the only apparent way forward from here is to desolder the flash chip. I had also purchased some sockets for the flash chip in hopes that I'd be able to solder one to the handheld's PCB. This would allow me to reprogram the ME2 and quickly iterate if I needed to write code for it to dump the internal ROM from the microcontroller.

Unfortunately, I was unable to get the flash chip off with a soldering iron without damaging the chip. To resolve this skill issue after multiple failed attempts, I instead purchased a rework station (effectively a heat gun that claims to be able to reach 500 °C) and removed the chip by melting the solder with hot air. This allowed me to dump the contents of the flash with no issue, but it revealed that actually using the sockets I had purchased was going to be beyond my capabilities. Not only would I have to solder all 48 tiny pins onto the PCB, I would also have to do it quickly enough to avoid melting the plastic on the sockets. I had neither the tools nor the skill to deal with that, so if I needed the ROM, I'd need another strategy.

The dump looked good, though, and using a tool I had already built specifically for finding uncompressed bitmaps in firmware dumps, I could find images that would ordinarily be displayed on the device.

I've obtained a dump of the firmware from the flash chip, but before serious reverse engineering can be done, I at least need to know what instruction set the device runs. There were no markings on the hardware itself, so it'd have to be guessed. I tried analyzing the code in Ghidra, an open source disassembler, decompiler, and janky nightmare that keeps me employed, with just about every type of processor spec it came with. Any ARM variant? Some 6502 descendant? MIPS? Literally anything else supported by Ghidra? All a resounding "no."

I tried everything, and nothing would disassemble this code. I knew it was code, because I could even find parts of the code I was looking for!

Because of my past work on the Miuchiz handheld device, I had some familiarity with how USB mass storage devices worked. I identified this snippet to be almost certainly moving 'U', 'S', 'B', 'S' somewhere, which is a signature specifically for the kind of USB mass storage communication that I was looking for. Some or all of the USB code that I needed to reverse engineer to figure out how to interact with this device was definitely in this flash dump, but with no clue as to what instruction set it was written in, I couldn't disassemble it.

At this point, I had a couple of broken ME2 units. It seems stupid, but perhaps there are markings somewhere under the epoxy blobs? Probably not, but for the research phase, sometimes a completely decimated unit is more valuable than one that is simply broken.

Well, I had a heat gun, and I had a knife. As they say, when you have a heat gun and a knife, everything looks like... a nail? I think that's how the saying goes.

Setting the rework station to its maximum temperature and prying with a knife liberated the entire epoxy blob. Its departure revealed no markings underneath the chip-on-board-now-off-board. You can see the underside of the microcontroller's silicon die, though, and the epoxy has a couple of air bubbles through which you can see bond wires.

As I said, sometimes a decimated unit is worth more than a broken unit, and I had a heat gun, a knife, and a dire need to brush up on my idioms.

Oh.