Report Overview

1. Basic Information

Background: From June 2024 to July 2025, external agencies and our side continuously carried out security monitoring and penetration testing work, during which some security risks were discovered; 

Scope: External accessible interfaces and functions of FJDynamics AT2 devices and related components (including firmware, MQTT Broker, Android applications, operating systems, etc.).

2.  Summary of Penetration

Descriptions of Vulnerabilities and Fix Suggestions

1. Critical Vulnerabilities

1-1 Firmware allows access to internal services

• Prerequisite: The attacker must know the URL of the RK firmware
• Problem Description: The RTK Shell firmware embeds a static SSH key, and this key is identical across multiple firmware installation instances. Once this key is extracted from any device, unauthorized users can use it to gain interactive Right of access to servers relying on this firmware, thereby executing arbitrary commands, accessing sensitive data, or escalating privileges.
• Fix Suggestions: Implement a unique key generation mechanism during the initial setup of devices to ensure that each device uses an independent SSH key, thereby reducing the risk of widespread damage to the large-scale system caused by the leakage of a single key.

1-2 MQTT Broker allows reading and writing data from other devices

• Prerequisite: None
• Problem Description: MQTT Broker configuration allows unrestricted access to sensitive data (such as GPS coordinates) and permits sending commands to all connected devices. This will lead to privacy breaches (such as exposure of device or personal physical location), unauthorized system control, and disruption of business functions.
• Fix Suggestions:
  • Immediately revise the MQTT Broker security settings, implement Role-Based Access Control (RBAC), and only authorize users to read GPS data and send commands.
  • Strengthen the authentication mechanism to ensure that all device connections and operations require strict identity verification.

1-3 Firmware update leads to remote code execution (RCE) due to lack of application verification

• Prerequisite: The attacker must be in a Man-in-the-Middle (MitM) position
• Problem Description: The communication channel of the Android application does not enable TLS encryption, and the device does not verify the APK file signature. Attackers can intercept or tamper with communication through MitM attacks and inject malicious APK files; due to the lack of signature verification, the device will execute malicious code, leading to unauthorized control of the device, data theft, or further malicious activities.
• Fix Suggestions:
  • Implement end-to-end TLS encryption for all communication channels, configure the server to support TLS 1.2 and above, and use certificates issued by trusted certificate authorities.
  • Force-enable APK signature verification, only allow the installation of apps signed by trusted sources, and reject APKs without a valid signature.

2.  High-risk Vulnerabilities

1-4 Outdated systems allow executable code to be executed via Bluetooth

• Prerequisite: The attacker must be within the Bluetooth Low Energy (BLE) range
• Problem Description: The Android system version running on the test device has stopped receiving support, with multiple security bugs, including a critical flaw that allows remote execution of executable code via Bluetooth. Attackers within Bluetooth range can execute arbitrary code without user interaction, potentially gaining full control of the device, including accessing sensitive data, installing malicious software, and even manipulating the device's steering function.
• Fix Suggestions:
• • Immediately upgrade Android devices to the latest supported version to fix known Bluetooth vulnerabilities.
  • Establish a regular update and patch management policy to ensure that devices and applications continuously receive security updates.

1-5 Kiosk mode escape can obtain root privileges of the device

• Prerequisite:  None
• Problem Description: The kiosk mode implemented by the application can be escaped, thereby accessing the underlying Android functions. Since the device is rooted by default, an attacker with physical access to the device can obtain privileges through the following methods: accessing the application and associated sensitive information, reading memory, and even manipulating application functions under certain circumstances. After entering the developer options via the Android UI and enabling ADB, the attacker can directly execute system commands as root.
• Fix Suggestions: Revise the kiosk mode to prevent escape; implement hardening measures (such as application allowlist) to restrict unauthorized access to functions.

1-6 Plaintext communication exposes credentials

• Prerequisite: The attacker must be in a passive MitM position
• Problem Description: The HTTP communication of the Android application does not enable TLS, allowing attackers to intercept network traffic and capture sensitive information (such as authentication tokens and user passwords). For example, JWT tokens are transmitted in plain text and may be used for account impersonation.
• Fix Suggestions:
• • Enforce the use of TLS 1.2 or higher for all HTTP communications and adopt strong cipher suites.
  • Configure all API endpoints to reject non-TLS connections and implement Certificate Pinning to prevent fraudulent certificate attacks.

3. Medium-risk vulnerabilities

1-7 Log files contain credentials and tokens

• Prerequisite: The attacker has access to local logs
• Problem Description: Android applications store sensitive data such as passwords in plain text in log files within the logs directory. The accessibility of the SD card allows other applications, administrators, or unauthorized third parties to potentially obtain this information, leading to account theft and compliance risks (e.g., violations of GDPR, HIPAA).
• Fix Suggestions:
• • Immediately stop recording sensitive information and remove relevant log statements through code review.
  • Clean up logs, and delete or securely archive sensitive data.
  • Logs need to be encrypted and desensitized.

1-8 MQTT Connection without TLS Verification

• Prerequisite: The attacker must be in a man-in-the-middle position
• Problem Description: The MQTT connection of the Android application does not verify the TLS certificate, allowing attackers to conduct MitM attacks, intercept, modify, or retarget data transmissions, endangering the confidentiality, integrity, and authenticity of sensitive data (such as user information and control commands) in the IoT system.
• Fix Suggestions:
• • Implement TLS certificate verification for all MQTT connections, verifying whether the server certificate is from a trusted CA and checking its validity (e.g., expiration, revocation status).
  • Using certificate pinning technology, hardcode the valid certificate of the MQTT server in the application and reject connections from non-matching certificates.

