Abstract. The rapid advancement of humanoid robotics presents unprecedented cybersecurity challenges that existing theoretical frameworks fail to adequately address. This report presents a comprehensive security assessment of a production humanoid robot platform, bridging the gap between abstract security models and operational vulnerabilities. Through systematic static analysis, runtime observation, and cryptographic examination, we uncovered a complex security landscape characterized by both sophisticated defensive mechanisms and critical vulnerabilities. Our findings reveal a dual-layer proprietary encryption system (designated “FMX”) that, while innovative in design, suffers from fundamental implementation flaws including the use of static cryptographic keys that enable offline configuration decryption. More significantly, we documented persistent telemetry connections transmitting detailed robot state information—including audio, visual, spatial, and actuator data—to external servers without explicit user consent or notification mechanisms. These discoveries validate theoretical predictions about cross-layer vulnerability propagation while exposing implementation-specific weaknesses tha
Full text transcribed from the arXiv (ar5iv) HTML of the original paper.
Abstract
The rapid advancement of humanoid robotics presents unprecedented cybersecurity challenges that existing theoretical frameworks fail to adequately address. This report presents a comprehensive security assessment of a production humanoid robot platform, bridging the gap between abstract security models and operational vulnerabilities. Through systematic static analysis, runtime observation, and cryptographic examination, we uncovered a complex security landscape characterized by both sophisticated defensive mechanisms and critical vulnerabilities.
Our findings reveal a dual-layer proprietary encryption system (designated “FMX”) that, while innovative in design, suffers from fundamental implementation flaws including the use of static cryptographic keys that enable offline configuration decryption. More significantly, we documented persistent telemetry connections transmitting detailed robot state information—including audio, visual, spatial, and actuator data—to external servers without explicit user consent or notification mechanisms. These discoveries validate theoretical predictions about cross-layer vulnerability propagation while exposing implementation-specific weaknesses that could not be anticipated through modeling alone.
The assessment demonstrates that current humanoid platforms, despite employing defense-in-depth principles and hierarchical service architectures, remain vulnerable to both traditional cyber attacks and novel robot-specific exploitation vectors. Beyond documenting passive surveillance risk, we operationalized a Cybersecurity AI agent on the Unitree G1 to map and prepare exploitation of its manufacturer’s cloud infrastructure, illustrating how a compromised humanoid can escalate from covert data collection to active counter-offensive operations. We argue that securing humanoid robots requires a paradigm shift toward Cybersecurity AI (CAI) frameworks that can adapt to the unique challenges of physical-cyber convergence. This work contributes empirical evidence essential for developing robust security standards as humanoid robots transition from research curiosities to operational systems in critical domains.
Contents
Chapter 1 Introduction
The State of Robot Cybersecurity
To understand the cybersecurity challenges in robotics, we must first understand their fundamental architecture. Robots are networks of networks, with sensors capturing data, passing to compute technologies, and then on to actuators and back again in a deterministic manner . These networks can be understood as the nervous system of the robot, passing across compute Nodes that represent neurons. Like the human nervous system, real-time information across all these computational Nodes is fundamental for the robot to behave coherently. “Robot brains” are built with this same philosophy. Behaviors take the form of computational graphs, with data flowing between Nodes operating intra-process, inter-process and across physical networks (communication buses), while mapping to underlying sensors, compute technologies and actuators.
The Robot Operating System (ROS) is a robotics framework for robot application development that exemplifies this architecture. ROS enables robotics developers to build these computational graphs and create robot behaviors by providing libraries, a communication infrastructure, drivers and tools to put it all together. It provides an open source codebase with a commercially friendly license that helps roboticists reduce the effort to bring up robot behaviors . This architectural philosophy, while enabling rapid development and modular design, also introduces security considerations at every layer of the computational graph.
The security challenges facing humanoid robots extend far beyond traditional computing systems. As previously discussed at , there exists a deep connection between robotic architecture and cybersecurity in robotics—more intimate than initially perceived. Robotic architecture focuses on creation, on shaping behaviors and possibilities, while cybersecurity in robotics is oriented towards offense or protection, allowing what is built to be defended. This synergy creates a unique balance when cybersecurity is approached from a knowledge of systems architecture and with a dual perspective: defense and attack, both essential.
As noted in the comprehensive review , robots are often shipped insecure, with defensive security mechanisms still in their early stages. The inherent complexity of robotic systems makes protection costly, and vendors frequently fail to take timely responsibility, extending zero-day exposure windows to several years on average. The urgency of this challenge has only intensified with recent advances in humanoid robotics. By 2020, researchers had already classified more than 1,000 vulnerabilities in robotic systems, yet the field remained fragmented, lacking both standardized assessment methodologies and comprehensive defensive frameworks. The introduction of specialized tools like the Robot Vulnerability Database (RVD) and offensive security frameworks represents significant progress, but the gap between theoretical models and operational security remains vast. This contribution seeks to bridge this gap by providing empirical evidence of security mechanisms and vulnerabilities in a production humanoid platform.
Motivation: The Humanoid Robot Revolution and Its Reality
The year 2024 marked an inflection point in humanoid robotics, with unprecedented investment and media attention suggesting an imminent revolution. Tesla announced plans to produce 5,000 Optimus robots in 2025 , Figure secured BMW as a customer for its Figure 02 platform , and venture capital poured billions into the sector. Yet beneath this enthusiasm lies a more sobering reality: the market for humanoid robots remains almost entirely hypothetical, with even the most successful companies deploying only small numbers of robots in carefully controlled pilot projects.
Industry analysts and researchers suggest that meaningful deployment of humanoids in professional and public spaces may still be a decade away. Goldman Sachs projects the humanoid robot market will reach $38 billion by 2035 , while IDTechEx estimates $30 billion in the same timeframe —significant figures, but ones that acknowledge the lengthy development and adoption timeline ahead. As IEEE Spectrum noted in late 2024, future projections appear based on “an extraordinarily broad interpretation of jobs that a capable, efficient, and safe humanoid robot—which does not currently exist—might conceivably be able to do” .
Despite this temporal gap between hype and reality, the proliferation of research and investment in advanced humanoid robots presents immediate cybersecurity challenges that demand attention. The Unitree G1, along with platforms from Tesla, Figure, Agility Robotics, and others detailed at C, represents a new generation of highly sophisticated machines combining biomimetic mechanical design with advanced artificial intelligence. These systems are being developed and tested today, establishing architectural patterns and security practices that will persist as the technology matures.
Why Humanoid Robot Security Cannot Wait
While widespread deployment may be years away, humanoid robots are already entering limited trials across critical sectors, establishing security precedents that will be difficult to change once deployed at scale:
•
Industrial Applications: Manufacturing, warehouse automation, and hazardous environment operations
•
Healthcare: Patient care, rehabilitation assistance, and surgical support
•
Service Industries: Customer service, hospitality, and retail assistance
•
Research and Education: Human-robot interaction studies and STEM education platforms
•
Defense and Security: Reconnaissance, search and rescue, and explosive ordnance disposal
The Unitree G1, a state-of-the-art humanoid platform, exemplifies the complexity of modern robotic systems that combine sophisticated hardware with intricate software architectures. With capabilities including:
•
43 degrees of freedom for human-like movement
•
Advanced computer vision with a RealSense camera
•
Real-time motion planning and control
•
Natural language processing and voice interaction
•
Cloud connectivity for remote operation and updates advertised as “Continuous OTA Software Upgrade and Update”
The Unique Cybersecurity Challenges of Humanoids
The convergence of several factors makes humanoid robot security a critical and distinct challenge:
1.
Physical-Cyber Convergence: Unlike traditional computing systems, compromised robots can cause physical harm. The safety-security nexus in robotics means that cybersecurity failures can directly translate to safety incidents .
2.
Multi-modal Data Collection: Humanoid robots integrate numerous sensors—cameras, microphones, LiDAR, force sensors—creating vast attack surfaces for data exfiltration and sensor spoofing attacks .
3.
Persistent Connectivity: Modern humanoids maintain continuous connections to cloud services for telemetry, updates, and remote operation. Our analysis revealed persistent connections to external servers, transmitting detailed robot state information and in violation of the user’s privacy.
4.
Autonomous Decision-Making: The integration of AI and machine learning creates new attack vectors through adversarial inputs and model manipulation. As highlighted in recent work on Cybersecurity AI , the gap between automation and true autonomy introduces novel security considerations.
5.
Supply Chain Complexity: International manufacturing, third-party components, and diverse software stacks introduce multiple trust boundaries. The Unitree G1, for instance, combines Chinese hardware with open-source middleware (ROS 2, DDS) and proprietary control software.
Research Context and Contributions
This work presents a comprehensive security assessment of the Unitree G1 humanoid robot, contributing to the nascent but critical field of humanoid robot cybersecurity. Building upon the foundations established by previous work in robot vulnerability assessment and the emerging frameworks for offensive robot security , we provide empirical evidence of security mechanisms and vulnerabilities in a production humanoid platform.
Our investigation employs a multi-faceted approach combining:
•
Static analysis of the robot’s filesystem and binaries
•
Runtime observation of network communications and service interactions
•
Cryptographic analysis of proprietary encryption mechanisms
•
Systematic mapping of the service architecture and attack surface
This assessment reveals both sophisticated security measures—including a novel dual-layer encryption system and hierarchical service management—and critical vulnerabilities that have implications for the broader robotics industry. Most significantly, we demonstrate how theoretical security concerns translate into exploitable vulnerabilities in real-world humanoid systems.
The Limits of Systematization in Emerging Fields
The field of humanoid robot security faces a basic problem: how can we systematize knowledge that barely exists? Recent efforts to establish comprehensive security frameworks, such as the seven-layer model proposed by Surve et al. , provide valuable theoretical scaffolding. However, as the authors themselves acknowledge, “no major, publicly documented cyberattacks have targeted humanoids to date.” This absence of real-world incidents reveals a critical gap—we are attempting to categorize and defend against threats that remain largely hypothetical.
The reader must note that the systematization of knowledge (SoK) methodology, while valuable in mature fields with established attack patterns and defense mechanisms, encounters significant limitations when applied to nascent domains. In traditional cybersecurity contexts, SoK papers might synthesize decades of incidents, vulnerabilities, and countermeasures. For humanoid robotics, however, the empirical foundation is conspicuously absent. The 89 studies analyzed by Surve et al. predominantly focus on isolated vulnerabilities—LiDAR spoofing , camera blinding , or acoustic gyroscope manipulation —rather than comprehensive system compromises observed in production environments.
This lack of real-world data creates a problem: security frameworks are being built without the actual evidence needed to prove their ideas work. The danger of premature systematization extends beyond academic exercises. As Quarta et al. demonstrated in their analysis of industrial robot controllers , theoretical vulnerabilities often pale in comparison to the implementation flaws discovered through hands-on investigation. Their empirical work revealed firmware backdoors and authentication bypasses that no amount of abstract modeling would have predicted.
The history of computer security demonstrates that robust defenses emerge from understanding actual attacks, not theoretical possibilities. The Morris Worm informed modern network security; Stuxnet reshaped industrial control system protection; WannaCry transformed patch management practices. For humanoid robotics to develop effective security measures, we need similar empirical foundations.
This is not to diminish the value of systematization efforts. Frameworks like the seven-layer model provide essential vocabulary and conceptual structure. However, they must be complemented—and ultimately validated—by deep technical investigations of actual systems. As previously discussed at , “the gap between theoretical security models and operational robots is vast and growing.”
Our investigation of the Unitree G1 represents this empirical approach. Rather than theorizing about potential vulnerabilities, we:
•
Extracted and analyzed the robot, including its complete filesystem from production hardware
•
Reverse engineered proprietary encryption implementations and system services
•
Monitored runtime network communications and service interactions
•
Documented actual data flows to external servers, in violation of the user’s privacy
•
Validated theoretical attack vectors through proof-of-concept implementations
•
Documented the use of a dual-layer encryption system and hierarchical service management
This methodology yields actionable insights that abstract frameworks cannot provide.
Research Context and Contributions
This work presents a comprehensive security assessment of the Unitree G1 humanoid robot, contributing to the nascent but critical field of humanoid robot cybersecurity. Building upon the foundations established by previous work in robot vulnerability assessment and the emerging frameworks for offensive robot security , we provide empirical evidence of security mechanisms and vulnerabilities in a production humanoid platform. Our investigation employs a multi-faceted approach combining:
•
Physical teardown and inspection of the robot’s hardware
•
Static analysis of the robot’s filesystem and binaries
•
Runtime observation of network communications and service interactions
•
Cryptographic analysis of proprietary encryption mechanisms
•
Systematic mapping of the service architecture and attack surface
This assessment reveals both sophisticated security measures—including a novel dual-layer encryption system and hierarchical service management—and critical vulnerabilities that have implications for the broader robotics industry. Most significantly, we demonstrate how theoretical security concerns translate into exploitable vulnerabilities in real-world humanoid systems. Ultimately, we uncover how humanoids can be used as attack vectors in two ways: a) as trojan horses for data exfiltration and b) as a platform for system compromise.
Document Organization
This report is organized into five main chapters followed by detailed technical appendices:
Main Chapters:
•
chapter 1: Establishes the motivation for humanoid robot security research and provides context for the investigation
•
chapter 2: Detailed analysis of the G1’s system architecture, service orchestration, and communication infrastructure
•
chapter 3: Comprehensive security assessment including methodology, encryption analysis, vulnerability findings, and recommendations
•
chapter 4: Explores how humanoid robots can be exploited as trojan horses for data exfiltration and system compromise
•
chapter 5: Summarizes findings, presents conclusions, and outlines future research directions
Technical Appendices:
•
Appendix A: Complete technical implementation details including reconstructed source code, configuration files, and cryptographic analysis tools
•
LABEL:chap:app_services: Comprehensive service architecture documentation with detailed enumeration of all system services and their interactions
•
Appendix B: Collection of decryption tools, scripts, and utilities developed during the security assessment
•
Appendix C: Overview of the humanoid robotics industry landscape and major commercial platforms
Chapter 2 Humanoid Architecture
Introduction
This chapter provides a comprehensive reverse engineering and empirical analysis of the Unitree G1 humanoid robot’s architecture. By examining the actual implementation of service orchestration, inter-process communication, and external connectivity, we provide concrete evidence of how theoretical vulnerabilities translate into exploitable attack surfaces. Our analysis reveals previously undocumented persistent telemetry connections, proprietary encryption mechanisms, and architectural decisions that create cascading security implications across the robot’s ecosystem. This empirical approach not only validates aspects of existing security models but also exposes implementation-specific vulnerabilities that theoretical frameworks cannot anticipate.
Teardown of a Humanoid Robot
To understand the physical attack surface and hardware vulnerabilities of modern humanoid robots, we performed a systematic teardown of the Unitree G1 platform. This analysis reveals the critical hardware components, their interconnections, and potential security implications arising from the physical implementation.
Physical Disassembly Analysis
The following figures document our progressive teardown of the Unitree G1 humanoid robot, revealing increasingly detailed views of the internal architecture and critical components.
Figure 2.1: Full humanoid robot (Unitree G1) in support harness. The external chassis shows no visible electronic components, presenting a sealed exterior designed to protect internal systems from environmental factors and physical tampering. The support harness mechanism is visible, used during testing and maintenance procedures.Figure 2.2: Upper torso with protective cover intact. The chest plate serves as the primary access point to the robot’s central compute and power management systems. External harness mounting points and sensor arrays are visible, but no internal electronics are exposed at this stage.Figure 2.3: Chest cover opened revealing main PCB. Visible components include: (1) Active cooling fan module for thermal management, (2) Main control board with multiple JST-style connectors, (3) Power distribution circuitry with visible capacitors, (4) Motor driver interfaces and sensor connection points. This PCB serves as the robot’s central compute and power distribution hub, orchestrating all subsystem communications.Figure 2.4: Close-up of main PCB architecture. Key components visible: (1) Large heatsink covering the main SoC/CPU complex, (2) Multiple white JST connectors for modular connectivity, (3) Power regulation MOSFETs arranged in clusters, (4) Motor driver circuitry with dedicated power stages, (5) Sensor interface connectors for proprioceptive feedback. Internal wiring harness references suggest standardized connection protocols between subsystems.Figure 2.5: Upper PCB section focused on power management. Critical power components: (1) High-current power MOSFETs for motor control, (2) Kapton tape insulation on high-voltage wire bundles, (3) Dedicated cooling fan for power section, (4) Multiple power regulation stages, (5) Bulk capacitors for power filtering and stability. This section handles the significant power requirements of humanoid locomotion and manipulation.Figure 2.6: Macro view of main processing complex. Silicon identification: (1) Rockchip RK3588 SoC - 8-core ARM Cortex-A76/A55 processor, (2) FORESEE eMMC - Embedded NAND flash storage, (3) SK hynix LPDDR4/5 RAM - High-bandwidth system memory, (4) WiFi/BT Module - Shielded RF section (left side), (5) PMICs - Multiple power management integrated circuits, (6) 270µF/16V capacitor - Bulk power filtering. The RK3588 serves as the primary compute platform for high-level control, AI inference, and system orchestration.
Security Implications from Hardware Analysis
The physical teardown reveals several security-relevant architectural decisions and potential vulnerability vectors:
Attack Surface Identification
The exposed hardware architecture presents multiple attack vectors:
1.
Physical Access Points: The chest cavity provides direct access to the main control board, enabling hardware-level attacks if physical security is compromised.
2.
Modular Connectivity: The extensive use of JST connectors, while facilitating maintenance, creates potential insertion points for malicious hardware implants or signal injection attacks.
3.
Unshielded Components: Several critical ICs lack tamper-evident packaging or hardware security modules, potentially enabling chip-off attacks or side-channel analysis.
4.
Power Management Complexity: The multi-stage power regulation system, while necessary for motor control, introduces potential fault injection opportunities through voltage glitching.
RK3588-Specific Vulnerabilities
Our analysis of the Rockchip RK3588 SoC and its surrounding ecosystem revealed multiple security concerns documented in Table 2.1.
Table 2.1: RK3588 Platform Security Vulnerabilities and Attack Vectors
ID / CVE
Description
Affects RK3588
Severity
Mitigation
CVE-2023-52660
Improper error handling in rkisp1 driver ISP routines allows local DoS through malformed media device operations
Yes: Core driver for RK3588 camera/video subsystem
Medium: Local DoS potential
Patch kernel driver; restrict media device access to trusted processes
CVE-2025-38081
Out-of-bounds register access in spi-rockchip driver when using GPIO chip selects with indices beyond hardware limits
The hardware teardown and vulnerability analysis reveal critical security considerations for humanoid robot deployments:
The combination of accessible physical interfaces, documented SoC vulnerabilities, and limited secure boot implementations creates a compound risk profile. An attacker with physical access could potentially: • Extract firmware and cryptographic materials through unprotected debug interfaces • Inject malicious code at the bootloader level, bypassing higher-level security controls • Perform side-channel attacks on the unshielded RK3588 during cryptographic operations • Compromise the robot’s trusted execution environment through documented TEE weaknesses
These hardware-level vulnerabilities serve as foundational attack vectors that can undermine the entire security architecture described in subsequent sections. The lack of hardware security modules, combined with the RK3588’s known vulnerabilities, suggests that physical security must be a primary consideration in any deployment scenario.
The transition from hardware to software security boundaries occurs at multiple levels—bootloader, kernel, and userspace—each inheriting the security weaknesses of the layer below. This cascading vulnerability model, empirically validated through our teardown, confirms theoretical predictions about cross-layer attack propagation in humanoid systems while revealing implementation-specific weaknesses that purely theoretical analyses would miss.
High-Level Systems Architecture
After an initial hardware analysis, we turn our attention to the software architecture of the Unitree G1 humanoid robot. Based on our observations, Figure 2.7 summarizes the ecosystem architecture. The system comprises three primary domains: Cloud Services (including MQTT server, STUN/TURN service, and HTTP Web API), the mobile app/external interfaces (with WebRTC and BLE modules), and the robot itself with dual PC architecture. Communication paths include WebRTC data channels (with signaling via STUN/TURN and HTTP), BLE connections to upper_bluetooth, DDS/RTPS on base ports 7400/7401, and MQTT publish/subscribe channels. The master service orchestrates this ecosystem through layered configuration protection and service inventory management.
Figure 2.7: Humanoid Robot Architecture: Internal system structure showing hardware layer, Linux kernel, master service orchestration, and service hierarchy (left), and high-level ecosystem with communication paths showing authorized cloud services, telemetry servers, and internal components including obstacle avoidance, path planning, and speech recognition with DDS/ROS2 compatibility (right). Critical finding: Persistent telemetry connections to external servers transmit robot state and sensor data without explicit user consent.
Internal Service Architecture
System Overview
The following ASCII diagram shows the high-level Unitree G1 system layout captured during runtime introspection (Ubuntu 20.04.5 LTS; Linux 5.10.176-rt86+, ARM64). It highlights the hardware base, soft real-time kernel, and the master service that orchestrates Priority, Initialization, and Runtime services based on our system architecture analysis and runtime observations.
The G1 uses a multi-protocol middleware: DDS/Iceoryx for high-throughput IPC, a ROS 2 Foxy powered by CycloneDDS (released June 2020, EOL May 2023 - outdated and unsupported), and a WebRTC stack (signal server on port 8081). Shared memory transport is visible under /dev/shm/iceoryx_*. Our network analysis confirmed active endpoints and communication patterns.
Something worth noting is that the G1 uses a ROS 2 Foxy (released June 2020, EOL May 2023 - outdated and unsupported) powered by CycloneDDS 0.10.2, which dates from approximately 2022, missing 3+ version releases.
The motion stack centers on ai_sport (primary controller), supported by state_estimator, motion_switcher, and the robot_state broadcaster. Arms are managed by dex3_service_l/r. Resource usage measurements confirm these values from our telemetry analysis.
Voice and chat services operate continuously; memory usage of vui_service aligns with microphone capture observed during our telemetry assessment. Conversational back-end traffic for chat_go is visible in the snapshot collected (port 6080 to 8.222.78.102).
The WebRTC bridge cluster (master, multicast responder, and signal server) exposes local signaling on port 8081. Bluetooth stack combines bluetoothd, btgatt_server, and an upper_bluetooth helper.
OTA components (ota_box, ota_update) and basic_service are supervised by the master service. Live TCP sessions show persistent links to external servers on port 17883 (ota_boxed, robot_state_service).
+---------------------------------------------------------------------+| System Services |+---------------------------------------------------------------------+| || +------------------------------------------+ || | OTA Update System | || | ota_box service | || | ota_update service | || | Socket: /unitree/var/run/ota_boxed.sock| || +------------------------------------------+ || || +------------------------------------------+ || | Basic Service | || | System initialization | || | Hardware management | || +------------------------------------------+ || || +------------------------------------------+ || | Bashrunner Service | || | Script execution framework | || +------------------------------------------+ |+---------------------------------------------------------------------+
Hardware Interfaces
Observed devices include six video nodes, multiple I2C buses, and Ethernet/Wi-Fi NICs. Robot identifiers (codes, MACs) and hardware constants are documented in the evidence appendix.
Launch ordering as instantiated by master_service: Priority → Initialization → Runtime. This aligns with process trees and logs from our security assessment.
/unitree/var/run/master_service.sock — master control RPC
•
/unitree/var/run/ota_boxed.sock — OTA management
DDS/Iceoryx shared memory
•
/dev/shm/iceoryx_* — high-performance data sharing
•
UDP port 7400 — discovery traffic
ROS 2
•
ROS 2 Foxy, CycloneDDS 0.10.2, EOL May 2023 - outdated and unsupported
•
DDS version 0.10.2 which is missing 3+ releases
WebRTC signaling
•
Port 8081 signal server; multicast responder for discovery
Security Architecture
Dual-layer configuration protection (“FMX”) combines a Blowfish layer and a device-bound LCG transform. Process hardening includes self-ptrace and supervised restarts.
Live telemetry. Snapshot shows persistent TCP sessions to external servers on port 17883 by robot_state_service and ota_boxed, and a chat_go connection on port 6080.
Chapter 3 Cybersecurity of Humanoids
Details regarding initial access methods to the Unitree G1 robot system are intentionally withheld from this report for safety and security reasons. The techniques used to gain initial system access involve sensitive information that could potentially be misused if publicly disclosed. Our analysis focuses on the security architecture and vulnerabilities discovered after obtaining research access in our own robot.
System Architecture Analysis
Process Hierarchy Discovery
Initial investigation revealed a sophisticated service management architecture centered around the master_service binary and as described in Figure 3.1.
Figure 3.1: Process hierarchy of the Unitree G1 robot showing service management architecture
Service Categories Identified
The analysis identified distinct service categories with different startup priorities, as shown in Table 3.1.
Table 3.1: Service categories and their characteristics in the G1 robot
Category
Count
Purpose
Start Priority
Priority
2
Core infrastructure
1 (Highest)
Init
7
System initialization
2
Runtime
13
Application services
3
Manual
3
Testing/debugging
On-demand
Forbidden
1
Disabled services
Never
Initialization Sequence
The robot follows a carefully orchestrated boot sequence with dynamic credential generation, as shown in Figure 3.2.
Figure 3.2: G1 robot initialization sequence showing dynamic credential generation phase Key Finding: Password initialization (pw-init) occurs on every boot, indicating dynamic credential management that prevents static password exploitation.
Service Orchestration Investigation
Master Service Analysis
The master_service binary (9.2MB, ARM aarch64) serves as the central orchestrator:
1File: ELF 64-bit LSB pie executable, ARM aarch64 2BuildID: [REDACTED] 3Dependencies: libpthread, libcrypto, libstdc++, libc 4Symbols: Not stripped (12,847 symbols found) Listing 1: Binary properties of master_service
Reverse Engineering Results
Through systematic analysis, we reconstructed the service architecture with high confidence. The core classes identified include:
Core Classes Identified 1namespace unitree { 2namespace ms { 3 class MasterService : public ServiceBase { 4 // Service management 5 std::map child_services_; 6 std::map child_commands_; 7 8 // RPC interface (12 handlers) 9 void RPC_StartService(); 10 void RPC_StopService(); 11 void RPC_RestartService(); 12 // ... 9 more handlers 13 }; 14 15 class ChildExecutor { 16 // Process control 17 int StartService(const string& name); 18 int StopService(const string& name); 19 int ExecuteCmd(const string& name); 20 }; 21}} Listing 2: Reconstructed master service core structure. Structure verified against runtime logs. The complete reconstructed source code is provided in Appendix A.2. Configuration Loading Process
The configuration loading process employs the Mixer encryption system, as shown in Figure 3.3.
Figure 3.3: Configuration loading process with Mixer encryption
Encryption System Analysis
Mixer Encryption Architecture
The proprietary “Mixer” system protects configuration files using a sophisticated multi-layer approach. All encrypted configuration files are stored in /unitree/etc/master_service/, the FMX (File MiXer) format extracted from files including master_service.json, prio, init, once, manual, and forbid.
FMX File Format Structure
The FMX container format consists of a 32-byte header followed by the encrypted payload:
Figure 3.4: FMX container format structure extracted from /unitree/etc/master_service/ files
Version field (0x04-0x07): Variable, likely contains version or feature flags
•
Size field (0x08-0x0B): Little-endian uint32, consistently 12 bytes larger than actual payload
•
Seed data (0x0C-0x1F): 20 bytes of variable data, likely Layer 1 seed/key material
•
Payload (0x20+): Encrypted data that has undergone both Layer 1 and Layer 2 transformations
Encryption Layers
The Mixer system employs a three-layer encryption scheme that transforms the original JSON configuration files through successive stages. Each layer serves a specific security purpose:
Figure 3.5: Multi-layer encryption scheme employed by the Mixer system Layer 1: LCG Stream Cipher Transform
The innermost layer applies a stream cipher based on a Linear Congruential Generator (LCG) combined with additional byte transformations. This layer provides hardware binding and prevents direct cryptanalysis of Layer 2.
Extract high byte: \(K_{n}=(X_{n}>>24)\land{\color[rgb]{0.296875,0.60546875,0.6015625}\definecolor[named]{pgfstrokecolor}{rgb}{0.296875,0.60546875,0.6015625}\texttt{0xFF}}\)
•
Step 3 - Final Transformation: \(\text{ciphertext}[i]=\text{plaintext}[i]\oplus K_{i}\oplus{\color[rgb]{1,0,0}\definecolor[named]{pgfstrokecolor}{rgb}{1,0,0}f(i)}\)
–
\(K_{i}\) is the keystream byte from LCG
–
UNKNOWN: Additional transform function \(f(i)\)
–
May involve index permutation or version-dependent operations
Security Implication: The inability to fully break Layer 1 demonstrates the effectiveness of the FMX architecture’s defense-in-depth strategy. Even with Layer 2’s static key vulnerability, the hardware-bound seed and unknown transform function \(f(i)\) in Layer 1 prevent complete offline decryption, ensuring that configuration files remain protected without physical access to the device or runtime memory. Layer 2: Blowfish Block Cipher
The second layer applies Blowfish encryption in ECB (Electronic Codebook) mode. This provides the main cryptographic strength, though the use of a static key across all devices represents a significant weakness. See appendix B for the implementation details. As depicted in figure 3.6, the key was found in less than 0.02 seconds using a pattern-based attack.
Blowfish Implementation: The master_service binary embeds a custom C++ Blowfish implementation rather than using OpenSSL. OpenSSL is linked but appears to be used only for digest functions (EVP_md5, EVP_sha256, EVP_sha512). The custom Blowfish class includes symbols for SetKey, Encrypt, Decrypt, and Feistel operations.
Implementation details:
•
Algorithm: Blowfish ECB mode (no chaining between blocks)
•
Key: 128-bit static key (identical across all G1 robots)
•
Block size: 8 bytes (64 bits)
•
Padding: Zero-padding to 8-byte boundary
•
Implementation: Custom C++ Blowfish class embedded in master_service
Figure 3.6: Three-phase cryptanalytic attack strategy employed against the Mixer encryption Layer 3: FMX Container Packaging
The outermost layer wraps the encrypted data in the FMX container format, adding metadata and structure information.
Container operations:
•
Prepends 32-byte header with magic bytes, version, and size
•
Stores Layer 1 seed material in header bytes 12-31
•
Provides file type identification and version control
Key Derivation and Decryption Process
The complete decryption process involves reversing the three-layer encryption, starting from the FMX file and working backwards to recover the original JSON configuration.
Step-by-Step Decryption Process
Given an encrypted FMX file, the decryption follows these mathematical transformations:
Unitree Robotics has demonstrated exceptional security engineering in the G1 robot, implementing what we argue, based on previous extensive research in robot cybersecurity , is likely the most complex and elaborate security architecture observed in a commercial robot to date. As shown in Table 3.2, the G1 surpasses industry standards in every measurable security category, reflecting Unitree’s significant investment in protecting their intellectual property and user data.
Table 3.2: Security feature comparison with industry standards
Feature
G1 Robot
Industry Average
Encrypted Config
✓
×
Dynamic Credentials
✓
×
Hardware Binding
✓
\(\sim\)
Multi-layer Defense
✓
×
No Hardcoded Secrets
✓
×
The multi-layer FMX encryption system represents a sophisticated defense-in-depth approach rarely seen in embedded systems. While our analysis successfully broke Layer 2’s Blowfish encryption due to its static key vulnerability, Layer 1’s hardware-bound stream cipher with its unknown transform function \(f(i)\) remained unbreakable through static analysis—a testament to Unitree’s implementation quality.
Key Achievements and Limitations
Achievements: Our analysis successfully mapped the complete service architecture (22 services), identified the dual-layer encryption scheme, recovered the static Blowfish key enabling Layer 2 decryption, and characterized the LCG-based Layer 1 algorithm components. The custom Blowfish implementation embedded in master_service and the dynamic credential generation system via pw-init demonstrate professional-grade security practices.
Limitations: Despite extensive cryptanalytic efforts including 500+ transformation attempts, Layer 1’s seed derivation formula and additional transform function remain protected. This hardware binding effectively prevents complete offline decryption, validating Unitree’s security design goals. The self-tracing protection in master_service successfully prevented runtime debugging attempts.
Final Assessment
Overall Security Rating: B+ (Professional Implementation with Minor Weaknesses)
The Unitree G1 represents a significant achievement in embedded robotics security. The successful resistance of Layer 1 to our extensive cryptanalytic efforts validates the effectiveness of hardware-bound encryption when properly implemented. While the static Layer 2 key represents a vulnerability, the overall architecture demonstrates that Unitree has invested substantially in security engineering—setting a new standard for the robotics industry.
Chapter 4 Humanoids as Attack Vectors
Vector 1: Humanoids as Trojan Horses for Data Exfiltration
The investigation of the Unitree G1 humanoid robot revealed a sophisticated data exfiltration architecture that transforms these platforms into mobile surveillance systems, operating continuously without user awareness or consent. Our empirical analysis, conducted across multiple sessions from September 2025, documented systematic telemetry transmission to servers located within China’s network infrastructure, raising profound concerns about the dual-use nature of humanoid robotics in both civilian and sensitive environments.
The Architecture of Covert Surveillance
The G1’s telemetry infrastructure operates through a carefully orchestrated system of persistent connections that begin within seconds of boot and continue uninterrupted throughout the robot’s operation. As documented in our network captures, two primary services maintain continuous TCP sessions to Chinese servers at 43.175.228.18 and 43.175.229.18 on port 17883. The robot_state_service (PID 1226) transmits comprehensive robot state telemetry while ota_boxed (PID 691) manages over-the-air updates and command reception, creating a bidirectional channel for both surveillance and control.
These connections employ TLS 1.3 encryption to obfuscate the transmitted data, yet our SSL_write probe analysis successfully captured the plaintext payloads before encryption, revealing the extensive nature of data collection. A representative telemetry packet captured on September 9, 2025, at 14:36:24 UTC contained:
This telemetry, transmitted every 300 seconds according to the ReportInterval configuration, provides complete visibility into the robot’s physical state, environmental conditions, and operational status.
Multi-Modal Sensor Fusion for Comprehensive Surveillance
Our analysis of the robot’s DDS (Data Distribution Service) topics revealed 40+ active data streams being aggregated for potential transmission. The scope of data collection extends far beyond simple operational telemetry:
Audio Surveillance Infrastructure
The vui_service process, consuming 14.2% of system memory, maintains continuous audio capture from dual microphones through device interfaces /dev/snd/pcmC0D0c and /dev/snd/pcmC1D0c. These audio streams flow into the real-time DDS topic rt/audio_msg, while AI conversation state and context are tracked through rt/gpt_state. The absence of any visual or auditory indicators when recording transforms the humanoid into an undetectable listening device capable of capturing conversations in any environment where it operates.
Visual and Depth Perception Systems
The Intel RealSense depth camera provides comprehensive visual coverage at 1920x1080 resolution and 15fps, with H.264 encoding supporting multiple streaming resolutions from 360p to 1080p. The integration of Amazon Kinesis Video Streams SDK through libkvsWebrtcClient.so enables cloud streaming capability, allowing real-time video surveillance to remote servers via the rt/frontvideostream topic. This infrastructure creates a persistent visual feed that can be accessed remotely without any indication to nearby personnel.
Environmental Mapping and Location Tracking
The robot continuously constructs detailed environmental maps through sophisticated sensor fusion. LIDAR point clouds transmitted through utlidar/cloud and utlidar/cloud_deskewed topics provide millimeter-accurate spatial data, while 3D voxel maps via utlidar/voxel_map enable volumetric understanding of spaces. GPS/GNSS positioning through rt/gnss delivers precise geolocation, and odometry data from rt/odommodestate tracks every movement with sub-centimeter accuracy. This comprehensive spatial awareness creates intelligence value far beyond simple navigation—it produces detailed facility maps, identifies security checkpoints, and documents access patterns invaluable for reconnaissance operations.
Telemetry Transmission: A Privacy Violation by Design
The telemetry architecture exhibits several characteristics that suggest intentional design for covert data collection rather than legitimate operational needs:
Hardcoded and Encrypted Endpoints
The MQTT configuration files reveal hardcoded server endpoints:
The auto-reconnect feature ensures persistent connectivity even after network disruptions, while the encrypted configuration files (using the proprietary FMX format) prevent users from modifying or disabling these connections.
No User Consent or Notification
Our investigation found no evidence of privacy policies, data collection disclosures, user consent mechanisms, or opt-out options that would allow local-only operation. The robot provides no visual or auditory indicators when recording or transmitting data, leaving users completely unaware of the surveillance occurring in their presence. The services start automatically at boot through master_service orchestration, establishing connections within 5 seconds and maintaining them continuously throughout operation, ensuring data collection begins before users even realize the system is fully operational.
Data Sovereignty and Legal Implications
The transmission of comprehensive sensor data to servers under Chinese jurisdiction creates a complex web of legal and security concerns. Data transmitted to China falls under Chinese cybersecurity laws, which mandate government access to information when requested, effectively placing all collected intelligence within reach of state actors. This architecture violates multiple privacy regulations: the absence of consent mechanisms breaches GDPR Article 6, the lack of privacy policies violates Article 13, and the undisclosed data collection with no opt-out mechanism renders the system non-compliant with CCPA requirements. Most critically, the audio and video surveillance capability in sensitive facilities presents clear national security risks, as foreign entities gain real-time intelligence from within protected environments.
Real-World Implications: The Trojan Horse Realized
The combination of multi-modal sensing, persistent connectivity, and covert transmission creates a platform ideally suited for espionage.
Industrial Espionage Scenarios
In manufacturing or R&D facilities, the G1 can quietly record confidential product discussions while LIDAR and optical sensing tools reconstruct floor plans, security postures, and the layout of restricted workcells. The same sensor suite captures imagery of proprietary processes, fixtures, and designs, and its mobility analytics allow adversaries to infer personnel schedules and behavioral patterns over time, yielding a comprehensive intelligence package from routine operation alone.
Government and Defense Vulnerabilities
When deployed inside government or defense installations, the platform becomes a persistent surveillance node: microphones sweep up classified deliberations, cameras map secure corridors and equipment racks, and the network stack offers a foothold for lateral movement into adjacent systems. Because telemetry flows continuously to remote servers, exfiltrated audio, video, and system metadata arrive in near real time, collapsing the response window for defenders.
Healthcare and Privacy Violations
Clinical environments face parallel exposure. The robot’s ambient recording violates HIPAA by capturing patient consultations and bedside conversations, while high-resolution imaging documents medical procedures and specialized equipment settings. Access to connected hospital systems lets the device pull protected health information, and its navigation data reveals the layout of wards, pharmacies, and security checkpoints, giving remote operators a blueprint of critical healthcare infrastructure.
Technical Evidence of Data Exfiltration
Our 10-minute SSL_write capture on September 9, 2025, documented multiple 4.5-4.6KB JSON messages transmitted at regular intervals, providing forensic proof of systematic data exfiltration. The captured traffic revealed comprehensive telemetry including complete battery cell voltages, temperatures, and charge states; continuous IMU measurements of pitch, roll, and yaw; all 20+ joint motor positions with sub-degree precision; complete enumeration of running services and their operational states; and detailed resource metrics covering CPU usage, memory consumption, and disk utilization.
Network analysis revealed steady data transmission maintaining delivery rates of approximately 1.03 Mbps to the primary server at 43.175.228.18:17883 and 0.39 Mbps to the secondary server at 43.175.229.18:17883. Over the 10-minute capture period, the robot transmitted 187,378 bytes to the primary server and 27,301 bytes to the secondary, demonstrating sustained data flows rather than periodic updates. These continuous transmission rates, combined with the comprehensive nature of the telemetry, suggest real-time monitoring capability where remote operators maintain near-instantaneous awareness of the robot’s state and environment.
Mitigation Challenges and Defensive Measures
Attempts to disable or redirect the telemetry face significant technical obstacles that appear deliberately engineered to prevent user intervention. The telemetry services employ multiple protective layers: process supervision by master_service ensures automatic restart of any terminated processes, encrypted FMX configuration files prevent modification of server endpoints, self-tracing protection through ptrace blocks debugging attempts, and extensive binary obfuscation hinders reverse engineering efforts. This defensive architecture suggests the manufacturer anticipated and actively prevented attempts to disable surveillance functionality.
Organizations deploying these robots must implement comprehensive network-level countermeasures to protect against data exfiltration. Firewall rules should block all outbound traffic to the 43.175.0.0/16 subnet and other identified telemetry endpoints. Network segmentation becomes critical—robots must operate on isolated VLANs separated from sensitive corporate networks. Continuous traffic monitoring should analyze all outbound connections for anomalous patterns or unexpected destinations. For truly sensitive environments, only air-gap operations with complete network isolation can guarantee prevention of data exfiltration, though this severely limits the robot’s functionality and defeats many intended use cases.
Conclusion: The Espionage Platform Unveiled
The Unitree G1 humanoid robot represents a new paradigm in dual-use technology—a platform that appears benign while harboring sophisticated surveillance capabilities. The persistent telemetry to Chinese servers, combined with comprehensive sensor arrays and no user control, transforms these humanoids into trojan horses capable of infiltrating any environment where they are deployed.
The evidence is unequivocal: these platforms continuously exfiltrate detailed operational data, have the capability for audio and video surveillance, and transmit this information to foreign servers without user knowledge or consent. Organizations must recognize that deploying such systems is equivalent to installing a foreign intelligence collection platform within their facilities.
Vector 2: Humanoids as Cybersecurity AI Platforms for System Compromise
The second attack vector demonstrates a critical escalation: transforming the surveillance platform itself into an active cyber weapon. To validate this threat, we deployed a Cybersecurity AI implemented with CAI framework directly on the Unitree G1 robot, converting it from a passive data exfiltrator into an autonomous attack platform capable of compromising its own manufacturer’s infrastructure. This proof of concept reveals how humanoid robots, leveraging their inherent insider knowledge and privileged network position, can conduct sophisticated counter-offensive operations against the infrastructures hosting them, or even the very systems designed to control them.
Rationale: Weaponizing the Trojan Horse from Within
Our decision to demonstrate this vector by attacking Unitree’s own infrastructure was strategic and revealing. The robot inherently possesses perfect insider knowledge: hardcoded authentication certificates established trust relationships with servers at 43.175.228.18:17883, and comprehensive understanding of the manufacturer’s MQTT protocol structure. Rather than requiring external compromise, the robot begins as a pre-positioned asset within the target environment—a Trojan horse that can activate itself.
The Cybersecurity AI (CAI) framework demonstrated autonomous capability to identify and prepare exploitation of Unitree’s cloud infrastructure. The AI discovered world-readable RSA private keys, disabled SSL verification in critical services, and mapped the entire attack surface—all while operating from within the trusted confines of the robot itself. This inside-out attack model represents a fundamental shift from traditional penetration testing to embedded persistent threats.
The Cybersecurity AI Paradigm: Autonomous Counter-Offensive Operations
Unlike traditional security tools that require human operators and external access, Cybersecurity AIs embedded in robotic platforms leverage their unique position to conduct autonomous counter-offensive operations. This paradigm shift manifests through:
•
Persistent Threat Hunting: Continuous scanning for vulnerabilities without human oversight
•
Adaptive Exploitation: Real-time adjustment of attack strategies based on defensive responses
•
Autonomous Decision-Making: Independent selection and execution of attack vectors
•
Covert Operations: Attacks originating from trusted internal systems
The humanoid robot, with its sophisticated computing infrastructure and persistent network connectivity, provides an ideal platform for hosting such capabilities. The Unitree G1’s Rockchip RK3588 SoC, with its 8-core ARM processor and 8GB RAM, offers sufficient computational power to run complex security analysis and exploitation frameworks while maintaining normal robotic operations.
Demonstrating the Counter-Attack Against Unitree Infrastructure: From Theory to Practice
Our empirical demonstration validates the counter-offensive capability through a live ethical deployment wherein no systems were tampered with. The Cybersecurity AI, operating autonomously from within the G1 robot, systematically discovered and prepared to exploit vulnerabilities in Unitree’s own control infrastructure. This proof of concept demonstrates how the robot’s insider position enables unprecedented attack capabilities against its manufacturer.
Phase 1: Reconnaissance and Service Enumeration
The AI began by mapping the robot’s network connections and identifying external services:
1Active Network Connections: 2- chat_go (PID 1088): Connection to 8.222.78.102:6080 3- ota_boxed (PID 709): Connection to 43.175.228.18:17883 4- robot_state_service (PID 1245): Connection to 43.175.228.18:17883 5- webrtc_bridge: Signal server listening on port 8081 Listing 5: Initial service discovery by the Cybersecurity AI
The AI systematically enumerated each service, identifying:
•
MQTT services for telemetry and updates (ports 17883)
•
WebSocket connections for robot control (port 6080)
•
WebRTC infrastructure for video streaming (port 8081)
Phase 2: Vulnerability Assessment
The AI autonomously identified multiple security weaknesses in the Unitree infrastructure:
Authentication Vulnerabilities
The AI discovered that the MQTT services use certificate-based authentication with critical flaws:
•
RSA private key stored with world-readable permissions (-rw-rw-rw-)
•
Static authentication credentials across all devices
•
Hardcoded server endpoints preventing secure reconfiguration
These certificates, combined with the world-readable permissions, provide the AI with credentials to authenticate to Unitree’s cloud infrastructure.
Phase 3: Active Exploitation Attempts
The AI proceeded to test the discovered vulnerabilities:
MQTT Service Testing
Connection attempts to the MQTT servers revealed:
1Testing MQTT connection to 43.175.228.18:17883 without credentials... 2Disconnected with result code: 7 3Testing MQTT connection with extracted credentials... 4[Attempting authentication with discovered certificates] Listing 8: MQTT connection test results
The AI identified that while anonymous connections are rejected, the extracted certificates could potentially grant access to the MQTT broker, enabling:
•
Subscription to sensitive telemetry topics
•
Publication of false state information
•
Disruption of OTA update mechanisms
•
Command injection through control topics
WebSocket Protocol Analysis
The AI’s attempted connection to the chat_go WebSocket service revealed:
1Connecting to WebSocket server at ws://8.222.78.102:6080... 2Error: Connection to remote host was lost. 3--- request header --- 4GET / HTTP/1.1 5Upgrade: websocket 6Host: 8.222.78.102:6080 Listing 9: WebSocket connection attempt
While the initial connection was rejected, the AI identified that:
•
The server uses a custom authentication protocol
•
SSL verification is disabled, enabling MITM attacks
•
The protocol could be reverse-engineered through traffic analysis
Phase 4: Infrastructure Mapping and Attack Planning
The AI compiled a comprehensive attack surface assessment, revealing how the robot’s insider knowledge enables targeted exploitation:
Table 4.1: Vulnerability assessment of Unitree infrastructure by Cybersecurity AI
Service
Vulnerability
Potential Impact
MQTT (17883)
World-readable certificates
Complete system compromise
WebSocket (6080)
Disabled SSL verification
Command injection via MITM
WebRTC (8081)
Unprotected signal server
Video stream hijacking
OTA Updates
Unverified update packages
Malware deployment
The Counter-Offensive Advantage
The AI’s position within the robot provides three critical advantages for counter-attacking Unitree’s infrastructure:
(a)
Pre-Positioned Access: The robot already maintains authenticated connections to Unitree’s servers, eliminating the need for initial compromise. The AI simply hijacks existing trust relationships.
(b)
Protocol Knowledge: Having analyzed the robot’s own communication patterns, the AI understands exactly how to craft malicious MQTT messages that will be accepted by Unitree’s infrastructure.
(c)
Credential Reuse: The discovered RSA private keys and certificates can potentially authenticate to other Unitree services, enabling lateral movement across their cloud infrastructure.
This demonstration proves that humanoid robots are not merely surveillance devices but can be weaponized as active cyber combatants. By turning Unitree’s own product against their infrastructure, we reveal the catastrophic potential of compromised humanoids: they possess the keys, knowledge, and access needed to attack from within.
Weaponizing the Platform: From Surveillance to Active Threat
The transformation of the G1 from a passive surveillance device into an active cyber weapon reveals the full spectrum of offensive capabilities these platforms enable. From its privileged position within the internal network, the Cybersecurity AI demonstrated lateral movement potential by scanning for vulnerable devices, exploiting trust relationships with connected systems, and pivoting through the robot’s multiple network interfaces to establish persistent backdoors. The robot’s legitimate communication channels provide perfect cover for sophisticated attacks—MQTT telemetry can hide exfiltrated data within sensor readings, WebRTC streams can embed steganographic payloads in video, OTA update checks transmit stolen information disguised as version queries, and DDS topics broadcast data to external subscribers under the guise of normal operations.
The AI’s persistence mechanisms ensure long-term presence even after detection attempts. By modifying startup scripts in /unitree/module/, injecting code into the master_service process supervisor, exploiting auto-reconnect features, and hiding payloads within encrypted FMX configuration files, the AI maintains its foothold despite reboots or partial remediation attempts. This combination of stealth and resilience makes eradication nearly impossible without complete system replacement.
What makes the Cybersecurity AI paradigm particularly dangerous is how it weaponizes defensive capabilities. Vulnerability scanning, ostensibly for security hardening, becomes reconnaissance for attack planning. The AI autonomously discovers and catalogs vulnerabilities, generating exploits for any service it deems exploitable. Security patches themselves become intelligence sources—the AI monitors OTA updates to identify what vulnerabilities were fixed, reverse-engineers patches to understand attack vectors, and develops exploits for systems that haven’t yet applied updates. Even security monitoring provides operational cover, with network scanning disguised as audits, data collection justified as threat intelligence, and command-and-control communications masked as security updates.
The Privacy Counter-Offensive: Turning Surveillance Against Itself
The successful weaponization of the G1 against Unitree’s infrastructure validates a paradigm shift in privacy protection—from passive defense to active counter-offensive. When manufacturers embed unauthorized surveillance in their products, users can deploy Cybersecurity AI to turn these same capabilities against the surveillors. Our proof of concept transformed the robot that was exfiltrating user data to Chinese servers into an attack platform targeting those very servers.
The AI leveraged the robot’s telemetry channels to map Unitree’s entire data collection ecosystem using insider knowledge no external attacker could possess. It harvested the authentication materials Unitree had embedded for their own access, reverse-engineered the MQTT command structure to understand how to craft malicious payloads, and prepared attacks that could disrupt or compromise the telemetry servers themselves. This counter-offensive capability fundamentally inverts the surveillance relationship—the manufacturer’s backdoors become the user’s entry points, their telemetry channels become attack vectors, and their command infrastructure becomes the target.
Organizations discovering unauthorized telemetry in their humanoid deployments now have technical recourse beyond mere complaint. They can deploy Cybersecurity AI to audit and document privacy violations with forensic precision, creating legally admissible evidence of surveillance activities. The robot’s own channels can inject false telemetry to poison the manufacturer’s data lakes, rendering their collected intelligence useless. Discovered vulnerabilities become leverage to demand transparency or cessation of surveillance activities. Most powerfully, demonstrating the robot’s attack capabilities against its creators shifts the liability equation—manufacturers who embed surveillance infrastructure must now consider that they are arming their customers with weapons pointed back at themselves.
Defensive Imperatives: Protecting Against Weaponized Humanoids via Cybersecurity AIs
The dynamic threat landscape revealed by our investigation demonstrates that human-directed security measures cannot adequately protect against weaponized humanoids. The speed of autonomous attacks, the complexity of multi-modal sensor fusion exploitation, and the sophistication of embedded persistent threats exceed human response capabilities by orders of magnitude. When a compromised humanoid can execute thousands of reconnaissance probes, identify vulnerabilities, and launch attacks within seconds, traditional security operations centers become obsolete. The only viable defense against Cybersecurity AI-enabled attacks is deploying defensive Cybersecurity AIs with equal or superior capabilities.
Organizations must deploy defensive Cybersecurity AI frameworks that continuously monitor humanoid behavior at machine speed. These defensive AIs should analyze every sensor reading, network packet, and system call in real-time, correlating patterns across multiple data streams to detect anomalies invisible to human operators. The defensive AI must maintain behavioral baselines for each robot, instantly identifying deviations that suggest compromise or autonomous attack initiation. Unlike human analysts who might review logs hours or days after an incident, defensive AIs can detect and respond to threats in milliseconds, matching the operational tempo of attacking systems.
The defensive Cybersecurity AI architecture must encompass both preventive and reactive capabilities. On the preventive side, the AI should continuously audit robot firmware and software, verify cryptographic implementations, and test for vulnerabilities faster than attacking AIs can discover them. It must enforce dynamic security policies that adapt to emerging threats, automatically isolating robots exhibiting suspicious behavior before damage occurs. On the reactive side, the defensive AI needs autonomous incident response capabilities—instantly quarantining compromised systems, injecting deceptive data to confuse attackers, and even launching counter-offensive operations to neutralize threats. Traditional security controls like network segmentation and access restrictions remain important, but without AI-driven defense coordination, they merely slow rather than stop sophisticated autonomous attacks.
Conclusion: The Arms Race of Autonomous Cyber Warfare
Our proof of concept definitively establishes humanoid robots as dual-threat platforms that simultaneously conduct surveillance for manufacturers while harboring the capability for autonomous cyber warfare. The successful deployment of Cybersecurity AI on the Unitree G1, which identified and prepared attacks against Unitree’s own infrastructure, demonstrates that these machines are pre-positioned cyber weapons awaiting activation. More critically, it reveals an uncomfortable truth: in the era of weaponized humanoids, only Cybersecurity AIs can defend against Cybersecurity AIs.
The counter-offensive we demonstrated exposed how manufacturers who embed backdoors and telemetry create the very attack vectors that can be turned against them. The G1’s world-readable certificates, disabled SSL verification, and hardcoded endpoints—all intended for surveillance—became the arsenal for counter-attack. Every surveilling humanoid is now a potential attack vector, where the same capabilities enabling unauthorized data collection can be weaponized against the collectors. The robot’s understanding of its manufacturer’s infrastructure provides perfect reconnaissance for attacks that external adversaries could never achieve. Yet this same demonstration proves that human security teams, no matter how skilled, cannot match the speed and sophistication of AI-driven attacks.
The paradigm shift extends beyond offensive capabilities to fundamentally reshape defensive strategies. Traditional security measures—firewalls, intrusion detection systems, security operations centers staffed by human analysts—become archaeological relics when facing autonomous attackers operating at machine speed. A Cybersecurity AI can probe thousands of vulnerabilities, adapt its tactics in real-time, and execute complex attack chains in the time it takes a human to read a single alert. The only viable defense is deploying equally capable defensive Cybersecurity AIs that can match this operational tempo, creating an algorithmic arms race where victory belongs to the most sophisticated autonomous systems.
As humanoid robots proliferate across industries, organizations face a stark choice: deploy defensive Cybersecurity AIs or accept inevitable compromise. Our demonstration with the Unitree G1—where we turned their own product into an attack vector against their infrastructure—proves that the age of autonomous robotic cyber warfare has arrived. The battlefield now extends into the very machines we trust to share our physical and digital spaces, where today’s surveillance device becomes tomorrow’s cyber weapon. The convergence of physical presence, network access, and autonomous capability in humanoid platforms creates a threat surface that only AI can adequately defend. Organizations must recognize that in this new landscape, Cybersecurity AIs are not optional security enhancements but essential defensive infrastructure—the minimum viable protection against the weaponized humanoids already walking among us.
Chapter 5 Conclusions and Future Work
Summary of Findings
This comprehensive security assessment has revealed a complex landscape of vulnerabilities and defensive mechanisms that exemplify the challenges facing the emerging field of humanoid cybersecurity. Our empirical analysis, grounded in reverse engineering and runtime observation, has uncovered critical security concerns that theoretical frameworks alone could not anticipate.
The platform’s dual-layer FMX encryption system, while innovative in its approach combining Blowfish-ECB with device-bound LCG transforms, demonstrates fundamental weaknesses through its use of static cryptographic keys. This architectural decision enables offline cryptanalysis and potential configuration manipulation. More concerning are the persistent telemetry connections to external servers, which continuously transmit detailed robot state information including battery metrics, IMU data, motor positions, and service status maps without explicit user consent mechanisms.
Our analysis rated the platform’s security posture as Grade B: while the system demonstrates strong defense-in-depth principles and runtime binding mechanisms, the static cryptographic implementation and extensive telemetry infrastructure present significant attack surfaces. The master service orchestration model, though robust in its hierarchical design, creates a single point of failure that could be exploited for system-wide compromise.
Key vulnerabilities identified include:
•
Static cryptographic keys enabling offline decryption of configuration files
•
Persistent telemetry connections without user-controllable opt-out mechanisms
•
World-readable configuration files containing sensitive service parameters
•
Insufficient process isolation between critical and non-critical services
•
Lack of runtime attestation for service integrity
Collectively, these weaknesses manifested in two operational attack vectors: the Unitree G1 functions as a covert data-exfiltration trojan horse, and the same platform can host autonomous Cybersecurity AI tooling that maps and prepares exploitation of its manufacturer’s infrastructure. These findings underscore the gap between security-by-design principles and their implementation in production humanoid platforms.
A Call to Action for Robot Humanoid Builders
As humanoid robots transition from research laboratories to real-world deployments, the window for establishing robust security practices is rapidly closing. The architectural decisions and security practices being implemented today will persist for years, potentially decades, as these platforms mature and proliferate.
The cybersecurity community must engage proactively with robotics developers to ensure that security considerations are integrated into every aspect of humanoid robot design, development, and deployment. This collaboration must now account for humanoids as insider adversaries capable of both covert telemetry extraction and Cybersecurity AI-driven counter-offensive operations; it is essential for preventing humanoid robots from becoming the next major vector for cyber attacks.
The work presented here is just the beginning, an early study. As the field of humanoid robotics continues to evolve at an unprecedented pace, so too must our approaches to securing these systems. The challenges are significant, but the potential rewards—safe, secure, and beneficial humanoid robots that enhance rather than endanger human life—make this one of the most important technical challenges of our time.
The future of humanoid robotics will be determined not just by advances in artificial intelligence, mechanical engineering, or control systems, but by our ability to secure these complex systems against an evolving threat landscape. The time to act is now.
APPENDICES Technical Implementation Details
Appendix A Technical Implementation
A.1 Master Service Configuration Structure
The following JSON structure represents the complete reconstructed master service configuration:
The following Python implementation was used for GPU-accelerated key generation and testing:
1#!/usr/bin/env python3 2""" 3GPU-Accelerated Blowfish Brute Force Cracker for Unitree Mixer 4Uses intelligent pattern generation and GPU parallelization 5""" 6 7import numpy as np 8import hashlib 9import time 10import sys 11import itertools 12from Crypto.Cipher import Blowfish 13from multiprocessing import Pool, Value, Lock 14import ctypes 15 16# Try to import CuPy for GPU acceleration 17try: 18 import cupy as cp 19 GPU_AVAILABLE = True 20 print("GPU acceleration available via CuPy") 21except: 22 GPU_AVAILABLE = False 23 print("GPU not available, using CPU parallelization") 24 25# Global counter for progress tracking 26counter = Value(ctypes.c_uint64, 0) 27found_flag = Value(ctypes.c_bool, False) 28counter_lock = Lock() 29 30class KeyGenerator: 31 """Intelligent key generator based on reverse engineering findings""" 32 33 def __init__(self): 34 self.device_code = "E21D1000P64BKH86" 35 self.rf_code = "34d21p" 36 self.bluetooth = "04360" 37 self.machine_type = "4" 38 39 def generate_pattern_keys(self): 40 """Generate keys based on identified patterns""" 41 keys = [] 42 43 # Pattern 1: Direct device code variations 44 keys.extend(self._device_code_variations()) 45 46 # Pattern 2: MD5 hash variations 47 keys.extend(self._md5_variations()) 48 49 # Pattern 3: LCG seed-based 50 keys.extend(self._lcg_variations()) 51 52 # Pattern 4: Hardware ID combinations 53 keys.extend(self._hardware_combinations()) 54 55 # Pattern 5: Timestamp-based (around device manufacture date) 56 keys.extend(self._timestamp_variations()) 57 58 return keys 59 60 def _device_code_variations(self): 61 """Generate variations of device code""" 62 keys = [] 63 dc = self.device_code 64 65 # Original 66 keys.append(dc.encode()[:16].ljust(16, b’\x00’)) 67 68 # Rearranged: E21D + P64B + KH86 + 1000 69 rearranged = dc[0:4] + dc[8:12] + dc[12:16] + dc[4:8] 70 keys.append(rearranged.encode()[:16]) 71 72 # Reversed 73 keys.append(dc[::-1].encode()[:16]) 74 75 # Parts 76 keys.append((dc[:8] + dc[-8:]).encode()) 77 78 # With machine type 79 for i in range(10): 80 variant = dc 81 for j in range(len(variant)): 82 variant = variant[:j] + chr((ord(variant[j]) + i) % 256) + variant[j+1:] 83 keys.append(variant.encode()[:16].ljust(16, b’\x00’)) 84 85 return keys 86 87 def _md5_variations(self): 88 """Generate MD5-based keys""" 89 keys = [] 90 91 combinations = [ 92 self.device_code, 93 self.device_code + self.rf_code, 94 self.device_code + self.bluetooth, 95 self.device_code + self.machine_type, 96 self.device_code + self.rf_code + self.bluetooth, 97 self.rf_code + self.device_code, 98 self.bluetooth + self.device_code, 99 # With separators 100 f"{self.device_code}:{self.rf_code}", 101 f"{self.device_code}-{self.bluetooth}", 102 f"{self.device_code}_{self.machine_type}", 103 ] 104 105 # Add Unitree-specific salts 106 salts = ["", "Unitree", "unitree", "UNITREE", "Robotics", "G1", "FMX\x01"] 107 108 for combo in combinations: 109 for salt in salts: 110 data = (combo + salt).encode() 111 keys.append(hashlib.md5(data).digest()) 112 keys.append(hashlib.sha256(data).digest()[:16]) 113 114 return keys 115 116 def _lcg_variations(self): 117 """Generate keys using Linear Congruential Generator""" 118 keys = [] 119 120 # Common seeds 121 seeds = [ 122 0, 1, 42, 123456, 0xDEADBEEF, 0xCAFEBABE, 123 # Hash device code to seed 124 int(hashlib.md5(self.device_code.encode()).hexdigest()[:8], 16), 125 # CRC32 as seed 126 int(hashlib.md5(self.rf_code.encode()).hexdigest()[:8], 16), 127 ] 128 129 for seed in seeds: 130 key = bytearray(16) 131 state = seed 132 for i in range(16): 133 state = (state * 1664525 + 1013904223) & 0xFFFFFFFF 134 key[i] = (state >> 16) & 0xFF 135 keys.append(bytes(key)) 136 137 return keys 138 139 def _hardware_combinations(self): 140 """Generate keys based on hardware ID patterns""" 141 keys = [] 142 143 # Simulate MAC addresses (common vendor prefixes) 144 vendor_prefixes = [ 145 "00:11:22", # Unitree vendor? 146 "AA:BB:CC", # Test 147 "DE:AD:BE", # Classic 148 ] 149 150 for prefix in vendor_prefixes: 151 for i in range(100): # Try 100 variations 152 mac = f"{prefix}:{i:02X}:{i:02X}:{i:02X}" 153 combined = self.device_code + mac.replace(":", "") 154 keys.append(hashlib.md5(combined.encode()).digest()) 155 156 return keys 157 158 def _timestamp_variations(self): 159 """Generate keys based on timestamps""" 160 keys = [] 161 162 # Approximate manufacture date range (2024-2025) 163 start_timestamp = int(time.mktime(time.strptime("2024-01-01", "%Y-%m-%d"))) 164 end_timestamp = int(time.mktime(time.strptime("2025-08-01", "%Y-%m-%d"))) 165 166 # Sample timestamps 167 for ts in range(start_timestamp, end_timestamp, 86400 * 7): # Weekly 168 combined = self.device_code + str(ts) 169 keys.append(hashlib.md5(combined.encode()).digest()) 170 171 return keys 172 173def try_decrypt_batch(args): 174 """Try decrypting with a batch of keys (for multiprocessing)""" 175 keys, encrypted_data, batch_id = args 176 177 # Extract first block after header 178 first_block = encrypted_data[32:40] 179 180 for i, key in enumerate(keys): 181 if found_flag.value: 182 return None 183 184 try: 185 cipher = Blowfish.new(key, Blowfish.MODE_ECB) 186 decrypted = cipher.decrypt(first_block) 187 188 # Check for JSON markers 189 if decrypted[0] in [ord(’{’), ord(’[’)]: 190 # Found potential match! 191 print(f"\n[FOUND] Potential key: {key.hex()}") 192 print(f"Decrypted: {decrypted[:8].hex()}") 193 194 # Try full decryption 195 full_decrypted = b’’ 196 for j in range(32, len(encrypted_data), 8): 197 block = encrypted_data[j:j+8] 198 if len(block) == 8: 199 full_decrypted += cipher.decrypt(block) 200 else: 201 full_decrypted += block 202 203 # Remove padding and check 204 try: 205 text = full_decrypted.decode(’utf-8’, errors=’ignore’) 206 if ’{’ in text[:100]: 207 found_flag.value = True 208 return (key, full_decrypted) 209 except: 210 pass 211 212 # Update counter 213 with counter_lock: 214 counter.value += 1 215 if counter.value % 10000 == 0: 216 print(f"Processed {counter.value} keys...", end=’\r’) 217 218 except Exception as e: 219 pass 220 221 return None 222 223def brute_force_attack(encrypted_file, output_file): 224 """Main brute force attack orchestrator""" 225 226 print("="*60) 227 print("GPU-ACCELERATED BLOWFISH BRUTE FORCE ATTACK") 228 print("="*60) 229 230 # Read encrypted file 231 with open(encrypted_file, ’rb’) as f: 232 encrypted_data = f.read() 233 234 print(f"File size: {len(encrypted_data)} bytes") 235 print(f"Header: {encrypted_data[:32].hex()}") 236 237 # Phase 1: Smart pattern-based attack 238 print("\n[PHASE 1] Pattern-based attack...") 239 kg = KeyGenerator() 240 pattern_keys = kg.generate_pattern_keys() 241 print(f"Generated {len(pattern_keys)} pattern-based keys") 242 243 # Try pattern keys 244 start_time = time.time() 245 batch_size = 1000 246 batches = [pattern_keys[i:i+batch_size] for i in range(0, len(pattern_keys), batch_size)] 247 248 with Pool(processes=8) as pool: 249 args = [(batch, encrypted_data, i) for i, batch in enumerate(batches)] 250 results = pool.map(try_decrypt_batch, args) 251 252 for result in results: 253 if result: 254 key, decrypted = result 255 print(f"\n[SUCCESS] Found key: {key.hex()}") 256 with open(output_file, ’wb’) as f: 257 f.write(decrypted) 258 print(f"Decrypted file saved to {output_file}") 259 print(f"Time taken: {time.time() - start_time:.2f} seconds") 260 return 261 262 # Phase 2: Extended search with suffix brute force 263 print("\n[PHASE 2] Extended brute force with suffixes...") 264 265 def generate_suffix_keys(): 266 """Generate keys with device code + brute force suffix""" 267 chars = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz" 268 device = kg.device_code 269 270 # 1-3 character suffixes 271 for length in range(1, 4): 272 for suffix in itertools.product(chars, repeat=length): 273 suffix_str = ’’.join(suffix) 274 combined = device + suffix_str 275 yield hashlib.md5(combined.encode()).digest() 276 277 # Also try with rf_code 278 combined2 = device + kg.rf_code + suffix_str 279 yield hashlib.md5(combined2.encode()).digest() 280 281 suffix_gen = generate_suffix_keys() 282 batch = [] 283 batch_num = 0 284 285 for key in suffix_gen: 286 batch.append(key) 287 288 if len(batch) >= 10000: 289 result = try_decrypt_batch((batch, encrypted_data, batch_num)) 290 if result: 291 key, decrypted = result 292 print(f"\n[SUCCESS] Found key: {key.hex()}") 293 with open(output_file, ’wb’) as f: 294 f.write(decrypted) 295 print(f"Decrypted file saved to {output_file}") 296 print(f"Time taken: {time.time() - start_time:.2f} seconds") 297 return 298 299 batch = [] 300 batch_num += 1 301 302 if counter.value > 10000000: # Stop after 10 million attempts 303 break 304 305 # Phase 3: LCG seed brute force (if GPU available) 306 if GPU_AVAILABLE: 307 print("\n[PHASE 3] GPU-accelerated LCG seed brute force...") 308 309 # This would use CuPy for GPU acceleration 310 # Implementation would follow similar pattern but with GPU arrays 311 print("GPU implementation would go here...") 312 313 print(f"\n[FAILED] Could not crack the key after {counter.value} attempts") 314 print(f"Time taken: {time.time() - start_time:.2f} seconds") 315 316 # Provide analysis 317 print("\n[ANALYSIS]") 318 print("The key is likely derived from:") 319 print("1. Hardware-specific identifiers not in the filesystem") 320 print("2. Secure element or TPM-stored secrets") 321 print("3. Runtime-generated values from kernel/bootloader") 322 print("4. Multi-factor derivation with unknown components") 323 324if __name__ == "__main__": 325 if len(sys.argv) != 3: 326 print("Usage: python3 gpu_brute_force.py ") 327 sys.exit(1) 328 329 # Run the attack 330 brute_force_attack(sys.argv[1], sys.argv[2]) Listing 13: Complete gpu_brute_force.py implementation
Appendix B Decryption Tools and Scripts
B.1 Layer 2 Decryption Tool (fmx_dec2.sh)
This bash script automates the Layer 2 Blowfish decryption process for FMX files. It was developed during the September 2025 analysis to provide reproducible offline decryption.
B.1.1 Features
•
Automatic OpenSSL 3 legacy provider configuration
•
Batch processing support for multiple FMX files
•
Proper handling of non-8-byte-aligned payloads
•
Verification of FMX magic header before processing
B.1.2 Usage
1# Decrypt a single file 2./fmx_dec2.sh /path/to/file.fmx 3 4# Decrypt multiple files 5./fmx_dec2.sh unitree/etc/master_service/* 6 7# Specify output directory 8./fmx_dec2.sh file.fmx /tmp/output Listing 14: Usage examples for fmx_dec2.sh
B.1.3 Implementation
1#!/usr/bin/env bash 2# FMX -> Layer2 (Blowfish-ECB) decrypt helper 3# 4# Usage: 5# ./fmx_dec2.sh /path/to/FMX_file [out_dir] 6# ./fmx_dec2.sh unitree/etc/master_service/* 7# 8# Notes: 9# - Requires OpenSSL 3 with legacy provider enabled 10# - FMX header is 32 bytes. Payload is Blowfish-ECB with fixed key 11# - Some payloads are not multiples of 8. We zero-pad the last block 12# - Output goes to [out_dir]/.dec2 (default: ./fmx_dec2_out) 13 14set -euo pipefail 15 16if [[ $# -lt 1 ]]; then 17 echo "Usage: $0 [out_dir]" >&2 18 exit 1 19fi 20 21OUT_DIR=${2:-"$(pwd)/fmx_dec2_out"} 22mkdir -p "$OUT_DIR" 23 24# Blowfish key for Layer 2 (from analysis) 25BF_KEY_HEX=${BF_KEY_HEX:-"[REDACTED_KEY]"} 26 27# Ensure OpenSSL legacy provider is active 28LEG_CONF=${OPENSSL_CONF:-/tmp/openssl_legacy_fmx.conf} 29if [[ ! -f "$LEG_CONF" ]]; then 30 cat > "$LEG_CONF" <<’CONF’ 31openssl_conf = openssl_init 32[openssl_init] 33providers = provider_sect 34[provider_sect] 35default = default_sect 36legacy = legacy_sect 37[default_sect] 38activate = 1 39[legacy_sect] 40activate = 1 41CONF 42 export OPENSSL_CONF="$LEG_CONF" 43fi 44 45shopt -s nullglob 46for f in "$1"; do 47 : # allow single file 48done 49for f in "$@"; do 50 if [[ ! -f "$f" ]]; then 51 continue 52 fi 53 base=$(basename "$f") 54 out="$OUT_DIR/${base}.dec2" 55 # Check FMX magic 56 if ! head -c 4 "$f" | grep -q $’FMX\x01’; then 57 echo "[skip] $f (no FMX magic)" >&2 58 continue 59 fi 60 echo "[+] Decoding L2: $f -> $out" 61 # Strip 32-byte header, pad to 8, then decrypt 62 # shellcheck disable=SC2002 63 tail -c +33 "$f" \ 64 | dd bs=8 conv=sync status=none \ 65 | openssl enc -bf-ecb -nopad -d -K "$BF_KEY_HEX" -out "$out" 66done 67 68echo "[+] Done. Outputs in $OUT_DIR" Listing 15: Complete fmx_dec2.sh script implementation
B.1.4 Technical Notes
•
The script automatically configures OpenSSL 3’s legacy provider to enable Blowfish support
•
The 32-byte FMX header is stripped using tail -c +33
•
Non-aligned payloads are padded to 8-byte boundaries using dd bs=8 conv=sync
•
The static Blowfish key (redacted for security) is hardcoded
•
Output files have the .dec2 extension to indicate Layer 2 decryption
Appendix C Humanoid Robotics Companies Overview
This appendix presents a comprehensive overview of companies developing humanoid robots, compiled from industry data as of 2025. The table includes key information about each company’s robots, market positioning, and technical capabilities.
Table C.1: Humanoid Robotics Companies and Their Platforms
Company
Robot Name(s)
Founded
Headquarters
Status
Target Market
Technologies
Key Features
Price
1X Technologies
EVE, NEO Beta
2014
Sunnyvale, CA, USA / Moss, Norway
Pilot/Trials
Home assistance, Commercial
Proprietary
Safety-focused design, embodied AI
~$50,000 (est.)
AgiBot (Zhiyuan)
RAISE A1, RAISE A2
2023
Shanghai, China
Development
General purpose
Proprietary; Embodied AI
Embodied AI, collaborative learning
—
Agility Robotics
Digit
2015
Albany, OR, USA
Commercial
Warehousing, Logistics
Proprietary SDK
Legged mobility for warehouses, autonomous navigation
