A Measurement Study of Cryptographic Misuse in Embodied AI Mobile Applications Junchao Li1
Xuelei Wang1 , Yuhang Huang1 , Qi Wang1 , Boyang Ma1 , Xuelong Dai1 , Minghui Xu1 , and Yue Zhang1
arXiv:2606.19983v1 [cs.CR] 18 Jun 2026
Shandong University, Qingdao, Shandong, China
Abstract. Embodied AI (EAI) mobile applications are evolving from auxiliary user interfaces into active control-path components, directly linking mobile-side cryptographic security to cyber-physical trust. Despite this shift, existing security research predominantly focuses on embodied AI devices and cloud infrastructures, leaving the mobile control layer largely unexplored as a critical attack surface. To bridge this gap, we present the first large-scale measurement study of cryptographic misuse within the EAI mobile ecosystem. We construct EAIAppZoo, a benchmark of 507 real-world applications across six EAI domains, and employ an automated semantic-aware analysis pipeline to measure the prevalence and characteristics of five major cryptographic failure modes. Our measurement yields 12,975 misuse findings (with an evaluated precision of 80.74%), revealing that these cryptographic failures are driven by EAI-specific engineering constraints rather than random developer errors. We uncover structural security trade-offs: latency-sensitive control paths systematically weaken transport protection, while the heavy reliance on offline device provisioning and legacy IoT SDKs exacerbates the local hardcoding of authentication credentials. Through real-world case studies, we demonstrate how these mobile-side cryptographic flaws bypass nominal network protections, enabling adversaries to intercept command channels and hijack the physical control of EAI entities. Ultimately, our findings highlight that mobile applications have become a fragile, yet overlooked, cryptographic trust boundary in cyber-physical systems. Keywords: Embodied AI · Mobile security · Cryptographic misuse · Cyber-physical security
1
Introduction
Embodied AI systems are rapidly moving from laboratory prototypes into realworld deployment scenarios, encompassing household cleaning robots, service robots, industrial robot arms, drones, wearable devices, and socially interactive platforms. In these ecosystems, mobile applications are no longer merely auxiliary user interfaces; they increasingly function as active control-path components responsible for device provisioning, remote command delivery, runtime monitoring, and cloud-assisted coordination. Through these roles, mobile applications
2
X. Wang et al.
directly mediate authentication and control instruction delivery. Unlike traditional mobile applications where a cryptographic compromise primarily leads to data privacy leakage, a cryptographic failure in an EAI control app translates directly into unauthorized physical actuation, kinetic damage, or unauthorized surveillance. This shifts the practical trust boundary of cyber-physical systems significantly towards the mobile layer. The mobile application layer serves as the critical bridge connecting users, cloud services, and physical entities, yet remains an insufficiently understood attack surface. In particular, the implementation and configuration of cryptographic logic along these complex EAI control paths remain poorly understood, with limited systematic analysis of how such mechanisms are deployed and potentially misused in practice. Our preliminary observations indicate that cryptographic misuse in EAI mobile applications is not merely a collection of isolated developer errors, but rather driven by unique, systematic engineering constraints inherent to embodied systems. First, the necessity for local or offline control (e.g., controlling a drone via direct Wi-Fi without internet access) creates significant friction with standard PKI infrastructures, often incentivizing developers to adopt insecure workarounds such as hardcoded static keys. Second, the strict low-latency requirements for real-time video streaming and teleoperation frequently compel developers to intentionally downgrade or strip away transport-layer encryption (e.g., using plaintext RTSP or MQTT). Finally, the fragmented EAI supply chain heavily relies on legacy third-party IoT SDKs, causing deprecated cryptographic primitives to spread virally across different device brands. To systematically demystify this overlooked threat landscape, we present the first large-scale measurement study of cryptographic misuse specifically targeting the EAI mobile ecosystem. We aim to answer the following three core Research Questions (RQs): – RQ1 (Prevalence & Distribution): How prevalent are cryptographic misuses in the EAI mobile ecosystem, and how are they distributed across different application domains? – RQ2 (Framework Reliability): How reliable and accurate is the proposed semantic-aware analysis pipeline in identifying cryptographic misuses in realworld EAI mobile applications? – RQ3 (Cyber-Physical Impact): How do mobile-side cryptographic flaws translate into exploitable vulnerabilities that bypass network protections and hijack the physical control of EAI entities? To answer these questions, we constructed EAIAppZoo, a benchmark dataset containing 507 real-world Android applications spanning six EAI categories. Instead of directly using off-the-shelf Android analysis tools, we developed an automated, semantic-aware static analysis pipeline. This pipeline seamlessly integrates dynamic memory unpacking with customized rule matching to precisely locate cryptographic misuses—including weak primitives, insecure parameter configurations, weak randomness, hardcoded secrets, and insecure communication practices—specifically along the practical control and authentication paths.
Cryptographic Misuse in Embodied AI Mobile Apps
3
Our measurement yields 12,975 misuse findings. We reveal that EAI mobile applications exhibit structured security trade-offs, exposing a fragile cryptographic trust boundary that severely undermines command authentication and transport integrity. Beyond large-scale prevalence, our case studies demonstrate that certain mobile-side cryptographic flaws can directly translate into practical cyber-physical attacks. In one representative case involving a Unitree Robotics quadruped robot application, a hardcoded cryptographic credential enabled the recovery of provisioning traffic, allowing attackers to reconstruct Wi-Fi credentials and pivot into the local network, thereby creating conditions for unauthorized command injection against the physical device. In summary, we make the following key contributions: – First Large-Scale Measurement on EAI Mobile Crypto-Security. We construct EAIAppZoo and conduct the first systematic measurement of cryptographic misuses across 507 real-world EAI mobile applications, exposing the mobile layer as a critical vulnerability surface in cyber-physical ecosystems. – Demonstration of Cyber-Physical Attack Chains. We bridge the gap between static code flaws and physical harm. Through in-depth case studies, we demonstrate how discovered mobile-side cryptographic vulnerabilities (e.g., hardcoded credentials and plaintext streaming) can be weaponized to intercept command channels and execute unauthorized physical hijacking of real-world EAI devices. – Revelation of EAI-Specific Root Causes. We demystify the structural factors driving these widespread cryptographic failures, highlighting how low-latency operational constraints, offline provisioning requirements, and inherited legacy IoT SDKs systematically force dangerous security tradeoffs. The dataset is not publicly released at the current stage due to ongoing research considerations, and will be considered for public availability after publication.
2
Responsible Disclosure
Following responsible disclosure principles, we reported a subset of confirmed vulnerabilities to affected vendors whose products were involved in our empirical analysis. In particular, we submitted a detailed technical report to Unitree Robotics regarding a hardcoded cryptographic credential issue identified in one of its mobile application deployments, including the affected code patterns, potential unauthorized-access risks, and possible attack consequences. Unitree Robotics actively acknowledged the reported issue and confirmed that the identified flaw could introduce unauthorized access risks under realistic deployment conditions. According to the vendor’s response, the issue has entered its internal security review and remediation process, and we are closely working with the vendor to support mitigation and validation of the fix.
4
X. Wang et al.
3
Background
3.1
The Dual-Mode EAI Control Architecture
A typical EAI ecosystem involves three tightly connected entities: the Mobile App is Cloud-Assisted Mode mobile application, the cloud sertheTrust Anchor vice, and the physical embodied device, as illustrated in Fig. 1. UnCloud Service Embodied Devices like conventional companion applicaMobile App Local/Offline Mode tions (which primarily act as passive data displays), mobile applications in EAI systems increasingly function Fig. 1: Dual-mode control interactions in as active, authoritative control-path EAI systems. bridges. They are directly responsible for device onboarding (provisioning), account authentication, real-time command generation, and firmware updates, effectively translating user intent into executable device actions. Crucially, EAI mobile control relies on a Dual-Mode Communication Architecture, which enables operation across heterogeneous environments. The system supports both cloudassisted communication for remote coordination and direct local communication for low-latency or offline control. These two modes coexist and are dynamically selected based on network conditions and operational requirements, forming a hybrid control paradigm distinct from traditional mobile-cloud interaction models. Provisioning
Authentication
Stability, standardization,security
WSS/PKI
WSS/PKI
Command Generation
– Cloud-Assisted Mode: The application communicates with the device via cloud telemetry relay, typically utilizing standard HTTPS/WSS protocols secured by well-established Web Public Key Infrastructure. – Local/Offline Mode: To ensure operational availability in environments without internet access (e.g., outdoor drone flights) or to minimize latency for real-time teleoperation, the application connects directly to the device via local networks (e.g., Wi-Fi AP mode, BLE, or local TCP/UDP). Within this dual-mode architecture, the mobile application often remains the primary trust anchor. It must locally manage credential storage, protocol initiation, and command construction before any physical actuation occurs. 3.2
EAI vs. Traditional Robotics
EAI systems differ fundamentally from traditional robotic systems in terms of architecture, control paradigm, and interaction model. Traditional robots are typically designed as closed, self-contained systems, where perception, planning, and control are tightly integrated within the device or a dedicated control unit. Their operation logic is relatively deterministic, task-specific, and often relies on pre-defined rules or classical control algorithms. In contrast, EAI systems
Cryptographic Misuse in Embodied AI Mobile Apps
5
Table 1: Comparison between EAI Systems and Traditional Robotics Dimension
Traditional Robotics
EAI Systems
System Architecture Closed, device-centric Open, distributed (App–Cloud–Device) Control Paradigm Pre-defined, deterministic Data-driven, adaptive Interaction Interface Dedicated controllers Mobile apps (text/voice/vision) Connectivity Limited or optional Always connected (cloud + local) Intelligence Source Embedded algorithms AI models (e.g., LLMs, multimodal) Control Path Single or fixed Dual-mode (cloud + local) Update Mechanism Infrequent, manual Continuous, OTA updates
are inherently open and distributed. They integrate mobile applications, cloud services, and physical devices into a unified control loop, enabling more flexible and adaptive behaviors. Instead of relying solely on pre-programmed logic, EAI systems increasingly incorporate data-driven models, including large language models and multimodal perception modules, to interpret user intent and generate actions dynamically. Another key distinction lies in the control interface. Traditional robots are usually operated through specialized controllers or fixed interfaces, whereas EAI systems expose user-facing interfaces via mobile applications, supporting natural interaction modalities such as text, voice, and vision. This shift significantly lowers the barrier to interaction but also introduces new security risks, as the control surface becomes broader and more accessible. These architectural and operational differences are summarized in Table 1.
4
Motivation and Threat Model
4.1
Motivation
Because mobile applications directly establish trust, cryptographic weaknesses at this layer critically undermine the entire cyber-physical system. To illustrate how such weaknesses emerge in practice, Listing 1.1 presents a representative code pattern adapted from a real-world EAI mobile application (a quadruped robot companion app named JueYingLite2 ), capturing three recurring classes of cryptographic misuse observed in our dataset. public void initAndPlay(String input) { try { 3 // (1) Weak cryptographic primitive (MD5) 4 MessageDigest md = MessageDigest.getInstance("md5"); 5 String hash = bytesToHex(md.digest(input.getBytes())); 1 2
6 7 8
// (2) Insecure local communication (plaintext RTSP) String url = "rtsp://192.168.1.103:8554/camera";
9 10 11
// (3) Hardcoded SDK credentials SmartPlayerJniV2 player = new SmartPlayerJniV2();
6
X. Wang et al.
12
player.SmartPlayerSetSDKClientKey( "8FC33AEE69AF4E7093FB95E9AFFE989C", "621E0DD5094841E2AB99C59C7173341A..." ); player.SmartPlayerSetLowLatencyMode(1); player.SmartPlayerStartPlayback(url); } catch (Exception e) { e.printStackTrace(); }
13 14 15 16 17 18 19
}
Listing 1.1: Real-world cryptographic misuses observed in an EAI mobile application named JueYingLite2. Unlike conventional mobile applications where secure communication is typically enforced through standardized TLS-based APIs, EAI applications operate under a distinct set of engineering constraints that often correlate with degraded security practices. Based on our empirical observations, three recurring factors are closely associated with such cryptographic misuses: – Use of Weak Cryptographic Primitives (Lines 3–5): The use of MD5 reflects reliance on outdated cryptographic primitives. Due to its lack of collision resistance, MD5 is unsuitable for security-sensitive operations, undermining data integrity guarantees. – Latency-Sensitive Communication Paths (Lines 7-8): Real-time video streaming and teleoperation require low-latency communication. Applications may rely on plaintext RTSP streams over local IP addresses to reduce overhead, resulting in the absence of transport-layer protection and weakening communication confidentiality and integrity. – Local Control Constraints and Credential Shortcuts (Lines 10–17): EAI applications frequently operate in local-network environments where standard PKI-based authentication is difficult to deploy. Developers therefore embed static credentials or SDK keys directly within the application to simplify device initialization and authorization, weakening credential security and exposing secrets to reverse engineering. Unlike traditional Android apps, EAI applications face unique design pressures—such as local connectivity, real-time demands, and proprietary SDKs—that drive recurring cryptographic misuses. This necessitates a largescale empirical analysis to determine whether these vulnerabilities represent a systemic structural weakness across the ecosystem, or if they concentrate in specific domains tied to physical device control. 4.2
Threat Model and Attack Surface
In this measurement study, we assume a realistic, unprivileged attacker model targeting the mobile-side trust boundary. We assume the cloud infrastructure and the internal hardware of the embodied device are trusted and secure. The attacker’s capabilities are restricted to the following:
Cryptographic Misuse in Embodied AI Mobile Apps
7
1. Reverse Engineer (APK Access): The attacker can easily download the public EAI mobile application package from app markets and perform static reverse engineering to extract embedded assets, decompiled logic, and hardcoded cryptographic parameters. 2. Local Network Eavesdropper (MitM): The attacker is situated on the same local network as the mobile device and the EAI entity (e.g., a shared Wi-Fi network, or within the broadcast range of the device’s AP hotspot). The attacker can intercept, observe, and inject network traffic. Attacker Goals & Impact: Unlike traditional attackers seeking data theft, the adversary in our EAI threat model aims for Unauthorized Cyber-Physical Actuation. By exploiting mobile-side cryptographic misuses (e.g., extracting a hardcoded session key to forge authentication tokens, or injecting malicious payloads into a plaintext control stream), the attacker seeks to bypass the nominal authorization mechanisms. The ultimate goal is to hijack the command channel, forcing the EAI device to execute unauthorized physical movements (e.g., altering a drone’s flight path) or causing kinetic harm, completely independent of the legitimate user’s control.
5
Design of EAGLE
As illustrated in Fig. 2, the proposed EAGLE (Embodied AI Global Leakage Evaluation) consists of four sequential stages: dataset construction, preprocessing, static detection, and security posture assessment. Stage Ⅰ Dataset Construction & Input Candidate Application
Stage Ⅱ Dataset Preprocessing
Stage Ⅲ Static Analysis & Detection
Stage Ⅳ Security Posture Assessment
Filter Embodied AI related apps APK Files
Android OS
Sample Pool
Security Ruleset
Packing Detection Static Analysis Engine high-recall keywords
Manual Sampling & Validation
Detection Accuracy Metrics
Is Packed?
Keyword Filtering Human Validation Rule Loading
Detection
DEX
Dynamic Unpacking constructed dataset:EAIAppZoo
Third-party Library Filtering
Unpacked and Decompiled Apps
Unified JSON Results
Security Posture Analysis & Visualization
Physical Risk Mapping
Fig. 2: Overview of the EAGLE framework.
Stage I: Dataset Construction and Input. The measurement pipeline begins with dataset construction, aiming to establish a representative sample of real-world embodied AI mobile applications before any security analysis is performed. Starting from candidate applications collected from mainstream app
8
X. Wang et al.
markets and open repositories, we first filter embodied AI related apps according to functional relevance, focusing on applications that directly participate in device control, telemetry, or local interaction with physical agents. To improve recall, a keyword-based filtering strategy is applied using domainrelevant terms associated with drones, quadruped robots, educational robots, cleaning robots, and other embodied AI products. Because keyword filtering alone inevitably introduces noise, a manual validation step follows to remove irrelevant applications and confirm physical-control relevance. This process produces the final benchmark dataset, EAIAppZoo, which serves as the input for subsequent large-scale security measurement. Stage II: Dataset Preprocessing To support automated large-scale analysis, each APK in EAIAppZoo is transformed into an analyzable intermediate representation through systematic preprocessing. We first unpack application packages and decompile DEX bytecode into Java-like source code using JADX [20], while simultaneously preserving manifest metadata and package structures. Compared with raw bytecode, this representation provides higher semantic readability for tracking cryptographic API usage and credential logic. Because EAI applications frequently rely on commercial protection mechanisms, the pipeline performs packing detection before analysis. If an application is identified as packed, dynamic unpacking is applied to recover executable code before further processing. After unpacking and decompilation, third-party libraries are aggressively filtered to reduce framework noise. Common generic dependencies (e.g., androidx, okhttp3, retrofit2) are excluded unless they directly interact with application-defined security logic. This ensures that the measurement reflects the security posture of EAI developers and proprietary SDK supply chains rather than generic Android framework behavior. Stage III: Static Analysis and Detection Static analysis is driven by a rule-based semantic detection engine built on Semgrep. A custom security ruleset is loaded to identify cryptographic misuse patterns in decompiled source code. The rules target five major categories of security weaknesses frequently observed in mobile and IoT software: weak cryptographic primitives, insecure parameter configurations, weak randomness, hardcoded secrets, and plaintext or insecure communication practices. For each application, the static analysis engine scans source files against the loaded ruleset and records all matched findings in a unified JSON format. Each finding preserves not only the matched code pattern itself, but also associated metadata such as file location, API context, and local surrounding code structures. This unified result format enables subsequent large-scale aggregation while preserving enough semantic detail for downstream interpretation. The rules target five major categories of security weaknesses frequently observed in mobile and IoT software: weak cryptographic primitives, insecure parameter configurations, weak randomness, hardcoded secrets, and plaintext or insecure communication practices.
Cryptographic Misuse in Embodied AI Mobile Apps
9
Table 2: Cryptographic misuse categories in EAGLE and example CWE mappings. Rule Category
Representative Description
Example CWE
Weak Cryptographic Deprecated or broken algorithms used CWE-327, Primitives in security-sensitive logic (e.g., MD5, CWE-328 DES, SHA-1). [6,11,30] Insecure Crypto- Unsafe parameter choices such as fixed CWE-323, graphic Parameter IVs, ECB mode, or improper padding. CWE-326 [2,10,29] Configurations Weak Randomness Predictable randomness sources or Generation insecure pseudo-random generators in cryptographic operations. [2,10,30]
CWE-329, CWE-330
Hardcoded Keys or Static secrets embedded in code or Sensitive Parameters assets, including keys, certificates, or authentication credentials. [22]
CWE-798, CWE-321
Insecure Communi- Plaintext transport or disabled cation Configurations certificate / hostname verification in communication channels. [19]
CWE-295, CWE-319
To improve methodological transparency, Table 2 further summarizes the operational rule inventory instantiated in the EAGLE pipeline. For each misuse category, we report the number of concrete detection rules together with their aligned CWE semantics, which serve as the standardized external reference for interpreting the security meaning of each matched finding. This rule inventory provides the operational basis for the subsequent largescale scanning process, ensuring that ecosystem-level measurements remain both semantically grounded and reproducible across heterogeneous EAI application contexts. Stage IV: Security Posture Assessment The final stage translates raw detection outputs into ecosystem-level security assessment. To estimate detection reliability, we perform manual sampling and validation on stratified subsets of findings, allowing us to compute detection accuracy metrics and calibrate the interpretation of static results. At the ecosystem level, aggregated JSON outputs are used for security posture analysis and visualization. Both absolute misuse counts and normalized misuse densities are computed to avoid scale bias across applications of different sizes. This supports cross-category comparison of misuse prevalence and concentration. To bridge static findings with embodied AI risk, findings located near communication interfaces, pairing logic, authentication modules, or control-relevant code paths are further interpreted under physical risk mapping. This contextu-
10
X. Wang et al.
alization allows the analysis to distinguish generic implementation flaws from security weaknesses that may directly weaken the mobile-device trust boundary and potentially affect physical actuation.
6
The EAIAppZoo and Measurement Setup
6.1
EAIAppZoo Dataset Construction
To support the large-scale measurement of cryptographic misuses and