Hip hip hooray!!

I mentioned in an earlier post that I saw some ‘freezing’ behaviour in the figure game functionality. Game logic is controlled in its entirety by a single bit ‘game code’, which I suspected was the index of a jump table containing all Tamagotchi functionality, and invalid game codes, especially those in the middle of the 0-255 range cause the Tamagotchi to freeze, requiring reset.

Looking into how 6502 (the Tamagotchi microcontroller architecture) works, I thought this might be a sign that the microcontroller was veering off into unexpected code.  Memory in 6502 is mapped into a single address space, and there’s no MMU or other memory protection. If unmapped memory is accessed, it returns 0 or some other garbage value. Invalid instructions do not cause a reset, but execute undefined behaviour taking a non-deterministic amount of time. This meant that freezing was unlikely to be due to an error being detected by the microcontroller (of course, it was possible that an error was being detected by the code on the microcontroller, and it handled the error by going into a tight loop, but this struck me as unlikely, as the Tamagotchi tends to handle detected errors by resetting). It also meant that exploiting a bug in 6502 should be reasonably forgiving,  as  if the PC ends up somewhere before the intended address, it will likely execute any garbage instructions in sequence, and end up at the right address anyhow.

My first thought was that maybe the invalid “game codes” corresponded to indexes outside of the jump table, so the microcontroller was jumping to addresses that were actually other data. Since LCD RAM is the only memory that can be controlled by a figure, I was hoping that maybe one of these values would cause a jump into LCD RAM. So   I filled up my LCD with a NOP slide and shell code and hoped.

Shellcode works better when an annoying Tamagotchi doesn’t stand in front of it

I tried all 255 indexes, but none of them worked. I did notice two interesting things, though. First, the indexes in the middle of the range weren’t all invalid. Some of them showed valid screens, although these screens didn’t always work. This meant that I probably wasn’t jumping to an unintended address, but something else was happening to cause freezing, such as the stack wasn’t set up correctly for the jump. Secondly, the index 0xCC had some interesting behaviour. If bit 3 of the 68th byte in the LCD RAM was set, it played a repeated beeping, and would detect when the figure was removed, and return to the main screen. If this bit wasn’t set, it would play no sound, and freeze. Based on the sound, I guessed that this was the location the Tamagotchi jumps to when playing a sound when a key is pressed. So the logic would be “check if sound is enabled (probably based on an address on the stack), and if set play the sound and return to the address on the stack otherwise return to  a different address on the stack”. Except the stack was messed up, so it was checking the LCD RAM for the bit, and returning to the address where it started instead of the correct address.

I found this perplexing. Considering that this behavior confirmed that pointers to the LCD RAM were being put on the stack before the jump, I found it surprising that none of the  255 possibilities were causing code execution. Eventually, I suspected my shellcode might be wrong. Since I have no sample microcontroller to test code on, and don’t know the locations of the ports, I thought this was likely. My original code was supposed to flash the IR LED, but I moved to the less ambition jumping to reset (since practically nothing will reset a 6502 microcontroller, this would be a good indicator of code execution). I also checked my code with the SunPlus compiler. And found I was using entirely the wrong instruction set. With the right instruction to byte value mapping, the Tamagotchi reset on the third “game code” I tried, 0xd4.

Playing with different instructions, I found the code execution was very unreliable, especially when calling longer instructions like stores and loads. Eventually, I figured out that the Tamagotchi LCD does not use one contiguous piece of LCD RAM, but uses at least two separate pieces. Jumping to one of these locations immediately after starting execution made it much more reliable.

Below is an example of changing the LCD using stores and loads. The area circled in blue is the first code that gets executed, and the area circled in green is the code in the contiguous memory it jumps to. The white boxes (circled in red) are the contiguous pieces of memory, set to be white using STA. The entire row is part of the memory, but I only set one byte (four pixels) per row.

Yes, I’m aware this is the lamest POC ever

For people trying this at home, the LCD RAM locations so far are:

Rows 1-7: 0x10cc-0×1107

Rows 8-18: 0×1120-0x117C

Row 17: 0x10B4-0x10CB

Row 18-31: ???

