Hacking Tamagotchi Uni Research/Hacking

[Zhongtiao1]

Look Ma! My Welcotchi is a part of the metaverse!​

In case you weren't aware, a new Tamagotchi was released over the weekend, the Tamagotchi Uni. The main difference this time around was the inclusion of wifi. This allows for firmware updates, time-limited items, and to interact with the "tamaverse." While the tamaverse is mostly offline, you're able to interact with other tamas online (marry them off, etc.)

^ This is Rash. He will most likely die because I have a full-time job and he sleeps from 8pm to 8am.

This thread will be to document what I've found (and if anyone wants to join in, they can). The goal (at least at the moment) is to grab any firmware updates/document how the Uni talks with the servers.

What I've found out so far:

• It uses TLS 1.2
• Only 2.4Ghz networks supported
• The first URL it checks is apiuni-tmgc.tyb.jp
• The cloud server is on AWS Northeast-1 in Japan
• The wireless module claims to be made by ESPRESSIF SYSTEMS (SHANGHAI) CO., LTD. so it's an ESP32 MCU
• Doesn't seem to have Bluetooth
• According to the manual, firmware downloads are as large as 9.5mb
• https://apiuni-tmgc.tyb.jp/ jumps to any one of the following IPs (this could of course change with an update):
  • 35.79.59.252
  • 52.199.19.128
  • 35.78.56.100
  • 54.95.78.200
  • 18.182.80.137
  • 52.194.44.193
  • 35.73.234.2
  • 18.181.64.19
• It tries to connect to the server 5 times before giving up

One annoyance is that if you choose "automatic" for the network settings, it's impossible to set the DNS server separately. If you choose manual though, it doesn't allow you to set DHCP for the IP. To get the network dumps so far, I've had to create my own mitm hotspot using wihotspot on Ubuntu. While I've done similar things before, for some reason the Uni gives an error when connecting. Wireshark isn't giving me a whole lot of info as to why though. The server just resets the connection, and then the Uni tries again.

Post automatically merged: Jul 20, 2023

Day 2! (Yes, I know it's the same day, but I did the research for my first post yesterday)

Rash isn't dead surprisingly. However, he's seemed to have de-aged:

He's also getting into social media which I am concerned about...

Thanks to u/siabe on Reddit, I know a lot more about the hardware itself:

• The Wifi Module is an ESP32-S3-WROOM-1
• The SoC is an Xtensa LX7
• 1300mah battery

What I've learned today:

• My Uni is currently on firmware 1.0.2.
• The apiuni server also points to 54.250.16.101. When you connect to the apiuni server, it gives a redirect to one of the IPs.
• When you connect to the apiuni server, whichever IP it sends back is locked on until either A) You disconnect, or B) a new DHCP lease is sent. So if you manually set the IP, never let it go to sleep, and never leave the range of your router, it will always connect to the exact same server.
• A new DHCP lease is requested each time the Uni wakes from sleep.
• When checking for updates, the Uni loves exchanging certificates. After every three or four transmissions of application data, it verifies the server certificate. It makes me wonder if there's no checks done by the Uni itself on whether a firmware image is valid.
• The server certs are generated by AWS, not Bandai specific. However, The ESP32 module declares itself as belonging to Bandai when it first connects.
• When you download items, all it's doing is downloading from an AWS S3 bucket (after exchanging a server cert twice). Presumably it is hashing the item code you've given it and identifying that hash with a specific s3 bucket.
• I downloaded the "hip-hop cap" and it looks like it's 2kb in size. No idea yet if every item is exactly 2kb or not

I explored the "tamaverse" a bit, and most things are closed at the moment. Potentially these open in a software update down the line?

If it was possible to install a new CA on the Uni, I could get a lot more info out of it.

 

[Zhongtiao1]

Day 3!

Rash has confusing tastes in social media:

When you download the "news," it looks like it downloads 40KB of data every time, and the promotional items/gifts are embedded in that.