1-9 Backdoor Account Vulnerability (including non-functional defects)

• Prerequisite: The attacker needs to access the tablet device
• Problem Description: There is a backdoor account in the application, which is intended to bypass the normal authentication mechanism but is currently unavailable due to implementation flaws (generating lowercase letters and spaces when converting passwords to hexadecimal hashes). The existence of the backdoor account indicates that there may be other potential malicious code in the system, and if the flaw is fixed, it will lead to a serious security breach.
• Fix Suggestions:
• • Immediately locate and remove backdoor accounts and related code.
  • Conduct a comprehensive code review to identify other malicious components or vulnerabilities.

4. Low-risk Vulnerabilities

1-10 Hardcoding Password

• Prerequisite: The attacker needs to obtain the source code
• Problem Description: Hardcoding the password for the "Technical Support" menu in plain text in the application source code increases the risk of privilege escalation for attackers. Such passwords are easily compromised and lack access control protection.
• Fix Suggestions:
• • Assess whether it is necessary to store the key. If storage is required, use a strong hashing algorithm such as SHA-512 with salt to avoid plaintext storage.
  • Restrict password storage locations, set strict file permissions, and use independent credentials for different clients.
  • The password in the update script is deleted immediately after use.

1-11 Poor Password Policy

• Prerequisite: None
• Problem Description: The system limits the maximum password length to 8 characters, significantly reducing password complexity and resistance to brute-force attacks, and increasing the risk of unauthorized access to accounts.
• Fix Suggestions:
• • Revise the password policy to support passwords with at least 16 characters and encourage the use of passphrases.
  • Enforce password complexity requirements (such as a mix of uppercase and lowercase letters, numbers, and special characters), which aligns with password security best practices.

Threats and Risk Assessments

Lateral diffusion risk

• 1-1, 1-2, and 1-3 vulnerabilities affect all associated devices/servers.

Physical contact amplifies hazards

• 1-5 (kiosk escape) and 1-7 (log access) pose direct threats to offline devices.

Compliance High-Pressure Zone

• 1-6 (plaintext transmission) and 1-7 (log storage) may violate GDPR/HIPAA, leading to legal risks.

Vulnerabilities Fix Measures

1. Platform

Complete the global deployment of MQTT TLS 1.2 + RBAC service by July 23, 2025.

2. APP Release Plan

3. Firmware

Before July 31, 2025, upgrade the configuration of devices with firmware versions lower than 1.0.3.20241209.

4. User Upgrade Guide

4.1 General Process

4.1.1 Where to Find the SN Code

From Sticker

• FJD AT1 Backplane

• FJD AT2 Backplane
  

From Operating Interface

• Old User Interface_Old Version
  

• Old User Interface_New Version

• New User Interface
  

4.1.2 Upgrade Activation Location

• Old User Interface. When there is an over-the-air update, the Click Detecting button will change to Upgrade .
  

• New User Interface

4.2 Before Update

1. Confirm network connection.
2. Confirm data synchronization in the case of data missing.

For FJD AT1 with version 218-  and FJD AT2 with version 412-, try Quick Mode by Clicking the base line icon.

4.3 Upgrade Process

4.3.1 Upgrade APP + Remove SHELL

If the system does not have a shell version, please go directly to step 4

Click on the Upgrade, and the system will initiate the update process.

4.3.2 Confirm SHELL Version

Note: After completing the APP installation, you may need to log in to your account again.

After the update is completed, restart and check if the shell version has disappeared. If it has disappeared, go to Step 3 . If it has not disappeared, go to Step 4 .

4.3.3 Remove SHELL

If SHELL has not been deleted, FAE will send another update. Repeat Step 1 and Step 2. 

4.3.4 Update APP + ECU + RTK + IMU + MOTOR (AT1 below V219)

After SHELL is removed, FAE will send another update.

After the update starts, the APP will first be downloaded, and you need to click "Install" to continue. See below.

• APP starts downloading 

• APP download completed, click "Install" to install the APP 

• Click "Open" to re-enter the application 

• After re-entering the system, the remaining updates will continue to be processed. 

• Update is in progress... 

• Update completed. 

If you are updating from the old UI to the new UI, after installing the new app, subsequent updates will not appear immediately. You need to check for updates again on the system page.

4.4 After Upgrade

After the update is completed, please make sure to power off for 30 seconds and then restart; otherwise, some automatic steering issues may occur. 

If the data in some fields disappears after the update, please try clicking the synchronization button. 

If it still doesn't work,

1. Ensure you are logged in to the correct account;
2. When logging in for the first time, please ensure that you have selected the correct country/region (New UI);
3. Send your account name and SN code to FAE to assist with recovery.

Summary and Acknowledgments

During this external penetration test of the FJDynamics AT2 device, a total of 11 security bugs were discovered, covering multiple components such as firmware, MQTT Broker, Android application, and operating system. The remediation work targeted the above risk vulnerabilities, systematically enhancing the device's security by implementing measures such as unique key generation, strict access control, TLS encryption, and signature verification. Meanwhile, a long-term security mechanism has been established, including regular system updates, code audits, and password policy optimization, to comply with data protection regulations.

We would like to thank the security researchers from the Limes Security team for their professional efforts in this penetration test. Through meticulous technical analysis, they identified multiple security vulnerabilities in the FJDynamics AT2 device and provided practical repair suggestions, laying an important foundation for enhancing the device's security. 

Through the collaboration of both parties, jointly promote the thorough repair of vulnerabilities to ensure the security of user data and the stable operation of devices.