Next step: chain this together to dump the code!

Tamagotchi Sound

As I mentioned in my previous post, figure ‘items’ are implemented using byte code with six byte instructions. One particular instruction, starting with 0xFEFF controls sound.

The first two bytes of the instruction are always the same, and are likely used to identify it, while the last three bytes are always zero (I checked all the figure dumps I have so far to check this). This leaves one byte to identify the sound. I tried changing this value, and found that it cause the Tamagotchi to play different complete sounds. For example, one value caused the Tamagotchi to beep once, while another code caused it to play “Yankee Doodle” in it’s entirety. Values 0-0×30(ish) played sounds that the Tamagotchi normally plays while running, such as the reset noise and the call noise. Values 0×30-0×52 played a wealth of public-domain music, ranging from “Fur-Elise” to “La Cucaracha” to “The Turkey in the Straw”. After that, codes 0×53-0x5f played a C-major scale. These are all the notes that are available for custom sound.

This is problematic in two ways. First, there are no sharps or flats, so a Tamagotchi figure can only play music that is playable on a major scale. This means that Tamagotchis are unable to dance to many popular tunes, including “Gangnam Style” and “The Macarena”. This isn’t a hardware limitation, as these notes are used in some of the complete songs the figure can play, but the functionality hasn’t been built into the figure.

The other difficulty is timing. The sound instruction does not contain any timing information. Instead, sound timing relies on the delays in image instructions. A sound instruction will not play until the delay in the pre-ceding image instruction is complete, and it will play until the next sound instruction is encountered (there may be several image delays in the mean time). If the sound is not yet complete, it will be interrupted, and not finish playing. There is no other way to change the timing of the sound.

This also means that there is no way to ‘hold’ notes. I tried doing this by repeating notes with a very short delay, but there was no delay that would make the notes play cleanly without “buzzing” due to short breaks in the note. The sound is still reasonable, though. To decrease the delay, and get even better (but not perfect sound), I had the Tamagotchi load a one pixel image during delays, which reduced the inherent delay due to image loading, and the larger image was still visible, except in the one pixel.

This allowed me to create a music video starring my Tamagotchi, albeit one with limited notes and sound quality. A helpful member of pmdev suggested I do “Mad World”, as it can be played with only the notes available.

This song perfectly sums up the angst of being unable to dance “Gangnam Style”. All the more motivation to get code execution!

I took my Tamagotchi to see the statue of Lincoln. What did you do for your Tamagotchi today?

 Fortunately, the second wave of Tamagotchi figures contain flash, instead of mask ROM, so I was able to program a figure directly.

Ignore the wire, these can be reprogrammed without modification

I attached wires to a Tamagotchi case, and used my Arduino to reprogram the flash.

This made testing the figure ROM format much easier, as the flash was much less finicky than my flash-simulation rig, and I could use the figure on any Tamagotchi, not just one with the lines broken out.

After _much_ testing, I figured out that items are implemented using an interpreted byte code. Each ‘instruction’ is 6 bytes long. The format is as follows:

This isn’t comprehensive, there are still a few functions I am not sure how to do. For example, some items will give the Tamagotchi points or make them less hungry. There are likely different types for these. That said, this info was enough to make my Tamagotchi do the Harlem Shake:

The audio on the video is a bit off, though, and this is due to limitations on the audio capabilities of the bytecode format (but not that Tamagotchi hardware). I’ll explore this further in a future post.

No one say ‘cross talk’ and maybe it won’t happen

I started by looking at the game functionality.  It turns out that the functionality is fairly simple, and a very limited amount of the game logic is controlled by data fetched from the figure. The majority of data is images. Near the beginning of the ROM is a pointer table which contains the locations of images used by games, shops, items and other figure functionality. The location of this table is in turn controlled by another pointer at the head of the ROM. The Tama-Go fetches images by first fetching an image pointer from the table, and then fetching the image.

When “GAME” is selected, the Tama-Go starts fetching the needed images from the figure as they are displayed. Interestingly, they are fetched exactly when they are show, and are fetched multiple times if they are displayed multiple times. This suggests that the Tama-Go does not store the images fetched from the figure, but writes them directly to the LCD.

