BE Modded: Exploring and hacking the Vital Bracelet ecosystem

cyanic

39th Chaos Communication Congress (39C3): Power Cycles · Day 3 · Saal Fuse

Overview

In this insightful talk from 39C3, security researcher cyanic takes attendees on a deep dive into the Bandai Vital Bracelet ecosystem, a series of fitness-tracking toys that allow users to raise digital characters on their wrist. The presentation meticulously dissects the hardware, firmware, and associated companion applications, uncovering numerous security vulnerabilities and demonstrating advanced modding capabilities. cyanic’s work highlights the often-overlooked security posture of consumer electronics, particularly those designed for a younger audience or with a focus on novelty over robust protection.

Watch on YouTube

Visual summary for BE Modded: Exploring and hacking the Vital Bracelet ecosystem by cyanic
Visual summary for BE Modded: Exploring and hacking the Vital Bracelet ecosystem by cyanic

Key moments

  1. 0:00 Introduction to Vital Bracelet and its ecosystem
  2. 1:15 Hardware overview of the first-gen Vital Bracelet
  3. 2:30 Guide to dumping Vital Bracelet flash chips
  4. 6:00 Understanding the unique micro NSP CPU architecture
  5. 7:30 Reverse engineering firmware with Ghidra challenges
  6. 9:00 Deep dive into the structure of DIM cards
  7. 11:00 Modding DIM cards and creating custom content
  8. 16:00 Analyzing the new Vital Bracelet BE generation

BE Modded: Exploring and hacking the Vital Bracelet ecosystem

Speakers: cyanic

Conference: 39C3

YouTube: https://www.youtube.com/watch?v=ry2Qy-8Q_QE

Overview

In this insightful talk from 39C3, security researcher cyanic takes attendees on a deep dive into the Bandai Vital Bracelet ecosystem, a series of fitness-tracking toys that allow users to raise digital characters on their wrist. The presentation meticulously dissects the hardware, firmware, and associated companion applications, uncovering numerous security vulnerabilities and demonstrating advanced modding capabilities. cyanic’s work highlights the often-overlooked security posture of consumer electronics, particularly those designed for a younger audience or with a focus on novelty over robust protection.

The talk is significant because it not only exposes design flaws in a popular toy line but also provides a comprehensive guide to reverse engineering obscure, proprietary microcontroller architectures. cyanic's detailed methodology for dumping firmware, analyzing custom assembly, and bypassing security mechanisms offers invaluable lessons for researchers tackling similar embedded systems. Furthermore, the successful creation of sophisticated custom firmware, including polyphonic audio and pet-care features, showcases the immense potential that arises when security vulnerabilities are leveraged for user-driven innovation and product enhancement.

The implications of this research extend beyond the Vital Bracelet itself, serving as a cautionary tale for manufacturers about relying on superficial security measures like additive checksums or easily extractable symmetric keys. For defenders and hobbyists alike, cyanic's methodical approach—from initial hardware analysis to advanced code patching—provides a roadmap for understanding, securing, and even creatively repurposing consumer devices. The talk ultimately underscores the importance of thorough security by design, even in seemingly innocuous "toys," and celebrates the power of community-driven reverse engineering.

Background

▶ Watch: Introduction to Vital Bracelet and its ecosystem (0:00)

The Vital Bracelet series, sold by Bandai from 2021 to 2024, are wrist-worn fitness toys designed to allow users to "raise" digital characters, such as Digimon or other anime figures, through physical exercise and battles. The core gimmick revolves around DIMs (Digimon Identified Memory), which are small flash chips on PCBs with a micro SD pinout, used to download new characters and content. Device-to-device battles are facilitated by VS DIMs, and companion apps (Vital Bracelet Lab, Vital Bracelet Characters Lab, Vital Bracelet Arena) exist for character storage and online battling, communicating with the bracelets via NFC.