Beyond that, I'm kind of at a standstill until we can get an mitm CA installed on the Uni. Nearly everything that the Uni does is communicated via TLS, and we need to be able to to decrypt that to get more info on its workings.

 

[tabzer]

Rash isn't dead surprisingly. However, he's seemed to have de-aged:

Rash lost all of his fur. Not dead, stressed?

 

[Zhongtiao1]

Rash lost all of his fur. Not dead, stressed?

Potentially, but he has it pretty good at the moment. He's even demanding I order food for delivery instead of eating his frickin cereal.

 

[ManuXD32]

Wow, thank you so much for sharing this info. I am so excited to see If we can make our own games or content and send It to the tama

Post automatically merged: Jul 21, 2023

Wow, thank you so much for sharing this info. I am so excited to see If we can make our own games or content and send It to the tama

 

[Selina282]

Is there something new about the hacking?
Do you have found something out?

 

[GlossPixie]

Hey,

As far as I can tell nobody's actually identified the Uni's main display/logic chip yet, only the ESP32-S3 wifi module is confirmed. I was assuming it'd be the same chip family as the Pix (which has accessible SPI flash via debug pads), but that's a guess, not a fact, and I don't want to send anyone shopping for tools based on it.

Marcelmono's power-off mod research already found test points on the board for the power regulator chip. Does anyone know if their writeup/photos show the main SoC's part number? That'd be the free way to confirm what we're actually dealing with before anyone opens anything up.

Separately, I want to help on the non-destructive side for now (I'm not willing to crack open my daily Uni for this). Maybe we run our own MITM capture and see what happens when it gets a cert it shouldn't trust, just to test whether validation is actually solid or there's a soft spot. If it turns out we do need board-level access down the line, maybe we can look for a dead/broken used unit to sacrifice rather than risk a working one.

Edit:

Found something that answers the "what's the main chip" question, from a couple Japanese sources that don't seem to have made it into English-language Tamagotchi circles yet:

1) A Japanese semiconductor analysis firm (Tecanarie/テカナリエ) did a die-level teardown for EE Times Japan, comparing it to Apple's M2 Ultra as a bit.
2) A much more detailed hobbyist teardown by tomorrow56 (ThousanDIY), originally published in the Japanese electronics magazine I/O, goes board-level.

Key findings from those:

- There's no separate "game logic" chip like the Pix has. The ESP32-S3-WROOM-1 module IS the main processor — it does wifi, display, and game logic, all on one chip. tomorrow56's writeup labels it directly as 「ボトラタ：無線モジュール（メインプロセッサ）」 ("the wireless module is the main processor").
- That module's specs: dual-core Xtensa LX7, 512KB SRAM, and 16MB of SPI flash built in. Not mask ROM — regular flash, same as any ESP32 dev board.
- Most importantly: tomorrow56 found and photographed test pads on the back of the board, explicitly identified as exposing UART plus the signal for triggering the chip's Download Boot mode. That's just the standard Espressif bootloader entry point — the same one esptool.py talks to on every ESP32 project. No glitching or decapping needed to get flash access, just normal ESP32 dev workflow.

Given that, the procedure to actually dump the flash should be:

1. Open the case and locate those test pads (cross-reference tomorrow56's photos for exact placement — I haven't pinned down which pad is which signal yet).
2. Identify GND, TX, RX, and the boot-mode pin (typically GPIO0 on ESP32-series chips — needs to be pulled low during reset to enter download mode).
3. Touch test probes (pogo pins or fine clips, no soldering needed) from a cheap USB-serial adapter to those pads.
4. Hold the boot pin low while power-cycling/resetting so it boots into Download mode instead of running the app.
5. pip install esptool, then read out the full 16MB: esptool.py --port [your port] --baud 115200 read_flash 0 0x1000000 uni_dump.bin
6. From there we've got the actual firmware to dig through — partition table, trust store/certs (answers the CA question from earlier), and hopefully the asset/character data format.

Haven't tried this myself yet on a real unit, posting the plan before touching anything in case someone's already further along or sees a problem with it. Anyone want to confirm pad locations against their own board before I commit to probing mine?