Only two pieces of data appear to affect the logic behavior of the game. The first are the “commands” at  addresses 0×18 and 0×19 (note I’m using a Mametchi figure, this might differ for other figures). These appear to control what game logic the Tama-Go executes when the specific game is selected. It turns out that if these are altered, the Tama-Go can not only jump into different games, but any screen on the Tamagotchi, such as the meal screen, going to the park or taking a bath. If the back button (C) is pressed on any of these screens, the Tama-Go jumps back to the screen it would normally go back to after the current screen, not the figure screen. This suggests that essentially the Tamagotchi acts as a large switch statement or jump table, with no memory of where it has previously jumped to.

I went through some of the possible command values, and found that many of them caused the Tamagotchi to freeze up and require a reset. This is likely because the commands do not exist, or the device is not in the right state for them to work correctly. It might be possible to exploit one of these invalid commands to dump the code of the Tamagotchi, although the lack of debugging information would make it difficult.

Of course, these commands can be used to ‘cheat’ at Tamagotchi. The video below shows this functionality used to ‘evolve’ the Tamagotchi (make it get older).

There is also a series of bytes that gets read at the very end of the game. This seems to be related to how many points the Tamagotchi is awarded for playing the game. The Tama-Go appears to read more data the higher the game score is, so my guess is it’s some sort of cumulative algorithm for calculating the points awarded from the game score. Randomly tampering with these values caused my Tamagotchi to be awarded an extremely large number of points (which was useful in testing item functionality), but I’m still not clear how the values translate to points exactly.

83009250 points has got to be enough for any Tamagotchi

Next, I looked at the shop functionality of the figure. This was also quite simple. The entire store functionality appears to be in the Tama-Go’s internal ROM, and it just fetched the images. The only interesting value was the item price, which can be altered in the ROM. This would probably be more useful had I not just given my Tamagotchi infinite points.

Lastly, I tried using an item, and this was quite interesting. The Tama-Go fetches one byte of non-image data from the figure, from inside the expected segment before using an item, and then fetches more than 200 bytes of non-image data from near the end of the ROM (not the segment, the entire ROM) while the item is being used. This is so bizzare, I tested it several times to make sure it was actually what was happening, and I’m confident that it is.

What I suspect is happening is that the first byte is a command similar to the game commands, jumping to code that relies on both image data and other data from the figure, which it then fetches. I’m not sure what this “other data” is. It could be the location of the images on the screen, it could be audio data (items make sounds) or it could be some type of metadata related to the behavior of the item (for example, whether it gives points, or the probability of behaving a certain way for items that don’t do the same thing every time). As for why this information is at such a strange location, my only guess is that its used by all three characters in the figure, so it can’t be a part of any of their segments. But this is wild speculation.

A complete list of memory addresses I’ve identified is below:

And a list of game codes I’ve tried so far:

Set-up

I originally simulated the ROM from a ChipKit Uno Board. While this sort of worked, I would see signs that the Tamagotchi was getting corrupt data after a few seconds. This made it difficult to ‘test’ the Tamagotchi, as I couldn’t be confident that a test that didn’t work had been received correctly. After looking into several possible causes of the problem that people had suggested, including wires being too long, ‘noise’ in the circuit and bugs in my simulation program, I decided to try rewriting the program for a faster board, hoping that the problem was due to a timing issue (and if it was due to a bug, I wouldn’t make the same mistake twice).

Wires too long? I have no idea how anyone could think such a thing …

I used an STM32F4 Discovery board,  which I had on hand from a giveaway (but’s it’s a pretty awesome board, well worth the ~$15 they’re going for these days). By default, the MCU runs at 8 MHz, but it can be cranked up to 166 MHz, certainly enough to keep up with any Tamagotchi.

After programming the board to simulate the Tamagotchi ROM, I found that it worked for roughly 10 reads, and then would stall. Eventually, I figured out what was different  about the reads that failed.

Do you see it? Do you see it? Do you see it?

