I dumped the EEPROM of the Tamagotchi Friends and altered it to see if it could be used achieve code execution on the device. The Tamagotchi Friends’ processing of EEPROM data is much more robust than the processing on the TamaTown Tama-Go, and did not contain any obvious vulnerabilities.
Since I wasn’t able to freeze or find any other interesting bugs in the Tamagotchi Friends using its NFC, the EEPROM seemed like a logical next place to look for paths to code execution or a code dump. I’ve looked at this before, and not found any problems, but I thought it was worth a second look now that I’ve dumped the Tama-Go’s code. Since it’s a lot rarer for an EEPROM to get corrupted compared to radio signals, I was hoping that EEPROM data might not be as well verified.
I started by going through the Tama-Go’s EEPROM processing code, hoping to find a vulnerability that translated over to the Tamagotchi Friends. I also used Asterick’s excellent Tama-Go simulator to test out suspected bad values. While I did get some rather interesting results, nothing appeared to cause freezing or exploitable memory corruption.
For good measure, I also searched the code for every location the state or substate changes, and every location where the “jump into jump table” function is called. None of these used unverified data from the EEPROM to determine where to jump.
I did manage to work out the functionality of most EEPROM data though, as shown below. Note that the address is the address the EEPROM is copied to in Tama-Go ROM, not the actual EEPROM address.
|Time (hour, minute)
|Name as entered on startup
|Height in pixels
|Age in hexadecimal
|Generation in hexadecimal
|Flag (in order) for gender, sick, packing bag, is family, dead, sick family, happy family, happy family
|No obvious impact, the final bit is whether the tama is an olditchi child
|Gender bit used for initial display
|This is the balancing factor for the toddlers
This didn’t make it seem very promising that I would be able to get code using the Tamagotchi Friends’ EEPROM, but it was worth a shot. I attached very tiny wires to the EEPROM, and dumped it using the Arduino Wire library.
Something nice I discovered about the Tamagotchi Friends is that it runs well at 5V, which means you can run it off an Arduino (unlike the Tama-Go, which got really hot and stopped working when I tried this).
Dumping the EEPROM, it was very similar to the Tama-Go EEPROM (full dump here). One thing that surprised me though, was that it was more robust in some ways. While the Tama-Go allowed for invalid sprite codes, which showed up as the generic ‘cactus’ character, the Tamagotchi Friends would just wipe the EEPROM. Similarly, if I set the sprite of the character’s baby to be a sprite that wasn’t a baby, it wouldn’t show up.
I also played around with the persistent NFC and ‘SMS’ data, but once again it was very sensitive to invalidity.
It’s interesting that EEPROM validation has improved between versions. It’s possible that this is because EEPROM corruption is a very catastrophic error– if it’s not detected and causes a problem, there’s nothing the user can do except manually reset the EEPROM, which they might not figure out how to do. It did say how to do this in the Tama-Go instructions, mentioning that the user should try it if they are getting multiple crashes or freezing, so perhaps this was a problem. It’s also possible they learned from my last hacks, but, nah, probably not.
So sadly, I still don’t have a code dump of the Tamagotchi Friends. Options at this point are:
– Keep looking at the EEPROM and NFC. There still could be a vulnerability I haven’t found yet
– Use the GeneralPlus test program to dump the code (this would require gaining access to 9 pins on the die that aren’t currently bonded)
– Decap and optically read the 32K mask ROM
– Look at the functionality of the four jumper pads on the board. According to the schematic , they are attached to IO ports, so it is possibly that they contain test functionality that could be used to execute or dump code. This is a very long shot though.