The first generation of Vital Bracelets (original Digimon version, Digivice V) shared common internal hardware. Key components included a General Plus GPC4p96UA 16-bit microcontroller based on the micro NSP architecture, a Micronics 16MB flash chip storing most of the code and resources, an NXP Integ C++ 1K NFC tag, an accelerometer (which saw a silent replacement in a later production run), and a heart rate sensor. A color LCD display connected over SPI, overlaid with an NFC antenna, completed the main setup. The choice of a discrete flash chip for images, rather than integrating everything into the chip-on-board (COB) microcontroller, proved beneficial for reverse engineering efforts.

Dumping these flash chips required specialized tools. cyanic highlighted the need for a flash programmer and either an SOP8 clip or desoldering the chip. A critical warning was issued regarding the ubiquitous and cheap CH341 programmer, which is slow, can output 5V to data lines instead of 3.3V, and lacks per-pin protection. The CH347 was presented as a faster, generally safer alternative for voltage, though still without per-pin protection and always-on power. The recommended and safest option was the XGCU T48, which only powers the chip during operation and provides better interface guidance. A significant hurdle in the initial dumping process was CPU interference, necessitating holding the CPU's reset pin to successfully read the flash contents. This low-level hardware interaction forms the foundation for all subsequent reverse engineering and modding efforts.

Key Findings

▶ Watch: Guide to dumping Vital Bracelet flash chips (2:30)

cyanic's research uncovered a series of critical security vulnerabilities and design flaws across the Vital Bracelet ecosystem, affecting both hardware and software implementations.

Firstly, the initial DIM card security was remarkably weak. While the header (containing vendor ID, product ID, card number, and release date) was signed, the actual content of the DIM was not. This meant that while creating a new card from scratch was difficult, an attacker could easily replace all other contents of an existing, signed DIM. Recognizing this, Bandai attempted to improve security in subsequent releases by signing the first 4 kilobytes of every 64 kilobytes of data. However, this still left 93.75% of the data unchecked, allowing for bypasses by placing custom data outside the signed regions and adjusting file tables. Further compounding this, the system relied on additive checksums, which could be easily accounted for by distributing the checksum difference across individual pixels, resulting in imperceptible visual changes. The use of HMAC-SHA256 also proved ineffective, as the symmetric secret required for verification was stored in the device's OTP ROM, which cyanic successfully dumped, rendering the scheme broken once the secret was exposed.

The DRM system, designed to tie a Vital Bracelet to a specific DIM card, initially allowed only one card per device. This was implemented by taking the UID from the NFC chip and writing it into the card. However, Bandai's own factory test mode (both software and hardware versions) contained functionality to write into this security slot and then clear it, effectively defeating their own DRM. This flaw was so significant that a subsequent emergency update for the Digivice V release gated the factory mode behind an additional special DIM, requiring proprietary hardware to bypass.

For the newer Vital Bracelet Be series, which introduced firmware upgrades via SD card, Bandai implemented a version rollback system. This system copied new firmware to both main and backup locations, performing a signature check only afterward. Paradoxically, the system also allowed installing any new version of firmware if both copies were corrupted (e.g., bricked), completely defeating the intended rollback protection. While the BE memory introduced OTP locking for content, using a random set of bytes signed with the content and stored in the secure OTP section of the flash chip, this too was bypassable. The chips lacked a unique ID feature, meaning that once the OTP data was dumped, it could be copied to another chip, creating a perfect clone. Furthermore, all HMAC secrets were still stored in this dumpable OTP.

Finally, the companion apps were not immune to vulnerabilities. The Vital Bracelet Arena app, which replaced earlier versions, used GS2 (game server services) but also had a "homebrew API" that lacked proper user authentication for certain operations. Specifically, if an attacker knew a user's ID (which could be found on the splash screen or social media screenshots), they could submit it to the server and delete the target user's account without requiring a user token.

These findings collectively demonstrate a pattern of insufficient security design, relying on easily circumvented measures and exposing sensitive information or critical functionality.

