Watch Your Kids: Inside a Children's Smartwatch

Nils Rollshausen

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

Overview

In an era where digital devices are increasingly integrated into every aspect of life, even children are equipped with smartwatches promising safety and connectivity. Nils Rollshausen's talk, "Watch Your Kids: Inside a Children's Smartwatch," delivers a stark reality check on these claims, revealing critical security vulnerabilities in the Explorer children's smartwatch. The presentation details a comprehensive security analysis, exposing how a device marketed for child protection could be easily compromised, allowing attackers to intercept communications, spoof locations, and even remotely factory reset the watch.

Watch on YouTube

Visual summary for Watch Your Kids: Inside a Children's Smartwatch by Nils Rollshausen
Visual summary for Watch Your Kids: Inside a Children's Smartwatch by Nils Rollshausen

Key moments

  1. 0:00 Introduction to children's smartwatch and security problem
  2. 2:40 Explorer's market and controversial Chiho 360 partnership
  3. 4:00 Previous security flaws and identical hardware with Chiho
  4. 6:00 Explorer's privacy claims and motivation for security analysis
  5. 8:00 Discovering hidden debug port via FCC reports

Watch Your Kids: Inside a Children's Smartwatch

Speakers: Nils Rollshausen, Researcher

Conference: 39C3

YouTube: https://www.youtube.com/watch?v=VRQz9EX2Tl0

Overview

In an era where digital devices are increasingly integrated into every aspect of life, even children are equipped with smartwatches promising safety and connectivity. Nils Rollshausen's talk, "Watch Your Kids: Inside a Children's Smartwatch," delivers a stark reality check on these claims, revealing critical security vulnerabilities in the Explorer children's smartwatch. The presentation details a comprehensive security analysis, exposing how a device marketed for child protection could be easily compromised, allowing attackers to intercept communications, spoof locations, and even remotely factory reset the watch.

Rollshausen, alongside his student Malta, meticulously reverse-engineered the Explorer smartwatch, uncovering a series of design and implementation flaws that undermine its core security promises. The research highlights a troubling disconnect between vendor marketing narratives, which often emphasize privacy and security, and the actual state of product security in the children's IoT market. With an estimated one-fifth of children aged 4-10 in Norway using Explorer subscriptions, the implications of these findings are profound, demonstrating how sensitive location and communication data of minors could be exposed to malicious actors.

The talk serves as a critical examination of the security posture of consumer IoT devices aimed at vulnerable populations. It not only dissects the technical weaknesses but also sheds light on the often-challenging process of responsible vulnerability disclosure with vendors. Rollshausen’s presentation is a compelling call to action for both manufacturers to prioritize security by design and for consumers to exercise skepticism when evaluating privacy claims in the burgeoning market of connected children's gadgets.

Background

▶ Watch: Introduction to children's smartwatch and security problem (0:00)

The market for children's smartwatches is driven by parents' desire for safety and connectivity, offering features like GPS tracking and text messaging. Explorer, a Norwegian company founded by Sten Gbak, has positioned itself as a prominent player in this space, even securing exclusive collaborations with major German soccer clubs and distribution through telecommunication providers. Their marketing strategy explicitly contrasts their privacy and security standards with those of "big tech" companies like Apple, asserting "strictest security and transparency standards" for children's sensitive data.

However, Explorer's history reveals a more complex narrative. In 2018, the company entered an exclusive supplier relationship with Chiho 360, a Chinese IT security firm known for its antivirus products and, curiously, its own line of children's smartwatches sold domestically. Chiho 360 has a documented history of controversies, including a dedicated Wikipedia page detailing various issues, most recently a racist AI chatbot integrated into their smartwatches in 2022. This association is particularly relevant as hardware comparisons from past security research indicate that Explorer previously re-branded Chiho 360's devices.

Indeed, Explorer watches faced significant scrutiny in 2020 when researchers at Pneummonic discovered a backdoor accessible via specially crafted SMS messages, which could turn the device into a listening device. This vulnerability rendered the watch illegal for sale in Europe at the time. While Explorer appears to have attempted a fresh start by switching to a new hardware platform in 2023 and potentially bringing firmware development in-house (suggested by a Norwegian-spelled string in their API), the inherent challenges of securing such devices, coupled with past incidents, set a precarious stage for the security claims they continue to make. Rollshausen's investigation was prompted by skepticism towards these vendor narratives, leading to a comprehensive security analysis of the latest Explorer smartwatch model.