It turns out that after running SPI at ~600 kHz for several cycles, the Tamagotchi speeds up to 2.2 MHz. It seems to do this specifically when it is fetching pixels that will be displayed on the screen. This explains the behavior I was seeing with the ChipKit Uno, which has a maximum SPI speed of 2 MHz. Since it could almost keep up, it would take a few seconds before there were obvious errors.

I fixed this by tweaking the PLL settings to speed up the microcontroller on the discovery board (note that this required removing resistor 68 on the back of the board), after which it worked!

It works!

A simulated figure doesn’t always have to return the same value for the same address, so I could make my Tamagotchi display an animation, which a real figure can’t do.

Since I can now test things reliably, I saw what happened when I extended the dimensions of the displayed image. While it does allow displaying images the size of the full screen, it rejects the image before it’s large enough to overflow LCD RAM (boo!).

It does let you do cool things, like displaying a picture of yourself holding a Tamagotchi on a Tamagotchi.

That’s me!

Totally meta!

The end result!

The pictures are etched in paint on plexiglass.

I got a piece of 4mm thick plexiglass, and cut it into squares a bit larger than I wanted the coasters to be using the laser cutter (power 100, speed 5), and then I painted them black. After a previous disaster involving spray paint, I used acrylic crafting paint.

It turns out layers of spray paint dissolve each other

Once the paint was dry, I etched the pictures in using the laser cutter. I started by converting photos to monochrome bitmaps, and importing them into the LaserCut software, but this led to pixelated-looking images.

Too pixelated!

The image in the attempt above is also reversed, because I forgot that when engraving, black areas in the laser-cut software are the ones that get engraved (so turn white).

Agnes suggested smoothing out the pictures using Adobe Illustrator (CS), which improved the engraving substantially. We then imported the smoothed files using Corel, which can convert to the DXF format which is supported by the laser cutter. Afterwards, I figured out that Corel Draw supports similar smoothing features, so the rest of the images were smoothed and exported in Corel only.

I tested engraving these images using the laser settings that had worked with spray paint (speed = 300, power = 20), and it turned out well. The acrylic paint doesn’t seem to be that sensitive to the power setting of the laser. I found that so long as the power was in the right ballpark, the paint from the etched areas would come off when I washed the plexiglass with soap and water. This resulted in very clear etching.

It worked!

I then painted the backs of the coasters to add colour.

Painting!

Before and after

I then used the laser cutter to trim around the edges, removing any paint I had dripped around the edges while painting.

I tried putting corkboard on the back of the coasters, but found that corkboard doesn’t cut well (and smells really bad) in the laser cutter, and it crumbled when I tried to cut it using scissors or a knife.  So I ended up cutting pieces of white acrylic and gluing them to the back with crazy glue.

Hey, it works

And we have coasters!

Now these coasters are ready to use. So if you see a couple that looks anything like the pictures, be sure not to ruin the surprise!

ChipKit Uno 32

This board is fast enough to keep up with the Tama-Go, and uses jumpers for SPI slave mode, so the resistor on pin13 is avoided.

There are still some speed limitations when using this board– having it query external memory or devices, or even do a lot of math to determine the return value for an SPI command is out of the question, but it can return a reasonable number values that are included in code. It’s not possible to simulate the entire Tamagotchi ROM at once this way, as there’s not enough memory, but I hope I can simulate it bit-by-bit in order to determine the format (although I suspect I might run out of memory when doing the game portion).

I started by simulating a figure being attached to the Tamagotchi. When this happens, the Tamagotchi displays an object in the background (for example, a wardrobe that clothes come out of, if it’s a figure that’s a ‘clothing store’, or a table if the figure’s a ‘restaurant’). It also plays a song, and displays a screen with the figure character dancing if this is the first time this particular figure has been attached to the Tamagotchi.

Using the SPI functionality of the ChipKit Uno, I determined what memory address the Tamagotchi queries when a figure is first attached, and then modified the code to return the value at that memory address (which I got from the figure ROM dump I did awhile ago) after the first SPI command. Once this value was correct, the Tamagotchi started to make a second query, so I made the code return the value at that address after the second query, and so on. Unfortunately, a lot of this had to be done manually, although I used Python to generate some of the code.

Currently, I can simulate up to the background image being loaded. Details of the simulation are below