Technical Deep Dive

▶ Watch: Reverse engineering firmware with Ghidra challenges (7:30)

The technical deep dive into the Vital Bracelet ecosystem involved a sophisticated blend of hardware analysis, reverse engineering, and custom code development, centered around the General Plus GPC4p96UA microcontroller and its micro NSP architecture.

The micro NSP architecture is a 16-bit system frequently found in toys. Its most distinctive feature is a peculiar 22-bit address space (16 bits plus 6 bits), which presented challenges for standard reverse engineering tools. It features four general-purpose registers (with extended registers in micro SP 2.0) and a four-stage pipeline. The assembly format is largely algebraic, using equal signs alongside registers rather than traditional mnemonics, which cyanic noted made it "fairly fun" to write compared to ARM.

For reverse engineering the flash dumps, GEDra was the primary tool. However, the default processor module for micro NSP, downloaded from Samuel Anderson, initially provided poor decompilation. cyanic invested significant effort to improve this, making the output more readable C code. Despite these improvements, challenges remained, particularly with far pointers (the 16+6 bit addresses) which GEDra struggled to represent cleanly, often resulting in "sub32" messiness. Additionally, micro NSP lacks an overflow flag, using only a sign flag, which led to "really weird things" in decompiled conditional statements, often requiring direct assembly reading to understand branch logic.

Loading the binary into GEDra also required careful management of absolute addressing. micro NSP uses three main methods: function calls, go-to instructions, and switch tables. cyanic's method involved "cutting" addresses in the middle to identify base addresses and offsets, validating them against known code patterns, and then repositioning memory blocks. The flash was mapped to 0x2000000 in the Vital Bracelet's GPC4 chip, while RAM, peripherals, and OTP ROM were mapped at much lower addresses.

A significant breakthrough was the dumping of the OTP ROM. Since the OTP ROM could not be directly read, cyanic employed an ingenious method: inferring functionality by correlating device behavior with code patterns. For example, by observing the boot animation and identifying draw_image function calls reading data from SPI flash, the graphics loading mechanism was understood. This allowed for sprite extraction, providing visual references for code analysis. Once code writing to flash was identified, cyanic patched the firmware to read the OTP contents and write them to the main flash chip, effectively dumping the OTP ROM.

The NFC system utilized an NXP Integ C++ 1K chip, a dual-interface device supporting both I²C (for device-side communication) and NFC (for app-side communication). Character data transfer involved the bracelet writing data to the tag upon entering a menu, which the app then read and commanded deletion from the device. App-to-device transfer involved the app checking for the correct DIM, writing character data to the tag, and sending a command to commit the character. Security here relied on a tag password and AES128-CTR encryption. The password was not calculated locally but retrieved from a server, and the encrypted data was only processed server-side, preventing local decryption by the app. However, all this logic was also present in the device's now-dumped OTP chip, making it vulnerable. The NFC chip also supported a "field detect" feature, triggering random encounters when placed near an NFC field. cyanic experimented with this using an Integ I²C+ explorer board and a re-rigged Xamarin demo app to send password unlocks and decrypt data.

The Vital Bracelet Be introduced firmware upgrades via SD card. Despite new hardware like a fuse and load switch, cyanic managed to bypass the secure boot. Initial attempts to dump the OTP ROM by modifying code led to a backup copy rewrite. By analyzing logic analyzer captures of the boot process, which showed a bulk checksum followed by 4KB/64KB checks (similar to DIM signing), cyanic applied the same checksum workaround. This allowed for successful OTP dumping even from the "secure boot" system. The version rollback system was also found to be flawed, as it copied new firmware to both main and backup locations before signature checks, and allowed installation of any new firmware if both copies were corrupted.