Key Findings

▶ Watch: Explorer's market and controversial Chiho 360 partnership (2:40)

The comprehensive security analysis of the Explorer children's smartwatch revealed a series of critical vulnerabilities, fundamentally undermining the device's promised security and privacy. The primary findings can be summarized as follows:

  1. Undocumented Debug Access: The watch, running a customized Android variant, contained a hidden debug menu accessible by tapping the version number multiple times, similar to enabling developer mode on standard Android phones. This menu was initially protected by a simple, brute-forceable 4-digit PIN.
  2. Physical Debugging Capabilities: By re-creating an internal development charger (identified from FCC reports), researchers could establish a USB connection to the watch, which, combined with enabled debug mode, allowed for ADB (Android Debug Bridge) access. This granted the ability to mirror the screen, browse the file system (without root privileges), and extract custom Explorer applications.
  3. Weak API Authentication: Reverse engineering the custom Android apps revealed a severely flawed authentication mechanism. The watch used an init API endpoint to obtain short-lived authentication tokens, API keys, and MQTT (Message Queuing Telemetry Transport) credentials. The parameters for this init request, crucial for authenticating the device, were derived from easily enumerable information (such as the watch's IMEI or serial number), timestamps, and static secrets hardcoded within the firmware.
  4. Forging Authentication: Due to the reliance on static secrets and predictable inputs, an attacker could forge valid init requests for any Explorer smartwatch. This allowed the attacker to obtain valid API keys, MQTT certificates, and topic names, effectively impersonating any targeted watch.
  5. Comprehensive Device Impersonation: With forged credentials, an attacker could perform any action the legitimate watch could. This included:
  • Reading the entire message history between a child and parent.
  • Sending arbitrary messages to both children and parents.
  • Spoofing the watch's GPS location, making it appear anywhere in the world.
  • Remotely initiating a factory reset, effectively bricking the device or wiping its data.
  1. Inadequate Vendor Response and Patching: Despite responsible disclosure efforts, the vendor's initial "fix" merely increased the debug PIN to 6 digits and implemented a lockout mechanism, while leaving the underlying authentication vulnerabilities completely unaddressed. Credentials were not even rotated. Subsequent updates also failed to fully resolve the root cause, highlighting a significant lack of security maturity.

These findings collectively demonstrated that the Explorer smartwatch, despite its marketing claims, offered minimal protection against a determined attacker, exposing children's location, communication, and potentially even device control to compromise.

Technical Deep Dive

▶ Watch: Previous security flaws and identical hardware with Chiho (4:00)

The technical core of the Explorer smartwatch's vulnerabilities lies in a combination of insecure debug access, easily discoverable static secrets, and a flawed API authentication scheme. The research began with the acquisition of an Explorer watch and a deep dive into its hardware and software.

The initial breakthrough came from FCC reports, which are publicly accessible documents required for devices with antennas sold in the US. These reports included images of internal development hardware, specifically a four-pin charger, contrasting with the two-pin consumer version. By Frankensteining a custom cable to connect to all four pins on the watch's charging port, Rollshausen and Malta enabled a USB connection. While this initially didn't yield data access, it laid the groundwork for further exploration.

The next critical step was discovering a hidden debug mode. Analogous to Android's developer options, repeatedly tapping the version number in the watch's settings menu unveiled a secret PIN entry screen. This PIN, initially a 4-digit code, was found to be brute-forceable. Malta manually tested every possible 4-digit combination in about two hours, successfully gaining access. This enabled ADB (Android Debug Bridge), a powerful tool for interacting with Android devices. With ADB, the researchers could mirror the watch's screen, browse its file system (though not with root privileges), and crucially, pull all of Explorer's custom-developed applications from the device.

These extracted applications, written in Java, were then subjected to reverse engineering using standard tools. This process revealed the internal architecture and communication protocols. The system primarily consists of:

  1. A parent app on a smartphone communicating via HTTPS to an API server.
  2. The child's smartwatch communicating via HTTPS to another API server.
  3. The smartwatch receiving real-time notifications via MQTT, a lightweight messaging protocol, provided by AWS IoT Core.

The central vulnerability resided in the watch's authentication process, specifically calls to an init API endpoint. This endpoint was invoked frequently, typically before other API requests, to obtain session-specific authentication tokens, API keys, and MQTT certificates and topic names. Analysis of the init request parameters revealed several high-entropy, seemingly random values. However, upon deeper inspection, these values were found to be derived from a combination of:

  • A timestamp.
  • The watch's IMEI (serial number), which is easily enumerable or guessable.
  • Two distinct static secrets hardcoded directly into the watch's firmware.

Specifically, one parameter was generated by a function named getEmailSecret, which essentially computed an MD5 hash of the timestamp concatenated with the IMEI. Another function, an encrypt function, performed "mental gymnastics" to encrypt data using a second static secret. The use of MD5, a cryptographically broken hash function, and static secrets found directly in the firmware, represents fundamental cryptographic and security design flaws.

By understanding these derivations, an attacker could reconstruct the necessary parameters. Since the IMEI could be enumerated (e.g., by testing common ranges or patterns), and the static secrets were fixed in the firmware, an attacker could forge a valid init request for any Explorer watch. The response to such a forged request would contain valid API keys, MQTT certificates, and the unique MQTT topic name associated with that specific watch. These credentials granted full access to the watch's capabilities, allowing an attacker to impersonate the device and interact with the backend services as if they were the legitimate smartwatch.

This technical breakdown exposed a complete failure in implementing secure authentication, rendering the entire system susceptible to widespread compromise with minimal effort once the underlying secrets were discovered.

Demo / Proof of Concept

▶ Watch: Explorer's privacy claims and motivation for security analysis (6:00)

Nils Rollshausen's presentation included compelling demonstrations of the practical implications of the discovered vulnerabilities, illustrating how an attacker—framed humorously as a "child-eating witch"—could exploit the Explorer smartwatch. These proof-of-concept attacks highlighted the severity of the security flaws:

  1. Communication Interception and Manipulation:
  • The first demonstration showed how an attacker could read the message history between a child and their parent for any targeted watch. This exposed sensitive private conversations, directly compromising the privacy of both parties.
  • Following this, the attacker could send arbitrary messages to the parent, impersonating the child. Rollshausen humorously demonstrated sending a message like, "Your child won't be home for a bit," underscoring the potential for malicious communication and distress.
  • The ability to send instant messaging notifications with attacker-defined text directly to the child's watch was also shown. While requiring some "trickery" as the watch's capabilities differ slightly from the parent app, this allowed an attacker to push custom messages onto the child's screen, potentially luring them or conveying false information.
  1. Location Spoofing ("Teleportation"):
  • This was perhaps the most visually striking demonstration. Using an MQTT client configured with the stolen certificates and topic names, the attacker could intercept location update requests from the parent app.
  • By copying a specific push ID from an intercepted MQTT message, the attacker could then inject a fabricated location update. The demo showed the child's reported location instantly changing from its actual position to an arbitrary location, specifically "Pyongyang, North Korea." This illustrates the critical risk of misleading parents about their child's whereabouts, potentially causing panic or facilitating real-world dangers.
  1. Remote Factory Reset:
  • The final demonstration showcased the ability to remotely initiate a factory reset on any targeted watch. By sending a specially crafted custom MQTT message, the attacker could command the watch to shut down and wipe its data.
  • While less visually dramatic, this attack could be used for denial of service, effectively disabling a child's watch, deleting their contacts, or removing any tracking capabilities, thereby further hindering parental oversight or the child's ability to call for help.

These demonstrations underscored that the vulnerabilities were not theoretical but immediately exploitable, posing significant risks to the safety, privacy, and security of children using Explorer smartwatches. The "one for loop away" comment highlighted the ease with which these exploits could be scaled to target a large number of devices.

Defensive Implications

▶ Watch: Discovering hidden debug port via FCC reports (8:00)

The findings from the Explorer smartwatch analysis carry significant defensive implications, not only for Explorer but for the broader IoT and children's smart device industry. Addressing these vulnerabilities requires a multi-faceted approach, focusing on robust security engineering, improved development practices, and transparent vendor-researcher communication.

For Explorer (and similar IoT manufacturers):

  1. Re-evaluate and Redesign Authentication: The absolute priority is to overhaul the authentication mechanism. This means eliminating static secrets hardcoded in firmware, which are easily extracted. Each device must generate and maintain unique, strong cryptographic keys. Authentication should employ modern, robust protocols that do not rely on easily enumerable data like IMEI combined with predictable inputs like timestamps. Credentials (API keys, MQTT certificates) must be rotated regularly and securely.
  2. Secure Debug Access: The hidden debug menu and brute-forceable PIN represent a severe security oversight. Debug modes should be completely removed or rendered inaccessible in production firmware. If absolutely necessary for specific scenarios, they must be protected by extremely strong, unique, device-specific credentials that are not guessable or brute-forceable, and ideally, require physical access or a secure provisioning process.
  3. Secure Firmware Development Practices: Implement a secure software development lifecycle (SSDLC). This includes threat modeling, regular security audits, static and dynamic analysis of code, and penetration testing by independent third parties. The use of broken cryptographic primitives like MD5 for security-sensitive operations is unacceptable.
  4. Robust Vulnerability Disclosure Program: While Explorer improved its program post-talk, the initial response was poor. Manufacturers must establish clear, accessible, and responsive vulnerability disclosure channels. Engaging with security researchers promptly and professionally is crucial for identifying and fixing issues before they are widely exploited. This includes timely communication, acknowledging findings, and providing realistic timelines for remediation.
  5. Credential Rotation: After a security incident or discovery of compromised keys, all potentially affected credentials (API keys, MQTT certificates) must be immediately invalidated and rotated. The observed failure to rotate credentials even after a firmware update indicates a fundamental flaw in their incident response and security architecture.
  6. Supply Chain Security: Given Explorer's history with Chiho 360, manufacturers must exercise extreme diligence in selecting hardware and software suppliers, particularly those with documented security issues. Thorough independent security audits of all third-party components are essential.

For Parents and Consumers:

  1. Skepticism Towards Marketing Claims: Do not blindly trust vendor claims of "strictest security and transparency standards," especially from smaller or lesser-known brands in the IoT space. Independent security audits and research often paint a different picture.
  2. Research Before Purchase: Investigate the security track record of a device and its manufacturer. Look for independent reviews, security research, and news about past vulnerabilities.
  3. Consider Established Vendors (with caution): While not immune to flaws, larger, more established technology companies like Apple, Garmin, or Google (Fitbit) often have more resources dedicated to security and a longer history of securing embedded devices. However, even these should be approached with a critical eye.
  4. Privacy Implications: Understand the data collected by these devices, how it's stored, and who it's shared with. Question whether the perceived benefits outweigh the potential privacy risks, especially when dealing with sensitive information about children.

Ultimately, the defensive strategy must shift from reactive patching to proactive security by design. This incident serves as a potent reminder that "convenience" and "safety" features in connected devices can introduce significant new risks if security is not a foundational priority.

Key Takeaways

  • Children's Smartwatches Pose Significant Security Risks: Despite marketing promises of safety and security, devices like the Explorer smartwatch can harbor critical vulnerabilities that expose sensitive child data.
  • Weak Authentication is a Common Flaw: Reliance on static secrets embedded in firmware, easily enumerable device identifiers (like IMEI), and predictable inputs leads to easily forgeable authentication credentials, allowing full device impersonation.
  • Insecure Debug Access is Dangerous: Hidden debug menus and brute-forceable PINs provide an easy entry point for attackers to gain ADB access, extract firmware, and reverse-engineer proprietary applications.
  • Attackers Can Intercept, Spoof, and Control: Exploiting these flaws enables attackers to read private messages, send arbitrary communications, spoof GPS locations, and even remotely factory reset devices, posing serious threats to child safety and privacy.
  • Vendor Response to Vulnerabilities Can Be Inadequate: Initial attempts by vendors to patch vulnerabilities may be superficial (e.g., changing a PIN length) and fail to address the underlying architectural flaws, requiring sustained pressure for meaningful fixes.
  • Community Research Drives Improvement: Independent security research and responsible disclosure are crucial for uncovering and publicizing these flaws, pushing manufacturers towards better security practices, and ultimately making devices safer for users.

About the Speaker(s)

Nils Rollshausen is a security researcher based in Germany. His work, as demonstrated in this talk, focuses on the security analysis of consumer IoT devices, particularly those targeting vulnerable populations like children. He collaborated with his student, Malta, who conducted the primary research for his master's thesis on the Explorer smartwatch. Rollshausen is actively involved in responsible vulnerability disclosure, working with entities like the German Federal Office for Information Security (BSI) to mediate communication with vendors. His presentation style combines technical depth with a clear, engaging narrative, highlighting both the vulnerabilities and the broader implications for privacy and security in the connected world. He emphasizes the importance of independent security research and the potential for users to enhance their own security, even to the extent of running alternative secure communication apps like Signal on compromised devices.

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