Reverse Engineering A PokeWalker

The PokeWalker is part of Nintendo’s long quest to get children (and likely some adults) walking and exercising. There’s the PokeWalker, Pokemon Pikachu, PokeBall Plus, Pokemon Pikachu 2, Pokemon mini, and of course Pokemon Go. Despite being out a decade, there wasn’t a ROM dump for the device and there was minimal documentation on the communication protocol. [Dmitry Grinberg] took it upon himself to change all that and crack the PokeWalker open.

At its heart, the PokeWalker is just a pedometer with an IR port and a 96×64 grayscale screen. It came out in 2009 to accompany the new Pokemon release for the Nintendo DS. Cracking open the device revealed a 64KB EEPROM, a Renesas H8/38606R CPU, a Bosch BMA150 accelerometer, and a generic IR transceiver. The CPU is particularly interesting as in addition to being quite rare, it has a mix of 8, 16, and 32 bits with 24-bit pointers. This gives it a 64K address space. While the CPU is programmable, any attempt to do so erases the onboard flash. The communication protocol packets have an 8-bit header that precedes each packet. The header has a checksum, a command byte, and four bytes of session id, and an unused byte. Curiously enough, every byte is XOR’d with 0xAA before being broadcast.

One command is an EEPROM write, which uses back-referencing compression. Each chunk of data to be written is packaged into 128-byte chunks, though 128 bytes likely won’t be sent thanks to the compression. The command can theoretically reference 4k bytes back, but in practice, it can only reference 256 bytes back. It was this command that laid the foundation for the exploit. By carefully crafting the command to send, the command can overflow the decompression buffer and into executable code. Only a few bytes can be overflowed so the payload needs to be carefully crafted. This allowed for an exploit that reads the system ROM and broadcasts it out the IR port. Only 22k bytes can be dumped before the watchdog reboots the device. By changing the starting address, it was easy to do multiple passes.

After the ROM was stitched together from the different passes, the different IR commands were analyzed. In particular, a command was found that allows direct writes into RAM. This makes for a much easier exploit as you can write your exploit, then override a pointer in the event table, then have the exploit revert the event table once the system naturally jumps to your exploit.

[Dmitry] finishes off this amazing exploit by writing a PalmOS app to dump the ROM from a PokeWalker as well as modify the system state. PalmOS was chosen as it is an easy and cheap way to have a programmable IR transciever. All in all, a gorgeous hack with a meticulous writeup. This isn’t the first video game accessory that’s been reverse engineered with a scrupulous writeup, and we’re sure it won’t be the last.

Thanks to [schme16] for sending this one in!

[Featured Image: legandarypkmn.net and Arty2]

13 thoughts on “Reverse Engineering A PokeWalker

    1. Thought you were through doing PalmOS stuff. :) WPA2 software for Palm OS 5 would still be a useful thing. I’d have a use for my old Tungsten E2 and LifeDrive if they could hook up to WiFi with WPA2.

      I’ve heard there was some ‘executive’ or somesuch software option package for the T|X that included WPA2 support but I’ve not been able to find a copy anywhere to try it on the E2 and LD.

      Something that might be up one of your alleys is figuring out how a one-trip temperature logger gets reset. I have three that have been used, and one that hasn’t been, so that would provide a “virgin” state to find how to revert to. They have a female DE9 RS232 port on the back and the official software to program and read them is a free download.

      They’re made for shipping with frozen foods (they’ll also work for hot stuff, up to higher than is human friendly), programmed with how often they read temperature, company data, high and low alarm temp etc.

      They’re supposed to be returned to the manufacturer for “disposal” but I’d bet they really have a secret way to wipe/reset them and if the case is damaged swap the internals to a new case. There’s also a really thick, easily removable coin cell. The company makes resettable ones that look just like these, minus a reset button on the control pad. IIRC there’s a spot for a reset switch and simply carefully shorting those contacts did nothing.

      What I want one for is to log temps in a dehydrator. Just one, don’t need all four. I want to see what peak temp it really achieves and how long it takes to get there.

      They’d be great for logging indoor or outdoor temps through a day or night, as a monitor to see how much a refrigerator heats up when the door is opened and how long it takes to cool back down, so many uses.

  1. Awesome work!

    ‘The data sent back and forth often had a lot of 0x55 and 0xAA bytes. Generally, you’d expect 0x00 and 0xFF more. Repetition suggests that a simple XOR operation is being used. After some analysis, I concluded that every byte sent was simply being XORed with 0xAA before being sent.’

    My guess would be that this serves as a very simple data whitenening. All those 0x55 and 0xAA’s would be 0x00 and 0xFF’s, and could cause the receiver to lose sync. There’s other ways to fix this (manchester encoding, for instance), but I guess this worked well enough.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.