For modding, cyanic exploited the micro NSP compiler's verbosity and a shorter encoding for absolute addresses within the first 64KB of address space. This allowed "squeezing" custom instructions into existing code sections. While the General Plus IDE provides a toolchain, cyanic preferred to rework its generated makefile for minimal compilation (assembling, linking, trimming). Reusing original firmware functions was achieved through macros or by defining empty "stubs" that the linker could resolve. To insert new behavior, existing instructions were replaced with a call to new, separate compiled code, followed by a jump instruction to bypass original logic, always ensuring original behavior was maintained where necessary. A custom, unreleased tool was developed to simplify mod building, capable of placing compiled code directly into flash images and featuring a micro SP assembly lexer and assembler.

Debugging remained a significant challenge, as the chip lacked in-circuit emulation lines, and proprietary tooling was inaccessible. The primary debugging method involved "staring at the code very hard." cyanic expressed interest in future emulation efforts to provide a proper debugger.

Demo / Proof of Concept

▶ Watch: Deep dive into the structure of DIM cards (9:00)

cyanic showcased several impressive modifications and proof-of-concept implementations derived from the extensive reverse engineering efforts:

  1. Bad Apple (Polyphonic Audio): A classic demoscene staple, Bad Apple, was ported to the Vital Bracelet. Uniquely, cyanic implemented it as a polyphonic demonstration, leveraging three Vital Bracelets hooked together to produce three-channel sound. This demonstrated advanced control over the device's audio capabilities, a significant technical feat given the constraints of the hardware.
  1. Vital PET Case Mod Software: In collaboration with Vak Design, cyanic developed software for the "Vital PET," a case mod that transformed the Vital Bracelet into a handheld device resembling a classic virtual pet. The custom firmware provided crucial quality-of-life improvements:
  • Workarounds for the heart rate sensor (often covered by the case).
  • Date display, a fundamental feature for a watch-like device that was surprisingly absent by default.
  • Evolution countdown, providing users with clear progression information. This specific mod laid the groundwork for cyanic's later patcher system and more complex modifications.
  1. Vital Bracelet Be Mod Rollup: This comprehensive mod for the Vital Bracelet Be is considered "essential" by many users due to its extensive quality-of-life features. It includes:
  • 12/24-hour time display.
  • Access to exclusive B memory features for older DIMs, enhancing compatibility and utility.
  • Fixes for "some other annoyances" in the original firmware.
  • An interesting anecdote was shared: a feature introduced by cyanic – turning evolution condition text yellow when met – suspiciously appeared in a later official Bandai update for the BE, hinting at potential inspiration or adoption.
  1. Vital Hero Major Mod: Done in collaboration with Comet Munch (who designed most of the logic), this mod significantly expanded the functionality of the Vital Hero, a cheaper and more accessible variant of the bracelet. It introduced traditional virtual pet care features:
  • Feeding and cleaning poop.
  • A progressively more challenging quest system.
  • cyanic's specific contribution to this mod was the implementation of an alarm clock, another basic watch feature missing from the default device.

These demonstrations collectively illustrate the practical application of the reverse engineering findings, transforming a proprietary toy into a highly customizable and enhanced platform, showcasing both technical prowess and a deep understanding of the device's underlying architecture.

Defensive Implications

▶ Watch: Analyzing the new Vital Bracelet BE generation (16:00)

The findings from cyanic's research into the Vital Bracelet ecosystem carry significant defensive implications, particularly for manufacturers of consumer electronics, IoT devices, and especially "smart toys."

Firstly, the repeated failures in content signing and integrity checks (e.g., only signing headers, signing only 4KB of 64KB, relying on additive checksums) highlight a critical flaw in security design. Manufacturers must adopt robust cryptographic hashing and digital signature schemes that cover the entirety of content and firmware. This requires using strong, industry-standard algorithms (e.g., SHA-256, ECDSA) and ensuring that verification occurs before any data is processed or executed. Additive checksums are fundamentally insecure and should be avoided in any security-critical context.