Next up is tampering with these values to see if I can cause any unexpected behavior.

The code for this is available here, and I’ve also uploaded a dissembler for two GeneralPlus instruction sets. You never know when you might need to disassemble a GeneralPlus binary, and it’s best to be prepared for these sort of things .

ROM Dumping

I removed the ROM from a figure, soldered wires to the pads and used the Arduino SPI library to dump the memory. This was a very slow process (the data transfer rate was a few hundred bytes per second running the library at max speed), and voltage dividers were needed to step down the voltage in order not to overload the memory. The first few attempts to dump memory resulted in heavily corrupted dumps, I suspect this was due to the Arduino having trouble reading data close to the input voltage threshold, as running the memory at a voltage closer to its maximum solved the problem.

The ROM dump contained many strings of 0×55, 0xAA and 0xFF. I suspected that these represented strings of identical pixels, as the Tama-Go uses a four-shade greyscale display, so pixels would be represented as two bits, and four identical pixels would be represented as 10101010 (0xAA), 01010101 (0×55), 11111111 (0xff) or 00000000 (0×00). Looking through the binary, I found an instance where a string of 5′s was preceeded by two values which seemed reasonable for width and height, and the string was exactly long enough to provide data for an image with that width and height.

I wrote a script to decode this image, and after a few decoding accidents, extracted an image.

They can't _always_ decode properly ...

Success!

I wrote a longer script to dump all the images on the ROM.  There were about 7000 images, taking up about 60% of the 32MBit ROM.

These images give some interesting insight into how the Tama-Go works internally. For example, outside of user-generated data, text doesn’t appear to be stored as strings. All of the text displayed while using the figure was part of the images dumped.

Text Strings

Also, for every item in the game, there were images of every single Tamagotchi using it, for example, pictures of every Tamagotchi in the dress.

Tamagotchis in dresses

This makes me suspect that Tamagotchi programs aren’t very ‘smart’, and simply display bitmap images on the screen in sequence.

Mask ROM and Unpopulated Board

On the right is an unpopulated board for that Tamagotchi figure, the blue areas are what was visible before I scraped the covering off the traces. Based on the position of the pads and the size of the rectangle for the die, I think it’s a GeneralPlus GPR26LXXX Low Voltage SPI ROM, either the 8MB or the 16MB version.

GeneralPlus MaskROMs

This means that the Tamagotchi figure pins are then as follows:

Tama-Go Pins

1, 4 and 8: Ground/Jumper Power/Jumper (Edited 2013/02/09)

2: Serial clock (C)

3: Serial data input (D)

5: Power Ground (Edited 2013/02/09)

6: Chip Select (SB)

7: Serial Data Output (Q)

I tried to confirm this by removing the PCB from the back of the die and taking a peek at the pads (yes, I realize now that they’re on the top).

Silver glittery stuff everywhere!

It turns out that this is not a recommended technique.

Tama-Go EEPROM

I hoped that the instruction pointer would be cached as a part of the game state. Spoiler Alert: it isn’t.

I soldered short leads to the EEPROM, and used the Arduino Wire library to read the memory using I2C. I found the library very easy to use, and the sample program required almost no modification to access the chip.

The contents of the EEPROM were minimal, and are identifiable as parts of the game state.

 I dumped the EEPROM a few times while playing the game to see the effect. I also tried overwriting the state, and saw the changes in the game.

Unfortunately, this means that the EEPROM stores a ‘game’ type of state and not a ‘stack and registers’ type of state, so probably won’t be useful in dumping the code from the MCU.

So, from here there are a few ways I could try to dump the code (listed in the order I plan on trying them):

1) Dump a figure mask ROM, and hope it contains code, pointers or something that could be tampered with to get code execution on the Tama-Go

2) Play around the the image formats supported over IR and through figures. I think it’s unlikely there’s any vulns in these, but it’s worth a shot.

3) Try harder to get a GeneralPlus eval board or the contents of the test program. Also, there are some SunPlus MCUs with pins and writable flash that contain a test program, maybe get one of those and dump it and hope the programs are similar.

4) Put the mask ROM under a microscope.

5) Learn about the glitching thing everybody’s always talking about.