Secondly, the compromise of symmetric secrets (HMAC keys) stored in the OTP ROM demonstrates a severe vulnerability in key management. While OTP ROMs offer a degree of tamper resistance, if the underlying architecture allows for dumping the entire ROM, any secrets contained within are exposed. For truly secure systems, cryptographic keys should ideally be stored in a Hardware Security Module (HSM) or a secure element that is designed to prevent direct readout and only allows cryptographic operations on the key. If software-based secrets are unavoidable, they should be unique per device and derived using a robust, device-specific root of trust, rather than a single global secret.

Thirdly, the bypass of DRM mechanisms through factory test modes or lack of unique device identifiers underscores the need for comprehensive security auditing of all device functionalities, including those intended for internal use. Factory test modes should be strictly isolated, highly privileged, and ideally disabled or locked down in production units. Relying solely on easily clonable identifiers like NFC UIDs for DRM is insufficient. Incorporating unique, unclonable hardware identifiers and linking them to server-side authentication can strengthen device-to-content binding.

Fourthly, the flaws in the firmware update system for the Vital Bracelet Be, particularly the ability to roll back or install any firmware if the device is bricked, demonstrate a lack of secure update practices. Secure boot and firmware update mechanisms must enforce strict signature verification before any new firmware is written or executed. Rollback protection should be robust, preventing downgrades to vulnerable versions, and recovery modes should still enforce signature checks for any loaded firmware.

Finally, the application-level vulnerabilities, such as the ability to delete user accounts via an unauthenticated user ID in the Vital Bracelet Arena app, emphasize the importance of secure API design and implementation. All sensitive operations on companion apps should be protected by robust authentication and authorization mechanisms, utilizing user tokens, proper session management, and server-side validation for every request. Publicly discoverable user IDs should never be sufficient for critical actions.

In summary, manufacturers of consumer electronics, especially those with online components, must prioritize security by design, employ robust cryptographic primitives, implement secure key management, thoroughly audit all code paths (including internal and recovery modes), and adhere to best practices for secure application development to prevent similar vulnerabilities.

Key Takeaways

  • Obscure hardware is not immune to reverse engineering: Despite proprietary 16-bit microcontrollers and custom architectures like micro NSP, determined researchers can develop tools and methodologies (e.g., GEDra improvements, OTP dumping techniques) to understand and control them.
  • Toy security often has critical flaws: The Vital Bracelet ecosystem demonstrated multiple vulnerabilities, including weak content signing, easily bypassed checksums, exposed symmetric cryptographic keys, and DRM defeated by factory test modes.
  • OTP ROM dumping is crucial for security analysis: Accessing and analyzing the contents of the OTP ROM proved essential for understanding and bypassing the device's core security mechanisms and extracting cryptographic secrets.
  • Modding ecosystems thrive on reverse engineering: The ability to dump and analyze firmware, coupled with knowledge of the underlying architecture, enabled the creation of sophisticated custom firmware that significantly enhanced device functionality and user experience.
  • "Secure boot" and "OTP locking" can be circumvented: Even with newer security features like secure boot and OTP-locked content, flaws in implementation (e.g., checksum workarounds, lack of unique IDs) allowed for bypasses and cloning.
  • Debugging proprietary chips remains a major challenge: The absence of in-circuit emulation lines and proprietary tooling forces reverse engineers to rely on laborious manual code analysis, highlighting an area ripe for future tooling development (e.g., emulation).

About the Speaker(s)

cyanic is a dedicated security researcher and "toy hacker" with a passion for reverse engineering obscure hardware. Their journey into toy hacking began with a micro NSP target, a boa tea game called Pun Tappy Chan (or Pun Boachan in the States), which sparked a deep interest in the architecture. This led cyanic to explore and collect all seven different firmware variants of the Vital Bracelet series, becoming intimately familiar with its intricate systems. Throughout the talk, cyanic demonstrates not only a profound technical understanding of embedded systems but also a commitment to improving the functionality and security of consumer devices through meticulous research and creative modding.

All talks from 39th Chaos Communication Congress (39C3): Power Cycles